作者注：本文纯技术文章，已剔除战略相关讨论，原文在个人知识库成型后发内网，现重新发外网。不涉及内容搬运。

先给结论

这篇文章真正想表达的，不是“上下文很重要”这样一句泛泛的空话。

更强一点的判断是：

大模型时代的竞争，正在从“谁的模型更强”，转向“谁能持续构造更高质量的 belief state”。

如果这个判断成立，那么很多今天看起来分散的问题，其实会突然连成一条线：

• 为什么同一个模型，换一个产品壳，效果能差这么多
• 为什么很多 agent 的问题，不是不会回答，而是越做越偏
• 为什么上下文窗口越来越大，系统却没有线性变强
• 为什么 skill、memory、retrieval、tool use、trace、summary 这些看起来零散的工程模块，会突然一起变重要

因为这些东西，本质上都在服务同一件事：

不是让模型“看到更多”，而是让系统“更稳定地理解当前局面”。

这就是我理解的“下半场是上下文”。

更准确一点说，不是 prompt，不是单轮输入，也不是简单的聊天历史。而是系统围绕 context → belief state → action 这条链，建立起来的一整套外部认知基础设施。

简单说，belief state 就是系统在信息不完整时，对当前局面的内部估计。它不是世界本身，而是系统此刻对外部世界的综合判断：基于当前观测、过去历史、已执行动作、经验和先验知识，形成一个“我认为现在大概是这样”的状态表达。

一、Agent 更像外部化认知系统，而不只是会调工具的 LLM

如果只把 agent 理解成“一个会调用工具的 LLM”，很多现象解释不通。

因为工具调用只是表面能力，真正的问题是：

• 什么时候该搜
• 搜回来什么该保留
• 哪些结果只是噪声
• 哪些历史应该压缩
• 哪些信息应该被长期记住
• 当前该围绕哪个假设继续推进

这些问题都不属于“语言生成”本身。

它们更接近一个认知系统在做的事：

• 感知
• 记忆
• 状态估计
• 动作选择
• 反馈修正

所以现代 agent 不是“更强的聊天机器人”，而是一种把工作记忆、检索、规则、工具和执行反馈外部化之后的认知系统。

这件事很关键。

因为它意味着：模型本身不再独自承担“理解世界”的任务，系统开始替它承担越来越多的状态管理工作。

换句话说，agent 的“智能”已经不是纯参数内生的，而是越来越多地来自外部系统对上下文和状态的组织方式。

二、下半场不是模型战，而是 belief state 战

“下半场是上下文”如果只停在 slogan 层，价值不大。真正有价值的是再推进一步：

上下文之所以重要，不是因为它是模型的输入，而是因为它是 belief state 的主要载体。

这两个说法差别非常大。

如果把上下文理解成“模型输入”，优化方向通常会变成：

• prompt 写得更精致一点
• 规则写得更全一点
• 检索多塞一点材料进去
• 窗口大了就多塞一些历史

但如果把上下文理解成“belief state 的表达载体”，问题就完全变了。

这时真正该关心的是：

• 当前 belief 是不是对的
• belief 是不是被噪声污染了
• 哪些信息在帮助 belief 更新，哪些信息在拖累 belief
• 系统有没有把 memory、retrieval、tool result 转成稳定的状态判断
• 当 belief 错了，系统能不能及时纠偏

也就是说，真正该被优化的，不是上下文容量，而是 belief state 质量。

接下来 agent 系统最重要的评价维度，未必是谁调用工具更多、谁上下文更长，而是：

谁能在更长任务链、更复杂环境、更高噪声条件下，持续维持一个不太漂的 belief state。

三、为什么最先吃到 AI 红利的，常常是内容与开发类工作

这两类工作之所以更早、更明显地感受到 AI 带来的生产力提升，不只是因为模型“擅长写东西和写代码”。

更底层的原因是：它们的工作上下文更容易被数字化，belief state 也更容易被系统构出来。

内容工作通常围绕：

• 选题
• 素材
• 历史文章
• 语气风格
• 平台约束
• 标题和封面策略
• 用户反馈数据

开发工作通常围绕：

• 代码
• 日志
• 报错
• 文档
• git 历史
• 测试结果
• 配置文件
• 工具输出

这些信息天然就是文本化、结构化或半结构化的，很容易被组织成上下文。

所以问题并不是这些工作更简单，而是它们的任务现场更容易被系统完整感知。

进一步说，AI 能不能深入一个岗位，关键未必只是模型能力再涨多少，而是：

