SKILL.state：用显式执行状态替代对话历史，降低智能体长任务成本

这篇论文不是又发了一个新模型而是想改掉智能体系统里一个越来越贵的设计不断增长的对话历史。Google 提出的 SKILL.state核心是用显式执行状态替代越攒越长的上下文让智能体在长任务、多轮工具调用、复杂规划场景下不再靠“重读一遍历史”来维持状态。如果你在做 AI Agent、自动化工作流、工具调用型应用或者只是被长上下文烧 token 烧到心疼这篇可以直接收藏。要理解 SKILL.state 的定位先得看清现在智能体系统的瓶颈在哪。当前主流 Agent 架构高度依赖大模型的上下文窗口每一轮推理、每一次工具调用结果、每一步中间思考都会追加进对话历史。为了不让模型“失忆”系统会把越来越多的文本塞进 prompt。问题随之而来——token 成本线性甚至超线性上升、首字延迟变大、长上下文中的注意力被稀释模型对关键信息的敏感度反而下降。SKILL.state 的思路是与其让模型每次都从庞大历史中推测“我现在执行到哪一步”不如由执行系统显式维护一份当前状态模型只需要读状态不再依赖整段历史。这相当于把 Agent 的“记忆”从文本上下文迁移到结构化程序状态里。这篇文章会从五个角度展开先用表格快速过一遍这论文的关键信息然后拆解对话历史为什么会成为 Agent 系统的瓶颈再分析 SKILL.state 的显式执行状态具体解决什么问题接着把它和摘要压缩、向量检索、上下文裁剪这类常见方案做对比最后给出一套可落地的验证思路和工程建议方便你在自己的 Agent 项目里测试“状态替换历史”的效果。1. 核心信息速览信息项说明论文名称SKILL.stateGoogle 新提出的智能体执行状态方案核心问题智能体对话历史不断增长导致 token 开销、延迟、注意力质量下降核心改动用显式执行状态替代对话历史模型不再依赖完整历史推断当前状态涉及技术智能体架构、显式状态管理、上下文压缩、工具调用、执行规划面向对象智能体开发者、RAG 应用工程师、Agent 框架使用者主要收益降低上下文开销、提高状态恢复能力、提升长流程任务稳定性待确认项论文原文中的实验数据、具体网络结构、效果量化指标需以原文为准从已有资料看它并不像多数论文那样直接发布一个新模型而是提出一种架构层面的优化思路。这意味着它的意义不在于“单点能力变强”而在于改变 Agent 在长任务中的状态管理方式。实际效果如何还需要等论文全文公开后做对照测试。2. 智能体对话历史为什么要被优化现在几乎所有 Agent 系统都建立在同一个假设上大模型需要完整的上下文才能知道下一步该做什么。于是对话历史成为 Agent 的“记忆体”。用户输入、模型思考、工具返回、执行结果、错误信息、中间修正……这些内容全部按时间顺序写入历史。任务越复杂历史越长。这里有一个深层问题历史不是结构化的它只是一串线性文本。模型需要从中自行“定位”关键信息。当历史长度超过一定阈值后模型的 attention 会被分散在大量低价值文本上真正的关键约束反而被淹没。多轮工具调用场景尤其明显第 10 轮还在重复读取第 2 轮的中间输出这种低效不仅浪费 token还会导致执行逻辑漂移。成本角度更直接。在 API 调用场景上下文越长单轮调用费用越高在本地推理场景KV Cache 占用显存随历史长度上升导致推理速度下降甚至可能超出显存限制。对话历史是一个持续累积的资源消耗项任务越长浪费越夸张。另一个常被忽视的问题是状态恢复。智能体一旦因为网络问题、工具告警或上下文被裁剪而中断系统很难从历史中快速定位“执行到哪一步了”。更糟的是如果采用“把最近几轮历史截断”这种粗暴策略Agent 可能丢失关键任务约束然后继续执行错误操作。这些问题的根源是一致的对话历史承担了它本不该承担的状态管理职责。SKILL.state 的提出正是瞄准这个痛点。它的主张是建立一个“显式执行状态”由智能体执行系统实时维护当前任务状态模型在每轮推理时读取这个状态而不是重新阅读全部历史。这个思路如果成立Agent 的上下文使用方式会发生结构性变化。3. SKILL.state 的核心思路显式执行状态替代对话历史先从名字拆解。SKILL.state 强调“执行状态”不是说完全删除对话历史而是让历史文本不再承担“状态推导”的功能。传统 Agent 中模型要通过大量历史文本推断“我当前在哪里”SKILL.state 则把“当前在哪里”变成一个可读取、可更新的结构化数据。一个合理的实现方式是把执行过程拆成多个状态字段例如当前任务目标、已完成步骤、当前所处阶段、最近的工具调用结果、待处理事项、环境快照、约束条件。每一轮执行结束后Agent 执行框架更新这些字段下一轮开始时模型只读一份紧凑的状态信息而不是重读完整对话历史。说明以下代码只是用于说明“显式执行状态”与“对话历史”差异的伪代码示例不是论文给出的正式实现。实际方案需要以论文原文和具体框架为准。# 传统 Agent 的上下文构造方式不断追加历史 conversation_history [] conversation_history.append({role: user, content: 请帮我订一张明天去上海的机票}) # 每轮工具调用后追加结果... # 历史越来越长模型每轮都要重新读懂全部历史 # SKILL.state 思路维护一个结构化执行状态 execution_state { task_goal: 订明天去上海的机票, completed_steps: [确认出行日期, 查询航班列表], current_stage: 选择航班, latest_tool_result: {航班数: 5, 价格范围: 800-1200}, constraints: [出发地北京, 时间明早 9 点前到达], } # 每轮推理时只需要将结构化状态注入上下文 # 不需要把过去 10 轮工具输出全部塞进 prompt prompt build_prompt(user_input, execution_state)这种设计带来的变化是巨大的。第一prompt 长度不再随着任务轮数线性增长每轮推理的 token 开销趋于稳定。第二模型拿到的是经过执行框架整理过的关键状态而不是原始文本堆叠推理质量理论上更稳定。第三执行中断后系统可以从状态快照恢复而不需要扫描历史重新定位。需要特别指出的是显式执行状态不是凭空维护的它需要任务规划模块、工具调用模块、状态更新模块协同工作。不同的任务类型状态字段差异很大。例如数据处理任务状态可能需要记录“已清洗字段、处理进度、输出模式”而对话类任务则需要记录“用户偏好、已确认信息、待澄清问题”。这意味着 SKILL.state 需要一个可以适配多种任务的状态抽象层这也是工程实现上最有挑战的部分。当然显式状态也有代价状态 schema 设计不当时可能会丢失历史文本中的细节。比如用户在第 3 轮提到的一个偏好如果状态系统没有记录到后续就无法感知。因此 SKILL.state 更可能采取“状态为主、历史按需加载”的混合模式——正常情况下只读状态发现状态信息不足时再回溯指定的历史片段。4. 与主流方案的横向对比在 SKILL.state 之前行业里已经有很多缓解对话历史膨胀的方法但它们的处理方式都停留在“文本上下文”这个维度上。这里把它们和 SKILL.state 做一组对比。方案处理方式优点局限历史截断只保留最近 N 轮历史实现简单token 开销直接下降容易丢失关键信息任务约束可能被截断历史摘要每轮压缩为摘要文本保留全局语义长度可控摘要有信息损失长任务下摘要本身也会变长向量检索构建历史向量库按需检索相关片段支持超长历史保留细节需要检索模块召回质量影响效果仍有额外存储和延迟RAG 外置记忆把关键信息写入外部数据库场景定制能力强需要设计记忆 schema与执行流程绑定较深SKILL.state用结构化执行状态替代历史推断跳出“文本上下文”状态稳定、开销低、恢复快需要设计通用状态抽象细节信息可能丢失这里最关键的区别在于前面的方案都是在“文本里节省空间”而 SKILL.state 是“让文本不再是唯一状态载体”。可以这样理解历史截断与摘要在做“压缩”向量检索在做“选择”而显式执行状态在做“数据建模”。在 Agent 执行中模型并不需要“所有历史”它只需要“当前状态”和“下一步可操作的信息”。SKILL.state 精准地满足这一需求用机械化的状态更新代替概率性的历史理解。这也是为什么它更适用于长流程、多工具、需要可靠恢复的任务而不是短对话、一次性问答这类简单场景。不过也要客观看待一点状态建模很难做到通用。摘要和检索方案不需要定义任务语义任何文本都能处理显式状态则需要为每类任务设计状态结构。这是它的工程门槛也是它相对“重”的地方。5. 适合应用的智能体场景SKILL.state 不是所有 Agent 场景都需要但对以下三类场景价值最大。第一类是多轮工具调用型 Agent。比如一个 Agent 需要依次调用搜索、数据库查询、API 请求、数据加工等多个工具才能完成一个任务。在这个过程中每一步的中间结果都会是下一步执行的依据。传统方式会把所有工具返回都写入对话历史导致模型每次都要重新阅读大量结构化数据。显式执行状态则可以直接维护“当前数据结果、已调用的工具、待执行的下一步”模型只读状态即可决策。第二类是长周期任务型 Agent。比如一个系统需要持续几小时甚至几天的自动化监控与任务执行。每一轮日志都写进上下文显然不现实。用 SKILL.state 思路可以把执行进度、异常记录、当前配置写成持久化的状态文件每一轮只加载状态配合按需加载日志片段就能把上下文开销控制在稳定水平。第三类是高可靠性要求的企业级 Agent。财务审批、内容审核、运维巡检这类场景要求每一步可追溯、可恢复。显式执行状态天然适合做“断点续跑”系统崩溃后从状态快照恢复而不是靠模型从历史中重新理解执行到哪一步。反过来说不适用场景也很清晰单轮问答、短对话、一次性文本生成这些任务本身历史很短引入状态管理反而增加复杂度。对这类轻量场景保持简单的对话历史反而是正确选择。需要强调一点无论使用哪种状态管理方式只要 Agent 涉及用户隐私数据、版权内容或敏感操作都必须保证数据流向的透明度建立授权机制避免将数据在无授权情况下用于模型训练或第三方接口调用。6. 验证路径与实验设计建议SKILL.state 属于架构方案类论文真正的价值要看它在真实任务上的表现。如果你打算在自己的 Agent 项目里验证这个思路可以按下面这个流程设计实验。这套验证路径不需要完整复现 Google 的实验重点是检验“显式执行状态”到底能不能比“长历史”更稳定、更省资源。建议使用一个小规模但包含多轮工具调用的任务集例如让 Agent 完成“从多个数据源收集信息经过清洗、合并后输出报告”这类流程型任务。// 任务配置示例用于对比对话历史方案与显式执行状态方案 { task: 查询三个数据源并生成对比报告, tools: [search, database, content_generator], max_steps: 10, context_strategy: [full_history, state_based], metrics: [task_success_rate, avg_token_per_step, total_latency, state_recovery_score] }可以围绕几个维度做对照实验。成功率同样的任务分别跑“完整历史”和“显式状态”两种策略统计任务完成率。关注长任务场景下完整历史策略是否出现执行漂移状态策略是否更稳定。token 消耗记录每轮实际发送给模型的 token 数对比两种方案在相同任务上的总 token 消耗。预期状态方案明显更低但这需要实测确认。延迟从用户输入到 Agent 输出最终结果的端到端时间观察状态方案能否通过减少输入长度来降低首字延迟。状态恢复能力在任务中途模拟一次中断然后分别从历史文本和状态快照恢复对比恢复到正确执行点的速度和准确度。如果你已经使用主流 Agent 框架可以考虑在框架的“状态”或“记忆”模块中做替换实验而不是从头搭建。实现时可以先定义一个简单的状态类每轮执行后更新状态并持久化到 JSON 文件或数据库然后让每轮 prompt 只注入状态内容。# 一个最简单的状态增量更新示例用于说明工程实现思路 class SimpleStateStore: def __init__(self, state_schema): self.state state_schema def update(self, key, value): self.state[key] value self._persist() def snapshot(self): return json.dumps(self.state, ensure_asciiFalse) def _persist(self): with open(state_snapshot.json, w, encodingutf-8) as f: json.dump(self.state, f, ensure_asciiFalse)实验之前先想清楚一个关键问题状态字段如何设计。状态字段覆盖的信息越多模型越不需要读历史但字段设计过复杂状态维护本身会成为新的负担。最好的做法是先针对一个固定任务类型设计一组最小状态字段验证基本收益后再迭代扩展。7. 工程落地会遇到的挑战SKILL.state 听起来很清爽但真正落地时会面临不少现实问题。写出来供大家提前设防。第一个挑战是状态 schema 的通用性问题。不同任务的执行状态千差万别数据库任务需要记录 schema、查询条件和结果集代码生成任务需要记录文件结构、依赖关系和当前报错客服 Agent 需要记录用户意图、订单状态和历史交互。要设计一套既能覆盖各种任务又不会被“抽象到没有信息量”的状态模型难度很高。更现实的做法可能是按任务类型定义多套状态模板并设计一个状态管理器来切换模板。第二个挑战是状态与历史的一致性问题。显式状态来源于历史但一旦状态更新出现遗漏后续执行就会基于不完整的信息继续行动。举个典型场景用户在对话中临时补充了一个要求状态系统如果只记录了“用户新增要求”却漏掉了“这条要求与之前某条约束冲突”模型就可能在不知情的情况下继续执行。这种遗漏在传统对话历史方案中相对少见因为模型至少能自己回溯历史。第三个挑战是模型对“描述性状态”的适应问题。当前大模型经过海量文本预训练已经非常擅长从对话上下文中自动提取当前状态。突然改成只看一份紧凑的 JSON 状态后模型是否能同样准确地理解任务目标和下一步动作仍然需要评估。某些依赖上下文细节做推理的模型可能在状态方案下表现下降。第四个挑战是状态膨胀。如果不加控制状态本身也可能越写越多。例如工具返回结果全部存入状态状态会变成另一个“小历史”。因此 SKILL.state 要求状态是结构化的、去冗余的、按需更新的状态里只保留影响下一步执行的信息。这个“少而精”的度需要在实践中反复调。工程上还容易踩一个坑状态快照的存储与恢复。任务中断后从快照恢复是 SKILL.state 的重要卖点但如果状态快照没有版本管理或者写入时序混乱恢复时反而可能回到错误的执行点。建议为每个状态快照记录版本号、时间戳和依赖的输入数据版本保证状态可回滚、可追溯。8. 给智能体开发者的实操建议如果你看完上面的分析想立刻在自己的 Agent 项目里试试“显式执行状态”的思路我给你几条可执行的建议并不需要一开始就完全照搬论文的复杂设计。先从一个中等复杂度的 Agent 任务开始跑通状态替换的最小子集。选一个包含 5 到 10 步工具调用的任务手动定义状态字段把每轮推理的 prompt 从“完整历史”替换为“状态信息 最近一轮用户输入”。先不用考虑复杂的状态管理器只用一个 Python dict 或 JSON 文件保存状态观察两个关键指标token 消耗和任务成功率是否改善。如果 token 消耗明显下降、成功率没有下降说明这条路径值得继续投入。然后再逐步完善状态结构增加状态校验、增加状态异常标记、增加历史按需回溯接口。比如当工具执行异常时状态中记录一个error字段当模型判断需要更多细节时再从历史库中检索相关片段。# 推荐的最小实验目录结构 agent_state_test/ ├── tasks/ # 测试任务配置 ├── states/ # 显式执行状态快照 ├── histories/ # 原始对话历史按需加载 ├── logs/ # 执行日志 ├── agent.py # Agent 主逻辑 ├── state_store.py # 状态读写与更新 └── metrics.py # token、耗时、成功率统计建议始终保留一套“完整历史”的实现作为对照组。不要一开始就彻底删除对话历史因为显式状态可能存在信息盲区。采用“默认读状态异常/信息不足时回退到历史检索”的混合模式是相对稳妥的演进路径。再补充一个合规性提醒如果你的 Agent 系统处理的是用户个人数据、企业机密或版权材料无论使用完整历史还是显式状态都需要在设计中明确数据留存范围、访问权限和删除策略。状态快照中如果包含敏感信息也要统一按敏感数据处理避免因为“状态更短”而忽视隐私保护。9. 总结与下一步SKILL.state 指出了一个很值得深思的方向智能体系统不一定非要靠更长的上下文来换能力在架构层面把“执行状态”从“对话历史”里解耦出来可能是更可持续的路线。它在长任务、多轮工具调用、高可靠性场景下具备明显的想象空间同时也带来了状态建模和一致性维护的新挑战。对开发者来说最先该验证的不是复现论文里的完整框架而是用一个小型 Agent 任务对比“完整历史”和“显式状态”这两种上下文策略在 token 消耗与成功率上的差异。只要这一组数据跑出来你就能判断这个思路适不适合自己的业务场景。当前最容易踩的坑是两个一是状态字段设计得过大把状态变成另一种历史二是没有保留历史回退通道一旦状态漏记信息Agent 就失去纠错机会。建议从最小状态集开始逐步迭代并始终保留对话历史作为“按需回溯”的兜底。后续还可以继续关注几个方向状态 schema 自动生成、状态与长期记忆的统一、多智能体协作时状态同步机制。这些方向如果做扎实SKILL.state 的工程价值会进一步释放。建议收藏这篇等论文全文和实验数据公开后再回来对照验证。