自改进的AI编排系统

发表于 分类于
AI 实践

前两天刷推看到一个案例，一个哥们用 8 天时间搞了 4 万行 TypeScript，17 个插件，3000 多个测试。而且最主要的是，这活儿基本全是 AI 干的。

我当时第一反应是：这特么怎么做到的？

不是”用 AI 写代码”那么简单

我仔细看了下他的做法，发现跟我平时用 Claude Code 的思路不太一样。

我们平时用 AI 编码，基本是这种模式：

  • 打开一个需求
  • 跟 AI 说：帮我实现这个功能
  • AI 写代码，我们 review
  • 提交，等 CI，改 bug
  • 下一个需求

问题在哪？瓶颈不是 AI 写代码的速度，是你切来切去的时间。

你搞完一个需求，AI 在写代码的时候，你干啥？刷 GitHub 等 PR？看 CI 有没有挂？等 Review 反馈？

这哥们说得好：”你自动化了工程，然后用项目管理替换了它。糟糕的项目管理。”

他的解法：让编排器代替你当”项目经理”

这哥们一开始也是写 bash 脚本，搞 tmux 会话、git worktree，让每个 AI 代理有自己的隔离环境。大概写了 2500 行脚本。

然后他想了个狠招：让 AI 代理去改进这个 bash 脚本本身。

结果代理搞出了 v1 版本，v1 又管理构建 v2 的代理，v2 从那以后一直在改进自己。

这就有意思了。

关键是，这个编排器本身也是一个 AI 代理。不是仪表板，不是 cron 任务，不是轮询脚本。它会读你的代码库，理解你的待办列表，决定怎么把一个功能拆成并行任务，分配给不同的编码代理，然后监控进度。

CI 挂了？它把错误日志丢给代理，代理自己读、自己修。

Review 有评论？它带着上下文转发给对应代理。

你什么时候介入？只在真正需要人类决策的时候。

最让我震惊的数字

他说这 8 天里，大概只花了 3 天实际专注工作。其他时间是：

  • 睡前设置好会话，让代理通宵跑
  • 早上审查合并，设置新会话
  • 重复

最夸张的一天，2 月 14 号，一天合并了 27 个 PR。

整个平台交付：核心服务、CLI、web 仪表板、17 个插件、npm 发布。他审查 PR 的速度比阅读速度还快，因为每个 PR 都已经过了 CI 和自动化代码审查。

我算了下，40K 行代码，722 次提交，700 多条自动化代码审查评论。其中 68% 的问题代理自己修了，7% 解释为有意的，只有 4% 推到下个 PR。

这已经不是”用 AI 辅助写代码”了，这是一个自我运转的系统。

核心洞察：编排比单个代理重要

这哥们有个观点我挺认同：

“上限不是 ‘Claude Code 在 TypeScript 方面有多好’，而是 ‘一个系统在部署、观察和改进并行工作的数十个代理方面能有多好’。那个上限要高得多。”

很多人盯着哪个模型更强，Claude 4 还是 GPT-5。但这案例告诉我们，真正重要的是如何协调、管理和改进多个代理。

编排器的智能程度，决定了整个系统的上限。

他设计了一个 8 槽位的插件系统：

  1. Tracker - 拉取问题（GitHub 或 Linear）
  2. Workspace - 创建隔离环境
  3. Runtime - 启动会话
  4. Agent - Claude Code、Aider 等
  5. Terminal - 实时观察
  6. SCM - 创建 PR
  7. Reactions - CI 失败或评论时自动响应
  8. Notifier - 只在需要人类时通知

每个都可以换。不用 tmux？换进程运行时。不用 GitHub？换 Linear。这套东西本身不绑定任何具体工具。

最狠的设计：自改进系统

我觉得最牛的是这个：

每个代理会话都会产生信号——哪些提示词导致了干净的 PR？哪些螺旋进入了 12 次 CI 失败循环？哪些模式导致冲突？

大部分 AI 工具用完就丢了，会话结束，下一个从零开始。

但他的系统会记录性能，跟踪会话结果，运行回顾。它学习哪些任务一次成功，哪些需要更紧的护栏。

代理构建功能 → 编排器观察什么有效 → 调整管理方式 → 代理构建更好的功能。

循环复合，而且每次循环都会放大效果。

因为代理构建了编排器，而编排器让代理更有效，那些代理又继续改进编排器——它是递归的。

工具通过它管理的代理改进自己。

这让我想到一个问题

未来会不会出现越来越多的”一人公司”？

以前你需要一个团队：前端、后端、测试、运维、产品经理。现在，一个人加一个 AI 编排系统，理论上是能完成所有这些角色的工作的。

当然，前提是你有足够的领域知识、架构思维，来设计和指导这个系统。

人类角色在重新定义：不再是”写代码的人”，而是”做架构决策的人”。编码、测试、审查、修复，交给 AI。人类只负责那些真正需要判断和创造的事情。

几个我觉得特别值得借鉴的点

1. 闭环自动化

从 PR 创建 → 自动审查 → 自动修复 → 人工决策 → 反馈学习，整个流程几乎没有人工干预。最夸张的例子：一个 PR 经历了 12 个 CI 失败→修复循环，零人工干预，干净交付。

2. 不依赖代理自我报告

Claude Code 会写结构化的 JSONL 事件文件。编排器直接读这些文件，而不是问代理”你在干啥”。因为代理会撒谎，或者至少会困惑。

3. Git trailer 追踪每次提交的模型

总提交 722 次，Opus 4.6 处理难的东西（复杂架构、跨包集成），Sonnet 处理量（插件实现、测试、文档）。人类做了什么、代理做了什么，一目了然。

4. 只在真正需要时才打扰你

配置大概长这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
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 失败？代理接手。审查者要改？代理自己读评论修代码。PR 通过？Slack 通知你。41 个 CI 失败全部自我纠正，就是这么来的。

这玩意儿对我有什么启发

说实话，这个项目让我意识到，我目前用 AI 的方式还太原始了。

我还在”一个需求一个需求地跑”，人家已经在”批量编排代理通宵干活”了。

差距在哪？

不是工具，是思维模式的差距。

我还在把 AI 当成”更聪明的代码补全”，人家已经把 AI 当成”可以并行工作的团队成员”了。

这个案例给我的启发是：

  1. 别盯着单个代理的能力上限，要想怎么让多个代理协同工作
  2. 建立反馈闭环，让系统从每次运行中学习
  3. 人类只负责关键决策，其他交给自动化
  4. 关注信号收集，什么提示词有效、什么模式容易失败，这些数据很有价值

写在最后

这个项目已经开源了：Agent Orchestrator

我还没试过，但从文档看，安装挺简单的：

1
2
3
4
5
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”的感觉。

原文：https://x.com/agent_wrapper/status/2025986105485733945

项目地址：https://github.com/ComposioHQ/agent-orchestrator