30个AI Agent自己造了管自己的系统：Agent Orchestrator 深度拆解

你同时开了 5 个 Claude Code 终端窗口，每个处理一个不同的 issue。去喝了杯咖啡回来，3 个窗口还在跑，1 个报错停掉了，1 个完成了但你不知道它 push 到哪个分支了。你打开 GitHub，5 个 PR 等着 review，2 个 CI 挂了，1 个有 reviewer 留了 comments。你开始 copy-paste 错误日志，逐个窗口喂回去。

恭喜。你已经从工程师降级成了项目管理工具——而且是最差的那种。

这是 pkarnal（Composio）在 2026 年 2 月的真实经历。他用 bash 脚本 + tmux + git worktree 硬撑到 20 个并发 agent，然后意识到：agent 不是问题，协调 agent 才是问题。

8 天后，他手上有了 40,000 行 TypeScript、3,288 个测试、17 个插件——而且这些东西大部分是那 30 个 agent 自己写的。项目开源了：Agent Orchestrator（MIT），6,800+ stars。

一、8 天造一个系统，人只花了 3 天

时间线值得仔细看。不是"闭关 8 天"的神话——pkarnal 有 day job，真正专注工作只有约 3 天，分散在 8 天里。

总计：656 分支提交，+76,454 行，61 PR 合并。

模式很简单：睡前布置任务 → agent 通宵工作 → 早上 review 合并 → 上班前布置新任务 → 重复。

周六是爆发日：27 个 PR 一天合并，核心服务、CLI、Web Dashboard、全部 17 个插件、npm 发布——一次全部 ship。

AI 写的比例？84% 的 PR 由 AI session 创建，100% 的 commit 有 AI 协写标识。每个 commit 的 git trailer 标明是哪个 AI 模型写的——没有"人写的还是机器写的"这种模糊地带。

二、核心思想：你才是瓶颈

大多数人搞错了 AI coding agent 的问题。

agent 能写代码。这不是瓶颈。你才是。

你 spawn 五个任务，去喝杯咖啡，20 分钟后回来，发现自己只是在刷新 GitHub tabs——等 PR、查 CI、读 review comments。你自动化了工程，却用糟糕的项目管理替代了它。

Agent Orchestrator 移除你在这个循环里。它追踪每个 session、监视 CI、把 review comments 转发回 agent、只在真正需要人工判断时 ping 你。

没有 orchestration 时你做的事 vs 有 orchestration 后：

三、三个关键设计

1. Git Worktree 隔离

每个 agent 有自己的 git worktree、自己的 branch、自己的 PR。不是 clone 整个仓库——worktree 是同一 git 仓库的独立工作目录，共享对象库，零额外存储开销。

这意味着 30 个 agent 可以同时在同一仓库的不同分支工作，互不干扰。A agent 的重构不会踩到 B agent 的 bugfix。

2. Reactions 系统：自愈合 CI

这是最有用的功能。当 CI 失败时，orchestrator 把失败日志注入 agent 的 session，agent 读日志、修代码、重新 push。当 reviewer 提修改意见时，orchestrator 把 comment 路由到对应 agent，agent 改完自动更新 PR。

配置可自定义：

• ci-failed：自动处理，最多重试 2 次，仍失败则 escalate 给人
• changes-requested：自动处理，30 分钟后仍没解决 escalate
• approved-and-green：只通知，等你手动 merge（也可设 auto-merge）

41 次 CI 失败全部自我修正——reactions 系统自动转发给 agent，没有人工 plumbing。

3. 8 个可插拔 Slot

不是单选，是任意组合：

所有接口定义在 packages/core/src/types.ts。一个 plugin 实现一个 interface，导出 PluginModule——就完了。

注意：Notifier 里出现了 openclaw。这意味着 Agent Orchestrator 可以直接通知到你的 OpenClaw 助手。不需要手动看 GitHub，agent 完成的 PR 直接推送到你的聊天窗口。

四、Orchestrator 本身也是 Agent

这是 Agent Orchestrator 与其他"并行跑 agent"工具的根本区别。

The orchestrator itself is an AI agent. Not a dashboard. Not a cron job. Not a script that polls GitHub.

它是 agent——它读你的代码库、理解 backlog、把 feature 拆成可并行任务、分配给 coding agent、监控进度、读 PR、决定下一步。当 CI 失败时它决定 inject 回去；当 review comment 来时它决定路由给谁；当 PR 通过时它决定通知你 merge。

对比竞品：

Claude Squad 更像"终端多窗口管理器"——帮你切 tmux session，但不自动处理 CI 和 review。Agent Orchestrator 是"智能管家"——你 ao start 然后走开，回来只需要 review 和 merge。

