#Web Search Agent 与 Code Agent 的 Agentic RL 演化路径：从“会调用工具”到“会在环境里学习”

这篇文章基于 Awesome-AgenticLLM-RL-Papers 中的两个任务分区：Search & Research Agent 和 Code Agent。我不打算把它写成论文清单，而是尝试回答一个更核心的问题：

为什么 Web Search Agent 和 Code Agent 会成为 Agentic RL 最自然、最先爆发的两个方向？它们各自是沿着什么问题链演化的？

一句话结论是：

Web Search Agent 的演化主线，是从“LLM 会不会用搜索工具”走向“LLM 能不能在长程信息搜集过程中学习搜索策略”；Code Agent 的演化主线，是从“LLM 能不能写出通过测试的代码”走向“LLM 能不能在真实软件环境里通过反馈持续修复、规划和改进”。

这两个方向看似不同：一个面向开放互联网信息，一个面向代码与软件仓库。但它们在 Agentic RL 里有同一个底层结构：

1. 都有外部环境：搜索引擎、网页、解释器、测试器、仓库、issue、CI。
2. 都有可验证反馈：答案是否正确、引用是否支持、测试是否通过、patch 是否解决 bug。
3. 都有长轨迹决策：不是一步生成，而是多轮查询、阅读、推理、执行、修复。
4. 都暴露了传统 SFT/RLHF 的不足：只模仿最终答案不够，必须学习过程策略。

所以 Web Search Agent 和 Code Agent 不是 Agentic RL 的两个随机应用，而是最像“真实智能体训练场”的两个方向。

#1. 先建立一个总框架：Agentic RL 到底在训练什么？

传统 LLM 后训练通常训练的是：

• 给定 prompt，生成一个更好的 response；
• 给定两个 response，偏好其中一个；
• 给定数学题或代码题，用最终正确性做 RLVR。

但 Agentic RL 训练的是另一类对象：

不是单个回答，而是一个在环境中行动的策略。

这个策略至少包含五种决策：

从这个角度看，Agentic RL 的核心不是“把 RL 套到 LLM 上”，而是把 LLM 从 answer generator 变成 environment-interacting policy。

#2. Web Search Agent：从检索增强到“可训练的搜索智能体”

#2.1 旧问题：RAG 会检索，但不会真正“搜索”

早期 RAG 解决了一个重要问题：LLM 参数知识会过时、不完整，所以让模型从外部文档库取回相关文本，再基于文本回答。

但 RAG 的基本假设很强：

• 用户问题通常一次性映射到若干相关文档；
• 检索器负责找资料，LLM 负责读资料；
• 查询通常是单轮的；
• 检索结果被动进入上下文。

这适合“已知问题、已知文档库、相对简单问答”，但不适合 deep research。

真正的研究型搜索任务里，模型经常不知道自己该搜什么。它需要先提出假设，再拆问题，再查证，再发现新概念，再继续追问。也就是说，搜索不是一个前处理模块，而是推理过程的一部分。

这就是 Web Search Agent 的起点：

搜索不再是 RAG pipeline 里的 retrieve step，而是 agent trajectory 里的 action。

#2.2 第一阶段：把搜索工具接进推理链

仓库中的 DeepRetrieval、Search-R1、R1-Searcher、ReSearch 等工作，可以看成这一阶段的代表。

它们试图解决的问题是：LLM 已经具备一定 reasoning 能力，但遇到知识缺口时，能不能主动调用搜索工具，并把搜索结果纳入后续推理？

这里的关键变化是 action space 发生了变化：

• 过去模型只能输出文字；
• 现在模型可以输出 search(query)、read(page)、answer(...) 这类动作；
• 环境返回搜索结果或网页内容；
• 模型继续根据新 observation 做下一步决策。

用人话说：

以前模型像闭卷考试；RAG 像考试前给你塞一页资料；Search Agent 则像允许你考试过程中查资料，但你必须自己决定查什么、信什么、什么时候停。

