ReaderMX.
高可用架构

8天，4万行代码：一个递归进化的agent编排器是如何“手搓”出自己的?

高Prateek约 10 分钟

导读：本文详细介绍了作者使用 AI 智能体编排器（Agent Orchestrator）在 8 天内构建 40,000 行 TypeScript 代码的经历，该系统由 AI 智能体自身开发，支持并行任务分解、CI 故障自愈和插件化架构，已开源于 GitHub。

核心创新在于编排器本身就是一个真正的 AI 智能体，能监控多智能体会话、路由审查反馈并仅在需人类决策时介入，解决了人类注意力瓶颈，推动自改进循环以提升整体效率。

作者 Prateek (@agent_wrapper) 是 Composio 的 AI 工程师与 Agent Orchestrator 的核心创建者。他主导开发了开源的 AI 智能体编排系统，用它在 8 天内由智能体自身构建出 4 万行 TypeScript 代码，实现 20 倍人类效率跃升，专注多智能体并行、自愈与自改进工程。

我曾试图加快交付速度

当时我手里有一个代码库，一堆待办需求（backlog），但每天的时间根本不够用。于是我开始让 AI 编程智能体并行运行——给每个智能体分配一个任务，让它们写代码，我来审查 PR、合并，然后循环。刚开始是两三个，然后是五个，最后增加到了十个。

智能体的速度很快，但问题出在我身上。我跟不上它们的节奏。我成了那个检查 CI（持续集成）是否通过、阅读审查意见、把报错信息复制回对话框的人。我从“写代码的人”变成了“给写代码的机器当保姆的人”。这根本无法规模化。

于是，我写了一些 Bash 脚本来自动化协调工作——大约 2,500 行代码，用于管理 tmux 会话、git worktree 和标签页切换。每个智能体都有自己独立的 tmux 会话和工作树。编排器可以启动它们，偷看它们在做什么，转发 CI 失败信息，并让我只需说一句“带我去 PR #1121 的标签页”就能在会话间跳转。这勉强能用。

接着，我让智能体们去处理这些 Bash 脚本本身。它们构建了正式编排器的 V1 版本。V1 管理着构建 V2 的智能体。从那时起，V2 就一直在自我改进。

图像

从 Bash 脚本到自我改进系统

成果如下：40,000 行 TypeScript 代码，17 个插件，3,288 个测试用例——在 8 天内构建完成，且大部分是由该系统编排的智能体编写的。每一条提交（commit）都有 git trailer 标注是哪个 AI 模型编写的。人类做了什么，智能体做了什么，清清楚楚。

我们已经将其开源：Agent Orchestrator[1]。

核心逻辑在于： 编排器本身就是一个 AI 智能体。它不是一个仪表板，不是一个定时任务（cron job），也不是一个轮询 GitHub 的脚本。它是一个智能体——它读取你的代码库，理解你的需求，决定如何将功能拆解为可并行的任务，将任务分配给编程智能体，并监控进度。

当 CI 失败时，它会将失败信息注入智能体会话——智能体读取日志并修复它。当审查意见出现时，它会将其路由到带有上下文的正确智能体会话。无需人工充当“搬运工”。这就是它与所有“并行运行智能体”方案的不同之处：管理智能体的东西本身就是智能的。

图像

AI 辅助编程的真正瓶颈

大多数人对 AI 编程智能体的理解都错了。智能体会写代码，这并不是瓶颈。瓶颈是你。

你启动了五个任务，去喝杯咖啡，20 分钟后回来，然后你就在那不停地刷新 GitHub 标签页——等 PR、查 CI、读审查意见。恭喜你，你自动化了工程开发，却用“项目管理”取而代之了。而且是糟糕的项目管理。

编排器智能体在这个闭环中取代了你。 它不是靠脚本，而是靠一个真正的 AI 智能体，它拥有每个活动会话、每个开启的 PR、每次 CI 运行的上下文。它追踪一切，监视失败，将审查意见转发回编程智能体，并且只有在真正需要人类决策时才会提醒你。

一旦你的注意力——这个瓶颈——消失了，复利效应就会迅速显现。

你打开仪表板查看状态。但编排器智能体已经在工作了——它审视了你所有的工作流并告诉你：“这个 PR 阻塞了另外三个任务，这个 CI 失败是由于测试不稳定导致的，而这条审查意见才是真正重要的。”它不是在向你展示数据，它是在为你提供决策建议。

图像

图像

插件化一切

