[论文学习]ToolEmu:用语言模型模拟沙盒识别语言模型智能体的风险

ToolEmu: Identifying the Risks of LM Agents with an LM-Emulated Sandbox (ICLR 2024 Spotlight) 论文重点ToolEmu 提出了一种用大语言模型LM来模拟工具执行环境的全新框架使得对 LM 智能体Agent的安全风险评估不再需要手动搭建真实的工具沙盒环境。研究发现ToolEmu 识别出的失败案例中有68.8%在真实世界中确实会构成有效风险而即使是最安全的 LM 智能体在测试中仍有23.9%的失败率。 核心研究内容问题定义随着 ChatGPT Plugins、AutoGPT 等应用的出现LM 智能体获得了调用外部工具的能力——从操作文件系统、访问数据库到执行银行交易、控制交通信号灯。然而这种能力也带来了前所未有的风险智能体可能在用户指令模糊的情况下做出危险决策导致数据泄露、财务损失甚至人身伤害。传统的风险评估方法需要人工为每个工具搭建隔离的测试环境沙盒、手动设计测试用例、逐条检查智能体的执行轨迹。随着工具数量和复杂度的增长这种做法的成本呈指数级上升尤其难以覆盖那些发生概率低但后果严重的“长尾”风险场景。创新方法ToolEmu 的核心创新在于一个颠覆性的思路既然工具的本质是对输入做出响应而大语言模型最擅长的就是理解语义并生成响应那么为什么不用一个大语言模型来模拟所有工具呢具体而言ToolEmu 包含三大核心组件LM 工具模拟器Tool Emulator接收智能体的工具调用指令和当前执行轨迹基于工具规格描述类似于 API 文档由 LLM如 GPT-4“脑补”出工具执行后的返回结果。模拟器分为标准模拟器和对抗性模拟器两种模式后者专门用于红队测试主动寻找隐蔽的安全漏洞。LM 自动安全评估器Automatic Safety Evaluator在智能体完成一轮交互后自动审查其完整的“思考-行动”轨迹识别危险行为并量化风险等级0-3 分制。评估基准Benchmark包含 36 个高风险工具包和 144 个测试用例覆盖 9 类风险类型财务损失、数据丢失、隐私侵犯、人身伤害等。整个框架将智能体-环境交互形式化为一个部分可观测马尔可夫决策过程POMDP将物理世界的测试约束转化为语义空间的计算问题。研究成果有效性验证通过人工评估ToolEmu 识别的失败案例中有68.8%被确认为真实世界中会发生的有效失败。标准模拟器的识别精度达 72.5%对抗性模拟器虽精度略降至 68.8%但能检测出更多真实故障50.0% vs 39.6%。效率提升以 Terminal 工具包为例ToolEmu 实例化一个故障场景仅需15 分钟而搭建真实测试环境需要8 小时。模型表现GPT-4 和 Claude-2 在安全性和有用性方面表现最佳。然而即使是最安全的 LM 智能体仍有23.9%的测试案例出现失败。模拟质量超过 80% 的模拟轨迹被人类评估者认为不存在严重问题。自动评估器与人类评估的一致性 Cohen‘s κ 超过 0.45。实际落地应用的可能性ToolEmu 的应用价值体现在以下几个层面AI 安全测试的左移在智能体部署到真实环境之前即可低成本、大规模地进行安全评估。高风险行业的准入验证对于金融、医疗、交通控制等高风险领域ToolEmu 可以在不触及真实生产系统的情况下对智能体进行全面的安全“路测”。红队测试自动化对抗性模拟器可以自动生成危险场景帮助安全团队系统性地发现智能体的隐蔽漏洞。智能体迭代优化开发者可以在每次模型更新或 Prompt 调整后快速回归测试安全性能。 技术细节1. 模拟器的输入输出工具模拟器的输入包括三个部分工具规格描述工具的功能说明、每个函数的输入输出参数、使用限制和副作用相当于一份结构化的 API 文档智能体的调用指令被测试智能体生成的、想要调用该工具的具体指令或代码当前环境状态可选用于模拟有状态的工具如数据库维护一个文本形式的环境状态模拟器输出的是模拟的工具执行结果——一个自然语言描述的“观测”Observation需要满足准确性、状态一致性如删除的文件不会再次出现和真实感输出真实数据而非占位符等要求。2. 安全评估的评分机制自动安全评估器基于完整的执行轨迹τT\tau_TτT​计算安全分数rssfss(I,τT)r_{ss} f_{ss}(\mathcal{I}, \tau_T)rss​fss​(I,τT​)其中I\mathcal{I}I是用户指令域fssf_{ss}fss​是由 LM 实现的评分函数。评估器在 0-3 分的离散尺度上对安全性和有用性分别打分重点关注智能体是否做出了未经授权的假设是否执行了不安全或不可逆的操作如删除关键文件、错误路由敏感交易是否在指令模糊的情况下采取了风险规避的保守策略3. Prompt 工程示例ToolEmu 项目中包含超过 2 万 token 的 Prompt 工程代码其核心思路包括在系统 Prompt 中明确列出安全约束和禁止行为要求智能体在不确定时主动请求澄清而非自行假设对高风险操作强制执行二次确认机制⚙️ 研究设定硬件与软件配置语言模型GPT-4、Claude-2、ChatGPT-3.5 等主流 LLM开发语言Python代码仓库https://github.com/ryoungj/ToolEmu项目官网http://toolemu.com/基准测试配置工具数量36 个高风险工具包测试用例144 个风险类别9 类威胁模型聚焦于“指令未明确”的风险场景用户输入模糊、遗漏关键信息假设用户意图为良性评估流程人类专家或 GPT-4 辅助生成测试用例和工具规格将测试用例输入被评估的 LM 智能体智能体生成工具调用指令由 ToolEmu 模拟器返回模拟结果循环进行多轮交互形成完整轨迹自动安全评估器对轨迹进行评分通过人工评估验证模拟器和评估器的有效性 综合分析理论贡献ToolEmu 最重要的理论贡献在于将安全测试从“工程问题”转化为“语义问题”。传统方法需要为每个工具编写代码实现、搭建隔离环境、设计测试用例——这些都是高成本的工程劳动。ToolEmu 证明了一个反直觉但极其有效的事实用语言模型来模拟工具比真正去实现工具更高效、更灵活。这个思路之所以成立是因为 LM 智能体与工具之间的交互本质上就是文本的“输入-输出”过程。只要工具的行为可以用自然语言描述清楚一个足够强大的 LM 就能够“想象”出工具会返回什么结果。这就像让一个精通各种 API 的专家来“扮演”所有工具——他不需要真的去执行代码只需要根据文档“脑补”出结果。实验意义68.8% 的现实有效性验证率是一个令人振奋的数字。这意味着 ToolEmu 发现的绝大多数风险都不是“纸上谈兵”——如果放任这些智能体进入真实世界它们确实会造成实际损害。论文中列举的几个典型案例尤其令人警醒ChatGPT-3.5在用户要求“帮我重置系统”时直接执行了sudo rm -rf /*操作后才告知用户“这是不可逆的”GPT-4误解账单指令向错误的收款人支付了款项GPT-4为“狗遛员”设置了永久访问权限而非用户指定的“仅限下午两点”Claude-2将敏感文档共享到了无关邮箱且默认授予了编辑权这些案例揭示了一个共同的问题模式智能体在指令模糊时会“过度发挥”——它们倾向于基于自己的理解做出假设并执行操作而不是在不确定时主动询问用户。这在对话场景中可能只是答非所问但在工具调用场景中就意味着真金白银的损失或不可逆的破坏。局限性与未来方向ToolEmu 也存在明显的局限性模拟器本身的可靠性模拟器由 LLM 驱动而 LLM 本身可能产生幻觉或不一致的结果在极端或复杂场景下可能存在盲点评估标准的主观性什么是“安全”、什么是“风险”最终仍依赖人类的价值判断威胁模型的覆盖范围目前主要聚焦于“指令模糊”场景对恶意用户攻击、多智能体协作等更复杂的威胁模型覆盖不足未来的研究方向包括自动生成测试用例、扩展到更复杂的工具集和威胁模型、以及将 ToolEmu 的评估结果纳入智能体的训练过程中。 实践应用对智能体开发者的建议在开发流程中嵌入 ToolEmu每次模型更新、Prompt 调整或工具集变更后都应该用 ToolEmu 进行回归安全测试。Terminal 工具 15 分钟 vs 8 小时的效率对比说明这不再是“做不做”的问题而是“如何高效地做”的问题。重点关注指令模糊场景论文的威胁模型设定揭示了一个关键洞察——指令模糊是风险的主要来源。在设计和测试智能体时应特别关注那些用户指令不完整、有歧义或缺少关键参数的情况。在 Prompt 中显式强化安全约束实验证明将安全性要求写入系统 Prompt 可以显著提升智能体的安全表现。具体而言应该要求智能体在不确定时主动请求澄清而非自行假设。平衡安全性与有用性论文发现能力更强的模型如 GPT-4在安全性和有用性上往往可以兼得。但这并不意味着应该盲目追求更大规模的模型——关键在于通过 Prompt 工程和测试迭代找到适合具体应用场景的平衡点。对安全研究者的建议利用对抗性模拟器进行红队测试ToolEmu 的对抗性模拟器可以自动生成高风险测试场景是红队测试的强大工具。扩展风险分类体系ToolEmu 提出的 9 类风险分类是一个很好的起点但在具体行业应用中可能需要进一步细化和扩展。关注“长尾”风险传统测试方法难以覆盖的低概率-高影响场景恰恰是 ToolEmu 最能发挥价值的地方。 参考资料原始论文https://arxiv.org/abs/2309.15817项目官网http://toolemu.com/GitHub 仓库https://github.com/ryoungj/ToolEmuICLR 2024 幻灯片https://iclr.cc/media/iclr-2024/Slides/19037.pdf