KanBots 发布了一款 MIT 许可的开源桌面应用，试图把 AI 编程代理从“聊天窗口里的助手”推进到“看板上的任务执行系统”。用户把代码仓库文件夹拖入应用后，可以得到一张 Kanban 看板，并在不同卡片上并行运行 Claude Code CLI 或 Codex CLI；每个任务会创建独立 git worktree，并运行在 kanbots/issue-N 分支。

这件事重要的地方，不是 KanBots 声称代理能写多少代码，而是它把并行、暂停决策、成本统计和 Git 隔离这些工程团队真正关心的环节做成了产品界面。对已经在用 Claude Code、Codex 或 Cursor 的独立开发者来说，这类工具解决的不是“有没有 AI”，而是“AI 乱跑之后谁来收拾现场”。

KanBots 把代理执行放进了看板，而不是聊天框

KanBots 的基本形态很直接：看板负责承载任务，卡片负责触发代理，worktree 负责隔离代码变更。官方页面显示，桌面版支持 macOS、Linux 和 Windows，代码开源在 GitHub，标注为 v1.0、MIT licensed，并采用“free forever”和自愿捐赠模式。

它支持两类 CLI：Anthropic 的 Claude Code CLI 和 OpenAI 的 Codex CLI。用户可以复用已有的 claude /login、codex login 或 OPENAI_API_KEY，KanBots 在应用侧通过统一的 AgentCliAdapter 处理两者输出流。

项目KanBots 桌面版做法对开发者的影响
任务组织Kanban 卡片触发代理运行多个需求、Bug、重构可并行排队
代码隔离每个代理使用独立 worktree 和 kanbots/issue-N 分支降低不同代理互相覆盖改动的风险
过程控制决策提示会暂停，用户选择后继续避免代理静默修改关键路径
成本管理实时统计 per-run、per-card、per-project 成本，可设预算更适合长任务和多代理并发场景

这里的判断要谨慎。官网称“0 bytes leave your machine”，但这不能被理解为模型推理和代码内容绝对不离开本机。KanBots 桌面版宣称的是应用侧无云账号、无遥测、无服务器；实际运行仍依赖 Claude Code CLI 或 Codex CLI，以及对应服务商的认证、接口和数据处理规则。

Autopilot 的亮点是编排，风险也是编排

KanBots 最有辨识度的功能是 Autopilot。用户可以配置 product、engineer、reviewer、tester 等 personas，设置最多 4 路并行。编排器会轮转这些 persona，把父任务拆成子任务，让新卡片进入 backlog，并在完成或达到会话预算后停止。

这比单次聊天式代码生成更接近工程现场。一个功能从需求、实现、评审到测试，本来就不是单线流程。KanBots 把这些角色抽象成可复用 system prompt，并允许代理在发现新工作后继续拆分任务，这等于把“代理会话”提升为一个轻量工作流。

但这也是最需要观察的部分。persona 拆任务是否可靠，QA mode 跑 typecheck、tests、lint、build、e2e 后自动派生修复任务是否会陷入循环，预算上限能否真实约束长链路任务，目前都只能依据产品设计来判断，不能写成经过第三方验证的生产效果。

横向看，Cursor、Claude Code 和 GitHub Copilot 更像是把 AI 放在编辑器或命令行旁边；Jira、Linear、GitHub Issues 则负责项目管理。KanBots 的位置介于两者之间：它不试图替代 IDE，而是把代理运行状态、成本和 Git 产物绑定到任务卡片上。这是一个聪明的切口，也意味着它必须同时经受开发工具和项目工具两边的挑剔。

本地优先适合个人，团队协作仍要看云端边界

KanBots 明确把产品分成开源桌面版和 Cloud for teams。官方说，本地版的代码与数据存放在仓库旁的 .kanbots/ 目录，包括 SQLite 数据库、配置和 worktrees；不需要云账号，没有遥测，也没有 HTTP server。云端功能则面向多人或多设备协作。

这个边界对用户决策很关键。独立开发者、开源维护者、小型 side project 作者，可能会喜欢这种“代码在旁边、状态在本地、预算可见”的工作方式。尤其当一个人同时处理多个 issue 时，KanBots 能把代理从临时助手变成可追踪队列。

工程团队则不能只看开源版。多人评审、权限管理、共享看板、跨设备同步和审计需求，天然会把他们推向云端或现有协作系统。KanBots 提供 GitHub Issues、草稿 PR、MCP server、QA mode 等集成，说明它懂开发流程；但能否进入团队工具链，还要看它和 GitHub、Linear、Jira、Cursor、Claude Desktop 等现有入口的摩擦有多小。

接下来最该看三件事：GitHub 上的真实 issue 与 PR 活跃度，用户在复杂仓库里的失败案例，以及成本上限在多代理并发时是否足够可预期。AI 编程代理的下一步竞争，不只是模型谁更会写代码，而是谁能让人放心地让它同时做四件事。