这个岗位的关键上下文，能否被充分数字化、结构化，并被系统持续转译成高质量的 belief state。

四、Chatbot 到 Agent 的真正变化，不是“会做事”，而是“要维持状态”

很多人会说，chatbot 和 agent 的区别在于：

• chatbot 只会说
• agent 会做

这话不算错，但还不够本质。

更本质的区别是：

chatbot 主要是在单轮语义映射里求最优；agent 则是在多步状态演化里求稳定。

前者的核心问题是表达。后者的核心问题是状态。

在 chatbot 阶段，系统主要围绕一段对话工作：

• 用户输入
• 历史消息
• system prompt
• 输出回答

这个阶段的上下文，本质上还是短时、对话型、隐式的上下文。

但到了 agent 阶段，系统开始面对这样的任务：

• 搜代码
• 查文档
• 调 API
• 执行命令
• 修改文件
• 根据结果继续推进

这个时候，系统必须维护的已经不是“上一轮说了什么”，而是：

• 当前目标
• 已知事实
• 已失败路径
• 当前假设
• 下一步验证方向
• 当前风险约束

也就是说，chatbot 和 agent 的分界线，不是“会不会调工具”，而是：

系统是否开始显式维护任务状态。

一旦任务状态变成核心，上下文就不再只是聊天记录，而变成任务的外部工作记忆。

五、为什么 POMDP 框架特别适合解释 Agent

POMDP 的关键不在公式，而在一个非常朴素的事实：

你永远看不到完整世界，只能根据局部证据猜当前局面，然后行动，再根据反馈修正。

这几乎就是今天 agent 的日常工作方式。

用户给你的从来不是完整需求。日志给你的从来不是真实根因。代码片段给你的从来不是完整架构。网页快照给你的从来不是整个系统状态。

因此，agent 一开始面对的，不是“世界本身”，而是一些局部观测：

• 用户消息
• 文件片段
• 工具结果
• 接口返回
• 日志和报错

它必须基于这些局部信号，形成一个“当前我认为事情大概是怎样”的内部判断，再决定下一步动作。

这就是 belief state。

可以把现代 agent 映射成下面这条链：

• o_t = 用户输入 / 文件片段 / 日志 / 工具结果
• b_t = U(b_{t-1}, o_t)
• a_t = π(b_t)
• s_{t+1} ~ T(s_t, a_t)

翻成白话就是：

• 系统先拿到新的局部观测 o_t
• 再用它去更新当前对局面的估计 b_t
• 再基于这个估计选择动作 a_t
• 动作改变环境，环境进入下一状态 s_{t+1}

这里最关键的是中间两个式子：

• b_t = U(b_{t-1}, o_t)
• a_t = π(b_t)

前者说明 belief state 不是凭空产生的，而是由上一轮判断加上这一轮新观测共同更新出来的。后者说明系统下一步到底是回答、搜索、读文件、调接口还是执行修改，取决的不是原始输入本身，而是当前 belief state。

所以，上下文工程真正做的事，本质上是在实现这个更新函数 U。

六、Belief State 不是术语，而是 Agent 的真正工作对象

Belief state 最简洁的定义可以是：

系统在信息不完整时，对当前局面的内部估计。

它在工程里并不抽象，一个 agent 当前的 belief state，通常体现在：

• 当前任务描述
• 已确认事实
• 当前假设与优先级
• 中间工具结果
• 阶段性摘要
• 下一步计划
• 风险与约束信息

换句话说，belief state 并不是一个隐藏在模型脑内的玄学对象。它在现实系统里，往往就是：

被组织进当前上下文里的那一份“任务局面判断”。

这里最重要的分界线是：

• memory 不是 belief state
• context 也不是 belief state
• world model 更不是 belief state

它们只是 belief state 的不同原料或载体。

可以用一条链来理解：

world model + observations + memory → belief state → context → action

真正直接驱动动作的，不是 memory，不是 prompt，也不是规则本身。 而是系统当前综合这些信息之后形成的局面判断。

七、检索增强真正改善的，不是知识，而是观测条件

RAG 经常被描述成“给模型外挂知识库”。这个描述对入门没问题，但对 agent 已经不够用了。

因为在 agent 场景里，检索的真正作用不是“补一点知识”，而是：

在当前观测不足时，主动改善系统对局面的感知条件。

如果把检索理解成知识补全，重点往往会放在：

• 知识库全不全
• embedding 强不强
• 召回多不多

但如果把检索理解成观测增强，重点就会变成：

