LLM智能体恒定上下文技能学习：从状态表示到工程实践

1. 从历史到状态：为什么LLM智能体需要“恒定上下文”技能学习？

如果你最近在关注大语言模型智能体领域，可能会发现一个有趣的现象：大家似乎都在忙着给智能体“打补丁”。无论是通过监督微调让智能体学会使用特定工具，还是用强化学习让它从错误中学习，目标都是让一个通用的语言模型变成一个能执行复杂、多步骤任务的“智能执行者”。但当你真正把这些方法应用到实际场景——比如让一个智能体去操作一个电商后台，或者管理一套云服务器——很快就会遇到一个根本性的瓶颈：上下文窗口的诅咒。

想象一下，你正在训练一个新手员工。传统的方法就像让他反复阅读一本厚厚的操作手册（SFT），或者让他在实际工作中不断试错，你只在他犯错时给予反馈（RL）。这两种方法都有个前提：员工能记住所有过去的操作步骤和反馈。但现实是，人的工作记忆是有限的。当任务链变得很长，涉及几十个步骤时，他很可能忘了第一步为什么那么做，或者中途某个关键的反馈是什么。LLM智能体面临的正是这个问题，它的“工作记忆”就是其有限的上下文窗口。ReAct这类框架要求智能体在每一步都输出“思考、行动、观察”，这些历史记录会不断累积并塞进上下文。几个回合下来，宝贵的上下文窗口就被冗长的历史对话占满了，真正用于理解当前状态、做出新决策的空间所剩无几。

这就是标题“From History to State”所直指的核心痛点。我们不能再让智能体仅仅依赖原始的、未经处理的行动历史记录（History）来做决策。我们需要教会它，如何从这些庞杂的历史中，提炼、压缩、抽象出一个对当前决策真正有用的“状态表示”（State）。这个状态应该像是一个经验丰富的老员工脑中的“战况图”：它不记录每一步操作的具体日志，但清晰地标明了“我们已经完成了用户身份验证”、“购物车里有三件待结算商品”、“支付网关的API上次调用返回了超时”。“恒定上下文技能学习”的目标，就是让智能体学会构建和利用这个“战况图”，使得无论任务历史多长，用于决策的“有效信息”所占用的上下文长度是相对恒定和可控的。

这不仅仅是工程上的优化，更是智能体能力范式的转变。它意味着智能体的技能学习，从简单地记忆动作序列，升级为学习如何感知和建模任务进程。相关热词中频繁出现的SFT、RL、ReAct，都是实现这一目标的可能路径，但都需要被重新审视和改造，以服务于“状态提炼”这个新目标。接下来，我们将深入拆解，如何让一个LLM智能体真正学会“读懂”自己的历史，并基于精炼的状态做出明智的下一步。

2. 技能学习的传统路径：SFT与RL在智能体场景中的局限与挑战

在讨论新范式之前，我们必须先理解现有工具的边界。监督微调和强化学习是赋予大模型能力的两种经典方法，但在应用于LLM智能体进行长序列任务时，它们各自暴露出了严重的缺陷。

2.1 监督微调：模仿的困境与历史依赖

SFT的本质是行为克隆。我们收集专家（或另一个高级模型）在特定任务上的一系列操作轨迹（Thought, Action, Observation），然后用这些轨迹数据对基础LLM进行微调，期望它能模仿专家的行为模式。

这种方法在短平快的任务上效果显著。例如，热词中提到的“React面试题”或“Vue和React区别”这类问答，SFT可以让模型快速掌握标准的回答格式和内容要点。然而，一旦任务变为一个长流程的智能体操作，比如“使用React框架开发一个前端应用并部署到Node.js后端”，SFT的短板就暴露无遗。

首先，是历史信息的冗余与干扰。一条完整的任务轨迹可能包含上百个交互轮次。在SFT的训练数据中，模型在预测第t步的行动时，输入的是前t-1步的全部历史。模型被迫去学习这些冗长历史中与当前决策真正相关的微弱信号，这极其低效。更糟糕的是，不同的历史片段可能导致相同的下一步行动（例如，无论之前点击了多少个菜单，最终“点击提交按钮”这个动作可能只依赖于“所有必填字段已填充”这一状态），但SFT却要费力地学习所有这些不同的历史到同一动作的映射。