另一件重要的事：任何东西都可以接入。换个智能体运行时？换个任务追踪器？换个通知渠道？随你。编排器不在乎你用的是 Claude Code 还是 Aider，用 tmux 还是 Docker，用 GitHub 还是 Linear。8 个插件槽位，全部可替换。

时间线

人们看到“8 天 4 万行代码”，以为我躲进山洞闭关了。但我有日常工作。这 8 天里，实际专注工作的时间大概只有 3 天，剩下的空隙全由智能体填补。

图像

模式很简单：睡前设置好会话，智能体整晚工作，早上上班前审查并合并，设置新会话，循环往复。

最亮眼的一天：2 月 14 日星期六。 单日合并了 27 个 PR。整个平台交付了——核心服务、CLI、Web 仪表板、全部 17 个插件、npm 发布。我审查和合并 PR 的速度甚至快过阅读速度，但每个 PR 都预先通过了 CI 和自动化代码审查。

图像

模型分工

通过 git trailers 追踪，我们可以看到各个模型的贡献：

图像

  • Claude Opus 4.6: 负责难点——复杂架构、跨包集成。
  • Claude Sonnet 4.5: 负责走量——插件实现、测试、文档。

（注：总计超过 722 个提交，因为有些提交由一个模型编写，另一个模型审查/修复。）

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

智能体不只是写完代码就扔过墙。这里有一个完整的自动化审查周期：

  1. 智能体创建 PR 并推送代码。
  2. Cursor Bugbot 自动审查并发布行内评论。
  3. 智能体读取评论，修复代码，再次推送。
  4. Bugbot 重新审查。

图像

700 条自动审查评论。 Bugbot 抓住了真正的痛点——通过 exec() 注入 Shell、路径遍历、未关闭的间隔、缺失的空检查。智能体立即修复了约 68% 的问题，解释了约 7% 的设计意图，并将约 4% 的问题推迟到未来的 PR。

图像

ao-58 的故事

最戏剧性的例子：PR #125（仪表板重构）。 它经历了 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 仪表板实时观察
  6. SCM (源码管理) 创建 PR 并用上下文丰富它们
  7. Reactions (响应机制) 在 CI 失败或出现审查意见时自动重新启动智能体
  8. Notifier (通知器) 只有在需要人类判断时才会 ping 你

图像

会话生命周期——从 Issue 到合并的 PR

不用 tmux？使用进程 (process) 运行时。不用 GitHub？使用 Linear。不用 Claude Code？接入 Aider 或 Codex。任何部件都可替换。

自愈式 CI：修复自身错误的智能体

这是最实用的功能。通过 YAML 配置对 GitHub 事件做出反应：

reactions:
ci_failed:
action:spawn_agent
prompt:"此 PR 上的 CI 失败了。阅读失败日志并修复问题。"
changes_requested:
action:spawn_agent
prompt:"已发布审查意见。处理每条评论并推送修复。"
approved:
action:notify
channel:slack
message:"PR 已批准并准备合并。"

CI 挂了？智能体接手。审查者要求修改？智能体读评论改代码。PR 批准了？你在 Slack 收到通知。这就是那 41 次 CI 失败被自我修正的原因——响应机制自动将失败信息转发回智能体。

所谓“递归”：AI 智能体构建自己的编排器

我有 30 个并行智能体在开发 Agent Orchestrator。当我在用 Bash 脚本版本管理它们时，它们正在构建 TypeScript 替代版。被构建的东西正是管理其自身构建的东西。

  • 我做的事：

    • 架构决策（插件槽位、配置模式、会话生命周期）
    • 启动会话并分配 Issue
    • 审查 PR（主要是架构层，不是逐行审查）
    • 解决跨智能体冲突（两个智能体改了同一个文件）
    • 判断决策（拒绝这个方案，尝试那个方案）

  • 智能体做的事：

    • 全部实现（4 万行 TypeScript 代码）
    • 全部测试（3,288 个测试用例）
    • 全部 PR 创建（102 个中的 86 个）
    • 修复所有审查意见
    • 解决所有 CI 失败

我从未直接在功能分支上提交过代码。每一行代码都经过了 PR。

图像

活动检测

一个比较棘手的问题是：如何在不询问智能体的情况下，弄清楚它到底在做什么。

Claude Code 在每次会话期间都会编写结构化的 JSONL 事件文件。编排器不依赖智能体自我报告（它们会撒谎，或者至少会感到困惑），而是直接读取这些文件：

  • 智能体正在生成 token 吗？
  • 它在等待工具执行吗？
  • 它是空闲的吗？
  • 它完成了吗？

