尧图网站建设 
1. 为什么 Agentic RAG 不是“加个循环”那么简单Agentic RAG 这个词最近半年被聊得很多但真正在生产环境里跑过一轮的人都知道它跟传统 RAG 的差别远不止“让模型多调几次工具”这么轻巧。传统 RAG 的链路是线性的用户提问 → 向量检索 → 拼上下文 → 生成答案。Agentic RAG 则把这条链路改成了一个带决策的循环模型要自己判断“当前信息够不够”“要不要再检索”“检索哪个数据源”“什么时候停”。一旦引入这种自主性工程复杂度会指数级上升——Token 消耗失控、死循环、工具调用风暴、上下文污染这些问题在 Demo 阶段看不出来一上量就全暴露。我过去一年在三个不同规模的项目里落地过 Agentic RAG从内部知识库问答到面向 C 端的智能客服踩过的坑足够写一本小册子。这篇内容就是把这些经验浓缩成八条工程硬规则每一条都对应一个真实翻车场景。核心关键词会围绕Agentic RAG、ReAct、GraphRAG、Token、上下文这几个点展开但我不打算写成教科书而是按“判断—执行—刹车”的实际工程顺序来讲。适合谁看如果你已经搭过基础 RAG想往 Agent 方向演进或者你正在用 ReAct 范式做工具调用但发现成本和质量都不受控再或者你在评估 GraphRAG 到底值不值得上——那这篇内容应该能帮你省掉至少两个月的试错时间。下面所有规则都附带可落地的参数建议和排查思路不是泛泛而谈。2. 规则一先判断“要不要 Agent”再谈怎么 Agent2.1 什么场景才真正需要 Agentic RAG很多人一上来就想做 Agent觉得线性 RAG “不够智能”。但我的经验是80% 的问答场景线性 RAG 加上好的重排序和查询改写效果已经足够。Agentic RAG 真正有价值的场景只有三类。第一类是多跳推理。比如“我们公司去年 Q3 在华东区销售额最高的产品它的供应商今年有没有涨价”——这个问题需要先查销售数据再定位产品再查供应商合同单次检索根本拿不到完整信息。第二类是多数据源异构查询比如同时要查向量库、SQL 数据库和 API 接口且查询顺序依赖前一步结果。第三类是需要验证和反思的任务比如生成报告后要自己检查事实一致性不一致就重新检索。反过来如果你的场景是“用户问一个事实知识库里有就直接答”那上 Agent 就是杀鸡用牛刀Token 成本翻五倍延迟翻三倍效果还不一定更好。我见过一个团队花了三个月做 Agentic RAG最后发现把查询改写和重排序做好线性方案的效果只差 2 个百分点但成本只有十分之一。2.2 判断框架三个维度打分我通常用一个简单的三维打分来决定要不要上 Agent维度低分0-3高分7-10查询复杂度单事实问答多跳、多约束、需推理数据源数量单一向量库3 个以上异构源错误容忍度答错代价低答错有严重后果需自检三项加起来低于 12 分我建议先老老实实优化线性 RAG。高于 20 分Agentic RAG 才值得投入。中间地带可以先用“固定两步检索”这种半 Agent 方案过渡。注意这个打分不是绝对的但能帮你避免“为了 Agent 而 Agent”的常见陷阱。我见过太多团队因为技术焦虑上了 Agent结果维护成本高到想回退。2.3 一个真实的决策案例去年有个做法律咨询的客户一开始坚持要 Agentic RAG理由是“法律问题很复杂”。我让他们先跑了一周线性 RAG 的日志发现 70% 的查询其实是“某法条的具体内容是什么”这种单跳问题。最后方案改成了简单查询走线性只有涉及“对比”“因果”“多法条关联”的查询才触发 Agent 循环。上线后 Token 成本降了 60%用户满意度反而升了因为简单问题的响应速度快了一倍。这个案例说明一个道理Agent 的“判断”能力首先应该用在“判断要不要启动 Agent”上而不是一上来就全量走循环。3. 规则二ReAct 循环必须设硬性步数上限3.1 死循环是怎么发生的ReAct 范式的核心是 Thought → Action → Observation 的循环。问题在于大模型有时候会陷入“我觉得信息不够 → 再检索 → 还是觉得不够 → 再检索”的死循环。我实测过一个案例模型连续检索了 23 次每次都是相似的查询词Token 烧了 18 万最后还没给出答案。更隐蔽的是“工具调用风暴”。当你有多个工具时模型可能反复调用同一个工具或者在不同工具之间来回横跳。比如先查向量库觉得不够查 SQL又觉得向量库可能更全再查向量库……这种循环在日志里看起来每一步都“合理”但整体就是停不下来。3.2 硬性上限怎么设我的建议是双重上限步数上限和 Token 上限同时设谁先到就停。步数上限方面简单多跳任务设 5 步复杂推理任务设 8 步超过 8 步的基本可以判定为“模型没能力解决这个问题”继续循环也是浪费。Token 上限按单次查询预算来算我通常设 3 万到 5 万 Token 作为单查询上限超过就强制返回当前最优答案并附带“信息可能不完整”的提示。MAX_STEPS 8 MAX_TOKENS_PER_QUERY 40000 for step in range(MAX_STEPS): if total_tokens MAX_TOKENS_PER_QUERY: return fallback_answer(reasontoken_budget_exceeded) thought, action model.decide(context) if action finish: return generate_answer(context) observation execute(action) context.append(observation)这段伪代码的关键在于上限是硬编码的不是让模型自己判断。我试过让模型“自己决定什么时候停”结果它在 90% 的情况下都会多跑 2-3 步因为模型天生倾向于“再确认一下”。3.3 超限后的降级策略超过上限后不能直接报错要有降级方案。我的做法是如果已经检索到了部分信息就用现有上下文生成一个“尽力而为”的答案并明确标注哪些部分可能不完整。如果完全没检索到有效信息就返回“当前知识库无法回答该问题建议转人工”。这个降级策略看起来简单但能极大提升用户体验。用户宁愿要一个“可能不完整但有用”的答案也不想要一个“系统繁忙请重试”的报错。实操心得步数上限不要设得太紧。我一开始设了 3 步结果很多正常的多跳问题被截断。后来通过分析日志发现 5-8 步能覆盖 95% 的正常查询超过 8 步的几乎都是异常情况。4. 规则三上下文管理要“分层”不能一锅炖4.1 上下文污染的典型表现Agentic RAG 的上下文会随着循环不断增长里面混杂着原始问题、历史 Thought、工具调用结果、中间推理、系统提示词。如果不做管理会出现几个典型问题。一是注意力稀释。当上下文超过一定长度模型对关键信息的注意力会下降。我实测过同样的问题上下文从 4K 涨到 32K 后答案准确率下降了 15 个百分点。二是旧信息干扰。早期检索到的错误信息如果一直留在上下文里模型可能会被误导。三是Token 浪费把无关的历史全部带上每次调用都在烧钱。4.2 分层上下文的具体做法我的方案是把上下文分成四层每层有不同的保留策略层级内容保留策略系统层角色定义、工具说明、输出格式全程保留不裁剪任务层原始问题、约束条件全程保留推理层最近 3 步的 Thought 和 Action滑动窗口旧的压缩成摘要观察层工具返回结果只保留与当前问题相关的片段关键是推理层用滑动窗口 摘要。比如第 5 步时第 1-2 步的详细推理可以压缩成一句话“已确认产品 A 的销售数据”而不是保留完整的工具返回 JSON。这样既保留了推理链又控制了长度。4.3 上下文压缩的实操参数压缩时机当上下文超过模型窗口的 60% 时触发压缩。压缩比例把最早的 30% 内容压缩到原来的 20% 长度。压缩方法用一个小模型比如 7B 级别做摘要而不是用主模型这样成本低很多。我试过几种压缩策略最后发现“按步数压缩”比“按 Token 数压缩”更稳定。因为每一步的推理长度差异很大按 Token 数压缩容易把关键步骤压没。按步数的话比如“保留最近 4 步的完整内容更早的压缩”逻辑更清晰。注意压缩后的摘要要标注“这是历史摘要可能丢失细节”提醒模型在需要时重新检索而不是完全依赖摘要。5. 规则四GraphRAG 不是万能药用之前先算三笔账5.1 GraphRAG 的真实成本GraphRAG 这两年被炒得很热核心思路是把知识建成图结构检索时沿着实体关系走。听起来很美但落地成本很高。我算过三笔账。第一笔是构建成本。把文档转成知识图谱需要实体识别、关系抽取、图构建每一步都要调模型。一个 10 万篇文档的库构建一次图谱的 Token 成本大概在 5000-8000 美元耗时 3-5 天。第二笔是维护成本。文档更新时图谱要增量更新但增量更新比全量重建还麻烦因为要处理实体合并、关系冲突。第三笔是查询成本。图查询本身不贵但图检索返回的上下文往往很长因为要带上关系路径Token 消耗比向量检索高 2-3 倍。5.2 什么场景 GraphRAG 才划算GraphRAG 真正划算的场景是实体关系密集且查询需要多跳关联的领域。比如医疗诊断症状-疾病-药物关系、金融风控公司-股东-交易关系、供应链产品-供应商-物流关系。这些场景里向量检索很难捕捉“A 的供应商的竞争对手是谁”这种关系型问题。反过来如果你的知识库主要是叙述性文档实体关系稀疏那 GraphRAG 的投入产出比很低。我见过一个做企业制度问答的项目硬上 GraphRAG结果发现制度文档之间几乎没有实体关联图谱建出来是一堆孤岛效果还不如向量检索。5.3 混合方案GraphRAG 向量检索我的建议是不要二选一而是混合。具体做法是先用向量检索召回相关文档片段再用图谱扩展关联实体最后把两者拼进上下文。这样既保留了向量检索的语义匹配能力又利用了图谱的关系推理能力。参数上向量召回 Top 10图谱扩展 1-2 跳扩展出的实体再回查向量库拿具体内容。这个混合方案在我实测中比纯 GraphRAG 的准确率高 8 个百分点成本低 40%。方案准确率单查询成本适用场景纯向量72%低叙述性文档纯 GraphRAG78%高关系密集型混合方案86%中大多数场景6. 规则五工具设计要“窄而深”不要“宽而浅”6.1 工具过多的灾难Agentic RAG 里工具是模型的手脚。但工具不是越多越好。我见过一个项目给模型配了 15 个工具结果模型在工具选择上花了大量 Token而且经常选错。日志显示30% 的查询里模型至少调用了一个不相关的工具。工具过多的另一个问题是描述冲突。比如“搜索文档”和“查询知识库”两个工具功能高度重叠模型很难判断该用哪个。每次都要在 Thought 里纠结半天浪费步数。6.2 窄而深的设计原则我的原则是每个工具只做一件事但要做透。比如不要设计一个“查询数据”的万能工具而是拆成“按关键词搜文档”“按实体查图谱”“按条件查 SQL”三个专用工具。每个工具的输入输出格式要严格定义参数要少而精。工具数量控制在 5-7 个以内。超过这个数就要考虑合并或分层。分层的意思是先让模型选“工具类别”再在类别内选具体工具。这样每次决策的候选集小了准确率会提升。6.3 工具描述怎么写才有效工具描述不是写给人类看的是写给模型看的。我的经验是描述里要包含“什么时候用”和“什么时候不用”。比如{ name: search_documents, description: 按语义搜索文档片段。适用于查找事实性信息、定义、背景知识。不适用于查询结构化数据用 query_sql或实体关系用 query_graph。输入应为自然语言问题不要输入关键词列表。 }这个描述里“不适用于”那部分特别重要能减少 40% 的误调用。另外输入格式的说明也要具体比如“不要输入关键词列表”这种约束能避免模型把查询改写成奇怪的格式。实操心得工具描述写完后拿 20 个典型查询做测试看模型的选择准确率。如果低于 85%就回去改描述而不是加更多工具。7. 规则六Token 预算要按“查询类型”动态分配7.1 一刀切的预算为什么不行很多团队给所有查询设一个统一的 Token 预算比如“每次查询最多 5 万 Token”。问题是简单查询用不了这么多复杂查询又不够用。结果就是简单查询浪费预算复杂查询被截断。我分析过一批日志发现查询的 Token 消耗呈明显的双峰分布60% 的查询在 1 万 Token 以内解决20% 的查询需要 3-5 万 Token剩下 20% 是异常情况。一刀切设 5 万等于给 60% 的查询浪费了 4 万 Token 的额度。7.2 动态分配的具体方案我的做法是先分类再分配。用一个轻量分类器可以是小模型也可以是规则把查询分成三档查询类型特征Token 预算步数上限简单单事实、单跳80003中等多跳、需对比250006复杂多源、需推理500008分类器不需要很准80% 的准确率就够了。分错了也没关系因为预算只是上限不是必须用完。关键是让简单查询快速通过把资源留给真正需要的复杂查询。7.3 预算监控和动态调整上线后要持续监控 Token 消耗分布。如果发现某一档的查询经常触顶说明预算设低了要调高。如果某一档的查询平均只用了预算的 30%说明设高了可以调低。我通常每周看一次分布每月调一次参数。这个习惯帮我省了至少 30% 的 Token 成本而且没有影响效果。8. 规则七刹车机制要覆盖“异常”而不只是“超限”8.1 三种需要刹车的异常超限刹车是最基础的但实际运行中还有三种异常需要刹车。第一种是重复调用。模型连续调用同一个工具参数也几乎一样。这种情况说明模型卡住了继续跑没意义。我的检测方法是如果连续两步的工具名和参数相似度超过 90%就强制中断。第二种是矛盾观察。工具返回的结果和上下文里的信息矛盾模型却继续往下跑。比如先查到“产品 A 价格 100”后面又查到“产品 A 价格 200”模型不处理矛盾就继续。这种情况要中断让模型先解决矛盾。第三种是置信度骤降。模型在 Thought 里表达出“不确定”“可能不对”之类的信号且连续出现。这说明模型对自己的推理没信心继续跑大概率是错的。8.2 刹车后的处理刹车不是简单报错而是要有“软着陆”。我的做法是中断循环后用当前已有的上下文生成一个“部分答案”并明确告诉用户“以下信息可能不完整建议补充更多细节”。同时把这次异常记录到日志用于后续分析。对于重复调用和矛盾观察还可以触发“重新规划”清空推理层上下文只保留任务层让模型重新开始。但重新规划只能做一次第二次还异常就直接降级。8.3 刹车机制的参数异常类型检测方法阈值处理重复调用工具名参数相似度90% 连续 2 次中断重新规划矛盾观察数值/事实冲突检测冲突 1 次中断提示置信度骤降关键词检测连续 2 步中断降级这些阈值都是可以调的但建议一开始设严一点宁可多刹车也不要让异常跑完。跑一段时间后根据日志再放宽。9. 规则八评估体系要“过程结果”双轨9.1 只看结果为什么不够很多团队评估 Agentic RAG 只看最终答案对不对。问题是答案对了不代表过程对。我见过一个案例模型答案正确但过程里调用了 12 次工具Token 烧了 8 万。这种“对的但贵”的情况只看结果是发现不了的。反过来答案错了也不代表过程全错。有时候模型推理链是对的只是最后一步生成出了问题。如果只看结果就会误判为“推理能力不行”实际上要优化的是生成环节。9.2 过程指标怎么定我的过程指标主要有四个步数效率实际步数/最优步数、工具准确率正确调用/总调用、Token 效率有效 Token/总 Token、刹车率触发刹车的查询占比。步数效率低于 0.6 说明模型绕路了要优化工具描述或提示词。工具准确率低于 0.85 说明工具设计有问题。Token 效率低于 0.5 说明上下文管理要改进。刹车率高于 5% 说明异常处理有漏洞。9.3 评估集怎么建评估集要覆盖三类查询简单、中等、复杂比例大概是 5:3:2。每类查询要有标准答案和标准过程最优步数和工具调用序列。评估时结果和过程分别打分最后加权。我通常建 100-200 条评估集每周跑一次。评估集要定期更新把线上发现的 bad case 加进去。这样评估集越来越贴近真实场景评估结果也越来越有参考价值。实操心得评估集不要只建“难题”简单题也要有。因为简单题是基线如果简单题的过程指标都差说明基础能力有问题先修基础再修难题。10. 落地时的几个真实教训上面八条规则是框架但落地时还有一些“规则之外”的教训我觉得比规则本身更重要。第一个教训是不要追求一步到位。我第一个 Agentic RAG 项目想一次性把所有规则都实现结果代码复杂度爆炸调试了两周还没跑通。后来改成“先跑通最小循环再逐条加规则”反而快了。建议的顺序是先加步数上限再加 Token 预算再加上下文分层最后加刹车和评估。第二个教训是日志要记全。Agentic RAG 的调试难度比线性 RAG 高一个数量级因为每次查询的路径都不一样。我的做法是每一步的 Thought、Action、Observation、Token 消耗、耗时全部记下来存成结构化日志。这样出问题时可以完整回放定位效率高很多。第三个教训是不要迷信模型能力。我试过用更强的模型来“解决”循环问题结果发现强模型确实少绕几步但该绕的时候还是绕。工程规则的作用是兜底不是替代模型能力。两者要配合不能偏废。最后一个体会是关于“刹车”的。一开始我觉得刹车是失败后来发现刹车是保护。一个及时刹车的查询成本是 2 万 Token一个不刹车跑飞的查询成本是 20 万 Token还可能给出错误答案。从这个角度看刹车机制是 Agentic RAG 里性价比最高的投入。后续如果要做扩展我会优先考虑把评估体系自动化用 LLM 做过程打分减少人工评估的成本。另外上下文压缩的策略还可以再细化比如按查询类型用不同的压缩比例。这些方向等我跑一段时间再分享。 Agentic RAG 工程落地八条硬规则：从 ReAct 循环到 Token 预算的实战避坑指南
1. 为什么 Agentic RAG 不是“加个循环”那么简单Agentic RAG 这个词最近半年被聊得很多但真正在生产环境里跑过一轮的人都知道它跟传统 RAG 的差别远不止“让模型多调几次工具”这么轻巧。传统 RAG 的链路是线性的用户提问 → 向量检索 → 拼上下文 → 生成答案。Agentic RAG 则把这条链路改成了一个带决策的循环模型要自己判断“当前信息够不够”“要不要再检索”“检索哪个数据源”“什么时候停”。一旦引入这种自主性工程复杂度会指数级上升——Token 消耗失控、死循环、工具调用风暴、上下文污染这些问题在 Demo 阶段看不出来一上量就全暴露。我过去一年在三个不同规模的项目里落地过 Agentic RAG从内部知识库问答到面向 C 端的智能客服踩过的坑足够写一本小册子。这篇内容就是把这些经验浓缩成八条工程硬规则每一条都对应一个真实翻车场景。核心关键词会围绕Agentic RAG、ReAct、GraphRAG、Token、上下文这几个点展开但我不打算写成教科书而是按“判断—执行—刹车”的实际工程顺序来讲。适合谁看如果你已经搭过基础 RAG想往 Agent 方向演进或者你正在用 ReAct 范式做工具调用但发现成本和质量都不受控再或者你在评估 GraphRAG 到底值不值得上——那这篇内容应该能帮你省掉至少两个月的试错时间。下面所有规则都附带可落地的参数建议和排查思路不是泛泛而谈。2. 规则一先判断“要不要 Agent”再谈怎么 Agent2.1 什么场景才真正需要 Agentic RAG很多人一上来就想做 Agent觉得线性 RAG “不够智能”。但我的经验是80% 的问答场景线性 RAG 加上好的重排序和查询改写效果已经足够。Agentic RAG 真正有价值的场景只有三类。第一类是多跳推理。比如“我们公司去年 Q3 在华东区销售额最高的产品它的供应商今年有没有涨价”——这个问题需要先查销售数据再定位产品再查供应商合同单次检索根本拿不到完整信息。第二类是多数据源异构查询比如同时要查向量库、SQL 数据库和 API 接口且查询顺序依赖前一步结果。第三类是需要验证和反思的任务比如生成报告后要自己检查事实一致性不一致就重新检索。反过来如果你的场景是“用户问一个事实知识库里有就直接答”那上 Agent 就是杀鸡用牛刀Token 成本翻五倍延迟翻三倍效果还不一定更好。我见过一个团队花了三个月做 Agentic RAG最后发现把查询改写和重排序做好线性方案的效果只差 2 个百分点但成本只有十分之一。2.2 判断框架三个维度打分我通常用一个简单的三维打分来决定要不要上 Agent维度低分0-3高分7-10查询复杂度单事实问答多跳、多约束、需推理数据源数量单一向量库3 个以上异构源错误容忍度答错代价低答错有严重后果需自检三项加起来低于 12 分我建议先老老实实优化线性 RAG。高于 20 分Agentic RAG 才值得投入。中间地带可以先用“固定两步检索”这种半 Agent 方案过渡。注意这个打分不是绝对的但能帮你避免“为了 Agent 而 Agent”的常见陷阱。我见过太多团队因为技术焦虑上了 Agent结果维护成本高到想回退。2.3 一个真实的决策案例去年有个做法律咨询的客户一开始坚持要 Agentic RAG理由是“法律问题很复杂”。我让他们先跑了一周线性 RAG 的日志发现 70% 的查询其实是“某法条的具体内容是什么”这种单跳问题。最后方案改成了简单查询走线性只有涉及“对比”“因果”“多法条关联”的查询才触发 Agent 循环。上线后 Token 成本降了 60%用户满意度反而升了因为简单问题的响应速度快了一倍。这个案例说明一个道理Agent 的“判断”能力首先应该用在“判断要不要启动 Agent”上而不是一上来就全量走循环。3. 规则二ReAct 循环必须设硬性步数上限3.1 死循环是怎么发生的ReAct 范式的核心是 Thought → Action → Observation 的循环。问题在于大模型有时候会陷入“我觉得信息不够 → 再检索 → 还是觉得不够 → 再检索”的死循环。我实测过一个案例模型连续检索了 23 次每次都是相似的查询词Token 烧了 18 万最后还没给出答案。更隐蔽的是“工具调用风暴”。当你有多个工具时模型可能反复调用同一个工具或者在不同工具之间来回横跳。比如先查向量库觉得不够查 SQL又觉得向量库可能更全再查向量库……这种循环在日志里看起来每一步都“合理”但整体就是停不下来。3.2 硬性上限怎么设我的建议是双重上限步数上限和 Token 上限同时设谁先到就停。步数上限方面简单多跳任务设 5 步复杂推理任务设 8 步超过 8 步的基本可以判定为“模型没能力解决这个问题”继续循环也是浪费。Token 上限按单次查询预算来算我通常设 3 万到 5 万 Token 作为单查询上限超过就强制返回当前最优答案并附带“信息可能不完整”的提示。MAX_STEPS 8 MAX_TOKENS_PER_QUERY 40000 for step in range(MAX_STEPS): if total_tokens MAX_TOKENS_PER_QUERY: return fallback_answer(reasontoken_budget_exceeded) thought, action model.decide(context) if action finish: return generate_answer(context) observation execute(action) context.append(observation)这段伪代码的关键在于上限是硬编码的不是让模型自己判断。我试过让模型“自己决定什么时候停”结果它在 90% 的情况下都会多跑 2-3 步因为模型天生倾向于“再确认一下”。3.3 超限后的降级策略超过上限后不能直接报错要有降级方案。我的做法是如果已经检索到了部分信息就用现有上下文生成一个“尽力而为”的答案并明确标注哪些部分可能不完整。如果完全没检索到有效信息就返回“当前知识库无法回答该问题建议转人工”。这个降级策略看起来简单但能极大提升用户体验。用户宁愿要一个“可能不完整但有用”的答案也不想要一个“系统繁忙请重试”的报错。实操心得步数上限不要设得太紧。我一开始设了 3 步结果很多正常的多跳问题被截断。后来通过分析日志发现 5-8 步能覆盖 95% 的正常查询超过 8 步的几乎都是异常情况。4. 规则三上下文管理要“分层”不能一锅炖4.1 上下文污染的典型表现Agentic RAG 的上下文会随着循环不断增长里面混杂着原始问题、历史 Thought、工具调用结果、中间推理、系统提示词。如果不做管理会出现几个典型问题。一是注意力稀释。当上下文超过一定长度模型对关键信息的注意力会下降。我实测过同样的问题上下文从 4K 涨到 32K 后答案准确率下降了 15 个百分点。二是旧信息干扰。早期检索到的错误信息如果一直留在上下文里模型可能会被误导。三是Token 浪费把无关的历史全部带上每次调用都在烧钱。4.2 分层上下文的具体做法我的方案是把上下文分成四层每层有不同的保留策略层级内容保留策略系统层角色定义、工具说明、输出格式全程保留不裁剪任务层原始问题、约束条件全程保留推理层最近 3 步的 Thought 和 Action滑动窗口旧的压缩成摘要观察层工具返回结果只保留与当前问题相关的片段关键是推理层用滑动窗口 摘要。比如第 5 步时第 1-2 步的详细推理可以压缩成一句话“已确认产品 A 的销售数据”而不是保留完整的工具返回 JSON。这样既保留了推理链又控制了长度。4.3 上下文压缩的实操参数压缩时机当上下文超过模型窗口的 60% 时触发压缩。压缩比例把最早的 30% 内容压缩到原来的 20% 长度。压缩方法用一个小模型比如 7B 级别做摘要而不是用主模型这样成本低很多。我试过几种压缩策略最后发现“按步数压缩”比“按 Token 数压缩”更稳定。因为每一步的推理长度差异很大按 Token 数压缩容易把关键步骤压没。按步数的话比如“保留最近 4 步的完整内容更早的压缩”逻辑更清晰。注意压缩后的摘要要标注“这是历史摘要可能丢失细节”提醒模型在需要时重新检索而不是完全依赖摘要。5. 规则四GraphRAG 不是万能药用之前先算三笔账5.1 GraphRAG 的真实成本GraphRAG 这两年被炒得很热核心思路是把知识建成图结构检索时沿着实体关系走。听起来很美但落地成本很高。我算过三笔账。第一笔是构建成本。把文档转成知识图谱需要实体识别、关系抽取、图构建每一步都要调模型。一个 10 万篇文档的库构建一次图谱的 Token 成本大概在 5000-8000 美元耗时 3-5 天。第二笔是维护成本。文档更新时图谱要增量更新但增量更新比全量重建还麻烦因为要处理实体合并、关系冲突。第三笔是查询成本。图查询本身不贵但图检索返回的上下文往往很长因为要带上关系路径Token 消耗比向量检索高 2-3 倍。5.2 什么场景 GraphRAG 才划算GraphRAG 真正划算的场景是实体关系密集且查询需要多跳关联的领域。比如医疗诊断症状-疾病-药物关系、金融风控公司-股东-交易关系、供应链产品-供应商-物流关系。这些场景里向量检索很难捕捉“A 的供应商的竞争对手是谁”这种关系型问题。反过来如果你的知识库主要是叙述性文档实体关系稀疏那 GraphRAG 的投入产出比很低。我见过一个做企业制度问答的项目硬上 GraphRAG结果发现制度文档之间几乎没有实体关联图谱建出来是一堆孤岛效果还不如向量检索。5.3 混合方案GraphRAG 向量检索我的建议是不要二选一而是混合。具体做法是先用向量检索召回相关文档片段再用图谱扩展关联实体最后把两者拼进上下文。这样既保留了向量检索的语义匹配能力又利用了图谱的关系推理能力。参数上向量召回 Top 10图谱扩展 1-2 跳扩展出的实体再回查向量库拿具体内容。这个混合方案在我实测中比纯 GraphRAG 的准确率高 8 个百分点成本低 40%。方案准确率单查询成本适用场景纯向量72%低叙述性文档纯 GraphRAG78%高关系密集型混合方案86%中大多数场景6. 规则五工具设计要“窄而深”不要“宽而浅”6.1 工具过多的灾难Agentic RAG 里工具是模型的手脚。但工具不是越多越好。我见过一个项目给模型配了 15 个工具结果模型在工具选择上花了大量 Token而且经常选错。日志显示30% 的查询里模型至少调用了一个不相关的工具。工具过多的另一个问题是描述冲突。比如“搜索文档”和“查询知识库”两个工具功能高度重叠模型很难判断该用哪个。每次都要在 Thought 里纠结半天浪费步数。6.2 窄而深的设计原则我的原则是每个工具只做一件事但要做透。比如不要设计一个“查询数据”的万能工具而是拆成“按关键词搜文档”“按实体查图谱”“按条件查 SQL”三个专用工具。每个工具的输入输出格式要严格定义参数要少而精。工具数量控制在 5-7 个以内。超过这个数就要考虑合并或分层。分层的意思是先让模型选“工具类别”再在类别内选具体工具。这样每次决策的候选集小了准确率会提升。6.3 工具描述怎么写才有效工具描述不是写给人类看的是写给模型看的。我的经验是描述里要包含“什么时候用”和“什么时候不用”。比如{ name: search_documents, description: 按语义搜索文档片段。适用于查找事实性信息、定义、背景知识。不适用于查询结构化数据用 query_sql或实体关系用 query_graph。输入应为自然语言问题不要输入关键词列表。 }这个描述里“不适用于”那部分特别重要能减少 40% 的误调用。另外输入格式的说明也要具体比如“不要输入关键词列表”这种约束能避免模型把查询改写成奇怪的格式。实操心得工具描述写完后拿 20 个典型查询做测试看模型的选择准确率。如果低于 85%就回去改描述而不是加更多工具。7. 规则六Token 预算要按“查询类型”动态分配7.1 一刀切的预算为什么不行很多团队给所有查询设一个统一的 Token 预算比如“每次查询最多 5 万 Token”。问题是简单查询用不了这么多复杂查询又不够用。结果就是简单查询浪费预算复杂查询被截断。我分析过一批日志发现查询的 Token 消耗呈明显的双峰分布60% 的查询在 1 万 Token 以内解决20% 的查询需要 3-5 万 Token剩下 20% 是异常情况。一刀切设 5 万等于给 60% 的查询浪费了 4 万 Token 的额度。7.2 动态分配的具体方案我的做法是先分类再分配。用一个轻量分类器可以是小模型也可以是规则把查询分成三档查询类型特征Token 预算步数上限简单单事实、单跳80003中等多跳、需对比250006复杂多源、需推理500008分类器不需要很准80% 的准确率就够了。分错了也没关系因为预算只是上限不是必须用完。关键是让简单查询快速通过把资源留给真正需要的复杂查询。7.3 预算监控和动态调整上线后要持续监控 Token 消耗分布。如果发现某一档的查询经常触顶说明预算设低了要调高。如果某一档的查询平均只用了预算的 30%说明设高了可以调低。我通常每周看一次分布每月调一次参数。这个习惯帮我省了至少 30% 的 Token 成本而且没有影响效果。8. 规则七刹车机制要覆盖“异常”而不只是“超限”8.1 三种需要刹车的异常超限刹车是最基础的但实际运行中还有三种异常需要刹车。第一种是重复调用。模型连续调用同一个工具参数也几乎一样。这种情况说明模型卡住了继续跑没意义。我的检测方法是如果连续两步的工具名和参数相似度超过 90%就强制中断。第二种是矛盾观察。工具返回的结果和上下文里的信息矛盾模型却继续往下跑。比如先查到“产品 A 价格 100”后面又查到“产品 A 价格 200”模型不处理矛盾就继续。这种情况要中断让模型先解决矛盾。第三种是置信度骤降。模型在 Thought 里表达出“不确定”“可能不对”之类的信号且连续出现。这说明模型对自己的推理没信心继续跑大概率是错的。8.2 刹车后的处理刹车不是简单报错而是要有“软着陆”。我的做法是中断循环后用当前已有的上下文生成一个“部分答案”并明确告诉用户“以下信息可能不完整建议补充更多细节”。同时把这次异常记录到日志用于后续分析。对于重复调用和矛盾观察还可以触发“重新规划”清空推理层上下文只保留任务层让模型重新开始。但重新规划只能做一次第二次还异常就直接降级。8.3 刹车机制的参数异常类型检测方法阈值处理重复调用工具名参数相似度90% 连续 2 次中断重新规划矛盾观察数值/事实冲突检测冲突 1 次中断提示置信度骤降关键词检测连续 2 步中断降级这些阈值都是可以调的但建议一开始设严一点宁可多刹车也不要让异常跑完。跑一段时间后根据日志再放宽。9. 规则八评估体系要“过程结果”双轨9.1 只看结果为什么不够很多团队评估 Agentic RAG 只看最终答案对不对。问题是答案对了不代表过程对。我见过一个案例模型答案正确但过程里调用了 12 次工具Token 烧了 8 万。这种“对的但贵”的情况只看结果是发现不了的。反过来答案错了也不代表过程全错。有时候模型推理链是对的只是最后一步生成出了问题。如果只看结果就会误判为“推理能力不行”实际上要优化的是生成环节。9.2 过程指标怎么定我的过程指标主要有四个步数效率实际步数/最优步数、工具准确率正确调用/总调用、Token 效率有效 Token/总 Token、刹车率触发刹车的查询占比。步数效率低于 0.6 说明模型绕路了要优化工具描述或提示词。工具准确率低于 0.85 说明工具设计有问题。Token 效率低于 0.5 说明上下文管理要改进。刹车率高于 5% 说明异常处理有漏洞。9.3 评估集怎么建评估集要覆盖三类查询简单、中等、复杂比例大概是 5:3:2。每类查询要有标准答案和标准过程最优步数和工具调用序列。评估时结果和过程分别打分最后加权。我通常建 100-200 条评估集每周跑一次。评估集要定期更新把线上发现的 bad case 加进去。这样评估集越来越贴近真实场景评估结果也越来越有参考价值。实操心得评估集不要只建“难题”简单题也要有。因为简单题是基线如果简单题的过程指标都差说明基础能力有问题先修基础再修难题。10. 落地时的几个真实教训上面八条规则是框架但落地时还有一些“规则之外”的教训我觉得比规则本身更重要。第一个教训是不要追求一步到位。我第一个 Agentic RAG 项目想一次性把所有规则都实现结果代码复杂度爆炸调试了两周还没跑通。后来改成“先跑通最小循环再逐条加规则”反而快了。建议的顺序是先加步数上限再加 Token 预算再加上下文分层最后加刹车和评估。第二个教训是日志要记全。Agentic RAG 的调试难度比线性 RAG 高一个数量级因为每次查询的路径都不一样。我的做法是每一步的 Thought、Action、Observation、Token 消耗、耗时全部记下来存成结构化日志。这样出问题时可以完整回放定位效率高很多。第三个教训是不要迷信模型能力。我试过用更强的模型来“解决”循环问题结果发现强模型确实少绕几步但该绕的时候还是绕。工程规则的作用是兜底不是替代模型能力。两者要配合不能偏废。最后一个体会是关于“刹车”的。一开始我觉得刹车是失败后来发现刹车是保护。一个及时刹车的查询成本是 2 万 Token一个不刹车跑飞的查询成本是 20 万 Token还可能给出错误答案。从这个角度看刹车机制是 Agentic RAG 里性价比最高的投入。后续如果要做扩展我会优先考虑把评估体系自动化用 LLM 做过程打分减少人工评估的成本。另外上下文压缩的策略还可以再细化比如按查询类型用不同的压缩比例。这些方向等我跑一段时间再分享。