很多人卡在同一个地方：手上这套东西到底算 agentic AI，还是只是给 RAG 套了个循环？叫错名字不影响跑，但影响你怎么设超时、怎么限步数、怎么做评测和降级。这篇不纠结名词本身，给一套按「谁决定下一步、资料在不在回路里、失败怎么收场」来判断的办法，再给一张对照表和落地检查顺序，让你能对着自己的代码把边界划清楚。
很多人卡在同一个地方：手上这套东西到底算 agentic AI，还是只是给 RAG 套了个循环。叫错名字不影响它跑，但影响你怎么设超时、怎么限步数、怎么做评测和降级——这三样一旦按错的那类去配，线上就会用很奇怪的方式坏掉。
这篇不纠结名词本身，给一套按「谁决定下一步、资料在不在回路里、失败怎么收场」来判断的办法，再给一张对照表和落地检查顺序。你对着自己的代码逐条过一遍，就能把边界划清楚，也能知道哪些地方其实两边通用、不用硬分。
先用三个问题把边界问清楚
别一上来就看架构图，先问三个问题，答不上来的地方就是你还没想清楚的地方。这三个问题的顺序也有讲究：第一个问题决定它是不是 agent，第二个决定它是不是 RAG 那一路，第三个决定它能不能上线。
- 第一问：下一步动作由谁定是预先写死的流程分支，还是模型每轮自己选工具、选检索词、决定要不要再查一次。只要还是固定编排，只是把模型塞进一个 if-else 里，叫它 agentic 就是抬举；这种情况按普通流水线配参数反而更稳。
- 第二问：外部资料在不在决策回路里资料只在入口拼一次进上下文，那属于带检索的生成；资料能反过来触发下一轮动作——比如查到的东西让模型决定换个关键词再查——才算 agentic RAG。区别不在于查没查，而在于查的结果能不能改变接下来的路。
- 第三问：失败由谁收场跑到一半查不到、工具报错，是直接甩一句兜底话术给用户，还是模型自己换策略重试或降级。第三问答不上，往往说明这只是个套壳，前两问的答案也别太当真。
重叠区和交叉区：哪些能力两边都占
把两类东西拆成能力清单看，会发现它们的公共底座几乎一样：多轮循环、工具注册、状态传递、终止条件。真正的差别只在一个点上——检索是不是被当成一等工具，能不能改变后续决策。按产品名字归类容易吵起来，按能力打勾就清楚多了。
| 能力项 | agentic RAG | 通用 agentic AI |
|---|---|---|
| 多轮循环 | 有 | 有 |
| 工具注册 | 通常只有检索 | 多种外部工具 |
| 状态传递 | 有 | 有 |
| 检索是否一等工具 | 是，且驱动下一步 | 看配置，挂了才算 |
| 失败面宽度 | 窄，集中在检索 | 宽，工具越多越杂 |
| 护栏松紧 | 可以更松 | 要更紧 |
- agentic AI 若挂了一个检索工具，实质上就是 agentic RAG，不用硬区分，重点转成检索这一环的质量和预算怎么控。
- 反过来，agentic RAG 如果只允许调检索、没有别的工具，它的失败面比通用 agent 窄很多，超时和重试策略可以简单不少。
- 同一套代码在不同配置下可能两边都算，所以别在代码注释里写死「这是 agentic AI」，写清楚它当前挂了几类工具更实用。
- 判断时按能力清单逐项打勾，勾完看哪几项是关键路径，再决定参数往哪边靠。
落到工程参数上，两边的取舍差在哪
边界划清楚之后，真正影响线上表现的是下面这几组参数。它们不是理论差异，是你在配置文件里要填的具体值，填错方向就会在高峰期以奇怪的方式暴露出来。
- 超时口径
- 只带检索的循环单步耗时可预测，整体超时按步数乘单步估计就够；带多种工具的 agent 方差大，建议给整轮设上限，而不是只给单步设。
- 并发与限流
- 检索类调用容易在同一秒打爆向量库，要给检索单独排队；工具类调用要按外部接口的额度分档退避，别共用一个队列。
- 日志字段
- 两类都要记每轮决策理由、用了哪个工具、命中哪段资料、花了多少 token；缺了「为什么再查一次」这条，事后没法复盘。
- 降级顺序
- agentic RAG 降级优先退成单次检索加生成；通用 agent 降级优先砍工具白名单，只留最稳的那一两个。
这些数字没有通用答案，跟你自己的资料量、接口额度、用户容忍度都有关。想知道同行的实际配置区间，可以去站内价格与成本追踪页核对当时的数字，再回到自己的压测结果上做取舍。
落地检查顺序：从上到下逐条过
下面这五步是按依赖关系排的，跳步做很容易返工。建议拿一张纸或者一个文档，逐条写结论，写不出来的那条就是当前最大的风险点。
- 第一步：画实际调用图把每个决策点和每个外部调用标出来，看有没有模型自主分支。图上有自主分支才进下一步，没有的话直接按流水线处理更省事。
- 第二步：定终止条件步数上限、成本上限、连续无新信息就停，三条里至少写两条。只写步数上限的话，遇到每步都很便宜的循环会烧得比预期久。
- 第三步：给检索和工具分别设预算别共用一个总预算，否则一边跑飞会拖死另一边。检索超预算就停检索，工具超预算就砍工具，两边的告警也要分开。
- 第四步：准备固定用例做回归改提示词或换模型后重跑，看成功率和平均步数有没有变差。用例集规模按自己能维护的量来，贪多会导致没人愿意更新。
- 第五步：确认不可用时怎么办检索挂了、工具超时、模型拒绝，各自要有兜底文案和可观测的告警点。这一步做完才算能上线，前面四步只保证跑得对。
这些判断什么时候不适用
上面这套判断不是万能钥匙，有几类场景里它价值不大，硬套反而增加沟通成本。遇到下面这些情况，直接按更简单的形态做就行。
- 纯离线批处理、没有实时交互的场景，边界划分对工程参数影响很小，可以简化，重点放到结果校验上。
- 已经上了强编排框架、所有分支都由配置决定的，模型自主空间本来就窄，讨论 agentic 与否意义不大。
- 单次问答、资料量极小、不需要多轮修正的场景，直接用一次性检索加生成更省事，硬上循环只会拉高成本和延迟。
- 团队只有一两个人维护时，先按最简单的形态上线，等出现「一次检索答不准」的真实投诉再往 agentic 走。
另外注意，这些结论是在「你已经有检索能力和基本评测」的前提下成立的。如果连检索质量都没稳定下来，先解决召回和排序，再谈要不要加循环，顺序反了会同时怀疑三个变量。
下一步拿你的调用图对照上面的检查顺序过一遍，再去看站内中转站可信度检测和工具目录，把检索链路上的实际服务商和延迟表现核一遍，确认自己该往哪边配参数。→常见问题
我现在的项目挂了一个搜索工具，算 agentic RAG 还是 agentic AI？
看这个工具是不是唯一能让模型影响下一步的手段。如果模型只能决定查不查、查什么词，动作范围全在检索里，叫 agentic RAG 更准。如果它还能写文件、调外部接口、再根据结果换路径，那就是通用 agent，检索只是它的一个工具。不用纠结名字，按能力清单打勾更实用。
两边在成本控制上有什么实质区别？
主要差在方差。只带检索的循环，每轮花多少 token 大致可预测，预算好估；带多种工具的 agent，某些轮次会突然变长变贵。所以 agentic RAG 可以按步数均摊预算，通用 agent 更适合给整轮设成本上限加中途熔断。要按当时的单价折算，去 /tools/model-cost-calculator 和 /official-api 核对再算。
上线前最少要做哪些验证才算过关？
三件事：一是固定一组用例跑通，记录成功率和平均步数；二是人为把检索和工具打断一次，看兜底是不是干净、有没有把错误原样抛给用户；三是压一轮并发，看检索和工具各自的排队是否生效。测速基线可以先到 /tools/speed-test 量一下。
