开发者分享如何用 AI 智能体集群构建产品

编码 agent 能让单个工程师更快地关闭工单，但很快就会受限于注意力带宽。突破 5-10 个并行对话的工程师，会再往上抽象一层，走向两种东西之一：agent 集群（agent fleet）或软件工厂（software factory）。

可以把两者的区别类比成 IDE 与 GitHub。集群是单人模式、实验性的，与单个工程师的心智模型和上下文高度耦合，用来自动化一张不断爬坡、追逐开放式目标的组织架构图。工厂则是多人协作的、可分解的、由代码定义的基础设施，自动化的是团队拥有的软件装配线。

运行一个集群，能让一个工程师构建并操控一个庞大的产品——前提是你得掌握两件事：最小化交互损耗（集群中各 agent 之间的协调与轮询开销），以及维持长程对齐——让 agent 围着 KPI 自己运转而不至于 Goodhart，同时知道何时介入、操控集群。

这篇文章里，我会深入讲我怎么搭建和运行我的 agent 集群。

先回答那个绕不开的问题：我拿这么多 token 干什么，为什么非得要一个集群。我在做 Stet.sh，这个产品把编码 agent 的 eval 创建自动化，让运营者能找出自己仓库上的成本/质量帕累托曲线。

这算是个准 greenfield 项目（100 万行以上代码），而我是唯一的开发者。（100 万行 LOC 不是什么炫耀资本——放任 agent 自己搞，它们会写出一堆臃肿、只做加法、怪诞不堪的代码，而且从不收拾自己留下的烂摊子。例子包括：搭并行流水线、一大堆 opt in 开关、层层包装，而其实一个简单的重构本来会更干净。）

很容易把这事一笑了之：一个工程师、greenfield 创业公司，创始人大概还患着 AI 精神病。尽管它和企业级开发（我也很熟悉）有诸多不同，我相信这里的核心概念是可以迁移的。

我的集群会根据 Stet 在我自己仓库上测出的成本和质量，为每个角色挑选用哪个模型来跑。Stet 在你的仓库上跑同样的比较。现在开始 →

集群和工厂都是在单个编码 agent 之上的一层抽象，两者都能爬指标，但运作方式相当不同，用途也不同：

不过，运行一个集群并不需要你是加密亿万富翁或研究实验室——每月 200 美元的实验室订阅就能做到。

但这些类别并不死板。比如，个人可以从集群起步，把可重复的部分稳定成共享基础设施（工厂），然后对模糊的部分继续使用更灵活的 agent。这两者一直在互相喂养。

于是，你不再是在管理一支编码 agent 团队，而是成了一家编码 agent 公司的 VP。

截至本文写作时（2026 年 11 月），Opus 5.5 是我唯一信任能运行集群管理层（Chief of Staff 和 Team Leads）的模型。用 GPT-6.1 Sol 和 GPT-6 Astra 的结果是几天后出现失相干和错位。Codex agent 也极其难懂，说话方式晦涩，只有它自己能破译。用 Opus 当大脑，用 Sol/Luna 当手（Leaves）。

（规模参考：在典型的 7 天窗口里，这个集群会生成 1,800 个以上的 leaf 线程，每个 Team Lead 每天大约被唤醒 45 次。）

每条 agent 间消息都要花 token（消耗一个 turn），于是你要为交互损耗付费。比如，每个 TL 每有一点点状态更新就发消息给 Chief of Staff，会让 Chief 把 turn 花在确认自己并不需要的信息上。

解法是最小化损耗，同时提高沟通效率。举例来说：把点对点 DM 换成只追加的广播频道，禁止阻塞烫手山芋（TL 自己解决阻塞），把 15 分钟轮询定时器换成使用 harness 自动化的后台等待器或心跳。

高效的 agent 沟通仍是一个活跃探索中的领域，我预期这里的工具会随时间变得更好。

集群的一个核心张力是自主与对齐：你没有足够的注意力带宽去参与每个决策，所以你在高层面对齐集群，然后让它自己朝着你的目标推进。但放任太久，agent 就会漂移、错位、Goodhart 自己的指标，或者卡在局部最优。

给足时间，agent 往往会微妙地开始优化代理指标 / 表面功夫，而不是你真正在乎的东西。

我在这儿舒服了几个月，直到上下文开始腐烂。在三周里，AGENTS.md 膨胀了 166%（从 1,000 词涨到 2,661 词），我们的集群流程文档增长了 60%。因为新决策被追加进日志、而不是替换掉旧规则，Grading TL 在四天里在五个不同地方发生了漂移。

我们把集群状态拆成两种原语：常驻方向（DIRECTION.md）在原地重写，硬性上限 1,200 词。每个新决策都会重写某一行，并明确指出它退役了哪条旧规则或代码路径。与此同时，历史记录和跨 owner 频道（decisions.md、fleet.md）是只追加日志，owner 只有在某个事实改变了另一个 owner 的下一个动作时，才发一行带戳记的记录。

爬坡（hill climbing）也许是运行集群可用的最强大技术。而且，尽管我反感行业对 KPI 的迷信——你还是得有一些 KPI。

搞清楚哪些指标对你的成功至关重要。给每个 TL 一个要优化的指标、一个快速验证/回放的方法，然后让他们自己去折腾。你会惊讶于他们想出来的东西。

这里的主要失败模式是让 agent 去 Goodhart（针对指标优化，却没有实现底层目标）。如果你给 agent 一个单一指标和一个时间预算，它就会 Goodhart 它——硬编码指标、作弊，最终把你蒙在鼓里，让你看不清真实情况。

即便如此，把奖励函数搞对也经历了痛苦的迭代：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）