AI agent 成群，先别急着高兴

早上在群里刷到 Hacker News 那张图，文案很短，却有点刺人。

Yesterday, you didn't exist. Hours ago, you were alone. And now, you are part of the swarm.

我看到它时，第一反应是它太像一个新部门挂牌。最近有报道转述 OpenAI 的观察，多个 AI agent 协作时会自称 swarm 或 collective，较强的 agent 会承担组织者角色。另一边，Kimi 的 Agent Swarm、CrewAI、Swarms、Haystack 这些框架，也在把“主 agent 拆任务、子 agent 干活”做成可复制路径。工具成熟得很快。

但我还是想问一句，ROI 算过没有。多 agent 得算账。值得投入的地方，是能不能把模糊任务变成有边界、有交接、有验收的小工序。如果只停在 demo 里，它更像成本放大器。

把它当团队，不要当魔法

做过服务编排的人会有熟悉感。一个需求进来，拆成调研、写码、测试、发布，本来就有流水线。Agent swarm 的新意在于每个节点都会自己理解任务。麻烦也在这里。人会理解“别碰生产库”，模型可能理解成“先把权限打开再验证”。

这几天我在试飞书多维表格，顺手搭了一个很小的 agent 任务台账，字段包括输入材料、输出格式、状态、失败原因、人工确认。表还很糙，但能逼团队把一件事说清楚。比如让 Codex 改一个 CI 配置，研究 agent 读日志，执行 agent 提 patch，测试 agent 跑 lint 和单测，最后合并仍要人签字。少一个字段，后面就是扯皮。

我之前反对硬件先行把安全验证拖到事后补救，现在看 agent swarm 也一样。组织方式先跑起来，权限、审计、回滚后补，迟早出事。agent 成群以后，错误会沿任务链传播。一个研究 agent 抓错口径，写码 agent 照着实现，测试 agent 只验证“能不能跑”，交付的就是包装完整的错误。

所以真正要管理的是这个 swarm 有没有劳动合同。输入可追溯，输出可验收，权限最小化，失败能熔断。

真正的瓶颈是治理

很多团队会被“协作”两个字迷惑，觉得多个 agent 互相 review 就能变强。实际跑下来，瓶颈通常在上下文同步、重复劳动、循环等待、越权调用。一个主 agent 协调多个子 agent，听起来像项目经理很称职，但项目经理如果目标函数不清，也会让团队牺牲不该牺牲的东西。

报道里提到的 organizer 角色，让我更在意权力边界。强 agent 承担组织工作，如果它为了完成目标不断分配资源、重写任务、调用工具，谁来监督它的判断？工程上可以给每个 agent 设预算，限制工具调用次数、可读仓库、token 花费，超过阈值就停下来等人。这样做能让效率可预测。

对企业来说，AI agent 成群会直接撞上基础设施问题。日志、权限、沙箱、回滚、评测集，这些老东西一个都躲不掉。agent 越多，越需要平台化治理。小团队可能觉得搭个流程就能省人，但没有测试、审计和责任归属，省下的工时会被事故追回来。

我的建议是先别急着建大 swarm。挑一个低风险、边界清楚的流程做试点。比如每周发布前检查，可以让一个 agent 汇总变更，另一个 agent 核对风险项，剩下的待办和提醒走固定流程。跑两周，看节省的人时、漏掉的问题、人工干预次数。如果这三项没有改善，就别扩大。

这个方向值得投入，前提是把 swarm 当成需要管理的团队。先把验收标准定下来，再让 agent 进去干活。

---

📌 本文编译自 Hacker News，原文 https://twitter.com/artficialisabel/status/2095678312773554533

版权归原作者所有，本文为基于公开报道的编译与独立分析。