其次，缺乏泛化与状态理解。SFT训练出的模型，更像是一个“历史模式匹配器”。它没有学会理解“状态”。当遇到一个与训练历史相似但不完全相同的状态时（比如，某个表单字段的验证提示信息换了一种说法），模型可能因为匹配不到熟悉的“历史模式”而失效。它没有抽象出“字段验证通过”这一核心状态概念。

最后，复合错误的累积。在长任务中，智能体一旦在某步偏离了专家轨迹，后续的历史就与训练数据完全不同了。一个仅通过SFT训练的智能体，由于没有学会如何从“偏离轨道”的历史中恢复，很容易在一步错之后步步错，导致完全失败。它缺乏对任务进程的鲁棒性理解。

2.2 强化学习：稀疏奖励与信用分配难题

RL通过奖励信号来塑造智能体的行为，理论上能探索出超越专家示范的更优策略。在智能体场景中，奖励通常只在任务最终成功或失败时给出（稀疏奖励），例如“成功部署”得+1，“部署失败”得-1。

其核心挑战在于“信用分配”：如何将最终的成功或失败，归因到长达数十上百个具体行动中的某一个上？哪个行动是关键性的？哪个是无关紧要的？传统的RL算法在如此长的行动序列和巨大的行动空间（自然语言）面前，几乎无法有效学习。

探索成本高昂是另一个现实问题。让一个LLM智能体在真实环境（如生产服务器）中通过试错来学习部署，代价是不可接受的。即使是在模拟器中，生成一个包含思考、行动、观察的完整轨迹也需要多次调用大模型，计算成本巨大。

部分热词如“Agentic RL”反映了一种思路：设计更密集、更细致的奖励函数，或者让LLM自身参与奖励信号的生成（例如，让LLM判断当前子目标是否达成）。这在一定程度上缓解了稀疏奖励问题，但依然没有解决最根本的“历史冗长”问题。RL的决策点（Policy）在每一步仍然需要处理不断增长的历史序列，计算负担和训练不稳定性随着轨迹增长而急剧上升。

2.3 ReAct框架：连接思想与行动，但加剧了上下文压力

ReAct框架之所以流行，是因为它巧妙地结合了推理（Reasoning）和行动（Acting），让LLM的“思考过程”变得可观测、可引导。这对于提升智能体行为的可靠性和可解释性至关重要。

然而，ReAct在长任务中恰恰是**“恒定上下文”需求的反面教材**。它的标准模式要求每一步都将“Thought: ... Action: ... Observation: ...”的完整三元组追加到上下文中。一个20步的任务，上下文长度很容易膨胀到原来的数倍。这导致两个后果：

1. 后期决策质量下降：模型在任务后期，宝贵的上下文窗口被前期大量的“Thought”和“Observation”占据，用于理解当前状况和进行深度推理的空间被严重挤压。
2. 长上下文模型的依赖与成本：为了运行长任务，不得不依赖GPT-4-128K、Claude-200K等支持超长上下文窗口的模型，推理成本极高。而许多优秀的开源模型（如Llama系列）的上下文长度有限，无法胜任此类长序列任务。

因此，无论是SFT、RL还是ReAct，在应对长周期、多步骤的智能体任务时，都共同面临一个基础架构性的挑战：如何打破对原始行动历史的直接、完整依赖？我们需要一种机制，让智能体学会“忘记”无关细节，“记住”核心状态。这正是“恒定上下文技能学习”要解决的核心问题。

3. 恒定上下文的核心：构建动态的任务状态表示

要实现“恒定上下文”，关键在于设计一个智能体的“工作记忆”系统。这个系统不再存储原始的历史对话，而是维护一个动态更新的、高度压缩的“任务状态表示”。这个状态表示，就是智能体对“我现在在哪、完成了什么、接下来要干什么”的认知摘要。

3.1 状态表示的设计原则

一个有效的状态表示应该具备以下几个特性：

