RAG不是“查资料”，而是让智能体“能用知识行动”，很多人认为 RAG 就是让模型“查查资料再回答”。这完全低估了 RAG 的价值。

如果你正在做智能体（Agent），你会很快发现一个现实：

光靠大模型本身，是无法记住你业务里的真实信息的。 它不知道产品细节、不知道你的数据结构、不知道执行规范、也不知道你公司怎么做事情。

智能体要能执行任务，就必须“拥有自己的知识”。那这些知识从哪来？

答案：RAG 是 智能体 的“知识系统” 。

今天这篇，你将真正理解 RAG 的工程意义，以及在智能体中的高阶玩法。

1. 为什么智能体离不开RAG？

如果智能体没有知识库，会出现三个严重问题：

① 智能体会“乱编”你公司内部信息（hallucination）

例如：

 让 Agent 回复用户的售后问题。

没有知识库，它只会“编一个看起来合理的答复”。这在企业场景会直接造成事故。

② 智能体 无法“执行任务”

例如让智能体自动写日报：

• 它不知道昨天发生了什么
• 不知道用户上传的文件是什么
• 不知道产品更新了哪些功能

智能体不是 ChatGPT。智能体是要执行任务的。

执行任务 = 需要知道“过去和现在的事实”。

③ 智能体无法“长期稳定运行”

你的业务每天变化：

• 文档变了
• 产品变了
• 规则变了
• 流程变了
• 数据变了

模型是不会自动更新的。因此，智能体要能稳健运作，必须“能读取新知识”。

RAG = Agent 的动态知识系统 让智能体可以随着你业务实时更新。

2.大多数人RAG用错了

传统 RAG 流程如下：

搜索向量 → 找到相关段落 → 拼接到上下文 → 输入给模型

这是“最低级”用法。它的限制非常明显：

• 找到的是段落，不是“知识结论”
• 完全依赖 chunk 拆法
• 模型要自己读文档、自己理解 = 计算浪费
• 无法用于执行任务
• 只能回答问题，不能驱动一个智能体行动

你会发现它就像一个带搜索的 ChatGPT，不像智能体。

3.智能体 RAG 的正确结构

下面是智能体工程里“真正好用”的 4 种 RAG 模式。

模式 1：决策型RAG（Decision RAG）

让智能体用知识“做判断、做选择”。

用户问：

是否应该退款？

普通 RAG：找到退款政策 → 引用 → 模型发挥

智能体 RAG：

• 拿到政策结构化信息
• 按规则判断
• 得到结论
• 执行动作（通知客服、发工单）

结构：

知识库（结构化规则） → 规则匹配 → 得到决策 → 执行动作

这是“流程自动化”的关键。

模式 2：执行辅助RAG（Execution RAG）

适用于“帮智能体完成任务的一部分”。

例如智能体要写代码，但需要知道：

• 你的项目目录
• 你的函数参数
• 你的 API 文档
• 你的数据库 schema

执行型智能体必须“读懂代码库”。

RAG = 智能体的“工程手册”。

没有 RAG，智能体永远无法真正操作外部系统。

模式 3：状态型RAG（State RAG）

这是一个超重要但很多人不知道的用法。

智能体需要“记住”过去：

• 当前进行到哪个步骤？
• 任务是否完成？
• 用户偏好是什么？
• 之前生成了哪些文件？

模型是无状态的。智能体必须“有状态”。State RAG = 智能体的短期记忆系统 它不是传统意义的知识库，而是状态数据库。

例如：

{
  "current_step": "5. 正在分析用户需求",
  "previous_output": "...",
  "fail_count": 1
}

这是 Devin 的核心机制：通过状态系统保持 Agent 不迷路。

模式 4：知识工作流RAG（Knowledge Workflow）

这是真正高级的 RAG 用法。不是简单搜索，而是：

根据任务 → 自动选择 → 自动裁剪 → 自动组合 → 构造一个“任务专用知识包”

例如：

智能体要写《AI 智能体架构》的文章：

• 从知识库找“体系结构类知识”
• 从资料库找“多 Agent 协作”
• 从代码库抽取“工作流示例”
• 从笔记库抽取你的写作风格
• 自动拼接为上下文 → 开始写作

这叫 Knowledge Orchestration（知识编排）。未来所有智能体都需要。

4.智能体RAG的最佳实践

① Chunk 越小越好？错。最佳 Chunk 取决于“任务类型”

智能体的任务只有两类：

• “决策任务” → 结构化知识 → Chunk 小
• “理解任务” → 语义连贯 → Chunk 大

给你一个简单规则：

任务类型	Chunk 大小
FAQ、规则判断	200–400 tokens
技术文档、API、流程	800–1500 tokens
论文、文章分析	2000 tokens 起

绝不是“越小越好”。

② RAG 最重要的不是“搜索”，而是“重写检索”

模型天然不会提出优秀的搜索 query。必须让 Agent 重写检索。

示例：

“怎么退款？” 重写 → “退款政策 条件 流程 金额 限制 平台规则”

重写后的检索效果能提升 30%–50%。

③ 知识要结构化，而不是乱糟糟的PDF

例如：

不建议直接给模型：

大段退换货政策

应转成结构化：

{
  "refund_policy": {
    "conditions": [...],
    "exceptions": [...],
    "time_limit": "...",
    "required_documents": [...],
    "steps": [...]
  }
}

结构化知识 = Agent 可以自动执行。

④ RAG不应该只返回文本，而应该返回“可执行信息”

例如：

不返回：

用户可退款，如果订单未超 7 天。

应该返回：

{
  "decision": "refundable",
  "reason": "purchase within 7 days",
  "action": "trigger_refund_api"
}

智能体不是让用户看，而是：

• 做判断
• 执行动作
• 走流程

因此 RAG 输出必须可执行。

⑤ 最关键的不是“召回率”，而是“任务成功率”

开发 RAG 时，不要执着于：

• cosine score
• 向量模型
• chunk 方案

最应该看的指标是：

智能体的任务成功率（而不是 RAG 的检索精度）

这是工程视角和学术视角的重大差异。

5.可直接复用：智能体用的 RAG 工作流

Step 1：解析任务 → 判断是否需要 RAG

模型检查：

• 任务是否要用外部知识
• 需要什么类型的知识（规则、文档、状态……）

Step 2：重写检索 Query

让模型把用户任务转成检索向量。

Step 3：检索知识（多源）

包括：

• 内部文档
• 用户上传内容
• 结构化数据库
• 任务状态
• 历史对话

Step 4：知识预处理

包括：

• 总结
• 合并
• 去重复
• 提取关键字段
• 转成结构化格式（JSON）

Step 5：构建“任务专用知识包”

例如：

{
  "policy": {...},
  "api_doc": {...},
  "user_history": {...},
  "task_state": {...}
}

Step 6：执行主任务（写、分析、编程、判断…）

模型此时不是“从零创作”，

而是“在知识环境中执行任务”。

这才是智能体的本质价值。

Step 7：输出 & 更新状态（State RAG）

把结论写入状态数据库，让智能体“记住这次执行情况”。

6.RAG 是智能体的“大脑皮层”，不是搜索引擎

你现在理解的是：

• 传统 RAG 是“检索”

• 智能体 RAG 是“知识驱动的行动系统”

• 智能体需要 RAG 才能：

  • 做判断
  • 执行流程
  • 维护状态
  • 实现长期运行
  • 连接外部系统

你现在掌握的是工程级RAG，而不是论文里的那一套。