1. 从一份日报标题说起Agent 与 LLM 生态正在发生什么看到Agent / LLM 技术精选日报这个标题很多人第一反应是又是一个资讯聚合。但如果你真的在一线做 Agent 和 LLM 相关的东西就会明白这类日报背后其实藏着一个非常现实的问题这个领域的信息密度太高了高到一天不跟进就可能错过一个关键协议、一个框架更新、或者一个踩坑预警。我自己从 2023 年开始做 RAG 相关的项目到后来转向 Agent 编排和 MCP 工具链集成最大的感受就是——信息筛选本身就是一项工程能力。这份日报涉及的关键词非常密集Agent、LLM、RAG、MCP、GraphRAG。这几个词不是并列关系而是有层次的。LLM 是底座RAG 是让 LLM 能对接外部知识的手段Agent 是在 LLM 之上加了规划、工具调用、记忆的自主系统MCP 是让 Agent 能标准化调用外部工具的协议层GraphRAG 则是 RAG 在知识结构化方向上的进阶方案。理解这个层次关系比记住每个词的定义重要得多。这篇文章我想做的事情不是复述日报里有什么而是把这几个核心概念之间的工程关系讲透把每个环节里真正会踩的坑说清楚再给出一套可以直接参考的落地思路。适合谁看如果你正在做 RAG 知识库、正在搭 Agent 工作流、正在纠结要不要上 MCP、或者被 GraphRAG 的概念绕晕了这篇应该能帮你理清一些东西。如果你只是刚听说这些词也没关系我会尽量用生活化的类比把底层逻辑讲明白。2. 核心概念拆解LLM、RAG、Agent、MCP、GraphRAG 到底是什么关系2.1 用一家餐厅来理解这五个概念我习惯用餐厅来类比这套体系。LLM 就是那位博学但有点健忘的主厨——他懂很多菜系但你问他我们店上周进的这批松露还剩多少他答不上来因为他没有你店里的实时数据。RAG 就是给主厨配了一个食材仓库管理员主厨做菜前先问管理员要相关食材信息再动手。Agent 就是餐厅经理他不只做菜还要接单、安排后厨、处理客人投诉、决定什么时候该叫主厨、什么时候该叫服务员。MCP 就是餐厅的标准点单系统让经理能用统一的方式跟后厨、仓库、收银台沟通而不是每次都要重新学一套方言。GraphRAG 则是把仓库管理员的账本从流水账升级成关系图谱不仅知道有什么食材还知道食材之间的搭配关系、替代关系、产地关系。这个类比能解释很多实际问题。比如为什么 RAG 会有瓶颈——因为仓库管理员再厉害主厨如果不会问问题或者问的问题太模糊照样拿不到对的食材。为什么 Agent 需要 MCP——因为如果没有标准协议每接一个新工具就要重写一遍对接逻辑维护成本会爆炸。为什么 GraphRAG 会出现——因为传统 RAG 基于向量相似度检索处理不了这道菜的替代食材有哪些这种需要关系推理的问题。2.2 为什么这几个概念总被放在一起讨论因为它们解决的是同一个问题的不同层面如何让 LLM 从聊天玩具变成能干活的系统。单独一个 LLM你只能做对话、生成、总结。加上 RAG它能回答基于你私有知识的问题。加上 Agent 架构它能自主规划多步任务。加上 MCP它能调用真实世界的工具。加上 GraphRAG它能处理复杂的知识关系。我在实际项目里的体会是很多人一上来就想做全能 Agent结果连最基础的 RAG 检索质量都没搞定最后做出来的东西答非所问。正确的路径应该是先把 LLM 的基础调用和 prompt 工程做扎实再上 RAG 解决知识问题再考虑 Agent 解决流程问题最后才考虑 MCP 和 GraphRAG 这些进阶方案。顺序错了返工成本极高。2.3 一张表看清五个概念的分工概念解决的核心问题典型使用场景上手难度常见误区LLM语言理解与生成对话、总结、翻译、代码生成低以为它能记住所有事RAG私有知识接入企业知识库、文档问答中以为向量检索万能Agent多步任务自主执行自动化工作流、复杂查询中高以为越自主越好MCP工具调用标准化多工具集成、跨系统协作中以为必须用 MCPGraphRAG知识关系推理复杂知识图谱问答高以为一定要上图谱这张表是我自己踩坑之后总结的。特别是常见误区那一列每一条都是我或者身边朋友真实踩过的。比如以为向量检索万能——我见过太多项目用户问我们公司去年 Q3 的营收和 Q2 比怎么样纯向量检索根本搞不定因为它需要的是结构化查询而不是语义相似度匹配。3. RAG 实战从知识库搭建到检索瓶颈突破3.1 RAG 知识库到底能存什么图片行不行这是热搜里出现频率很高的问题rag知识库能存储图片嘛。答案是能但方式和你想象的不一样。RAG 知识库本质上存的是向量化的文本片段图片本身不能直接变成向量存进去。但你可以通过几种方式让图片进入 RAG 体系。第一种是图片转文字描述。用多模态模型给图片生成详细描述把描述文本存进知识库。这种方式简单但会丢失图片里的细节信息。第二种是图片 OCR 提取文字。如果图片主要是文档截图、表格、图表OCR 提取出来的文字直接入库效果通常不错。第三种是多模态向量。用支持图文联合嵌入的模型把图片和文本映射到同一个向量空间检索时可以用文字搜图片。这种方式最先进但对模型和存储的要求也最高。我自己的项目里用得最多的是第二种加第一种的组合先 OCR 提取文字再让多模态模型补充一段整体描述两段文本都入库。实测下来对于技术文档、产品手册这类场景召回率比单纯 OCR 高不少。但要注意图片描述的质量直接决定检索质量如果描述生成得太笼统比如一张架构图那基本等于没存。3.2 RAG 检索瓶颈的三个真实来源很多人做 RAG 做到一半会发现效果上不去然后开始怀疑是不是模型不行。其实大部分时候问题不在模型而在检索环节。我总结下来RAG 检索瓶颈主要来自三个地方。第一个是分块策略不合理。文本切得太碎一个完整的意思被切成好几段检索时只能召回片段LLM 拿到的是残缺信息。切得太大一个块里混了好几个主题向量表示被稀释检索精度下降。我的经验是技术文档按 500 到 800 字切带 10% 到 20% 的重叠对话记录按轮次切代码按函数切。这个没有万能公式必须根据你的数据特点调。第二个是嵌入模型和查询不匹配。用户问的是口语化问题你的知识库是正式文档如果嵌入模型没有针对这种跨风格做优化检索效果会很差。解决办法要么是换更强的嵌入模型要么是在检索前做一次查询改写把口语化问题改写成更接近文档风格的表述。第三个是缺少重排序。向量检索召回 top-k 之后直接丢给 LLM这是很粗糙的做法。加一个重排序模型比如基于交叉编码器的 reranker对召回的候选做精排通常能把准确率提升 20% 到 40%。这一步的性价比极高强烈建议加上。3.3 一个可复现的 RAG 最小实现下面这段代码是我常用的 RAG 最小骨架去掉了所有花哨的东西只保留核心流程。你可以直接拿去改。from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Chroma from langchain.chat_models import ChatOpenAI from langchain.chains import RetrievalQA # 1. 分块 splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap100, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_text(raw_document) # 2. 嵌入与存储 embeddings OpenAIEmbeddings() vectorstore Chroma.from_texts(chunks, embeddings, persist_directory./db) # 3. 检索加问答 retriever vectorstore.as_retriever(search_kwargs{k: 5}) qa_chain RetrievalQA.from_chain_type( llmChatOpenAI(modelgpt-4o-mini, temperature0), retrieverretriever, return_source_documentsTrue ) result qa_chain({query: 我们产品的退款政策是什么}) print(result[result])这段代码能跑但只是起点。真正上线要加的东西包括重排序、查询改写、多路召回、缓存、以及最重要的——评估体系。没有评估你根本不知道改动是变好了还是变差了。3.4 RAG 评估别凭感觉说效果好我见过太多团队RAG 做完之后靠感觉判断效果。问几个问题答得还行就上线了。结果真实用户一用问题全暴露。RAG 评估必须量化核心指标有三个召回率相关文档有没有被检索到、精确率检索到的文档有多少是相关的、答案忠实度生成的答案有没有偏离检索到的内容。实操上我会先人工标注 50 到 100 个问答对作为测试集然后每次改动都跑一遍。召回率和精确率可以用脚本自动算答案忠实度可以用 LLM as judge 的方式评估——让另一个 LLM 判断生成的答案是否完全基于检索内容。这个流程搭起来大概半天但能帮你省下无数返工时间。提示评估集一定要包含难例也就是那些你直觉上觉得会出问题的问题。只测简单问题评估结果会虚高。4. Agent 架构从自主性到可靠性的工程取舍4.1 Agent 是什么和普通 LLM 调用差在哪agent是什么这个问题在热搜里反复出现说明很多人还没搞清楚。我的定义很简单Agent 是一个能自主决定下一步做什么的 LLM 系统。普通 LLM 调用是你问一句它答一句Agent 是你给一个目标它自己拆解步骤、调用工具、检查结果、决定继续还是停止。这个自主决定是双刃剑。好处是能处理复杂任务坏处是容易跑偏。我做过一个自动整理会议纪要的 Agent目标是把会议录音转成结构化纪要。它自己决定先转写、再分段、再提取待办、再生成摘要。听起来很顺但实际跑的时候它有时候会在提取待办这一步反复循环因为它觉得提取的结果不够好就一直重试。这就是自主性带来的可靠性问题。4.2 Agent 架构的四种常见模式目前主流的 Agent 架构大概有四种我按复杂度从低到高排。第一种是 ReAct 模式也就是推理加行动交替。Agent 先想一步做一个动作看结果再想下一步。这种模式简单直接适合步骤不多的任务。缺点是每一步都要调用 LLM延迟高、成本高。第二种是 Plan-and-Execute 模式先让 LLM 制定完整计划再逐步执行。好处是计划阶段可以全局优化执行阶段可以并行。缺点是计划一旦定错后面全错而且执行中遇到意外不好调整。第三种是 Multi-Agent 模式多个 Agent 各司其职互相协作。比如一个负责检索一个负责分析一个负责写报告。这种模式适合复杂任务但协调成本高容易出现 Agent 之间互相等待或者重复劳动。第四种是带记忆的 Agent在以上基础上加了短期记忆和长期记忆。短期记忆存当前任务的上下文长期记忆存跨任务的经验。这种模式最接近真正的助手但记忆管理本身就是一个大工程。4.3 Agent 怎么扛并发一个被低估的工程问题ai agent 怎么扛并发这个问题问得非常实在。Agent 和普通 API 不一样它的单次请求可能包含多次 LLM 调用、多次工具调用耗时可能是普通请求的十倍甚至几十倍。如果直接同步处理并发能力会非常差。我的做法是全链路异步化加任务队列。用户请求进来先入队返回一个任务 ID然后后台 worker 异步处理。处理过程中每一步的状态都写进数据库或者 Redis前端通过轮询或者 SSE 获取进度。这样即使用户量很大也不会把服务打挂。另一个关键是工具调用的超时和重试策略。Agent 调用的外部工具可能很慢或者不稳定如果不设超时一个卡住的工具调用会拖垮整个 Agent。我的经验是每个工具调用设 10 到 30 秒超时失败后最多重试两次重试还失败就降级处理或者告知用户。还有一个容易被忽略的点是LLM 调用的并发限制。大部分 LLM 服务商都有速率限制如果你的 Agent 并发很高很容易触发限流。解决办法是加一个令牌桶或者漏桶限流器把 LLM 调用控制在服务商允许的范围内。4.4 Agent 安全AgentPoison 这类攻击值得警惕热搜里出现了agentpoison: red-teaming llm agents via poisoning memory or knowledge ba这是一个很值得关注的方向。简单说就是攻击者通过污染 Agent 的记忆或者知识库让 Agent 在后续任务中做出错误决策。这类攻击的可怕之处在于它是持久的。普通 prompt 注入攻击只影响当前对话但记忆污染会影响之后所有使用这段记忆的任务。我做过一个实验在一个带长期记忆的 Agent 里注入一条错误信息结果它在接下来十几轮对话里都基于这条错误信息做判断。防御思路有几个。一是记忆写入要审核不是所有信息都能直接进长期记忆重要的记忆要经过验证。二是记忆读取要标注来源让 Agent 知道这条记忆是从哪来的、可信度多高。三是定期清理和审计把过时或者可疑的记忆清掉。这些措施会增加系统复杂度但对于涉及敏感操作的 Agent是必须的。5. MCP 协议工具调用的标准化之路5.1 MCP 是什么为什么需要它mcp是什么这个问题我用一句话回答MCP 是一个让 LLM 应用标准化调用外部工具和数据的协议。在 MCP 出现之前每个 LLM 应用要接一个新工具都得自己写一套对接代码。工具 A 用 REST API工具 B 用 WebSocket工具 C 用本地命令行每个都要单独适配。MCP 的目标就是把这些统一起来让工具提供方按 MCP 规范实现一次所有支持 MCP 的 LLM 应用都能直接用。这个思路其实不新鲜类似 USB 接口统一了外设连接。但在 LLM 领域它的价值特别大因为 LLM 应用需要接入的工具种类太多了——数据库、文件系统、浏览器、代码执行环境、各种 SaaS 服务。没有标准协议集成成本会随着工具数量线性增长。5.2 MCP 的核心概念Server、Client、Tool、ResourceMCP 的架构不复杂核心就几个概念。MCP Server是工具提供方它暴露一组能力。MCP Client是 LLM 应用它连接 Server 并使用这些能力。Tool是可执行的操作比如查询数据库发送邮件。Resource是可读取的数据比如某个文件的内容某个表的结构。我实际用下来MCP 最实用的地方是它把工具的描述和调用分开了。Server 会告诉 Client 我有哪些工具、每个工具需要什么参数Client 把这些信息喂给 LLMLLM 决定调用哪个工具、传什么参数。这样 LLM 不需要预先知道所有工具的细节扩展性很好。5.3 从零搭一个 MCP Server 的实操步骤下面是一个最小 MCP Server 的实现思路用 Python 举例。from mcp.server import Server from mcp.types import Tool, TextContent app Server(demo-server) app.list_tools() async def list_tools(): return [ Tool( namequery_database, description查询用户数据库输入 SQL 语句返回结果, inputSchema{ type: object, properties: { sql: {type: string, description: 要执行的 SQL} }, required: [sql] } ) ] app.call_tool() async def call_tool(name: str, arguments: dict): if name query_database: result execute_sql(arguments[sql]) return [TextContent(typetext, textstr(result))] if __name__ __main__: app.run()这个 Server 暴露了一个query_database工具。任何支持 MCP 的 Client 连上来都能看到这个工具并调用它。实际生产中你要加的东西包括权限校验、SQL 注入防护、结果大小限制、调用日志。特别是权限校验MCP Server 不应该无条件执行任何 SQL必须限制在允许的范围内。5.4 MCP 的常见坑和注意事项我用 MCP 踩过的坑不少挑几个典型的说。第一个坑是工具描述写得太随意。LLM 是根据工具描述来决定调不调用的如果描述写得含糊LLM 要么不调用要么乱调用。我的经验是工具描述要写清楚什么时候用什么时候不用参数格式是什么最好给一两个例子。第二个坑是错误处理不完善。工具调用失败时如果 Server 直接抛异常Client 那边可能拿到一个很难理解的错误。好的做法是返回结构化的错误信息告诉 LLM 这个操作失败了原因是 X你可以尝试 Y。第三个坑是忽略了流式输出。有些工具调用耗时很长如果等全部完成再返回用户体验很差。MCP 支持流式返回对于长任务应该边执行边返回进度。注意MCP Server 的权限边界一定要划清楚。我见过有人把数据库的 root 权限直接暴露给 MCP Server这是非常危险的。最小权限原则在这里同样适用。6. GraphRAG 与知识结构化RAG 的进阶方向6.1 GraphRAG 解决的是什么问题传统 RAG 基于向量相似度检索擅长找到和问题语义相近的文本片段。但它有个天然短板处理不了需要关系推理的问题。比如和 A 公司有合作关系的公司里哪些也投资了 B 领域这种问题需要遍历关系网络向量检索无能为力。GraphRAG 的思路是先把知识组织成图结构——实体是节点关系是边。检索时不仅做向量匹配还在图上做遍历和推理。这样就能回答那些需要多跳推理的问题。微软的 GraphRAG 实现是这方面的代表它用 LLM 从文档中抽取实体和关系构建知识图谱然后用图算法做社区发现和摘要。6.2 KG 知识库、RAG 知识库、结构化知识库的区别热搜里有个问题问得很专业kg知识库、rag知识库和结构知识库区分以及应用场景。我用自己的理解解释一下。RAG 知识库存的是文本片段的向量检索靠语义相似度。适合非结构化文档比如产品手册、客服对话、技术博客。优点是搭建简单缺点是处理不了复杂关系。KG 知识库知识图谱存的是实体和关系检索靠图查询。适合关系密集的场景比如企业股权结构、供应链网络、医疗诊断。优点是关系推理强缺点是构建成本高需要实体抽取和关系抽取。结构化知识库存的是表格数据检索靠 SQL 查询。适合数值型、统计型数据比如销售报表、库存数据。优点是精确缺点是不灵活只能回答预设好的查询。实际项目中这三者往往是组合使用的。我的一个项目就是结构化知识库处理数值查询RAG 知识库处理文档问答KG 知识库处理关系推理然后用一个路由层根据问题类型分发给不同的知识库。6.3 Ontology RAG给 RAG 加上本体约束ontology rag是 GraphRAG 的一个变体。Ontology 是本体也就是对某个领域的概念和关系的正式定义。Ontology RAG 的做法是先定义好领域的本体然后按本体来抽取和组织知识。这样做的好处是知识结构更规范推理更可靠。比如在医疗领域你可以定义疾病症状药物禁忌这些概念以及它们之间的关系。抽取知识时按这个框架来检索和推理时也按这个框架来结果会比自由抽取的图谱更准确。代价是前期投入大。定义本体需要领域专家参与而且本体一旦定下来后续修改成本高。所以 Ontology RAG 适合领域明确、知识结构相对稳定的场景比如法律、医疗、金融。对于快速变化的领域可能不太划算。6.4 GraphRAG 的落地成本与适用判断GraphRAG 听起来很美但落地成本不低。构建知识图谱需要 LLM 做实体和关系抽取这个过程的 token 消耗可能是普通 RAG 的几十倍。而且图谱构建完之后维护也是持续成本——新文档进来要更新图谱实体消歧、关系冲突处理都是麻烦事。我的判断标准是如果你的问题里超过 30% 需要多跳关系推理才值得上 GraphRAG。如果大部分问题还是简单的是什么怎么做那传统 RAG 加个重排序就够了。不要为了技术先进性而上 GraphRAG要看实际需求。7. 常见问题与排查技巧实录7.1 LLM 调用报错排查速查表报错信息可能原因排查方向解决方案provider rejected the request schema请求格式不符合服务商要求检查 messages 结构、参数类型对照官方文档逐字段核对rate limit exceeded触发速率限制查看调用频率加限流器或申请提额context length exceeded输入超过模型上下文窗口统计 token 数截断、摘要、或换长上下文模型invalid api key密钥错误或过期检查环境变量重新生成密钥timeout网络或服务端慢检查网络、服务状态加重试、设超时这张表是我自己整理的基本覆盖了日常开发中 80% 的报错。特别是第一条 provider rejected the request schema很多时候是因为参数类型不对比如该传数组的传了字符串该传整数的传了浮点数。这种错误信息通常不明确需要仔细核对。7.2 RAG 答非所问的排查思路RAG 答非所问是最常见的问题。我的排查顺序是先看检索结果再看生成结果。如果检索出来的文档就不相关那问题在检索环节检查分块、嵌入模型、查询改写。如果检索结果相关但生成答案跑偏那问题在 prompt 或者 LLM检查 prompt 有没有明确要求只基于检索内容回答。还有一个隐蔽的原因是检索结果太多。有些人为了保险top-k 设成 20 甚至 50结果 LLM 被大量无关信息干扰反而答不好。我的经验是 top-k 设 3 到 5配合重排序效果通常比大 top-k 好。7.3 Agent 死循环的三种破解方法Agent 死循环是另一个高频问题。破解方法有三个。第一是设最大步数比如最多执行 20 步超过就强制停止并返回当前结果。第二是加循环检测如果连续几步的动作和结果高度相似就判定为循环强制跳出。第三是引入外部判断让另一个 LLM 或者规则引擎判断当前状态是否正常异常就干预。我自己的项目里三个方法都用上了。最大步数是最简单的兜底循环检测能处理大部分情况外部判断用于关键任务。三层防护下来死循环基本不会发生。7.4 一些不那么显然的实操心得最后分享几个我在实际项目里总结的、文档里不太会写的心得。关于 prompt 工程不要追求一次写完美的 prompt要迭代。我的做法是建一个 prompt 版本库每次改动都记录配合评估集看效果。这样能清楚知道哪个改动是有效的。关于模型选择不要迷信最大的模型。很多任务用小模型加好的 prompt效果和大模型差不多但成本和延迟低很多。我的策略是先用大模型跑通流程再逐步替换成小模型看效果能保持到什么程度。关于日志Agent 和 RAG 系统的日志要记全。每次 LLM 调用的输入输出、每次工具调用的参数和结果、每次检索的召回内容都要记下来。出问题的时候这些日志是唯一的排查依据。我吃过亏早期没记全日志出了问题只能靠猜。关于测试除了正常的测试用例一定要构造边界用例。空输入、超长输入、特殊字符、并发冲突这些才是真正会暴露问题的地方。关于成本LLM 应用的成本很容易失控。我的做法是给每个环节设成本上限超过就告警。特别是 Agent一次任务可能调用几十次 LLM不控制的话账单会很吓人。这套东西我摸索了挺久从最开始只会调 API到后来能搭完整的 Agent 系统中间踩的坑比想象中多。但每次踩坑之后对这个体系的理解都会深一层。Agent 和 LLM 这个方向变化快但底层的工程逻辑其实很稳定——把数据管好、把流程控好、把异常处理好大部分问题都能解决。