如何从Search Agent 方向，切入到 Coding Agent？
最近爆炸忙，好多都没有更新上，自己的内容都拖拖拉拉没做，有些丧，并且最近做 search 的过程中，心里也越来越慌~~~
背景
因为发现，现在做 Agentic RL 方向的，基本都在往"会修改环境"的方向走。而这里面最大的方向，就是 Coding。这事直接给我干 emo 了。
因为如果继续只看 Search Agent，会有一种很强的焦虑感：大家都在做能改代码、能跑测试、能和真实环境交互的 Agent，而 Search Agent 还停留在"搜网页、读证据、回答问题"的闭环里。search 依然重要，只是它看起来没有那么像一个完整的 RL 环境。
为了不被时代抛弃，一个比较自然的问题是：
能不能把自己在 Search Agent 上积累的东西，迁移到 Coding Agent 里？
我仔细想了下，先来拆解会面临哪些问题：
- Search Agent 到底面临哪些问题？
- 这些问题切到 Coding Agent 后，会变成哪些新问题？
- 如果真要入门 Coding Agent / Coding RL，应该从哪些项目开始？
这里我们先一个一个的讲：
- Search Agent 面临的问题，不止是"会不会搜"
Search Agent 表面流程很简单：
用户问题→ 生成查询→ 搜索网页 / 文档→ 阅读证据→ 多步推理→ 最终回答但真正困难的地方不在于调用 search API，而在于它要在一个长程过程中持续保持目标、管理状态、判断证据、决定什么时候停止。
典型问题包括：
1.1 Query Drift：越搜越偏
Agent 一开始可能搜得还对，但几轮之后 query 会逐渐偏离原问题。
比如问题问的是：
某个雕塑的作者去世地所在郡属于哪个州？
合理链路应该是：
雕塑 → 作者 → 去世地 → 郡 → 州但 Agent 可能搜着搜着开始查雕塑风格、展览地点、作者生平八卦，最后证据链断掉。
这类问题的根源通常在于 query evolution 缺少约束。
1.2 Goal Drift：任务目标变形
Search Agent 经常会在长程搜索中忘掉最初要回答什么。
它可能找到了很多相关信息，但这些信息并不服务于最终问题。结果就是看起来搜了一大堆，但是实际上做了很多无效的探索。
1.3 Premature Answer：证据不够就急着回答
很多 Agent 搜了一两条结果就开始总结。它没有真正建立完整证据链，只是看到一个看似相关的片段，就提前生成答案。这在开放域 QA 里很常见，在 BrowseComp 这种长程任务里更明显。
1.4 Evidence Conflict：证据冲突不会处理
不同网页、文档、时间版本之间可能互相矛盾。
Agent 需要判断：
- 哪个来源更可信？
- 哪个时间更新？
- 哪个说法更接近原始证据？
如果没有这种判断，搜索越多，反而越容易混乱。
1.5 State Explosion：长程搜索状态爆炸
多轮搜索后，上下文里会堆积大量搜索结果。
问题包括：
- 哪些证据已经确认？
- 哪些子问题还没解决？
- 哪些 query 已经搜过，不能重复？
- 哪些搜索结果只是噪声？
- 哪些信息应该压缩成 summary？
这就是 Search Agent 里很核心的 state tracking 问题。
1.6 Stop Decision：不知道什么时候停
Search Agent 很难判断：
- 现在证据够了吗？
- 还需要继续搜吗？
- 继续搜的边际收益大吗？
停太早会答错，停太晚会浪费 token 和工具调用，还可能引入噪声。
1.7 Reward Credit Assignment：错了不知道错在哪一轮
最后答案错了，不代表所有搜索步骤都错。
可能是：
- 第一轮 query 就偏了
- 某一轮证据读错了
- 最后一轮总结错了
- 搜索过程是对的，但最终 answer extraction 错了
如果 reward 只打到最终 token，就很难知道应该惩罚哪一段行为。
- 如何从 Search Agent 切换到 Coding Agent
这里我们可以梳理下 Coding Agent 的流程：
Issue 描述 → 搜代码库 → 找相关文件 → 找相关函数 → 定位根因 → 修改代码 → 跑测试 → 根据失败日志继续定位 → 最终 patch换个角度看，这里也有一条证据链：
Issue → 相关文件 → 相关函数 → 错误原因 → 修改点 → 测试反馈 → 最终修复这和 Search Agent 的：
问题 → 搜索结果 → 证据 → 推理 → 答案非常像。
区别只是 Coding Agent 多了两个关键动作：Edit File跟Run Test，也就是这两个动作会真正的改变环境。
这里我列一下一个表，来看一下两者的映射：
| Search Agent 问题 | Coding Agent 中的对应问题 | 具体表现 |
|---|---|---|
| Query Drift | Code Search Drift | grep / rg 搜索词越来越偏，打开一堆无关文件 |
| Goal Drift | Patch Goal Drift | 本来修 bug，最后开始重构无关模块 |
| Premature Answer | Premature Patch | 没定位根因就直接改代码，靠猜 patch |
| Evidence Conflict | Code / Test / Doc Conflict | README、注释、测试、真实代码行为互相矛盾 |
| State Explosion | Repo Context Explosion | 文件、函数、日志、历史尝试太多，状态管理失控 |
| Stop Decision | Search-to-Edit Decision | 不知道什么时候停止搜代码、开始改代码 |
| Verification Failure | Test Feedback Failure | 测试失败后不会根据 traceback 继续定位 |
| Credit Assignment | Patch Credit Assignment | 最终测试失败，不知道是哪次 edit 或哪条定位链错了 |
这张表很关键。
它说明 Search 背景和 Coding Agent 有很强的连接点，可以迁移到 Coding Agent 里最核心的"仓库导航 + 根因定位 + 反馈闭环"部分。
- Coding Agent 的关键是"在代码库里找 bug"
现在很多人讲 Coding Agent，容易把重点放在 code generation 上。
但真正的 SWE-bench 类任务，会给模型一个真实 GitHub issue，让它在已有仓库里修问题，而非写一个孤立函数。
这类任务的难点往往超出"会不会写 Python"：
- 能不能读懂 issue？
- 能不能找到相关文件？
- 能不能理解跨文件调用链？
- 能不能定位真正根因？
- 能不能只做必要修改？
- 能不能跑对测试？
- 测试失败后能不能继续 debug？
所以对 Search 背景的人来说，最自然的切入点是：
Codebase Context Retrieval for Coding Agents
或者更明确一点：
State-Aware Repository Navigation for SWE Agents
也就是：让 Coding Agent 更会在代码库里找问题，避免只停留在写代码。
- 可以切入 Coding 方向的几个具体点
4.1 Repository Navigation：代码库导航
这是最像 Search Agent 的方向。
把网页搜索换成 repo search：
web search → repo grep / rg / AST / LSP / symbol search可以研究的问题包括：
- Issue 里哪些词应该用来搜？
- 搜不到时怎么改 query？
- 什么时候 grep，什么时候查定义，什么时候查引用？
- 先看测试还是先看源码？
- 如何避免重复打开同一批无关文件？
- 如何维护"我已经知道什么 / 还缺什么"的状态？
这其实就是 Search Agent 的 query planning 和 state tracking。
4.2 Fault Localization：根因定位
Coding Agent 的核心在于先定位 fault，再生成 patch。
可以把它拆成一个中间任务：
- Issue → Top-k suspicious files/functions
或者：
- Issue + traceback → root cause explanation
这方向很适合做 reward：
- 是否找到 gold file？
- 是否找到 gold function？
- 是否打开了过多无关文件？
- 是否在修改前引用了足够证据？
这比直接训练 end-to-end patch 更轻，也更适合从 Search Agent 迁移。
4.3 Test Feedback RL：测试反馈驱动的 RL
Search Agent 大多是：
Search → Read → Answer环境没怎么变。
Coding Agent 是：
Search Repo → Edit File → Run Test → Observe Failure → Edit Again这里的测试结果是环境反馈。可以设计的训练信号包括：
- 测试是否从 fail 变 pass？
- fail 数量有没有减少？
- traceback 是否变短？
- 是否修复目标测试但破坏其他测试？
- 是否引入 lint / type error？
- 是否过度修改？
这比只看最终 pass/fail 更 dense，也更适合做过程奖励。
4.4 Patch Minimality：防止乱改
Search Agent 有 goal drift，Coding Agent 有 patch drift。
Agent 很容易改太多：
- 大范围重构
- 删除测试
- hard-code
- 修改无关文件
- 为了过当前 case 破坏通用行为
所以可以做一个 reward / verifier：
通过测试 + 修改范围小 + 与 issue 相关 + 不破坏现有行为
这方向很实用，因为真实工程里"能过测试但改得很脏"的 patch 也不能接受。
4.5 Trajectory Compression：长程 debug 状态压缩
长程 Coding Agent 会产生大量历史：
- 搜过哪些关键词
- 看过哪些文件
- 改过哪些地方
- 跑过哪些测试
- 每次失败日志是什么
- 当前最可信的 root cause 是什么
这和 Search Agent 的多轮搜索 summary 很像。
可以做： debug memory / repo state summary / evidence graph
目标是让 Agent 在长程任务中不丢状态、不重复探索、不忘记失败教训。
4.6 Tool Policy：什么时候用什么工具
Coding Agent 工具比 Search Agent 更多：
例如：
- rg / grep
- sed / cat
- LSP jump-to-definition
- find references
- pytest
- lint
- edit
- git diff
工具选择本身就是 policy。
可以研究：
- 什么时候 search？
- 什么时候 read？
- 什么时候 edit？
- 什么时候 run test？
- 什么时候 rollback？
- 什么时候停止？
这和 Search Agent 的"搜 / 读 / 总结 / 停止"非常像，只是动作空间更丰富。
- 可以怎么设计一个最小闭环？
这里，我大概写了一个最小的闭环：
输入：GitHub issue + repo
动作：rg / read file / inspect symbol
输出：top-k suspicious files + evidence summary
奖励：
- gold file 命中
- gold function 命中
- 打开的无关文件少
- 重复搜索少
- evidence summary 能支持后续 patch
这样可以先把 Coding Agent 里的 search 子问题做扎实。
然后再接上 edit 和 test：
输入：issue + repo
动作：search / read / edit / test
输出：patch
奖励：
- hidden tests pass
- public tests pass
- fail-to-pass 数量增加
- pass-to-pass 不回退
- patch diff 小
- 没有删除测试 / hard-code / 大范围无关修改
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～