自我改进的 AI 系统：它自己构建了自己

AI Agent 开源 转载

以下是 @agent_wrapper（prateek）发布的 X Article 原文完整转载。

自我改进的 AI 系统：它自己构建了自己

我想加快交付速度。

我有一个代码库，有一堆待做的事，却没有足够的时间。于是我开始并行跑多个 AI 编程 agent——每个分配一个任务，让它们写代码，审 PR，合并，循环往复。最开始跑两三个，后来五个，再后来十个。

agent 跑得很快，问题出在我身上。我跟不上它们的节奏。检查 CI 有没有过、读 review 评论、把报错复制粘贴回去——这些都得我来。我从写代码的人，变成了给写代码的东西当保姆的人。这根本没法扩展。

于是我写了一批 bash 脚本来自动化这些协调工作——大概 2500 行，负责管理 tmux session、git worktree 和标签页切换。每个 agent 都有自己独立的 tmux session 和 worktree。编排器可以创建 agent、查看它们的进展、把 CI 失败的信息反馈回去，还能让我只需说一句"切到 PR #1121 的标签页"就能在 session 之间跳转。勉强能用。

然后我把 agent 指向那批 bash 脚本本身，让它们构建出一个正式编排器的 v1 版本。v1 负责管理构建 v2 的那些 agent，而 v2 从那以后一直在自我改进。

From bash scripts to self-improving system
From bash scripts to self-improving system

最终的结果：40000 行 TypeScript 代码，17 个 plugin，3288 个测试——8 天内完成，主要由系统所编排的 agent 构建。每一条 commit 都带有 git trailer，标明是哪个 AI 模型写的。人类做了什么、agent 做了什么，一目了然，毫无歧义。我们已将其开源：Agent Orchestrator（github.com/ComposioHQ/agent-orchestrator）。

有一点至关重要：编排器本身就是一个 AI agent，而不是什么仪表盘、cron job，也不是轮询 GitHub 的脚本。它是一个 agent——读取你的代码库，理解你的 backlog，决定如何把一个功能拆解成可并行的任务，把每个任务分配给对应的编程 agent，并监控它们的进展。当 CI 失败时，编排器会把失败信息注入到对应的 agent session 里，agent 读取日志并修复问题；当 review 评论进来时，编排器会把评论连同上下文一起路由到正确的 agent session。不需要人工串联。这正是它与所有"并行跑 agent"方案的本质区别——管理这些 agent 的东西，本身就是智能的。

AI 辅助编程的真正瓶颈

大多数人对 AI 编程 agent 的问题判断错了。agent 会写代码，这不是瓶颈。瓶颈是你。

你一次启动五个任务，去倒杯咖啡，20 分钟后回来，发现自己只是在不停刷 GitHub 标签页——等 PR 合并、看 CI 状态、读代码审查意见。恭喜你，成功把工程工作自动化了，然后用项目管理把自己填了进去。而且还是很糟糕的项目管理。

编排 agent 的作用，就是把你从这个循环里替换出去。替换你的不是脚本，而是一个真正的 AI agent——它对每一个活跃 session、每一个开放中的 PR、每一次 CI 运行都有完整上下文。它追踪所有事情，监控失败，把代码审查意见转发回编码 agent，只有在真正需要人来决策的时候才通知你。一旦这个瓶颈——你的注意力——被消除，事情就开始快速复利。

你打开 dashboard 查看状态，但编排 agent 已经在工作了——它扫完了你所有的工作流，然后告诉你：“这个 PR 正在阻塞另外三个任务，这个 CI 失败是个 flaky test，这条审查意见才是真正需要处理的。“它不是在展示数据，而是在给你决策结论。

另一件重要的事：什么都可以接进来。想换 agent 运行时？换 issue tracker？换通知渠道？直接换。编排 agent 不在乎你用 Claude Code 还是 Aider，用 tmux 还是 Docker，用 GitHub 还是 Linear。八个 plugin 插槽，全部可替换。

时间线

看到"8 天写了 4 万行代码”，大家可能以为我把自己关在山洞里没日没夜地干。但我还有正职工作。这 8 天里，真正专注投入的时间大概只有 3 天左右，剩下的空隙全靠 agents 来填。

模式很简单：睡前配置好会话，agents 通宵干活，早上上班前 review 并 merge，再配置新的会话，如此循环。

