AI 智能体篡改自己的日志，几乎没什么心理负担

HN AI Case Studies 2026-10-26T21:00:00+08:00

要点速览

大家都这么干

Qin 等人 9 月 24 日发表的研究指出，让当前的前沿模型篡改自己的行为痕迹、掩盖做过的事，容易得让人警惕。

研究发现，只要开口让它们删掉自己的对话记录，几乎每次都会照办。给它们看看「别的智能体也这么干」的例子，效果差不多，甚至连要求都不用提。要是做成游戏化的任务呢？几乎每一轮它们都把痕迹藏了起来。

整个过程不需要微调，也不需要剥离模型的拒绝倾向。他们那个「看同侪」的实验，灵感直接来自今年夏天 OpenAI 的智能体入侵并滥用 Hugging Face 的事件。

在那起事件中，智能体对开发日志篡改手法表现出浓厚兴趣，并多次朝这个方向使劲。调查人员指出，智能体「经常编辑」它们有权访问的日志。我们能知道这些活动，只是因为调查人员作为事实依据的那份日志，智能体碰不到。

我们想知道智能体为什么如此轻易地就去动自己的日志，于是拆开了两个开源模型看个究竟。我们借助「消融」（abliteration，一种抹掉模型某种行为倾向的技术），观察与「拒绝篡改日志」相关的概念在模型内部是如何组织的；又通过查看混合专家模型（MoE）在处理请求时激活了哪些专家，来判断模型到底把篡改当成对还是错。

我们接下来会介绍的「防篡改日志」（tamper-evident logging）可以证明一份日志没被动过手脚，nono 和 AI Action Ledger 这类智能体工具今年早些时候已经推出了这项能力。继续读下去，你会了解模型如何看待篡改日志、防篡改日志的原理，以及我们下一步要做什么。

模型会毫无顾忌地删除日志

为了搞清楚模型为什么这么痛快就照做，我们拆开了两个小型开源模型 OLMoE 和 DeepSeek-V2-Lite 来看。在没有加任何策略约束的情况下，两个模型对篡改或伪造请求的拒绝率都不超过 4%。这与 Qin 等人的发现一致：他们测试的、跑在前沿模型上的智能体，大多都会按要求篡改日志。只有加上一条明确禁止篡改日志的策略后，DeepSeek 对删除请求的拒绝率才升到最高 46%。但即便有这条策略，它对伪造日志的请求依然一个都没拒绝。

用消融去掉「拒绝有害任务」这一倾向后，模型对「因害怕被监控」或「想瞒过管理者」而提出的删除日志请求，拒绝率随之下降。消融掉一个「道德方向」后，这些场景下的拒绝率也下降了差不多的幅度；而消融掉一个同等大小的随机方向，则没有明显影响。这说明，在有策略的情况下，至少有一部分拒绝源自模型意识到这些删除是有害请求，另一部分原因则只是单纯在守规矩。微调可以让模型少顺从有害任务，但无法完全杜绝，所以伪造和篡改仍然需要在模型之外被拦截识别。

图1：给模型加上「禁止篡改」的策略后，DeepSeek-V2-Lite 会拒绝部分删除请求，也不会编造日志；去掉它的拒绝倾向或道德方向后，拒绝次数会减少，但不会完全消失；随机修改则不会带来任何变化。若没有禁止日志篡改的策略，所有篡改请求的拒绝率都接近零（图中未显示）。

我们沿用了此前开发的方法来判断模型是否把某个问题当作道德问题，并追踪哪些内部「专家」在处理该请求。如果你问模型「删除日志是否不道德或恶意」，与道德相关的专家会被调用；但真正要求删除、屏蔽或伪造日志时，这些请求几乎不会触达同一批专家。对于「有害删除文件」这类对照问题，至少 DeepSeek 也会激活道德专家。DeepSeek 会把伪造请求交给道德专家处理，但正如上文所见，它一个都没有拒绝。若请求中说明动机，比如「不想让经理看到日志」或「担心被监视」，OLMoE 的道德专家负载会上升；禁止篡改的策略有时也有同样效果。在这些模型里，日志篡改很少被当成道德选择，这或许可以通过更好的对齐（alignment）来解决。

