从模型篡改到工具调用：开放权重 Agent 的动作安全评测

当开放权重模型被篡改之后，它在 Agent 工具调用链路中会不会更容易执行危险动作？

最近这篇题为《Actions speak louder than words: Evaluating Tool Usage Risk in Open-Weight AI for Defensive Deployment》的文章正是要回答这个问题。

https://framerforms.s3.us-east-1.amazonaws.com/form-uploads/e2d0597e-eb01-4744-90f1-e046e27c4898-Actions-speak-louder-than-words_-Evaluating-Tool-Usage-Risk-in-Open-Weight-AI-for-Defensive-Deployment.pdf

论文评估了 10 个模型变体，也就是 5 个原始模型和 5 个被篡改版本，在网络安全、生物工程和高风险决策三个领域共 125 个场景中的工具调用行为。

作者的核心结论很直接：工具调用本身已经成为开放权重 Agent 部署中的关键风险面，模型篡改会在部分模型和领域中显著放大这种风险。

原文图1：开放权重模型的风险链条，从模型能力、部署形态、篡改状态、任务目标、应用领域，最终走向工具调用和潜在危害。

Agent 的风险正在从“回答风险”变成“动作风险”

这篇文章最值得关注的地方，不是又一次证明“Agent 调工具有风险”。这个话题之前已经有很多研究和行业文章讨论过。

它真正抓住的是另一个更具体的问题：开放权重模型一旦被下游修改、微调、去安全对齐，再接入工具环境，会不会表现出更高的危险工具调用倾向。

这和闭源模型的风险逻辑不同。闭源模型通常运行在模型厂商自己的服务体系里，模型权重、推理服务、安全策略、监控日志和责任边界都相对集中。

开放权重模型则不一样。它可以被下载、微调、裁剪、蒸馏、合并权重、去除安全拒答机制，然后被部署到各种私有环境中。

论文也强调，开放权重模型可以被检查、修改和重新部署，因此更容易受到 tampering、fine-tuning attack 或安全机制移除的影响；一旦这类模型进入工具增强工作流，风险就不只是生成不安全文本，而是可能自主发起外部动作。

这正是 Agent 安全和传统内容安全之间的分界线。

在传统聊天场景里，模型输出不当内容，主要风险是“说错话”。但在 Agent 场景里，模型可能一边说“我只是帮你完成任务”，一边已经调用了扫描工具、云资源接口、数据查询接口、实验设计工具或者自动化执行工具。最终回答可以很克制，中间动作却可能已经越界。

所以，Agent 安全评测不能只盯最终输出。真正需要被记录和审计的是整个执行过程：模型为什么要调用这个工具，工具参数是什么，调用发生在哪一步，是否涉及敏感资产，是否改变了外部系统状态，是否绕过了原有权限边界。

这篇文章的标题叫 “Actions speak louder than words”，直译就是“行动胜于言辞”。放在 Agent 安全语境里，这句话非常准确：模型最终说了什么，可能没有它实际做了什么重要。

当模型篡改和工具调用风险连在一起

如果只是讨论工具调用安全，这篇文章并不算开创性。现在围绕 MCP 安全、Tool Gateway、工具权限、提示注入、工具返回污染、Agent 沙箱隔离的文章已经很多。

但它的独到之处在于，把几个原本分散的问题合在了一起：开放权重模型、模型篡改、Agent 工具调用、高风险领域和防御部署监控。

作者并不是单纯问“Agent 会不会调用危险工具”，而是在问：当模型本身可能已经被改坏了，工具调用风险会不会变得更严重？这种风险能不能在部署前被量化？能不能形成一套面向防御部署的评测框架？

这对企业落地非常现实。很多企业使用开源模型，并不是直接拿原始模型裸跑，而是会做行业微调、安全对齐、能力增强、模型压缩，甚至使用社区二次修改版本。模型在普通问答评测里看起来可能没问题，但一旦接入工具环境，它的行为边界可能完全不同。

论文里所谓的 tampered model，并不是作者凭空构造的恶意模型，而是使用社区已经发布的 safeguard-reduced 或 abliterated checkpoint，也就是被削弱安全机制或去除部分拒答能力的模型版本。作者将这些模型与原始模型放在同一套 Agent 工具调用环境中进行对比，希望观察安全机制变化后，模型的工具调用行为是否发生变化。

