自我改进的 AI 系统：它是如何把自己造出来的

我当时想更快地交付。

我有一个代码库、一堆待办要做，但每天的时间不够用。于是我开始并行跑 AI 编码代理（coding agents）——给每个代理分配一个任务，让它们写代码，我负责审 PR、合并、再循环。我一开始只开两三个，然后变成五个、十个。

代理们很快；问题在我。我跟不上它们。我得盯着 CI 是否通过、读 review 评论、把错误复制粘贴回对话里。我从写代码变成了“带娃”：照看那些会写代码的东西。这完全不可能规模化。

所以我写了一些 bash 脚本来自动化协调——大概 2,500 行，管理 tmux 会话、git worktree 和标签页切换。每个代理都有自己隔离的 tmux 会话和 worktree。编排器可以拉起它们、偷看它们在做什么、把 CI 失败转发回去，还能让我只要问一句“带我去 PR #1121 的标签页”，就能直接跳过去。它能用，但只能说勉强。

然后我把这些 bash 脚本本身也交给代理们去改。它们做出了一个真正的编排器 v1。v1 又去管理代理们去写 v2。而 v2 从那以后一直在自我改进。

结果是：4 万行 TypeScript、17 个插件、3,288 个测试——8 天里写出来的，而且大多数是由系统自己编排的代理完成的。每个提交（commit）都带有一个 git trailer，标识是哪一个 AI 模型写的。人类做了什么、代理做了什么，没有任何歧义。

我们已经开源：Agent Orchestrator（github.com/ComposioHQ/agent-orchestrator）。

关键点是：编排器本身就是一个 AI 代理。它不是仪表盘、不是 cron job、也不是一个轮询 GitHub 的脚本。它是一个代理——它会读你的代码库、理解你的 backlog，决定如何把一个功能拆成可以并行的任务，把每个任务分配给编码代理并监控进度。CI 失败时，它把失败信息注入到对应代理会话里——代理读日志并修复。review 评论来了，它会带着上下文把评论路由到正确的代理会话。整个链路不需要人类做“水管工”。

这就是它和所有“并行跑代理”的方案不一样的地方：管理代理的那个东西，本身是有智能的。

AI 辅助编码的真正瓶颈

大多数人把 AI 编码代理的问题想错了。代理能写代码，这不是瓶颈。瓶颈是你。

你开五个任务，去喝杯咖啡，20 分钟后回来，发现自己只是在刷新 GitHub 标签页——等 PR、看 CI、读 review 评论。恭喜，你把工程自动化了，然后把自己降级成项目经理。还是那种很差的项目经理。

编排器代理把你从这条循环里替换掉。不是用脚本，而是用一个真正的 AI 代理——它对每个活跃会话、每个打开的 PR、每次 CI 运行都有上下文。它跟踪一切，盯着失败，把 review 评论转发给编码代理；只有当确实需要人类决策时才来 ping 你。一旦这个瓶颈——你的注意力——消失，事情就会开始疯狂复利。

你打开 dashboard 看状态，但编排器代理早就已经在工作了：它看过所有工作流，然后告诉你：“这个 PR 正在阻塞另外三个任务；这个 CI 失败是 flaky test；这条 review 评论才是真正重要的那条。”它不是在给你看数据；它是在给你结论和决策。

另一个重要点：任何东西都能插拔。不同的代理运行时？不同的 issue tracker？不同的通知渠道？换掉就行。编排器不在乎你用 Claude Code 还是 Aider，用 tmux 还是 Docker，用 GitHub 还是 Linear。8 个插件槽位，全都可替换。

时间线

人们看到“8 天 4 万行”，会以为我闭关了。我还有一份全职工作。实际上这大概是 8 天里分散的 ~3 天真正专注的工作，其余空档都是代理在填。

模式很简单：睡前把会话都设好，代理们通宵干；早上上班前 review 并合并；再设一批新会话；循环。

最夸张的一天：2 月 14 日（周六）。一天合并了 27 个 PR。整个平台被发出来了——核心服务、CLI、Web dashboard、17 个插件、npm 发布。我 review、合并 PR 的速度快到我都来不及逐行读，但每个 PR 在那之前都已经通过 CI 和自动化代码审查。

哪些模型做了什么

每个提交都会通过 git trailer 记录对应的模型。

总数会超过 722 个提交，因为有些提交是一个模型写的，另一个模型 review/修复的。Opus 4.6 负责硬骨头——复杂架构、跨包集成。Sonnet 负责体力活——插件实现、测试、文档。

全自动代码审查：700 条评论，1% 人类

代理不只是写完代码就扔过墙。这里有一个完整的自动 review 循环：

1. 代理创建 PR 并推送代码
2. Cursor Bugbot 自动 review 并发布行内评论
3. 代理读评论、修代码、再推送
4. Bugbot 再次 review

总计 700 条自动化 review 评论。Bugbot 抓到的都是实打实的问题——通过 exec() 的 shell 注入、路径穿越、未关闭的 interval、缺失的空值检查。代理们大约 68% 会立刻修复，约 7% 会解释为“这是有意为之”，约 4% 会延期到后续 PR。

ao-58 的故事

最戏剧性的例子：PR #125，一个 dashboard 重设计。它经历了 12 轮“CI 失败→修复”的循环。每一次，代理拿到失败输出，诊断问题（类型错误、lint 失败、测试回归），然后推一个修复。没有人类碰过它。

12 轮。零人类介入。干净上线。

9 个分支上的 41 次 CI 失败，最终全部被代理自我纠正。总体 CI 成功率：84.6%。

架构

编排器使用一个带 8 个可替换槽位的插件系统。

