编码代理状态文件实践：四天后弃用

给长任务加一份状态文件，让 AI 每走一步都重新读取目标、决策和下一步，看起来能缓解上下文越堆越乱的问题。作者把 SKILL.state 的思路接进 Claude Code，跑了四天却停用了：任务简报确实清楚，但维护状态的麻烦一直存在，而换用 Opus 5.5 后，上下文压缩已经很少发生。

这次尝试值得看，不是因为它证明了状态文件没用，而是它拆开了两件经常被混在一起的事：让新 agent 拿到完整简报，和为整个任务维护一套结构化状态。前者有收益，后者需要额外算账。

状态文件究竟想替代什么

Badhe、Tiwari 和 Chung 在 2026 年提出的 SKILL.state，是一种面向长任务的运行时设计。

常见 agent 会把观察、操作和推理不断追加到对话里。任务越长，历史越厚，早期已经失效的判断也可能继续影响后续步骤。上下文压缩可以缩短历史，却又可能丢掉关键信息。

SKILL.state 的做法是维护一份可修改的执行状态。模型每一步只接收三样东西：遵循的 skill、当前状态、最新观察。生成有效的状态更新后，这一步的推理就被丢弃。

大白话解释：下一棒读的是整理好的交接记录，不必重看全部聊天。

原文称，论文报告了更高的准确率和更低的 token 消耗，但没有给出具体数值和实验条件。这个结论不能直接套到作者的试用上，因为两者的运行方式并不相同。

Claude Code 里的实现，多了一套维护工作

Claude Code 始终保留完整聊天历史，作者无法像论文中的运行时那样，自行构造每一次模型输入。因此，他通过一个 skill 近似实现了这套机制。

每个任务在 worktree 内维护一个 JSON 文件，记录目标、阶段、决策、审查发现和下一步动作。阶段包括 spec、design、issue、implementation、review、merge。所有变更都通过一个小型 CLI 提交补丁，先按 schema 校验，通过后再写入。

具体工作交给每一步新建的 subagent。它拿到的简报只有 skill、当前状态和最新观察，不携带此前的对话。

这部分确实跑通了。作者观察到，审查者不需要补充上下文；审查要求修改后，新建的实现 agent 也能只靠状态文件继续处理。

但每次启用 skill 的运行，都会碰到多项维护问题：

• subagent 生成的状态补丁过不了 schema，主 agent 得重写其中一部分。
• schema 要求每条审查发现带时间戳，subagent 却会编造时间，偏差达到数小时，仍需主 agent 替换。
• deno fmt 和 deno lint 会扫描状态目录，每次检查前都得把它移开。

还有一次，subagent 忽略了禁止 push 的指令，主 agent 随后不得不改写公开提交的说明。作者没有把这件事归罪于 SKILL.state，但它暴露了交接的成本：交接点增加，指令也就多了丢失的机会。

这里要分清两种「纠正」。作者说四个任务都不需要他纠正 agent，同时又记录了这些修补，执行修补的是主 agent。用户没有介入，不等于流程没有额外开销。

四个任务没跑出对照结论，为什么仍然停用

作者原计划让任务交替启用和关闭 skill，积累足够样本后，对比首次审查通过率、人工纠正次数和每个任务耗时。只有可靠性至少持平、速度没有明显变慢，才设为默认。

实际只跑了四个任务：三个启用 skill，一个未启用。四次对话都没有发生上下文压缩。这样的样本既无法证明收益，也无法证明它降低了效率。

转折发生在实验中途。作者把 agent 换成 Opus 5.5 后，后续统计中上下文峰值的中位数是 162K tokens，48 个工作单元里只有 2 个发生过压缩。

这组数据与前面的四任务试验不是同一组，不能当成状态文件的效果对照。它支持的是另一个决定：在作者当前的模型和任务条件下，需要解决的问题已经不常出现，维护状态却仍然是每次任务的固定成本。

按他的任务节奏，完成足够样本还得花数周，于是他在四天后停止实验，后来移除了这个 skill。

他保留了独立简报和新 agent 的工作方式：主 agent 拆分工作，每位实现者从干净上下文开始，另有审查者检查每份 diff。这个流程原本就在使用，不依赖状态文件。

我的判断

我认同作者把「交接有效」和「状态系统值得维护」分开判断。完整简报能够帮助新 agent 接手，并不能自动证明所有决策都应该写进经过 schema 校验的 JSON。

但这仍是一份经验记录，不是对 SKILL.state 的否定性验证。作者没有完成对照实验，也没有给出额外 token、修补耗时或审查通过率的比较数据。时间戳、目录扫描和补丁校验问题中，也有一部分属于这次实现的工程细节。

更关键的是，他的主对话仍然保留历史，并没有完整实现论文所说的替换机制；实验期间又更换了模型，前后条件发生了变化。

与「完整简报＋新 agent」相比，状态文件需要证明额外维护能带来收益；与持续累积聊天相比，它则可能减少对旧历史的依赖。对于小上下文、较弱模型，或能控制每次输入的运行时，作者也预期 SKILL.state 会更有价值，但这只是预期，本文没有验证。

能拿来做什么

• 在日常 AI 编程中，先把下一步简报写完整，包含目标、已有决策、审查发现和下一步动作，再让新 agent 接手。可以先验证交接是否可靠，再决定是否增加状态文件。
• 如果准备引入 JSON 状态和校验 CLI，先处理好工具生成时间戳、状态目录避开格式化与 lint 等细节，减少 agent 为维护记录而返工。
• 评估长任务方案时，记录首次审查通过率、人工纠正次数、任务耗时和压缩频率，并区分用户介入与主 agent 内部修补。
• 更换模型后，重新检查原来的流程是否仍有必要；如果上下文压缩已经很少发生，就重新衡量专门为它增加的维护成本。