过去半年，只要聊RAG，十个人里有八个会问Agent。仿佛不往系统里塞一个能自主规划、调用工具、多步推理的智能体，你做的就不是下一代AI应用。工具调用的demo跑通了，CEO在屏幕前点头了，PR稿发出去了——然后呢？系统在生产环境里三天两头抽风，一个简单的问题要等十几秒才吐出答案，还时不时把销售数据塞进合规问答的上下文里。

这不是个例。

先搞清楚你面对的是什么问题

企业内部的知识问答，绝大多数是“信息获取型”任务——员工问年假怎么算、报销流程怎么走、某个产品的技术参数是多少。他要的是文档里的原话，要的是能点开看的出处链接。他不需要Agent替他决定“我觉得你应该休五天还是三天”，甚至不需要Agent去调用什么外部工具。

在纯信息获取的场景下，系统的核心使命只有一件事：把最相关的文档片段送到用户面前。

那这个场景的瓶颈在哪？在检索。

很多团队踩过的坑是这样的：兴致勃勃搭了一套RAG流水线，向量数据库嵌好了，LLM也接上了，结果用户问一个稍微带点条件的问题，召回的全是噪声。问“北京分公司的差旅标准”，出来的可能是总部的、上海分公司的、甚至三年前的版本。这时候第一反应往往是——是不是该上Agent了？让Agent做意图识别，让Agent分步检索，让Agent自己判断该查哪个知识库。

但真实情况是，连最基础的混合检索都没做好。没有关键词匹配，没有元数据过滤，没有查询改写，向量相似度搜索一竿子捅到底。这种底子，上Agent只会放大错误。Agent每多一步规划，就多一次犯错的机会，最终效果不是1+1=2，而是0.8的n次方。

代码Agent的成功被严重误读了

Claude Code这类编程Agent确实惊艳。但很少有人停下来想一想，它为什么有效。

代码是高度结构化的。变量命名有规律，函数调用有明确语法，import语句精确指向文件路径。在这种环境里，grep一把梭哈比什么向量检索都好使。你让Agent搜一个函数名，返回的结果100%精确，因为文本本身就在那里，不需要语义层面的“理解”。

换成企业内部的合同、会议纪要、年报PDF呢？grep搜“违约”可能搜出几百处，没有哪一处能直接回答问题“这份合同里的违约责任条款到底怎么写的”。语义检索是必要的，但语义检索本身就充满不确定性。向量空间里两个词的相似度是连续值，永远没有“绝对正确”的匹配。

编程Agent的成功，恰恰建立在不需要语义理解的基础上。把它的经验推广到语义密集的企业文档场景，这个推理链条本身就不牢靠。

长上下文也救不了你

还有人会说，现在上下文窗口都拉到百万token了，还做什么检索优化？直接把所有文档塞进去让模型自己找不就完了。

这个想法在成本账上就算不过来。百万token的输入，调用一次的钱够做几百次精检索。延迟呢？十几秒起步，用户早关页面了。更不用说当塞进去的干扰信息增多时，模型定位准确内容的能力会明显下降，这是“大海捞针”类测试反复验证过的事实——即便模型“捞得到”，速度和价格也不允许你在生产环境里这么干。

务实的做法恰恰相反：用更精准的检索把候选文档压缩到最少，只把高相关的三五段文本送进上下文。检索越准，上下文越短，回答越快，成本越低。

但有个更底层的问题，比检索和Agent都重要

很多团队在讨论“要不要上Agent”之前，其实连文档解析这道坎都没过。

PDF里的表格被解析成什么了？列和行还对得上吗？双栏排版的文档，阅读顺序有没有错乱？扫描件做的OCR，有没有把“履约”识别成“履钓”？这些事儿跟Agent一点关系都没有，但它们直接决定了你塞进向量库的文本是不是干净的。垃圾进，垃圾出，检索做得再花哨也白搭。

在优化检索算法之前，先用肉眼抽查十份被你“处理好了”的文档，看看解析后的文本有没有丢字、漏行、乱序。这一步的优先级，高于一切模型选型和调优。

Agent到底什么时候该上

先区分一个容易混淆的概念：复杂工作流和自主Agent是两回事。

如果你的任务需要“先查A知识库，再根据结果查B知识库，最后汇总”——这叫多步检索，用一个编排好的工作流（Workflow）就能解决，不需要Agent。每一步的逻辑是确定的、可预期的，系统只是在按预设的路线走。

Agent的关键特征是什么？是自主决策。它在运行时自己判断该用什么工具、该走哪条路径、什么时候停止、什么时候换一种策略。这才带来真正的不确定性。

什么时候需要这种不确定性？一个典型场景是写操作——不仅读取信息，还要更新数据库、发邮件、创建工单、改配置。这时候Agent的工具调用能力是刚需。另一个场景是真正的开放式探索，比如“帮我调研一下竞品最近半年的定价策略变化”，需要多轮搜索、阅读、判断、再搜索，中间路径无法预先穷举。

但如果你的场景只是“找到对的信息并呈现给用户”，Agent就是多余的。它不是锦上添花，而是往一杯干净水里加颜料。

一个更清醒的落地路线

务实的企业应该这么干：

第一，先搞定文档解析。确保PDF、Word、扫描件被转换成干净的、保留结构和顺序的文本。这一步不过关，后面全是白费。

第二，花力气把检索召回打磨到极致。清理元数据、上混合检索、做查询理解、加重排序。这些活不性感，不fancy，但每做一步效果都肉眼可见。

第三，等检索质量真的撞到天花板了，再去审视业务里那些需要多步确定流程的场景，用工作流编排来解决。

第四，只有到了需要与环境交互、自主决策的环节，才考虑引入Agent。

这个顺序不能乱。很多项目死在第一步，却把时间花在了讨论第四步该用哪个框架。

工具本身不是目的。让用户更快更准地拿到他想要的信息，才是。

RAG和Agent的关系从来不是替代，是分工。多数RAG项目在当下这个阶段就是不需要Agent——这不丢人，这恰恰说明你清楚自己要解决什么问题。