外置持久状态，降低长任务智能体开销

长时间运行的 AI Agent，可能把不少 token 花在了反复阅读自己的历史记录上。Stateless Language Agents（SLA）的做法是把研究历史交给外部系统保管，每次只向模型提供下一步需要的证据。原文称，它在达到最强内核优化基线最终表现时，少用了超过 84% 的 token。

这条思路值得程序员关注：Agent 能跑多久，不只取决于模型能力，也取决于历史如何保存、筛选和传递。但省下上下文之后，如何保证关键信息不丢，成了新的难题。

为什么历史越完整，Agent 反而越贵

原文指出，一类长程 Agent 会把整个研究过程放进每次模型调用：试过哪些方案、得到什么结果、接下来怎么改，都跟着对话继续累积。

问题出在重复输入。前面已经读过的内容，后面的调用还要再读；任务越长，单次调用携带的历史越多。模型除了推进研究，还在持续消耗 token 重读旧材料。

短预算测试容易掩盖这种成本。Agent 只跑几轮时，完整历史既方便，又不显得昂贵；运行轮数增加后，历史与当前推理绑在一起的代价才逐渐暴露。

需要长期保存的信息，不必每次都完整进入模型上下文。

SLA 就围绕这一区分重新组织流程。不过，原文没有给出传统 Agent 的具体上下文策略，不能据此认定所有现有方案都会无限追加完整记录。

「无状态」之后，谁来记住试验结果

Stateless Language Agents 并没有取消记忆，而是把记忆移到了模型之外。

外部执行框架（harness）保存候选方案和试验结果，再根据工作角色，为每个无状态工作代理整理当前需要的上下文。模型可以不携带完整对话历史，但整个系统依然保留研究进度。

负责协调的组件叫 Advisor。它读取汇总后的证据，并下发具体的实验任务。可以把这套分工理解为：外部系统保管实验记录，Advisor 分配下一步实验，工作代理拿着必要材料执行。

这里的核心不只是「把对话压短」，还包括把研究过程整理成可检索、可比较的候选方案与结果。如果只留下结论，却丢掉成立条件，下一轮就可能沿着错误方向继续尝试。

超过 84% 的节省，到底比较了什么

原文转述的实验覆盖软件工程、内核优化和算法设计三个领域，测试预算最高达到十亿，即 10 亿 token。

作者报告了三个结果：

• SLA 在每项任务上都取得了最佳最终结果。
• 达到最强内核优化基线的最终表现时，SLA 使用的 token 少了超过 84%。
• Advisor 消耗的 token 占比低于 0.6%。

第二条最容易被读偏。它比较的是达到某个性能水平所需的 token，不能直接扩写成「任何任务都能省 84%」，也不能推导出运行时间或实际账单同比下降。原文没有提供这些对照数据。

第三条说明，实验里的协调组件本身消耗较小。但原文没有交代摘要生成、外部存储和调度的完整成本如何核算，低于 0.6% 不能直接当成整套框架的总开销。

还有一个计量区别：原文开头提到十亿步研究的困难，实际报告的实验规模是最高 10 亿 token，二者不能混为一谈。

我的判断

我赞同把长期记录与当前上下文分开。对于反复提出候选方案、运行测试、比较结果的任务，保存完整实验档案，再按需提供证据，比每轮重放所有历史更有扩展空间。

但收益有明确前提：结果需要能记录，优劣需要能判断，摘要还得保留关键条件。原文也承认，证据压缩可能遗漏细节，导致工作代理选择次优方向。把历史移出模型，只是把上下文管理变成了系统工程，并没有让它自动变可靠。

相比滚动摘要或按需检索旧记录，SLA 更强调由外部框架保存历史、按角色组织输入，再由 Advisor 分配实验。原文没有给出与这些替代做法的直接对照，因此无法判断收益中有多少来自外部存储，又有多少来自任务分工和证据筛选。

实验结果支持在这三个工程领域继续验证，尚不足以证明它适用于所有长期研究。

至于短预算结果将因此过时，这是作者对未来的判断，原文提供的证据还不足以支持如此宽泛的结论。

能拿来做什么

• 给日常 AI 编程任务单独保存候选补丁、测试结果和失败原因，下一轮优先提供相关记录，避免每次塞入完整终端输出与聊天历史。
• 对前端或 Node 性能优化任务，把候选改动、运行条件和测量结果一起保存，让后续比较能追溯到相同条件。
• 评估 Agent 时，同时比较最终质量和达到同等质量所需的 token，并增加运行轮数，检查短任务里看不出的历史累积成本。
• 检查摘要是否保留失败条件和未验证假设；一旦结论存在歧义，让工作代理能够回查原始记录。