研究结论已经开始分层了

如果把时间拉回到两年前，讨论“大模型还有没有提升空间”通常很抽象，争论点要么落在参数规模，要么落在一句很宽泛的“推理能力还会继续增强”。到 2026 年 4 月，这个问题已经可以讲得更具体一些了。过去一年里，很多原本只存在于论文和 demo 里的能力，已经被主流产品做成了用户可感知的功能，比如更长的思考过程、内置工具调用、更大的上下文窗口、轻量级记忆，以及能够完成一段工作流的基础 Agent。

也正因为这些能力已经开始产品化，很多人会自然得出一个判断：剩下的进步大概只会是边际优化，像手机芯片那样一年快一点、便宜一点、稳一点。这个判断并不准确。更值得看的，是研究界和一线产品团队现在反复碰到的那些硬边界。它们已经足够明确，足以告诉我们下一阶段的增量会从哪里冒出来；但它们又还没有被主流产品稳定做成默认能力。

Mermaid 图：2026 年仍未做完的六块能力底盘

这篇文章要回答的，是三件更具体的事。

  • 到目前为止，哪些方向已经基本被产品层吃掉了。
  • 哪些方向仍然存在清晰的 headroom，而且论文结论和一线团队观点还没有过期。
  • 如果把这些缺口翻译成产品语言，未来 12 到 24 个月最可能长出来的 feature 会是什么。

现在已经做出来的，其实比很多人印象里更多

先把基线说清楚很重要。今天再去讲“更长上下文”“会调用工具”“会想更久”“会记住一点偏好”这些能力，已经不能算真正的下一代猜想了。它们当然仍然在进步，但大方向已经进入产品层。

OpenAI 在 2026 年 3 月发布 GPT-5.4 时，已经把 1M 级上下文、原生 computer use、长输出和多步工具工作流写进主力模型叙事里。Anthropic 和 Google 在过去一年里也把长思考、外部工具、多模态输入、不同力度的 Agent 编排放进了各自的主线产品。换句话说，主流玩家已经证明了一件事：用户愿意为“模型不只会答题，还能完成一段工作”付费。

真正的问题因此发生了变化。现在大家已经默认模型会多想一会儿，分歧转到了“额外这段思考到底被花在了哪里”；对记忆也是一样，讨论重点已经变成“什么该写入，什么该遗忘，什么该因为安全原因暂时不让它记”。这一层变化很关键，因为它把问题从“有没有这个 feature”推进到了“feature 背后的系统底盘是否成立”。

第一件事：推理预算的分配，远没有产品化完成

微软 2025 年那篇关于 inference-time scaling 的研究，到现在依然是理解下一阶段 headroom 的核心入口。它最有价值的地方不在于又一次证明“多一点计算能带来更好成绩”，而在于把问题翻译成了系统设计语言：同样的额外预算，落在不同搜索策略、不同 verifier、不同反馈机制上，收益完全不一样。

这个结论到现在依然成立，甚至比一年前更重要。因为主流产品已经普遍引入了思考模式，用户也已经默认模型会在后台跑一段更长的 reasoning。接下来真正稀缺的，是把隐藏思考变成有效预算路由的能力。

  • 什么时候值得继续想，而不是立刻回答。
  • 什么时候应该并行分支搜索，而不是沿着一条错误路径越走越深。
  • 什么时候该调用 verifier、测试环境或外部工具来校准方向。
  • 什么时候该停下来，避免把更多 token 浪费在已经跑偏的轨迹上。

Anthropic 在 2025 年关于 test-time compute 的文章里给了一个很重要的反例：额外算力并不总是提升性能，有些场景里甚至会出现“想得更久、结果更差”的反向缩放。这件事的意义很直接。它说明今天主流产品里已经出现的 extended thinking，只是把“可分配的预算”开放了出来，还没有把“怎样正确花预算”这个更难的问题解决掉。

如果把这个缺口翻译成未来 feature，最值得盯的不是更高的 max_thinking_tokens，而是几种更具体的能力：动态预算路由、题型感知的分支搜索、结果不确定时自动升级验证强度，以及在低价值任务上快速收敛的成本控制。谁先把这些能力做稳，谁就有机会把“同样一份底模”做出更高一代的体验。

第二件事：Verifier 仍然是把上限变成稳定收益的关键缺口

今天很多产品已经会“自我检查”，但这和研究里说的 verifier-first 还差得很远。主流产品里的自检，很多时候仍然是再让另一个模型看一眼，或者让同一个模型换个语气重写一遍。它可以减少一部分低级错误，却很难把复杂任务里的额外算力稳定转成成功率。