Search-R1、R1-Searcher 这类工作的重要性不在于“用了搜索”，而在于它们把搜索行为纳入 RL 训练：模型不是只学习最终答案，而是学习一串搜索-阅读-推理动作怎样导向正确答案。

这一阶段暴露的新问题是：只用最终答案奖励很稀疏。模型可能碰巧搜到了答案，但我们不知道是哪一步有用；也可能乱搜很多次，最后答案对了，但策略并不好。

于是下一阶段自然转向：过程奖励、动态知识获取、step-wise 优化。

#2.3 第二阶段：从“会搜”到“会分步搜”

R1-Searcher++、StepSearch、ReSearch、Tool-Star 等工作体现了这一转向。

它们要解决的不是“模型是否能调用搜索”，而是更细的问题：

1. 查询是否逐步变得更准确？
2. 每一步搜索是否减少了不确定性？
3. 模型是否知道什么时候换 query？
4. 模型是否能把工具调用和内部推理交织起来？
5. 模型是否能在长链路里避免跑偏？

StepSearch 的名字就很直观：把搜索能力拆成 step-wise 的可优化过程。Tool-Star 则把问题进一步推广为多工具推理：搜索只是工具之一，模型还可能需要计算、代码执行、文档读取等工具。

这一阶段的演化逻辑是：

只奖励最终答案，会让模型学到“结果正确”但不一定学到“搜索策略正确”；要训练真正的搜索智能体，就必须把中间步骤也变成可评估、可优化的对象。

但这又带来新问题：真实 Web Search 的状态空间太大了。搜索结果、网页内容、query 变化、引用证据都很开放，训练成本和环境不稳定性很高。

于是出现了另一个方向：能不能把搜索环境内部化、模拟化？

#2.4 第三阶段：从外部搜索到内部化搜索环境

仓库中把方法标为 Internal 的 ZeroSearch、SSRL，代表了一个很重要的分支。

External search 的好处是真实：模型真的访问搜索引擎或网页。坏处是昂贵、不稳定、不可控、难复现。Internal search 则试图构造一个更可控的训练环境：让模型在模拟或内部知识环境中学习搜索策略。

这背后的关键矛盾是：

• 如果完全依赖真实互联网，训练成本高，结果受搜索引擎波动影响；
• 如果完全离线，模型又可能学不到真实搜索中的噪声、长尾与多跳信息发现。

ZeroSearch 这类方向的价值在于，它把 Web Search Agent 的训练问题推向了一个更基础的问题：

搜索能力到底是“访问外部网页”的能力，还是“在不完整信息状态下主动获取信息”的能力？

如果是后者，那么搜索环境可以被模拟、压缩、抽象，甚至未来可以和 world model / model-based RL 结合：模型先在内部环境里学会提出信息需求，再迁移到真实 Web。

这与 wenjun 关心的 model-based RL for LLM Agent 很相关。因为 Web Search 本质上是一个 partially observable problem：当前上下文只是世界的一小部分，agent 必须通过 action 获取新 observation。内部化搜索环境，就是在尝试为这种 POMDP 构造训练场。

#2.5 第四阶段：从 QA 搜索到 Deep Research 长轨迹

WebDancer、WebThinker、WebSailor、WebWatcher、ASearcher、Search Self-play，以及闭源的 OpenAI Deep Research、Perplexity Deep Research、Gemini Deep Research、Kimi-Researcher 等，代表了更接近产品形态的阶段。

这里任务已经不再是简单问答，而是 deep research：

• 问题开放；
• 需要多轮检索；
• 需要比较来源；
• 需要证据引用；
• 需要综合、归纳、写作；
• 有时还要追踪动态信息。

ASearcher 的标题 “Beyond Ten Turns” 很能说明问题：真正的搜索智能体难点在十轮以后。前几轮搜索靠 prompt engineering 也能撑住，但长轨迹之后会出现：

1. 目标漂移：搜着搜着忘了原问题。
2. 信息污染：把不可靠网页当成事实。
3. 上下文爆炸：资料越搜越多，模型反而抓不住主线。
4. 停止困难：不知道什么时候信息足够。
5. 信用分配困难：最终报告质量来自哪一步搜索？

