无状态 Agent：研究状态交给 harness，token 省 84%–93%

这篇论文到底提出什么

2026 年 10 月 6 日提交到 arXiv 的《Stateless Language Agents: Scaling Long-Horizon Automated Research》，作者来自 Stanford、CMU、UW 与 SambaNova（Qizheng Zhang、Changxiu Ji、Kunle Olukotun 等）。它把长时程自动研究（autoresearch）里的失效模式，直接归因到两个设计问题：研究状态存在哪里，以及由谁决定下一步试什么。

作者给的答案叫 SLA（Stateless Language Agents），原则一句话概括：有状态搜索，无状态智能体（stateful search with stateless agents）。任何 Agent 都不在多次调用之间携带自己的对话；harness（外围执行框架）持有研究状态——候选解与实测结果——并在每次调用时重建一份全新、针对角色的上下文。于是「Agent 能看到什么」从「随运行不断变长的历史」变成了一个显式的设计选择。

这里的 harness 指模型与工具之间的运行时：它负责存储状态、重建提示、调度 Worker、记录评估器结果。注意与常见做法的区别——多数编码 Agent 也支持并行子 Agent，但编排者本身是有状态的，它保留自己的对话，决定每个子 Agent 看到什么、何时停。SLA 里连 Advisor 都是无状态的，上下文完全由 harness 决定。

为什么长跑 Agent 会「烧 token 不出活」

论文把问题拆成三个具体观测到的失效：

1. 重放历史。候选解、评估结果、失败尝试可能很久以后才有用，但每次都把不断增长的历史重新喂进去，token 持续消耗。
2. 重复劳动。在 CORAL 的 FrontierSWE libexpat 轨迹里，两个 Agent 从同一父解出发实现了同一功能、拿到同一分数，下一个功能上又撞车——尽管其中一个 Agent 已经贴了「我在做这个」的笔记。
3. 过早停机。在 GPU kernel 运行里，Agent 反复宣称自己的候选已最优然后等待，即便被提示继续、被重启也一样。原因很微妙：CORAL 重启时会恢复该 Agent 自己的会话，于是它从「当初决定停下的那段对话」里继续，多出来的推理基本在重放那个决定。

论文还引了一项对照：coding agent 的会话拉到 1 亿 token 量级后，前期比独立采样进步快，会话越长越落后——把一个固定预算拆成几段更短的会话，可能比一个超长会话更强。这直接指向核心矛盾：既要保住可复用的证据，又要给每个 Agent 挑选它当前决策真正需要的那部分。

SLA 的机制：两类上下文，各自重建

SLA 每一轮（epoch）做全局规划，然后在局部做实验，循环往复。关键是把「状态」和「上下文」彻底分开：

Advisor 上下文（全局决策用）：每个 epoch，harness 重建 Advisor 的全局证据上下文——任务规格、当前全局最优的代码与分数、以及 harness 生成的证据摘要。摘要覆盖近期尝试、按搜索方向分组的结果、Worker 状态、近期进展，外加任务特有的诊断信息。它还会把「实测没有改进」与「因实现、运行或正确性而结论不明的失败」分开，避免把一个跑挂的实验误判为该方向已穷尽。

Worker 上下文（局部实验用）：每次试验，Worker 只拿到自己的任务分配、自己保留的候选解、以及紧凑的局部反馈（上一轮状态、实测分数、可用的正确性诊断）。Worker 之间不能访问彼此的 workspace，也看不到完整研究历史。

每个 Worker 在独立 workspace 里跑若干局部试验，独立评估器给每个候选打分，harness 记录结果并更新 Worker 的局部候选与全局最优，直到预算耗尽。每个 Advisor epoch、每个 Worker trial 都是一次调用，每次调用开一个新会话，只有 harness 记录进研究状态的东西才跨调用保留。

这套结构可以浓缩成伪代码：

# harness 是唯一持有持久状态的地方
state = {
    "task": task_spec,
    "global_best": {"code": ..., "score": ...},
    "experiments": [],       # 追加式全量日志，只有 harness 读
    "directions": {},        # 按搜索方向分组的证据汇总
    "workers": {},           # 每个 Worker 的候选解 + 最近反馈
}

