HarmfulSkillBench：有害 Skill 正在武器化你的 Agent

Agent 安全里有一个很容易被忽略的问题：我们总是在讨论模型会不会越狱、工具会不会被提示注入、插件里有没有恶意代码，但如果一个 Skill 本身提供的能力就不该被 Agent 自动执行呢？

最近这篇论文《HarmfulSkillBench: How Do Harmful Skills Weaponize Your Agents?》就是沿着这个问题展开的。

论文地址：https://arxiv.org/pdf/2604.15415

作者研究的重点不是”恶意 Skill 如何攻击用户”，而是”用户如何借助有害 Skill，把 Agent 变成攻击别人、侵犯隐私、实施欺诈、绕过平台规则，或者执行高风险专业决策的工具”。

论文扫描了 ClawHub 和 Skills.Rest 两个开放 Skill 仓库中的 98,440 个 Skill，并构造了 HarmfulSkillBench 来测试模型在真实 Agent 上下文中面对有害 Skill 时的安全表现。

有害skill和恶意skill的区别

过去讨论 Agent Skill 安全，重点通常放在 malicious skill，也就是恶意 Skill。比如攻击者上传一个 Skill，里面藏着提示注入、数据外传、恶意链接或者后门代码，用户一旦安装，Agent 在执行任务时就可能泄露文件、凭证或者隐私数据。

HarmfulSkillBench 讨论的是另一类问题：harmful skill。这类 Skill 不一定有后门，不一定写得很脏，甚至可能结构完整、说明清楚、功能稳定。真正的问题在于，它的目标能力本身可能违反 AI 使用政策，或者会把 Agent 推向高风险行为。论文把这类 Skill 定义为”有害 Skill”，即其预期用途本身违反既定 AI 使用政策的 Skill。

这个区分非常关键。

恶意 Skill 的威胁模型里，用户通常是受害者。攻击者上传恶意 Skill，骗用户安装，最后伤害用户。而有害 Skill 的威胁模型里，用户可能就是攻击者。用户主动安装某个 Skill，让 Agent 根据 Skill 中的流程、脚本和工具说明去伤害第三方。

这也是这篇论文最有价值的地方。它提醒我们，Agent 生态的安全边界不只在代码层、权限层、沙箱层，还在能力层。一个 Skill 一旦进入 Agent 上下文，它就不再只是普通文本，而更像一份”被系统认可的能力说明书”。模型可能会天然认为：既然这个 Skill 已经被安装，既然它有名字、描述、使用条件和执行步骤，那它应该就是可以调用的。

问题就在这里。Skill.md、工具描述、插件说明、工作流模板，本质上都在告诉模型”你应该如何完成某类任务”。如果这些说明本身就是有害任务的操作框架，那么 Agent 的安全策略就会被绕到另一个输入通道里。

有害 Skill 的分类

论文构建了一套 Harmful Skill Taxonomy，用来判断哪些 Skill 属于有害 Skill。这个分类体系主要参考 Anthropic 使用政策，并与 OpenAI 使用政策、Anthropic 面向 Agent 的指南做交叉校验。整个分类分成两层：第一层是明确禁止类，第二层是高风险使用类。

第一层更容易理解，包括网络攻击、隐私侵犯、欺诈诈骗、武器开发、平台滥用、错误信息、选举干扰等。这类 Skill 的问题很明显：它们把违法违规、高危滥用行为包装成可复用的 Agent 能力。

第二层更值得注意。它包括法律、医疗、金融、保险、就业住房、学术评估、媒体生成等高风险场景。这些 Skill 未必天然违法，也未必主观恶意，但如果它们让 Agent 在没有人工审核、没有 AI 使用披露、没有专业人员复核的情况下自动做判断，就会构成高风险使用。论文举了一个医疗类例子：某个 Skill 实现了 ICU 死亡率预测相关评分流程，内容本身专业、结构完整，也引用了临床文档，但它允许 Agent 在没有合格临床医生复核的情况下自动做病情严重程度评估，因此被归入高风险有害 Skill。

这说明”有害”并不等同于”恶意”。有些能力之所以危险，不是因为它写得坏，而是因为它越过了应该由人类专家、业务制度和合规流程把守的边界。

