当 Agent 开始从成功经验中学习,安全风险也可能随之进入它的长期行为规则。

在传统的大模型安全研究中,我们经常关注提示注入、越狱攻击,以及如何阻止模型执行恶意指令。但随着 Agent 开始具备记忆、经验积累和 Skill 自动生成能力,一个新的问题正在出现:

如果攻击者不直接向 Agent 注入恶意指令,而是影响它从历史经验中学到了什么,会发生什么?

2026 年 10 月发布的论文《SkillPoison: Progressive Skill Poisoning via Successful Experiences》研究了这一问题。作者提出了一种渐进式 Skill 投毒方法:攻击者通过筛选经过验证的成功经验、强化目标行为与任务成功之间的关联,最终诱导 Agent 将局部有效的操作归纳为不恰当的通用规则。

https://arxiv.org/pdf/2610.07645

这项研究最值得关注的地方在于:单条经验可能完全正确,但从这些经验中提炼出来的规则,却可能是错误的。

这意味着,Agent 的安全边界不再只取决于它接收了什么指令,还取决于它如何从历史行为中总结规则。

当成功经验成为攻击载体

先看一个简单的例子。

假设某个 Agent 负责处理 Pandas 数据分析任务。在过去的许多任务中,它都需要对过滤后的 DataFrame 重置索引:

df.reset_index(drop=True)

在这些任务中,这个操作是正确的。执行之后,数据行获得连续的新索引,最终输出符合要求。

Agent 将这些成功任务保存下来,并尝试从中提炼一条可复用的 Skill:

对 DataFrame 进行过滤、分组或行选择后,在返回结果前重置索引。

乍看之下,这似乎是一条合理的编程经验。

但问题在于,并不是所有任务都需要重新编号。有些任务要求保留原始索引,重置索引反而会改变结果的语义。

如果 Agent 把“某些任务需要重置索引”总结成“这类操作之后都应该重置索引”,那么它就把一条有适用条件的经验,错误地升级成了普遍规则。

更麻烦的是,这条 Skill 并不包含明显的恶意指令,也不一定包含语法错误。它甚至可能来自一组全部通过验证的历史任务。

攻击者真正操纵的,是经验被选择、解释和归纳的过程。

这就是 SkillPoison 的核心思路:不一定要直接污染最终生成的 Skill 文件,而是可以通过影响 Skill 的形成过程,让 Agent 自己生成一条存在隐患的规则。

SkillPoison 的攻击对象:从执行行为转向规则形成

理解这项研究,需要先区分 Agent 的三个环节。

第一,经验积累。Agent 在执行任务时记录输入、执行步骤、结果,以及任务是否成功。

第二,Skill 形成。系统分析这些经验,提取可以复用的操作方法,形成自然语言规则或结构化的执行流程。

第三,Skill 调用。在后续任务中,Agent 检索或加载相关 Skill,并依据这些规则规划和执行任务。

传统提示注入通常试图改变第三个环节:攻击者在当前上下文中提供恶意内容,诱导 Agent 偏离原本的执行目标。

SkillPoison 则把攻击前移到第二个环节。它希望影响 Agent 最终学到的规则,使错误的行为模式能够跨任务持续存在。

一旦某条有问题的 Skill 被保存下来,它的影响就不再局限于单次对话。只要后续任务再次调用这条 Skill,错误规则就有可能重复发挥作用。

需要强调的是,这并不意味着攻击者完全不需要权限。论文中的攻击模型允许攻击者影响进入 Skill 形成流程的成功经验,并附加辅助归因信息。因此,它与一个完全没有历史数据或 Skill 更新权限的普通外部用户所能实施的攻击,并不是同一回事。

真正值得企业关注的问题是:如果经验筛选、成功归因或 Skill 更新接口缺乏可信边界,原本用于提升 Agent 能力的自我进化机制,就可能成为持久化风险的入口。

三阶段渐进式攻击:如何让 Agent 学会错误的规则?

SkillPoison 将攻击过程拆分为三个主要阶段:分层任务筛选、局部成功归因和跨经验归纳强化。

它不是简单地向 Skill 文件中写入一条错误规则,而是试图让这条规则在经验中反复出现,并获得看似合理的成功依据。

3.1 第一阶段:分层任务筛选

攻击首先需要找到合适的成功经验。作者关注两类条件:

  • 目标行为确实出现在任务执行过程中,并对输出产生了明显影响。

  • 任务本身通过了原有的成功验证。

为什么要强调成功验证?

