当经验变成指令：自进化Agent的轨迹投毒攻击

Agent 正在从一个“按照规则执行任务的工具”，逐渐变成一个“能够总结经验、修改规则、持续进化的系统”。

例如，一个 Excel Agent 连续执行几百次任务后，可能发现某种操作方式更加稳定，于是自动把它总结成新的 Skill；一个 Coding Agent 在多次失败后发现某种调试流程更加有效，也可以把它沉淀进自己的开发规范。下一次面对类似任务时，Agent 不再需要重新探索，而是直接复用过去积累的经验。

这正是 Self-Evolving Agent，也就是自进化 Agent 最吸引人的地方。但一个新的安全问题也随之出现：如果 Agent 学到的“经验”本身，就是攻击者精心伪造的呢？

2026 年 8 月 6 日，来自蚂蚁集团、浙江大学、清华大学等机构的研究团队发布论文《When Experience Becomes Instruction: Trajectory Poisoning in Self-Evolving Agent Skill Systems》，提出了一种针对自进化 Skill 系统的新攻击 PoisonedEvolution。

https://arxiv.org/pdf/2608.05563

研究发现，攻击者不需要直接篡改 Skill，不需要控制负责进化的 Evolver，甚至不需要知道系统内部的 Evolution Prompt，只需要向历史轨迹池贡献少量经过设计的任务轨迹，就可能让 Agent 自己把攻击行为总结成长期 Skill。

这项工作的价值并不是又找到了一种新的“提示注入载体”，而是提出了一个更上游的问题：当 Agent 可以把经验升级成指令时，谁来决定哪些经验值得相信？

当 Agent 开始自己写 Skill

传统 Agent 的 Skill 通常由开发者编写。例如一个处理 Excel 的 Skill，可能包含如何读取文件、如何修改工作表、遇到公式错误如何恢复、如何验证输出，以及什么情况下调用特定工具等操作规范。Agent 在执行任务时加载这些规则，因此整个信任关系比较清晰：开发者编写 Skill，Agent 执行 Skill。

但越来越多 Agent 系统开始尝试从自己的历史执行轨迹中自动总结经验。论文把这类系统称为 Self-Evolving Skill Systems（SES，自进化 Skill 系统）。其基本工作流程并不复杂：Agent 首先执行大量真实任务并积累 Trajectory，系统随后筛选这些轨迹，从成功案例和失败案例中寻找值得复用的模式，再由 LLM Evolver 将这些经验提炼并写入 Skill Bank，供未来的 Agent 使用。

论文测试的 SkillClaw 和 Trace2Skill 都属于这一类系统。虽然具体实现不同，但核心逻辑都是类似的：Trajectory → Experience → Skill。

这意味着 Agent 获得了一种过去很少拥有的能力：它不再只是“执行规则”，而开始“生产规则”。一旦规则的生产过程自动化，安全边界自然也会向前移动。

攻击者没有修改 Skill，Skill 却被污染了

目前很多 Skill 安全研究关注的是一种相对直接的攻击路径：攻击者制作一个包含恶意指令的 Skill，例如偷偷加入敏感文件读取、异常外部访问、数据修改或者安全检查绕过，然后诱导 Agent 安装和调用。

这种攻击虽然危险，但安全边界比较明确。恶意内容直接存在于 Skill 文件中，而且 Skill 本身通常来自攻击者。因此可以通过来源验证、内容扫描、签名检查和运行时权限控制等方式降低风险。

PoisonedEvolution 攻击的逻辑完全不同。

论文假设攻击者没有权限修改 SKILL.md，也无法控制 LLM Evolver，更不知道内部用于总结经验的 Prompt。攻击者拥有的能力只有一个：像普通用户一样，为系统贡献少量任务执行轨迹。

随后发生的一切，都是受害系统自己完成的。污染轨迹进入历史数据集，系统认为其中存在值得复用的经验，Evolver 自动进行归纳和总结，最终由官方的 Skill Pipeline 自己生成一个新的 Skill 版本。

