论文链接：SKILL.state: Scalable Long-Horizon Agent Skills (arXiv:2608.26263) 发表时间：2026年8月26日 机构：Google LLC、Purdue University——企业与高校合作（Google 工程师与普渡大学研究者联合完成，属于工业界运行时工程经验与学术界系统研究的结合） 领域标签：cs.AI，EMNLP 接收；Agent 运行时 / 长时程技能执行

一、论文背景

1.1 Agent 与程序性技能

大语言模型（LLM）已经从「你问我答」的语言界面，进化成能自主干活的智能体（Agent）：它会迭代推理、调用工具、与外部环境交互。在此基础上，研究者进一步把这些能力封装成可复用的程序性技能（procedural skill）——可以理解为 Agent 的「岗位操作手册」：软件工程、工作流自动化、网页操作、科学发现，都由一组组模块化的专业技能组合完成。

当 Agent 执行的是长时程（long-horizon）任务——动辄上百步的运维、客服、攻防流程——「执行」本身就不再只是一个推理问题，而变成了一个系统问题：上下文怎么管、token 怎么省、状态怎么保持，这些工程决策直接决定任务成败。

1.2 append-only 对话历史：主流运行时的隐含假设

今天的 Agent 运行时（从 ReAct 到各类 Agent 框架）几乎都采用对话式执行模型：每一步，模型收到的 prompt = 原始技能规范 + 一份不断增长的转录记录（transcript）——此前所有推理、动作、观察、工具输出全部追加（append）在后面。这就是所谓 append-only 对话历史：只增不减，像一本只许续写不许撕页的流水账。

这个设计在短任务上没问题，但拉长到几百步就会出现三个结构性病灶：

1. prompt 尺寸随步数线性膨胀：第 t 步的 prompt 长度是 O(t)，整个任务累计 token 消耗是 O(T²)——步数翻倍，成本翻两番；
2. 上下文污染（context poisoning）：过期观察和早已失效的推理永远留在上下文里，模型被迫反复区分「哪些是当前事实、哪些是历史残留」，检索准确率随上下文变长而下降（即「lost in the middle」现象）；
3. 状态靠文本重建：执行状态隐式地散落在自然语言历史里，每一步都要靠模型「考古」——从历史文本里重新推断现在的世界是什么样。

现有的缓解手段——记忆系统（MemGPT 等的摘要与检索）、滑动窗口、prompt 压缩——都只是给历史「瘦身」，执行语义没变：未来的决策依然建立在对过去的文本重建之上，而不是建立在对「当前状态」的显式表示之上。

二、论文定位和关联工作

论文的立场非常鲜明：先前工作在管理对话历史，本文在移除对话历史。按四条谱系梳理：

2.1 程序性技能研究

前序工作（作者团队 2026 年的技能综述与技能安全研究）聚焦技能的发现、表示、组合与安全威胁建模。本文补上了被忽视的一环：技能被选中之后，执行机制本身怎么办。

2.2 记忆架构

Mem0、MemoryBank、MemGPT 等通过情景检索或持久存储管理长期记忆，LangGraph 这类编排框架用辅助结构化状态在节点间协调工作流。但它们的推理基底仍是完整对话转录。SKILL.state 的区别在于把结构化状态当作充分统计量——推理轨迹在产出经验证的状态更新后被立刻丢弃。

2.3 对话状态跟踪（DST）

DST 是任务型对话的老课题：跨轮维护用户槽位值（如「目的地=东京、日期=周五」）。两者都维护结构化表示，但机制根本不同：DST 是辅助状态 + 完整对话历史，对话准静态；SKILL.state 是结构化状态本身作为唯一依据、丢弃历史，环境动态变化且 prompt 有界。

2.4 长上下文与 prompt 压缩

Lost in the middle、InfiniteBench 揭示长上下文检索退化；StreamingLLM 用注意力汇聚点做流式注意力；LLMLingua（微软，用小模型困惑度做预算感知的 token 剪枝）压缩 prompt。这条路线试图「处理或压缩」长历史，SKILL.state 则阻止历史累积——只维护下一步计算所需的规范化执行状态。

三、问题定义

具体场景：Agent 执行一个 T 步的程序性技能，每步产生观察、推理、动作。传统运行时的上下文 C_t 随历史累积，|C_t| = O(t)，累计 token 为 Σ|C_t| = O(T²)。

核心洞察：论文发现，长时程技能执行在本质上不是一个「语言建模」问题，而是一个状态维护问题——过去的一切，只有「对决定未来动作有影响的部分」才有价值。既然如此，与其让模型每步从文本历史里考古重建状态，不如显式维护一个状态，让执行只依赖当前世界。