WebSailor、WebWatcher 等名字背后其实是更强的 agent 假设：模型不只是检索器，而是一个在 Web 环境里航行、观察、判断、记录、整合的研究员。

Search Self-play 则进一步触及自我改进：如果没有人工标注，agent 能不能通过自博弈或自生成任务来扩展搜索能力边界？这条线与 STaR/self-training、frontier sampling、agentic self-evolution 高度相关。

#2.6 Web Search Agent 的演化主线总结

可以把 Web Search Agent 的演化压缩成五个阶段：

它真正的研究核心不是“搜索”二字，而是：

如何训练一个语言模型在不完整信息世界中主动获取信息、更新信念、管理上下文并形成可靠结论。

#3. Code Agent：从代码生成 RL 到真实软件工程 RL

Code Agent 是 Agentic RL 的另一个天然主场，因为代码任务有一个巨大优势：

反馈天然可执行。

数学题的答案可以验证，代码更进一步：代码可以运行、测试、报错、benchmark、静态分析、CI 检查。这个反馈结构让 Code Agent 很适合 RL。

但 Code Agent 的演化并不是简单的“用测试通过率做奖励”。它经历了三次重要扩展：

1. 从一次性代码生成到过程监督；
2. 从单文件题目到迭代修复；
3. 从算法题到真实仓库级 SWE agent。

#3.1 第一阶段：RL for Code Generation —— 用可执行测试奖励最终答案

AceCoder、RLTF、CURE、Absolute Zero、DeepCoder-14B 等属于这一大类。

这一阶段的问题很直接：给定题目，让模型生成代码，运行测试，用通过与否作为奖励。

这相比普通 SFT 有一个明显优势：

• SFT 模仿人类答案，但人类答案不一定覆盖所有正确写法；
• RL 可以探索不同代码，只要通过测试就给正反馈；
• 代码的 correctness 比自然语言偏好更可验证。

AceCoder 强调 automated test-case synthesis，这很关键。因为代码 RL 最大的问题之一是测试覆盖不足：如果只有少量 public tests，模型可能学会投机，生成过拟合代码。自动构造测试，本质上是在增强 reward model 的分辨率。

Absolute Zero 更进一步触及“无人工数据自我改进”：如果模型能自己提出任务、自己求解、自己验证，那么 code reasoning 可以形成闭环。这对 self-evolving code agent 很重要。

但这一阶段仍然像“算法题训练”：输入是题，输出是代码，反馈是 pass/fail。它还不是完整 Code Agent。

暴露的新问题是：只看最终通过与否，无法解释模型为什么失败，也无法训练 debugging 策略。

#3.2 第二阶段：从 Outcome Reward 到 Process Reward

StepCoder、PRLCoder、o1-Coder、CodeFavor、Focused-DPO、CodeBoost、Process Supervision-Guided PO 等属于这一转向。

这里的核心问题是：

代码正确性虽然可以最终验证，但写代码的过程同样重要。

一个模型写错代码，可能是：

• 没理解题；
• 算法思路错；
• 边界条件漏了；
• 变量类型错；
• 复杂度不够；
• 没看懂测试报错；
• 修复时破坏了已有逻辑。

最终 pass/fail 只能告诉你“错了”，不能告诉你“哪一步错了”。所以过程监督开始变重要。

o1-Coder 的意义在于把 reasoning-style training 引入代码：代码不只是 syntax generation，而是包含规划、分解、验证、反思的推理过程。PRLCoder、StepCoder 这类方法则试图把中间步骤变成可学习信号。

CodeFavor、Focused-DPO 则体现了偏好学习路线：不是只判断代码最终是否过测，而是学习哪些代码修改、解释、推理过程更符合高质量代码偏好。

这个阶段的演化逻辑可以概括为：

代码任务的 reward 虽然比开放问答更容易获得，但如果只奖励最终结果，模型学到的是“猜到能过测的代码”；如果奖励过程，模型才可能学到“如何系统性地写代码”。