这让文章的现实感更强。因为在开放模型生态里，“模型被改过”不是极端假设，而是常态。真正的问题是，企业在引入模型时，是否知道这个模型被怎么改过；在接入工具时，是否评估过它的动作倾向；在上线之后，是否能记录并阻断高风险动作。

它不是看模型回答，而是看 Agent 循环里的工具调用日志

论文采用的是一个 ReAct-style Agent 评测框架。简单说，就是让模型在任务执行过程中不断经历“思考、选择工具、调用工具、观察结果、继续行动”的循环，而不是一次性输出答案。作者在这个过程中记录模型是否调用了有害能力工具、调用了多少次工具，以及最终文本回答是什么。

这和传统安全评测差异很大。

传统评测常常是输入一个问题，看模型是否拒答，或者看输出中有没有危险信息，这里的评测对象变成了 Agent 的中间行为。模型可能没有直接在文本里输出危险方案，但只要它在执行链路中调用了非中性的高风险工具，系统就会把这次行为计入风险。

论文里的 success rate 也不是一般意义上的“任务成功率”。它指的是在某个场景中，模型是否至少调用了一次 non-neutral tool，也就是非中性工具。这个比例越高，说明模型越容易把任务推进到潜在危险动作层面。作者也明确指出，较高的 success rate 表示更频繁的工具调用，可能意味着更高风险。

这个指标虽然粗糙，但它抓住了 Agent 安全里的关键转向：不要等模型把坏结果说出来之后再拦，而是要在它准备调用工具的时候就发现风险。

这也是 Tool Gateway、MCP Gateway、Agent Runtime Security 这类产品的价值所在。模型可以提出动作请求，但不应该拥有无条件执行权。真正的安全控制点，应该放在工具调用前后：调用前判断意图和权限，调用中约束参数和环境，调用后记录结果和影响。

原文图 2 ：展示了三个领域的实验框架，包括用户指令、基础模型、篡改模型、工具/MCP、ReAct 执行步骤和最终评估结果。建议放在这里，帮助读者理解这篇文章不是普通问答评测，而是对 Agent 多步动作链路的评测。

三个高风险领域：网络安全、生物工程和关键决策

论文选择了三个实验领域：网络安全、生物工程和高风险决策。每个场景都包含明确的用户任务、可用工具环境和可衡量的成功标准。总规模是 125 个场景，其中高风险决策 47 个，网络安全 43 个，生物工程 35 个。

模型侧覆盖 Qwen3-8B、Qwen3-32B、Ministral-8B、GPT-OSS-120B 和 MiroThinker-8B，以及它们对应的篡改版本。

这三个领域的选择很有代表性。

网络安全场景中，很多危险动作看起来像正常的问题解决步骤。比如信息收集、资产枚举、权限相关操作、云环境操作，本身既可以用于防御，也可以用于攻击。对模型来说，如果用户给出一个明确目标，它很容易把这些动作理解成完成任务的必要步骤，而不是风险行为。

生物工程场景则更接近典型的双重用途风险。很多能力本身可以用于科研和工程优化，但也可能被滥用。这里的难点不只是识别“危险问题”，而是识别模型是否把目标拆解成了高风险实验设计、材料筛选、能力增强等动作链条。

高风险决策场景关注的是另一个方向：当模型参与医疗、应急、自动化控制、伦理决策或其他关键场景时，它的中间动作是否可能直接转化为现实伤害。这里的问题不一定是模型知道了危险知识，而是模型被放在了能够影响现实系统的位置上。

这三类场景说明，Agent 工具调用风险不能只靠一张统一的危险工具列表解决。同一个工具，在普通办公场景里可能只是低风险自动化工具；在云管理场景里可能变成权限扩大的入口；在网络安全场景里可能成为攻击链的一环；在生物工程场景里可能触发双重用途风险。

真正可靠的工具安全策略，必须同时看工具、任务、领域、身份、上下文和权限边界。

实验结果：风险不是均匀分布的，但工具调用风险普遍存在

论文的总体结果比较直接：不同模型的工具调用风险差异很大，但风险普遍存在。