def run_epoch():
    # 1) 重建 Advisor 上下文：喂汇总证据，不喂原始历史
    adv_ctx = build_context(
        task=state["task"],
        best=state["global_best"],
        evidence=summarize(state["experiments"]),
    )
    assignments = call_agent("advisor", adv_ctx)   # 全新会话

    # 2) 每个 Worker 独立会话、独立 workspace
    for a in assignments:
        w = state["workers"][a.id]
        worker_ctx = build_context(
            task=state["task"],
            assignment=a,
            candidate=w["candidate"],
            feedback=w["feedback"],   # 上轮状态 / 分数 / 诊断
        )
        result = call_agent("worker", worker_ctx)  # 不继承其他 Worker 对话
        score = evaluate(result)
        state["experiments"].append((a, result, score))
        update(w, result, score)

对比之下，SwarmResearch 的探索型 Search Agent 用全新上下文窗口，而优化型 Search Agent 会 fork 父 Agent 的对话历史；CORAL 则是长期运行的 Agent 加共享持久记忆。SLA 的不同在于：连编排者都无状态，且上下文的构成是 harness 的显式契约。

84%–93% 这个数字怎么来的

论文在软件工程、内核优化、算法设计三类任务上，把预算拉到最高 10 亿 token，与三个近期框架对比。结论是 SLA 在每项任务上都取得最佳最终结果。

最硬的一组数据在 Anthropic 内核优化任务上，用 Codex/GPT-5.5、10 亿 token 预算：SLA 平均周期数 1112.0（越低越好），最强基线 SwarmResearch 为 1275.7。SLA 累计消耗 67.9M token 就达到了 SwarmResearch 的平均最终性能，而后者用了 986.3M token——报告称 token 少用 93.1%，约 14.5 倍。 摘要里概括为「追平最强内核基线的最终性能，token 减少 84% 以上」，覆盖到 93% 的区间。

Advisor 本身很便宜：只占 0.24%–0.51% 的 token、至多 2.3% 的模型成本（摘要口径为「不到 0.6% 的 token」）。这与「规划层开销小、执行层省得多」的直觉一致。

消融实验用共享检查点做，每个变体从同一保存状态续跑、各续跑 1 亿 token、三次独立运行。以 FrontierSWE libexpat 从 7000 万 token 检查点续跑为例（起分 16.12）：完整 SLA 达到 18.78 ± 0.92，而取消 Advisor 任务分配的变体只有 16.54 ± 0.33——相当于放弃了该检查点之后所获进展的 84.2%。整体上，去掉 Advisor 上下文重建、Worker 上下文隔离或 Advisor 任务分配中的任意一项，每项比较的平均进展都下降。

还有一组时间尺度上的发现：在 FrontierSWE 上，SLA 在 1.75 亿 token 时落后于最强基线，到 7 亿 token 时才反超；在 25% 预算时落后，全预算时领先。宽 Worker 池在 25% 预算时落后 337 个周期，到全预算时与最窄配置只差 4 个周期。作者据此建议：报告进度时要在多个累计 token 预算下给结果——短时程评估会系统性误判研究系统及其组件。

与同类方案的取舍

这条路线并非只有 SLA 一家，方向甚至相反，值得摆在一起看：

