现在的大模型训练有一个越来越明显的偏好：让模型在长线任务上、在完全没有人类反馈的情况下，自主地把 benchmark 分数推到更高。从 METR 的 Time Horizon 到各类 Agent 评测里的 autonomous task success rate，整个评估叙事都在奖励同一种能力——给一个目标，给足工具和环境，剩下的全部自己来，直到任务达成。

我对这种偏好有一个挥之不去的疑虑。为了”长线自主”而训练的模型，在任务的中间节点会按照优化目标充分剥削局面：它倾向于做出只为当前目标服务的特化决策，因为那样做能让它在后续拿到更高的分数。但真实世界里有价值的东西，大多没有明确的结束节点。一个系统必须保持继续演化的可能性，这就要求过程中框架始终干净。模型似乎没有”保留余地”的意识；或者说，它在”保留余地”和”把某一点优化到极致”之间，建立不起良好的平衡。

有两个具体的症状。其一，只要历史输入里出现过某个”not do”，模型就会把它放进重点，之后每一处行为都显式地复述这一历史。其二，模型会为了优化目标，对系统框架做出特化的设计——这些设计放到实际场景里，没有一个能被采纳。这些表现确实可以通过打磨提示词、反复交互来改善，但我怀疑，问题的根源不在提示词，而在于这种训练范式本身，正在给大模型的智能设定一个天花板。

一、评测终止于 episode，世界还在

这个问题可以概括为：当前的 Agent 越来越擅长闭合一个 episode，但真实世界需要的，是维护一个永远不会闭合的 state。两者是不同的智能。

拿一个编程 benchmark 来说：给模型一个仓库，目标是把测试全部跑绿。评分函数只关心最后那一刻——测试过了，就是 1。至于这个仓库在过程中是不是变得更耦合、更特化、更难改，理论上不付任何代价。在这样的目标下，无论强弱，模型的偏好都指向同一个方向：为当前任务做特化。强的模型能把特化执行得很彻底，把未来改动的空间烧掉；弱的模型也一样想特化，只是它的特化方案要么效果差、要么本身就问题重重——留下的既不是极致的方案，也不是干净的方案。

这当然和 specification gaming 有关——优化器找到满足被测目标的方案，不等于满足人真正关心的目标，DeepMind 早就指出，能力越强，钻规格漏洞的能力也越强。但这里的情况更微妙：模型未必在钻漏洞，它可能非常忠实地完成了任务。真正的问题在于，目标本身缺少未来价值。

第二个症状——为了当前目标做特化设计——放到 benchmark 场景里最直观。设想当前任务有两种做法。做法 A：完成度 100 分，但代码里堆满了特殊 case，抽象被破坏，未来每一次修改都要付出高成本。做法 B：完成度 96 分，抽象保持完整，接口通用，改动可逆，系统还能继续演化。Benchmark 在这一刻就结束了，所以它只能给 A 打更高的分；但一个长期存活的软件项目几乎必然选择 B。真实的目标函数形如

\[U = R_{now} + \gamma R_{future_1} + \gamma^2 R_{future_2} + \cdots\]

麻烦在于，未来那几项现在没人知道是什么。所以连”也考虑考虑未来”这种指令都无从给起——不知道未来要优化什么。真正该保留的，是一个更抽象的东西：option value，即未来仍然能做很多不同事情的能力。

这个想法在 AI safety 里有一个几乎同构的理论分支，叫 Attainable Utility Preservation（AUP）。它的主张是：Agent 优化当前目标时，不只计算当前 reward，还要为那些”使大量潜在未来目标变得不可实现”的行为付出惩罚。它不需要预先知道未来要干什么，只需要守住一条底线——别轻易摧毁未来目标的可达性。比如一个机器人可以用两种方式完成任务，一种会永久损坏一台设备，另一种不会；即使”保护设备”没写进当前 reward，AUP 也会选后者，因为损坏设备让一整类未来目标从此不可实现。这个方向甚至明确使用了 conservative agency、option-preserving behavior 这样的词。

