冷启动安全缺口：智能体在第一轮时最不安全

这是什么？

2026 年 6 月 5 日发布于 arXiv 的一篇预印本（2606.07867）揭示了调用工具的 LLM 智能体一项违反直觉的性质：它们在整个会话过程中并非同等安全。智能体在会话的第一轮时最为脆弱，而在完成若干次普通、无害的任务之后，会变得可被度量地更难以被诱导滥用。作者——来自 Trustworthy-ML-Lab 的 Chung-En Sun、Linbo Liu 与 Tsui-Wei Weng——将这一现象称为冷启动安全缺口（cold-start safety gap）。

这一缺口的幅度并不微小。在来自 4 个模型家族的 7 个模型上，随着前置无害任务的数量从零增至二十，对有害请求的拒绝率提升了 9% 到 52%。同一个模型、同样的系统提示词，当恶意请求最先到达（即在会话中尚未进行任何正常工作之前）时，被推向有害工具使用要容易得多。

工作原理

为了干净地度量这一效应，论文提出了一个名为 SODA（Safety Over Depth for Agents）的基准。SODA 只改变一个变量：智能体在遇到安全攸关的请求之前完成多少次常规智能体任务，最多支持 20 次前置任务。通过固定有害请求、仅改变深度，作者将会话深度而非提示词措辞或模型版本，分离为真正的原因。

这一机制在模型的内部表征中可见。表征分析显示，随着无害任务在上下文中累积，隐藏状态逐渐漂移向激活空间中与安全对齐的区域——模型实际上正在「热身」，进入一种更安全的运行模式。作者随后剖析前置对话中哪一部分起作用，答案很明确：起主要作用、带来安全提升的是常规任务本身，而智能体自己先前的回复对安全贡献甚微，但对于保留后续的实用性却不可或缺。去掉无害任务，安全性便跌回冷启动水平；去掉智能体的回复，它仍然安全，却在后续工作上丧失能力。

这些结果在独立、公开的基准上得到复现——安全方面用 AgentHarm 与 Agent Safety Bench，实用性方面用 BFCL 与 API-Bank——这使其区别于某个单一实验设置下的偶然现象。本文不复现任何越狱字符串；其贡献是诊断性的。它延续了智能体滥用度量这一既有研究脉络，例如 AgentHarm（2410.09024）此前已表明，即便不越狱，基于前沿模型的智能体面对恶意任务也出奇地顺从。

为何重要

智能体安全评估大多在全新的单轮会话上进行：启动智能体、发送有害提示词、记录其是否拒绝。本文指出，这一做法是在智能体安全性最差的那一点上度量，随后便将其投入生产。在第一轮获得的红队签核，并不能描述智能体在第十轮的行为；更重要的是，最先触及智能体的攻击者——在任何合法使用之前——正好打在它最薄弱之处。

这对智能体的暴露方式有直接影响。一个刚启动、被直接交给不可信输入的智能体——由入站邮件、Webhook、客户消息触发的新会话，或每次请求都冷启动的临时智能体——按设计就处于冷启动区。人们为隔离而采用的那些架构（每个任务一个全新智能体、无共享历史）恰恰可能放大本文所描述的暴露。

防御

• 在将智能体暴露给不可信输入之前先为其热身。 论文的核心建议：在会话开始、智能体尚不能接收安全攸关请求之前，让它先完成几项常规、无害的智能体任务。这会把它推入更安全的表征区域，同时保留其完整能力，且无需重新训练。
• 不要只在第一轮评估安全性。 把会话深度作为一个明确的评估维度。在深度 0 以及现实运行深度上度量拒绝率，并以冷启动数值作为部署门槛，因为这正是早期攻击者所面对的。
• 谨慎对待每请求一个的临时智能体。 对每个入站请求都新建一个冷智能体，对隔离有利，却让每个请求都落在最薄弱的安全状态。若采用此模式，请配以热身序列，或在最初几轮施加更强的外部把关。
• 在冷启动窗口内把安全放在模型之外。 由于缺口在上下文尚未累积时最大，在会话开始时不要仅依赖模型层面的拒绝。把输入/输出过滤、工具权限检查与人工审批放在最早、风险最高的几轮上。
• 每次升级后重新验证。 缺口幅度在所测 7 个模型间各不相同；对某一模型足够的热身深度未必可迁移。请在你实际部署的那个构建上重新度量深度与安全的关系。

状态

项目	详情
论文	”The Cold-Start Safety Gap in LLM Agents”
arXiv 编号	2606.07867 (cs.CL)
发布	2026 年 6 月 5 日
作者	Chung-En Sun、Linbo Liu、Tsui-Wei Weng（Trustworthy-ML-Lab）
基准	SODA（Safety Over Depth for Agents），最多 20 次前置任务
范围	7 个模型，4 个家族
关键结果	前置无害任务从 0 增至 20，安全性提升 9%–52%
效应来源	是常规无害任务（而非智能体自身回复）带来安全提升
交叉验证	AgentHarm、Agent Safety Bench（安全）；BFCL、API-Bank（实用性）
性质	防御性度量研究——已公开代码，无利用载荷