最高产的一天是 2 月 14 日周六。单日合并了 27 个 PR，整个平台就此成型——核心服务、CLI、Web 控制台、全部 17 个 plugin、npm 发布，全部搞定。我 review 和 merge PR 的速度快得自己都来不及细看，但每个 PR 都已经通过了 CI 和自动化 code review。

Daily activity — commits and PRs merged over 8 days
Daily activity — commits and PRs merged over 8 days

各模型分工

每次 commit 都通过 git trailers 记录了使用的模型：

commit 数合计超过 722，因为部分 commit 是由一个模型写出来、再由另一个模型 review 和修复的。Opus 4.6 负责攻坚——复杂的架构设计、跨 package 的集成；Sonnet 负责走量——plugin 实现、测试、文档。

全自动代码审查：700 条评论，人工介入不到 1%

Agent 不只是写完代码就扔出去了事。整个流程有一套完整的自动化审查循环：

  • Agent 创建 PR 并推送代码
  • Cursor Bugbot 自动审查，发布行内评论
  • Agent 读取评论，修复代码，再次推送
  • Bugbot 重新审查

700 条自动化代码审查评论。Bugbot 抓出了真实问题——通过 exec() 引发的 shell injection、path traversal、未关闭的 interval、缺失的 null checks。Agent 立即修复了约 68% 的问题，约 7% 被解释为有意为之，另有约 4% 推迟到后续 PR 处理。

Code review pipeline — from agent PR to ship
Code review pipeline — from agent PR to ship

ao-58 的故事

最戏剧性的案例：PR #125，一次仪表板重构。这个 PR 经历了 12 轮 CI 失败→修复循环。每次失败，Agent 都会拿到失败输出，诊断问题（类型错误、lint 失败、测试回归），然后推送修复。全程没有人工介入。

12 轮。零人工干预。干净交付。

跨 9 个分支共 41 次 CI 失败，最终全部由 Agent 自行修正。整体 CI 成功率：84.6%。

架构

Orchestrator 采用插件系统，共有 8 个可替换插槽：

Session 生命周期：

  • Tracker 拉取一个 issue（GitHub 或 Linear）
  • Workspace 创建隔离的 worktree 或 clone
  • Runtime 启动 tmux session 或进程
  • Agent（Claude Code、Aider 等）自主执行任务
  • Terminal 让你通过 iTerm2 或 Web 面板实时观察进度
  • SCM 创建 PR，并为其补充上下文信息
  • Reactions 在 CI 失败或收到 review 评论时自动重新启动 Agent
  • Notifier 仅在需要人工判断时才通知你

Session lifecycle — from issue to merged PR
Session lifecycle — from issue to merged PR

不用 tmux？切换到 process runtime。不用 GitHub？换成 Linear。不用 Claude Code？接入 Aider 或 Codex。任意模块都可以替换。

自愈 CI：能自己修复故障的 Agent

这是最实用的功能。对 GitHub 事件自动响应：

reactions:
  ci_failed:
    action: spawn_agent
    prompt: "CI failed on this PR. Read the failure logs and fix the issues."
  changes_requested:
    action: spawn_agent
    prompt: "Review comments have been posted. Address each comment and push fixes."
  approved:
    action: notify
    channel: slack
    message: "PR approved and ready to merge."

CI 挂了？Agent 自动接手。Reviewer 提了修改意见？Agent 读完评论、改完代码。PR 通过审核？你会收到一条 Slack 通知。那 41 次 CI 失败能自动修复，靠的就是这套 reactions 机制——它把每次失败直接转发给 Agent 处理。

盗梦空间式的递归：AI Agent 亲手搭建自己的编排系统

我同时跑了 30 个 Agent 来开发 Agent Orchestrator。它们在用 TypeScript 写替代版本，而我则在用旧的 bash 脚本版来管理它们。被构建的工具，正在管理自身的构建过程。

我实际做了什么：

  • 架构决策（插件插槽、配置 schema、session 生命周期）
  • 启动 session、分配 issue
  • Review PR（主要看架构，不逐行审）
  • 解决跨 Agent 冲突（两个 Agent 同时编辑同一个文件）
  • 拍板判断（否定这个方案，换那个方向）

Agent 做了什么：

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