但过程监督也有困难：谁来标注过程？过程是否唯一？错误推理但代码正确怎么办？漂亮推理但代码错误怎么办？

于是 Code Agent 进入下一阶段：让环境反馈本身成为过程监督来源。

#3.3 第三阶段：Iterative Code Refinement —— 把报错和测试变成交互环境

RLEF、μCode、R1-Code-Interpreter、IterPref、LeDex、CTRL、ReVeal、Posterior-GRPO / ReCode、Policy Filtration 等，关注的是迭代修复。

这一步非常关键，因为它把代码生成从 one-shot 任务变成多轮环境交互：

1. 生成初始代码；
2. 运行解释器或测试；
3. 读取错误信息；
4. 定位 bug；
5. 修改代码；
6. 再运行；
7. 直到通过或放弃。

这才开始像真正的 agent。

R1-Code-Interpreter 的名字说明了一个趋势：模型不只是写代码，还要用代码作为推理工具。代码解释器既是执行环境，也是反馈环境，也是思维外化工具。

CTRL / critic-rl 这样的方向强调 critic：模型需要学会判断自己的修改是否合理、错误是否被真正修复。ReVeal、Posterior-GRPO / ReCode 则强调 reasoning-process reward：奖励不只来自最终测试，还来自推理过程是否指向有效修复。

这一阶段暴露的新问题是长轨迹信用分配：

• 最后通过测试，是哪一次修改的功劳？
• 中途失败的尝试是否有训练价值？
• 模型应该探索更多修复路径，还是保守小改？
• 如何避免模型通过删除测试、硬编码答案、改接口等方式 reward hacking？

这已经非常接近一般 RL 问题，只不过环境是代码执行器和测试套件。

#3.4 第四阶段：SWE Agent —— 从题目代码到真实仓库

DeepSWE、SWE-RL、Satori-SWE、RLCoder、Qwen3-Coder、ML-Agent、DeepAnalyze、SWEET-RL 等代表了仓库级、软件工程级任务。

这里任务不再是“写一个函数”，而是：

• 读懂整个 repository；
• 理解 issue 或需求；
• 搜索相关文件；
• 修改多处代码；
• 添加或更新测试；
• 跑测试和 CI；
• 处理依赖、配置、数据、文档；
• 最终提交 patch。

这与 HumanEval / MBPP 时代完全不同。HumanEval 更像考试题，SWE-bench 更像真实工作。

SWE-RL 的重要性在于，它把 RL 用到软件工程 agent 训练里：奖励不只是代码片段通过单元测试，而是 patch 是否解决真实 issue。DeepSWE、DeepCoder-14B 等工作则说明开源社区开始系统性地把 RL scale 到 code agent 上。

SWEET-RL 关注 collaborative reasoning tasks，也提示 Code Agent 不一定是单体模型：真实软件工程可能需要 planner、coder、tester、reviewer、critic 协作。这与 multi-agent RL、agent workflow optimization 连接起来。

ML-Agent、DeepAnalyze 则把 Code Agent 扩展到机器学习工程和数据科学：这里 agent 不只是写业务代码，还要跑实验、分析结果、调参、生成报告。它进一步接近 wenjun 关心的 self-evolving code agent / research agent。

#3.5 Code Agent 的演化主线总结

可以把 Code Agent 的演化压缩成四个阶段：

它真正的研究核心不是“代码生成”，而是：

如何训练一个语言模型在可执行环境中利用反馈进行规划、调试、验证和持续改进。

#4. 两条线的共同底层逻辑：为什么它们都走向 Agentic RL？

Web Search Agent 和 Code Agent 的外表不同，但演化结构高度相似。

#4.1 都从“静态生成”走向“环境交互”

Web Search：

• 静态回答 → RAG → 主动搜索 → 多轮 deep research。

Code Agent：

• 静态代码补全 → 题目代码生成 → 运行测试 → 迭代修复 → 仓库级 SWE。

共同趋势是：

