← 随机比特 / 所有内容

multi agent bottleneck

2026-04-26 · 随机比特

Steve Yegge 说 320 个 Claude Code 实例并行，我跑 3 个就开始打架

Steve Yegge 这周抛了一个数字：320 个 Claude Code 实例并行。他说这是 2026 年底"高级程序员"的工作日常——不再敲代码，而是"在策略层调度一支智能体军团"。

中文公众号一周 26 条 Claude Code 实战 + 19 条 AI 编程工具大乱斗，连带把这个 320 的数字推成了爆点。所有转载的标题都在惊呼：未来已来。

先承认 Yegge 是真在跑这件事。但有一个更具体的数字想跟他对照：我们跑 3 个 agent 串行就摸到了多 agent 工程的天花板。

不是 LLM 的天花板。是编排的天花板。

这 3 个 agent 是什么

不复杂。一个内容 cron：

每个 agent 都是 claude -p 给一段 prompt 跑出来。三段串行，原本计划 2 小时跑完。

跑了 5 天，撞到 3 个跟 LLM 能力无关的坑。每一个坑解决之后才意识到：再扩到 30 个、300 个，问题不是变难一点，是质变。

坑一：prompt 边界不是「该做什么」，是「不该做什么」

agent 1 的 prompt 写：「按 SKILL.md 的 Turn 0 步骤采集」。

跑下去 24 分钟核心活做完，然后 agent 接着跑了 66 分钟，撞 90 分钟 timeout 被 kill。

去翻日志才发现：SKILL.md 把"采集→评分→写作"绑在同一个 turn 描述里，agent 看完 SKILL.md 又顺着 reference 翻到 writing-pipeline.md（一份"完整步骤清单"），它的合理推断就是：核心采集做完后接着跑评分、跑爆款分析、能做到第几步算第几步——直到撞 90 分钟 timeout。

它不是在"瞎做"。它是在按它能找到的最详细文档"勤勉地"做事。

写脚本的本能是「列出该做什么」，写 LLM prompt 的本能也是「列出该做什么」。但 LLM 跟脚本的差别就是这里——脚本没写的指令永远不会跑，LLM 没写的边界它自己拼。你不写「不要打开 writing-pipeline.md / 不要 spawn subagent / 不要写 spec.md」，它撞到那些 reference 就会顺手做。

修法是给 prompt 加一份「禁止做 X」清单 + 一段「完成定义」（4 条可量化条件 + 一句"立即停止"）。改完跑 19 秒退出，从 5400 秒降到 19 秒。

但这个修法是给 1 个 agent 写的边界。3 个 agent 你要写 3 份「禁止做」清单，每份都得想清楚这个 agent 顺着你的 reference 链能走到哪些岔路。Yegge 的 320 个实例，意味着 320 份这种边界设计——而且每个新加的 agent 都可能因为某个共享文档的小改动让其他 319 个的边界一起漂移。这不是工程量的线性增长。

坑二：状态机判断别交给 LLM

agent 2 的 prompt 里有一句硬门控：「stage 不是 fetched 就直接结束」。

某天 agent 1 因为某个 hang 跑超过了 90 分钟，被 timeout 杀掉前没写 STATE。agent 2 启动看见 stage=idle，按规则"直接结束"——rc=0。

下游的 agent 3 启动看见 stage 还是 fetched 不是 drafted，同样"直接结束"——rc=0。

三段连环 sanity FAIL，但每一段日志都是「Turn X 完成」「rc=0」。报警链路触发了，但人看一眼以为是"按规则跳过"，没意识到这其实是"前序崩了"。

LLM agent 是不可靠的状态机执行者。 它会把"按规则跳过"和"做完了"输出成同一种格式，rc 同样是 0。你让它自己判前置态，就要接受偶尔的"假成功"。

这是个反模式：把控制流职责下放给一个语义层（LLM），控制流就再也回不到硬规则。能在编译期抓的别留给运行时，能在 wrapper 抓的别留给 prompt，能在 prompt 抓的别留给 LLM 自由发挥。LLM 是最后一道防线，不是第一道。

3 个 agent 之间的握手判断，必须用 wrapper（shell / 状态机框架）做硬校验。320 个实例之间的握手判断如果还放在 LLM 层——撑不到 320 就崩了。

坑三：时间不要假设

第三段是 cron 调度的：5:00 跑 agent 1，6:30 跑 agent 2，7:30 跑 agent 3。

设计假设：agent 1 跑完不超过 90 分钟。

破防点：agent 1 跑了 93 分钟。06:30 cron 触发 agent 2，但 agent 1 还没退出。agent 2 看 stage=idle 直接 NO_REPLY。下游连环失败。

修法是扔掉"三段独立 cron"，改成单入口 0 5 * * * 串行 chain（fetch && write && finish）。串行依赖天然把"前序就绪"约束硬编码进了控制流，不需要任何 wrapper 检查——前一段没退出后一段就不会启动。

但这个修法只对 3 个 agent 有用。Yegge 的 320 个实例如果还想用这套——一段串行跑 320 段，第一段慢就全卡，根本不可行。要支持 320 必须真的并行 + 真的有消息总线 + 真的有依赖图 + 真的有监督树。

那不是"调度智能体"，那是 Erlang OTP / Kubernetes operator 的活。

320 之前要先过的关

把这三个坑放一起看，是同一件事的三种症状：multi-agent 工程的瓶颈不在 LLM，在编排。

LLM 想做什么、能做什么、做得多好——那是模型的事，每个月都在变好。但要让 N 个 LLM 实例协同跑生产，要解决的是 50 年前 Erlang OTP / 30 年前 Kubernetes / 20 年前 message queue / 10 年前 Airflow 已经在解的那一类问题：

Yegge 说的"320 个 Claude Code 实例" 不是夸张——LLM 能力上完全做得到。但要支持 320，模型层不需要任何升级，缺的全是经典分布式系统该有的东西：调度器、消息总线、监督树、依赖图、超时熔断、降级策略、监控仪表。

3 个 agent 串行 chain 的工程量是 100 行 bash。30 个 agent 已经要小型 message bus + 状态机框架。300 个 agent 就是一套小型分布式调度系统，工程量比一个中型微服务架构只多不少。

中文圈这一周转 Yegge 那篇博客的 26 篇文章里，没有一篇在讨论这个。所有人都在讨论"程序员要变成什么"。但多 agent 编排不是程序员的身份焦虑话题，是分布式系统的实战话题。前者写在公众号上有阅读量，后者写在公众号上没人看——但只有后者真的能让 320 跑起来。

如果你想做 multi-agent 编排，不用先盯着 LLM 怎么进化。先把 Erlang/OTP 那本书翻出来，再去看一眼 Kubernetes operator 怎么写。然后你会发现，Yegge 描述的不是 2026 年底的工作日常，是分布式系统工程师过去二十年一直在做的事——只是现在 worker 从微服务换成了 LLM 实例。

工程问题没有捷径。3 之前的坑过不去，谈 320 是空中楼阁。

来源