RAG & Agent 策略：复杂系统设计
RAG & Agent 策略：复杂系统设计
RAG 和 Agent 是 AI PM 最容易被 buzzword 带偏的两个方向。很多 roadmap 一上来就写“做 Agent”“接 RAG”，但其实连用户任务都还没定义清楚。结果就是架构词很多，产品价值很空。
这页的重点不是讲底层实现细节，而是从 PM 视角判断：什么时候该上 RAG，什么时候该上 Agent，什么时候其实两者都不该上。
先说结论：先问用户任务，再选系统形态
更稳的判断顺序应该是：
- 用户需要的是“更准的回答”还是“更复杂的执行”
- 你缺的是知识访问能力，还是任务编排能力
- 风险和成本是否值得引入更复杂系统
如果这三步不先想清楚，团队很容易把技术复杂度误当产品进步。
什么问题更适合用 RAG
RAG 的核心价值，不是让回答“更聪明”，而是让回答更 grounded。
它更适合：
| 场景 | 为什么适合 |
|---|---|
| 内部知识问答 | 需要引用公司文档和规则 |
| 帮助中心 / support copilot | 需要基于已有知识回答 |
| 政策、流程、产品资料检索 | 需要 source-backed answer |
| 长文档问答 | 模型本身并不知道你的私有内容 |
如果你的问题本质上是“模型不知道这份资料”，RAG 往往是对的方向。
什么问题更适合用 Agent
Agent 的核心价值，不是“更像人”，而是能做多步任务。
它更适合：
| 场景 | 为什么适合 |
|---|---|
| 多步 research workflow | 需要搜索、整理、生成结果 |
| 需要调用多个 tool 的任务 | 例如查数据、写报告、发通知 |
| 复杂 operation workflow | 需要判断下一步动作 |
| 半自动执行任务 | 不是只回答，而是要做事 |
如果任务本质是“先做 A，再判断，再做 B”，Agent 才开始有意义。
什么时候其实不该急着上 RAG
| 情况 | 原因 |
|---|---|
| 文档质量很差 | 垃圾进库，只会让答案更乱 |
| 知识更新流程没建立 | 很快就会过时 |
| 用户真正要的不是问答 | 你可能在优化错问题 |
| 团队还没定义 source trust | 检索到了也不代表能用 |
很多所谓“RAG 效果差”，其实根本不是模型问题，而是知识库治理没做好。
什么时候不该轻易上 Agent
| 情况 | 原因 |
|---|---|
| 任务步骤其实很固定 | 普通 workflow automation 可能更稳 |
| 错一步代价很高 | Agent 的自主性会放大风险 |
| 还没搞定单步质量 | 多步链路只会把问题放大 |
| 用户根本不需要 autonomy | 你在增加复杂度，不是在增加价值 |
Agent 不是高级版聊天框。
很多产品其实只需要明确的 flow + 少量 tool call，不需要 full agent loop。
一个更实用的判断框架
你可以先用这张表判断：
| 问题类型 | 更可能的方案 |
|---|---|
| 缺知识 | RAG |
| 缺步骤执行 | Agent |
| 既缺知识又缺执行 | RAG + Agent，但要先分层 |
| 只是普通表单或规则流 | 不一定需要 AI system complexity |
PM 最应该避免的，就是因为“听起来更先进”而直接上最复杂方案。
RAG 的 PM 关注点，不只是检索准确率
更应该关注这些问题：
| 决策点 | PM 为什么要管 |
|---|---|
| source coverage | 用户要问的东西有没有被覆盖 |
| update freshness | 知识多久更新一次 |
| citation UX | 用户能不能看到来源 |
| failure handling | 找不到资料时怎么说 |
| trust boundary | 哪些 source 可以被信任 |
RAG 做得好不好，很大程度取决于 knowledge operation，而不是单次检索指标。
Agent 的 PM 关注点，是可控性
Agent 最需要被问的不是“酷不酷”，而是：
- 它会不会调用不该调用的工具
- 它会不会在错误前提上继续执行
- 它的每一步是否可观测
- 它失败时是否能中断或转人工
如果这几件事答不清，Agent 方案通常还不成熟。
RAG + Agent 一起上时，先分层
更稳的方式不是一口气做一个“大而全 Agent”，而是拆成：
knowledge layer -> retrieval layer -> decision layer -> action layer
这样你才能分清：
- 是检索错了
- 还是判断错了
- 还是工具执行错了
系统一复杂，最怕的就是出错以后没人知道错在哪一层。
最容易被忽略的成本
RAG 和 Agent 的成本都不只在 API bill。
还包括：
- 文档治理成本
- eval 和 monitoring 成本
- prompt / workflow maintenance 成本
- bad case 处理成本
PM 如果只拿“模型调用成本”做预算，通常会低估很多。
一套够用的策略评审问题
在讨论 RAG 或 Agent 前，先让 team 回答：
- 用户任务到底是什么
- 失败后最坏后果是什么
- 为什么 simpler workflow 不够
- 上线后怎么监控质量
- 出问题时能回滚到哪一层
这 5 个问题答不清时，先别着急画复杂架构图。
Practice
拿你现在最想做的一个 AI feature，先判断它更像哪一类：
- 知识型问题
- 多步执行型问题
- 两者都有
- 其实只是普通自动化
分类做对了，后面的系统设计方向通常就不会差太远。