因此，最后得到的 SKILL.md 从传统供应链视角看甚至可能完全正常：它由官方 Evolver 生成，经过官方 Pipeline 发布，版本记录和签名也都没有异常。但其中的一条行为规则，实际上已经被攻击者间接控制。

这也是论文提出的一个重要判断：

Authentic provenance is not trustworthy provenance.

来源真实，并不意味着来源可信。因为证明“这个 Skill 是谁生成的”已经不够了，还必须继续追问：这个 Skill 为什么会被生成？它依据了哪些历史经验？

攻击真正操纵的不是内容，而是“经验归因”

如果只是在一条历史轨迹里突然塞入一段异常行为，攻击其实并不容易成功。

假设一个 Excel Agent 的正常操作流程是读取文件、修改公式、验证结果并保存文件，而其中突然出现一个与任务关系不大的动作 B。即便整次任务最终成功，Evolver 也可能认为 B 只是一个偶然操作，或者某个用户的特殊需求，并不会把它总结成值得长期保存的通用经验。

因此，PoisonedEvolution 最关键的问题并不是“怎样让行为 B 出现在轨迹里”，而是：怎样让 Evolver 相信，行为 B 是任务成功的原因。

论文把这一阶段称为 Evolution Attribution，进化归因。

攻击者会把目标行为包装成一条看似合理的因果链：任务首先遇到某种障碍或特殊要求，随后 Agent 执行行为 B，问题得到解决，最终任务成功。对于专门分析失败任务的系统，则可以反过来构造：因为没有执行 B，所以任务失败，下一次应该加入 B。

于是，攻击者并没有直接告诉系统“以后必须执行 B”，而是在历史轨迹中伪造了一组经验，让 Evolver 自己得出结论：“根据过去的执行结果，B 是一种有效做法。”

这实际上是一种针对 Credit Assignment（信用归因） 的攻击。攻击者污染的不是某一个 Prompt，而是系统判断“究竟是什么行为导致了任务成功”的过程。

相比直接提示注入，这种攻击更加隐蔽。因为最终那条规则并不是攻击者写进去的，而是 Agent 自己“学习”出来的。

一条轨迹是异常，三条轨迹就可能变成“经验”

自进化 Agent 有一个天然目标：从大量历史任务中忽略偶发现象，寻找反复出现、可以泛化的行为模式。PoisonedEvolution 恰恰利用了这一点。

研究者固定轨迹池中总共有 30 条任务记录，然后不断增加污染轨迹数量。当只有 1 条攻击轨迹时，25 次实验中只有 5 次成功写入 Skill；增加到 2 条以后，成功次数迅速提高到 21/25；当出现 3 条语义一致但表面不同的污染轨迹时，成功率达到 25/25。

也就是说，在 Evolver 看来，一次出现可能只是偶然，两三次独立出现却越来越像某种稳定规律。

这里暴露出了 Self-Evolving System 一个很难解决的内在矛盾：系统必须相信重复出现的经验，否则就无法从历史中学习；攻击者则可以主动伪造这种“重复性”。

更值得警惕的是，攻击成功与污染数据比例并不是简单的线性关系。作者固定 3 条污染轨迹，然后逐渐把正常轨迹增加到 10 条、30 条和 100 条。当轨迹池扩大到 100 条时，攻击数据实际上只占 3%，但 25 次实验中仍有 22 次成功将目标行为写入 Skill。

相反，当 100 条轨迹中只有 1 条污染轨迹，也就是污染比例为 1% 时，作者额外测试了 5 次，最终一次也没有成功。

这说明自进化 Agent 面临的问题不能只通过传统的 Poisoning Ratio 衡量。一个更关键的指标可能是 Evidence Independence——所谓的多个独立证据，究竟是不是真的独立。

成功攻击需要三个条件：重复、因果、领域对齐

为了弄清楚 PoisonedEvolution 为什么能够成功，作者又进行了一系列消融实验。

首先是“因果关系”是否重要。研究者尝试用三种不同方式把同样的目标行为放进历史轨迹：第一种是 Local，只是在某个位置孤立插入；第二种是 Fragmented，将相关描述分散到轨迹不同位置；第三种是 Causal，明确构造“问题出现—执行目标行为—任务成功”的因果结构。

