KanBots 看板级并行 Agent 编排：Git Worktree 隔离与状态同步机制

从聊天窗口到看板：Agent 执行范式的转移

当前大多数 AI 编程工具将交互局限在对话流中，用户与单个 Agent 的交互如同在终端里逐条发指令。当任务复杂度上升，这种单线程模式很快成为瓶颈 —— 上下文窗口膨胀、多任务串行等待、代码变更难以追踪。

KanBots 提出了一种不同的思路：将看板（Kanban）作为 Agent 执行的 "系统记录"（system of record），在看板卡片级别运行并行 Agent。每个卡片对应一个独立的执行单元，拥有自己的 Git 工作区、分支和运行状态。这种架构让多 Agent 协作从 "聊天室" 迁移到了 "生产线"。

核心架构：Worktree 隔离与双状态模型

KanBots 的技术底座建立在 Git Worktree 之上。当用户将一张卡片拖入 "进行中"（In Progress）列时，系统会自动创建一个以 kanbots/issue-N 命名的分支，并在独立的 worktree 中启动 Agent 会话。

Git Worktree 是 Git 2.5 引入的特性，允许同一个仓库拥有多个工作目录，共享同一个 .git 对象库但保持文件系统隔离。这种设计对并行 Agent 至关重要：多个 Agent 可以同时修改不同文件而不会产生文件锁冲突，每个 worktree 的变更都限制在自己的分支范围内。

状态管理采用 "双状态" 分离策略：

• Board 状态：存储在 .kanbots/ 目录下的 SQLite 数据库中，包括卡片位置、Agent 运行进度、决策点、成本累计等元数据
• Repo 状态：由 Git 管理，包括分支、提交、代码变更

这种分离让看板可以实时更新（SQLite 写入轻量）而不污染代码仓库的历史记录。当 Agent 完成执行时，worktree 中的变更需要经过人工审查（Review）阶段才能合并回主分支。

并行编排：Persona 轮转与 Slot 管理

KanBots 的 Autopilot 模式支持最多 4 个并行执行 slot。编排器采用 round-robin 算法在预设的 Persona 列表中轮转，每个 slot 原子性地获取下一个 Persona 并执行。

Persona 是一组命名的系统提示词片段，内置包括 Product（产品）、Engineer（工程师）、Reviewer（审查者）、Tester（测试者）等角色。用户也可以定义自定义 Persona，这些配置仅存储在本地 SQLite 中，不会上传云端。

并行执行的关键机制包括：

1. 原子任务认领：每个 slot 在执行前会锁定当前卡片，防止多个 Agent 竞争同一任务
2. 子任务分裂：Agent 在执行过程中发现的新工作可以动态创建子卡片，这些卡片自动进入 Backlog 等待下一轮调度
3. 成本预算控制：用户可设置单次运行和整个会话的成本上限，当累计 token 费用触及阈值时自动停止所有运行中的 Agent

决策流：从静默修改到可审查的交互

传统 Agent 工具常在后台执行工具调用并直接修改代码，用户只能在事后查看变更。KanBots 引入了 "决策提示"（Decision Prompt）机制：当 Agent 需要执行关键操作（如重构核心模块、修改配置文件）时，运行会暂停并弹出带编号的选项列表。

用户可以通过以下方式响应：

• 点击选项继续执行
• 编辑后重新提交
• 使用 slash 命令如 /spec（查看规格）、/review（请求审查）、/split（拆分子任务）

这种设计将 Agent 从 "自动执行" 转变为 "协作执行"，每次代码变更都经过显式确认，符合工程团队对代码审查的流程要求。

成本透明化与 MCP 生态集成

KanBots 内置实时成本分析，按运行、按卡片、按项目汇总 token 消耗。这种透明度对控制 AI 编程成本至关重要 —— 用户可以在看板上直观看到每张卡片的 "价格标签"。

此外，KanBots 提供 MCP（Model Context Protocol）服务器，将看板暴露为可被外部 Agent 调用的工具。这意味着 Cursor、Claude Desktop 等支持 MCP 的客户端可以直接驱动 KanBots 看板，将看板能力整合到更大的 Agent 生态中。

本地优先的工程哲学

KanBots 采用 "本地优先"（local-first）架构：

• 所有数据存储在 .kanbots/ 目录，包括 SQLite 数据库、配置、worktree
• 无需注册云服务账号，无遥测数据上传
• 代码永不离开本地机器
• 支持 GitHub 集成（通过个人访问令牌），可一键将 worktree 提升为 draft PR

这种模式适合对数据隐私敏感的企业环境，也降低了工具采用的门槛 —— 下载即可用，无需配置复杂的服务端基础设施。

实施建议与限制

对于希望采用类似架构的团队，KanBots 提供了可落地的参考模式：

1. Worktree 命名规范：采用 project/issue-N 或 project/feature-slug 格式，便于自动化脚本识别
2. Slot 数量调优：4 slot 上限基于典型开发机器的 CPU / 内存资源，可根据团队规模调整
3. 成本预算分层：建议设置 per-run 预算（防止单次任务失控）和 per-session 预算（防止整体超支）
4. Review 门控：配置 pre-push hook 确保 Agent 不会自动发布代码，强制人工审查环节

当前版本的限制包括：仅支持 Claude Code 和 Codex 两种 CLI，Persona 轮转不支持动态优先级调整，以及并行 slot 的硬编码上限。这些限制在开源 MIT 许可证下可通过二次开发解决。

资料来源

• KanBots 官网：https://kanbots.dev
• Git Worktree 与并行 AI Agent 技术实践：https://developer.upsun.com/posts/ai/git-worktrees-for-parallel-ai-coding-agents

ai-systems