• 当前任务最缺哪类证据
• 什么观测最能缩小问题空间
• 什么检索结果会污染当前判断
• 哪类证据应该直接入上下文，哪类只保索引不保正文

也就是说，检索系统不是一个“静态知识入口”，而更像一个主动采样观测的模块。

系统不是为了“知道得更多”而检索，而是为了“猜得更准”而检索。

八、Context Rot 最值得警惕的，不是窗口不够，而是 belief 被污染

Context Rot 这个概念很重要，因为它直接戳穿了一个常见误区：

上下文更长，不等于系统更强。

很多人以为窗口越来越大，系统就会越来越接近“记住一切”。但现实恰恰相反。

在很多真实任务里，随着上下文不断增长，系统会出现：

• 准确率下降
• 关键信息遗漏
• 噪声干扰加重
• 推理链条断裂
• 历史阶段混淆
• 简单任务还能做，复杂任务先劣化

如果只把这理解成“注意力机制不够强”，还是太浅。

更合理的理解是：

系统在长任务里，逐步失去对“当前局面”的清晰判断，belief state 被噪声、冗余和历史残留慢慢污染。

一旦这么看，解决方向就会完全不一样。

重点不再是“怎么塞更多 token”，而是：

• 怎么做阶段性摘要
• 怎么卸载大工具输出
• 怎么把正文变成状态而不是原文堆积
• 怎么把历史从上下文里挪到 memory 里
• 怎么在需要时再检索回原始证据
• 怎么检测 belief 是否开始漂移

所以 Context Rot 真正证明的不是窗口不够大，而是：

上下文的核心问题从来不是容量，而是 purity。

九、很多 Agent 不是不会做事，而是在漂移地做事

很多 agent 的问题，并不是不能行动。恰恰相反，它们往往很积极：

• 会搜
• 会读
• 会调工具
• 会写计划
• 会给解释

但问题在于，它们经常在一个已经偏掉的 belief 上持续行动。

也就是说，它不是不会做事，而是在错误的局面判断上，越来越高效地做事。

这能解释很多常见现象：

1. “失忆”未必是没记住，而是当前 belief 没拿到关键支撑

比如：

• 信息掉出了上下文
• 历史摘要压丢了关键细节
• memory 召回没命中
• 系统没触发回查

这时候看起来像失忆，本质上是当前 belief 缺了必要证据。

2. “越做越偏”通常是错误 belief 驱动错误探索

比如根因明明在后端 session，但系统早期误判成前端路由问题，于是后续搜索、阅读、验证全都围绕错误子空间展开。

这不是简单的推理失败，而是错误 belief 驱动错误动作分配。

3. “工具很多但效果一般”说明工具没有被纳入 belief update 回路

工具本质上只是观测通道和动作通道。如果系统不会：

• 选择恰当时机调用
• 正确解释结果
• 把结果压缩进当前状态判断
• 避免结果污染上下文

那么工具越多，只会让 belief 更乱。

plan / reflection 为什么有用？因为它们本质上都在做同一件事：

显式整理 belief state。

它们在不断帮助系统回答：

• 当前已知什么
• 当前未知什么
• 哪些假设已经失效
• 下一步应该验证什么

所以 plan / reflection 的真正价值，不是“更像人在思考”，而是“降低 belief state 漂移”。

十、接下来上下文系统会沿着五条主线演化

1. Memory 会从统一存储走向分层架构

长期 memory 很难由一种存储形态解决。更现实的方向是分层：

• L0 In-Context：当前窗口里的热状态
• L1 Session Cache：跨轮次短期记忆与阶段性结论
• L2 Episodic Store：可语义检索的历史经历
• L3 Semantic Store：偏好、事实、实体关系等结构化知识
• L4 Procedural Store：skill、rule、行为模板等程序性记忆

memory 的核心问题不再是“存没存”，而是：

哪一类信息应该以哪一种时间尺度和结构形态被保存。

2. Memory 会从自然语言摘要走向结构化状态资产

未来高价值 memory 很可能越来越不是自然语言 bullet，而是带有：

• 实体
• 关系
• 时间戳
• 来源
• 置信度

的结构化状态记录。

真正难的不是“把东西写下来”，而是：

• 以后还能不能稳定召回
• 不同来源会不会冲突
• 时间变化后会不会 semantic drift
• belief 更新时能不能有优先级依据

3. Skill 会从提示词文档走向能力注册表

skill 体系接下来会发生一个变化：

skill 不再只是说明书，而会变成可注册、可调度、可追踪的能力单元。