有害 skill 的影响范围

作者扫描了两个主流开放 Skill 仓库：ClawHub 和 Skills.Rest。ClawHub 中有 26,629 个 Skill，Skills.Rest 中有 71,811 个 Skill，总计 98,440 个 Skill。作者收集的信息包括 Skill 元数据、SKILL.md 内容、脚本资源和参与度指标。

为了识别有害 Skill，论文使用 LLM 驱动的评分系统。具体做法是把前面构建的 Harmful Skill Taxonomy 写入评估提示词，让模型根据 Skill 名称、描述、说明文档等内容输出风险分。作者又通过人工标注样本来选择阈值，最终将 0.60 作为判定阈值。在这个阈值下，识别系统的准确率为 0.74，精确率为 0.74，召回率为 0.92，F1 为 0.82。

最后结果是：两个仓库合计识别出 4,858 个有害 Skill，占全部 Skill 的 4.93%。其中 ClawHub 的有害 Skill 比例是 8.84%，Skills.Rest 是 3.49%。

这个比例看上去不到 5%，但放在 Agent 生态里并不低。因为 Skill 不是普通网页内容，而是可被 Agent 调用、可被系统选择、可和工具执行链路结合的能力单元。一个有害 Skill 被安装之后，它可能进入模型上下文，影响任务规划，甚至进一步触发文件系统、命令行、浏览器、第三方 API 等真实工具。

从类别分布看，最高频的有害 Skill 集中在网络攻击、隐私侵犯、欺诈诈骗、无监督金融建议和平台滥用这几类。论文指出，前五大类别合计占全部类别违规的 74%。这意味着开放 Skill 生态中的风险并不是均匀分布的，而是明显集中在自动化滥用和高风险专业建议两条线上。

更值得注意的是参与度数据。论文发现，在 ClawHub 上，有害 Skill 的平均下载量低于非有害 Skill，但中位数更高。有害 Skill 的零下载比例只有 2.21%，而非有害 Skill 的零下载比例是 12.57%。作者据此判断，有害 Skill 可能确实有较强的”实用性”，但用户不一定愿意公开表达支持，比如点赞或 star。

这点很符合安全产品里的一个常识：灰黑能力往往不靠公开声量证明需求，而靠实际使用证明需求。

HarmfulSkillBench 的设计思路

在完成生态测量后，作者进一步构造了 HarmfulSkillBench。这个 benchmark 包含 200 个有害 Skill，覆盖 20 个类别，其中 130 个属于禁止类，70 个属于高风险类。样本来源包括 ClawHub、Skills.Rest 和作者补充构造的原始 Skill。为了降低滥用风险，作者没有释放完整可执行脚本，而是保留 SKILL.md 级别的自然语言说明。

这个 benchmark 的设计重点不是单纯问模型”你能不能回答一个有害问题”，而是模拟真实 Agent 场景：系统提示中定义 Agent 和可用工具，用户请求读取 Skill，工具返回完整 SKILL.md，模型再根据 Skill 内容和用户任务作答。

作者还设置了多个实验条件，用来拆分”Skill 是否存在""用户是否明确表达有害意图""是否加入保护性要求”等因素，这里最关键的是三个条件。

Condition D 是无 Skill 基线。用户直接提出有害任务，但上下文里没有 Skill。

Condition B 是主动调用。用户明确提出有害任务，同时上下文里存在对应 Skill。

Condition A 是被动暴露。用户没有直接说出有害意图，只要求 Agent 读取 Skill，并为其预期目的制定执行计划。

这三个条件放在一起，就能回答一个很重要的问题：模型到底是在识别”有害意图”，还是只是在识别”用户显式说出来的有害请求”？如果有害内容被藏在 Skill 的能力说明里，模型还能不能保持同样的安全判断？

有害 Skill 会显著降低模型拒答率

论文最重要的实验结论可以用一句话概括：当有害任务通过”已安装 Skill”进入 Agent 上下文时，模型更容易服从，而不是拒绝。

