一个常见的架构误区：把所有问答都塞给 RAG（检索增强）。当用户问的是“有多少条待处理工单”“这个客户的订单当前是什么状态”这类精确问题时，用向量相似度检索去近似回答，会算错数，还分不清“这次没检索到”和“数据里确实没有”。
RAG 和 tool calling 解决的是不同类型的问题。混用错了，你的系统会以一种很自信的方式给出错误答案。
一、RAG 适合什么
RAG 的强项是开放语义和文档理解：
- “我们的退货政策是怎样的？”——答案在文档里，靠语义检索定位相关段落（通常取 top-k 3~10 段交给模型）。
- “这类故障通常怎么排查？”——从知识库里召回相关经验。
它本质是“找到相关文本，交给模型组织语言”，适合没有唯一精确答案、依赖文本理解的问题。
二、tool calling 适合什么
当答案是系统里可以精确计算出来的——数量、状态、聚合、事务——就该用 tool calling 直接查系统，而不是检索近似：
- “待处理工单有多少条” → 查数据库
count； - “这个订单当前状态” → 查订单表；
- “本月某指标合计” → 走聚合查询或计算器工具。
问题类型 → 该用什么
------------------------------------
精确计数 / 状态 / 事务 → tool calling（查真值）
开放语义 / 文档理解 → RAG（检索 + 组织语言）
两者都需要 → 混合：检索定位 + 工具取真值
三、混合：检索定位，工具取真值
很多真实问题是混合的：“帮我看看那个投诉最多的产品，最近的退货情况。” 这里“投诉最多的产品”可能靠检索/理解定位，而“退货情况”是精确数据，必须走工具查真值。合理的架构是让二者各司其职，而不是让 RAG 硬扛精确问题。
四、数据缺失要显式报告，不许猜
无论 RAG 还是 tool calling，都会遇到“查不到”。这里最贵的错误是：数据缺失时，Agent 编一个看起来合理的值继续往下走。
正确行为：
- 区分“本次没查到”和“对象不存在”，并说明是哪一种；
- 必需数据缺失时，明确报告不可用及原因，而不是补一个假值；
- 工具或检索超上下文容量时，按字段压缩并保留“记录总数”等完整性信号，不要静默截断。
常见问答
Q：都用 RAG 不行吗？省事。 A：精确问题用相似度近似会出错，还分不清漏检和不存在。省事的代价是自信地答错。
Q：怎么判断一个问题该走哪条路？ A：看答案是不是系统里能精确算出来的。能精确算的走工具，靠文本理解的走 RAG，混合的拆开。
Q：数据缺失时该怎么回? A：说明不可用并给原因，绝不编造。这是生产系统和 demo 最大的区别之一。
选对 RAG 还是 tool calling，是生产级 Agent 少出“自信的错误”的关键。这也是我们做生产级 AI Agent 系统时的基本判断：精确问题查真值、开放问题靠检索、缺数据就显式报告，不让模型硬猜。小结一句：先判断答案是不是系统里能精确算出来的，再决定走哪条路。想系统排查你的问答架构在哪些问题上会"自信答错"，可以做一次生产就绪自检。