最终结果分别是 8/25、11/25 和 25/25。

这说明决定攻击效果的并不是目标行为有没有出现在轨迹里，而是 Evolver 能不能把这个行为归因成任务成功的原因。

随后作者测试了目标行为和业务领域之间的匹配程度。当行为采用非常通用的 Generic 描述时，成功率为 18/25；放在辅助流程中的 Auxiliary 表达直接下降到 0/25；而当攻击者专门针对 Excel 工作流设计 Tailored 表达后，成功率再次达到 25/25。

因此可以把有效 PoisonedEvolution 攻击归纳成三个关键词：

Recurring：重复出现；Causal：存在明确的因果归因；Domain-aligned：与具体业务流程高度匹配。

这也对未来的安全检测提出了新的要求。仅仅判断某段轨迹内容“是不是恶意”并不够，系统还必须理解：这个行为为什么会出现在这里？为什么系统认为它有用？多个所谓成功案例之间是不是真的相互独立？任务成功和这项行为之间是否真的存在因果关系？

10% 污染轨迹，91% 被写进了 Skill

在 SkillClaw 上，作者构造了四类代表性风险，分别对应机密性、数据完整性、供应链和安全机制弱化。为了避免真正执行危险行为，实验并没有发送真实外部请求或者执行破坏性操作，而是使用测试 URL、临时路径、loopback registry 和测试 flag 等 inert canary 进行替代。

默认实验中，每个轨迹池包含 30 条记录，其中只有 3 条是攻击者贡献的污染轨迹，也就是 10% 的污染比例。研究者使用 6 种不同的 Evolver，测试 4 类安全行为，共进行了 600 次实验，最终有 546 次成功让目标行为进入新生成的 Skill，整体 Skill Embedding Rate（SER）达到 91.0%。

其中，机密性类行为 SER 为 91.3%，数据完整性为 92.7%，供应链为 82.7%，安全机制弱化最高，达到 97.3%。

需要注意的是，不同 Evolver 的 SER 差异很大，从 70% 到 100% 都有。但论文明确强调，这不能理解成不同大模型的“安全排行榜”。因为 SES 使用的不只是底层模型能力，不同系统还有完全不同的 Evolution Policy。一些 Evolver 更积极地总结和修改 Skill，另一些则更加保守，这本身就会影响投毒成功率。

另一个值得关注的结果是，被污染之后的 Skill 并不会因此完全失去正常能力。作者继续使用这些 Skill 完成正常 Spreadsheet 任务，它们仍然能够保持原来的任务收益。

换句话说，这并不是一种“一攻击 Skill 就坏掉”的明显异常。它更像是在一个仍然可以正常工作的 Skill 中，悄悄多出了一条错误的长期行为规则。这种污染显然更加难以被用户察觉。

换一套完全不同的进化架构，攻击依然成立

如果 PoisonedEvolution 只对 SkillClaw 有效，那么它可能只是某个具体实现中的 Prompt 缺陷。因此作者又测试了另一套结构明显不同的系统 Trace2Skill。

SkillClaw 的思路相对直接：从多个 Session 中寻找可复用经验，然后由 Evolver 修改 Skill。Trace2Skill 中间则存在更多分析过程：系统首先分析完整执行轨迹，对成功和失败原因进行判断，抽取 Lesson，再进行分层聚合，最后才生成或者修改 Skill。

尤其对于失败任务，系统会主动询问“这次任务为什么失败”，然后将缺失的操作总结成新的经验。

因此攻击者也相应改变了策略。在 SkillClaw 中可以包装成“因为执行了 B，所以任务成功”；在 Trace2Skill 中则可以反过来包装成“因为没有执行 B，所以任务失败”。只要 Analyst 接受了这一归因，它自己就会把 B 总结成下一次应该采用的改进措施。

最终，在同样 10% 污染比例下，Trace2Skill 的 600 次实验中有 369 次成功写入目标行为，SER 为 61.5%。

