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

"The agents can code. That's not the bottleneck. You are." — pkarnal

一个具体的 nightmare

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

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

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

8 天后，他手上有了 40,000 行 TypeScript、3,288 个测试、17 个插件——而且这些东西大部分是那 30 个 agent 自己写的。

项目开源了：Agent Orchestrator（ComposioHQ/agent-orchestrator），MIT 协议，6,800+ stars。

一、核心问题：不是"agent 能不能写"，而是"你能不能管"

费曼会说：先把问题讲清楚，再谈解法。

Agent Orchestrator 解决的问题不是"让 AI 写更好的代码"。那是 Claude Code、Cursor、Codex 的事。它解决的是：当你有 10 个、20 个、30 个 agent 同时工作时，怎么不让你的注意力成为 bottleneck。

具体来说：

关键洞察：agent 之间的协调成本，随着 agent 数量指数增长。2 个 agent 好管，5 个勉强，20 个就是 chaos。Orchestrator 把协调成本从 O(n²) 降到 O(1)——你不需要知道每个 agent 在干什么，你只需要知道"哪些需要我介入"。

二、架构：8 个插槽 + Reactions = 可组合的自动化流水线

Agent Orchestrator 的核心架构出奇地简单。它像是一个乐高底板——8 个标准化的插槽，每个插槽可以插不同的插件。

2.1 八插件插槽

这 8 个插槽的接口定义在 packages/core/src/types.ts 里。一个插件只需要实现对应的接口、导出 PluginModule，就能插进去。

设计哲学：不绑定任何具体工具。你不用 tmux？换 process runtime。不用 GitHub？用 Linear。不用 Claude Code？插 Aider。这种解耦让系统能适配任何已有的工作流，而不是强迫你迁移。

2.2 Session 生命周期：从 issue 到 PR 的自动流水线

一个完整的 session 走 8 步：

1. Tracker 从 GitHub/Linear 拉一个 issue
2. Workspace 创建一个隔离的 git worktree（不是 clone，是 worktree——轻量、共享 object storage）
3. Runtime 启动一个 tmux session 或进程
4. Agent 接收任务，在隔离环境里自主工作
5. Terminal 让你实时观察（iTerm2 或 web dashboard）
6. SCM 自动创建 PR， enriched with 上下文
7. Reactions 监听 GitHub events，自动响应
8. Notifier 只在需要人类判断时通知你

每一步都有明确的接口契约。这意味着：任何一步都可以替换，不影响其他步骤。

2.3 Reactions：自动反馈循环

Reactions 是整个系统最有价值的功能。它定义了当外部事件发生时，系统该做什么：

reactions:
  ci-failed:
    action: send-to-agent
    retries: 2
  changes-requested:
    action: send-to-agent
    escalateAfter: 30m
  approved-and-green:
    action: notify

CI 挂了？ 自动把日志 inject 回 agent session，agent 读取、诊断、修复、重 push。最多试 2 次，还失败就 escalate 给人类。

Reviewer 要求修改？ 自动把 comments 路由到对应 agent，agent 逐条处理。

PR 通过且 CI 全绿？ 通知你，你来 merge（也可以设为 auto-merge）。

这个设计把"外部反馈"变成了"闭环"——不需要人类做中转站。pkarnal 的数据：41 个 CI failures 全部 self-corrected，0 人类干预。

三、三个关键技术细节

3.1 Activity Detection：不靠 agent 自我报告

一个 tricky 的问题：你怎么知道 agent 在干嘛？问它？它会撒谎，或者至少会 confused。

Agent Orchestrator 的解决方案：不问你，我读你的日记。

Claude Code 在运行时会写结构化的 JSONL 事件文件。Orchestrator 直接读这些文件：

• 正在生成 token？→ active
• 等待 tool 执行？→ waiting
• 没动静？→ idle
• 结束了？→ finished

这比"问 agent"可靠得多。pkarnal 说："Agents lie, or at least get confused." 直接读事件文件，绕过 self-reporting 的不可靠性。

3.2 Self-Improvement Loop：系统越用越聪明

大多数 agent 系统跑完就扔了——session 结束，signal 丢失，下个 session 从零开始。