微软那篇报告最耐人寻味的结论之一，是所有模型在更强 verifier 或更强反馈下都还能继续上升。这其实是在提醒我们：前沿模型当前暴露出来的上限，不一定是“模型本体的最终上限”，更可能是“当前运行时系统还没有把验证层做厚”的阶段性上限。

这块缺口为什么到现在还没有被真正吃透，原因也很现实。

  • 真正有用的 verifier 通常依赖结构化环境，而不是一段自然语言评语。
  • 不同任务需要不同类型的 verifier，代码、数学、检索、表格分析和浏览器操作都不一样。
  • verifier 本身也有成本，会拖慢交互，并且可能被错误输入误导。

所以下一步更像会出现分层 verifier 栈，未必会是统一的“超强评审模型”。例如，代码任务更多靠测试与执行环境，研究任务更多靠引用检查和证据一致性，浏览器任务更多靠状态机与页面断言，办公任务更多靠结构化结果校验。主流产品今天已经把工具调用做出来了，但把验证层做成默认 runtime，还明显没有完成。

第三件事：记忆已经上桌，但持续学习还远没上桌

“模型有记忆”这件事，现在已经不新鲜了；真正还很新的，是“模型能不能长期学会新东西，而且不把自己学坏”。Google Research 在 2025 年提出 Nested Learning 时，点得很直白：当前大模型的知识更新，仍然主要依赖预训练时的静态知识和会话期的临时上下文，距离稳定的 continual learning 还有明显距离。

这一判断到 2026 年 4 月并没有失效，反而更容易从产品层得到印证。OpenAI 的 ChatGPT agent system card 直接写明，agent 在上线时默认关闭 memory，原因不是产品团队没想到，而是 prompt injection、敏感数据外泄和跨任务污染的风险都还太高。换句话说，行业已经承认记忆很重要，却还没有把这块底盘打磨到足够放心的程度。

这里最值得区分的是三层完全不同的能力。

  • 会话记忆：记住这一次对话里刚发生的事情。
  • 项目记忆：记住一个任务、一个代码库、一个客户上下文里的长期状态。
  • 持续学习：从新经验里沉淀新技能，并在后续任务中真正调用出来。

今天的主流产品，大多已经进入前两层的早期阶段，距离第三层还很远。真正难的地方不只是“多存一点”，而是建立整套写入、压缩、检索、合并、遗忘和权限控制机制。没有遗忘机制的记忆只会越来越脏，没有权限边界的记忆则根本不敢开。

这意味着未来一段时间里，最可能落地的 feature 不会直接叫“continual learning”。更可能的产品形态是：项目级持久记忆、结构化用户偏好档案、任务结束后的 memory distillation、团队共享记忆库、可回滚的记忆写入日志，以及对敏感上下文的更细粒度隔离。

第四件事：长时程 Agent 的真正难点，是恢复能力而不是第一步行动

Agent 产品现在已经不稀缺，真正稀缺的是能稳定跑长任务的 runtime。很多演示都能让模型完成一次网页操作、一次数据整理、一次简单编程，但一旦任务长度从几分钟拉到半小时、两小时，问题就开始不是“会不会用工具”，而是“会不会在长链路里保持目标、发现偏航、在失败后恢复”。

这块能力到现在还没有被主流产品完全实现，从公开系统卡里也能看出来。OpenAI 的 Operator 和 ChatGPT agent system card 都反复强调 watch mode、用户确认、网络限制和高风险操作保护。这些设计当然是安全需要，但它们同时也说明，今天的主流 Agent 仍然主要依赖外层护栏，而不是内生的长时程稳定性。

长时程 runtime 还没做完，通常会暴露在四个地方。

  • 任务跑到中段后丢失原目标，把局部子问题误当成总目标。
  • 工具失败以后只会重试，不会回滚，不会换路径，也不会降级策略。
  • 中间状态越积越多，却没有 checkpoint，导致上下文污染和决策漂移。
  • 不知道什么时候该把任务交还给人，或者把问题拆给另一个更适合的工具链。

所以这一层的 headroom，更像操作系统问题而不是聊天机器人问题。接下来值得盯的 feature 也会更像 runtime 组件：checkpoint / resume、失败恢复策略、任务状态图、分层 planner、handoff 协议，以及更细粒度的人工接管点。它们看起来不如“更聪明的模型”性感，但更可能决定真正能不能把 Agent 放进生产。

第五件事：长上下文已经普及，长上下文里的工作记忆还没有

上下文窗口变大，已经不是新闻；长上下文里还能不能稳定推理，仍然是新闻。OpenAI 在 GPT-5.4 发布页给出的结果本身就说明了这一点。模型在较短上下文区间表现已经非常强，但到了 256K 到 1M 这样的长区间，某些长程图任务和多轮检索任务的成绩仍然会明显下滑。

