ai agent vs rag

选型会上最常见的争论是「我们到底该上 Agent 还是上 RAG」。两边说的其实不是一回事：一个管「怎么行动」，一个管「答案从哪来」。这篇不重复原理，只给判断标准、组合方式和工程上必须先定的几件事，帮你在评审前把方案边界画清楚，也写清哪些场景下这套思路不适用。

选型会上最常见的一幕：一方说要上 Agent，另一方说要先做 RAG，两边吵得很热，其实说的不是一回事。一个管「答案从哪来」，一个管「怎么动手把事情做完」。先把这条分界线画出来，很多争论会自己消失。

这篇不重复原理，只给判断标准、组合方式和落地前必须先定的几件事。适合手里有一个具体需求、准备在评审前把方案边界写清楚的人。也提前说明：文里这套判断有明确的失效场景，最后一节会单独讲什么情况下别照这个思路走。

先破一个前提：这俩不是二选一

RAG 处理的是「模型不知道你私有的内容」，Agent 处理的是「一次问答搞不定、要跨多步才能完成」。两件事的层次不一样，谈不上谁替代谁。你要做的第一个动作，是把当前需求归类：答案是查出来的，还是做出来的。

查出来

用户问的东西已经躺在你的文档、工单、库表里，任务终点是「找到并说清」

做出来

任务终点是一个动作或一份产物，需要调接口、写数据、跨系统核对

又查又做

要先查到依据，再据此执行，执行中还要再查，这类才需要两层配合

• 只查资料：检索层单独跑就能交付，加编排只是徒增故障点；
• 只走流程：编排层单独跑也成立，知识直接写在提示词或配置里就够；
• 又查又做：两层都要，但不要一次全上，建议先让检索层跑稳再挂编排；
• 判断不准时：先问产品经理「最坏情况答错一次，业务能不能接受」，答案往往能定方向

三问定方向：查、做、还是又查又做

三问不是理论，是评审前十分钟就能问完的筛子。每一问的答案都会直接砍掉一批方案，别急着讨论用哪个框架、哪家模型。

1. 第一问：答案是否已存在于你的资料里把用户最常问的十来个问题写下来，逐个去文档、库表、工单系统里找。找到一半以上，检索层就是刚需；基本找不到，说明数据源本身要先补，模型帮不上。
2. 第二问：是否需要多轮、跨系统、写回数据如果任务涉及登录、查询、提交、改状态这些动作，编排层就是刚需。验证方式是画一张调用链草图，数一下要跨几个系统、有没有写操作。
3. 第三问：失败一次能不能接受不能接受就先收敛成固定流程，把分支写死在代码里，别急着交给模型自主决策。能接受再逐步放开自由度，一边放一边补监控。

只上 RAG 的路线：先跑通，再谈效果

决定先做检索层，最容易犯的错是直接跳到调模型和换嵌入模型。上限其实在进料那一步就定了：文档干不干净、切片口径统不统一、更新频率跟不跟得上，这些没解决，后面怎么调都是白费。

验收也要讲方法。凭感觉说「好像变准了」没有任何意义，你需要一组固定的问题集，每次改配置都跑一遍，对比命中情况。问集要覆盖三类：正常问题、边界问题、明确没有答案的问题。

• 进料先定三件事：谁负责清洗、切片按什么口径、多久同步一次；
• 召回不理想时按顺序排查：切片方式 → 嵌入方式 → 召回条数 → 是否加重排，不要一上来就换模型；
• 每条回答尽量带上来源片段，方便人工复核，也方便后续定位问题；
• 更新频率和业务节奏对齐，天天变的资料就别按季度同步

只上 Agent 的路线：把工具接口当成产品来设计

决定先做编排层，核心工作量不在提示词，而在工具接口。工具就是模型的手，手的设计不好，模型再强也做不对事。每个工具都应该有清晰的入参约束、明确的失败返回，而不是让模型去猜。

另一个绕不开的是边界控制。步数上限、单步超时、重试次数，这三样必须在第一版就设好，否则一次跑飞的成本和排查时间都不可控。写操作之前还要留一个人工确认节点。

工具数量从小往大加

一开始别给太多工具。每多一个，模型选错的概率就上升一点。建议先给两三个必备工具跑通主流程，确认调用链稳定后再逐个加。每加一个都要重新跑一遍问题集，看有没有影响原有任务的完成率。

两者配合的三种常见形态

当需求落进「又查又做」那一档，两层就要配合。配合方式大致三种，差别在于检索发生在流程的哪个位置，选择依据是任务里检索的必要程度。

• 检索当工具：把知识库封装成一个可调用函数，灵活但更难预测调用次数；
• 先检索再编排：确定性更好，代价是每次都要走一遍检索，可能有浪费；
• 编排完再检索：适合结果要给人工看、需要解释的场景，注意别把中间结果当成事实依据；
• 可以叠加：主流程用第一种，最后补一次第三种，但每加一层都要重跑问题集

别把两层的日志混在一起

配合形态下最容易出问题的环节是排障。检索为空和工具报错，从用户视角看都是「没答上来」，但从工程视角是完全不同的两件事。日志里至少分开记：检索命中了哪些片段、编排调了哪些工具、每一步各花多少时间。

落地前必须定下的五件事

不管最后选哪条路线，下面这五件事都建议在动手写代码之前敲定，写进方案文档里。它们的共同点是：事后补的成本比事前定高得多。

1. 超时与预算定清单次请求的超时、单任务的总耗时上限、单任务允许的最大调用次数。这三条是成本和安全的下限，验证方式是压测时故意触发上限，看系统行为是否符合预期。
2. 降级顺序把模型不可用、检索为空、工具报错三种情况分开写清返回什么、要不要兜底答案、要不要转人工。做一次故障演练，逐个触发确认。
3. 日志字段至少记下请求标识、命中的知识片段、调用了哪些工具、每步耗时。验证方式是拿一条真实请求去回溯，能不能完整还原整个过程。
4. 评测口径准备一组覆盖正常、边界、无答案的问题，每次改动前后都跑。问题集要版本化，别随手改。
5. 成本归属把检索和编排的消耗分开统计，才知道钱花在哪一层。具体单价和用量到站内的价格页与追踪页面核对当时的数字。

选型不是选一个更强的组件，而是先把任务的终点写清楚：是找到，还是做成。

什么情况下这套判断不成立

上面这套判断有个隐含前提：需求本身有不确定性，答案不唯一。如果这个前提不成立，整套思路就不适用，硬套反而会做出更脆弱的系统。

• 需求是确定性流程，比如每月固定出报表、固定格式的字段抽取，直接用工作流编排，别套 Agent；
• 数据极度敏感、不允许外部调用时，先确认部署形态，选型结论可能整个反过来；
• 团队只有一两个人维护时，优先选组件少、调用链能一眼看懂的方案，可维护性比能力上限重要；
• 预算或合规卡得非常死时，先把能做的范围缩到最小，再谈能力扩展

还有一类容易忽略的情况：需求本身还在变。如果业务方自己都说不清要什么，先别做架构选型，先做一个纯提示词的原型跑起来看反馈。原型阶段的目标是确认需求，不是验证架构。