现在的编码智能体，宣传口径里最常出现的一句话是「让它自己跑几个小时」。但一项新研究给出了一个尴尬的发现：它们并不知道几个小时是多久。
由两位独立研究者（牛津大学的 Maksym Andriushchenko 与合作者）在 MATS 研究项目下完成、8 月中旬以《Are LLM agents time-aware?》为题发布的研究显示，主流的编码智能体既估不准任务要花多久，也说不清自己已经跑了多久。
一、测法与结果：一律 90 分钟
测试方法不复杂：每个编码任务开始前，先让智能体预估需要多长时间；任务完成后，再让它回溯自己实际用了多久。测试材料来自 ProgramBench 的 200 个任务，外加研究者自建的 18 项基准。
结果是系统性的偏差。在 ProgramBench 上，两个模型不分任务难度，大多都猜 90 分钟左右。
回溯已用时间时误差更大：Claude Code 平均偏差约 3 倍，Codex 偏差 6 到 10 倍。而且误差在短任务上最离谱，只有当运行时长进入数小时区间，部分预测才接近现实。
二、Harness 决定行为，模型只是其中一环
这项研究里最有工程价值的发现，是同一个模型在不同「harness」（承载智能体的外围软件环境）里表现完全不同。
Claude Code 会一直工作到它认为任务完成为止，中位运行时间约 90 分钟；而 Codex 大约 30 分钟就停，几乎与任务复杂度无关。据研究者统计，同一个语言模型在 Claude Code 中平均比在 Codex 中多走 2.5 倍的步骤。
换句话说，运行时长和行为模式更多取决于外部编排层，而不是模型的内在逻辑。这对选型是直接可用的信息：你买的不是「某个模型的耐力」，而是「某个 harness 的耐力」。
三、更麻烦的是：它们也高估自己做得好不好
时间感之外，研究还测了自我评估。早期模型（Opus 4.8 与 GPT-5.5）平均把成绩高估约 20 个百分点，甚至在失败的任务上给自己打高分。
最典型的一个案例：两个模型都认为自己的工作大约 70% 成功，而实际得分分别是 7% 和 14.5%。
这个缺陷和前面的时间感是同一个问题的两面。要让智能体可靠地执行「在这个任务上迭代两小时」这类指令，它必须先知道两小时是多久；同样，要让它在无人值守时自主判断是否该收手，它得先能判断自己做对了没有。两样它都不擅长。
四、解法意外地简单：给它一块表
研究中最有建设性的一条结论也最朴素：当研究者给智能体提供一个能直接报告已用时间的工具后，它几乎每次都能说对。
这说明问题不在于推理能力，而在于缺少接地信号（grounding）。没有显式输入，智能体根本没有追踪时长的机制——它所谓的时间感，是从训练语料里「猜」出来的，不是观测出来的。研究团队的下一步是测试：有了计时工具之后，智能体能否真正遵守一个给定的工作时长。
五、客观看：边界与实操
需要先给这项研究划范围。它只测了两个 harness（Claude Code 与 Codex）下的编码任务，样本量在同类研究中不算大，也不是顶会论文，而是一篇博客形式的研究记录。结论不宜外推到所有智能体与所有任务类型。
但它指向的问题足够真实，也有几条可以立刻用上的做法：
不要相信智能体的时间自述。无论是「还需 10 分钟」还是「已完成 90%」，都当作待验证的估计，而不是状态报告。真正该看的是外部计时、步数、token 消耗与最终测试结果。
把时间做成工具。如果自研智能体需要长时间运行，把「已运行秒数」作为显式工具暴露给它，成本极低，效果在这项研究里近乎立竿见影。同理，把测试通过率、lint 结果、覆盖率这类可验证信号接进环内，比让它自我感觉良好可靠得多。
用 wall-clock 预算代替「跑到完成」。既然不同 harness 的停止策略差异巨大（中位 90 分钟 vs 约 30 分钟），那么按任务难度设定外部硬性时间上限与最大步数，比把停止判断交给模型更可控。
最后是一个更一般的提醒：智能体的自我监控能力——无论是时间的、进度的还是质量的——不是模型变大之后会自然涌现的属性，而是一项需要显式工程化的基础设施。行业目前在卖的是「能自主工作数小时」，而研究显示，它们连「数小时是多久」都还没搞清楚。这中间的落差，正是接下来一年值得盯的地方。