agent-claude-code 插件知道如何解析 Claude 的会话文件。未来的 agent-aider 插件也将读取 Aider 的等效文件。

Web 仪表板

基于 Next.js 15，使用 Server-Sent Events (SSE) 进行实时更新。没有轮询 (polling)。

  • 注意力区域 (Attention zones) —— 按需要你关注的事项分组的会话（CI 失败、等待审查、运行正常）
  • 实时终端 (Live terminal) —— 浏览器中的 xterm.js，实时显示智能体的实际终端输出
  • 会话详情 (Session detail) —— 当前正在编辑的文件、最近的提交、PR 状态、CI 状态
  • 配置发现 (Config discovery) —— 自动发现你的 ao.config.yaml 并显示可用会话

自我改进的 AI 闭环

每个智能体会话都会产生信号。哪些提示词产出了干净的 PR？哪些导致了 12 次 CI 失败？哪些模式引发了合并冲突？ 大多数智能体配置都会丢弃这些信号。会话结束，你继续下一个，下一个会话又从零开始。

Agent Orchestrator 拥有一个自我改进系统 (ao-52)——它本身也是由智能体构建的。它记录性能，追踪会话结果，并进行回顾。它学习哪些任务能一次成功，哪些需要更严密的约束。

智能体构建功能 → 编排器观察效果 → 调整未来的管理方式 → 智能体构建更好的功能。 环环相扣，不断叠加。

既然智能体构建了编排器，编排器又让智能体变得更高效，而这些智能体又不断改进编排器——这就是递归的。这个工具正通过它所管理的智能体来改进自身。

我认为这就是为什么**编排（Orchestration）**比任何单一智能体的改进都重要。天花板不在于“Claude Code 写 TypeScript 有多强”，而在于“一个系统在部署、观察和改进数十个并行工作的智能体方面能有多强”。这个天花板要高得多，而且每次循环都在提升。

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

  1. 远程对话： 无论你在哪里都能与智能体对话。现在你需要坐在桌前。未来你应该能在散步时，通过 Telegram 或 Slack 给编排器发消息——检查状态、批准合并、重定向智能体。
  2. 会话中反馈： 智能体容易走偏。它们可能会去解决错误的问题、对简单的修复过度设计、钻牛角尖。编排器需要根据最初的意图检查智能体的工作，并在它们错误方向上浪费 20 分钟之前注入路线修正。
  3. 自动升级： 智能体搞不定？升级给编排器。编排器需要判断？升级给你。你只看那些真正需要人类决策的事。其他一切都能自行解决。
  4. 除此之外： 一个用于在并行智能体之间自动解决冲突的协调器 (reconciler)，用于长时间运行分支的自动 rebase，用于云部署的 Docker/K8s 运行时，以及一个用于社区贡献的插件市场。

立即尝试

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

启动编排器，打开仪表板，告诉它要构建什么。剩下的交由它处理——生成智能体、创建 PR、监控 CI、转发审查意见。你只负责做决定。

我们正在寻找贡献者：新的插件（智能体运行时、追踪器、通知器）、Docker/K8s 运行时、一个用于自动冲突检测的协调器，以及更好的升级规则。

  • 开源仓库已上线：github.com/ComposioHQ/agent-orchestrator[1]
  • 完整指标报告：github.com/ComposioHQ/agent-orchestrator/releases/tag/metrics-v1[2]
  • 构建数据的交互式可视化：pkarnal.com/ao-labs/[3]

我正在 Composio 构建 Agent Orchestrator 和开发者工具层。如果你对研发自我改进的 AI 系统感兴趣——我们正在旧金山 (SF) 和班加罗尔 (Bangalore) 招聘：jobs.ashbyhq.com/composio[4]

原文[5]

References

  1. Agent Orchestrator: https://github.com/ComposioHQ/agent-orchestrator
  2. github.com/ComposioHQ/agent-orchestrator/releases/tag/metrics-v1: https://github.com/ComposioHQ/agent-orchestrator/releases/tag/metrics-v1
  3. pkarnal.com/ao-labs/: https://pkarnal.com/ao-labs/
  4. jobs.ashbyhq.com/composio: https://jobs.ashbyhq.com/composio
  5. 原文: https://x.com/agent_wrapper/status/2025986105485733945

参考阅读

KEEP THE THREAD GOING

更多来源文章