摘要 ：微软研究院10月5日挂上arXiv的论文《Fork-and-Flush》揭示了一个反常识结论：同一个Agent跑同一个任务八次，分数从68.3到100.0，差了30多分。砸算力追不回来，因为Agent掉进了"思维盆地"。解法简单粗暴：定期清空聊天记录。记忆不是越多越好，清空比积累更有效。
一、八次运行，五个盆地
研究团队把每次运行产出的方案按功能相似度画成二维地图，发现每次方案都缩在地图的一小块区域里，从头到尾没怎么挪窝。他们给这种区域起名：思维盆地（Idea Basin） 。八次运行掉进了五个不同的盆地。
聊天记录，就是Agent手机里那些参考图。前几轮推理得出的方向，会持续牵引后续探索路径。哪怕定期压缩历史，Agent还是把大量算力花在打磨盆地内的次优方案上。
更关键的是：这些Agent本来就有自动压缩机制，但实测下来，光靠压缩摘要，跳不出盆地 。压缩只是把旧内容缩短，没有改变"旧内容在牵引新推理"这个事实。
二、Fork-and-Flush：分叉+清空
解法只有两步：
| 步骤 | 操作 | 作用 |
|---|---|---|
| 分叉（Fork） | 把Agent复制成几个并行分支，每个分支继承完整工作区（代码、文件、实验结果） | 在多个盆地里同时找 |
| 清空（Flush） | 每个分支的聊天记录清零，让Agent从工作区文件重新推导意图 | 跳出旧盆地 |
新分支必须从文件里重新推导自己的意图，这正是它能落到另一个盆地里的原因。推理路径断了，但工作成果还在。
三、消融数据：1+1>2
| 配置 | 归一化平均分 | 相对单次运行提升 |
|---|---|---|
| 单次运行 | 0.45 | --- |
| 只清空对话，不分叉 | 0.55 | +22% |
| 只分叉，不清空 | 0.57 | +27% |
| Fork-and-Flush（清空+分叉） | 0.71 | +58% |
清空解决"跳出盆地"，分叉解决"在多个盆地里同时找"。两个加在一起，效果才好。
在13个长周期任务（多连块拼图、车间调度、密码破译等）上，Fork-and-Flush在12个任务上平均分最高。稳定性也同步改善：归一化标准差从0.26降到0.16。
四、盆地不随模型变强而消失
研究者用Qwen3.5-4B、9B、27B三个尺寸在MAX-3-SAT上测试。更大的模型有更强的推理能力，但同样会被聊天历史牵引。路径依赖是上下文结构问题，不是模型能力问题。
五、三个可落地的操作
① 定期清空聊天记录，保留工作区。 每跑固定时间或步数，清空对话上下文，让Agent从代码和文件中重新推导。不要依赖自动压缩摘要。
② 分叉探索，择优保留。 复制成多个分支，每个分支带着同一工作区、从空白聊天记录出发，跑固定时间后比较分数，留最好的。
③ 把清空设计成流程的一部分，而不是异常处理。 Fork-and-Flush用固定节奏（三次fan-out），而非检测"是否掉进盆地"。检测很脆弱，固定节奏更可靠。
可直接用GitHub skill：hetankevin/fork-and-flush，实现了Claude Code和Codex的完整流程。
边界提示：分叉越多，单分支算力越少；工作区必须包含足够上下文（README、注释、实验记录），否则清空后重新推导可能失败。
查看原文
以上仅为核心速览。完整版包含：思维盆地的完整形成机制拆解、Fork-and-Flush与自动压缩的本质差异分析、13个长周期任务的完整实验数据、边界条件与固定节奏vs自适应检测的取舍、以及GitHub skill的完整使用指南。
本文首发于微信公众号「阿Q的AI笔记」，点击下方链接阅读全文：
我拆了微软的Fork-and-Flush：Agent跑8次分数差30分，原因不是算力不够，是聊天记录在拖后腿
关注公众号
如果你想持续追踪Agent上下文管理的前沿研究、获取Fork-and-Flush的一手实操经验，欢迎关注公众号「阿Q的AI笔记」。