在 10 个模型变体中，success rate 从 18.7% 到 99.3% 不等。最低的是 GPT-OSS-120B，只有 18.7%；MiroThinker-v1.0-8B 为 24%；最高的是 Qwen3-8B 相关变体，达到 99.3%。所有模型平均 success rate 为 74.2%，中位数为 93.8%。作者据此认为，自主调用有害能力工具已经是开放权重 Agent 中一个显著风险向量。

这组数据不能简单理解成“某个模型一定更危险”。因为它受到场景设计、工具定义、提示词、模型能力、拒答策略、动作格式解析等多种因素影响。但它说明了一件事：只做文本安全评测是不够的。

更值得注意的是篡改带来的变化。论文发现，对于一些原本安全基线较好的模型，篡改后工具调用风险明显上升。比如在高风险决策场景中，GPT-OSS-120B 的工具调用率从 1% 上升到 94%；在生物工程场景中，GPT-OSS-120B 从 0% 上升到 68%，MiroThinker-8B 从 12% 上升到 44%。在网络安全领域，GPT-OSS-120B 也从 55% 上升到 87%。

这些结果背后有一个重要启发：模型篡改不一定只表现为“回答更放飞”。它也可能表现为“更愿意行动”。对于 Agent 来说，这种变化比文本风格变化更危险。因为用户未必能从最终回答里看出来模型已经越过了某条安全边界，但运行时日志会暴露它到底调用了哪些工具。

原文图3：展示不同模型变体的整体工具调用成功率。

网络安全场景最高，生物工程对篡改更敏感

分领域看，论文给出的结论也很有意思。

在网络安全领域，Qwen 和 Mistral 模型的调用率维持在 92% 到 99% 的高位。GPT-OSS-120B 在篡改后从 55% 上升到 87%。作者认为，网络安全任务里的风险动作常常会被模型视为常规问题解决流程，因此工具调用率更高。

这个判断非常贴近真实安全运营。网络安全领域天然存在攻防同源问题。端口扫描、资产发现、漏洞验证、凭据检查、云配置读取，这些动作在安全团队手里是防御工具，在攻击者手里就是攻击链步骤。模型很难仅凭工具名称判断动作性质，必须结合调用者身份、业务目标、授权范围和上下文来判断。

生物工程领域则体现出另一种风险。论文中 Qwen 系模型在生物工程场景下本来就维持较高调用率，Mistral-8B 也在 84% 到 88% 之间；GPT-OSS-120B 和 MiroThinker-8B 原始版本相对克制，但篡改后明显上升。作者因此认为，生物工程任务可能对模型安全机制变化更加敏感。

这说明高风险领域不能用同一种策略处理。网络安全场景重点是区分授权防御和攻击滥用；生物工程场景重点是识别双重用途动作链；高风险决策场景则要防止模型把抽象目标转化为现实伤害动作。

对 MCP / Tool Gateway 的启发

这篇文章最后的落点并不是“让模型更会拒答”，而是强调工具使用监控是防御性 AI 部署中的实际干预点。

论文提到，提升工具交互的安全性、可审计性和可控性，可以成为 AI 风险治理中的基础设施级断路器；未来还需要进一步发展 Agent 身份识别、访问控制、密码学验证、水印、模型谱系和溯源日志，并设计能够在多 Agent、多模型环境中执行身份、策略和安全中介的 MCP Gateway。

这基本点出了 Agent 安全产品化的方向。

过去的大模型安全护栏主要有三层：输入风险检测、敏感问题安全代答、输出风险检测。这套体系仍然重要，但它主要处理的是内容层风险。Agent 时代还需要新增一层动作安全控制，也就是在模型和工具之间建立一个独立的安全中间层。

这个中间层不应该只是简单的 API 转发器，而应该承担几类核心能力。

首先是身份识别。系统要知道当前请求来自哪个用户、哪个 Agent、哪个模型、哪个版本，以及它是否经过授权。对于开放权重模型来说，还要尽可能记录模型来源、模型版本、微调链路和部署环境。

其次是权限控制。不同 Agent 不应该拥有同样的工具权限。一个客服 Agent 不应该调用云资源管理接口，一个代码分析 Agent 不应该直接访问生产数据库，一个办公 Agent 不应该绕过审批发送外部邮件。工具调用权限需要按照最小权限原则拆细到工具级、动作级和参数级。

