--- title: "8天，4万行代码：一个递归进化的agent编排器是如何“手搓”出自己的?" source: wechat url: https://mp.weixin.qq.com/s/yHy3vfASiMQ9S9g_1ao1kw ingest_date: 2026-07-04 vxc: 64 stars: 4 sha256: 363e84f77ecec0d88206595a4d18a8723fa9debe3d6a0966f5fec20c5e935bb8 --- # 8天，4万行代码：一个递归进化的agent编排器是如何“手搓”出自己的? **来源**: 高可用架构 **发布日期**: 2026-03-11 **原文链接**: https://mp.weixin.qq.com/s/yHy3vfASiMQ9S9g_1ao1kw --- 导读：本文详细介绍了作者使用 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% 智能体不只是写完代码就扔过墙。这里有一个完整的自动化审查周期： - 智能体创建 PR 并推送代码。 - Cursor Bugbot 自动审查并发布行内评论。 - 智能体读取评论，修复代码，再次推送。 - Bugbot 重新审查。 700 条自动审查评论。 Bugbot 抓住了真正的痛点——通过 exec() 注入 Shell、路径遍历、未关闭的间隔、缺失的空检查。智能体立即修复了约 68% 的问题，解释了约 7% 的设计意图，并将约 4% 的问题推迟到未来的 PR。 ## ao-58 的故事 最戏剧性的例子： PR #125 （仪表板重构） 。 它经历了 12 次“CI 失败 → 修复”循环 。每一次，智能体都会拿到失败输出，诊断问题（类型错误、lint 失败、测试回归），并推送修复方案。 全程无人工干预。 12 轮循环，零人工参与，最终干净交付。 在 9 个分支中发生的全部 41 次 CI 失败，最终都被智能体自我修正。 整体 CI 成功率：84.6%。 ## 架构 编排器使用了一个包含 8 个可替换插槽的插件系统： 会话生命周期： - Tracker (追踪器) 拉取一个 Issue (GitHub 或 Linear) - Workspace (工作区) 创建一个隔离的 worktree 或 clone - Runtime (运行时) 启动一个 tmux 会话或进程 - Agent (智能体) (Claude Code, Aider 等) 自主工作 - Terminal (终端) 让你通过 iTerm2 或 Web 仪表板实时观察 - SCM (源码管理) 创建 PR 并用上下文丰富它们 - Reactions (响应机制) 在 CI 失败或出现审查意见时自动重新启动智能体 - 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 有多强”，而在于“一个系统在部署、观察和改进数十个并行工作的智能体方面能有多强”。这个天花板要高得多，而且每次循环都在提升。 ## 下一步：迈向全自主软件工程 - 远程对话： 无论你在哪里都能与智能体对话。现在你需要坐在桌前。未来你应该能在散步时，通过 Telegram 或 Slack 给编排器发消息——检查状态、批准合并、重定向智能体。 - 会话中反馈： 智能体容易走偏。它们可能会去解决错误的问题、对简单的修复过度设计、钻牛角尖。编排器需要根据最初的意图检查智能体的工作，并在它们错误方向上浪费 20 分钟之前注入路线修正。 - 自动升级： 智能体搞不定？升级给编排器。编排器需要判断？升级给你。你只看那些真正需要人类决策的事。其他一切都能自行解决。 - 除此之外： 一个用于在并行智能体之间自动解决冲突的协调器 (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 - Agent Orchestrator: https://github.com/ComposioHQ/agent-orchestrator - github.com/ComposioHQ/agent-orchestrator/releases/tag/metrics-v1: https://github.com/ComposioHQ/agent-orchestrator/releases/tag/metrics-v1 - pkarnal.com/ao-labs/: https://pkarnal.com/ao-labs/ - jobs.ashbyhq.com/composio: https://jobs.ashbyhq.com/composio - 原文: https://x.com/agent_wrapper/status/2025986105485733945 ## 参考阅读 - 如何手搓一个 CLI：只需 80 行代码，彻底看清 AI 的底层逻辑 - 从任务到系统：深度拆解2027年百万年薪的6项AI核心技能 - Context 不是免费的：解析长文档 agent 的性能天花板与架构优化 - 别再死磕模型调优了！Cursor和Manus告诉我们: 外壳(Harness)才是真正的护城河 - 像智能体一样观察：Anthropic 团队谈 Claude Code 工具设计的演进与艺术