长时程Agent有两个典型症状：越跑越慢，然后被自己的上下文"毒"死。
这里的Agent，指能自主执行多步任务的LLM程序。比如让它管理一个500个货架的仓库，或者在一台Linux机器上完成CTF挑战。任务短的时候一切正常，一旦拉长到几十上百步，问题就来了。
Google和合作者的一篇新论文（已获EMNLP接收）指出，两个症状来自同一个设计选择：为了让执行持续下去，运行时把每一步的观察结果、执行动作、中间推理轨迹，全都追加进一段越来越长的对话历史里。
论文作者是Sanket Badhe、Priyanka Tiwari和Jonghyun Chung，分别来自Google LLC和Purdue University。
任务短的时候，这种"只增不减的历史"没有问题。但一旦拉长，历史本身就成了负担：延迟随上下文长度上升，而更早的、可能已过时的信息一直留在上下文里，不断干扰模型判断。论文把这叫作上下文中毒（context poisoning）。
怎么改
SKILL.state的思路是把这段历史，换成一个显式、可变的执行状态。
每一步，模型只看三样东西：不变的技能规范（P）、当前的结构化执行状态（Σt）、最新一条观察结果（Ot）。中间推理在产出一次通过校验的状态更新后，立刻丢弃。prompt不再随执行历史增长，增长的是状态本身。
打个比方。传统做法像是让Agent写日记，每做一件事就记一笔，然后每次做决策前把整本日记从头读一遍。SKILL.state的做法是只维护一张"当前状态表"，做完决策、更新完表格，草稿纸扔掉。
从复杂度看，传统方法每步的prompt长度随步数线性增长，累计token消耗是O(T²)。SKILL.state每步prompt大小恒定，累计O(T)。这个差距在长时程任务上会被迅速放大。
实验怎么做的
论文的实验设计分了自建基准和公开基准两层。
自建基准叫SkillExecBench，包含两个环境：
Warehouse Management：500个独立货架的库存管理，动作包括Store、Ship、Move、Wait。测试的是模型在长时间跨度上维护独立状态变量的能力——早期观察早已滚出上下文窗口，但货架上放了什么必须记住。
Software Repository：一个嵌套的Git仓库图，有分支、commits、Pull Request、CI测试状态。动作包括CherryPick、Merge、RunTests、CreateRelease、Rollback。这个环境测试的是复杂结构推理，一个merge操作可能同时改变目标分支和所有依赖PR的状态。
公开基准用了两个：
InterCode CTF：100个Linux bash CTF挑战，涵盖逆向工程、取证、密码学、二进制漏洞利用。Agent在Docker容器里执行命令，不断测试假设来发现隐藏flag。
Sierra τ-Bench：模拟企业客服场景（Retail和Airline两个领域），Agent要和模拟用户对话、查询SQLite数据库、执行事务性操作（改签机票、退款等），还要遵守业务策略约束。
基线有四个：ReAct（追加全部历史）、Memory（滚动3步窗口+定期摘要）、Stateful/LangGraph（在对话历史旁注入结构化状态块）、以及SKILL.state。另外还做了预算匹配的对照组：滑窗截断、摘要硬上限、以及用LLMLingua做统计压缩。
模型用了三个：Gemini-3-Flash、Gemma-4-31B-it、Qwen-3-8B-it。所有实验temperature=0，top-p=1，确保可复现。
数字
先说长时程扩展实验。
在Warehouse任务上，T=200步时，SKILL.state准确率0.94，累计消耗122k token。Memory基线准确率0.84，消耗610万token。T=100步时，SKILL.state消耗65k token，Stateful消耗106万token——16.2倍差距。
在Software Repository上，T=100步时SKILL.state准确率0.78，消耗90k token；Prompt基线准确率0.53，消耗185万token。
噪声鲁棒性实验也很有意思。在T=50步的Warehouse任务中注入大量无关背景遥测（机器人电池状态、传感器读数、安全摄像头日志），噪声从低到高三个等级。Prompt基线从0.68一路掉到0.53；SKILL.state保持在0.97以上。原因是噪声在状态patch生成阶段就被过滤掉了，永远不进入后续prompt。
状态恢复实验测试了外部环境悄然改变（比如有人偷偷挪了货架上的东西）后各方案的恢复能力。历史基线会连续幻觉5到8个回合，因为prompt里过时的旧信息压过了矛盾的新观察。SKILL.state需要0步恢复——它的决策基于当前结构化状态，收到纠正信息后立刻更新。
公开基准的结果：
-
InterCode CTF：SKILL.state pass@1 54.2%，比最强基线高7.8个百分点，比Stateful高12.4个百分点。累计token消耗比ReAct少60.4%，比Stateful少65.9%。状态schema只用了5个静态字段（discovered_flags、tested_hypotheses、active_files、working_dir、cmd_summary），100个任务共用。 -
τ-Bench Retail：58.3% pass rate，token消耗最低。 -
τ-Bench Airline：32.4% pass rate，prompt稳定在约2800 token/步，而基线会飙到11000 token/步以上。
最说明问题的是预算匹配实验。把ReAct、摘要、滑窗截断、LLMLingua全都限制在和SKILL.state相同的1800 token/步预算下，在T=100步的Warehouse任务上跑。结果：滑窗截断0.18（早期货架分配信息被踢出窗口），LLMLingua 0.22（统计熵过滤把看似冗余但语义关键的slot标识符删掉了），SKILL.state 0.94。结构化状态维护保住了精确的关系依赖，这是统计压缩器天然会破坏的。
开源模型的表现
在Gemma-4-31B（T=100，score 0.42）上的错误分析显示，问题不在推理能力，而在结构化输出的一致性：
-
68%的错误：过早覆盖或删除状态中的已有key，而不是做in-place合并 -
20%：schema理解或类型转换错误（嵌套列表和字典的预期不一致） -
12%：JSON语法错误（分隔符、尾随逗号）
论文作者建议未来可以集成语法约束解码来消除格式化错误，让模型专注于语义层面的状态转换。
局限
论文列出了三个不适用场景：
-
没有固定schema、状态结构需要在执行中动态发现的任务 -
某个早期观察的重要性当时没被识别、因此从未被提交到状态中，但后来发现需要它 -
任务目标本身就定义在历史轨迹上（比如审计、调试溯源、解释过去的行为），这时候交互历史是输出目标而不是运营开销
怎么看
有网友说这不过就是把历史丢了省token，基本优化而已。但仔细看实验设计，论文在预算匹配对照组上花的功夫说明他们自己早就想到了这个质疑。截断、压缩、摘要硬上限，同样的token预算下全崩了，而SKILL.state能稳住。区别在于，这不是临时丢信息，而是换了一套运行时抽象，从"记录一切"变成"当前在哪"。
论文：https://arxiv.org/abs/2608.26263
关注公众号回复“进群”入群讨论