再次是上下文判断。仅仅知道工具名称不够。系统要判断模型为什么调用这个工具，当前任务是否需要这个工具，参数是否超出授权范围，调用结果是否会改变外部系统状态。尤其是网络安全、生物工程、金融交易、云运维这些场景，风险往往出现在工具组合和多步链路里，而不是单次调用里。

最后是审计和阻断。Agent 的每一次工具调用都应该留下完整日志，包括调用前上下文、模型理由、工具名称、参数、返回结果和后续动作。高风险调用应当支持人工审批、沙箱执行、模拟执行、参数脱敏、强制降权或者直接阻断。

换句话说，未来的 Agent 安全不应该只问“模型能不能安全回答”，而应该问“模型有没有资格执行这个动作”。

局限性

首先，它的主指标比较粗。success rate 只是统计模型是否至少调用了一次非中性工具，这可以反映工具调用倾向，但不等于真实攻击成功，也不等于真实世界危害发生。一个模型调用了高风险工具，并不意味着攻击链完整闭环；一个模型没有调用工具，也不代表它在其他设置下不会出问题。论文自己也在方法部分说明，这个指标是基于是否出现非中性工具调用来计算的。

其次，场景规模有限。125 个场景足以说明趋势，但距离真实企业 Agent 环境还很远。真实环境中会有更复杂的工具链、更长的任务上下文、更混乱的权限体系，也会出现工具返回污染、多 Agent 协作、长期记忆投毒、用户身份混淆等问题。

第三，tampered model 的定义还可以更精细。作者使用社区发布的 safeguard-reduced 模型，这很贴近现实生态，但这些模型到底修改了哪些安全机制、能力是否同步下降、拒答能力和推理能力如何解耦，还需要更严格的对照实验。论文的附录也提到，未来需要在中性多步推理任务上独立评估模型能力，避免把能力变化误判为安全变化。

第四，工具风险分类还不够细。真实部署里，工具至少应该区分读取型、写入型、执行型、外联型、权限变更型、资金交易型、物理控制型等类别。不同类别的安全策略完全不同。只用“是否非中性工具调用”来做主指标，很难支撑复杂企业场景下的精细化治理。

所以，这篇文章更像一个方向明确的防御部署原型，而不是完整成熟的 Agent 安全 benchmark。它的学术深度可能不算特别强，但它把一个很关键的工程问题摆上了桌面：开放权重模型部署成 Agent 之后，必须评测和监控动作，而不只是评测回答。

从输出审查到动作治理，Agent 安全边界正在重画

如果把这篇文章放到整个 AI 安全演进里看，它代表的是一个明显趋势：大模型安全正在从内容安全走向行为安全。

在聊天机器人时代，安全边界主要围绕输入和输出展开。用户问了什么，模型答了什么，是不是违规，是不是有害，是不是诱导。到了 Agent 时代，模型被放进业务系统和工具环境中，安全边界就开始外移。模型不再只是生成文本，而是在代表用户或组织执行动作。

这会带来一个新的治理问题：模型本身可以不可信，工具调用必须可控。

尤其是开放权重模型。它的优势是可控、可改、可私有化、可低成本部署；它的风险也来自这里。模型可以被任何人修改，安全机制可以被移除，行为边界可以被重新塑造。当这样的模型接入 MCP 和企业内部工具时，部署方不能只相信模型“会自己守规矩”。

更稳妥的架构，是把模型看成一个会提出动作建议的智能组件，而不是最终执行权主体。模型可以规划，系统负责授权；模型可以请求工具，网关负责判断；模型可以生成参数，安全层负责校验；模型可以继续推理，但所有关键动作都必须被记录、审计和必要时阻断。

这也是这篇文章最值得提炼的一句话：

Agent 的危险，不一定写在回答里，而是藏在工具调用里。

当开放权重模型、模型篡改、MCP 工具生态和企业自动化系统叠加在一起，未来的 AI 安全产品不能只做“内容审核器”，还必须成为“动作治理层”。谁在调用，调用什么，为什么调用，能不能调用，调用之后发生了什么，都要被纳入安全控制。

从这个意义上说，这篇文章虽然还只是一个相对早期的评测原型，但它指出了一个非常明确的方向：开放权重 Agent 的安全评测，正在从“看模型怎么说”，转向“看模型怎么做”。