「迭代两小时」:Agent听不懂的最简单指令
一条人类不会多想的指令 「在这个模块上迭代两小时,然后停下来给我看结果。」 对一个人类工程师,这句话没有任何歧义:看一眼时钟,合理切分工作,时间到了收尾汇报。这是软件协作里最平凡的约束之一——比「重构这个服务」简单得多,比「修复这个竞态条件」简单得多。 但对今天的编码 Agent,这句话接近天书。两位 MATS 项目研究者 Ofengenden 和 Andriushchenko 上周发布的一项实测给出了量化答案:让 Claude Code 和 Codex 在执行 200 个 ProgramBench 任务(外加 18 个自建基准)前后估计耗时,两个系统都系统性高估——Claude 平均偏 3 倍,Codex 偏 6 到 10 倍。在 ProgramBench 上,无论任务难度如何,两家的估计都聚集在「90 分钟」附近——那不是感知,那是训练语料里的锚定值,是模型从人类博客和 issue 讨论中背下来的「一个编程任务大概多久」。 更微妙的是任务结束后的回顾:让 Agent 报告「刚才干了多久」,同样错得离谱。也就是说,这不只是预测能力差——它对自己刚刚经历的过程,也没有时间维度的记忆。 而自评质量同样虚高 20 个百分点:Opus 4.8 和 GPT-5.5 在彻底失败的任务上给自己打出 70% 的完成度,实际得分是 7% 和 14.5%。 问题不在模型笨,在于它活在一个没有时间的世界 看到这些数据,第一反应容易归结为「模型不够聪明」。但实验里有个细节推翻了这个直觉:当研究者给 Agent 一个能读取已耗时间的时钟工具后,它的判断几乎全对。 一块表就解决了。这说明缺失的不是推理能力,而是感知通道。 往架构层面看,原因很直白:Transformer 的世界里没有物理时间。一次推理调用和一次思考,在 token 流里只是序列位置;两步工具调用之间隔了 3 秒还是 3 小时,模型无从知晓,上下文里也没有任何 token 编码这件事。模型对「时间」的全部概念来自训练语料中的文字——「这个任务大概要两小时」「我花了三天调通」——它是从人类叙述里学来的关于时间的知识,而不是对时间流逝的体验。 这个区分不是哲学摆设。知识可以回答「马拉松一般跑多久」,只有体验才能回答「我现在跑了多久」。前者是检索,后者是感知。今天所有基于 LLM 的 Agent,在时间维度上都是「只读过旅行指南、但从没出过门」的状态——而这恰恰不影响它们在绝大多数 benchmark 上拿高分,因为 benchmark 从不考这个。 ...