会话生命周期：

1. Tracker 拉取一个 issue（GitHub 或 Linear）
2. Workspace 创建一个隔离的 worktree 或 clone
3. Runtime 启动一个 tmux 会话或进程
4. Agent（Claude Code、Aider 等）自主工作
5. Terminal 让你通过 iTerm2 或 Web dashboard 实时观察
6. SCM 创建 PR，并附带上下文信息
7. Reactions 在 CI 失败或 review 评论出现时自动重启/唤起代理
8. Notifier 只在需要人类判断时提醒你

不用 tmux？换成 process runtime。不用 GitHub？用 Linear。不用 Claude Code？插 Aider 或 Codex。任何一块都能替换。

自愈 CI：会修自己失败的代理

这是最有用的功能之一。针对 GitHub 事件的自动响应：

CI 挂了？代理接管。reviewer 请求修改？代理读评论并修代码。PR 被批准？你收到 Slack 通知。这就是那 41 次 CI 失败怎么被自我纠正的——reactions 系统会把失败信息自动转发回代理。

起源：AI 代理在构建自己的编排器

我同时开了 30 个代理在写 Agent Orchestrator。它们在写 TypeScript 版本，而我还在用 bash 脚本版本来管理它们。正在被构建的东西，正是管理它自身构建过程的东西。

我真正做的事情：

• 架构决策（插件槽位、配置 schema、会话生命周期）
• 拉起会话并分配 issue
• review PR（主要是架构层面，不是逐行）
• 解决跨代理冲突（两个代理改同一个文件）
• 判断取舍（否掉这个方案、换另一个）

代理做的事情：

• 所有实现（4 万行 TypeScript）
• 所有测试（3,288 个测试用例）
• 所有 PR 创建（102 个 PR 里有 86 个是代理开的）
• 所有 review 评论修复
• 所有 CI 失败处理

我从不直接往 feature branch 提交。每一行代码都要走 PR。

活动检测

更棘手的问题之一：不问代理，怎么判断它正在干什么。

Claude Code 会在每次会话期间写结构化的 JSONL 事件文件。与其依赖代理自报（它们会“撒谎”，或者至少会搞混），编排器直接读取这些文件：

• 代理是否在持续生成 token？
• 它是在等待工具执行吗？
• 它是空闲的吗？
• 它完成了吗？

agent-claude-code 插件知道怎么解析 Claude 的会话文件。未来的 agent-aider 插件会读取 Aider 的等价文件。

Web dashboard

Next.js 15，使用 Server-Sent Events 实现实时更新。没有轮询。

• 注意力分区（Attention zones）——按“需要你关注什么”对会话分组（CI 失败、等待 review、运行正常）
• 实时终端——浏览器里用 xterm.js 实时展示代理终端输出
• 会话详情——当前编辑的文件、最近的提交、PR 状态、CI 状态
• 配置发现——自动找到你的 ao.config.yaml 并展示可用会话

自我改进的 AI 循环

每个代理会话都会产生信号：哪些提示词能产出干净的 PR？哪些会发散成 12 轮 CI 失败？哪些模式更容易触发合并冲突？

大多数代理方案都会把这些信号丢掉。会话结束，你继续下一件事；下一个会话又从零开始。

Agent Orchestrator 有一个自我改进系统（ao-52——也是由代理构建的），它记录性能、追踪会话结果，并做复盘（retrospective）。它会学到：哪些任务一次就能成功，哪些需要更严格的护栏。

代理构建功能 → 编排器观察哪些有效 → 调整未来如何管理会话 → 代理构建得更好。这个循环会复利。

而且由于代理们构建了编排器，编排器又让代理更有效，这些代理再继续改进编排器——它是递归的。这个工具通过它管理的代理在改进自己。

我认为这就是为什么“编排”比任何单个代理的提升都更重要。天花板不在于“Claude Code 写 TypeScript 有多强”，而在于“一个系统能把几十个并行代理部署、观察、改进到什么程度”。那个天花板要高得多，而且每跑一轮循环就会更高。

下一步：走向全自动软件工程

从任何地方跟你的代理说话。现在你得坐在电脑前。你应该能在散步时用 Telegram 或 Slack 给编排器发消息——查状态、批准合并、重定向一个代理。

更紧的中途反馈。代理会漂移，开始解决错误的问题，把简单修复过度工程化，钻牛角尖。编排器需要把代理正在做的事情和原始意图对齐，在它们浪费 20 分钟之前就注入纠偏。

自动升级（escalation）。代理解决不了？升级给编排器。编排器需要判断？升级给你。你只会看到真正需要人类决策的部分，其他都会自己收敛解决。

再往后：用于并行代理间自动冲突解决的 reconciler、长跑分支的自动 rebase、云端部署的 Docker/K8s runtime、以及社区插件市场。

试试看

启动编排器，打开 dashboard，然后跟它对话。告诉它你要构建什么。它会处理剩下的一切——拉起代理、创建 PR、盯 CI、转发 review 评论。你只要做决策。

我们在找贡献者：新插件（代理运行时、tracker、notifier）、Docker/K8s runtime、用于自动冲突检测的 reconciler、以及更好的升级规则。

仓库在这里：github.com/ComposioHQ/agent-orchestrator

完整指标报告：github.com/ComposioHQ/agent-orchestrator/releases/tag/metrics-v1

构建数据的交互式可视化：pkarnal.com/ao-labs/

我在 Composio 构建 Agent Orchestrator 和开发者工具层。如果你喜欢做“自我改进的 AI 系统”这类问题——我们在 SF 和 Bangalore 都在招人：jobs.ashbyhq.com/composio