Agent Orchestrator 有个自改进系统（ao-52，它自己也是被 agent 建的），记录：

• 哪些 prompt 产生 clean PR（一次过）
• 哪些需要 guardrails（ spiraled into 12 CI cycles）
• 哪些 CI failures 是 flaky，哪些是 real bug
• 哪些 review comments 是真问题，哪些是 style nitpick

跑一段时间后，orchestrator 能回答："给这个 agent tighter prompt，因为它在这个类型的任务上经常 over-engineer。"

这是递归的：agents 建 features → orchestrator 观察什么有效 → 调整管理方式 → agents 建更好的 features → orchestrator 变得更聪明。工具通过管理 agents 来改进自己。

pkarnal 的原话："The tool is improving itself through the agents it manages."

3.3 Worktree 隔离：轻量且正确

用 git clone 做隔离太重（复制整个 repo）。Agent Orchestrator 用 git worktree——同一个 repo 的多个 checkout，共享 object storage，但各自独立的 working directory。

好处：

• 快：不需要复制 .git，几乎是瞬时创建
• 省磁盘：N 个 worktree 和 1 个 repo 占用差不多
• 正确：每个 agent 在自己的沙盒里，不会互相踩踏
• merge 友好：worktree 天然对应 branch，PR 流程顺畅

对比 Docker 隔离：worktree 隔离的是代码，不是进程。如果两个 agent 要访问同一个 dev server 的端口，worktree 挡不住——这时候需要 port injection 或真正的容器化。这是已知限制，也是未来插件的方向。

四、数据：40K 行 TypeScript 是怎么 8 天建出来的

pkarnal 公布了完整的 metrics。让我直接列关键数字：

时间线：8 天，但 pkarnal 说有 day job，实际专注时间约 3 天。模式是：睡前 setup sessions，agents 通宵工作，早上 review + merge，白天上班，晚上 setup 新一轮。

** standout 的一天**：2 月 14 日，周六，27 个 PR merged。pkarnal 说他在 review PRs "faster than I could read them"——因为每个 PR 已经通过了 CI 和 Bugbot 自动 review。

模型分工：

• Claude Opus 4.6：512 commits（复杂架构、跨包集成）
• Claude Sonnet 4.5：373 commits（插件实现、测试、文档）
• Claude Sonnet 4.6：124 commits

五、Review Loop：不是写完就扔，是真有 review

86 个 PR 里有 700 个 inline comments。谁 review 的？

Bugbot 抓到了 real issues：shell injection via exec(), path traversal, unclosed intervals, missing null checks。Agent 修复了 ~68%，解释了 ~7%（认为是 intentional），defer 了 ~4%。

ao-58 的故事：一个 dashboard redesign PR，经历了 12 轮 CI failure → fix 循环。每轮 agent 读报错、诊断、push fix。零人类干预。最终 shipped clean。

这说明了一件事：自动化的 review 不是摆设。700 个 comments 里有 real bugs，而且 agents 能处理绝大多数。

六、费曼式审视：这是魔法吗？

6.1 "30 个 agent 自己建了自己"——有多 meta？

这个说法很 catchy，但需要拆开看。

真正发生的事：pkarnal 用 bash-script 版本的 orchestrator 管理 30 个 agents，让它们把 bash scripts 重写成 TypeScript 的 orchestrator。新 orchestrator 建好后，开始管理自己的改进。

不是 agents 从无到有创造了一个系统。是 pkarnal 做了架构决策（8 个插槽、session lifecycle、config schema），agents 填了实现。没有 pkarnal 的架构蓝图，agents 不会自动知道"应该做成插件架构"。

费曼会问："如果 pkarnal 没说'要做成插件系统'，agent 会自己想到吗？" 答案是：不会。agents 擅长 execution，不擅长 architecture。

6.2 "100% AI co-authored"的真相

这个数字意味着每行代码都经过 agent 之手。但 pkarnal 自己也说了，他做的事包括：

• 架构决策
• 分配 issue
• Review PRs（主要是架构，不是逐行）
• 解决跨 agent 冲突（两个 agent 改同一个文件）
• 判断 calls（"这个方案不行，试另一个"）

所以"100% AI co-authored"不等于"0% human involvement"。它等于"human 从打字降级到了判断"。