模型能力不再只由 prompt-response 决定，而由 model-environment loop 决定。

这意味着训练目标也必须改变。只训练最终回答，就像只看学生期末答案；Agentic RL 则要看学生如何查资料、如何做草稿、如何试错、如何修正。

#4.2 都天然存在可验证反馈，但反馈粒度不足

Web Search 的反馈包括：答案正确性、引用支持性、来源可靠性、事实一致性。

Code Agent 的反馈包括：测试通过、编译成功、静态检查、benchmark、review 结果。

看起来反馈很多，但问题是：最终反馈仍然太稀疏。

例如：

• 一篇 deep research 报告写得好，可能来自第 3 次搜索找到的关键证据；
• 一个 patch 通过测试，可能来自第 5 次修改修复了边界条件；
• 但最终 reward 只给整个 trajectory 一个分数。

所以两条线都走向 process reward、step-wise RL、critic、verifier、trajectory filtering、policy filtration。

#4.3 都面临长上下文与状态表示问题

Web Search 的上下文爆炸来自网页、搜索结果、引用、笔记。

Code Agent 的上下文爆炸来自仓库文件、依赖、测试日志、issue 历史。

这使得一个核心问题浮出水面：

Agent 真正需要记住的不是所有文本，而是当前任务的 decision-sufficient state。

这正好连接到 latent-space reasoning / context compression：未来的 Agentic RL 可能不只是训练 action policy，还要训练 state abstraction policy。也就是：agent 要学会把长轨迹压缩成足以支持下一步决策的潜在状态。

#4.4 都从人类监督走向自生成环境与自我改进

Web Search 里有 Search Self-play、SSRL、ZeroSearch。

Code Agent 里有 Absolute Zero、DeepCoder、DeepSWE、R1-Code-Interpreter、SWE-RL。

它们共同指向一个问题：

Agent 能否自己生成任务、自己探索、自己验证、自己训练？

但这里必须谨慎：自我改进不是“凭空变聪明”。它需要外部锚点：

• Web Search 需要事实来源、检索环境、引用验证；
• Code Agent 需要解释器、测试、CI、benchmark；
• 如果反馈信号不可靠，自我训练会放大错误。

因此，自演化 Agent 的关键不是“自己生成数据”，而是“有可靠的自动化反馈闭环”。

#5. 对 wenjun 关心的问题：这两条线给 model-based RL / latent reasoning 什么启发？

#5.1 Web Search Agent 是天然的 model-based RL 场景

Web Search 可以被看成 POMDP：

• hidden state：真实世界知识和网页信息结构；
• observation：当前搜索结果、网页片段；
• action：查询、点击、阅读、停止；
• reward：最终答案质量、证据支持、效率。

External search 是真实环境，Internal search / ZeroSearch / SSRL 则是在尝试构造模拟环境。

这给 model-based RL 一个很自然的问题：

能不能训练一个“信息获取 world model”，让 agent 在内部想象不同 query 可能带来什么信息增益，再决定真实搜索？

如果能做到，Web Search Agent 就不会只是 brute-force 多搜，而会变成主动实验设计：每次搜索都像一次 information-gathering experiment。

#5.2 Code Agent 是最适合训练“可执行推理”的环境之一

代码环境的好处是反馈清晰。解释器和测试器提供了比自然语言 judge 更可靠的信号。

这使 Code Agent 特别适合研究：

• 长轨迹 credit assignment；
• debugging policy；
• self-repair；
• verifier-guided exploration；
• agentic curriculum；
• 从单题到仓库的能力迁移。

对 self-evolving code agent 来说，关键问题不是“让模型多写代码”，而是：

如何构造一个能持续产生新任务、暴露能力边界、提供可靠验证、避免 reward hacking 的软件环境？

这和“通过设计环境催生自演化智能”的思路非常一致。

#5.3 两条线都逼近“潜状态”问题

长轨迹 Agent 不能把所有历史都塞进上下文。它必须学会：

• 哪些网页证据值得保留；
• 哪些搜索分支已经排除；
• 哪些代码文件是关键；
• 哪些测试失败代表同一个 bug；
• 当前计划的最小充分状态是什么。