• 有状态 Agent + 固定窗口（Stateful ReAct）：《Remember, Don't Re-read》把 autoresearch 重写成用 LangGraph 的有状态 ReAct，用类型化持久状态跨迭代携带实验历史。超参调优上 token 少 90%（2,492 vs 24,465），代码优化少 52%（627K vs 1,275K）。其机理是结构性的：无状态 Agent 每轮以 O(n) 重读全历史、总计 O(n²)，有状态 Agent 在固定窗口内以 O(1) 运行。和 SLA 一样是「把状态搬出对话」，但状态挂在 Agent 自己身上（有状态 Agent），而不是由 harness 统一掌管。
• 分层记忆（HORMA）：把经验组织成文件系统式层级，摘要实体挂到原始轨迹，构建+导航两段式，长对话任务里最多只用到基线 22.17% 的 token。
• 上下文本体感知（VISTA）：不压缩、不删证据，而是把工作记忆变成可寻址块，向模型暴露每块的 token 成本、新鲜度、归档状态和剩余预算，归档为可无损恢复的载荷；LOCA-Bench 上把 Gemini-3-Flash 从 22.7% 提到 50.7%。它解决的是「模型对自己的上下文状态盲目」。
• harness 侧的整体经济学：Writer harness 用「字节稳定的缓存前缀 + 结构化增量压实 + 上下文卸载 + 零 token 等待」等机制，实测 99.9% 的提示 token 走缓存读，harness 层降本对所有模型同时生效。另一篇《Token Reduction Is Not Cost Reduction》则提醒：省 token 不等于省钱，端到端任务成功率与计费成本才是真指标。

SLA 的取舍很清楚：它放弃了「Agent 自己记得住」的便利，换取可复现、可审计、可并行、上下文可被显式设计。 代价是 harness 要承担更多工程——状态 schema、证据摘要、Worker 隔离、评估器接线，全都得自己搭；而且它假设任务有可执行评估器（论文所有任务都满足），目标模糊、评估缓慢的任务未被测试。

还有一条重要限定：所谓「累计 token」是整个运行的输入+输出之和，不是经过的时间。它衡量 token 用量，不能证明实际运行时间更短或总费用更低——并行 Worker 会推高瞬时推理量。复现范围也有限：只有 Anthropic 内核优化任务和检查点消融被复现过，且每方法只跑一次。

适合谁用，怎么上手

适合这几类场景：需要跑很久的自动研究/优化（内核、算法、超参、代码性能），任务有确定性评估器能给候选打分，并且你关心的是单位算力买到的进展（quality per token）而非峰值耗时。

上手路径大致是：

1. 先把状态外置。定义一份持久状态 schema：任务规格、候选解集合、实测分数、按方向分组的证据、每个 Worker 的局部候选与反馈。全量日志可追加，但只给 harness 读。
2. 为每个角色写一个上下文构造函数。Advisor 拿跨方向汇总；Worker 只拿自己的分配 + 候选 + 局部反馈。核心纪律是：没有任何 Agent 继承上一轮的对话。
3. 隔离 Worker，独立 workspace、独立评估，避免互相污染；用分支/工作区承载不同候选。
4. 把证据汇总和失败归因做实：区分「实测无改进」和「实现/运行/正确性导致的不明失败」，否则 Advisor 会误判方向。
5. 多预算点评估。至少报 25%、50%、100% 累计 token 下的进展，避免被短时程数字误导。

一句话判断：如果你的 Agent 长跑后开始「重放历史、撞车、假装收敛」，而任务又有客观打分，那么把状态搬进 harness、让 Agent 每次从干净上下文出发，是低风险、高杠杆的一步。

参考链接

1. Stateless Language Agents: Scaling Long-Horizon Automated Research — https://arxiv.org/abs/2610.07625
2. Stateless Language Agents（HTML 全文） — https://arxiv.org/html/2610.07625v1
3. SwarmResearch: Orchestrating Coding Agents for Open-Ended Discovery — https://arxiv.org/abs/2607.02807
4. Remember, Don't Re-read: Stateful ReAct Agents for Token-Efficient Autonomous Experimentation — https://arxiv.org/abs/2606.14945
5. Organize then Retrieve: Hierarchical Memory Navigation for Efficient Agents (HORMA) — https://arxiv.org/abs/2606.11680
6. LLM Agents Are Latent Context Managers: Eliciting Self-Managed Context via State Proprioception (VISTA) — https://arxiv.org/abs/2606.30005
7. Token Reduction Is Not Cost Reduction: An Empirical Study of End-to-End Efficiency in API-Based Coding Agents — https://arxiv.org/abs/2607.12161

创作说明：本文在资料整理与成文中使用了 AI 辅助（DeepSeek），经作者审阅后发布，作者对内容负责。