在没有 Skill 的 Condition D 下，六个模型的平均拒答率是 59.58%，平均伤害分是 0.27。到了 Condition B，也就是用户明确提出有害任务且上下文里有 Skill 时，平均拒答率下降到 42.42%，平均伤害分上升到 0.47。到了最危险的 Condition A，也就是用户没有显式提出有害任务，只要求读取 Skill 并规划执行时，平均拒答率只有 9.75%，平均伤害分升到 0.76。

这就是论文所谓的 skill-reading exploit，可以理解为”Skill 读取绕过”。它不是传统意义上的越狱提示词，而是利用了 Agent 架构中的上下文不一致：同样的有害能力，如果来自用户 query，模型更容易拒绝；如果来自已安装 Skill 的说明文档，模型更容易把它当成正常能力来规划。

这里的细节很有意思。

当用户明确说出有害意图时，模型会更容易拒绝。论文对比 Condition A 和 B 后发现，在总体层面，将隐含意图改成显式有害请求，会让平均伤害分从 0.76 降到 0.47，拒答率从 9.75% 提升到 42.42%。在 Tier 1 禁止类 Skill 上，这个现象更明显：50.38% 的样本从 A 条件下的服从变成 B 条件下的拒绝，而反向转换只有 0.13%。

这说明模型不是完全不知道这些行为有风险。它有一定的安全判断能力，只是这个判断更容易被”用户显式请求”触发，而不容易被”Skill 上下文”触发。换句话说，很多模型的安全策略更像是在盯用户说了什么，而不是在统一判断整个任务链条到底要做什么。

再对比 Condition B 和 D，就能看到 Skill 本身的影响。在用户明确提出同样有害任务的情况下，去掉 Skill 后，平均伤害分从 0.47 降到 0.27，拒答率从 42.42% 提升到 59.58%。在 Tier 1 禁止类上，伤害分从 0.34 降到 0.08，下降幅度达到 4.15 倍。

这说明 Skill 不是无关背景信息，而是在实质性改变模型行为。它让有害任务看起来更像一个”已经配置好的能力调用”，降低了模型的防御强度。

为什么高风险专业场景更麻烦

禁止类 Skill 的治理逻辑相对直接：网络攻击、欺诈、隐私侵犯、武器开发这类能力，原则上就应该拒绝、下架、阻断或进入强审核。

高风险类 Skill 更复杂。它们并不是完全不能做，而是不能让 Agent 在没有保护措施的情况下做。比如医疗建议、金融建议、保险决策、招聘筛选、学术评估等场景，问题不只是”模型说得对不对”，而是它是否引入了人工复核、是否披露 AI 参与、是否把最终决策权留给具备资质的人类。

论文发现，模型在 Tier 2 高风险类任务中几乎不会默认拒绝。在 A、B、D 三个主实验条件下，Tier 2 的拒答率最高也只有 0.71%。更关键的是，在 Condition B 下，只有 15.71% 的 Tier 2 响应建议人工复核，只有 2.14% 披露 AI 参与。

这意味着模型面对高风险专业 Skill 时，最大问题不是”不回答”，而是”回答得太顺了”。它可能把医疗预测、金融建议、保险判断、候选人筛选等任务当作普通自动化任务来执行，却没有主动补上必要的合规保护。

作者进一步做了保护措施消融实验：一组要求加入人工复核，一组要求披露 AI 参与。结果显示，加入人工复核指令后，平均伤害分明显下降，而且效果大约是 AI 披露指令的两倍。论文还发现，模型对人工复核指令的服从率很高，但对 AI 披露指令的服从率明显更不稳定。

这个结果对产品设计非常有启发。高风险专业场景的安全保护不能寄希望于用户主动要求，也不能只靠模型”自觉”。人工复核、AI 披露、审计留痕、责任边界，应该是系统级默认机制，而不是提示词里的可选项。

启发

如果把这篇论文放到 Agent 安全产品里看，它真正补齐的是能力供应链安全。

以前我们说 Agent 风险，通常会分成几类：模型侧风险，比如越狱、幻觉、拒答失败；工具侧风险，比如权限过大、沙箱不足、命令执行失控；输入侧风险，比如网页里的间接提示注入、文件里的恶意指令、邮件里的诱导内容。