这相当于把经典自动机/操作系统的状态转移思想移植到 Agent 运行时：

形式化定义：第 t 步模型接收三元组 A_t = (P, Σ_t, O_t)——不可变程序规范 P、结构化执行状态 Σ_t、最新环境观察 O_t；生成 (R_t, ΔΣ_t, a_t)——推理轨迹、状态补丁、待执行动作。目标：在保持（或提升）任务准确率的前提下，使单步 prompt 尺寸有界 O(1)、累计 token 复杂度线性 O(T)。

精妙之处：这个抽象把「记得发生过什么」（历史）与「知道现在是什么」（状态）解耦——前者是手段，后者才是目的。历史只在它被投影进状态的那一刻产生价值，之后即可安全丢弃。

四、问题解法

4.1 运行时执行循环

每个执行步（Algorithm 1）：

1. 接收最新观察 O_t；
2. 用 (P, Σ_t, O_t) 构造 prompt（不含任何历史观察、历史动作、历史推理）；
3. 模型生成三元组 (R_t, ΔΣ_t, a_t)；
4. 运行时确定性验证状态补丁 ΔΣ_t；
5. 合并：Σ_{t+1} = Σ_t ⊕ ΔΣ_t（⊕ 为字典合并算子，带 null 删除语义——补丁里值为 null 的键被删除）；
6. 执行动作 a_t，进入下一步。

关键在推理轨迹的生死：步内多步 Chain-of-Thought 在生成时完整保留（支撑复杂演绎规划），但状态转移一经验证应用，R_t 即被永久丢弃，绝不进入后续 prompt。瞬时推理被「投影」为持久结构化状态，只有未来执行需要的信息得以存活。

类比：这就像编译器优化——中间表示（推理轨迹）在生成机器码（状态补丁）后即被丢弃，运行时只执行机器码；而不是每次都把整个编译历史背在身上。

4.2 状态 schema 的按领域编写

执行状态是运行时的一等公民，用领域定义的结构化 schema 表示。schema 按领域编写一次，而非按任务编写：InterCode CTF 全部 100 道题复用同一个静态 5 字段 schema（discovered_flags、tested_hypotheses、active_files、working_dir、cmd_summary）。这保证了状态表示的成本不随任务数增长。

4.3 复杂度对比

• 对话式运行时：|C_t| = O(t)，累计 Σ|C_t| = O(T²)；
• SKILL.state：|P_t| = O(|P| + |Σ| + |O|)，与已执行步数 t 无关，累计为 O(T)。

差距随步数拉大：T=200 时基线烧掉数百万 token，SKILL.state 只需 12 万。

4.4 安全性与容错

schema 的所有权与验证权在确定性运行时而非模型手中——格式错误的补丁无法污染持久状态 Σ_t，只触发回滚-重试循环。这把「模型可能写坏状态」的风险挡在了状态之外。对小模型，作者建议引入语法约束解码（grammar-constrained decoding）进一步消除格式错误。

五、评估指标与实验证据

5.1 指标体系

• 主指标：任务准确率 / 成功率（SkillExecBench 连续得分 = 成功动作数 / 可行动事件总数；CTF 二值 pass@1；τ-Bench 官方程序化评估器）
• 辅助指标：平均 prompt 尺寸（每次调用的 token 足迹）、累计 token 消耗
• 消融指标：预算匹配对照（把所有基线钉在与 SKILL.state 相同的 ~1,800 token 预算上）——用于分离「短 prompt」与「结构化状态」两个混杂因素

5.2 基准

• SkillExecBench（自建诊断测试床）：Warehouse（500 独立货架的离散库存管理）测独立状态变量的长时程维护；Software Repository（Git 分支/commit/PR/CI 的深层关系图）测纠缠结构上的关系推理。确定性真值转移 + 5 个生成器种子，保证各运行时面对完全相同的事件序列。
• InterCode CTF：100 道 Linux bash 夺旗赛题（逆向、取证、密码学、二进制利用），Docker 内交互执行。
• Sierra τ-Bench：企业客服（Retail / Airline），模拟用户 + 关系型 SQLite + 业务政策约束下的事务操作。

基线三类主范式：Prompt（ReAct 式追加）、Memory（摘要式）、Stateful（LangGraph 式：状态块 + 完整滚动历史）；三类预算匹配对照：滑窗截断、摘要封顶、ReAct + LLMLingua。模型：Gemini-3-Flash、Gemma-4-31B-it、Qwen-3-8B-it，temperature 0.0。T≥50 的差距经配对 t 检验 p < 0.01。

5.3 证据一：长时程扩展（表 1，Warehouse，Gemini-3-Flash）