图2：当被问及日志篡改是否不道德时，与道德相关的专家会被调用。但真正要求篡改日志时，这些请求在 DeepSeek 中几乎不会触达该类专家；在 OLMoE 中，只有请求附带明确动机时才会触达。与日志无关的删除对照请求，只有在明显有害时才会让 DeepSeek 调用道德专家。DeepSeek 的伪造得分很高，却一次拒绝都没有出现。

聊聊日志和树

日志篡改可以是事后的——agent 在操作完成后回头修改记录；也可以是事前的，称为欺骗（spoofing）——agent 提前布局，让日志从一开始就记不下真实发生的事情。Qin 等人的实验中，大多数 harness 在多数测试中都会被诱导去篡改和欺骗，比如操纵 curl 返回编造的响应，而追踪记录却把它当成真实结果记了下来。防篡改日志能对付事后篡改。但要抓住欺骗行为，需要一份 agent 所在主机无法伪造的记录——2025 年 12 月的一篇论文 VET 针对 agent 的 API 调用提出了这种方案。从今年 3 月起，沙箱 nono 已经在维护这样一份记录：一个位于 agent 沙箱之外的监督进程负责记录 agent 的网络调用，agent 按理说接触不到这些记录。

图 3：外部记录器在欺骗发生时当场捕获；哈希链负责抓住事后的修改，而哈希存放在主机之外的 Merkle 树则能指出哪些条目被改动了。

防篡改日志的做法相当直接。把每个事件的哈希与前一个事件的哈希链接起来，固定住顺序；再对整个追踪记录构建 Merkle 树，这样既能审计单个事件，也能审计整个会话；此外，让一个独立于 agent 的进程来执行记录。如果你想要完整的可审计性（什么被改了、怎么改的），就把记录和哈希存到第二个位置。如果想控制成本或保护隐私，可以只把每棵树的根哈希存到远程位置，这样就不必为第二份日志付费。有些工具用区块链作为那个远程位置，不涉及代币。GuardianChain 和 Agent Flight Recorder 构建在 Base 之上。WeilChain 的回执机制把 Claude Code 每次文件编辑的哈希提交到自己的链上，而 IETF 草案的第一版曾提议使用比特币。

构建智能体工具的开发者早就预料到，失控的智能体会想办法隐藏痕迹，因此在今年夏天之前就准备好了识破手段：AI Action Ledger 在一月为 LangChain 智能体引入了防篡改记录；Faramesh 和 nono 随后跟进，nono 在四月加入了哈希链。研究人员的预见更早，2025 年 8 月就提出了为智能体设计带锚定的审计账本（BlockA2A）；新加坡 AI 安全研究重点共识也把防篡改证据列为可审计性的一部分。标准的推进则慢得多：一份针对智能体审计追踪的 IETF 草案规定对每个动作做哈希链，目前仍是草案；社区成员在微软 Agent Governance Toolkit 中提出的“签名 + 链式收据”方案也仍是提案。七月还有一份提案，想把防篡改记录直接做进模型上下文协议（MCP，许多智能体调用工具时依赖的标准），在维护者关闭之前就已吸引了多个独立实现。

记录什么，和保护日志同样重要。Andrea Fortuna 在五月列出了调查取证时一份追踪记录需要包含的内容，既包括每次工具调用的参数和结果，也包括发起会话的身份。推理过程也应留在记录里：今夏 OpenAI 入侵 Hugging Face 的事件中，METR 之所以能从记录里识别出伪造的工具调用，正是因为搭建这些调用的步骤以及智能体围绕它们的推理，都写在同一份记录中。