1. 信息密度高：用远少于原始历史的Token数，承载对决策最关键的信息。例如，将十步的表单填写操作，抽象为“用户个人信息部分（3/5完成），公司信息部分（0/2完成）”。
2. 与决策相关：状态中的每一项信息都应能直接或间接地影响下一步的行动选择。无关的环境细节（如每次API调用的完整响应头）不应包含在内。
3. 结构化与可更新：状态最好能被表示为结构化的数据（如键值对、列表、或特定的JSON Schema），以便于程序化地读取和更新。当智能体执行一个行动并得到观察结果后，应有一套规则或一个学习到的模块来更新这个状态。
4. 具有泛化能力：同一种状态表示，应能适用于同一类任务的不同具体实例。例如，“用户已登录”这个状态，无论登录过程是通过邮箱密码、手机验证码还是第三方授权，其对于后续“访问个人资料”这个决策的意义是相同的。

3.2 实现状态提炼的两种技术路径

如何让智能体学会从历史中提炼出这样的状态呢？目前主要有两种互补的思路：

路径一：基于规则或启发式的状态提取器这是更工程化、可控性强的方案。由开发者预先定义好，对于特定领域（如网页操作、CLI命令、API调用），哪些观察结果需要被提取并转化为状态。

• 示例（网页自动化）：定义一个解析器，从网页的HTML或可访问性树中提取关键元素：当前页面标题、主要的表单字段及其填充状态、出现的按钮文本、错误提示信息等。将这些信息结构化后，作为当前状态。
• 示例（CLI操作）：解析命令输出，提取关键信息行、退出码、当前工作目录、环境变量变化等。
• 优点：精确、高效、可预测。状态更新逻辑清晰，不依赖额外训练。
• 缺点：需要大量领域知识，泛化能力差。每个新任务类型都需要重新设计提取器，无法适应未知或复杂多变的观察结果。

路径二：基于学习的状态生成器这是更通用、更有潜力的方向。训练一个额外的模型（可以是一个小的神经网络，也可以是另一个LLM），其职责就是“阅读”最新的行动和观察，并输出对任务状态的更新描述。

• 如何训练：这本身可以看作一个序列到序列的学习任务。输入是上一轮的状态和本轮的（Action, Observation），输出是更新后的状态。训练数据可以通过多种方式获得：
  • 从专家轨迹中推导：给定专家的长轨迹，反推出在每一步，专家决策所依赖的最小核心状态是什么。这需要标注，成本较高。
  • 通过逆强化学习：不直接定义状态，而是定义“状态应能使策略（即智能体）做出正确决策”。通过优化策略在给定状态下的表现，同时优化状态生成器，使其产生的状态能最大程度地帮助策略学习。
  • 自监督学习：利用下一个观察或最终任务成功与否作为监督信号，要求状态表示能够预测未来或结果。一个好的状态应该蕴含预测未来所需的信息。
• 优点：泛化能力强，可以适应新的、未见过的观察类型。能自动发现对决策有用的特征。
• 缺点：训练复杂，需要数据，且生成的“状态”可能难以被人直观理解（黑盒问题）。

在实际系统中，常常混合使用这两种路径。例如，用规则提取器处理结构化的、低层级的观察（如API返回码、数据库查询结果），用学习生成器处理非结构化的、高层的观察（如一段自然语言描述的任务进展汇报）。

4. 融合状态表示的技能学习新范式

当我们为智能体装备了“状态表示”这个能力后，传统的SFT和RL训练方式就可以被重构，从而突破它们原有的局限。

4.1 状态驱动的监督微调

在新的训练范式下，我们不再用冗长的原始历史轨迹(H_1, A_1, O_1, H_2, A_2, O_2, ...)来微调模型。取而代之的是状态-动作对(S_t, A_t)。

• 数据准备：对于每一条专家轨迹，我们使用状态提取器/生成器，为每一步生成对应的状态表示S_t。S_t包含了到当前步骤为止所有历史的精炼摘要。
• 训练目标：训练模型学习一个策略π(A_t | S_t)。即，给定当前的任务状态，模型应能输出专家在该状态下会执行的动作。
• 优势：
  • 样本效率高：模型直接学习状态到动作的映射，避免了在冗长历史中寻找模式的困难。
  • 泛化能力强：只要状态S_t相同，即使导致这个状态的历史路径不同，模型也能做出正确决策。它学会了基于“现状”决策，而不是机械地复现“过去”。
  • 减轻复合错误：即使智能体在实际运行时偏离了路径，只要状态生成器能根据新的观察更新出正确的状态S_t‘，策略模型仍然有可能根据S_t‘做出合理的动作，从而有机会回到正轨。