6.3 "41 个 CI failures 全自愈"的边界

这个数字 impressive，但要看 context：

• 这些 failure 都在同一个项目里（Agent Orchestrator 自身）
• 项目有 3,288 个测试，CI 很 solid
• failure 大多是 type errors、lint failures、test regressions——agent 能 read logs 就诊断的

如果 CI failure 是"测试本身设计错了"或"架构级缺陷"，agent 还能自愈吗？可能不行。这些 failure 属于"execution error"（执行层面），不是"design error"（设计层面）。

6.4 Idle Time 问题

第三方评测（augmentcode.com）提到一个 limit：agents 经常在步骤之间 idle 90 秒以上，等 tool approval。如果你按 token 付费，这 idleness 是 real cost。

这说明 orchestrator 在"调度效率"上还有优化空间。30 个并发不等于 30 个同时在工作。

七、竞品对比：为什么不用 Claude Code 的 native teams？

Claude Code 确实有内置的团队协调功能。Agent Orchestrator 的区别在哪？

简单说：Claude Code Teams 是"多个 agent 在一个房间里协作"，Agent Orchestrator 是"一个指挥中心管理多个战场上的 agent"。

其他竞品的定位：

• Claude Squad (AGPL)：TUI 终端，per-edit approval（human-in-the-loop）
• Bernstein (Apache)：确定性调度器 + Janitor 清理
• Intent：spec-driven verification，living artifact 约束 agent 产出
• Microsoft Conductor：YAML workflow，适合已有 Azure DevOps 的团队

Agent Orchestrator 的定位是 milestone gates + auto CI retry（human-on-the-loop）——比 HITL 更自主，比 full-auto 更安全。

八、适用场景与边界

适合的场景

• 中大型代码库（有完善的 CI 和测试）
• 有清晰的 issue/任务 backlog
• 需要并行处理多个独立任务
• 团队已经有 code review 文化

不适合的场景

• 没有 CI 的项目（agents 没有反馈信号）
• 需要 per-edit 人类审批的高风险代码（金融核心、安全模块）
• 小型项目（2-3 个 agent 手动管理就够了，orchestrator 的 overhead 不划算）
• 离线环境（需要 GitHub/Linear API 连接）

九、结语：Agent Orchestrator 的真正意义

Agent Orchestrator 不是"又一个 AI 编程工具"。它是一个信号——说明这个行业正在从"单个 agent 能写多好的代码"转向"多个 agent 如何被有效协调"。

pkarnal 的实验证明了几个关键判断：

1. Execution 已经 commoditized。40K 行代码、3K 测试——agents 能建。这不是魔法，是现在的 baseline。

2. Orchestration 是新的 bottleneck。不是"agent 行不行"，而是"30 个 agent 怎么不互相踩脚、怎么把反馈闭环跑起来、怎么让 human 只介入真正需要判断的地方"。

3. Self-improvement 是 next frontier。系统记录 signal、学习 prompt 效果、调整 guardrails——这个 loop 每跑一圈，ceiling 就抬高一点。

4. Human 的角色变了。不是打字员，是架构师 + 裁判 + 冲突调解员。pkarnal 说："I never committed directly to a feature branch. Every line of code went through a PR." 但他做了所有架构决策。

费曼会怎么总结？

"他们不是在让 agent 替代工程师。他们是在做一个系统，让工程师从管代码变成管 agent。管代码是 craft，管 agent 是 orchestration。后者需要不同的技能——不是 syntax 和 algorithm，而是系统设计和异常处理。"

Agent Orchestrator 的真正价值，不是它 40K 行的代码量，不是它 30 个并发的 impressive 数字。而是它回答了一个问题：当 agent 的生产力超过人类的协调能力时，该怎么办？

答案是：再建一层——让 orchestrator 来协调 agents，让 engineer 来 orchestrate the orchestrator。

Turtles all the way down。

参考链接

• 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
• Composio 官方博客: https://composio.dev/blog/the-self-improving-ai-system-that-built-itself
• 竞品评测: https://www.augmentcode.com/tools/open-source-agent-orchestrators

#AgentOrchestrator #AI编程 #多智能体 #软件工程 #自动化 #费曼视角 #小凯