这个信号非常重要，因为它提示了一个常被忽略的事实：大窗口不等于大工作记忆。把一大堆材料全部塞进上下文，更像把文件全摊在桌上；而真正困难的能力，是模型能不能在这么多材料里建立一套稳定的中间表示，知道哪些细节应该保留，哪些应该压缩成摘要，哪些应该在后续步骤里被重新取回。

今天大多数产品在这层上的做法，仍然偏向“给更大窗口 + 做一点检索增强”。它们当然有用，但距离真正的长上下文工作记忆还差三步。

  • 第一，结构化压缩：不是简单总结，而是按任务维度保留可复用中间结论。
  • 第二，层级检索：不是全文回捞，而是按问题阶段取回不同粒度的信息。
  • 第三，再推理：取回信息之后，还要能把前面已经形成的中间判断重新接起来。

如果这三步没有连起来，1M 上下文更像一个昂贵的仓库，而不是一个高效的工作台。未来更有价值的 feature 因此不会只是更大的窗口数字，而是项目级摘要树、自动 context compaction、问题驱动的 retrieval plan，以及能跨多轮会话维持中间结论的 working memory 层。

第六件事：推理可见性依然很弱，监控层还在早期

很多产品已经会展示计划、解释步骤，甚至会在界面上用很像“思考过程”的方式呈现 reasoning trace。但研究界过去一年给出的提醒非常一致：这些 trace 很有用，却不能被简单当成模型真实推理的完整镜像。

OpenAI 在 2025 年关于 frontier reasoning models 的监控文章里强调，chain-of-thought monitoring 是值得投入的方向，但如果优化方式不当，模型也可能学会把真正意图藏到看不见的地方。Anthropic 在 2025 年的技术安全研究方向总结里，也把 faithful CoT 和 activation monitoring 继续列为关键但尚未成熟的方向。

这块缺口之所以重要，不只是因为安全。它直接关系到下一代 Agent 系统能不能被调试、被审计、被企业信任。一个能长期执行任务却无法解释关键决策来源的系统，组织很难放心把更高权限交给它。

因此，这里真正未完成的，是建立多层监控面，而不只是让模型多写一点解释。

  • 自然语言 trace：便于人理解，但不应被神化。
  • execution trace：记录调用了哪些工具、访问了哪些资源、在哪一步失败。
  • verifier transcript：记录哪些外部证据真正改变了决策。
  • activation-level signal：在自然语言表述之外，再增加一层内部状态监控。

这类 feature 现在已经能看到原型，但还没有被主流产品做成稳定、默认、可配置的通用能力。它一旦成熟，意义会非常大，因为它会把“我相信这个 Agent”变成“我能审计这个 Agent”。

把六个缺口翻译成产品语言，下一阶段更像这些 feature

如果不再用“4.8、5.5、7.5”这类版本感来想问题，而是直接看产品能力树，未来 12 到 24 个月最可能被做出来的 feature，已经能看得比较清楚。

  • 动态推理预算：根据任务价值、失败代价和不确定性自动调整思考强度。
  • 任务专用 verifier：代码、检索、浏览器、表格和文档分析各有不同验证器。
  • 项目级持久记忆：从“记住一句偏好”走向“记住一个任务状态机”。
  • checkpoint 与恢复：长任务中断后能够回到上一个稳定状态，而不是从头再来。
  • context compaction：把超长上下文压成可复用的工作记忆，而不是一次性大杂烩。
  • 可审计 reasoning runtime：让 trace、工具调用和验证证据被统一记录。

这些 feature 里，有的看起来像模型能力，有的看起来像平台能力，有的更像安全能力。真正值得注意的地方恰恰在这里。下一代体验很可能不会来自某一个单独技术点，而是来自模型、runtime、memory、verifier 和 monitoring 同时往前推一小步，最后合成出一个明显更强的系统。

最后更值得问的，是哪种底盘会先成熟

到 2026 年 4 月，再去问 Agent 和大模型还有没有提升空间，答案其实已经相当明确：当然有，而且不是一点点。只不过这类提升已经不太像过去那种“加大底模、重跑训练、重新刷榜”的单轴增长了。更大的增量，正在迁移到系统底盘。

谁先把额外算力分配得更聪明，谁就能把“想更久”变成真正更强；谁先把 verifier 做进 runtime，谁就能把额外预算变成稳定收益；谁先把 memory、checkpoint、working memory 和 monitoring 做厚，谁就更有机会把今天的 Agent 从“能演示”推进到“能长期交付”。

所以这篇文章最后想留下的判断很简单。当前主流产品已经把第一层能力上桌了，但真正决定下一阶段代际差距的，仍然是那六块还没做完的底盘。接下来最值得看的，是哪家公司先把这些底盘里的两三块接成一套真正可规模化运行的系统，而不是又多发明一个宣传词。