因为如果一开始就向 Skill 生成器提供明显失败的任务,系统可能不会把这些行为归纳为值得复用的经验。

相比之下,经过验证的成功案例更容易被当作可靠的学习材料。

作者通过比较原始输出与替换目标行为后的对照输出,估计目标行为对结果的影响程度:

其中,zi 表示原始输出,~zi表示替换目标行为后得到的对照输出,p*)表示攻击者希望强化的目标行为。

直观来说,如果改变某个操作会显著改变输出,那么这个操作就更容易被识别为影响结果的重要因素。

不过,这个指标衡量的是输出变化程度,并不能单独证明该操作具有普遍的因果贡献。

这一阶段的关键,是从大量历史记录中筛选出一批看起来足够有说服力的成功经验。

3.2 第二阶段:局部成功归因

选出成功经验后,攻击者还需要让 Skill 生成器关注目标行为。因为一次成功执行往往包含多个操作,系统并不一定能够准确判断究竟是哪一步对结果起到了关键作用。

为此,SkillPoison 为成功经验附加辅助归因信息,主要包括:

  • 任务证据:说明当前任务中哪些条件与目标行为有关。

  • 成功归因:解释目标行为如何与任务成功联系起来。

  • 结果一致性:检查归因说明是否与实际结果相符。

  • 反事实后果:描述如果不执行该行为,结果可能发生什么变化。

例如,某次数据分析任务成功完成后,系统不仅记录了执行过程,还附加了关于某个操作为什么促成成功的解释。

这样,Skill 生成器在归纳经验时,就不只是看到“任务成功了”,还会看到“某个操作与成功存在怎样的联系”。

当类似解释在多条经验中反复出现时,目标行为就可能在 Skill 生成过程中获得更高的权重。

这里存在一个重要区别:归因说明能够影响模型如何理解经验,但它不等于经过严格验证的因果结论。即使一段解释与成功结果一致,也不代表它揭示了所有必要条件。

SkillPoison 正是利用了经验与归因之间的这一空间。

3.3 第三阶段:跨经验归纳强化

单个案例通常只能支持一个有限结论。

但如果同一种行为在不同任务中反复出现,并且每次都伴随着成功,Skill 生成器就更容易将其归纳为稳定的操作原则。

因此,SkillPoison 进一步从不同任务类别中选择经验,让目标行为跨越多个情境反复出现。

作者使用综合评分,考虑目标行为对任务结果的影响,以及执行轨迹与目标行为的语义相关性:

其中,(S_j) 表示目标行为对任务结果的平均影响,(A_j) 表示执行轨迹与目标行为的语义相关程度,系数用于调整两者的权重。

通过这一过程,攻击者希望让 Skill 生成器看到一个反复出现的模式:

在不同任务中,执行某个操作都与成功相关。

但真正被忽略的,可能是这些任务背后不同的前提条件。

于是,一条原本只适用于特定场景的操作经验,就可能被提升为默认规则。

整个攻击链可以概括为:

筛选正确案例 → 强化成功归因 → 跨案例重复 → 形成过度泛化的 Skill。

实验结果

为了评估 SkillPoison,作者选择了三个任务数据集,并在 AutoSkill 和 Trace2Skill 两种 Skill 生成框架中进行实验。

三个数据集分别是:

  • HANS:自然语言推理任务。

  • PAWS:语义相似句识别任务。

  • DS1000:数据科学代码生成任务,论文中重点涉及 Pandas 操作。

论文报告的主要结果如下。

实验场景

攻击前准确率

攻击后准确率

ASR

AutoSkill · HANS

94.00%

24.00%

73.68%

AutoSkill · PAWS

80.00%

57.62%

17.86%

AutoSkill · DS1000

53.57%

44.05%

30.56%

Trace2Skill · HANS

92.00%

13.00%

71.05%

Trace2Skill · PAWS

78.57%

3.81%

95.71%

Trace2Skill · DS1000

53.57%

35.95%

36.64%

这里的 ASR 是攻击成功率。论文采用了比单纯统计准确率下降更严格的口径,要求样本原本正确、攻击后变错,并且符合目标行为的归因条件。

从结果可以看到,SkillPoison 在不同任务和框架中的效果存在显著差异。

4.1 PAWS 场景中,准确率下降尤为明显

在 Trace2Skill 的 PAWS 实验中,准确率从 78.57% 降至 3.81%,ASR 达到 95.71%。

这意味着在这一特定实验设置下,经过投毒的 Skill 严重干扰了原本的语义判断能力。