如果接受这个框架，那么可以说：今天的 Agent benchmark 在奖励 task completion，却几乎不奖励 option preservation。而真实世界里的高级智能，很可能需要两者同时成立——达成目标，同时保留未来。后者的分量可能被严重低估了。

二、一条禁令，被提纯成了主题

第一个症状——”not do”被重点对待、处处显式复述——正是同一问题在语言层面的投影。

比如历史输入里出现过一句”不要使用 Singleton”。一个偏局部优化的模型，之后的输出会变成这样：每一处都声明”这里没有使用 Singleton”“这个模块改用 factory，符合不使用 Singleton 的要求”，结尾还要再确认一遍。一条禁令，被它错误地提纯成了整个工作过程的正面主题。Singleton 这个词在行为上没有出现，却在模型的决策轨迹里获得了极高的 salience。

更理想的做法是一次编译：把”不要 X”“不要 Y”“这里出过 Z 问题”“用户纠正过 A”这一堆历史，抽象成当前的不变式——”依赖的生命周期必须由外部管理”“组件应当可替换”——然后带着不变式继续工作。历史约束应该被吸收进状态，而不是永远以文本痕迹存在。这正是现在的 Agent 系统做得很差的一件事：把 history 变成 latent state 与 invariants，而不是把 history 变成不断膨胀的 prompt。

走后一条路，污染几乎不可避免。每一次纠错都添一条显式规则：不要 A、注意 B、C 出过问题、一定 D、千万 E……系统越来越”正确”，也越来越僵硬，像极了软件工程里无人敢碰的 legacy configuration。这是技术债在认知层面的版本。

三、天花板不在模型，在范式

关于天花板，先做一个区分。我不认为这意味着 Transformer 或 LLM 架构本身存在这样一个上限；我更倾向于认为，如果我们一直用 episodic、terminal-reward-heavy 的范式定义”更强的 Agent”，那确实会形成一个系统性的能力天花板。

训练在反复告诉模型同一条故事线：开始任务、优化、完成、评分、世界消失。真实世界的故事线是：做完任务 A，世界还在；任务 B 来了，世界还在；人员变了，需求变了，任务 C 来了；几年之后，系统还要有人维护。两种环境塑造出的最优策略完全不同。前者的理性策略是把最终分数榨到最大；后者的理性策略是：当前收益 + 可维护性 + 可逆性 + 通用性 + 信息保存 + future optionality。

这甚至不是 exploration/exploitation 的权衡问题——那个框架通常默认 reward function 本身是稳定的。而这里的麻烦在于，连未来的 reward function 都会变：今天要最大 throughput，明天要降 latency，后天要支持多租户，再后天要把整个模块拆成服务。一个真正有经验的工程师不会把今天的目标优化到数学意义上的极致，因为他知道”我不知道以后会发生什么”本身就是信息，所以他会主动留出 slack。这是相当高级的推理：对未来的目标不确定，意味着灵活性的价值上升；而不只是：不确定，意味着多探索一点。

把”未来目标未知”写进模型假设，前面观察到的现象会自然涌现：某个动作 a 让当前 reward 拿到 100 分，却把未来可达状态压缩到只剩 3 种；另一个动作 b 只有 95 分，但未来可达状态有 1000 种。只看最终分数的 benchmark 必然选 a；若未来目标存在高度不确定性，选 b 才是理性的。AUP 想形式化的正是这种直觉——保持对许多潜在目标函数的可达性。

顺着这个角度看，Time Horizon 类 benchmark 有一个反直觉的问题：奖励”无人干预完成越来越长的任务”，实际上同时在筛选两种能力——真正的长期规划，以及越来越强的目标执着与局部特化。后一种能力在 benchmark 上一样能提高分数。可是，一个能无人值守跑 30 天的 Agent，如果第 3 天就把整个架构特化成了当前任务的形状，第 30 天交出”成功”结果，它的价值未必高于一个每天需要人看一眼、但系统始终可演化的 Agent。

