论文笔记：Agent 安全应该是”运行时契约”

arXiv: 2608.11274 2026年8月

一句话总结

通过对 NeurIPS、ICML、ICLR 三大顶会 2023—2025 年间 28,560 篇论文的系统分析，这篇论文揭示了一个严重失衡：训练阶段的对齐研究远远超过部署阶段的安全研究。论文提出核心观点——Agent 安全不应只是训练阶段的产物，而应被视为一种运行时契约（Runtime Contract）。

核心问题：训练对齐 ≠ 运行时安全

当前 Agent 正从”聊天助手”向”执行者”转变——它们开始操作退款、调配云资源、管理库存。学术界花了大量精力教 Agent”什么该做、什么不该做”，但一旦 Agent 真正上线运行，面对复杂的真实环境时，几乎没有系统性的安全保障机制。

这篇论文做了一次大规模的”体检”：

  • 样本：NeurIPS、ICML、ICLR 2023—2025 年间发表的 28,560 篇论文
  • 发现：训练阶段对齐论文数量远超部署阶段安全论文
  • 结论：安全研究存在严重的阶段性失衡

运行时契约：安全工程化的新方向

论文提出的”运行时契约”（Runtime Contract）是什么意思？

类比软件工程中的 API 规范：

  • API 有明确的输入输出规范
  • 调用方和提供方基于契约工作
  • 违反契约时可以被检测和阻止

对 Agent 的含义：

  • Agent 在运行时的每一步操作应该受到可验证、可执行的约束
  • 不仅仅是”训练时学到了什么不该做”
  • 而是”运行时能强制执行什么不能做”

这为 Agent 安全治理提供了一个工程化的方向，而不是依赖训练时的隐式对齐。

为什么重要

当前 Agent 落地的核心痛点：

场景 风险
操作退款 未经授权的资金流动
调配云资源 成本失控
管理库存 错误决策影响真实供应链

仅靠训练时的 RLHF 对齐已经不够了。运行时契约的思路让安全变得可操作、可审计、可强制执行——对整个行业有深远的指导意义。

局限与开放问题

  1. 契约的具体形式：运行时契约如何正式定义？用什么语言描述？
  2. 可执行性：如何确保契约被遵守？违反后如何处理？
  3. 性能开销：运行时安全检查对 Agent 延迟的影响
  4. 跨场景泛化：不同领域的契约如何标准化

结论：这篇论文最重要的贡献是提出了一个框架性问题——我们不能把安全全部押在训练阶段。当 Agent 开始真正”做事”而非”说话”时，运行时安全保障是不可替代的。Runtime Contract 的思路值得整个行业认真对待。