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步的任务上下文长度很容易膨胀到原来的数倍。这导致两个后果后期决策质量下降模型在任务后期宝贵的上下文窗口被前期大量的“Thought”和“Observation”占据用于理解当前状况和进行深度推理的空间被严重挤压。长上下文模型的依赖与成本为了运行长任务不得不依赖GPT-4-128K、Claude-200K等支持超长上下文窗口的模型推理成本极高。而许多优秀的开源模型如Llama系列的上下文长度有限无法胜任此类长序列任务。因此无论是SFT、RL还是ReAct在应对长周期、多步骤的智能体任务时都共同面临一个基础架构性的挑战如何打破对原始行动历史的直接、完整依赖我们需要一种机制让智能体学会“忘记”无关细节“记住”核心状态。这正是“恒定上下文技能学习”要解决的核心问题。3. 恒定上下文的核心构建动态的任务状态表示要实现“恒定上下文”关键在于设计一个智能体的“工作记忆”系统。这个系统不再存储原始的历史对话而是维护一个动态更新的、高度压缩的“任务状态表示”。这个状态表示就是智能体对“我现在在哪、完成了什么、接下来要干什么”的认知摘要。3.1 状态表示的设计原则一个有效的状态表示应该具备以下几个特性信息密度高用远少于原始历史的Token数承载对决策最关键的信息。例如将十步的表单填写操作抽象为“用户个人信息部分3/5完成公司信息部分0/2完成”。与决策相关状态中的每一项信息都应能直接或间接地影响下一步的行动选择。无关的环境细节如每次API调用的完整响应头不应包含在内。结构化与可更新状态最好能被表示为结构化的数据如键值对、列表、或特定的JSON Schema以便于程序化地读取和更新。当智能体执行一个行动并得到观察结果后应有一套规则或一个学习到的模块来更新这个状态。具有泛化能力同一种状态表示应能适用于同一类任务的不同具体实例。例如“用户已登录”这个状态无论登录过程是通过邮箱密码、手机验证码还是第三方授权其对于后续“访问个人资料”这个决策的意义是相同的。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”。在这个范式下每一步的循环变为状态感知智能体接收当前的状态表示S_t由状态管理器维护。推理基于S_t模型进行思考Thought规划下一步。行动模型输出行动A_t。观察环境执行行动返回原始观察O_t。状态更新状态管理器根据(S_t, A_t, O_t)利用规则或学习到的方法生成新的状态表示S_{t1}。这个更新过程可以是一个简单的函数调用也可以是一个轻量级模型的推理。循环将S_{t1}作为下一轮的输入。关键变化上下文窗口中不再需要存储整个历史轨迹。我们只需要存储可能一个简短的任务初始描述。当前的状态表示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 实现状态管理器状态管理器负责从原始观察中更新这个状态。我们采用规则与简单学习结合的方式页面识别规则解析当前页面标题或关键元素如是否存在id“register-form”来判定current_page。表单字段解析规则启发式从可访问性树中定位表单输入框。通过检查元素的value属性是否非空更新filled字段。通过查找输入框附近的错误提示元素通常有特定的CSS类如.error-text提取文本更新error字段。阶段判断规则根据current_page、form_fields的完成度以及是否有成功提示信息来判断registration_stage。结果解析轻量学习last_action_result的更新可以稍微复杂。对于click、navigate成功与否较易判断页面是否跳转。对于type和submit可能需要一个微调过的小型文本分类模型或prompt一个轻量LLM来分析动作执行后返回的观察文本判断是“成功”还是包含某种错误如“用户名已存在”。这个分类器可以先用规则生成一些种子数据再通过少量标注数据微调得到。5.4 收集数据与状态驱动的SFT录制专家轨迹人工或通过脚本操作完成10-20次成功的注册流程记录下每一步的(原始观察, 动作)对。离线生成状态序列使用我们实现的状态管理器离线处理所有专家轨迹。对于轨迹中的每一步输入上一步的状态和本步的动作原始观察输出本步更新后的状态。这样就得到了一个(S_t, A_t)配对的数据集。注意S_t是执行动作A_t之前的状态。微调模型使用这个(S_t, A_t)数据集对一个基础LLM如ChatGLM3-6B, Qwen1.5-7B进行监督微调。训练时将状态S_t以结构化的文本描述如“当前状态页面在‘register’注册阶段为‘form_filling’用户名已填写无错误邮箱未填写...”的形式作为输入要求模型输出下一步的动作指令A_t。部署与运行部署微调好的模型和状态管理器。在运行时状态管理器初始化状态S_0。将S_0输入策略模型得到动作A_0。执行A_0获得原始观察O_0。状态管理器根据(S_0, A_0, O_0)更新状态为S_1。循环直至任务完成状态显示registration_stage: “completed”。5.5 避坑指南与实操心得状态设计的迭代性第一次设计的状态几乎肯定是不完备的。在测试智能体时你会发现它因为缺少某个关键状态信息而做出错误决策。这时就需要回头修改状态表示增加新的字段。这是一个“开发状态表示 - 测试智能体 - 发现信息缺失 - 扩充状态表示”的迭代过程。状态更新器的可靠性至关重要如果状态更新器出错比如错误地判断了页面或字段状态那么智能体基于错误的状态做出的决策必然是错的。因此状态更新器的规则需要非常鲁棒能处理各种边界情况如网络延迟导致的页面加载不全、弹窗遮挡等。对基于学习的部分需要准备足够多样性的数据来训练。平衡状态的信息量与复杂度状态不是越详细越好。我们的目标是包含充分且必要的信息。如果一个信息项从未影响过任何决策它就是冗余的。可以尝试在训练后分析模型的注意力机制看它关注了状态描述中的哪些部分来辅助精简状态。与长上下文模型的结合即使采用了恒定上下文策略在任务最开始你可能仍需要将任务的初始指令“请注册一个论坛账号”和状态一起输入模型。这个指令是固定的很短。整个交互过程模型只需要处理“固定指令 当前状态恒定长度”的上下文效率极高。处理异常与恢复智能体可能遇到未知状态。需要在架构中设计兜底策略例如当状态管理器无法解析页面时可以生成一个“未知”状态并让策略模型输出一个探索性动作如“点击页面最显眼的按钮”或“刷新页面”而不是僵住。通过这个实战构想你可以看到“恒定上下文技能学习”并非一个遥不可及的理论而是一套可以逐步实施的工程框架。它通过引入“状态”这一抽象层将智能体从记忆历史的重负中解放出来使其能够专注于基于当前形势的决策从而更可靠、更高效地完成复杂长程任务。这或许是让LLM智能体从玩具走向真正生产力工具的关键一步。