RAG应用里Agent到底该管什么？跟普通搜索流程边界好模糊

Agent的核心价值是处理模糊意图和跨源信息组装，纯事实查询真没必要让它先折腾一圈。

我觉得你举的那个Q3营收的例子挺典型的，如果数据本身在文档里格式规整，纯向量检索加rerank可能真就够用了，Agent强行去调工具反而增加延迟和不确定性。我自己的经验是，Agent的价值更在于处理那些需要多步推理或者跨文档聚合的复杂问题，比如“对比一下我们和竞品去年三个季度的增长差异”，这种query拆解和路径规划才值得它介入。至于重写query能力有限这事，我也有同感，现在很多Agent的改写其实是在跟embedding模型的语义理解较劲，不如把精力放在优化召回策略上。

说实话Agent在RAG里最大的价值不是替你做检索，而是帮你判断“该不该查”和“查完怎么用”。

老实说我觉得你那个例子挺典型的，Agent硬要去调日期工具反而暴露了它不懂“去年Q3”这种相对时间其实可以靠上下文推算。我个人感觉Agent的价值不在检索前后端，而是在处理那些需要多步推理、信息不全或者要跨多个数据源拼答案的场景，单纯的事实查询真没必要让它介入。另外你说重写query能力有限我也遇到过，最后发现不如把精力放在优化metadata过滤和rerank模型上，效果反而立竿见影。所以边界大概就是：检索能搞定的事别硬塞给Agent，它更适合当个“协调者”而不是“翻译官”。

Agent该管的是检索搞不定的模糊意图和多跳推理，简单查询直接向量加rerank就行，别硬塞。

我理解那种绕一圈的感觉，Agent最该管的其实是“检索搞不定的事”——比如query本身有歧义、需要多跳推理、或者要判断该不该检索。像“去年Q3”这种，与其让Agent调工具算日期，不如在query改写阶段直接归一化掉。纯向量加rerank能覆盖八成场景，Agent留给剩下那两成复杂意图就够了，别为了用而用。

Agent该管的是检索搞不定的模糊决策，比如多跳推理或该不该查，单纯问答加rerank确实够了。

我最近也在踩这个坑，感觉Agent在RAG里最容易变成“为了用而用”。你举的那个查日期的例子特别典型，其实很多意图判断用轻量分类或者规则就能搞定，硬塞给Agent反而多一跳延迟，还容易引入不确定性。我自己的体会是，Agent真正值钱的地方在于处理“检索解决不了的问题”，比如多跳推理、需要组合多个数据源、或者用户问题本身有歧义需要主动澄清。像“去年Q3”这种，如果知识库里文档都带时间元数据，直接过滤比让模型算日期靠谱得多。至于重写query，我觉得它更适合处理那种口语化、指代不明的情况，而不是用来弥补检索质量本身不行。chunk size和top_k调不好，说明索引和切分策略有问题，这时候让Agent背锅有点冤。我现在倾向的做法是：先用纯检索加rerank跑一版baseline，看bad case里有多少是检索能救的、多少是必须靠多步推理的，再决定Agent插在哪。如果只是单跳事实问答，Agent基本就是装饰品。