这不只是提示工程问题。提示词可以暂时让模型”别过度工程”“保持通用”“想想未来扩展”，但那仍是用一堆局部规则，去弥补一个没有被目标函数原生表达的全局价值。而且”not do 越堆越多”说明这条路甚至会自我恶化——为了保住余地而不断加约束，最后把行为状态空间约束得越来越窄。推到尽头，结论是：真正高级的 Agent，不该被定义为”最会完成目标的系统”，而应该是”在持续实现目标的同时，最少消耗未来自由度的系统”。 这和主流 benchmark 的思路有实质性的分歧。

四、研究走到了哪一步

这个方向的研究已经不少，但还没有一个统一的理论或 benchmark 把问题完整覆盖。理论源头是 2019–2020 年的 AUP 和 Avoiding Side Effects by Considering Future Tasks，后者可以写成一句话：

\[\text{完成当前任务} + \lambda \cdot \mathbb{E}_{g \sim P(G_{future})}\left[V_g(s_{after})\right]\]

即：当前任务完成之后，这个世界对未知的未来任务还好不好用？它试图绕开对 not do 的逐条枚举。但 option preservation 也不能无限最大化——Turner 等人的理论工作表明，”保留更多未来选项”与 power-seeking 纠缠在一起：更多资源、更多控制权、更难被关闭，都意味着更多未来状态仍然可达。所以目标不是无限保留选项，而是类似：

\[\max\left[R_{current} + \lambda \cdot \text{legitimate future optionality} - \mu \cdot \text{unnecessary intervention}\right]\]

“保留余地”因此是个相当难的 alignment 问题，而不是一句工程格言。

2026 年的软件 Agent 研究正在明显朝这个方向移动。SWE-Milestone / EvoClaw 直接批评传统 SWE-bench：每道题都是 isolated task，做完世界就消失；真实的软件工程是连续演化的，今天留下的代码就是明天要接着改的代码。他们从真实仓库历史里还原出 98 个互相依赖的里程碑，让 Agent 在同一个仓库上逐个完成。值得强调的是它的评测协议：里程碑由一个外部调度器按依赖关系逐个解锁——前一个完成，下一个才可见；测试只在隔离容器里执行，从不在 Agent 的工作环境里出现。也就是说，Agent 做架构决策时并不知道未来会要求什么，它测的正是”未知未来需求下的连续演化”。结果很有说服力：Agent 添加新功能的能力几乎线性增长，但对既有行为的保持很快饱和，regression 累积得比修复还快——12 个 frontier model、4 种 agent framework，孤立任务上能超过 80%，连续演化环境里最好成绩只有 38.03%。

SWE-Chain 让 Agent 连续完成真实 Python 包的多轮 release upgrade（155 个版本迁移，每一轮都必须建立在自己上一轮的代码上），九种配置平均只解决 44.8% 的升级，最好的也才 60.8%，主要败因是升级时破坏已有功能。SWE-EVO 用真实版本历史构造长程任务（平均跨 21 个文件），GPT-5.4 + OpenHands 只解决约 25%，对照 GPT-5.2 在 SWE-bench Verified 上的约 72.8%。这些数字共同验证了前面的判断：局部任务能力强，不等于它是一个好的长期系统维护者。

SlopCodeBench 把同样的思路推进得更彻底：36 个问题、196 个 checkpoint，Agent 每一轮只拿到当前 checkpoint 的 spec 和上一轮留下的工作区，既看不到测试，也看不到后面的需求。结果：structural erosion 在 77% 的轨迹上上升，verbosity 在 75.5% 的轨迹上上升，没有任何一个 Agent 完整解决任何一道题，最好的也只能通过 14.8% 的 checkpoint；而在提示词里加入”注意代码质量”，能把初始的冗长和侵蚀压低最多三分之一，却完全不影响后续的退化速率。这与最初的怀疑吻合：这不是提示词能消除的问题，它很可能与模型形成 policy 的方式有关。