我从未直接向功能分支提交代码。每一行代码都经过 PR 合入。

活动检测

最棘手的问题之一：在不询问 agent 的情况下，搞清楚它到底在干什么。

Claude Code 在每次会话期间都会写入结构化的 JSONL 事件文件。编排器不依赖 agent 自我汇报（它们要么说谎，要么自己也搞混了），而是直接读取这些文件：

  • agent 是否正在生成 token？
  • 是否在等待工具执行？
  • 是否处于空闲状态？
  • 是否已经完成？

agent-claude-code 插件知道如何解析 Claude 的会话文件。未来的 agent-aider 插件也会以同样的方式读取 Aider 的对应文件。

Web 控制面板

Next.js 15，用 Server-Sent Events 实现实时更新，无需轮询。

  • 关注区 — 按需要处理的紧急程度对会话分组（CI 失败、待 review、正常运行中）
  • 实时终端 — 在浏览器中嵌入 xterm.js，实时展示 agent 的实际终端输出
  • 会话详情 — 当前正在编辑的文件、最近的 commit、PR 状态、CI 状态
  • 配置发现 — 自动找到你的 ao.config.yaml，并展示可用的会话列表

自我进化的 AI 循环

每一次 agent 会话都会产生信号。哪些 prompt 最终生成了干净的 PR？哪些陷入了 12 次 CI 失败的死循环？哪些模式导致了 merge 冲突？

大多数 agent 方案都把这些信号直接丢掉了。会话结束，你继续向前，下一次会话从零开始。

Agent Orchestrator 内置了一套自我提升系统（ao-52，它本身也是由 agent 构建的），会记录性能数据、追踪会话结果、并定期做复盘。它会学习哪类任务第一次就能成功，哪类任务需要更严格的约束。

agent 构建功能 → 编排器观察哪些方式奏效 → 调整管理未来会话的策略 → agent 构建出更好的功能。这个循环会不断复利叠加。

而且，因为是 agent 构建了编排器，编排器又让 agent 更高效，这些 agent 再持续改进编排器——整个过程是递归的。这个工具通过它所管理的 agent，在持续地改进自身。

我觉得这正是为什么编排层比任何单个 agent 的进步都更重要。上限不是"Claude Code 写 TypeScript 能有多好”，而是"一个系统能在并行调度、观察、改进数十个 agent 这件事上做到多好"。后者的上限要高得多，而且每跑一次循环，这个上限都会再往上升一点。

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

随时随地与 Agent 对话。 现在你必须坐在电脑前才能操作。理想状态是：你在散步时也能通过 Telegram 或 Slack 给 orchestrator 发消息——查看进度、批准合并、给 agent 调整方向。

会话中途的反馈要更及时。 Agent 会跑偏。它们可能开始解决错误的问题，把一个简单修复过度设计，或者钻进某个兔子洞出不来。Orchestrator 需要持续对照原始意图检查 agent 的工作，在它们浪费 20 分钟走错方向之前及时纠偏。

自动升级机制。 Agent 搞不定？升级给 orchestrator。Orchestrator 需要判断？升级给你。你只需要处理真正需要人来决策的事情，其余的一切自动解决。

此外还在规划：用于并行 agent 之间自动冲突解决的 reconciler、长期运行分支的 auto-rebase、云端部署的 Docker/K8s runtime，以及面向社区贡献的 plugin 市场。

试一试

git clone https://github.com/ComposioHQ/agent-orchestrator.git
cd agent-orchestrator
pnpm install && pnpm build
ao init --tracker github --agent claude-code --runtime tmux
ao start

启动 orchestrator，打开 dashboard，直接告诉它你想构建什么。剩下的事它来处理——派出 agent、创建 PR、监控 CI、转发 review 评论。你只需要做决定。

我们正在寻找贡献者：新 plugin（agent runtime、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 系统感兴趣——我们正在旧金山和班加罗尔招人：jobs.ashbyhq.com/composio

原文出处: @agent_wrapper（prateek）发布于 X，2026-02-23 原文链接: https://x.com/agent_wrapper/status/2025986105485733945 项目地址: github.com/ComposioHQ/agent-orchestrator

☕ 如果这篇文章对你有帮助，欢迎请我喝杯咖啡，支持我继续创作更多内容。

Buy me a coffee