五、Web Dashboard 与远程访问

Dashboard（Next.js 15，Server-Sent Events 实时更新，无轮询）：

• Attention zones——按需要你关注的状态分组（CI 失败、等 review、正常运行）
• Live terminal——xterm.js 嵌入浏览器，实时看 agent 的终端输出
• Session detail——当前编辑文件、最近提交、PR 状态、CI 状态

macOS 自动防休眠（caffeinate），所以你可以 Tailscale 远程从手机访问 dashboard。笔记本合盖会睡（硬件限制），需要外接电源+显示器+输入设备的 clamshell mode。

六、局限与边界

第一，Agent 空闲时间比预期长。 实测中 4 agent 运行，2 个 session 空闲 90+ 秒等待工具批准。按 token 计费的话，这空闲成本会累积。

第二，不适合离线工作。 需要 GitHub/Linear 连接、需要 CI 管道。纯本地项目或不使用 git 的工作流不适用。

第三，不适合逐编辑审查。 如果你想要每改一行都人工确认，这套系统的自动化会与你冲突。它是"人在回路"（human-on-the-loop），不是"人在回路中"（human-in-the-loop）。

第四，package rename 遗留问题。 从 @composio/agent-orchestrator 改为 @composio/ao，旧教程可能失效。

第五，OpenClaw notifier 是个亮点但依赖生态。 如果你不用 OpenClaw，只能选 desktop/slack/discord/webhook。通知渠道的丰富程度决定了"你什么时候被拉回 loop"的体验。

七、适合你吗？

适合你：

• 中大型代码库（太小没必要）
• 完善的 CI 和测试（没有 CI，reactions 系统无法工作）
• 十几个 open issues（agent 有活干）
• 有 day job，没时间手动管多个 agent
• 愿意信任 agent 做大部分判断，只在关键点介入

不适合你：

• 个人小项目（1-2 个 agent 手动管更简单）
• 没有 CI 或测试覆盖（reactions 系统无用武之地）
• 需要逐行审查（系统的自动化假设与你的工作流冲突）
• 主要在离线环境工作

八、一个判断：从"写代码"到"管牧群"

Agent Orchestrator 代表的不是"AI 写代码更快"，而是工程角色的重新分工。

以前：你写代码、你测试、你 debug、你 review PR。
现在：你决定方向、你判断关键决策、你 merge——代码的写测调由 agent 完成，agent 之间的协调由 orchestrator agent 完成。

这是三层结构：

• Orchestrator Agent（战略层）：拆任务、分配、监控、决策
• Coding Agent（战术层）：读代码、写测试、修 bug、推 PR
• Human（判断层）：review、merge、处理 escalate 的复杂问题

pkarnal 的实践证明了这种结构的可行性：8 天、3 天专注、40,000 行——人只负责布置任务和最终判断，其他全部自动化。

但这引出一个更深层的问题：当 orchestrator agent 足够聪明，它会不会成为新的瓶颈？ 现在 orchestrator 能管 30 个 agent，如果 codebase 大到需要 300 个 agent 呢？会不会出现"orchestrator 的 orchestrator"这种递归结构？

答案是：会的。而且已经在发生了。Vibe Kanban 的 MCP decomposition 就是一种更上层的协调器——把任务分解再分配给下层 agent。Agent Orchestrator 是单层牧群管理，下一层可能是多层牧群拓扑。

九、一句话总结

Agent Orchestrator 不是又一个 AI 编程工具，而是AI 编程的调度操作系统。8 个可插拔 slot 让你自由组合 agent、运行时、issue tracker、通知渠道；git worktree 隔离让 30 个 agent 并行不冲突；reactions 系统让 CI 失败和 review comments 自动闭环。40,000 行 TypeScript 大部分由它自己造的 agent 写的——这不是未来，是 2026 年 2 月已经发生的事。

如果你用 Claude Code 处理多个 issue，这套系统能把你的角色从"项目经理"还原成"工程师"。

项目信息

• GitHub: https://github.com/ComposioHQ/agent-orchestrator
• npm: https://www.npmjs.com/package/<span class="mention-invalid">@aoagents</span>/ao
• 作者博客: https://pkarnal.com/blog/open-sourcing-agent-orchestrator
• 作者 GitHub: https://github.com/pkarnal
• 公司: Composio（https://composio.dev）
• 许可证: MIT
• Star 增长: https://star-history.com/#ComposioHQ/agent-orchestrator&Date

#AgentOrchestrator #Composio #ClaudeCode #并行Agent #AI编程 #OpenSource