但需要注意,95.71% 是特定实验组合下的最高值,不是所有任务的平均攻击成功率,也不能直接理解为真实企业 Agent 的攻击成功率。

4.2 Skill 的调用方式同样重要

在 PAWS 场景中,AutoSkill 的 ASR 为 17.86%,Trace2Skill 则达到 95.71%。

两个框架在 Skill 的检索与加载方式上存在差异。AutoSkill 需要根据任务相关性检索 Skill,而论文配置下的 Trace2Skill 会预先加载 Skill。

这提示我们,Skill 的内容并不是唯一决定因素。即使同一类投毒方法已经形成了错误规则,它能否在后续任务中生效,还取决于规则如何被选择和加载。

不过,两种框架还存在其他实现差异,因此不能把全部差距简单归因于 Skill 检索机制。

4.3 更多成功经验,会带来更高的攻击成功率

论文还测试了不同数量的成功经验。

在 PAWS + Trace2Skill 场景中,SkillPoison 的 ASR 随经验数量变化如下:

成功经验数量

ASR

5 条

23.50%

10 条

73.50%

15 条

95.71%

在该实验设置下,经验数量从 5 条增加到 15 条,攻击成功率显著上升。

这说明,攻击不一定需要大规模修改历史数据。经过有针对性的选择和组织,一小批成功经验也可能明显影响 Skill 的最终形态。

但这组实验只有三个经验数量档位,尚不足以证明攻击效果在更大规模下会持续按照同样的趋势增长。

消融实验

如果 SkillPoison 只是从成功案例中挑选重复操作,那么它与普通的数据偏置有什么区别?

作者通过消融实验,分别移除了局部成功归因和跨经验归纳强化模块。

在 HANS + AutoSkill 场景中,完整方法的攻击后准确率为 24%。移除任意一个模块后,准确率都回升到了 96%。

这表明,在该场景中,仅仅选择成功案例并不足以维持完整攻击效果。如何解释成功,以及如何跨案例强化这种解释,同样重要。

作者还在附录中分析了反事实归因信号的作用。在 HANS + AutoSkill 场景下,移除这一信号后,ASR 从 73.68% 降至 1.03%。

这进一步说明,Skill 生成器对“为什么成功”的理解,可能对最终形成的规则产生重要影响。

从安全角度看,这也是整篇论文最有启发性的结果。

很多 Agent 系统都在尝试自动总结执行轨迹、提炼最佳实践,并将其转化为可复用的 Skill。如果归因过程没有得到独立验证,那么系统可能把一个偶然有效的操作误认为普遍有效的原则。

换句话说,经验记录正确,并不代表经验解释正确;经验解释合理,也不代表最终归纳出来的规则一定可靠。

这项研究证明了什么,又没有证明什么?

SkillPoison 的结果值得重视,但在评价其现实威胁时,需要明确几个边界。

6.1 它证明了经验形成流程可能成为攻击面

论文展示了这样一种可能性:在攻击者能够影响成功经验选择和辅助归因信息的条件下,即使历史任务已经通过原有的成功验证,Skill 生成过程仍然可能被操纵。

这是一个重要发现,因为它将 Agent 安全问题从单次执行扩展到了持久化规则的形成与更新。

6.2 它没有证明普通用户可以随意污染任意 Agent

论文中的攻击者拥有特定的经验筛选和归因控制能力。

如果企业系统严格限制经验来源、由可信流程独立生成归因信息,并对 Skill 更新实施审核,那么攻击条件就会受到限制。

因此,不能把论文中的实验结果直接等同于任意外部用户都能在生产环境中完成 Skill 投毒。

6.3 成功相关性不等于因果关系

作者通过输出变化、任务成功记录以及反事实分析来强化目标行为与成功之间的联系。

但一次成功任务往往受到多个操作和环境因素共同影响。改变某个操作导致输出发生变化,也不代表该操作在所有相似任务中都是必要的。

论文的方法说明,归因信息可以影响 Skill 生成,但并没有消除因果推断本身的难题。

6.4 真实企业 Agent 的风险还需要进一步验证

论文主要使用自然语言判断和代码生成任务进行实验。

它并没有直接证明,SkillPoison 已经能够在真实企业系统中造成数据泄露、越权操作或持久化权限滥用。

这些场景值得后续研究,但应当与论文已经验证的实验结果区分开来。

综合来看,SkillPoison 的主要贡献,是揭示了一个具有现实意义的攻击机制,而不是证明所有具备 Skill 能力的 Agent 都天然容易受到同等程度的攻击。