这意味着 skill 需要的不只是自然语言描述，还需要更明确的能力声明，比如：

• 触发条件
• 所需上下文
• 输出契约
• 成本估计
• 降级策略

本质上，这是在把 skill 从“文本资产”升级成“系统能力资产”。

4. Context 会从预注入走向 Just-in-Time Loading

过去的思路是：任务开始时尽可能多塞信息。未来更合理的方向是：

• 先暴露摘要和索引
• 再让 agent 基于当前 belief 判断要不要加载详细上下文
• 上下文选择权从系统硬编码，逐步转给 agent 的动态决策

这不是一个小优化，而是一种范式切换：

context 从静态输入，变成动态装配。

5. 可观测性会从辅助调试，变成上下文系统的基础设施

如果 belief state 真的成为系统核心对象，那么未来调试 agent 的重点也会变化。

不再只是看最终回答对不对，而是要看：

• 当前 context 由哪些部分组成
• skill 为什么被加载
• memory 什么时候被读出、什么时候被写入
• belief 在多轮之间有没有漂移
• 哪一段工具输出开始污染当前判断

没有这类可观测性，就没有可靠的 agent 工程。 因为上下文一旦不可见，belief 一旦不可见，系统基本就退回黑盒状态了

十一、真正的分水岭，不是谁更像人，而是谁更像一个 Context OS

如果把前面的判断再压缩一下，未来 agent 的分水岭，可能不是：

• 谁写作更像人
• 谁回答更流畅
• 谁窗口更长
• 谁接了更多工具

真正的分水岭，更可能是：

谁更像一个稳定运行的 Context OS。

这里的 Context OS，不是一个营销概念，而是一个很具体的系统判断。它至少意味着：

• 能持续获取高价值观测
• 能维护分层 memory
• 能动态装配上下文
• 能隔离噪声与冗余
• 能检测 belief 漂移
• 能在错误状态下回滚与纠偏
• 能把长期历史沉淀成可复用状态资产

这时候，系统的竞争焦点就已经从“模型有多聪明”，转向“系统能不能长期不漂”。

在这套分工里：

• 模型负责局部推理与动作生成
• 检索负责补观测
• memory 负责跨时间保存
• context 负责当前表达
• belief state 负责当前判断
• agent runtime 负责把这些东西组织成可持续执行的闭环

十二、一个更现实的判断：很多场景的瓶颈，正在从模型能力转向上下文工程能力

这个判断不是“模型不重要”，更不是“底座模型可以不做”。更准确的说法应该是：

在很多真实业务场景里，继续单纯追求模型能力提升，未必总是最优解；很多时候，更直接的瓶颈已经变成：

• 拿不到足够有效的上下文
• 无法把历史信息压缩成高质量状态
• 检索、memory、tool result 无法稳定汇成 belief state
• context rot 在长任务里持续污染判断
• 不同产品或流程之间没有形成统一的上下文基础设施

从 ROI 角度看，一个很值得认真面对的问题是：

在很多具体场景里，把上下文工程做好、把 belief state 质量做高，带来的质量提升和落地收益，可能比继续堆模型更直接，也更可兑现。

因为模型投入通常有几个天然特征：

• 投入重
• 周期长
• 结果不完全可控
• 与外部 frontier model 的差距未必容易快速拉开

而上下文工程和 belief state 基础设施的投入，往往有另一组特征：

• 更贴近具体业务问题
• 更容易形成明确的质量闭环
• 更容易观察到真实 ROI
• 一旦沉淀下来，可以横向复用到多个业务场景

从这个角度看，上下文系统不只是一个工程优化项，它很可能本身就是业务壁垒的一部分。

十三、结语

如果只把全文压缩成一句话，就是：

AI 的下半场，不是上下文更长，而是 belief state 更稳。

这句话之所以重要，是因为它把讨论重心从“模型能做什么”，推到了“系统能不能长期不漂”。

上下文本身不是目标。上下文只是载体。真正要被维护的，是系统对当前局面的那份判断质量。

谁能更稳定地构造、维持、修正这份判断，谁就更可能做出下一代真正可用的 agent；谁不能把这件事做成工程能力，谁的模型优势也很可能在真实业务里被快速耗散掉。

如果这个判断成立，那么未来 agent 系统最核心的工程问题，就不再只是模型接入、prompt 优化或工具扩展，而会变成：

如何把 belief state 的构造，做成一套显式、可观测、可治理、可持续演化的系统基础设施。

我觉得，这才是“AI 的下半场是上下文”这句话背后真正的战略含义。