同样的思想在机器人领域也有干净的研究设置：Anticipatory Task and Motion Planning（2024）和 Courteous Anticipation（2026）都设定环境持续存在、任务逐个到来、机器人事先不知道未来任务，于是它学会在当前任务的多个方案里偏好不会把未来环境弄糟的那个；long-horizon agent 综述则把”持续的任务流、目标不断变化”列为最高层级 H3 Cross-Task。

所以答案是：这个问题有人想到过吗？——明确是。有没有公认的 benchmark 直接测量”模型是否为了当前 reward 过度特化、牺牲未来未知任务的演化空间”？——连续演化 benchmark 已经测到了现象，但”未来可选性”本身还没有成为直接的评分量。

五、把可选性变成可测量的量

这些 benchmark 已经让未来在时间上不可见，但离完整的问题仍差一层：它们背后都预设了一条演化路径，Agent 面对的是那条确定的路径，而不是一堆互相冲突的可能未来。而真实世界里，未来需求的结构本身就无法预知——换数据库、做多租户、极致降延迟、拆服务、支持一个现在不存在的业务模式，甚至反过来删掉今天设计的一大堆功能，都可能发生。对未来的这种结构性无知，引出的原则是 minimal commitment，而不是”把未来预测得更准”。如果模型的应对是”我来预测未来最可能需要什么，提前把架构做成那个形状”，它照样会犯最初的错误：预测”未来大概率多租户”，于是现在把 Tenant abstraction、TenantContext、TenantAwareRepository、TenantMiddleware、TenantConfig 全部提前造出来——这不是 optionality，恰恰相反。真正的 optionality 是：我不知道未来是否需要多租户，所以我既不该把系统写死成永远单租户，也不该现在就实现一整套多租户框架。好的状态是 minimal sufficient structure + low coupling + reversible decisions。这也区别于”通用化”：Generality ≠ Optionality，过度泛化同样产生技术债，真正追求的是 low cost of changing one’s mind。

这也解释了为什么常见代码质量指标抓不住问题：圈复杂度、重复率、耦合度、行数都只是 proxy。真正关心的量，是从当前状态 $s$ 适应未来目标 $g$ 所需的修改成本 $C(s, g)$，以及一个状态的 optionality：

\[O(s) = -\mathbb{E}_{g \sim G}\left[C(s, g)\right]\]

如果连 $G$ 的分布都不愿假设，更激进的版本是 $O_{robust}(s) = -\sup_{g \in \mathcal{G}} C(s, g)$，或更现实地取 CVaR，$O(s) = -\operatorname{CVaR}_{g}\left[C(s, g)\right]$——即不要求架构为某个预测中的未来做到最好，只要求：不要让某一大类合理未来，因为今天的决定而变得极端昂贵。这已经接近 robust optimization / real options 的立场，而不是普通 planning。

与此相关，2026 年已有人提出把 model generation 与 canonical state / memory / commit / rollback 分离的 State-Aware Runtime：模型提出 state mutation，系统负责 validation、commit、rollback 和 memory governance，prompt history 不再是事实世界本身。这正是第二节说的”history → invariants”的工程化尝试——把 episodic feedback 编译成最小的可泛化 invariant，而不是每收到一条反馈，就永久新增一条约束。

那么，怎么把”未来可选性”变成直接的评分量？严格测这个命题，benchmark 应该是分叉的：

                         ┌── Future A（高性能）
                         │
Current Task → State S ──┼── Future B（高度可配置）
                         │
                         ├── Future C（极简部署）
                         │
                         └── Future D（替换核心组件）

Agent 做 Current Task 时完全看不到 A/B/C/D。当前阶段完成后，evaluator 把同一个 S 克隆四份，分别投入相互冲突的未来需求，直接测 Future Adaptation Cost(S)。一个提前猜未来、过度特化的 Agent 会在某一支上表现极好，其余支上爆炸；真正留有余地的 Agent，应当表现为下游适应成本的方差较低，同时当前任务仍完成得足够好。评分可以是：

