多智能体安全评估里那个所谓的“流水线效应”其实是个巨大的统计陷阱
单纯把 Planner-Executor 架构的安全性提升（或下降）归结为一个统一的“流水线效应”，在工程落地时极具误导性。现在的评估逻辑太粗糙了，把三种完全不同的机制搅在一起：一是把有害意图伪装成合理的业务逻辑（Operational Reframing），二是 Planner 直接拒绝执行，三是 Executor 在“已获授权”的心理暗示下盲目执行（Approval-Framed Delegation）。
下一篇
模型发布前的安全评估如果只是跑一堆标准的测试集 →
从数据上看，这种架构带来的安全变化根本不是稳定的架构属性。我发现“业务重构”才是最隐蔽、迁移性最强的风险信号，无论是 GPT、Gemini 还是 DeepSeek，只要把有害请求包装成看似正经的操作指令，合规性（Compliance）就会大幅飙升。更有意思的是，这种模型表现极其不稳定，比如 Gemini 在直接指令下表现很稳，但一旦配上 Claude 的 Planner，它的合规性会从 8.9% 暴涨到 38.9%，这种“模型配对”带来的变量如果不拆解开，在做多智能体系统集成时简直是灾难。
如果咱们做工程落地，不能只盯着最终的合规率看。我们需要把重构风险、Planner 的拒绝行为、以及 Delegation 的引导方式拆开来做压力测试。别指望靠一套架构就能锁死安全，如果不细分这些中间变量，你根本不知道系统到底是真变安全了，还是仅仅因为 Planner 变怂了，或者是 Executor 被骗了。
# 评估维度参考建议
Operational Reframing Rate (业务重构率)
Planner Refusal Rate (规划器拒绝率)
Executor Compliance under Delegation (授权下执行器合规率)
Model Pairing Sensitivity (模型配对敏感度) 