程序员转 AI Agent：把 RAG 做进一个可用的 Agent

如果你已经会做一个最小 Agent，下一步最值得加的能力通常不是“更会聊天”，而是 RAG。因为真正有价值的 Agent，往往不是靠模型记住一切，而是靠它能先检索，再回答，再行动。

这篇文章讲一个最实用的方向：把 RAG 做进一个可用的 Agent。

为什么 Agent 需要 RAG

纯聊天模型有两个天然问题：

• 它不知道你自己的资料
• 它会在知识不足时胡猜

而 RAG 的作用很明确：

• 从知识库里找相关内容
• 把相关内容提供给模型
• 让模型基于事实生成结果

这对 Agent 尤其重要，因为 Agent 不只是回答，还要做决策。

一个最小 RAG 流程

最简单的流程是：

1. 把文档切分成片段
2. 计算向量并建立索引
3. 用户提问时做检索
4. 把检索结果放进上下文
5. 让 Agent 基于资料回答或执行下一步

你可以把它理解成：先找证据，再做判断。

先解决什么问题

别一上来就做复杂的分层检索、多路召回、重排模型。先把这三个问题搞定：

• 能不能找到相关片段
• 找到后能不能正确塞进上下文
• 模型会不会明显比纯生成更稳

只要这三点成立，RAG 就算起步成功。

文档切分怎么做

切分是 RAG 的第一步，也最容易出问题。

实战里通常要注意：

• 不要切太碎，否则上下文失真
• 不要切太大，否则召回不准
• 保留标题、来源、章节信息

一个常见策略是按段落和标题切，再给每个片段加元数据。

召回之后怎么用

检索到内容后，不要直接把一堆文本全塞给模型。

更好的做法是：

• 只保留前几条最相关结果
• 去掉重复片段
• 给模型明确指令：只能基于资料回答

如果是 Agent 场景，还可以让模型判断：

• 资料足够就直接回答
• 资料不足就继续检索
• 资料冲突就提示不确定

Agent 场景下的关键点

RAG 放到 Agent 里后，重点就不只是“答得对”，而是“能不能支持下一步动作”。

例如：

• 查文档后生成摘要
• 查知识库后写方案
• 查规范后修改配置
• 查历史记录后执行修复

所以 Agent 不应该只拿检索结果做回答，还要能根据结果决定下一步。

常见坑

1. 召回结果不准

通常是切分方式、embedding 模型或召回参数的问题。

2. 上下文太长

把太多内容塞给模型会让结果变慢，也会降低稳定性。

3. 模型还是会胡说

说明提示词没有限制好，或者证据不足时没有强制拒答。

4. 检索了，但没用上

很多系统只是“查了资料”，但没有真正把资料纳入决策。

一个实用的判断标准

你可以用这三个问题判断 RAG 是否可用：

• 它能否稳定找到相关内容
• 它能否在答案里引用到证据
• 它能否在资料不足时明确说不知道

如果这三点做到了，RAG 才算真正进入可用阶段。

适合程序员的练手项目

推荐做一个“小型知识库 Agent”：

• 输入：技术文档、团队规范、笔记
• 功能：检索、总结、回答、生成 Markdown
• 目标：让它能基于资料辅助你完成真实工作

这个项目很适合继续扩展成：

• 代码库问答助手
• 运维知识助手
• 需求文档总结助手

结语

对 AI Agent 来说，RAG 不是可选项，而是很多实际场景里的基础能力。先把“检索 -> 注入上下文 -> 基于证据决策”这条链跑通，你的 Agent 就会从“会说话”变成“能干活”。

如果你已经做过最小 Agent，下一步最值得补的就是 RAG。