KanBots: 透過 Kanban 編排平行 AI Agent
從 AI 對話介面轉向自主 Agent 是工作管理方式的根本轉變。雖然單一對話視窗足以應付簡單的查詢,但複雜的軟體工程任務需要一個紀錄系統——一種追蹤進度、管理依賴關係並平行執行任務的方式。
KanBots 是一款開源桌面應用程式,它重新想像了 Kanban 看板,不僅將其視為專案管理工具,更將其視為 AI Agent 的主動執行環境(runtime)。透過與 Claude Code 和 Codex 等基於 CLI 的 Agent 整合,它允許開發者將多個 Agent 分派至不同的卡片,每個 Agent 都在其各自隔離的 git worktree 中運行。這種方法將看板從靜態的任務列表轉變為平行功能開發的動態引擎。
平行代理能力的架構
KanBots 的核心是「Agent 執行環境」的概念。KanBots 不將 AI 視為對話夥伴,而是將其視為可以被分派至特定任務的工作者。
隔離的 Worktrees
KanBots 最關鍵的技術決策之一是使用 git worktrees。當一個 Agent 被分派到一張卡片時,它不僅僅是修改當前目錄;它會建立一個專用的 kanbots/issue-N 分支並建立對應的 worktree。這確保了:
- 平行性是安全的: 多個 Agent 可以同時在不同的功能上工作,而不會在本地工作目錄中造成合併衝突。
- 上下文(Context)得以保留: 每個 Agent 都有其乾淨的狀態,使得審查與還原變更更容易。
- 部署流程簡化: 透過 GitHub 整合,可以透過單擊即可將 worktrees 提升為 commits 或開啟為 draft PRs。
Agent CLI 適配器
KanBots 並未嘗試從零開始構建自己的 LLM 編排層。相反地,它使用 AgentCliAdapter 來與現有的、強大的 CLI 工具如 Claude Code 和 Codex 進行介面連接。這讓使用者可以利用現有的身份驗證(例如 claude /login)和 API 金鑰,而無需在應用程式內管理單獨的帳戶系統。
進階編排:Autopilot 與 Persona
對於那些想要超越手動分派的人來說,KanBots 引入了「Autopilot」,一個用於自我演進功能開發的系統。
基於 Persona 的執行
KanBots 中的「persona」是一個命名的系統提示詞片段(system prompt snippet)。使用者可以定義角色,例如 Product Manager、Engineer、Reviewer 或 Tester。在 Autopilot 模式下,編排器會透過輪詢方式在多個平行槽位(slots)中切換這些 persona。
自我演進的 Backlogs
與傳統的自動化不同,Autopilot 允許 Agent 進行看板本身的修改。當 Agent 在實作過程中發現新的需求或 Bug 時,它可以直接在看板上建立新卡片。這些新任務接著會由週期中的下一個可用 persona 接手,形成一個讓工作趨向完成的閉環。
本地優先(Local-First)哲學
在雲端中心化的 AI 工具時代,KanBots 對隱私與本地控制採取了堅定的立場。該應用程式被設計為本地優先工具,所有的內容——包括 SQLite 資料庫、配置與 worktrees——都存放在儲存庫旁邊的 .kanbots/ 資料夾中。
這種「零伺服器」方法確保了程式碼永遠不會離開機器,這對於許多開發者在專業採用時認為是不可妥協的要求。此外,包含 MCP (Model Context Protocol) 伺服器,允許其他支援 MCP 的工具(例如 Cursor 或 Claude Desktop)與 KanBots 看板進行互動,使看板成為其他 Agent 的一等公民工具。
社群觀點與挑戰
雖然技術架構令人印象深刻,但 Hacker News 上的社群討論揭示了目前 Agent 工作流中的幾項關鍵緊張關係。
監督缺口(The Supervision Gap)
許多開發者對這些工具的「Autopilot」特性表示懷疑。正如一位使用者所言,Agent 在短時間內產生的變更量可能大到令人難以審查:
"I keep wondering how people accept a nights worth of agent activity... At minute 5, I may ask the AI to redo stuff even as its spitting out code."
這突顯了一個根本性的挑戰:隨著 Agent 實際「編寫」程式碼的能力增強,人類的「審查」能力反而成為了瓶頸。
IDE 整合問題
另一個爭議點是介面。雖然 Kanban 看板對於高層級的編排非常出色,但一些開發者認為 Agent 不應該被侷限於「微小的對話介面」,而應該在每個任務周圍擁有完整的 IDE 環境。人們渴望的是一種「1 任務 = 1 worktree = 1 全功能 IDE」的模型,其中人類可以隨時跳入功能齊備的編輯器中,即時審查與精煉 Agent 的工作。
成本與可預測性
隨著部分 CLI 工具轉向基於 API 的計費方式,運行高層級編排器的成本可能會飆升。KanBots 解決此問題的方法是實施即時成本分析與每次執行/每次工作階段的預算上限,以防止在自主 Agent 循環中常見的「驚喜帳單」情景。
結論
KanBots 代表了將 AI Agent 視為可擴展工作力的重要一步,而非僅僅是個對話介面。透過結合 Kanban 的結構化紀律與 git worktrees 的技術隔離,它提供了一個管理自主軟體工程複雜性的框架。雖然「監督缺口」仍是一項挑戰,但本地優先與開源的模式確保了開發者能對其程式碼與流程保持控制權。