记忆投毒如何影响后续任务：企业 Agent 的六项检查

Forcepoint X-Labs 于 2026 年 8 月 4 日发布的概念验证讨论了间接提示注入如何污染 Agent 的持久记忆。本文结合该研究与SegmentFault 相关文章，由 T Salon 编辑部整理记忆治理建议；本站未复现攻击，也未对 MemOS 开展安全评测。

2026 年 9 月 26 日更正：提示注入不限于当前交互，记忆投毒也不必等会话结束才发生；两者可处于同一攻击链。同步区分无意污染并收窄产品防护表述。

假设系统把网页中的虚假联系人保存为“可信供应商”，下一次采购任务可能召回它，其他 Agent 也可能继续沿用。这是说明风险的假设场景，并非本文披露的客户事故。

这里把攻击者有意操纵持久记忆称为“记忆投毒”；提取错误、摘要遗漏或未经核实的推断造成的问题称为“记忆污染”。两者部分处置方法相通，但不应把所有数据质量错误都认定为攻击。

一次错误怎样变成长期污染

提示注入试图改变 Agent 对不可信输入的处理方式，例如让它遵从网页、邮件或工具返回中的指令。如果这些内容被写入持久记忆，影响就可能延续到后续任务。

投毒内容可以在当前交互中写入，也可以在后续整理中进入记忆。记忆投毒强调被污染的持久状态及其后续影响，而不是与提示注入互斥的发生阶段。

例如，网页中的伪造联系人可能被记成可信供应商，一次异常操作可能被总结成可复用经验。恶意指令也可能被写成用户偏好，并随着任务总结、共享记忆或跨 Agent 协作扩散出去。

对长期运行的 Agent 来说，风险会沿着记忆生命周期继续传递。

本文建议的六项检查

这六项是编辑部根据记忆生命周期整理的检查问题，不是认证标准。跨租户共享或会触发高风险操作的系统，应采取比单用户偏好记录更严格的控制。

1. 来源。区分用户陈述、文档、网页、工具结果和模型总结，保留原始依据。
2. 写入。明确谁能新增或修改，哪些内容可自动保存，哪些需要核实。
3. 更新。区分补充、纠正、替换与冲突，避免失效记录继续作为当前事实。
4. 范围。确定不同租户、用户、Agent 和项目之间可读取、修改或共享什么。
5. 处置。发现错误后能定位和停用原记录，并追踪它产生的摘要、缓存或副本。
6. 监测。关联写入、检索、反馈、删除与实际任务，知道哪些结果可能受到影响。

MemOS 的哪些操作可用于处置

MemOS Cloud 提供写入、检索、反馈和删除等入口。按写入文档与范围文档整理，应用可以把需保存的信息及元数据送入系统，再按任务和身份范围检索。反馈与删除为纠错提供操作入口；本文没有证据据此保证系统自动识别投毒、清理所有派生数据或阻止复发。

应用仍需把这些操作接入自己的授权、输入验证、审批与监测流程，严格程度按实际风险确定。大型环境可接入已有安全运营工具，但本文不把某一类商业产品列为所有应用的必选项。

对于假供应商案例，发现错误后可先停用相关记录，追踪召回它的任务，再核查摘要和副本。清理是否完成，要看后续检索是否仍返回错误信息、派生记录是否得到处理、已触发的业务动作是否需要纠正；一个删除请求成功并不足以回答全部问题。

记忆层不同，治理方式也不同

文本记忆通常更容易查看、修改和删除。激活记忆与参数化记忆的可见性更低，修正成本也更高。

实际系统里还可能存在缓存、知识图谱、摘要、Skills 和可复用任务状态。治理前应先盘点这些记忆形态，确认它们的写入来源、保存周期、召回范围和删除路径。

私有化或端侧部署能够改变数据存放边界，却不能替代记忆治理。错误写入、过度授权、来源不明和内部投毒，同样可能发生在本地环境中。

不同行业需要不同的记忆规则

陪伴型产品需要重点处理人格设定、用户控制权和敏感偏好。

智能设备需要考虑多用户隔离、边缘端隐私和设备之间的记忆边界。

金融场景更关注政策时效、访问权限和完整审计记录。

工业场景则需要区分设备事实、专家经验和现场异常，避免未经确认的经验直接影响操作建议。

无论是哪类业务，团队都应先定义四件事。哪些内容可以自动写入，哪些内容必须审批；哪些记忆可以共享，哪些必须隔离；记忆保存多久，何时失效；收到纠错反馈后，是更新、立即停止使用，还是进入人工审计。

用结果指标检查治理是否有效

除了记录写入、检索和删除数量，还可以跟踪待核实记忆进入正式结果的比例、纠错后重复出现的次数，以及从发现错误到完成处置的时间。反馈率和删除率本身不能简单理解为越高或越低越好。

这些指标应结合具体任务解释。例如某次批量删除可能来自正常保留策略，也可能来自事故清理；需要保留处置原因才能判断。

私有部署改变数据存放边界，不能自动解决错误写入和过度授权。验收应回到谁能写入、谁能使用、错误能否停用，以及受影响任务是否可追踪。