原论文SKILL.state: Scalable Long-Horizon Agent SkillsGoogle LLC Purdue University2026-08-26 首版2026-09-02 v3。论文标注 accepted at EMNLP。一、整体思想多轮对话变成状态提交SKILL.state 改的是多轮对话的默认模式。传统 Agent 下一轮通常会继续看到这些东西用户最初的需求 上一轮、上上轮、更早的用户补充 模型之前的推理 所有工具调用 所有工具输出 模型之前说过的话SKILL.state 把这些历史从下一轮 prompt 里拿掉。下一轮模型只看三块P Policy / Skill稳定规则。告诉模型这类任务怎么做。 Sigma State当前状态。告诉模型现在已经确定了什么、做到哪一步。 O Observation最新观察。告诉模型刚刚发生了什么。写成论文里的形式就是下一步输入 (P, Sigma_t, O_t) 下一步输出 reasoning state_patch action这里的P通常来自SKILL.md比如“修改前先读现有实现保持 API 向后兼容完成后运行测试”。Sigma_t通常来自state.json比如“正在给订单列表增加 CSV 导出仅管理员可用已定位到订单路由和权限中间件”。O_t是最新一条工具结果或用户补充比如“搜索结果显示订单接口在routes/orders.ts”。之前的用户输入、工具输出、模型推理不会直接出现在下一轮。它们要想继续生效必须被写进Sigma_t。用户最初的任务可以写进state.task用户中途追加的约束先作为本轮O_t出现下一轮还要用就提交进state_patch。所以这套思想一句话就能说清把多轮聊天记录改成一份当前状态模型每轮只读当前状态和最新观察。二、用一个开发需求看多轮怎么跑假设用户提出需求给订单列表增加 CSV 导出。仅管理员可用不要改变现有 JSON 接口。这句话是第 0 轮的最新观察O_0。处理开发任务的SKILL.md是稳定的P# Implement Feature - 修改前先搜索并阅读现有实现。 - 保持现有 API 向后兼容。 - 权限校验复用项目已有机制。 - 修改后运行相关测试。任务刚开始时Sigma_0只表示还没有完成探索{task:,facts:[],progress:not_started,open_questions:[],done:false}第 1 轮接收需求模型收到的 prompt 是{P:修改前先搜索并阅读现有实现保持现有 API 向后兼容权限校验复用已有机制修改后运行测试。,Sigma:{task:,facts:[],progress:not_started,open_questions:[],done:false},O:{type:user_message,content:给订单列表增加 CSV 导出。仅管理员可用不要改变现有 JSON 接口。}}模型把需求中下一轮仍要使用的信息提交进 state同时选择搜索动作{reasoning:先定位订单接口、权限实现和现有测试。,state_patch:{task:add CSV export to order list,facts:[CSV export is admin-only,existing JSON API must remain compatible],progress:locating implementation,open_questions:[where is the order list implemented?,how does the project enforce admin access?],done:false},action:{tool:search_code,args:{query:orders route admin middleware}}}runtime 提交 patch再执行搜索。搜索结果成为下一轮的O_1routes/orders.ts: GET /orders middleware/require-admin.ts: requireAdmin() tests/orders.test.ts: order list tests第 2 轮根据搜索结果继续这一轮不携带用户原话和第 1 轮 reasoning。模型看到同一份P、已提交的Sigma_1以及刚得到的O_1{P:修改前先搜索并阅读现有实现保持现有 API 向后兼容权限校验复用已有机制修改后运行测试。,Sigma:{task:add CSV export to order list,facts:[CSV export is admin-only,existing JSON API must remain compatible],progress:locating implementation,open_questions:[where is the order list implemented?,how does the project enforce admin access?],done:false},O:{type:tool_result,content:Order route: routes/orders.ts; admin middleware: middleware/require-admin.ts; tests: tests/orders.test.ts}}模型把搜索结论写回 state并读取相关文件{state_patch:{facts:[CSV export is admin-only,existing JSON API must remain compatible,order list is implemented in routes/orders.ts,admin access uses requireAdmin(),order tests are in tests/orders.test.ts],progress:reading implementation,open_questions:[what response shape and query parameters already exist?],done:false},action:{tool:read_files,args:{paths:[routes/orders.ts,middleware/require-admin.ts,tests/orders.test.ts]}}}用户中途补充约束读取结果也会在下一轮提炼进 state例如“现有GET /orders返回 JSON应新增独立导出路由”。随后用户又说CSV 里的时间统一用 UTC。这条消息成为新的O。模型仍能从当前Sigma读到原需求、权限要求和代码位置于是把 UTC 约束并入已有facts{state_patch:{facts:[CSV export is admin-only,existing JSON API must remain compatible,CSV timestamps must use UTC,order list is implemented in routes/orders.ts,admin access uses requireAdmin(),order tests are in tests/orders.test.ts,GET /orders returns JSON and must remain unchanged,CSV export should use a separate route],progress:ready to implement,open_questions:[],next_action:{tool:edit_files,args:{paths:[routes/orders.ts,tests/orders.test.ts]}},done:false},action:{tool:edit_files,args:{paths:[routes/orders.ts,tests/orders.test.ts]}}}几轮之后完整聊天、搜索命令和文件内容都留在审计日志里。下一轮只读取当前state.json和最新编辑结果。用户原始需求已经离开 prompt其中的长期约束仍保存在 state 中。三、runtime 和 LLM 自己 patch 的区别普通 OpenAI tool calling 的流程是LLM 返回 tool_call → runtime 执行工具 → 工具结果作为下一条 tool message 发回 LLMSKILL.state 只改第一步的输出内容LLM 同时返回 state_patch action → runtime 校验并提交 state_patch → runtime 执行 action → 工具结果成为下一轮 O论文附录中的action是字符串命令没有使用 OpenAI 原生tool_calls。接入 OpenAI 时不必修改 API 协议可以定义一个propose_transition工具让一次 function call 同时携带两部分{state_patch:{progress:ready to implement},action:{tool:edit_files,args:{paths:[routes/orders.ts]}}}不要拆成update_state和edit_files两个 tool call两者可能并行或只成功一个。runtime 应先校验整个 transition再提交 state 和执行工具。需求怎样实现由模型判断这次状态更新能否生效由 runtime 判断。四、少上下文是结果单源事实才是因完整历史的输入会随步数增长。第 100 步要读前 99 步第 101 步又要读前 100 步累计成本接近O(T^2)。SKILL.state 每一步只读P Sigma O只要 Skill、state、最新 observation 的大小受控累计成本就是O(T)。这个成本变化来自一条规则下一步要依赖的事实必须先通过state_patch提交进state.json。开发例子里“仅管理员可用”来自用户第一条消息。后续实现和测试都要用它所以模型必须把它写进facts。用户后来补充的 UTC 约束也要提交{state_patch:{facts:[CSV export is admin-only,existing JSON API must remain compatible,CSV timestamps must use UTC,order list is implemented in routes/orders.ts,admin access uses requireAdmin(),order tests are in tests/orders.test.ts,GET /orders returns JSON and must remain unchanged,CSV export should use a separate route],progress:ready to implement,open_questions:[],next_action:{tool:edit_files,args:{paths:[routes/orders.ts,tests/orders.test.ts]}},done:false},action:{tool:edit_files,args:{paths:[routes/orders.ts,tests/orders.test.ts]}}}到了实现阶段模型看到的是“目标需求 权限和兼容性约束 已定位文件 最新工具结果”。任务进度、关键事实、未解问题都有一个固定入口。五、审计日志和 state 分工不同生产系统需要两份记录state.json 给下一步决策用只保留当前充分状态 audit/events.jsonl 给人、测试和故障复盘用保留完整提交记录state.json要短、稳定、可放进 prompt。它回答“下一步现在知道什么”。{task:add CSV export to order list,facts:[CSV export is admin-only,existing JSON API must remain compatible,CSV timestamps must use UTC,order list is implemented in routes/orders.ts,admin access uses requireAdmin(),order tests are in tests/orders.test.ts,GET /orders returns JSON and must remain unchanged,CSV export should use a separate route],progress:ready to implement,open_questions:[],next_action:{tool:edit_files,args:{paths:[routes/orders.ts,tests/orders.test.ts]}},done:false}audit/events.jsonl可以长。它回答“这份 state 是怎么来的”{type:step,observation:给订单列表增加 CSV 导出。仅管理员可用不要改变现有 JSON 接口。,state_patch:{task:add CSV export to order list,facts:[CSV export is admin-only,existing JSON API must remain compatible],progress:locating implementation},action:{tool:search_code,args:{query:orders route admin middleware}}} {type:step,observation:Order route: routes/orders.ts; admin middleware: middleware/require-admin.ts,state_patch:{facts:[CSV export is admin-only,existing JSON API must remain compatible,order list is implemented in routes/orders.ts,admin access uses requireAdmin(),order tests are in tests/orders.test.ts],progress:reading implementation},action:{tool:read_files,args:{paths:[routes/orders.ts,middleware/require-admin.ts,tests/orders.test.ts]}}} {type:step,observation:CSV 里的时间统一用 UTC。,state_patch:{facts:[CSV export is admin-only,existing JSON API must remain compatible,CSV timestamps must use UTC,order list is implemented in routes/orders.ts,admin access uses requireAdmin(),order tests are in tests/orders.test.ts,GET /orders returns JSON and must remain unchanged,CSV export should use a separate route],progress:ready to implement},action:{tool:edit_files,args:{paths:[routes/orders.ts,tests/orders.test.ts]}}}下一轮 prompt 使用state.json和最新 observation。审计日志留给ss check、故障复盘和人读。这条边界让 operational state 保持小也让旧轨迹仍然可查。六、Token 收益要降温执行语义更重要论文报告的几个结果很强场景历史基线SKILL.state仓储 T1000.91 / 1,062,387 tokens0.94 / 65,408仓储 T2000.88 Stateful0.94软件仓库 T1000.63 / 2,308,0000.78 / 90,200InterCode CTF46.4%54.2%tau-Bench Retail51.7%58.3%tau-Bench Airline28.1%32.4%仓储 T100 的16.2xToken 降幅最醒目这个数字不能直接换算成生产 Agent 的成本或速度收益。实际 coding agent 常会裁剪大型 tool output、压缩旧轮次而稳定的历史前缀还可能命中服务端 prompt cache。论文统计的是累计 Token没有报告缓存命中率、缓存后的实际费用和wall-clock latency。因此16.2x更接近“相对完整重放历史的理论收益上限”。如果现有 Agent 已经丢弃旧工具输出SKILL.state 能继续节省的 Token 确实会少很多。更关键的比较是论文的同预算实验仓储 T100约 1,800 字符/轮得分滑动窗口0.18LLMLingua0.22受限摘要0.52SKILL.state0.94几种方法的累计 Token 都在约 6.2 万到 6.5 万之间差异主要体现在正确率。这个实验支持的结论是关键不只是删掉历史而是把仍然影响后续动作的事实写进有领域语义的状态。除了 Token显式状态还有三个价值旧事实不会与新事实同时留在 prompt。当前状态覆盖或删除旧值模型不必从多轮记录中判断哪个版本有效。环境变化可以立即成为当前事实。论文的状态漂移实验中SKILL.state 恢复步数为 0历史方案需要多个步骤摆脱旧信息。状态提交可以校验和回滚。schema、类型检查和原子写入能阻止非法 patch 成为下一轮事实状态文件也自然形成暂停和恢复的检查点。前两项有论文实验支撑第三项主要是 runtime 设计带来的工程收益。论文结论仍有几个边界论文没有控制 prompt cache也没有与具体生产 Agent 的 output masking、自动 compaction 做直接对照。Stateful (LangGraph-style)是作者构造的state full historybaselineLangGraph 本身允许调用方自行决定 prompt 内容。开源模型收益弱很多。错误分析中68% 来自提前覆盖或删除状态20% 是 schema/type 错误12% 是 JSON 格式错误。所以这项工作的意义不宜概括成“找到一种更省 Token 的压缩方法”。它真正提出的是一种执行契约Agent 的下一步只依赖经过提交的当前事实不再依赖模型从聊天记录中重建当前事实。这对状态结构稳定的长流程很有价值例如订单、审批、发布和运维工作流对探索式编码、开放研究以及需要保留用户语境的任务固定 schema 容易漏掉当时没有意识到的重要信息。实际 coding agent 更适合采用有界 operational state、独立审计日志和按需历史检索的组合。七、和 Ledger 的分歧更值得看同月还有一篇更工程化的相邻工作Ledger: Turning Interaction History into Execution State。Ledger 不让模型维护状态。runtime 根据已经完成的工具调用确定性地记录三类事实观察记录成功读取了哪个文件、哪些行以及读取时的版本计数 修改状态哪些文件被修改以及文件级和仓库级的变更计数 命令记录标准化后的命令、命令类别和最近执行位置例如 Agent 已经读取src/order.ts:1-120期间文件没有变化又提出相同读取。Ledger 在命令真正执行前检查相同行范围以前成功读取过 → 是 读取后文件或仓库发生过修改 → 没有 旧结果仍在当前模型上下文中 → 是此时 runtime 返回Reuse跳过读取引用旧结果。文件已经修改时返回Allow重新读取。测试命令更保守没有修改代码却重复运行测试时返回Nudge测试仍会执行只在结果后附加“可能重复”的提示。Ledger 只强制复用确定安全的读取和搜索结果。因此所谓“拦截”不是让另一个模型判断两个动作是否相似而是根据标准化命令、读取范围和变更计数做规则匹配。解析失败、不支持的命令以及环境配置等操作默认Allow。理解这个机制后两者的分歧就很直接SKILL.state 下一次输入 Skill 当前 state 最新 observation 历史消息不再发送 Ledger 下一次输入 原有对话历史 确定性执行账本 历史消息继续发送Ledger 容易接进现有 coding agent也能在执行前阻止一部分重复工作但无法获得 SKILL.state 的固定 prompt 大小。SKILL.state 能彻底停止历史增长代价是必须重新组织 agent loop并确保 schema 足以承载后续需要的事实。本复现选择 SKILL.state 的执行方式同时保留一份不进入 prompt 的审计日志供测试和故障复盘使用。八、这套东西该怎么迁移到真实 Agent最小可用版本应该长这样runtime/ prompt_builder 只拼 P Sigma O patch_validator schema 校验返回 Path Hint state_store 原子提交失败回滚 audit_log append-only不进 prompt retry_policy patch 无效时重试不执行 action tests/ no_history_leak invalid_patch_rollback resume_round_trip bounded_prompt_growth最先写的测试应该是no_history_leak。因为这条一破整个系统表面上仍能跑实际上已经退回完整历史 Agent。其次是invalid_patch_rollback。模型迟早会写错 JSON、写错字段、删掉还需要的事实。runtime 要按 schema 裁决每一次提交。最后才是成本曲线。prompt 变短只是结果如果状态契约不对短 prompt 只会更快地把任务跑错。