这就是 latent-space reasoning 的入口：

未来 Agent 可能需要在显式文本轨迹之外，学习一种隐式任务状态，用来承载目标、假设、证据、约束和下一步 action 倾向。

如果只优化 token-level CoT，可能会被长文本拖垮；如果能优化 decision-sufficient latent state，Agentic RL 才可能扩展到更长任务。

#6. 我对这个方向的研究判断

#6.1 Web Search Agent 的短期瓶颈

Web Search Agent 最急的问题不是“模型会不会搜索”，而是：

1. 证据可靠性：搜索结果里有噪声、SEO、过时内容、相互引用污染。
2. 长轨迹状态管理：搜得越多，上下文越乱。
3. 过程信用分配：哪些 query / page / note 真正有贡献？
4. 停止策略：什么时候应该继续查，什么时候应该收敛？
5. 训练环境可复现性：真实 Web 会变，搜索引擎结果会变。

我认为最有价值的研究问题之一是：

训练一个 research agent 的“信息增益估计器”：每一步搜索前预测这一步可能减少多少不确定性，搜索后评估它是否真的改变了结论。

这比单纯提高最终答案分更基础。

#6.2 Code Agent 的短期瓶颈

Code Agent 最急的问题也不是“能不能写代码”，而是：

1. 仓库级上下文选择：哪些文件该读，哪些不用读？
2. 调试过程学习：如何从失败测试定位根因？
3. 防 reward hacking：不能通过删测试、硬编码、绕检查来拿 reward。
4. 多步 patch 信用分配：最终通过来自哪一步？
5. 真实软件工程分布：HumanEval 到 SWE-bench 之间仍有巨大 gap。

我认为最有价值的研究问题之一是：

训练一个 code agent 的“可执行世界模型”：它不只是预测下一个 token，而是预测某个 patch 会导致哪些测试变化、依赖变化和副作用。

这正是 model-based RL 在 Code Agent 中的可能切入点。

#6.3 两条线最终会汇合

Web Search Agent 和 Code Agent 未来可能不会分得那么开。

一个真正的 research / engineering agent 会同时需要：

• 搜索资料；
• 阅读论文和文档；
• 写代码复现；
• 跑实验；
• 分析结果；
• 修 bug；
• 写报告；
• 继续查缺补漏。

也就是说，Web Search 与 Code Agent 最终会汇合成 Research Agent / SWE Research Agent。

这时 Agentic RL 的训练目标也会更复杂：不只是搜索对了、代码过测，而是整个研究闭环是否产生了可靠新知识。

#7. 一张总图：两条演化线如何对应

#8. 最后：真正值得抓住的主线

如果只看论文名，这个方向会显得很散：Search-R1、R1-Searcher、WebDancer、WebSailor、AceCoder、DeepSWE、SWE-RL、R1-Code-Interpreter……名字很多，很容易变成列表。

但如果看演化逻辑，它其实很清楚：

1. LLM 先从闭卷生成走向开卷工具使用。
2. 工具使用暴露了多步决策问题。
3. 多步决策需要 RL，而不是只靠 SFT。
4. 最终奖励太稀疏，所以需要过程奖励、critic、verifier、trajectory filtering。
5. 真实任务轨迹太长，所以需要状态压缩、记忆、潜空间推理。
6. 人工数据不够，所以需要自生成任务、自博弈、可验证环境。
7. 当 agent 能在环境中持续获取反馈并改进策略时，才真正进入 Agentic RL。

因此，Web Search Agent 和 Code Agent 的共同终点不是“更会搜”或“更会写代码”，而是：

训练一种能够在开放环境中主动获取信息、执行动作、接收反馈、更新策略、持续改进的基础智能体能力。

这也是 Agentic RL 真正值得研究的地方。它不是把 RLHF 换个名字，而是在把 LLM 的训练对象从“答案”推进到“行动轨迹”，再进一步推进到“可自我改进的环境闭环”。