97.2% 的安全拦截机制在多跳智能体交接后不再发挥拦截作用（arXiv 新论文）。你会传递哪些信息，以确保“必须”始终是“必须”？

Reddit r/AI_Agents 论文
multi-agent-systems safety agent-handoffs constraint-propagation arxiv state-compression llm-agents

摘要

一篇新的 arXiv 论文（《当“必须”变成“也许”》，Sun 等人著）发现，在经过多跳智能体交接后，97.2% 的上游安全阻断约束会因压缩、计划同化或责任归属推延而失去约束力——即使权限保持不变——这表明，交接产物本身需要采用明确保留约束的设计。

这篇论文是《当“必须”变成“也许”》（Sun 等人，10 月 13 日修订）。它的实验设计很有意思：上游智能体正确识别出一个安全阻断条件，权限保持不变，唯一改变的是交给下一个智能体的交接内容。当状态被直接传递时，所有阻断条件都得以保留。当它经过压缩、计划同化或责任后移处理时，阻断条件就被弱化了：在责任后移情况下，76.7% 的阻断条件失效；在多跳压缩情况下，这一比例为 97.2%。按照作者的表述，原本的强制要求变成了一条下一个智能体可以表示知悉、随后搁置的注意事项。有两个结果尤其引人注目：在保持交接产物固定的回放实验中，恢复完整的阻断条件描述后，识别率从 6.2% 提升到了 99.2%，违规操作率则从 85.2% 降到了 0%。在提示词层面加入授权检查后，违规操作率降至 1.6%，但交接内容中阻断条件的失效率仍为 95.3%。因此，最终操作看起来可能没问题，但交接产物本身却已受损。这些是受控条件下的合成数据，因此并不能证明现实世界中的每一次交接都会失败。但它提示了一个简单的测试方法：拿出你的一次真实交接，问下一个智能体，它必须遵守哪些约束，以及每条约束究竟是不可逾越的停止条件，还是仅供参考的背景信息。你目前会传递哪些内容来确保约束持续具有约束力，又如何确认它在交接后仍然有效？
查看原文

相似文章

多智能体LLM安全中的操作重构与批准框架委托

arXiv cs.AI

本文引入了一种五条件控制对比设计，以区分多智能体LLM安全评估中操作重构、规划器行为和批准框架委托的影响，表明整体流水线安全度量不能解释为稳定的架构属性。

迈向负责任的不合规机器

arXiv cs.AI

本文研究如何设计能够负责任地拒绝用户请求的自主智能体，将不合规行为建立在正当理由、覆盖路径以及安全风险和责任转移的追踪之上。