这周命题是「RAG 和 Agent 的从属关系」。我的判断很直接：RAG 是 Agent 工具箱里的一个工具，不配当底座。把检索写死在每轮开头，是在用固定管线偷懒。但反面我也认——有些场景，固定管线就是正确答案。分界线在哪，下面说。

检索返回的是文档列表，不是答案

周一 ArXiv 上 AskChem 这篇，讲化学文献综述的，摘要里一句话戳中我：现有检索系统「primarily return ranked document lists」，科学家和 AI agent 还得自己定位相关信息、验证出处、组装跨论文的答案。

问题就在这。检索只是找材料。组装、验证、推理，才是 agent 真正该干的活。你把 RAG 当底座，等于把「找材料」当成整条流水线——材料拉回来了，后面组装没人管，那要 agent 干嘛？

还有个佐证，Handbook.md 这篇说长政策文档不能可靠地约束 agent。这跟 RAG 也是同一件事：你把政策文档检索进上下文，指望 agent 照着执行，结果文档一长，模型根本不逐条遵守。检索进来了，约束没进来。又一次证明——检索不等于答案。

让模型自己决定要不要检索，代价是延迟不可控

我见过把 RAG 写死在每轮开头的系统。每轮先怼 top-k 进上下文，不管当前这一步到底需不需要外部知识。省心是真省心，但浪费也真浪费——上下文里塞满无关段落，模型还得自己学会忽略。

让模型自己决定检索，质量确实更好。该查才查，不该查不查，上下文干净，回答也直接。但延迟不可控——模型可能连查三次，也可能一次不查，prompt 调起来费劲。用户等不起的时候，你没法跟他说「模型在思考要不要检索」。

这是工程权衡，不是免费的午餐。固定管线的价值就在于可预期，而这恰恰是自由检索的反面。

反面观点我认。知识边界清晰的客服场景——供应商的 FAQ，知识库就几百条规则，用户问题基本能枚举——固定 RAG 管线又稳又便宜。每轮都检索，延迟可控，结果可预期，出问题也好查。为什么要给 FAQ 机器人上「自主决策」？我不信。

PostHog 那篇讲能委托多少给 agent 的，我觉得问到了真问题。委托度越高，不可控性越大，你要投入的监控成本越高。客服场景恰恰是委托度最低的场景，固定管线是对的。

我的判断标准就三个问题：

前两个答「清晰」+「不需要」，延迟又敏感——固定 RAG 管线，别折腾。开放性问题，答案需要跨文档组装、验证来源——让 agent 自己决定怎么用检索这个工具，别把检索写进每轮开头。

按我现在看，多数内部工具场景落在中间地带：知识边界半清晰，答案多少要推理，延迟有点敏感但能忍。这种场景没有银弹，只能自己试。也许 6 个月后回头看，连「工具还是底座」这个问题本身都会被重构——但那是后话。