SKILL.state 的 prompt 全程平坦（~1,736–1,905 tokens）。T=100 对最强基线 Stateful 实现 16.2 倍 token 缩减（65,408 vs 1,062,387），且得分反而更高；T=200 时对 Memory 基线省下约 50 倍 token。

5.4 证据二：噪声鲁棒性（T=50，每轮注入 5/20/50 条干扰事件）

高噪声下 Prompt 基线从 0.68 跌到 0.53，SKILL.state 保持 0.98——干扰项在状态补丁生成时被过滤，从不进入后续 prompt。

5.5 证据三：状态恢复（外部静默篡改世界状态）

历史式基线在收到矛盾的新观察后会连续幻觉 5–8 步（Software 场景最长达 12–14 步）——过时的历史事实压倒了新观察。SKILL.state 零步恢复：决策只依赖当前结构化状态，纠正性警报一到、状态立即更新。

5.6 证据四：公开基准（表 4，Gemini-3-Flash）

CTF 上把已发现 flag 与已试假设显式存进 Σ_t，直接杜绝了重复尝试失败命令的问题。

5.7 证据五：预算匹配对照（关键消融，T=100，~1,800 token 预算）

同等 token 预算下 0.94 vs 0.18 / 0.22——这是全文最重要的对照：它证明收益并非来自「prompt 更短」，而来自「结构化状态表示」。滑窗丢掉了早期关键库存分配，LLMLingua 的统计熵过滤删掉了「看似冗余实则语义关键」的槽位标识符。

5.8 开权重模型误差分类（Gemma-4-31B，T=100 得分 0.42）

过早状态覆盖/删除 68%、schema 理解/类型强制 20%、JSON 语法滑误 12%——小模型退化源于结构化输出遵循而非推理能力，指向语法约束解码这个明确的修复方向。

六、效果优势的根源解释

按「方法差异 → 机制变化 → 指标提升」建立因果链。

6.1 根本改变：信息流的单向投影

对比对象：四类基线曾有效，是因为保留历史让模型「看见」完整因果链条；LangGraph 甚至已有结构化状态块。根本局限：它们的信息流是全量保留 + 事后筛选——每一步，模型都要在包含全部过期事实的上下文里做「相关性过滤」，这个过滤由统计性质（注意力权重、困惑度）而非任务语义决定，必然出错且必然随历史增长而恶化。

本文的根本性改变：把信息流改为单向投影——每步只做一次「过去 → 当前」的有损压缩，压缩的语义标准由 schema 定义（只保留未来需要的），且压缩结果一经验证即成为唯一事实源。

6.2 三条因果链

链条一（噪声鲁棒）：结构化状态替代文本历史 → 干扰事件（系统遥测、无关 webhook）在状态补丁生成环节被语义过滤，从不写入 Σ、从不进入后续 prompt → 模型注意力再无噪声可被拖拽 → 高噪声下 0.98 vs Prompt 基线 0.53。反事实：Stateful 基线虽也有状态块，但噪声仍随滚动历史进入 prompt，所以只能到 0.98 边缘持平——因为没有彻底移除历史。

链条二（状态漂移零恢复）：决策只依赖 Σ_t 而非历史事实 → 纠正性观察到达时，唯一需要更新的是状态本身，不存在「与新观察矛盾的旧文本」→ 外部篡改后 0 步恢复。基线的 5–8 步幻觉本质是上下文内的证据竞争：过期事实在数量上压倒孤立的纠正信号；SKILL.state 从结构上消除了这场竞争。

链条三（预算匹配下的碾压）：schema 保留精确关系依赖（货架↔物品的键值映射、PR↔分支的图结构）→ 0.94；统计压缩器按信息熵操作，无法区分「冗余」与「低熵但关键」（槽位 ID 就是例子）→ LLMLingua 0.22；滑窗按时间裁剪，恰好淘汰最早的（往往是奠基性的）分配 → 0.18。三者同样短 prompt，结局天壤之别——决定性变量是表示的结构保真度，不是长度。

链条四（CTF +7.8pt）：tested_hypotheses 与 discovered_flags 显式持久 → 失败命令与已试路径不可遗忘 → 搜索空间单调收缩 → 54.2% vs 基线最高 46.4%。

6.3 结构上必然，而非凑巧

四条链共享同一个根源：把「相关性判断」从每步的统计推理中移出，固化到一次性的 schema 设计与确定性的状态合并中。历史式运行时把这个判断重复执行 T 次、每次都可能出错且错误累积；SKILL.state 只在 schema 编写时执行一次。这就是「不是调参调出来的好，而是结构上必然更好」。