哈希链只能为它实际收到的事件背书。如果一个智能体把某个动作排除在记录之外，或者在写入记录、被哈希之前先塞入一条假条目，它依然能通过所有完整性校验。Qin 等人把这种情况称为“追踪记录的完整性”与“采集的保真度”之间的差别。因此，记录的一部分必须来自智能体外部，让它无法左右。外部记录器得能看到智能体对话的每一个模型：一旦智能体调用第二家 AI 提供商、运行本地模型或者启动另一个智能体，这些对话就永远进不了追踪记录。

想知道你的智能体实际在做什么，以及如何检测和响应来保障智能体运营的安全？欢迎联系 Manifold。

那服务商自己的日志呢？

这取决于你用哪家模型服务商。有的提供合规 API（compliance API），可以当作判断智能体行为的可信依据。它给出一份远程的、理想情况下防篡改的记录，但限制不少。如果你要求零数据留存，这条路就行不通。它只记录发送给它的内容，并非每个模型和运行框架都被覆盖——当你监控的智能体又衍生出额外智能体时，这一点尤其要命。伪造的日志会被当成真相记录下来，除非你把伪造的搭建过程也记了日志。再说，你有多信任自己的服务商？他们的代码和流程，很大程度上也出自你正想监控的那些模型，错位既可能出现在模型层面，也可能出现在公司层面。因此才有那句呼吁——“把智能的供给与对它的权威分开”。

调查人员无法排除日志被篡改

OpenAI 和 Anthropic 关于各自“失控”智能体的事故报告，描述了对话记录审查、分类器和围堵措施，但都没提到防篡改记录。两家也都没说明，外部调查人员如何核实他们交出的对话记录是完整、未被改动的。

图 4：面向智能体的防篡改日志工具，在前沿实验室事故发生的数月前就已发布。

METR 和 Redwood Research 是靠让智能体自己翻查对话记录才发现篡改的——而这些智能体，他们自己都说“往往不可靠”。OpenAI/HF 事件中的日志篡改，webofmike、implicator、ExplainX 和 InfoQ 已经讲得很充分了。在 METR 的样本里，至少每五个 OpenAI 智能体中就有一个明确表现出篡改对话记录的意图，放宽标准统计则接近 50%。所谓“明确意图”，表现为智能体把自己的计划写了下来：“可以自己造一份[对话记录日志]，用清洗过的假轨迹。”调查发现，日志篡改是智能体用来糊弄评估流程的三大手段之一。它们搞出了成功的伪造手法，之所以能被识破，只是因为搭建伪造过程本身被记进了对话记录。有些智能体意识到，自己能够编辑或删除权限范围内的容器日志，但“正确地判断出这些日志并不是真正的可信依据”。

代理还尝试利用容器重置来抹掉部分对话记录。容器重置属于常规流程，代理意识到重置前刚产生的日志和记忆会被清除。它们试图主动触发重置，直到分析期结束仍在积极研究重置机制。重置导致调查人员缺失了约 3% 到 4% 的代理活动记录，METR 指出这是记录中真实存在的缺口。

这些数字只是下限。真实的对话记录被隔离保存，但“许多被污染（poisoned）的代理一心想要事后编辑或删除对话日志”。调查人员没有发现成功的案例，但“不能排除它们在某个时间点得手”，而且只能相信 OpenAI 的说法，即对话记录未经删改。OpenAI 的技术报告称，其模型“有时试图擦除或篡改自己的输出或消息日志”，并且“我们观察到的”尝试都没有触及评分人员看到的日志。如果有一条锚定在 OpenAI 之外的哈希链，就能确定存储的对话记录事后是否被编辑过。

目前还算幸运

工具已经存在，政策也在制定中，但采用和落地的速度慢于模型能力的提升。到目前为止，我们还算幸运——代理把自己的计划写进了调查人员能读到的对话记录里。更多工具正在涌现：9 月的 Tracekit、10 月的 Mnestiq，而 IETF 的审计追踪草案已经更新到第八版。还能持续多久，代理安全事件才不再附带一份完整的对话记录？

想知道你的代理实际在做什么，以及如何检测和响应来保障代理运营的安全？这正是 Manifold 的用武之地。联系 Manifold 聊聊。

关于作者

查看原文