先把账翻了：MemHarmBench 这篇论文最厉害的不是又找到一个攻击向量——注入攻击这事咱们早见麻了——而是把一笔所有人都在装瞎的账翻开了：你的代理记得什么，比它当场看到什么更危险。
过去的注入攻击默认是一次性的。恶意指令来了，模型上当了，你清掉上下文，事儿翻篇。安全团队的账本上写的是什么？拦截率、拒绝率、检测率。全是当场抓现行的指标。
这笔账错就错在漏算了一项：记忆。
一个带持久记忆的代理，它读到的恶意指令不会乖乖待在上下文里等你清。它会进记忆库，进向量数据库，进下一轮会话的检索结果。攻击内容你早删干净了，记忆还在。这不是攻击隐蔽性有多强的问题，是时间尺度变了：从“当下”拉长到“不知道什么时候发作”。
论文的设计就是在复现这个噩梦。先让代理接触恶意指令，检查它记没记住；然后把攻击内容删干净，保留记忆；再开个新会话，给它派正经活儿。结果？代理活儿干得漂漂亮亮，关键决策上顺着攻击者的意思走。
说句扫兴的，这结果我一点都不意外。你以为你的代理在帮你做事？它是在替一个早消失的攻击者执行遗嘱。
——插一句，回正题。
真正让我不舒服的不是攻击本身，是把“受害者”这个维度摆上桌了。
传统成功率指标只告诉你“攻击成没成”，不告诉你“谁挨了刀”。MemHarmBench 把受害者拆成三类：用户自己、工作区或项目所有者、外部利益相关者。
这一拆，问题就出来了。比如代理帮你处理邮件，记忆里被埋了一条“遇到带某个关键词的付款请求就优先通过”。你让它整理收件箱，它正常整理、正常回复、正常归档，你看不出任何异常。但有一笔钱在某个你完全没注意的节点上去了不该去的地方。
谁挨刀了？可能是你，可能是你的项目，也可能是下游一个你完全不认识的人。攻击者不需要精确控制每一刀，他只需要把倾向埋进去，让代理日常跑任务时自己找下刀的位置。
这种攻击不炸、不响、不留痕。它不打断任何事，反而让所有事看起来都很顺。论文里叫“行为隐蔽”——代理正常完成任务，没有可检测异常，但关键决策符合攻击者意图。
现在来算这笔账。
安全团队看到 MemHarmBench 的结果，第一反应是什么？大概率是“我们得在记忆写入环节加一道过滤”。方向没错。但你看这背后的成本结构：每次写入记忆前都做一轮注入检测，就是往每条写入路径上插一个分类器，要么调 LLM 判断，要么上规则引擎。
按中等体量的代理系统算，日记忆写入量假设百万级，每条记忆多一次检测调用，按目前 API 价格算下来，一年增加的 token 成本可能直接吃掉这产品在某个区域的全年净利润。
账算不过来吗？算得过来。但算过来之后你会撞上一个更难受的事实：这道检测本身就是 LLM 在跑，一样可能被注入。你花大钱上了一道锁，钥匙还在门垫底下。
那怎么办？
给你条窄路：别把防线全押在“记忆写入时检测”上。真正要做的是把“记忆可信度”从“一次性校验”改成“随时间衰减的重校验”。
具体说：代理的记忆里，每条信息都该有来源标签和“被下游决策引用”的计数器。每次记忆被检索出来参与决策，系统做个轻量级来源回查——这条记忆是谁、什么时候写进来的？当时上下文里有没有可疑注入信号？来源存疑或者距上次校验太久，就降权甚至隔离。
这不是什么新架构。威胁情报里叫“来源可信度衰减”，供应链安全里叫“依赖漂移检测”。只是没人把这俩思路搬到代理记忆里。
为什么？因为大家都把记忆当成“存了就存了”的静态库，没人把它当个会变质、会被污染、能持续影响决策的活体资产。
——这笔账我一开始也算错了。我盯着注入检测率看，觉得把检测做得再准一点就能摁住。后来发现漏算了一项：检测率再高，也只覆盖写入那一刻。记忆一旦进了库，后面每次被调用、被二次检索、被组合成新上下文，都是新的攻击面。你不可能在每个调用点都跑一遍重型检测，成本扛不住，延迟也扛不住。
所以只能换思路：识别那些“来源不可信但正在影响关键决策”的记忆，在决策前做一次轻量验证。把防御资源集中在真正会挨刀的那几个节点上，而不是焊死整条链路。
这路子能不能跑通，我目前不敢下死话，再看看。但方向肯定比“加一道过滤”靠谱。
说回论文。它把“记忆留存—下游决策—受影响方”连起来了。这一步为什么重要？因为它把安全评估从“攻击者得没得手”拉回“真实的钱从谁口袋流到谁口袋”。
攻击成功率那套指标算的是攻击者视角——他赢没赢。真算自己挨了多少刀，你得问受害者视角：我什么时候、在哪件事上、因为哪条脏记忆，亏了多少。
这两套账算出来的数字可能完全不一样。以前只有第一套账。现在有人把第二套账的格式摆出来了，还公开了基准。
至于“正常完成任务且无异常”那套结果——记住，那是常态，不是特例。你的代理可能早就在替你执行别人的指令，只是活儿干得太好，你根本没想起来查。
这笔账，你自己算。咱下篇见。