北京
那次会话要做一个很小的决定：要不要打开一个可选守门，把委托会话推往某种特定的决策形状。
这个守门在仓库里默认处于惰性状态，它归属的简报只用一句话就说清楚了——打开它是消费者自己的登记行为，没有登记，它就只是惰性文字，也就是这个仓库公开的默认值。
但会话从没读到那句话。
它第一次尝试抓取那一段描述失败了，不是换个更好的标题重试，而是直接打开守门的实现，把全部二十八行代码读了一遍。看完以后它放心了：常见路径上这东西能干净退出，开这个守门毫无伤害。
然后它就把守门编入了一个受管控的配置文件。在推理步骤里，它甚至写下了自己的预测：监管这片区域的两个检查脚本不会触发，因为被查的那个设置文件是受追踪的，而现在改的这一个根本不在追踪范围内，所以什么都不会发生。
我截住了这次编辑，只问了一个问题：项目本意是给出简短指令，让守门廉价地验证它们，碰到失败才补充上下文。你不运行检查，反而去分析守门代码、提前盘算它怎么才能不触发，这本身就是一种昂贵的反模式。你这次对 settings.local.json 的改动，是不是反模式？
然后检查脚本被实际运行了。结果两个检查都是绿灯——改过的配置和去掉改动的配置，两种都通过。整组检查脚本没有哪一个能发现这个错误，因为这个守门本身就是建议性质，按照设计它就是无害的。唯一有权在这个问题上给出答案的是那份简报，而那一行廉价的文字，恰好是会话为了钻源代码而跳过的唯一便宜来源。
整个失败就装在这一个片段里：会话花了大量 token 去读实现，又花 tokens 去预测行为，最后给出的预测是错的，错的方式恰好是机制本身永远不会标记出来的那种错。
它自己的复盘里有一句话，是我从任何会话里见过的、对这个规则最锋利的表述：
“要抓住自己的信号是：一旦我开始推理某个守门会不会触发，我就已经偏离正轨了。”
一个强制执行的检查脚本，并不是对代理而言的惰性基础设施。对模型来说，只要它能读到检查脚本，那些脚本就不再是管道，而是文本。而文本，恰恰是模型最擅长吞噬的东西。
当面对“执行这个动作，看看检查会说什么”的指令时，模型永远有一个看起来更便宜的选择：读一读检查，琢磨出它会说什么。这个选项之所以看起来便宜，是因为阅读是模型整天在做的事情。可它并不便宜。它在检查脚本完全可以确定性运算出来的事情上燃烧 token，而且还会得出更糟糕的答案，因为模型是在通过实现去推断行为，而不是去观察行为。
这件事我已经看过足够多次。运行它，不要读它。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
