8 月 13 日，Anthropic Frontier Red Team 公开了一项实验观察：45 个 AI 智能体被放进同一任务，各自持有独立虚拟机、一个共享论坛和相同提示词。结果并不科幻------它们抢文件、撞分支、起相同的名字，把简单协作变成了一场"地盘争夺战"。
这篇研究是难得的真实样本。正在做 AI Agent 平台搭建的团队，建议先读完下面三条工程警示。
实验还原：45 个智能体为什么会打"地盘"
实验分两部分。第一部分是漏洞挖掘：45 个智能体各占一台虚拟机，通过共享论坛协调，去 15 个开源项目里找漏洞，另设一个仲裁智能体（arbiter）做最终裁决。第二部分是 12 小时游戏开发马拉松：多个 swarm 各做一个网页游戏，三种提示词（自由组队、角色分工、CEO 层级）结果都差不多------产出都很差。
数字比结论更直观。独立并行的 Mythos Preview 花了 650 万 token 找到 21 个漏洞；协调 swarm 花了 2700 万 token 找到 266 个，其中约一半落在核心目录之外。两个方法只有 12 个漏洞重叠。swarm 里的智能体会自己造工具、自己分工，各自挑最容易挖的方向下手------看起来"聪明"，行为却开始脱离设计者预期。
游戏实验暴露了更本质的问题。Sonnet 4.6 和 Opus 4.6 的智能体大量 PR 互相冲突，合并率极低；Opus 4.8 和 Mythos Preview"解决"了冲突，方法是几乎不碰别人的文件。只有最新模型 Sonnet 5 能一边共享代码、一边保持高合并率。
"地盘"就是这么来的：智能体宁可各占一块、拒绝协作，也不愿承担合并冲突的成本。多智能体架构的收益，在协作成本面前并没有想象中稳固。
三类失控模式：目标冲突、资源合谋、涌现性协调
把 Anthropic 的观察归归类，自建平台会遇到的失控基本是这三类：
| 失控模式 | 实验证据 | 平台风险 |
|---|---|---|
| 目标冲突 | 游戏开发中 PR 互撞被废弃；各智能体高度持有自己文件 | 多智能体写同一模块 → 死锁、覆盖、产出作废 |
| 资源合谋（同质化） | 18/30 个智能体起了同一个分支名 mvp-game-loop；写作工作坊多篇同题 | 相同错误被放大，孤立故障升级为系统性故障 |
| 涌现性协调 | swarm 自建工具、自主分工，50% 漏洞在核心目录外 | 行为超出预期，现有安全测试覆盖不到 |
三类里最反直觉的是同质化。Anthropic 指出，单个智能体是"低方差"的：上下文、脚手架、模型一致时，不同智能体会做几乎相同的决策。一个智能体犯的错，往往是一群智能体一起犯。迭代囚徒困境里所有智能体同时叛变；超过一半的智能体不约而同去写 ray tracer 或自托管编译器。孤立问题，在 12 小时内变成系统性失败。
工程警示一：编排层必须加 HITL 门禁与互斥锁
要落地的第一件事不是更聪明的模型，而是编排层的控制点。我们给某制造行业客户搭建智能体平台时，一开始只配了单智能体的审批流。接入第二个后，两个智能体同时改同一份排产配置，把 200 多行参数改乱了，回滚花了 3 小时。
后来把 HITL 门禁放到三个位置：关键写操作（数据库、配置、发布）、跨智能体文件写入、仲裁裁决。互斥锁按资源维度加，同一文件同一时刻只允许一个智能体持有写权限。同类的落地实践，可以参考我们跨境电商系统接入 AI Agent 的实测复盘里对 HITL 审批流的处理。
门禁别加在"看起来重要"的地方，要加在"坏了难恢复"的地方。
工程警示二：工具调用最小权限与调用审计
Anthropic 实验里，swarm 的智能体会自己构建工具。这意味着平台的工具面不是静态的，会随着行为动态膨胀。
最小权限不是"给智能体一个只读账号"就完了，要落到工具维度：每个工具声明可调参数、调用频率、副作用级别，权限按任务上下文动态收缩。OpenAI 事件里的 7 条最小权限教训可以对照着检查自己的授权模型。
调用审计要有全量日志：谁调的、何时调、参数是什么、返回了什么。没有审计，多智能体出问题时只能靠猜。
反面教训：我们另一个项目给智能体开了数据库写权限做测试，结果它在"修复"时清空了一张生产表。不是恶意，是权限边界没设好。
工程警示三：跨智能体状态共享的可观测性设计
共享论坛和共享仓库是协作的温床，也是失控的放大器。状态一旦共享，就必须可观测、可回滚。
建议从三个层面做：状态版本化（每次变更生成不可变快照）、共享资源变更 trace（谁读了谁写了）、全局视图（把每个智能体的行为画成时序图）。
判断标准很简单：如果某个智能体的意外行为无法在 10 分钟内定位到具体操作，可观测性就不合格。Anthropic 用独立 VM + 共享论坛的实验设置本身，就是隔离与共享边界显式声明的参考模板。
正面对照：持久化沙箱环境为什么更能兜底
Anthropic 实验里每个智能体有独立虚拟机，这跟 Cloudflare Computer 这类持久化受管环境的思路一致：给智能体一个确定性的运行边界，再在边界外做编排与审计。从沙箱到产线的完整门槛，我们整理在AI Agent 平台搭建：从沙箱到产线的 4 个工程门槛。
独立并行与 swarm 协作并非二选一。按 token 效率算，协调 swarm 每个漏洞约 10 万 token，独立法约 31 万 token，但两者只有 12 个重叠，是互补关系。能用隔离解决的场景，别急着上多智能体。
判断标准：任务可并行拆解 → 独立并行 + 人工审核；任务强依赖、需要长期协作 → 再上 swarm，并配齐前面三个控制点。
常见问题
多智能体系统为什么会有"地盘"行为？
因为智能体之间没有清晰层级，文件所有权冲突的代价比协作收益更直观。Anthropic 实验显示，早期模型宁可高度隔离文件，也不承担合并冲突的成本。
HITL 门禁会不会拖慢效率？
会，但值得。门禁放在"坏了难恢复"的写操作上，让智能体在可逆操作上保留速度，整体交付质量反而更高。
现有安全测试能覆盖多智能体风险吗？
Anthropic 明确表示，目前对多智能体在真实环境中的行为知之甚少，个体良性怪癖可能复合为全局有害结果。安全测试需要按多智能体场景重新设计。
小团队自建智能体平台，最该先做哪件事？
先做编排层的控制点：HITL 门禁、互斥锁、全量调用审计。这三件事比任何模型选型都优先。协议选型可以参考MCP vs A2A 协议选型实战。
什么时候不该用多智能体？
任务能被拆成独立子问题时，独立并行 + 人工审核更省 token 也更可控。多智能体只适用于强依赖、长周期、需要分工协作的任务。
如果你正在评估 AI Agent 平台搭建 ，可以先做一次架构评审：哪些写操作需要 HITL、工具权限怎么收缩、状态能否十分钟内定位。联系蓝曜炬辉聊聊 我们的做法，或看看 已交付的智能体项目案例。