Agent与LLM工程化实战：从RAG瓶颈到GraphRAG与MCP的容错设计

1. 从一份日报说起Agent 与 LLM 生态到底在卷什么做 AI 应用开发这几年我养成了一个习惯每天早上花二十分钟扫一遍 Agent 和 LLM 领域的新动态。不是为了追热点而是这个领域的迭代速度实在太快——上周还在用的方案这周可能就被新的范式替代了。2026 年 9 月这个时间节点回头看整个技术栈已经和两年前完全不是一个面貌。以前大家聊的是怎么把大模型接进业务现在聊的是怎么让 Agent 稳定地自主干活。这份日报的选题本身就很有意思。它把 Agent、LLM、RAG、GraphRAG、MCP 这几个词放在一起基本勾勒出了当前 AI 工程化的完整拼图LLM 是底座能力Agent 是执行主体RAG 是知识供给GraphRAG 是知识组织的高级形态MCP 是连接外部世界的标准接口。这五块拼在一起才构成一个能真正落地的智能系统。单独看任何一块都不完整这也是为什么很多团队做出来的 Demo 很惊艳一上生产就拉胯——缺的往往不是模型能力而是这几层之间的工程衔接。我写这篇东西不是要复述日报里的条目而是想借这个由头把这几条技术线背后的真实工程问题拆开讲清楚。适合谁看如果你正在做 Agent 项目、正在搭 RAG 知识库、正在纠结要不要上 GraphRAG、或者被 MCP 的各种概念绕晕了那这篇应该能帮你省下不少试错时间。我会尽量说人话把那些文档里不会写的坑和取舍讲明白。先说一个我观察到的现象大部分 Agent 项目失败不是因为模型不够聪明而是因为容错没做好。热词里有个词叫识的 llm 智能体自主容错控制虽然表述有点绕但点到了要害。Agent 和传统程序最大的区别在于它的执行路径是不确定的同一个任务跑两次可能走不同的路。这就要求我们在设计时必须假设每一步都可能出错而不是假设它会按我想的走。这个思维转变是做好 Agent 工程的第一道门槛。2. LLM 底座选型别被榜单牵着鼻子走2.1 榜单分数和实际体感的差距在哪每次有新模型发布各种榜单就刷屏。但我在实际项目里踩过太多次坑榜单上排名靠前的模型放到具体业务里反而不如排名靠后的好用。原因很简单榜单考的是通用能力而你的业务考的是特定场景下的稳定性。举个例子做结构化信息抽取时某些在推理榜单上表现一般的模型因为指令遵循更严格输出格式反而更稳定。而一些聪明的模型喜欢自由发挥你让它输出 JSON它给你加一段解释解析直接崩掉。所以选型的第一步不是看榜单而是先明确你的任务类型是生成、抽取、分类、还是多轮决策不同类型对模型的要求完全不同。我一般会用一个简单的对照表来快速筛选任务类型优先看重的能力容易踩的坑结构化抽取指令遵循、格式稳定模型自作主张加解释长文生成上下文长度、连贯性长文后半段跑题多轮决策工具调用准确率参数幻觉、循环调用分类打标一致性、低温度稳定性边界样本摇摆2.2 本地部署还是调 API算一笔真实的账这个问题我被问过无数次。很多人一上来就说要私有化部署但根本没算过账。我的建议是先用 API 把业务跑通等调用量和数据敏感度都到临界点了再考虑本地化。算账的逻辑是这样的本地部署一台能跑中等规模模型的机器硬件成本加上运维人力一年下来是笔不小的固定支出。而 API 是按量付费业务没起来的时候几乎不花钱。只有当你的日均调用量稳定超过某个阈值本地部署的边际成本才会低于 API。这个阈值因模型规模而异但通常不是小数目。更重要的是本地部署带来的不只是成本问题还有一整套工程负担模型版本管理、推理服务稳定性、并发调度、显存优化……这些都需要专人维护。我见过太多团队模型是部署起来了但推理服务的可用性还不如直接调 API。所以除非有硬性的数据合规要求否则我一般建议先用 API 快速验证。提示如果确实需要本地部署优先考虑推理框架的成熟度而不是模型本身。一个推理框架不成熟的模型部署起来会让你怀疑人生。2.3 微调、RAG 还是提示词工程三条路的边界热词里有使用聊天记录模型精调 llm这代表了一类常见需求想让模型更懂自己的业务。但微调不是万能药很多时候 RAG 或者提示词工程就够了。我总结了一个判断标准知识类问题模型不知道的事实→ 优先 RAG因为知识会更新微调成本太高风格类问题模型知道但表达不对→ 优先提示词工程实在不行再微调能力类问题模型压根不会的技能→ 才考虑微调而且要有足够高质量数据微调最大的坑是数据质量。我见过团队拿几千条聊天记录直接去微调结果模型学了一堆废话和错误格式。聊天记录里充斥着口语、错别字、不完整表达直接拿来训练等于给模型喂垃圾。真要用聊天记录必须先做清洗和结构化把用户问-助手答整理成规范的指令数据这一步的工作量往往比训练本身还大。3. RAG 的瓶颈为什么你的知识库总是答不准3.1 检索不准八成是切分和嵌入的锅RAG 看起来简单把文档切块、向量化、存库、检索、拼进提示词。但真正做起来检索环节的坑最多。热词里rag 瓶颈这个词很真实大部分 RAG 系统的瓶颈就在检索质量上。最常见的错误是切分策略一刀切。很多人不管什么文档统一按固定字数切。结果技术文档被从代码块中间切断合同被从条款中间切断检索出来的片段语义不完整模型自然答不准。我的经验是切分要跟着文档结构走。Markdown 按标题层级切代码按函数切合同按条款切实在没有结构的才按语义切。嵌入模型的选择也很关键。热词里rag 知识库能存储图片嘛这个问题其实反映的是多模态检索的需求。纯文本嵌入模型处理不了图片如果你的知识库里有大量图表就得考虑多模态嵌入方案或者先用视觉模型把图片转成文字描述再入库。这个决策要在建库初期就定好后期改起来很痛苦。3.2 重排和混合检索被低估的两个提效手段很多人做完向量检索就收工了其实重排Rerank是性价比极高的优化点。向量检索召回的是语义相近的片段但相近不等于相关。重排模型会对召回的候选做精细打分把真正相关的排到前面。实测下来加上重排后答案准确率往往有明显提升。另一个被低估的是混合检索向量检索加关键词检索。向量检索擅长语义匹配但对专有名词、编号、代码符号不敏感。比如用户搜错误码 E1024纯向量检索可能召回一堆语义相近但编号不对的内容而关键词检索能精准命中。两者结合用加权或融合排序效果比单用任何一种都稳。检索方式擅长短板向量检索语义相近、同义表达专有名词、精确匹配关键词检索精确命中、编号符号同义表达、语义泛化混合检索兼顾两者需要调权重、实现复杂加重排精排相关性增加延迟和成本3.3 RAG 知识库和结构化知识库别混为一谈热词里有个很好的问题kg 知识库、rag 知识库和结构知识库区分以及应用场景。这三者经常被混着说但本质不同。RAG 知识库存的是非结构化文本的向量适合模糊查询、语义问答的场景比如客服问答、文档助手。结构化知识库比如关系型数据库、图数据库存的是实体和关系适合精确查询、关系推理的场景比如找出所有和某公司有股权关系的企业。KG 知识库知识图谱是结构化知识库的一种强调实体间的语义关系。实际项目里这三者往往是组合使用的。用户问一个模糊问题先用 RAG 检索相关文档再从文档里抽取实体去结构化库查精确信息最后综合回答。单独用任何一种都有局限组合起来才能覆盖复杂需求。4. GraphRAG什么时候值得上什么时候是过度设计4.1 GraphRAG 解决的到底是什么问题GraphRAG 这两年被炒得很热但很多人其实没搞明白它解决什么问题。简单说传统 RAG 处理不了全局性、跨文档的问题。比如你问这批文档里反复出现的核心矛盾是什么传统 RAG 只能召回几个片段拼不出全局图景。而 GraphRAG 通过构建实体关系图能沿着关系链做多跳推理回答这类问题就从容得多。它的核心思路是先把文档里的实体和关系抽出来建成图然后基于图做社区发现和摘要。查询时既能走图的关系路径也能结合向量检索。代价是建图成本高实体抽取要调模型图构建要处理冲突和消歧社区摘要又是一轮生成。所以它不是免费的午餐。4.2 判断要不要上 GraphRAG 的三个信号我的经验是满足以下信号之一才值得考虑 GraphRAG问题需要多跳推理答案不在单个文档里需要串联多个文档的信息实体关系是核心业务本身就以实体和关系为主比如风控、供应链、科研文献全局性问题频繁用户经常问整体趋势主要矛盾这类需要俯瞰的问题反过来如果你的场景就是简单的文档问答用户问的都是某条规定是什么这种单点问题那 GraphRAG 就是过度设计。我见过团队为了技术先进硬上 GraphRAG结果建图成本高、维护复杂效果还不如优化好的传统 RAG。4.3 Ontology RAG给知识加一层骨架热词里ontology rag值得单独说。Ontology本体本质上是给知识定义一套概念框架和关系规则。传统 RAG 是扁平的所有片段平等地躺在向量库里。而 Ontology RAG 会先定义好有哪些类型的实体、它们之间允许什么关系再按这个框架组织知识。好处是检索和推理更有章法。比如医疗场景本体里定义了疾病-症状-药物-禁忌的关系检索时就能沿着这些关系做约束避免召回不相关的内容。代价是前期建模成本高需要领域专家参与定义本体。所以它更适合领域边界清晰、知识结构相对稳定的场景比如医疗、法律、金融。5. MCP把 Agent 接进真实世界的标准接口5.1 MCP 到底解决了什么痛点MCPModel Context Protocol这两年的热度肉眼可见热词里从mcp 是什么到ruoyi-vue-pro 合并 mcp 功能再到altium designer ai 接口 mcp说明它已经从概念走向了各种具体工具的集成。它解决的核心痛点是Agent 要调用外部工具但每个工具的接入方式都不一样。以前每接一个工具就要写一套适配代码工具一多维护成本爆炸。MCP 提供了一套标准协议工具方按协议暴露能力Agent 方按协议调用双方解耦。这就像 USB 接口统一了外设连接一样是个基础设施级别的进步。我实测下来MCP 最大的价值在于让工具生态可以复用。一个团队写好的 MCP 服务别的团队可以直接用不用重复造轮子。热词里使用 mcp 工具流式输出内容到文件 cherrystudio就是典型场景通过 MCP 把文件操作能力标准化任何支持 MCP 的客户端都能调用。5.2 接入 MCP 时最容易忽略的细节MCP 用起来简单但有几个坑我踩过第一是权限边界。MCP 服务暴露的能力Agent 不一定都该用。比如文件操作服务如果 Agent 能删任意文件那就是灾难。所以接入时一定要做能力白名单只开放必要的操作。第二是错误处理。MCP 调用失败时返回的错误信息格式不统一Agent 很难判断是重试就行还是彻底失败。我的做法是在 MCP 服务层做一层错误归一化把错误分类成可重试和不可重试再返回给 Agent。第三是流式输出的处理。热词里流式输出内容到文件看着简单但流式场景下如果中途断了文件可能处于半写状态。稳妥的做法是先写临时文件全部完成后再原子性地重命名。注意MCP 服务的能力设计要遵循最小权限原则。宁可多拆几个细粒度的服务也不要做一个什么都能干的超级服务。5.3 MCP 和传统工具调用的取舍不是所有场景都值得上 MCP。如果你的 Agent 只调用一两个固定工具直接写函数调用更简单直接。MCP 的价值在工具多、需要复用、需要跨团队协作的场景。判断标准很简单当你的工具接入代码开始重复、开始难以维护时就是上 MCP 的时候。另外MCP 目前还在演进中协议细节可能变化。所以我在设计时会把 MCP 相关逻辑隔离在一个适配层里万一协议变了改适配层就行不影响业务代码。这个隔离设计是我做任何还在演进中的标准时的通用习惯。6. Agent 工程化容错、并发和安全这三座大山6.1 自主容错让 Agent 学会摔倒了爬起来回到开头说的那个词——自主容错控制。这是 Agent 从 Demo 走向生产的关键。传统程序出错会抛异常Agent 出错可能只是走错了一步如果不处理它会沿着错误路径一路狂奔。我的做法是给 Agent 设计多层容错单步重试工具调用失败时先重试几次很多失败是瞬时的路径回退如果某条执行路径连续失败回退到上一个决策点换条路走目标校验每完成一个子目标校验结果是否符合预期不符合就重新规划兜底降级实在搞不定转人工或返回明确的失败信息而不是硬编一个答案关键是每一步都要有可观测的状态。Agent 执行时我会把每一步的输入、输出、决策理由都记下来。出问题时能完整复现它的心路历程才知道是哪一步开始跑偏的。没有可观测性容错就是空谈。6.2 并发Agent 扛并发的难点不在模型热词里ai agent 怎么扛并发是个很实际的问题。很多人以为并发瓶颈在模型推理其实真正的瓶颈往往在工具调用和状态管理。模型推理可以批处理、可以加机器相对好扩展。但工具调用涉及外部系统每个工具都有自己的限流和延迟。如果 Agent 并发调用同一个工具很容易把下游打挂。我的做法是给每个工具配独立的限流器和队列Agent 的并发请求先排队按下游能承受的速率放行。状态管理也是难点。Agent 是有状态的多轮对话、任务上下文都要维护。高并发下状态存储的读写会成为瓶颈。我一般用带过期策略的分布式缓存存会话状态同时把长任务的状态持久化到数据库避免进程重启丢状态。6.3 Agent 安全被投毒的记忆和知识库热词里agentpoison: red-teaming llm agents via poisoning memory or knowledge ba点出了一个容易被忽视的风险Agent 的记忆和知识库可能被投毒。如果攻击者能往知识库里注入恶意内容Agent 检索到后可能被诱导做出危险操作。防御思路有几层入库前做内容审核过滤明显恶意的内容检索后做来源校验对来自不可信来源的内容降低权重或标记执行前做操作确认涉及敏感操作时要求二次确认。特别是当 Agent 有写权限时一定要限制它能写什么、写到哪避免被诱导去篡改关键数据。这块目前还没有银弹我的态度是假设知识库不可信在关键决策点加人工或规则兜底。安全这事宁可保守一点。7. 一些实操中的零碎经验聊了这么多框架性的东西最后分享几个我在实际项目里攒下的小经验都是文档里不太会写、但很影响体验的细节。关于 LLM as judge用模型给模型打分是个好工具但别全信。我一般用它做初筛把明显有问题的筛出来边界样本还是人工看。而且 judge 模型本身也有偏好比如倾向于给长回答高分所以评分标准要写清楚最好给几个示例校准。关于基于 LLM 的单元测试热词里提到这个我的经验是LLM 生成的测试用例适合做补充覆盖不适合做核心验证。它能发现一些你没想到的边界但生成的断言可能不严谨。稳妥的做法是 LLM 生成、人工审核后再纳入测试集。关于 Agent 框架选型框架更新太快我的建议是别把业务逻辑深度绑定到某个框架。用框架的编排能力但核心的业务逻辑、工具实现、状态管理尽量自己掌控。这样框架换代时迁移成本可控。我见过太多项目因为深度绑定某个框架框架一停更就动弹不得。关于提示词版本管理提示词是代码必须纳入版本管理。我见过团队改提示词全靠手改出了问题都不知道改前改后差在哪。把提示词存文件、进 Git、配变更记录这是基本功。关于成本控制Agent 的 token 消耗很容易失控尤其是多轮循环的场景。我会给每个任务设 token 预算上限超了就降级或终止。同时缓存高频查询的结果很多重复问题没必要每次都调模型。这些经验谈不上高深但都是真金白银试出来的。Agent 和 LLM 这个领域概念满天飞但真正决定项目成败的往往是这些不起眼的工程细节。把底座选对、把检索做准、把容错做扎实、把安全守住比追任何一个新概念都实在。