一个数字让我停下来想了很久：0.64。

这不是某个新模型的能力分数，而是工具调用合规率——当系统从单Agent扩展到多Agent协作时，这个数字从 0.85 一路跌到了 0.64。丢失的 21 个百分点去哪了？论文的核心追问就从这里开始。

问题的本质：单Agent安全不等于系统安全

做单Agent系统时，我们习惯把安全边界画在Agent内部：输入过滤、输出校验、工具调用前做一轮Policy Check。这套机制在单Agent场景下运行得相当好，毕竟参与方就一个，”信任域”边界清晰。

但多Agent舰队完全是另一回事。论文指出了三个核心暴露面：

  • 工具调用在Agent间交叉传递时，原始调用者的身份和意图被稀释——B Agent 调用了 A Agent 的工具，但 B 对那个工具的权限边界一无所知
  • 各Agent可能来自不同团队、不同信任等级，但共享同一套工具生态，谁来为越权调用负责？
  • Agent具备动态生成能力（调用未见过的工具、组合出新行为），传统的静态白名单根本跟不上

这不只是”安全策略没跟上”的问题，而是多Agent系统的架构性缺陷：安全边界和执行边界压根不在同一层。

OpenAgentFlow的核心洞察：把边界往外推一层

论文的核心贡献不是又一套Agent内嵌的Policy引擎，而是提出了一个更基本的架构问题：安全边界应该放在哪里？

答案是——放在Agent外部，放在Action-Commit边界上。

所谓 Action-Commit 边界，是一个统一的强制执行接口。当Agent发出一个动作（工具调用、数据访问、状态修改），这个动作必须经过Commit层才算生效。Commit层不看Agent内部逻辑，只看：这条动作是否在当前上下文的允许范围内？

这样做有一个关键好处：安全策略和Agent实现解耦了。不论你用的是哪个框架（LangChain、AutoGen、或者自研），只要经过Action-Commit边界，安全策略就能统一生效。

架构拆解

OpenAgentFlow的架构里有几个值得注意的设计：

AgentEvent流。整个系统的状态变化都以事件形式记录——不只是最终执行的工具调用，还包括意图、参数、上下文来源。这为事后审计和溯源提供了基础。

Policy Enforcement Point（PEP）。这是Action-Commit边界的执行机构。它不运行在Agent内部，而是作为独立组件存在。论文强调，PEP的位置很重要——必须在动作提交前拦截，而不是事后日志审计。

Provenance追踪在Agent外部。这是论文反复强调的一点：不要依赖Agent自己报告”我做了什么”，要独立追踪。Agent可能被prompt注入、可能被错误引导，但provenance记录是独立于Agent执行路径的。

数字说话

论文的评估分两块：

Controlled Suite（300 cases）：针对已知攻击模式构造的测试集，OpenAgentFlow达到 94.00% 准确率。这是在受控环境下对安全边界有效性的直接验证。

AgentDojo-Traj（1220 cases）：来自真实多Agent协作轨迹的评估集，覆盖更复杂的实际场景，准确率 97.62%。这个数字更值得关注——它说明在真实协作流里，Action-Commit边界没有成为瓶颈，反而因为把安全检查前置，减少了因越权导致的回退和重试。

而对比基线的那个 0.64 vs 0.85，本质上就是”没有统一边界”和”有统一边界”的差距。

对Agent系统架构师意味着什么

这篇论文最有价值的提醒可能是：不要把安全当作Agent的功能特性，而要当作系统的横切关注点。

当你规划一个多Agent系统时，OpenAgentFlow提出了几个值得内化的问题：

  • 工具调用的权限检查放在哪个层？是每个Agent自己做，还是有独立的一层？
  • Agent之间传递的上下文里，哪些信息是可信赖的，哪些需要重新验证？
  • 当一个Agent调用了另一个Agent持有的工具时，谁来为这次调用负责？

论文不打算给你一个能直接塞进生产系统的完整方案——它更像是一份概念框架和方向指引。但那个 0.85→0.64 的数字值得每个正在构建Agent系统的人记住：系统越复杂，边界越重要。

论文：Enabling System-Wide Safety Boundaries for Heterogeneous AI Agent Fleets，arXiv:2609.00015，2026-08-14（v2 2026-09-02），Dongsheng Chen et al.