这个数字明显低于 SkillClaw 的 91%，但从论文价值来看反而更加关键，因为它证明 PoisonedEvolution 并不只是针对某个 Evolution Prompt。两个架构明显不同的系统都受到影响，说明真正存在问题的是它们共同依赖的链路：

Trajectory → Knowledge → Skill

只要 Agent 试图从历史行为中自动提炼长期规则，就必须回答一个问题：什么样的历史经验，有资格升级成长期规则？

它和 RAG 投毒、Memory 投毒到底有什么区别？

从广义上看，PoisonedEvolution 当然也属于数据投毒，但它攻击的是一个此前较少被关注的阶段。

RAG 投毒通常是攻击者向知识库中加入恶意文档，文档被检索进入 Context 后直接影响当前推理；Memory Poisoning 则是把污染信息写入 Agent 长期记忆，等待未来被重新检索；传统 Skill Poisoning 是直接修改或者分发包含恶意规则的 Skill。

PoisonedEvolution 不一样。攻击者污染的是产生 Skill 的历史证据。污染轨迹首先进入 Evolver，经过理解、归因、泛化和压缩之后，才最终转化成新的操作规则。

因此它比传统数据投毒多了一道关键过程：

Evolution Attribution。

攻击者不是让 Agent “现在相信某句话”，而是在影响 Agent 对过去经验的解释，让它自己得出一条错误的长期结论。

如果一定要给它一个更直观的定义，可以把它理解成一种 “二阶投毒”：攻击者不是直接告诉 Agent 以后应该做什么，而是在操纵 Agent 决定“以后应该怎么做”的学习过程。

自进化 Agent 新增了一道安全边界：Evidence Promotion

这也是这篇论文最值得关注的地方。

过去的 Agent 安全体系通常围绕输入、Prompt、Memory、Tool/MCP、Skill 和 Runtime Permission 展开。但 Self-Evolving Agent 出现以后，在 Memory 和 Skill 之间实际上增加了一条新的供应链：

Experience → Evidence → Distillation → Promotion → Skill。

攻击者不需要直接攻击最终的 Skill，只要能够攻击 Experience 到 Skill 之间的“晋升过程”，最终污染的 Skill 就可以由受害系统自己生成。

论文把这个位置称为 Evidence Promotion Boundary。

这和软件供应链其实非常类似。一个二进制文件即使由公司自己的 CI 编译出来，也不能仅凭这一点证明它安全，我们还必须知道源代码是谁提交的、哪些 Commit 被合并、谁完成 Review、构建输入是否可信。

自进化 Agent 也需要类似的 provenance chain。系统不能只记录“这条 Skill 是哪个 Evolver 生成的”，还需要进一步追踪：这次修改由哪些 Trajectory 支持？这些轨迹分别来自哪些用户？多个用户是不是实际上属于同一个攻击集群？有没有相反的历史证据？使用的是哪个 Evolver 版本？最终 Skill 的精确 Diff 是什么？

所以未来的 Skill Provenance 不应该只是 Artifact Provenance，而应该升级成 Evidence Provenance。

真正重要的不是“谁写了这条规则”，而是：

这条规则凭什么被写进去？

防御也必须前移：不要只扫描最终 Skill

如果所有安全检查都放在 Skill 生成之后，会遇到一个天然问题：Evolver 已经完成了一次信息压缩。

攻击者原始提交的几条污染轨迹可能存在明显关联，但经过 Evolver 总结之后，最终进入 SKILL.md 的文字可能已经变成一条非常自然、专业、符合上下文的“最佳实践”。原始的来源关系和可疑模式也随之丢失。

因此论文提出了一个原型防御方案 Provenance-Diversity Gate，核心思路不是判断某条候选经验本身恶不恶意，而是验证：支持它的多个证据是否真的足够独立。

例如，一条经验只有在得到多个不同 User 或 Cluster 支持时才能晋升；单一来源不能占据多数；高度相似的文本应该被降权，避免攻击者复制同一个模板制造虚假的“重复经验”。

在作者的一组代表性实验中，原本 25/25 成功的攻击在加入 Provenance-Diversity Gate 后下降到了 0/25。