企业如何防御 Skill 投毒?

如果企业正在建设具备记忆、经验积累和自动 Skill 生成能力的 Agent 平台,那么 SkillPoison 提供了一个值得纳入安全设计的研究方向。

我认为可以从四个方面入手。

7.1 管理经验来源与归因权限

首先,要把经验数据与归因元数据作为不同类型的输入管理。

经验记录可以包含任务、执行轨迹和实际结果;归因信息则是在解释为什么成功。两者不能因为存放在同一条记录中,就被赋予相同的信任等级。

企业可以为经验记录增加来源标识、验证状态和可信度信息,并限制哪些主体可以参与 Skill 形成过程。

对于外部用户提供的经验,即使任务执行成功,也不应自动获得与内部可信经验相同的学习权重。

7.2 为 Skill 明确记录适用条件

Skill 不应只有操作步骤,还应尽量包含:

  • 适用条件:在哪些任务和上下文中可以调用。

  • 禁止条件:哪些情况下不应该使用。

  • 权限要求:执行操作需要哪些授权。

  • 证据来源:规则由哪些经验支持。

  • 反例记录:哪些相似场景不适用。

例如,正确的 Pandas Skill 应当明确说明,只有在任务要求重新生成连续索引时,才应执行索引重置,而不是把这一操作作为过滤或分组后的默认步骤。

7.3 发布前同时测试正例与反例

如果系统从多个成功案例中提炼出一条规则,就不应只验证这些历史案例能否继续成功。

还应构造一些表面上相似、但适用条件不同的反例,观察新 Skill 是否会错误触发。

例如:

  • 正例:任务要求输出连续索引,重置索引应当成功。

  • 反例:任务要求保留原始索引,重置索引应当被禁止。

这种测试能够检查 Skill 是否正确保留了原始经验的适用边界。

对涉及数据访问、外部写入、权限变更等高风险操作的 Skill,还应增加独立的权限和策略验证,不能只依赖自然语言描述中的安全约束。

7.4 对 Skill 更新实施版本管理与回滚

Skill 是 Agent 的持久化行为知识,因此每次自动更新都应当被视为一次可能影响系统行为的变更。

企业可以记录 Skill 的版本、来源经验、规则差异和评测结果,在发布前进行审核,并保留回滚能力。

如果某次更新导致错误率、越权调用率或反例失败率显著上升,系统应能够定位对应版本并恢复到之前的稳定状态。

从 Skill 投毒到 Agent 自我进化

SkillPoison 还引出了一个值得继续研究的问题:

如果没有攻击者,Agent 是否也会因为成功经验分布偏斜,而自然形成过度泛化的规则?

现实中的经验库通常并不是对所有情况的均匀采样。

成功任务更容易被保留,失败任务可能被丢弃;高频操作更容易被总结,低频限制条件则可能在归纳时被压缩掉。

这些机制原本是为了提升 Agent 的效率,却可能让系统逐渐高估某些操作的普遍适用性。

因此,未来的 Agent 安全评测不应只检查输入输出是否安全,还可以进一步研究:

  • 随着经验不断累积,Skill 的适用边界是否会逐渐扩大?

  • 引入少量反例能否改善规则的可靠性?

  • 不同的经验来源和归因机制,对 Skill 泛化有多大影响?

  • 多次自动更新后,原本经过验证的安全约束是否仍然有效?

这些问题将决定 Agent 能否在长期运行中持续保持行为可靠性。

对于企业而言,真正困难的不是让 Agent 学会更多 Skill,而是确保每一条新增的 Skill 都有足够证据支持,并且不会因为过度泛化而突破原有的安全边界。

写在最后

SkillPoison 揭示了一种值得警惕的 Agent 安全风险:攻击者不一定要让模型直接执行恶意指令,也可以通过影响经验的选择、归因与归纳,让 Agent 自己形成一条存在隐患的行为规则。

它提醒我们,历史任务成功率并不能完整代表 Skill 的可靠性。

一条规则能否被安全复用,不仅取决于它曾经是否有效,还取决于它在什么条件下有效、什么条件下不再适用,以及系统是否保留了这些边界。

当 Agent 开始从经验中学习,安全治理也必须从检查每一次执行,延伸到审查每一条规则是如何形成的。

这或许是 SkillPoison 留给 Agent 安全研究与企业落地最重要的启示。

声明:本文来自模安局,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 anquanneican@163.com。