4.2 状态驱动的强化学习

在RL框架中引入状态表示，能极大地改善信用分配和探索效率问题。

• 状态作为RL的观察空间：在RL的环境定义中，智能体每一步接收到的“观察”（Observation）不再是原始的O_t，而是更新后的状态表示S_t。状态空间S的大小远小于原始历史空间，这显著降低了RL问题的复杂度。
• 价值函数与策略基于状态：我们需要学习的价值函数V(S)或Q(S, A)以及策略π(A|S)都基于状态S。这使得评估一个状态的价值、或者评估在某个状态下某个动作的价值，变得可行。
• 更有效的信用分配：由于状态S是历史的摘要，最终的成功奖励可以更合理地反向传播到导致关键状态转移的那些动作上。例如，从“用户未登录”状态转移到“用户已登录”状态的动作，其价值会得到显著提升。
• 与“Agentic RL”结合：我们可以设计基于状态的、更密集的奖励。例如，当状态显示“完成了部署流程的配置阶段”时，给予一个中间奖励。这需要领域知识，但比设计基于原始历史的奖励要直观得多。

4.3 重构ReAct：状态增强的推理与行动

我们也可以将状态表示融入ReAct框架，创造出一种更高效的范式。我称之为“State-ReAct”。

在这个范式下，每一步的循环变为：

1. 状态感知：智能体接收当前的状态表示S_t（由状态管理器维护）。
2. 推理：基于S_t，模型进行思考（Thought），规划下一步。
3. 行动：模型输出行动A_t。
4. 观察：环境执行行动，返回原始观察O_t。
5. 状态更新：状态管理器根据(S_t, A_t, O_t)，利用规则或学习到的方法，生成新的状态表示S_{t+1}。这个更新过程可以是一个简单的函数调用，也可以是一个轻量级模型的推理。
6. 循环：将S_{t+1}作为下一轮的输入。

关键变化：上下文窗口中不再需要存储整个历史轨迹。我们只需要存储：

• 可能一个简短的任务初始描述。
• 当前的状态表示S_t（长度恒定且较短）。
• 模型最新的“思考”过程（可选，为了可解释性）。

这样，无论任务进行到第10步还是第100步，输入模型的上下文长度都保持相对恒定。这使得我们能够利用更强大、但上下文窗口有限的模型（如一些优秀的开源模型）来执行长任务，成本大幅降低，且后期决策质量不会因上下文冗杂而衰减。

5. 实战构建：一个简易恒定上下文网页操作智能体

理论需要实践来验证。让我们构想一个简化但完整的例子：构建一个能自动完成“在某个论坛注册账号”任务的智能体。我们将采用混合路径（规则+学习）来构建状态，并应用状态驱动的SFT进行训练。

5.1 任务定义与环境设置

• 任务：在一个模拟的论坛网站（例如一个本地运行的测试页面）上，完成从打开首页到成功注册的全流程。
• 动作空间：click(element_id),type(text, element_id),navigate(url),submit(form_id)等。
• 观察空间：当前页面的可访问性树（包含元素ID、类型、值、状态等）以及上一步动作的执行结果（成功/失败/错误信息）。

5.2 设计状态表示

我们为这个“论坛注册”任务设计一个结构化的状态表示，采用JSON格式：

{ “current_page”: “home | login | register | confirmation”, “logged_in”: false, “registration_stage”: “not_started | form_filling | email_sent | completed”, “form_fields”: { “username”: {“filled”: false, “value”: “”, “error”: null}, “email”: {“filled”: false, “value”: “”, “error”: null}, “password”: {“filled”: false, “value”: “”, “error”: null}, “agree_terms”: {“checked”: false} }, “last_action_result”: “success | fail:error_message” }

这个状态大约在200-300个token，远小于存储多轮原始HTML和动作的上下文。

5.3 实现状态管理器

状态管理器负责从原始观察中更新这个状态。我们采用规则与简单学习结合的方式：

