关于长跑智能体，此前的主流认知是「上下文不够长」「token 烧太多」。一篇来自微软研究团队的工作把这套认知倒过来：上下文不是太短，是太黏。
论文作者包括 Ziyang Cai、Christos Ziakas、Vasilis Kontonis、Tim Pearce、Siddhartha Sen、Akshay Krishnamurthy、Shivam Garg 与 Dimitris Papailiopoulos。方法叫 Fork-and-Flush，10 月中旬经 The Decoder 报道后在工程圈引发不小讨论。
它研究的对象叫 autoresearch 智能体——反复提出解法、按分数评估、再据此修改的循环。比如一个花几小时不断改进调度算法、装箱算法或密码分析攻击的智能体，边跑边保存文件和结果。任务形态与现在流行的编码智能体、长任务代理是同一类循环。
八次运行，八个分数
研究人员把同一个智能体在同一任务上跑了八次。最终分数落在 68.3 到 100.0 之间——跨度 31.7 分。
关键的一句在后面：给这些运行多得多的算力，这个差距并没有收窄。这不是算力不足的问题。
他们把八次运行的解按功能相似度嵌入同一张二维图，让相似的解彼此靠近。结果很清晰：任何单次运行的解，几乎总是挤在一小块区域里。作者把这块区域叫做「想法盆地」（idea basins）。
接下来发生的事才是代价的来源：落进低分盆地的那些运行，会把大量剩余算力花在把原方案磨得更细上——而更好的解早被别的运行在另一个盆地里找到了。论文还验证了一件更麻烦的事：定期压缩对话历史也无法消除这个模式。也就是说，摘要、裁剪这些常规手段在这里救不了场。
解法：保留工作区，扔掉对话
Fork-and-Flush 由两个动作组成。
Fork（分叉）是把智能体拆成 K 条并行分支，每条分支继承此前的工作区——代码、文件、已保存的结果全部带走，但每条分支的对话上下文被清空，从一段新的对话开始，在已有的工作之上继续。到固定时限后，系统按分数选出最优的那条分支继续跑，其余丢弃。
它和 SLA 构成一个真实的学术分歧
同一时间线上，另一条相关工作走的是相反方向。arXiv 2610.07625 的 SLA（Stateless Language Agents，来自 Stanford、CMU、UW、SambaNova 等）主张：有状态搜索、无状态智能体——任何智能体都不要跨调用携带自己的对话，研究状态全部由 harness 持有，每次调用现场重建一份针对角色的新上下文。SLA 的目标很明确：省 token，论文报告在最高十亿 token 预算下省下 84%，且 Advisor 本身只占不到 0.6% 的 token。
而 Fork-and-Flush 的做法是：主动、周期性地把对话历史扔掉，工作区该留的一定要留。它的目标不是省钱，是恢复搜索多样性。
这两篇不构成谁对谁错的反驳，因为它们处理的是不同的问题。把它们并起来读，能得到一个更有用的结论：同一份对话历史，既是账单，也是路标。它让你反复读懂自己做过什么、要花多少 token（账单功能）；它也把你钉在已经想过的方向上（路标功能）。要不要留，取决于你当前更怕烧钱，还是更怕不换路。SLA 选前者，Fork-and-Flush 选后者。
数据：清空对话这一招，贡献了大部分收益
论文的评测覆盖 13 个长跑任务，包括多联骨牌装填、车间调度、密码分析、CIFAR 分类器压缩和 VLIW 内核优化。单次运行时长从数小时到 100 小时以上，智能体由 GPT-5.6-terra 与 GPT-5.5 经 GitHub Copilot CLI 驱动。
等算力下的 min-max 归一化平均分：单次运行 0.47，best-of-4 是 0.54，Fork-and-Flush 是 0.78。相对提升分别是对单次运行的 66.0% 和对 best-of-4 的 44.4%。13 个任务中有 12 个的均值最高。
更有信息量的是两个拆解。
其一，只清空对话、不做分支，在 11 个任务上把分数从 0.45 提到 0.55，约 +22%。也就是说 Fork 和 Flush 里，分支的贡献不是主要部分，扔掉对话才是。这是全文最反直觉也最实用的一条——最便宜的干预，可能就是清空聊天而保留工作文件。
其二，归一化标准差从单次运行的 0.26 降到 0.16（best-of-4 是 0.21）。也就是说一致性同时变好了。在生产环境里，一个平均分高 0.3 但方差也高的方案，和一个方差收窄一半的方案，价值并不相同——后者意味着更少的意外和更可预测的排期。
更强的模型能自己绕过去吗
论文还做了一次追问：如果模型足够强，思路够多，是不是就不容易掉进盆地？
用 Qwen3.5-4B、9B 和 27B 三个尺寸在 MAX-3-SAT 上测，运行间的方差呈倒 U 型——峰值出现在任务难度正好在模型能力边缘的位置，大致是随机猜测和参考求解器表现的中点。三个尺寸都是这个形状。
原因不难理解：太简单的任务模型几乎必过，太难的任务几乎必败，两头都不会产生分歧。分歧只发生在模型「有时行有时不行」的那条带上。
这个结果有一个不太舒服的推论。论文作者的说法是：开放研究问题恰好位于模型能力的边界附近，随着模型变强，这条边界以及边界附近的运行间方差，会一起往更难的问题上移。换句话说，换更强的模型不会让这个问题消失，只会把它推到更前面。
对工程团队来说，这篇论文最实际的价值提供了一条可以立刻试的改动：如果你在跑长任务、跑优化类任务，或者在用智能体做自动化研究，试试周期性分叉并清空对话上下文。成本是多烧一些并行算力，收益是恢复多样性。需要注意的是，论文的 arXiv 页面上未链接专门的代码仓库，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。