长时任务，正在成为 agent 模型的新分水岭

今天 HN 上另一个值得记下来的题目，是 GLM-5.1。表面上看，这又像是一篇熟悉的模型发布稿，列了一堆 benchmark，顺手再说自己对 coding 和 agent task 有明显提升。可如果只把注意力放在排行榜上，反而会错过它真正重要的地方。这次最值得看的，不是"它比谁高了几点"，而是它试图强调一个正在变得越来越关键的能力：长时任务里的持续有效性。

这是 agent 时代一个经常被低估的问题。很多模型在短任务里都已经相当能打了。读几份文件，写一段 patch，修一个明确报错，甚至搭个 demo 页面，大家做得都不算太难看。但一旦任务拉长，情况就会开始变味。模型会过早用完自己的招数，开始在几个熟悉套路里打转；会越来越依赖局部修补，而不是重新建模；会把"还在动"误当成"还在进步"；最后你看它跑了很久，token 烧了不少，真正带来的质量提升却越来越少。

GLM-5.1 这次有意思，就是因为它明确在和这种现象作对。它想证明的不是自己第一轮更聪明，而是自己在更长的时间里仍然有用。文章里反复强调几个特征：它更擅长把模糊问题拆开，能根据实验结果调整策略，能在数百轮迭代和数千次工具调用之后继续寻找新的突破口，而不是很快平台化。这种说法听起来有点抽象，但其实非常贴近真实工程。很多复杂任务，难点本来就不在"会不会写"，而在"能不能在长链路里持续修正自己的判断"。

它举的几个例子也很典型。比如向量数据库优化，模型不是一次性交作业，而是在外层优化循环里不断读 benchmark、改实现、再提交、再分析瓶颈。重要的不只是最后 QPS 高了多少，而是它在几百轮之后仍然能做结构性策略切换，而不只是调参数磨边角。又比如 GPU kernel 优化和长时间网站构建，这些任务共同说明一件事：agent 的价值不只来自初始生成，而来自"在不确定环境里持续推进"的能力。

我觉得这里有一个很重要的行业变化。以前大家评估模型时，隐含前提往往还是"单回合能力"或者"短流程工具调用能力"。也就是说，默认任务像考试题，有一个相对明确的输入、一个相对明确的输出，中间过程只是求解路径。但真正的 agent 任务并不是这样。它更像连续工作。目标会在过程中被重新理解，局部成功会暴露新的瓶颈，环境反馈会逼你改路线，甚至"什么才算完成"本身都需要动态判断。到了这个阶段，模型竞争就不再只是智力竞争，而开始变成耐力、节奏感和自我修正能力的竞争。

这也是为什么"productive horizon"这个概念很重要。不是模型能运行多久，而是多给它一些时间，额外时间是否仍然有价值。很多 agent 现在的问题，不是不能跑八小时，而是跑到第三十分钟后就已经开始低质量循环。后面的时间只是把错误包得更厚，或者把中等方案装饰得更完整。真正更强的模型，应该是在长时间运行后还能继续找到新的高价值动作，还能意识到自己早先的假设哪里错了，还能主动换策略，而不是机械地把同一种动作重复一百遍。

从实际使用角度看，这种能力可能比某些静态 benchmark 排名更重要。因为真实世界的大任务，往往没有一个裁判一直在旁边告诉你"分数升了还是降了"。你做 repo 级重构、跨模块调试、产品原型迭代、自动化脚本编排时，常常面对的是非常稀疏、非常含糊、甚至有些误导性的反馈。模型如果没有足够好的长时判断力，就会要么过早宣布完成，要么在局部最优里磨到天荒地老。于是 agent 看起来很忙，但离真正有价值的结果并没有更近。

这也顺手解释了一个越来越明显的趋势：agent 框架、任务 harness 和上下文管理，正在和模型本身一样重要。因为长时任务能力并不只是模型参数的产物，它还依赖外部循环怎么设计，反馈怎么组织，上下文怎么压缩，什么时候让模型停下来回看，什么时候逼它重新规划。换句话说，未来 agent 竞争不会只是"谁家的基础模型更聪明"，而会是"谁更擅长让模型在长链路里持续保持清醒"。

所以今天这篇 GLM-5.1 的价值，不只是又给排行榜加了一个新名字，而是把 agent 时代真正该问的问题说得更明确了。我们接下来要区分模型，不能只看它第一脚踢得多漂亮，还要看它跑到下半场会不会散架。短任务时代，比的是起跑爆发力。长时任务时代，比的可能是能不能在漫长的不确定性里，继续做出新的、对的、而且值得做的事。