这条讲的是编码智能体内部，语言模型在残差流里线性编码了程序状态的几个属性：能不能 parse、过不过测试、有没有减少失败测试、有没有引入回归。出处是 André Silva、Han Tu、Martin Monperrus 七月初提交到 arXiv 的，编号 2607.05188，主领域标 cs.LG，主题里还挂了 cs.SE。我读的时候没指望它多新鲜，逻辑回归探针解码隐藏状态这套做法，机制可解释性圈子里已经用到有点乏了。
读完第三节才确认这篇值得点开，而且值得点的不是 AUC。
我一开始扫到摘要里的 0.83，心想这数字放评估器里不算高，放"模型对自己状态有微弱预测力"那堆论文里也不算出格。真正让我醒过来的是作者管那个时间提前量叫 latent programming horizon——探针不只是解码出当前状态好不好，它能在 agent 真正动手 edit 之前，提前大概 25 步预测这次 edit 的结果会是变好还是变坏。
这个时延的指向才是我推荐的理由。
我们平时调 agent 全是事后行为：它改完，我们跑测试，然后对着 diff 骂。如果隐藏状态里提前 25 步就已经摆着"这次要糟"的线性可解码信号，那我们一直在用一个迟到了 25 步的 gauge 抽自己。我不确定这个时延能不能被工程上用起来，但方向先戳到我了。
作者探测了四个属性，不只有"能不能通过测试"，还包括能不能 parse、会不会引入回归。这个我读到的时候眼睛停了停——多属性的好处不是覆盖面，是能交叉看：如果探针对"引入回归"的提前预测明显弱于对"减少失败测试"的预测，那说明模型内部对"我别把已经好的东西弄坏"这件事本身就没那么早形成准信。作者没有把四个属性的曲线并排怼脸上，但数据够拿来自己比。
顺手跑一下的部分我这次得承认没跑通。作者没把探针提取脚本放出来，至少我翻到的主文和附录里没有能直接跑的 raw hidden state 提取代码。这条也就没法按原样复现。我最多做的是纸面反推：如果我拿一个现成的代码模型，把每个 token 位置的 hidden state 拉出来，喂给逻辑回归，标签设成"未来 25 步内失败测试数有没有减少"，能不能拿到近似的 horizon。做法不难，难的是怎么排除"这就是模型从一开始已经读懂任务、探针后期才敢出声"这个解释——作者好像也明白这一点，但区分"静态表征 + 探针自己拉高阈值"和"真的提前出现预测力"，写得比较克制。
跨基准迁移那个点，我读到那行的时候基本就决定要推这篇了。探针不用重新训练就能在另一个基准上保持预测力，这个比 AUC 本身更能说服我。如果只是在一个 benchmark 上把隐藏状态和未来结果对上了，那多半是那个基准本身分布太窄；能跨过去，至少说明它学到的不是某个输入界面独有的特征。
我不知道作者们自己算没算过另一个反例：如果探针能提前 25 步预测这次 edit 会引入回归，那人为什么还要让 agent 真去改？直接把探针接成 guardrail，在行动前拦下来不就行了。我读到一半就在想这个。他们没往工程化上写，主要是把发现往"呼吁对编码智能体做更多机制可解释性研究"那个方向推。
这个呼吁本身没问题。但以我自己的口味，先放探针的完整代码，再呼吁可解释性，力道会足得多。现在这篇只能算读，不能算验证过。
不点链接也能带走的一句：想在 agent 动手前拦住一次坏编辑，看 hidden state 的线性探针可能比等 diff 快 25 步；四类属性里，"引入回归"的提前预测力比"通过测试"更值得盯着看，因为那才是你不敢让它乱动的部分。
我夹子里还存着几篇同一类探针解 agent 状态的文章，但没有一篇把时间提前量写得这么明确。这条不是因为结论新到什么程度，是因为它把"模型在动手前已经知道这次会不会糟"这个说法推到了可测量的 25 步。等哪天作者真把探针和隐藏状态提取脚本放出来，我拿两个小模型在别的基准上补一遍，看看这 25 步在我环境里是几度都看不见，还是能摸到一点影子。先记着。