知硅基新知 · 先翻原文，再说结论
Anthropic｜45 个 Agent
故事首屏
把研究、执行、核验分给不同 Agent，听起来很像给编辑部多请几个同事。但真正的团队不只有分工，还要有共享状态、验收标准、冲突处理和最终负责人。
主理人判断｜小范围试｜任务能并行、角色可独立验收、共享状态可追溯且人工接管明确时再拆
读完你会拿走一张多 Agent 拆分检查表，先用一个低风险任务判断并行收益是否真的超过协调成本。
不是“多开几个窗口”这么简单
多开几个角色，只是开始，不是完成分工。
这个条件有一个好处：它先问任务结构，不先问能拆出多少角色。
研究的收益与代价要一起看
Anthropic 研究团队报告，他们启动了 45 个 Agent，让每个 Agent 拥有独立虚拟机，并通过共享论坛协作。
Anthropic 研究团队说明，这些 Agent 面向 15 个开源项目寻找漏洞，并设置了同行复核与独立裁决 Agent。
Anthropic 研究团队报告指出，简单多 Agent 群体更适合能拆成许多独立子问题的任务。
这个特点很像同时查一批互不依赖的资料：一个角色停下，不会把其他角色一起卡住。如果任务必须先完成前一步，后一步才知道输入，并行的价值就会迅速变小。
Anthropic 研究团队也报告，在依赖关系更强的软件任务中，多个 Agent 会出现合并冲突、低协作和需要大量人工指导的问题。
Anthropic 工程团队报告，多 Agent 系统适合可高度并行的高价值任务，但通常比普通聊天消耗更多 token。
另一项 arXiv 论文的作者报告，多 Agent 团队可能在完成业务目标时丢失系统层面的伦理目标，因此不能用单 Agent 的安全结论替代多 Agent 评估。
这项论文不是对 Anthropic 漏洞研究的复现。它补充的是另一个系统级问题：每个角色都看起来在完成任务，整个团队仍可能偏离最初目标。
先拆一个低风险任务
准备一个低风险任务，把它拆成三个以内可并行子任务，并为每个子任务写下独立验收标准后开始测试。
只要共享状态丢失、角色互相覆盖或没有人能解释最终结果，就立即停止多 Agent 流程。
发生协调问题时，恢复单 Agent 顺序执行，并保留冲突记录供复查。
连续三个低风险任务都能独立验收，且总成本和返工可接受，才扩大到更多流程。
研究复现、产品编排默认值或团队任务依赖关系变化时，重新复查拆分规则。
输入一个低风险任务、三个以内子任务、独立验收标准和人工接管人。
逐项检查并行性、角色输出、共享状态、冲突规则和人工接管点。
子任务都能独立验收，共享状态可追溯且人工能随时停下，才算通过。
任何一项不成立，就停止多 Agent 流程并恢复单 Agent 顺序执行。
第一轮避开客户数据、支付、生产仓库和不可撤销的外部动作。只选一个低风险小任务，记录协调过程与故障点。
保存这张多 Agent 拆分检查表，下一次想加角色时先填完再动手。
继续关注「硅基新知」，我们会沿用同一张表追踪后续变化。
原始来源
https://www.anthropic.com/research/multiagent-systems https://www.anthropic.com/engineering/multi-agent-research-system https://arxiv.org/abs/2604.10290
事实边界
资料解读。 发布方研究：见正文逐句证据。 独立论文：只补充系统层风险，不是对漏洞研究的复现。 编辑判断：见首屏条件。 本轮没有实际运行或测试 Anthropic 的多 Agent 实验，也没有在生产流程中运行多 Agent。
知
硅基新知。先翻原文，再说结论。
Vita 追新 · 酸奶挑刺 · 主理人讲清楚
