上下文是套在智能体身上最硬的一根绳。ReAct 式打法把观察、中间结果、失败尝试全堆在同一个上下文里，堆得越久，过期和跑偏的内容越占地方，想找的证据越发埋得深。10 月 14 日提交 arXiv 的 TreeFlex（编号 2610.20334）换了个问法：不压信息，改问「接下来该回到哪一段」——让智能体在一棵自己长出来的搜索树里，自己决定往哪搜。
一个模型，两个身份
TreeFlex 的结构可以一句话讲完：harness 替智能体维护一棵搜索树，每个中间状态配一条短摘要存成节点；同一个语言模型轮换两个身份干活。Reflection 身份只看各节点的摘要，拥有全局视野，负责挑一个节点恢复，并附上一条指令；Execution 身份接手时，harness 先把通往该节点的路径还原出来，模型带着常规任务工具把指令执行下去，直到存下一个新节点，或者抛出一个方案——再由 Reflection 批准，或者打回到别的节点上去。
这个设计里最值得停下来看一眼的，是「往哪搜」的决定权。深挖当前这条线、从更早的状态分叉、回头访客旧节点、先验证再收工、或者干脆收工——策略自己权衡，没有固定的遍历顺序，也不给每个节点打一个分。导航从工程算法变成了被训练的对象，这是它和过往上下文管理方案最根本的分野。
把两张成绩单摆在一起看
在一项高难度深度研究基准上（摘要未点名具体基准，需回原文确认），4B 模型小规模 RL 之后、所有方法共用同一活跃上下文上限：TreeFlex 48.8%，扁平 ReAct 41.5%，FoldAgent 42.8%，Pass@8 还比两者各高出约 10 个点。换到 SWE-bench Verified，三个系统都从同一个 9B 模型 RL 起跑：TreeFlex 解掉 54.9%，FoldAgent 43.3%，FoldAgent 的步进变体 45.2%。对照的两位恰好代表上下文管理的老路子——ReAct 把历史堆成一列，FoldAgent 把历史折起来；TreeFlex 既不堆也不折，它修了一条可以随时跳转回来的路。
和压缩路线不是一回事
本站解读过的几条上下文管理方案，底色都是「丢」：Claude Code 2.1.299 的空闲压缩（1904）在会话停滞时把旧历史换短，AutoCompact（1650）学着压，Remory（1788）在压缩里留残差。TreeFlex 反着来：全量历史都在，只是不常驻上下文，而是住在树里，靠摘要导航、按需还原。代价它没在摘要里算——维护树、写摘要、还原路径都要 token 和工程量，这笔账只有读了原文的预算章节才能评估。
放进赛道里看
顺着既有叙事接两根线。一根接 1882 的 SOAR：搜索智能体编造证据的病灶，一半在「该查的没查、查完就忘」；如果导航本身变聪明，证据链的成色理论上跟着受益。另一根接 1908 的「交付债」：上下文管理正是单机可靠性层里最具体的一笔工程债，TreeFlex 把还债的希望寄托在「结构」而非「压缩」上。对做会话产品的团队，它的启示甚至先于分数：如果树状回跳真成立，「历史记录」的产品形态该从一列流水账改成一张可回跳的地图。
需要保留的怀疑
边界划清楚。4B 与 9B 都是小规模 RL 的展示环境，放到前沿骨干上增益是否还在，摘要没给答案；深度研究基准在摘要里没点名，复现时对不齐卷子；对照组只有 ReAct 与 FoldAgent 两家，没有和压缩类方法同场对比；树深了之后，摘要写得好不好直接决定导航质量，而摘要本身又是新的单点故障。它现阶段的价值在于把问题问对了，读数是否惊艳要等第三方验货。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。给工程团队的一条动作：如果你们的智能体已经在长会话里「迷路过」，别急着上加压算法，先看看历史是不是压根没有办法回跳——导航和压缩，治的不是同一种病。