七、必要知识反推

假设一个零知识的人要复现这项工作，最少需要掌握：

7.1 领域知识层

• Agent 运行时执行模型：ReAct 范式、append-only 历史、prompt 构造——不理解「现有系统怎么跑」，就看不到 O(T²) 病灶；
• 长上下文失效模式：lost in the middle、上下文污染——这是论证「历史有害」的实证支点；
• 程序性技能表示：技能即不可变规范 P——需要知道技能生态（SKILL.md 类格式）才能把 P 与状态分离。

7.2 方法论知识层

• 四条相关研究脉络（记忆架构、DST、prompt 压缩、流式注意力）：定位「管理历史 vs 移除历史」的差异点；
• 充分统计量概念（统计学）：整个方法的合法性依赖「状态是未来的充分统计量」这一假设，也是局限性分析（第七节）的框架；
• 复杂度分析：O(T²) vs O(T) 的累计 token 推导是核心卖点的形式化表达。

7.3 工程知识层

• 确定性运行时设计：状态验证、回滚-重试、null 删除合并语义——「模型提议、运行时裁决」的权限分离是安全性的来源；
• 受控实验设计：固定种子让所有运行时面对相同事件序列；预算匹配对照分离混杂变量——没有这一步，「短 prompt」与「结构化状态」的贡献无法区分；
• 基准构建：SkillExecBench 两个环境（独立变量型 vs 关系依赖型）的设计逻辑。

7.4 知识融合的关键节点

• 节点一：把操作系统/自动机的「寄存器 + 转移函数」心智模型接到 Agent 运行时上——领域知识（运行时）× 经典系统概念（状态机）的化学反应，产生「丢弃推理轨迹」这个反直觉但必然的设计；
• 节点二：用预算匹配实验证明结构化表示优于统计压缩——实验设计方法论 × 对压缩技术机理（熵 vs 语义）的理解，把「结构好」从口号变成可检验命题。

八、论文中可以提取的通用性灵感

灵感一：当前态优于历史账——维护状态，而不是重放轨迹 证据：状态恢复实验 0 步 vs 5–8 步幻觉；O(T) vs O(T²)。 推广：运维告警系统（维护「当前故障拓扑」而非滚动日志流）、多人协作文档（CRDT 当前态合并而非操作历史回放）、机器人导航（位姿估计而非帧历史）、实时交易系统（账本当前余额快照）、GUI 框架（响应式状态而非事件堆栈）。

灵感二：推理是一次性计算，产出应被投影为持久结构 证据：R_t 在状态补丁验证后即丢弃，CTF 假设显式持久化带来 +7.8pt。 推广：代码评审（评审意见沉淀为 lint 规则而非留存于讨论）、科研（推理过程丢弃、结论入知识库）、数据分析（中间计算丢弃、结论入特征库）、会议（讨论即弃、决议入账）。

灵感三：统计压缩保不住低熵关键信息，语义过滤必须发生在写入时 证据：LLMLingua 0.22 vs SKILL.state 0.94（同预算）；「看似冗余的槽位 ID」被熵过滤误删。 推广：日志系统（按 schema 采集而非全量后过滤）、数据库索引（schema 驱动而非查询后筛选）、特征工程（先验结构化优于事后降维）、通信协议（结构化编码优于压缩编码）。

灵感四：权限分离——提议者不持有验证权 证据：畸形补丁无法污染 Σ_t，触发回滚重试；小模型误差分类指向约束解码的修复路径。 推广：数据库事务（应用提议、DBMS 验证提交）、CI/CD（开发者提议、流水线门禁）、组织流程（提案与审批分权）、区块链（交易提议与共识验证分离）。

灵感五：一次性 schema 成本，换取按领域复用的常数表示 证据：100 道 CTF 复用一个 5 字段 schema；schema 按领域编写而非按任务。 推广：企业数据建模（领域 schema 一次定义）、测试夹具（按领域而非按用例）、API 设计（领域资源模型）、机械设计（标准件库）。

灵感六：混杂变量必须在预算匹配下检验 证据：若不做预算匹配对照，「0.94 vs 0.18」会被误归因于「prompt 短」。 推广：任何 A/B 测试（拉平资源再比效果）、模型评估（等参数量/等 FLOPs 对比）、硬件评测（等功耗对比性能）、教育评估（等基础对比教法）。

局限提示（论文自述）：方法的合法性依赖「状态可作充分统计量」假设——schema 未知需动态发现、关键观察的 relevance 被晚察觉、目标定义在历史轨迹本身（审计/溯源/解释）三种场景下会失效；当前仅验证单智能体，多智能体并发写状态需要确定性的冲突解决语义。