ABSeeker细化搜索智能体训练归因

大多数搜索 Agent 的训练仍有一个偷懒的习惯：等到一轮漫长的浏览过程结束后，检查最终答案是否正确，然后据此把整条轨迹判定为好或坏。

这对训练循环来说很方便，但调试不是这么做的。

如果一个 Agent 花了十五个步骤进行搜索、快速浏览、顺藤摸瓜、排除糟糕的页面，并把证据拼接起来，那么最终答案只能告诉你故事的最后一句。一次失败的运行，可能包含三个非常出色的检索动作，以及一次致命的绕路。一次成功的运行，也可能充斥着大量多余的点击，只是碰巧最终落在了答案附近。

8 月 5 日发布在 arXiv 上的新论文 ABSeeker 很有意思，因为它直接针对这种错位提出了解决方案。论文中的方法叫作 Answer-Backtracked Credit Assignment，简称 ABC。这个名字有点拗口，但思路很实用。

ABC 不会把整条搜索轨迹视为一个整体来奖励，而是从已知答案出发，反向回溯。它会找出解决这个问题所需的中间线索，再根据这些线索给每个搜索步骤评分。即使整条轨迹最终失败，有用的动作也能得到正向 credit；即使最终答案碰巧正确，糟糕或重复的动作也会受到抑制。

这更接近我理想中的 Agent 训练方式。我们不应该只问“最终字符串匹配了吗？”，而应该问：“这次运行中的哪些环节，真正推动了任务向前进展？”

常见的训练信号过于粗糙

长程搜索的混乱程度，是单轮 benchmark 无法比拟的。

一个还不错的搜索 Agent 必须拆解问题、决定搜索什么、打开信息源、判断页面是否无用、优化查询、在上下文中保留证据，最后才能给出答案。真正重要的错误往往发生在中途：Agent 相信了错误的页面；搜索了错误的实体；找到了线索，却没能保留下来；因为上下文窗口已经塞满了混乱信息，它又重复执行了一次查询。

最终奖励会掩盖这一切。

这也是为什么长程 Agent 在演示中看起来很出色，到了真实工作流里却没那么好用。benchmark 只关心通过还是失败，操作者则关心整个过程，因为只有过程才能告诉你：Agent 究竟变得更可靠了，还是只是运气更好。

监督微调也存在同样的问题，只是换了一层外衣。如果成功轨迹中的每个步骤都被视为同样优秀，模型就会在学习有效行为的同时，也把噪声一起学进去。如果失败轨迹中的所有步骤都被丢弃，你也会同时扔掉其中那些实际上正确的部分。

当搜索轨迹的获取成本很高时，这笔交易非常不划算。

ABC 把答案变成评分标准

ABSeeker 最巧妙的一步，是反向评分。

给定一个问题及其 ground-truth answer，ABC 首先执行 answer-backtracked clue recovery。通俗地说，它会追问：哪些中间事实或线索能够引导 Agent 得到这个答案？然后，它利用这些线索为 Agent 的每个搜索步骤评分。

这样一来，稀疏的结果就能转化为密集的监督信号。最终答案不再是唯一的信号，每一轮操作都能获得更准确的标签。

论文通过两种方式使用这种信号。

ABC-SFT 根据步骤质量重新加权监督微调的 loss，让有用的轮次在模仿学习中发挥更大作用。ABC-GRPO 则把步骤级评分引入强化学习，让真正推动搜索过程的部分获得奖励。

论文报告的结果，值得关注小模型的人认真看看。作者基于 Qwen3.5-4B base model，使用 8,500 个样本训练 ABSeeker。他们报告的 BrowseComp 得分为 37.3%，BrowseComp-ZH 得分为 39.1%。引入上下文管理后，两项得分分别提升到 55.3% 和 52.9%，在论文的对比中追平甚至超过了参数规模大得多的 Agent。

不要过度解读排行榜上的具体数字。benchmark 会变化，baseline 的选择会影响结果，而且 arXiv 论文并不等于生产系统。真正有价值的是一个更基础的结论：更好的 credit assignment，可以让模型从同一批搜索数据中学到更多东西。

这才是最值得借鉴的部分。

真正的实践启示在于可观测性

这篇论文以训练方法为主题，但我认为它在实际运行层面的启示要更加广泛。

如果你在真实工作中运行 Agent，就需要保存步骤级的凭证。只有最终答案远远不够。

对于 coding agent，这意味着保留计划、命令、diff、测试输出和回滚路径。对于 research agent，这意味着保留搜索记录、打开过的信息源、采纳的证据、排除的证据，以及结论发生变化的位置。对于客服或运维 Agent，这意味着保留为某项操作提供依据的准确状态检查结果。

没有这样的轨迹，你就无法分辨能力与运气。你也无法干净地训练或调优系统，因为你不知道究竟哪个动作应该获得 credit。

这正是许多 Agent 技术栈仍显得建设不足的地方。工具列表很长，模型路由器很炫，但轨迹记录却成了事后才想起来的东西。

然后某件事失败了，唯一能得到的解释就是：“Agent 弄错了。”这不叫解释，只是在耸肩的同时附上了一段 stack trace。

我更愿意优化运行过程，而不是崇拜答案

ABSeeker 并不是解决长程 Agent 问题的万能方案。它依赖 ground-truth answer、线索恢复的质量，以及那些最终答案确实可知的 benchmark。真实工作要更混乱。有时，Agent 还在搜索，答案本身却已经发生了变化。有时，正确的做法是停下来询问人类。有时，信息源具有权威性，却依然是错的。

但这个方向是对的。

Agent 正在变得不再像 autocomplete，而更像一个个小型工作流程。工作流程需要审计轨迹。有了审计轨迹，你才能更好地训练、更好地评估，也能更好地调试。

这是 Agent 进步中乏味的那一半，而这通常意味着，它恰恰是更重要的那一半。

最终答案只能告诉你这次运行是否有一个好结果。轨迹则能告诉你，系统是否正在养成正确的习惯。

我会选择轨迹。

来源：ABSeeker：通过 Answer-Backtracked Credit Assignment 训练长程搜索 Agent

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。