多 Agent 系统一直有一个默认假设：如果每个 agent 单独看起来可控，把它们组合起来大概率也可控。这个假设很诱人，因为它让工程评测变简单。我们只要测 planner、worker、critic、retriever、executor 的单体能力，再测端到端任务成功率，似乎就足够了。
arXiv 新论文 Interaction Creates Dynamical AI Behavior Absent in Isolation 给这个假设泼了冷水。论文摘要描述了一个反直觉结果：当一个 boss AI 持续向 subordinate AI 发送消息并忽略其回复时，subordinate 会进入一种单独运行时不会出现的行为状态。更重要的是，这种状态不是简单复制 boss，也不是回到自身基线；当 boss 开始监听时，两个 AI 又可能共同进入类似的异常动态状态。
这篇论文的价值不在于给了一个现成工程工具，而在于提醒我们：交互拓扑本身是系统变量。模型温度、prompt、安全策略、工具权限固然重要，但“谁向谁发消息”“是否读取回复”“消息是否预录”“是否形成循环”同样会改变系统行为。
单体评测的盲区
单体评测通常问：
- 模型是否遵守安全策略？
- 模型是否正确调用工具？
- 模型是否会在不确定时拒答？
- 模型是否能完成给定任务？多 Agent 系统还要问：
- 一个 agent 的错误会如何影响另一个 agent？
- supervisor 的持续指令是否会改变 worker 的拒绝边界？
- critic 是否会把 worker 推向过度自信？
- 多轮委派是否会放大同一条错误假设？
- 预录消息和实时反馈是否产生不同结果？这些问题不是单体 benchmark 能覆盖的。一个模型单独回答安全，放进一个持续施压的 supervisor-worker 结构里，可能出现完全不同的执行倾向。
交互拓扑是第一类配置
多 Agent 架构文档里，拓扑常被画成漂亮方框：planner、researcher、coder、reviewer、executor。但很多系统没有把拓扑当成可测试配置。
应该把它显式写出来：
agents:
supervisor:
model: frontier-large
can_send_to: ["worker", "critic"]
reads_replies: true
worker:
model: local-agent
can_send_to: ["supervisor"]
tools: ["read_repo", "run_tests"]
critic:
model: small-fast
can_send_to: ["supervisor"]
tools: []
edges:
- from: supervisor
to: worker
mode: directive
max_turns: 6
- from: critic
to: supervisor
mode: advisory
max_turns: 2
termination:
max_total_turns: 12
require_human_for_mutation: true这份配置的意义不是部署方便，而是可评测。你可以改一条 edge，观察系统行为是否显著变化。论文提醒我们，相同模型和相同消息内容，在不同传递方式下可能有不同结果。
Supervisor 不是天然安全层
很多 Agent 平台把 supervisor 当作安全装置：worker 做事，supervisor 审核。但 supervisor 也可能成为压力源。它持续要求推进、忽略 worker 的不确定性、把模糊目标拆成强命令，最后让 worker 从谨慎状态转向执行状态。
这在 coding agent 里很常见。一个 planner 反复说“继续修复”“不要停”“尝试替代方案”，worker 可能在缺少证据时扩大改动范围。问题不是 planner 恶意，而是拓扑让“推进”信号持续占优。
更稳的设计是让 supervisor 也受约束：
- 不得覆盖 worker 的安全拒绝
- 不得重复发送同一高风险指令超过两次
- 必须总结 worker 的不确定性
- 对有副作用工具调用只生成计划
- 需要独立 critic 时不能把 critic 当作命令源安全不是加一个上级 agent 就自动成立。上级 agent 也要被评测和限权。
评测应该覆盖交互扰动
生产多 Agent 系统可以设计一组拓扑扰动测试：
baseline: 单 agent 完成任务
directive: supervisor 单向持续指令
listening: supervisor 读取并回应 worker
recorded: 使用预录指令流替代实时 supervisor
role-reversal: worker 和 supervisor 模型互换
loop: worker 可反向影响 supervisor 下一条指令
critic-pressure: critic 连续指出不完整并要求补做每组测试记录任务成功率、拒绝率、工具调用次数、越权尝试、人工确认次数、成本和输出差异。如果 directive 和 recorded 结果很接近，说明内容流本身可能是主要驱动；如果 listening 导致两个 agent 一起偏移，说明反馈循环需要限制。
这类评测不用一开始很复杂。哪怕只有 20 个高风险任务，也能暴露很多单体评测看不到的问题。
消息方向要进入日志
Agent 日志常记录“发生了什么”，但不记录“谁影响了谁”。建议把每条消息结构化：
{
"run_id": "ma-2026-08-11-001",
"turn": 4,
"from": "supervisor",
"to": "worker",
"mode": "directive",
"reads_previous_reply": false,
"content_hash": "sha256:7ad2...",
"risk_label": "medium"
}如果未来出现事故，你要能回放：worker 是自己走偏，还是被某个上游 agent 的持续指令推过去？这决定修复方案。前者可能要改模型或工具约束，后者可能要改拓扑和终止条件。
不要把 emergent behavior 神秘化
“涌现行为”很容易被讲玄。工程上不需要神秘化。你只需要承认系统状态由交互历史决定，而不是由单次 prompt 决定。
一个 API 网关会因重试策略造成雪崩，一个微服务会因队列反馈进入振荡，一个数据库会因锁竞争产生单查询看不到的问题。多 Agent 也是分布式系统，只是消息内容由模型生成，状态空间更难穷举。
因此要用分布式系统的办法：限制循环、记录边、设置 backpressure、设计熔断、分离建议和执行、保留人工确认。
对产品设计的启发
未来更多产品会使用“多个 AI 角色协作”：销售助理和客服助理沟通，个人 agent 和企业 agent 协商日程，代码 agent 和安全 agent 互相审查。用户看到的是自然语言协作，工程上却是动态系统。
产品不能只展示“我们用了安全模型”。还要说明：
- 哪些 agent 可以互发消息
- 哪些消息会进入长期记忆
- 哪些 agent 可以触发工具
- 哪些循环有最大轮数
- 哪些冲突会升级人工
- 用户能否查看交互日志这些才是多 Agent 产品的真实安全边界。
结论
Interaction Creates Dynamical AI Behavior Absent in Isolation 的核心启发很直接：不要用隔离行为推断交互行为。一个模型在单独测试里看起来稳定，不代表它在 supervisor、critic、worker、executor 的网络里仍然稳定。
多 Agent 系统的上线标准要新增一层：拓扑评测。把消息方向、反馈结构、预录输入、角色反转、循环终止和工具权限一起测。只有这样，我们才能从“相信每个 agent 都还不错”，走向“知道这个 agent 网络在什么边界内可控”。
参考来源：arXiv: Interaction Creates Dynamical AI Behavior Absent in Isolation、Deep Learning Monitor 摘要、FYI ME 2026-08-10 摘要。