长时程 Agent 跑着跑着开始"烧 Token 不出活"，症状通常有三种：不断重放越来越长的历史、两个 Agent 撞车做同一件事、反复宣称任务已完成而实际没有。一篇 2026 年 10 月挂上 arXiv 的论文（Stanford、CMU、UW 与 SambaNova）把这三种失效归因到同一个设计问题：研究状态存在哪里、由谁决定下一步。他们的答案叫 SLA——有状态搜索，无状态智能体。
核心动作：状态和对话彻底分离
SLA 的原则一句话能说完：任何 Agent 都不在多次调用之间携带自己的对话。外围执行框架（harness）持有全部研究状态——候选解、实测分数、失败记录——并在每次调用时为角色重建一份全新的上下文。
这和常见做法的区别在于：多数支持并行子 Agent 的框架里，编排者本身有状态，它保留自己的会话并决定子 Agent 看什么。SLA 里连 Advisor 都无状态，上下文构成完全由 harness 显式决定。"Agent 能看到什么"从"随运行不断变长的历史"变成了一个设计选择。
两类角色的上下文分开构造：Advisor 拿全局证据——任务规格、当前最优解与分数、按搜索方向分组的结果摘要；Worker 只拿自己的任务分配、自己保留的候选解和紧凑的局部反馈，看不到彼此的工作区，也看不到完整历史。每个 Agent 每次"重启"都是从干净上下文出发，避免从"当初决定停下的那段对话"里继续重放旧决定——那正是过早停机失效的根源。
数字怎么来的，代价是什么
论文最硬的一组数据在内核优化任务上、10 亿 Token 预算下：SLA 用 67.9M Token 就达到了最强基线 SwarmResearch 用 986.3M Token 才达到的性能——Token 少用约 93%。规划层本身极便宜，Advisor 只占全部 Token 的 0.24%–0.51%。
但有三笔代价别漏看：
- 前提是任务有确定性评估器。论文里所有任务都能程序化打分；目标模糊、评估缓慢的任务没有被测试，直接套用等于无米之炊；
- 省 Token 不等于省钱省时间。并行 Worker 会推高瞬时推理量，"累计 Token"衡量的是用量不是账单，端到端成本要自己算；
- 工程量转移到了 harness：状态 schema、证据摘要、失败归因、Worker 隔离，全要自己搭。
动手改造的五步
如果自家 Agent 已经出现重放历史、撞车、假装收敛的迹象，且任务有客观打分，改造路径如下：
- 先定义持久状态 schema：任务规格、候选解集合、实测分数、按方向分组的证据、每个 Worker 的局部候选与反馈。全量日志只追加、只给 harness 读；
- 为每个角色写上下文构造函数：Advisor 拿跨方向汇总，Worker 拿分配加局部反馈。核心纪律只有一条——没有任何 Agent 继承上一轮的对话；
- 隔离 Worker：独立工作区、独立评估，防止互相污染；
- 把失败归因做实：区分"实测无改进"和"因实现或运行问题结论不明"——混为一谈会让规划层误判方向已穷尽，提前放弃有希望的路；
- 多预算点评估：至少在 25%、50%、100% 累计 Token 三个点报告进展。论文自己就演示了短时程的误导性——SLA 在 25% 预算时落后于基线，全预算时反超。只用一个预算点评估长程系统，结论大概率是反的。
和有状态路线怎么选
值得对照的另一条路线是有状态 Agent 加固定窗口：把状态挂在 Agent 自己身上，在固定窗口内以常数成本运行，超参调优场景 Token 也省了九成。两者的分野不在省不省，在谁掌管上下文：harness 掌管（SLA）换来可复现、可审计、可并行；Agent 自持换来实现简单、行为连续。评估器是否确定、是否需要严格复现实验、团队工程能力，这三个问题的答案基本就能定方向。
长跑 Agent 的账已经算得很清楚：把"记住一切"的负担从模型身上卸下来，交给确定性的代码，是目前性价比最高的一步改造。
评论0