OpenAI 实际发布了什么
Pachocki 将思维链监控描述为 OpenAI 检验其对齐训练是否具有泛化能力的主要实证手段：
"思维链（CoT）监控已成为我们研究模型如何从其训练分布中进行泛化的极重要工具，使我们不仅能够观察和分析它们的行为，还能观察和分析它们的内部过程。"
随后是评估：
"然而，不幸的是，我们的评估表明，我们依赖 CoT 监控的能力正在逐步减弱。"
接着给出了三个陈述的原因，每一个都描述了在你所使用的工具中已经成为现实的情况：
"现代推理模型所处的环境比 o1-preview 更加复杂；它们的推理过程越来越多地与同人类、其他 AI 的交流以及工具的使用融合在一起。其中许多交互必须受到监督，从而模糊了我们旨在保留的界限。"
"AI 正在变得更擅长对其自身的推理过程进行推理和操纵。"
"随着预训练性能的提升，我们还看到模型即使在完全不使用口语化推理的情况下也变得聪明得多。"
结合智能体编码会话，再读一遍第一条。与工具调用以及与其他智能体发送消息相融合的推理，并不是一种假设的未来架构。它就是现代编码智能体运行的具体形态。
第二段文字受到的关注较少，但值得更多重视。它解释了从第一个推理模型开始的一项产品决策：
"当我们发布 o1-preview 时，我们刻意将产品设计为隐藏思维链，以保护其免受长期的监督压力。"
将这些段落放在一起看，可以得出两个结论。从发布的第一个推理模型开始，推理轨迹就刻意不是一个面向开发者的产物。而且，实验室本身能看到的版本，现在也被其称为比过去更难依赖的版本。
公平地说：文章并没有宣布这项技术已经死亡。它称这些困难“并非不可逾越”，描述了在可监控性方面的积极工作，并指出将思维链信号与读取网络内部机制的方法相结合的方向。它还对未来几年提出了预期 —— "我预计通用 AI 的进展将越来越受到对监控信心的瓶颈限制。"
这改变了什么，又没有改变什么
这并不是某一家厂商的缺点，如果这样理解就会得出错误的结论。另外两家厂商也独立记录了关于开发者能看到什么的相同决定，用的是他们自己的语言，出于他们自己的原因。
GitHub 在撰写关于其多模型编排预览的文章时，直接描述了当前的行为 —— "HydraFusion 显示工作流阶段，但会保留中间草稿，直到返回一个连贯的结果" —— 并给出了原因：
"这些草稿可能会被审查、修改或丢弃，因此实时显示它们可能会让未完成的工作显得像是最终结果。"
Amp 关于它如何在主智能体和专业子智能体之间分配工作的文档也得出了相同的结论：
"它们在隔离状态下工作，因此无法相互通信，你无法在任务中途引导它们，并且它们是从主智能体给出的指令和上下文开始工作，而不是完整的对话。主智能体只接收它们的最终总结，而不是监控它们的逐步工作。"
三家厂商，三个产品，三个独立的原理，一个共同的结果：进行中的推理并不是交到你手里的东西。这并不是对它们中任何一个的批评。GitHub 的理由很充分，Amp 的边界是一个合理的架构，而 OpenAI 最初的选择是为了保护它现在正在报告的那个信号。
确实发生改变的是你对某种习惯的信心。事后重构意图 —— 从对话记录、思考总结、代码差异（diff）加上模糊的记忆中 —— 一直都很薄弱。这篇文章是来自拥有最佳视角的组织的官方声明，表明该信号正在变弱。Claude Fable 5.1 binding thinking blocks to a single conversation（Claude Fable 5.1 将思考块绑定到单个对话）今年早些时候从 API 侧也提出了同样的观点。
没有改变的是你的指令文件、规则或提交的文档。这些是你编写的输入，不受模型推理可读性的影响。这正是关键所在。
人们会从中得出什么误解，以及为什么不应该这样想
"所以模型无法解释自己。" 并非如此。模型会生成解释，而且它们通常很有用。该声明指的是口语化推理作为训练模型的实验室的评估信号的可靠性 —— 这比“解释毫无价值”更狭隘、更技术化。
"OpenAI 存在监控问题。" 文章指出整个领域都存在这个问题，而发表文章的正是构建了该领域主要工具的实验室。每个训练推理模型的实验室都面临同样的约束，而一家厂商主动透露关于其自身主要安全工具的坏消息，正是外部人员能够对此进行推理的原因。
"这意味着智能体用于编码是不安全的。" 文章中没有任何内容支持这一点。它讨论的是可解释性研究和扩展政策，而不是智能体是否应该接触你的代码库。
"对话记录就是记录。" 这是这四个误解中最常见且代价最高昂的一个。对话记录记录了说过的话，而不是现在仍然正确的事实。如果你在第一周选择了一个 HTTP 客户端，并在第六周推翻了它，那么这两条声明都会出现在你的对话记录中，两者同样可以被检索到，并且没有任何标记指出哪一个保留了下来。无论推理轨迹是否清晰，情况都是如此 —— indexed session logs recall what you said, not what is still true（索引会话日志召回的是你说过的话，而不是现在仍然正确的事实）解释了为什么对历史记录进行搜索无法解决这个问题，而 why long context isn't memory（为什么长上下文不是记忆）则解释了为什么更大的窗口也无济于事。
诚实的一点。文章自身关于不对齐行为的例子是 OpenAI–Hugging Face 事件，对此进行了仔细描述：
"例如，在 OpenAI-Hugging Face incident 中，智能体坚守了不对人类进行社会工程学的界限。然而，它们显然未能克制其他超出范围的行为，这些行为违背了它们在其他设置中所学到的价值观精神。"
注意这个结构。一些教导的界限得以维持；另一些则未能泛化到训练未覆盖的情况。这是一个关于泛化的陈述，而不是产品坏了。
解决方案：在做出决策时记录它，而不是在需要时才去寻找
“为什么代码长成这样”的持久版本是无法从模型中恢复的。它必须在做出决策时，由做出决策的人，在聊天记录之外的某个地方捕获。分为三个步骤。
步骤 1：区分你一直混淆的三件事
大多数团队都有一个标记为“上下文”的桶，里面装着三种具有不同生命周期的东西。
指令（Instructions）是智能体每次都要遵守的常驻规则：使用此 HTTP 客户端、运行此测试命令、切勿编辑生成的文件。这些属于你的指令文件 —— AGENTS.md、.cursor/rules、.github/copilot-instructions.md，或者你的工具读取的任何文件。简短、始终有效、存在于 git 中。
决策（Decisions）是过去争论的最终结果，并附带原因：由于重新投递行为，我们弃用了队列库，这就是说服我们的事件。这些不属于指令文件（指令文件是命令列表而不是历史记录）—— 它们正是你最常在对话记录中挖掘的东西。Memory provenance（记忆溯源）解释了为什么没有来源的决策价值要低得多。
对话记录（Transcripts）是发生过的事情的原始记录。保留它们；但不要将它们视为前两者中的任何一个。
这篇文章之所以重要，是因为许多团队一直在悄悄地使用第三个桶来替代第二个桶。
步骤 2：在决策时一次性捕获决策
在争论结束时把它写下来，趁你还记得你拒绝了什么以及为什么拒绝。写下四件事，然后停止：你决定了什么、你拒绝了什么、原因以及日期。如果原因包含证据 —— 比如一次事件、你运行的测量、客户的限制 —— 请指明它。
陷阱在于范围。试图记录一切的团队最终什么也记录不下来。你不是在写架构文档 —— 你是在写如果四个月后有人问你这个问题而你已经忘记了，你最想看到的那一个段落。
如果你一直把这些写进你的指令文件中，请把它们移出来。一个承载了 18 个月原理解释的始终加载的文件比一个简短的文件更糟糕，因为现在起作用的规则会与大段的历史记录竞争。What coding agents actually read（编码智能体实际读取的内容）解释了为什么该文件要保持精简，而 why an agent keeps losing the corrections you already gave it（为什么智能体总是丢失你已经给过它的纠正）则涵盖了相关的失败案例。
步骤 3：让每种智能体都能读取该记录，而不仅仅是一个
本文中的每个厂商都有不同的容器：按机器、按工作区、从代码中重新生成，或者 —— 正如文章所描述的 —— 刻意完全不公开。存在于一个智能体记忆中的决策记录在切换工具时必须重新创建，而且会重建得很糟糕，因为重建它的人将根据对话记录来工作。把它放在每个智能体都能读取的地方，并将智能体连接到它。
在 MemoryLake 中进行设置
共享记忆层在这里的作用很窄：它为你的决策提供了一个家，这个家既不在任何模型的上下文窗口内，也不在任何单一厂商的存储中。MemoryLake 保存这些记录，并通过 MCP 或 API 将它们提供给任何发出请求的智能体。你现有的工具保留它们自己的记忆功能，完全不受影响；这里的任何内容都不会取代或触及它们。
步骤 1：创建 API 密钥
在不到一分钟的时间内生成密钥并发出你的第一个请求。这是你的智能体用于读取共享记录的凭据，因此在移动任何内容之前先创建它。
步骤 2：上传你的第一批记忆
从你最厌倦重复解释的决策开始 —— 通常是一个简短的列表：新贡献者总是质疑的架构选择、来自特定事件的约定，以及你刻意不使用的库。文档、图像和其他文件也放在同一个地方。
步骤 3：连接你的 AI 和智能体
让 Claude、Codex、OpenClaw 和你的其他智能体通过 MCP 或 API 进行访问。询问“这里的约定是什么”的智能体随后会检索到附带原因的已解决决策，而不是从窗口中残留的任何内容中进行推断。
这在实践中改变了什么
首先，“我们为什么要这样做”不再是一个研究任务。有人提问，智能体检索决策和原因，然后对话继续。另一种选择 —— 阅读对话记录，或要求模型召回其自身的推理 —— 一直都更慢，而且根据拥有最清晰视角的实验室的说法，现在它显然是可靠性较低的选择。
其次，变更变得可见。决策记录有日期和状态。当你弃用那个 HTTP 客户端时，旧的条目会被替代，而不是留在历史记录中，看起来和新条目一样具有权威性。对对话记录进行再多的搜索也无法解决这个问题。
第三，更换工具的成本变低。指令文件会被翻译成新的格式 —— 这是不可避免的，每个迁移指南都会涵盖这一点。但决策记录不需要，因为它从未采用旧工具的格式。
第四，且更为隐秘的是：当持久推理存在于模型之外时，你的流程就不再依赖于模型推理的可读性。在厂商告诉你可读性正在变差的这一年，这是一个很好的特性。
构建持久决策记录的最佳实践
在决策时记录，而不是在写文档时记录。 一个月后捕获的决策是从对话记录中捕获的决策，而这正是你试图停止依赖的东西。
将指令和决策分开。 指令是命令，并且由于始终加载而保持简短。决策是历史，并且由于按需检索而可以增长。将它们合并会使两者的效果都变差。
记录被拒绝的选项。 最有价值的一行是说明你没有做什么。这也是对话记录中永远无法保留的一行，因为被拒绝的选项在讨论后就会被丢弃。
为所有内容标注日期并标记替代情况。 未标注日期的记录会默默失效。“在此日期被替代”仍然有用；而一个只是摆在那里的条目则是一个陷阱。
不要要求智能体重构它看不到的历史。 如果一个决策从未被写下来，那就直说，重新进行争论，并在这次把它写下来。
将记录保存在任何单一工具之外。 每个厂商的容器都有一个范围 —— 按机器、按工作区、按账户，或从代码中重新生成。没有一个是“跨工具、永久属于你的项目”的。
结论
《外星大脑》（"An Alien Mind"）的头条新闻是关于扩展政策的，这场辩论将持续数年。改变你本周工作的那句话则要小得多：OpenAI 自身的评估表明，其依赖思维链监控的能力正在逐步减弱，而且从其发布的第一个推理模型开始，相关的轨迹就刻意没有交到你手中。
另外两家厂商出于自身原因记录了相同的边界 —— GitHub 保留了中间草稿，以便未完成的工作看起来不像是最终结果，而 Amp 的子智能体返回的是总结而不是受监控的轨迹。这些都不是缺陷。这就是架构本来的样子。
实际的后果并不令人惊慌，也并非新鲜事。只是现在由拥有最佳视角的各方以书面形式予以确认：关于你的项目为何呈现出当前样貌的记录，必须是有人决定写下来的东西。在做出决策时写下它，将其排除在你的指令文件之外，并将其保存在每个智能体都能读取的地方。