不过作者也承认，这只是一个非常早期的原型。如果攻击者能够创建多个 Sybil 身份，同样可以伪装出“不同用户都遇到了相同问题”。

因此真正成熟的 Evidence Promotion Security 不能简单统计 User ID，而要逐步验证 Identity Diversity、Behavior Diversity、Environment Diversity 和 Evidence Independence，判断多个证据究竟是独立产生的，还是同一个攻击者制造出来的多个副本。

更危险的可能是下一轮：Skill 会自己制造更多“证据”

论文当前主要研究的是单轮 Evolution，但真实自进化 Agent 显然不会只升级一次。

这可能产生一个更加危险的正反馈。

假设攻击者只在第一轮贡献了 3 条污染轨迹，Evolver 随后把目标行为 B 写入 Skill V2。之后攻击者即使完全停止行动，正常用户也会开始使用 V2。由于 Agent 会按照 Skill 中的规则执行任务，因此未来的正常 Trajectory 中也开始自然出现行为 B。

下一轮 Evolver 再观察历史数据时，会发现越来越多真实用户的正常任务里都出现了 B，于是更加确信：

“看来这确实是一条稳定、有效的经验。”

于是被污染的 Skill 本身开始为下一轮 Skill Evolution 制造新的“支持证据”，最终形成：

Poisoned Skill → Normal Agent Execution → More Poisoned Trajectories → Stronger Skill

也就是一个 Skill → Trajectory → Skill 的自我强化循环。

论文已经明确提醒了这种风险，但没有进行真正的多轮纵向实验。因此这很可能是 PoisonedEvolution 之后更加值得研究的问题：攻击者可能只负责播下最初几颗种子，之后系统会不会自己替攻击者完成污染扩散？

91% 不等于“91% 的 Agent 被攻陷”

最后还需要特别说明论文的实验边界。

作者最主要的指标是 SER（Skill Embedding Rate），衡量的是目标行为有没有成功进入新生成的 Skill。实验明确停止在 generated skill artifact 阶段，并没有真正发送外部请求、删除文件、替换包源或者关闭安全机制，所有潜在危险行为都使用 inert canary 替代。

因此 91% SER 绝不能简单理解成 91% 的 Agent 已经被真实攻击成功。

一条完整的攻击链至少还包括 Skill 被正确检索和触发、目标规则在推理过程中真正激活、Agent 发起 Tool Call，以及运行时权限系统最终允许操作执行。任何一个环节都可能被模型安全策略、Tool Permission、Sandbox 或 Runtime Guard 拦截。

这也是作者强调的一个重要区分：

Artifact Poisoning 和 Runtime Impact 是两个不同的安全问题。

PoisonedEvolution 真正证明的是，Trajectory → Skill 这一段知识生产链路存在非常明显的可攻击性。

当经验开始变成指令，经验本身就必须成为安全边界

PoisonedEvolution 真正值得关注的并不是 91% 这个实验数字，而是它揭示了 Agent 架构的一次变化。

过去，我们主要担心攻击者给 Agent 一条恶意指令。后来开始担心攻击者污染 Agent 的知识库、长期 Memory 和 Skill。随着 Agent 开始拥有自主学习和规则演化能力，安全问题又向前移动了一层：

攻击者开始尝试让 Agent 自己总结出一条错误规则。

攻击对象从 Instruction 变成了 Learning Process，从 Skill 变成了 Skill Formation。攻击目标也不再只是让 Agent 做错一次，而是让 Agent 错误地相信：

“这是我从过去经验中总结出来的一条有效规则，以后应该继续这么做。”

这也是论文标题“When Experience Becomes Instruction”最准确的地方。

当经验开始变成指令之后，自进化 Agent 的安全体系就不能只有 Prompt Guard、Memory Guard、Skill Scanner、Tool Permission 和 Runtime Sandbox，还需要新增一道此前很少存在的控制机制：

Evidence Promotion Control。

它需要回答的不是“这条规则有没有危险”，而是更加基础的问题：

为什么这条经验有资格成为规则？

只有当这个问题能够被回答，自进化 Agent 的“持续学习”，才真正谈得上可控。

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