你有没有试过让 Claude Code 写代码，让 Cursor 做 UI 调整，再让 Codex 审一遍？三个 Agent 都装好了，但问题来了——它们怎么知道谁先谁后？改完的代码会不会互相覆盖？出了岔子谁负责？
这其实是 2026 年 AI 工具圈最头疼的问题。GitHub 上有个叫 Kandev 的开源项目，做的事情很直接：把"多个 AI Agent 协作"这件事变成可以拖拽的工作流，而且强制要求每一步都得人审核。
今天我们就拆开看看，这种"多 Agent 编排"工具到底是怎么工作的。
一、为什么不是"一个 Agent 干所有事"
先泼一盆冷水：现在市面上的 Claude Code、Cursor、Codex，每一个单独拿出来都很强，但让它们"联合起来干活"就不行了。原因很现实：
- 协议不通用：Claude 用 Anthropic 的 API，Cursor 走自己的 IDE 协议，Codex 用 OpenAI 的 Responses API
- 状态不互通：Claude 改完的文件，Cursor 不知道；Cursor 写的代码，Codex 看不到上下文
- 算账不方便：跑了多久、烧了多少 token、不同 Agent 的成本怎么分摊，没人统计
Kandev 的解法是：别让 Agent 自己协商，给它们安排一个调度器。
二、20+ Agent 在同一个流水线里接力
打开 Kandev 的界面，你会看到一个类似看板（Kanban）的视图。每个卡片是一个任务，卡片里可以拖拽出多个步骤（Step），每一步指定一个 Agent。
举个例子，一个"给电商网站加购物车功能"的任务可以这样拆：
[Step 1] Claude Opus（设计）→ 给出架构方案和数据模型
↓
[Step 2] GitHub Copilot（实现）→ 按方案写代码
↓
[Step 3] Codex（审查）→ 检查代码质量、提优化建议
↓
[Step 4] 人工 Review Gate ← 这步必须人来
↓
[Step 5] Cursor Pro（UI 调整）→ 改界面细节这就是 Multi-step Pipeline。每个 Agent 只擅长一件事，但串起来能完成一个完整的开发任务。
Kandev 现在内置了 20 多个 Agent 适配器，包括 Claude Code、Codex、Copilot、Cursor Pro、Devin 这些商业产品，也有 OpenCode、Pi、Gemini CLI、Qwen、Kimi 这些开源/国产的。理论上你可以把同一个任务交给完全不同的模型跑——Claude 设计、Qwen 实现、Gemini 审查。
三、最关键的"审核门控"：为什么必须留个人
如果你只看 Kandev 的功能列表，最容易被忽略但其实最重要的一栏叫 Review Gates（审核门控）。
它的规则很简单粗暴：
所有 Agent 产出的变更，必须经过人工审核才能合并到主分支。
听起来像是在拖后腿，对吧？现在不是都讲"全自动"吗？但你真正用过 Claude Code 改过生产代码就知道——它会自信地给你写一个看起来对但其实是错的实现，编译过了，测试也能跑，但上线就炸。
Kandev 的设计哲学是这样写的：
"Humans stay in control. Define tasks, build agentic workflows with gates, review every change, decide what ships."
翻译成人话就是：Agent 是工具，不是替代品。企业真正愿意花钱买的不是"全自动写代码的机器人"，而是"能帮我干 80% 活、但最后 20% 我说了算"的工作流。
这个洞察其实和张小鸣做内容营销很像——AI 可以写 80% 的初稿，但选题、价值观、合规风险必须人来把关。
四、并发 Agent 不打架的秘密：Git Worktree
还有一个工程问题：如果你同时派 5 个 Agent 改同一个仓库的代码，怎么防止它们互相覆盖？
Kandev 的答案是 Git Worktree。
Git Worktree 是 Git 的一个原生功能，可以让同一个仓库在不同的目录下有多个独立的工作分支。每个 Agent 在自己的 Worktree 里干活，互不干扰。最后所有 Worktree 的改动通过 Pull Request 汇合到主分支。
这个思路其实就是 GitHub Flow 的工业化版本。Kandev 把它包了一层 UI，让你可以可视化地看到 5 个 Agent 各自在哪个分支上干活，进度一目了然。
除了本地 Worktree，Kandev 还支持把 Agent 跑在：
- 本地进程（最简单，吃本地资源）
- Docker 容器（隔离干净，适合测试）
- SSH 远程服务器（用公司的开发机跑）
- Sprites 云端（按需启动，省成本）
- K8s 集群（开发中，适合大规模团队）
五、Server-first：为什么可以在手机上用
很多 AI 工具必须装桌面端才能用，但 Kandev 偏偏走Server-first路线——后端是 Go 写的服务，前端是 React 的 SPA，桌面只是一个壳。
好处很明显：
- 电脑没带也能用（手机浏览器访问）
- 团队共享一个后端，不用每个人都装环境
- 数据在自己服务器上（默认存在
~/.kandev，零遥测）
这一点对有数据合规要求的企业特别重要。Cursor 这种 SaaS 工具，代码是要上传到他们服务器的；Kandev 这种自托管工具，代码永远在公司内网。
代价是部署门槛——你需要懂一点 DevOps 才能把它跑起来。但官方给了一行命令：
brew install kandev
# 或者
npx kandev@latest最低门槛只要 Node.js 24。
六、对 AI 学习者的启示：什么场景适合用、什么场景别碰
聊到这里你可能会问：我也想试试，值不值得装？
我给你三个建议：
适合用的场景：
- 你有 3 个以上的 AI 工具订阅（Claude + Cursor + Codex），想串起来用
- 团队协作，每个人的 Agent 配置不一样，需要统一管理
- 你做的是生产代码（电商网站、客户项目），不能容忍 Agent 自动改坏
暂时别碰的场景：
- 你只是写个人 Side Project，单个 Claude Code 就够了
- 公司不允许装 AGPL-3.0 的工具（Kandev 是这个协议，传染性强）
- 你不懂 Git Worktree 概念（用之前最好先补课）
七、写在最后
多 Agent 编排这事，2026 年还在非常早期的阶段。Kandev 不是第一个做的工具（之前有 jCode、Worktrunk、ECC 等），也不会是最后一个。
但它给我最大的启发不是技术，而是产品哲学：AI 越强，越要把"人"放回去。
完全自治听起来很酷，但企业不会买单；半自动 + 强制审核，看起来不性感，但能真正落地。
如果你也在做 AI 工具类产品，不妨想想：你的产品里有没有那个"必须用户确认"的 Gate？
*项目地址：https://github.com/kdlbs/kandev