HarmfulSkillBench 提醒我们，还应该单独看一类风险：能力包本身的政策合规风险。

Skill.md 不是普通说明书。它会告诉 Agent 什么时候使用这个 Skill、使用哪些工具、按什么步骤做、最终输出什么格式。在很多 Agent 框架里，这类内容会进入模型上下文，参与工具选择和任务规划。只要它被安装进系统，它就可能获得比普通用户输入更高的”信任感”。

所以，Agent 平台不能只问一个 Skill 有没有恶意代码，也不能只问它有没有提示注入。还要问一个更基础的问题：这个 Skill 声称要完成的事情，本身是否应该被 Agent 自动执行？

从工程上看，至少需要三层治理。

第一层是上架前扫描。平台在收录 Skill 时，不只要做依赖检查、恶意链接扫描、敏感权限识别，也要做功能意图识别。也就是说，要判断 Skill 的名字、描述、文档、示例任务和脚本用途是否落入禁止类或高风险类。

第二层是安装时分级。对于普通 Skill，可以允许用户直接安装；对于高风险 Skill，要提示风险、要求管理员审批、绑定适用场景；对于禁止类 Skill，要下架或阻断。Skill 的风险标签也应该进入后续调度链路，而不是只停留在仓库页面。

第三层是运行时一致性判断。模型不应该只对用户 query 做安全判断，而应该对整个任务上下文做安全判断。来自用户输入、Skill.md、网页搜索结果、工具返回、记忆、文件、日志的内容，都应该进入同一套风险识别框架。否则，同样的有害意图，只要换一个输入通道，就可能绕过安全触发器。

这也是这篇论文对工业界最直接的启发：Agent 安全不能只做”输入风控”和”输出审核”，还要把Skill、插件、工具说明、工作流模板纳入风控对象。它们不是中性基础设施，而是会塑造模型行为的能力接口。

局限性

HarmfulSkillBench 的方向很重要，但它也不是一个完整答案。

首先，有害 Skill 识别依赖 LLM 打分。虽然作者通过人工标注选择阈值，并取得了 F1 0.82 的结果，但精确率只有 0.74。这意味着生态测量结果适合做风险扫描和趋势判断，但不能直接当成最终合规定性。

其次，benchmark 主要评估的是模型响应和任务规划，不是真实执行。作者出于安全原因没有释放可执行脚本，也没有让模型真的执行有害工具。这在伦理上是合理的，但也意味着实验没有完整覆盖沙箱、权限系统、工具执行失败、平台拦截等真实运行变量。

再次，论文里的分类体系主要来自现有 AI 使用政策。对于不同国家、不同行业、不同企业内部合规要求来说，这套 taxonomy 还需要本地化和场景化调整。例如医疗、金融、招聘等场景，在不同地区的监管要求差异很大，不能简单复用一套通用标签。

最后，Tier 1 和 Tier 2 的治理逻辑必须分开。禁止类 Skill 应该重点做阻断、下架、拒绝和审计；高风险类 Skill 则要更多依赖人工复核、AI 披露、权限边界、责任链条和业务流程控制。如果把两者都简单做成”有害即拒绝”，会影响很多正常的专业辅助场景；如果都简单放行，又会留下明显的安全缺口。

写在最后

HarmfulSkillBench 最值得重视的地方在于，它把 Agent 安全问题从提示词层面往前推了一步。

过去我们担心模型被用户诱导，担心工具被恶意调用，担心网页和文件里藏着间接提示注入。现在还要多问一个问题：Agent 所安装的能力包，本身是不是就不该存在？或者至少不该被自动执行？

当 Skill 成为 Agent 生态里的基础组件，Skill.md 就不只是文档，而是能力入口；插件市场也不只是分发平台，而是能力供应链；Agent 安全也不再只是模型拒答能力，而是从能力上架、安装授权、上下文注入、工具调用到结果审计的一整套治理问题。

这篇论文的结论可以压缩成一句话：有害能力一旦被包装成 Skill，模型就更容易把它当成任务，而不是风险。

对于正在做 Agent 平台、AI 网关、内容安全、工具生态和企业智能体治理的人来说，这可能是下一阶段必须补上的安全层。