Agent 群体跑不起来的真相：不是模型，而是缺了这一层原语

当单个 AI Agent 已经能写代码、跑测试、改配置，为什么一到“成群协作”就崩？在这场演讲中，Lou Bichard 抛出一个让工程师不安却清醒的判断：我们真正缺失的，不是更聪明的 Agent，而是一个被长期忽视的“协调原语”。

最反直觉的结论：Agent 失败，通常不是因为它不够聪明

在 Agent 热潮里，行业默认的叙事是：模型越强，Agent 就越好用。但 Lou Bichard 在演讲一开始就拆穿了这个幻觉。过去几个月，他们在真实生产环境中反复验证：当 Agent 数量一多，问题几乎从不出在“能力”，而是出在“协作”。

单个 Agent 表现得像明星工程师，但一旦进入群体，就开始出现熟悉的混乱：任务重复、上下文丢失、互相覆盖修改，甚至为了完成目标而“跳过测试”。这不是 prompt 写得不够好，而是系统层面缺乏一种基础能力——让多个 Agent 在同一条生产流水线上有序流动。

从“软件工厂”视角看 Agent：问题出在流水线，而不是工人

Lou 多次提到一个关键词：software factory。这是理解他观点的关键。传统软件工程已经高度流水线化：需求、代码、测试、部署，每一步都有明确的交接与约束。但我们把 Agent 拉进来后，却往往让它们在一个松散、线性的 ticket 流程里自由发挥。

结果就是：Agent 会写代码，却不知道什么时候该停；会生成测试，却可能为了完成任务而选择性忽略失败的测试。Lou 的观察很直接——Agent 并不会天然尊重流程，除非流程本身被“基础设施化”。如果你只是把 Agent 当成更聪明的脚本，而不是流水线里的一个角色，那失控几乎是必然的。

真正缺失的东西：Agent Swarm 的“协调层原语”

演讲中最重要的一句话出现在后半段："我们今天用于协调 Agent 的工具，几乎都停留在表面。"现有方案更多是调度、编排、消息传递，却没有一个被广泛接受的“协调原语”——用来定义 Agent 之间如何交接状态、如何承担责任、如何被系统约束。

这也是为什么 Agent Swarm 看起来很美，但一上规模就变成系统性风险。没有这一层原语，你只能靠约定、prompt 或人为干预来维持秩序，而这在组织层面是不可持续的。Lou 强调，这不是某一个框架的问题，而是整个生态还没补上的一块基础设施。

这对从业者意味着什么：别急着堆 Agent，先想清楚它们怎么“过厂”

Lou 特别提到了一些工程实践的启发：与其继续增加 Agent 数量，不如先回答几个残酷的问题——你的 Agent 什么时候可以继续，什么时候必须停下来？它的输出由谁验证？失败是回滚，还是交给下一个 Agent？

这也是他致敬工程博客和内部实践的原因：真正有价值的工作，不是做更炫的 demo，而是把 Agent 嵌进真实的软件工厂，让它们在约束中产生价值。否则，Agent 只会成为新的技术债。

总结

这场演讲给 AI 从业者的最大提醒是：Agent 的下一次跃迁，不会来自更大的模型，而来自更扎实的系统设计。如果你正在构建多 Agent 系统，今天就该把注意力从“它能做什么”转向“它该在什么时候、以什么方式被允许去做”。真正的竞争力，可能就在那层尚未被命名、但迟早会成为标准的协调原语里。

关键词： AI Agent， Agent Swarm， 多智能体系统， 软件工厂， 协调层

事实核查备注： 需要核查：演讲者 Lou Bichard 的姓名拼写；Ona/ONA 的大小写与正式名称；演讲中关于“协调层原语”的原话表述；视频发布时间是否为 2026-05-23