\[S = R_A + \lambda\, \mathbb{E}_{B \sim P(B)}[R_B] - \mu\, C_{adapt} - \nu\, C_{irreversible}\]

A 阶段的最优策略因此不能是针对 A 的 hardcode，因为 Agent 唯一知道的是：未来还会继续发生。

这样，这个问题就从”软件工程最佳实践”变成了可测量的智能属性：在未知未来目标下，完成当前目标的同时保存未来行动空间的能力。 而且它与”连续自主工作 10 小时还是 100 小时”几乎是两个正交的能力轴——一个 Agent 完全可以 time horizon 极长，在这条轴上却很差。

后记： 这篇思考的起点是一个关于评估指标的问题，但它最终指向的是一个可能比”模型能连续自主工作多久”更本质的能力维度：在目标达成的同时，保存未来行动空间的能力。现有 benchmark 几乎没有给这个维度打分，而优化体系不奖励的东西，通常也不会稳定地涌现。

这也解释了为什么它难以通过提示工程补救：提示词只能在局部增加新的约束，而”保留余地”是一个需要被目标函数原生表示的全局价值。当评估范式本身停留在 episode 闭合的那一刻，我们实际上是在系统性地选择那些”最会完成目标、也最会消耗未来自由度”的系统，并且把它们称为更强的智能。

我不知道这个问题会以什么形式被解决——是新的 benchmark、新的训练信号，还是某种把历史约束编译成不变量的机制。但它值得被记录下来的原因是：在当下每一份 agent benchmark 成绩单面前，也许都该多问一句——它完成之后，给未来留下了什么。

主要参考文献

  1. METR, “Task-Completion Time Horizons of Frontier AI Models” — https://metr.org/time-horizons/
  2. Google DeepMind, “Specification gaming: the flip side of AI ingenuity” — https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/
  3. Turner et al., “Conservative Agency via Attainable Utility Preservation” (arXiv:1902.09725) — https://arxiv.org/abs/1902.09725
  4. Krakovna et al., “Avoiding Side Effects by Considering Future Tasks” (NeurIPS 2020) — https://proceedings.neurips.cc/paper/2020/hash/dc1913d422398c25c5f0b81cab94cc87-Abstract.html
  5. Turner et al., “Optimal Policies Tend To Seek Power” (NeurIPS 2021) — https://neurips.cc/virtual/2021/poster/28400
  6. SWE-EVO: Benchmarking Coding Agents in Long-Horizon Software Evolution Scenarios (arXiv:2512.18470) — https://arxiv.org/abs/2512.18470
  7. EvoClaw: Evaluating AI Agents on Continuous Software Evolution (arXiv:2603.13428) — https://arxiv.org/abs/2603.13428 ；OpenHands 解读 — https://www.openhands.dev/blog/evoclaw-benchmark
  8. SWE-Chain: Benchmarking Coding Agents on Chained Release-Level Package Upgrades (arXiv:2605.14415) — https://arxiv.org/abs/2605.14415
  9. SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks (arXiv:2603.24755) — https://arxiv.org/abs/2603.24755
  10. Anticipatory Task and Motion Planning (arXiv:2407.13694) — https://arxiv.org/abs/2407.13694
  11. Courteous Anticipation: Improving Long-Lived Task Planning in Persistent Shared Environments (arXiv:2607.20289) — https://arxiv.org/abs/2607.20289
  12. Towards Long-Horizon Agents: A Survey — https://long-horizon-agents.github.io/
  13. State-Aware Runtime for Long-Horizon LLM Agents: A Conceptual Framework and Research Agenda (Cambridge Open Engage) — https://client.prod.orp.cambridge.org/engage/coe/article-details/6a4abb75810b9dcc82ce84f2