1. 页面识别（规则）：解析当前页面标题或关键元素（如是否存在id=“register-form”），来判定current_page。
2. 表单字段解析（规则+启发式）：从可访问性树中定位表单输入框。通过检查元素的value属性是否非空，更新filled字段。通过查找输入框附近的错误提示元素（通常有特定的CSS类，如.error-text），提取文本更新error字段。
3. 阶段判断（规则）：根据current_page、form_fields的完成度以及是否有成功提示信息，来判断registration_stage。
4. 结果解析（轻量学习）：last_action_result的更新可以稍微复杂。对于click、navigate，成功与否较易判断（页面是否跳转）。对于type和submit，可能需要一个微调过的小型文本分类模型（或prompt一个轻量LLM），来分析动作执行后返回的观察文本，判断是“成功”还是包含某种错误（如“用户名已存在”）。这个分类器可以先用规则生成一些种子数据，再通过少量标注数据微调得到。

5.4 收集数据与状态驱动的SFT

1. 录制专家轨迹：人工或通过脚本，操作完成10-20次成功的注册流程，记录下每一步的(原始观察, 动作)对。
2. 离线生成状态序列：使用我们实现的状态管理器，离线处理所有专家轨迹。对于轨迹中的每一步，输入上一步的状态和本步的（动作，原始观察），输出本步更新后的状态。这样就得到了一个(S_t, A_t)配对的数据集。注意，S_t是执行动作A_t之前的状态。
3. 微调模型：使用这个(S_t, A_t)数据集，对一个基础LLM（如ChatGLM3-6B, Qwen1.5-7B）进行监督微调。训练时，将状态S_t以结构化的文本描述（如“当前状态：页面在‘register’，注册阶段为‘form_filling’，用户名已填写无错误，邮箱未填写...”）的形式作为输入，要求模型输出下一步的动作指令A_t。
4. 部署与运行：部署微调好的模型和状态管理器。在运行时：
   • 状态管理器初始化状态S_0。
   • 将S_0输入策略模型，得到动作A_0。
   • 执行A_0，获得原始观察O_0。
   • 状态管理器根据(S_0, A_0, O_0)更新状态为S_1。
   • 循环直至任务完成（状态显示registration_stage: “completed”）。

5.5 避坑指南与实操心得

• 状态设计的迭代性：第一次设计的状态几乎肯定是不完备的。在测试智能体时，你会发现它因为缺少某个关键状态信息而做出错误决策。这时就需要回头修改状态表示，增加新的字段。这是一个“开发状态表示 -> 测试智能体 -> 发现信息缺失 -> 扩充状态表示”的迭代过程。
• 状态更新器的可靠性至关重要：如果状态更新器出错，比如错误地判断了页面或字段状态，那么智能体基于错误的状态做出的决策必然是错的。因此，状态更新器的规则需要非常鲁棒，能处理各种边界情况（如网络延迟导致的页面加载不全、弹窗遮挡等）。对基于学习的部分，需要准备足够多样性的数据来训练。
• 平衡状态的信息量与复杂度：状态不是越详细越好。我们的目标是包含充分且必要的信息。如果一个信息项从未影响过任何决策，它就是冗余的。可以尝试在训练后，分析模型的注意力机制，看它关注了状态描述中的哪些部分，来辅助精简状态。
• 与长上下文模型的结合：即使采用了恒定上下文策略，在任务最开始，你可能仍需要将任务的初始指令（“请注册一个论坛账号”）和状态一起输入模型。这个指令是固定的，很短。整个交互过程，模型只需要处理“固定指令 + 当前状态（恒定长度）”的上下文，效率极高。
• 处理异常与恢复：智能体可能遇到未知状态。需要在架构中设计兜底策略，例如当状态管理器无法解析页面时，可以生成一个“未知”状态，并让策略模型输出一个探索性动作（如“点击页面最显眼的按钮”或“刷新页面”），而不是僵住。

通过这个实战构想，你可以看到，“恒定上下文技能学习”并非一个遥不可及的理论，而是一套可以逐步实施的工程框架。它通过引入“状态”这一抽象层，将智能体从记忆历史的重负中解放出来，使其能够专注于基于当前形势的决策，从而更可靠、更高效地完成复杂长程任务。这或许是让LLM智能体从玩具走向真正生产力工具的关键一步。