1. 从一份日报标题说起Agent 与 LLM 技术生态的当下切面拿到“Agent / LLM 技术精选日报”这个标题的时候我第一反应不是“又一份资讯汇总”而是它背后折射出的一个现实Agent 和 LLM 这条线上信息密度已经高到单靠零散刷帖根本追不上了。热搜词里同时出现了 Agent、LLM、RAG、MCP、GraphRAG 这几个词本身就说明了一件事——这个领域已经从“单点模型能力”进入了“系统工程能力”的阶段。模型只是发动机真正让车跑起来的是围绕它搭建的整套传动、散热和控制系统。这份日报类内容的核心价值不在于告诉你“今天又出了个新模型”而在于帮你把散落在各处的技术碎片串成一条可理解的脉络。它适合谁看我的判断是三类人第一类是正在做 Agent 应用落地的工程师需要快速判断哪些新工具值得接入第二类是做 RAG 知识库的产品和技术负责人需要知道检索增强这条线又冒出了什么新玩法第三类是刚入门、被 MCP、GraphRAG 这些缩写砸得有点懵的开发者需要一份能看懂的技术地图。我自己在过去一年里陆续做过几个 Agent 相关的项目从最简单的工具调用到带记忆的多轮任务编排都踩过。最大的体会是这个领域最贵的成本不是算力而是“选型试错”的时间。一份好的技术日报本质上是在帮你压缩试错成本。下面我就围绕这份日报涉及的核心技术点把 Agent、LLM、RAG、MCP、GraphRAG 这几条线拆开讲透顺带把热搜词里那些具体问题——比如 RAG 知识库能不能存图片、MCP 到底是什么、GraphRAG 和普通 RAG 差在哪——都落到实操层面说清楚。2. 核心概念拆解Agent、LLM、RAG、MCP、GraphRAG 到底是什么关系2.1 用一条流水线理解这五个词的分工很多人一开始会被这几个缩写绕晕其实它们不是并列关系而是有层次的。我习惯用一条“智能流水线”来类比LLM是流水线上的“大脑”负责理解和生成语言。它本身不会主动做事你问它答仅此而已。Agent是给这个大脑装上了“手脚和记忆”。它能自己决定调用什么工具、分几步完成任务、失败了怎么重试。热搜里“agent是什么”“agent架构”“agent框架”这些词问的都是这层。RAG是给大脑配了一个“外部资料库”。模型训练时没见过的私有数据通过检索的方式临时喂给它解决“幻觉”和“知识过期”问题。MCP是给大脑和外部工具之间定了一套“标准插头”。以前每接一个工具就要写一套适配代码MCP 想做的就是统一接口。GraphRAG是 RAG 的进阶版把“资料库”从一堆散文档升级成一张有关系网的知识图谱解决普通 RAG “只见树木不见森林”的问题。这么一摆关系就清楚了LLM 是底座Agent 是应用形态RAG 和 GraphRAG 是知识供给方式MCP 是工具连接协议。一份技术日报之所以要把它们放在一起是因为真实项目里这几样东西往往是同时出现的。2.2 为什么现在必须关注 MCP 和 GraphRAG热搜词里 MCP 出现的频率非常高甚至出现了“unreal 5.8 mcp”“altium designer ai接口 mcp”“ida mcp下载”“x32dbg 的mcp插件”这种非常具体的组合。这说明 MCP 已经不只是聊天机器人的事了它正在往专业软件领域渗透。游戏引擎、电路设计软件、逆向调试工具都在接 MCP背后的逻辑是这些专业工具本身功能强大但操作复杂如果能让 Agent 通过 MCP 去调用它们就相当于给这些工具装了一个“自然语言遥控器”。GraphRAG 则是另一个方向的信号。普通 RAG 用久了都会遇到一个瓶颈当你问一个需要“跨多个文档综合推理”的问题时向量检索只能召回相似片段拼不出完整答案。比如问“A 项目和 B 项目之间有哪些人员重叠”普通 RAG 很难答好因为它不理解实体之间的关系。GraphRAG 通过预先构建实体关系图把这类问题变成图上的路径查询效果提升明显。热搜里“rag瓶颈”“kg知识库、rag知识库和结构知识库区分”这些词问的正是这个痛点。3. RAG 知识库实操从能存什么到怎么存好3.1 RAG 知识库到底能不能存图片这是热搜里一个非常具体的问题“rag知识库能存储图片嘛”。答案是能但要看你怎么定义“存”和“用”。这里必须把三种情况分清楚否则很容易踩坑。第一种是只存图片文件本身。你把图片当普通文件塞进知识库检索时只能靠文件名或人工打的标签。这种方式基本等于网盘RAG 的价值没体现出来。第二种是图片加文字描述一起存。用多模态模型给每张图片生成一段文字描述把描述文本做向量化图片原文件作为附件关联。检索时命中描述文本再把图片返回给用户。这是目前最实用的做法成本可控效果也够用。第三种是图片直接向量化。用 CLIP 这类多模态嵌入模型把图片和文本映射到同一个向量空间实现“以文搜图”和“以图搜图”。这种方式效果最好但对存储和算力要求高而且中文场景下的多模态嵌入模型选择还比较有限。我自己的经验是绝大多数业务场景用第二种就够了。给图片配描述这一步可以用多模态 LLM 批量生成提示词里明确要求“描述图片中的主体、场景、关键文字和可能的用途”生成质量比想象中好。唯一要注意的是描述文本要控制长度太长会稀释向量语义一般 100 到 200 字比较合适。3.2 普通 RAG 的三个典型瓶颈热搜里“rag瓶颈”这个词很值得展开。我踩过的坑主要集中在三个地方瓶颈一切分粒度两难。切得太碎单块信息不完整检索出来答非所问切得太粗一块里混了多个主题向量被平均掉检索精度下降。我的做法是先用语义切分再对超长块做二次拆分同时给每块加上“所属章节标题”作为上下文前缀这样即使块被切碎语义也不会丢太多。瓶颈二检索召回不准。纯向量检索对“关键词精确匹配”不友好比如查一个产品型号向量可能召回一堆语义相近但型号不同的内容。解决办法是混合检索向量检索加 BM25 关键词检索两路结果用 RRF 融合排序。实测下来混合检索比纯向量在专业领域文档上的召回准确率能提升不少。瓶颈三多跳问题答不了。这就是 GraphRAG 要解决的问题。普通 RAG 是“一次检索一次生成”遇到需要串联多个信息点的问题就歇菜。GraphRAG 通过实体关系图支持“先找到实体再沿关系扩展最后综合生成”的多跳流程。3.3 一个可复现的 RAG 知识库搭建流程下面这套流程是我在多个项目里验证过的适合中小规模知识库几千到几万文档。第一步文档预处理。把 PDF、Word、Markdown 统一转成纯文本保留标题层级信息。这一步用现成的解析库就行关键是别丢结构。第二步语义切分。按标题层级切一级标题下的内容如果超过 800 字再按段落切。每块前面拼上“文档标题 一级标题 二级标题”作为上下文。第三步向量化入库。嵌入模型选中文效果好的维度不用追求最高768 或 1024 维通常够用。入库时同时存原文、向量和元数据来源、标题路径、时间。第四步混合检索。查询时同时跑向量检索和关键词检索各取前 20 条用 RRF 融合后取前 5 条。第五步重排序。用一个轻量重排模型对前 5 条重新打分把最相关的放前面。这一步对最终答案质量影响很大别省。第六步生成。把重排后的内容拼进提示词明确要求“只根据给定资料回答资料中没有的信息不要编造”。提示重排序模型和嵌入模型最好用同一家或同一系列的语义空间更一致效果更稳。4. MCP 协议深入它解决了什么问题怎么用4.1 MCP 是什么为什么突然火了MCP 全称是 Model Context Protocol翻译过来叫“模型上下文协议”。热搜里“mcp是什么”“mcp协议”问的就是它。用一句话说它是一套让 LLM 应用和外部工具、数据源之间标准化通信的协议。在 MCP 出现之前每接一个工具都要写适配代码。你想让 Agent 读数据库写一套想让它调某个 API再写一套换个模型框架这些适配可能还要重写。MCP 的思路是把“工具提供方”和“工具使用方”解耦工具方按 MCP 标准暴露自己的能力使用方按 MCP 标准去调用中间不用关心对方是谁。这就像以前每个电器都有自己的充电口现在统一成 Type-C。热搜里“unreal 5.8 mcp”“altium designer ai接口 mcp”“ida mcp下载”这些词说的就是这些专业软件开始提供 MCP 接口让 Agent 能直接操作它们。4.2 MCP 的核心概念Server、Client 和 ToolMCP 的架构不复杂三个角色MCP Server工具提供方。它把自身能力包装成一个个“Tool”每个 Tool 有名字、描述和参数定义。MCP Client工具使用方通常就是你的 Agent 框架。它连接 Server获取 Tool 列表按需调用。Tool具体的能力单元。比如“查询数据库”“发送邮件”“读取文件”都是一个 Tool。调用流程是这样的Client 启动时连接 Server拉取 Tool 列表LLM 根据用户需求决定调用哪个 Tool生成参数Client 把调用请求发给 ServerServer 执行后返回结果结果再喂回 LLM 继续推理。这个流程的关键在于Tool 的描述质量直接决定 LLM 会不会正确调用。描述要写清楚“这个工具做什么、什么时候用、参数什么含义”写得含糊LLM 就会乱调或漏调。4.3 自己写一个 MCP Server 的实操要点假设你要把一个内部查询接口包装成 MCP Server步骤大致如下首先定义 Tool。给每个能力写清楚名称、描述和参数 schema。参数 schema 用 JSON Schema 描述类型、是否必填、取值范围都写明白。然后实现执行逻辑。收到调用请求后解析参数执行实际查询把结果整理成结构化文本返回。返回内容要简洁别把整个数据库 dump 回去LLM 的上下文窗口很贵。接着处理错误。工具执行失败时返回明确的错误信息而不是抛异常让 LLM 知道“这次调用失败了原因是 X”它才能决定重试还是换方案。最后做连接管理。MCP 支持多种传输方式本地工具用标准输入输出远程工具用 HTTP。选哪种取决于你的部署形态。注意MCP Server 的 Tool 数量别一次暴露太多。我试过暴露 30 多个 Tool结果 LLM 选择困难调用准确率明显下降。按场景分组一次只给相关的 5 到 10 个效果更好。4.4 MCP 与 Agent 框架的配合热搜里“agent框架”“agent架构”“harness和agent区别”这些词其实都在问同一个问题Agent 框架和 MCP 怎么配合。我的理解是Agent 框架负责“决策和编排”MCP 负责“能力接入”。框架决定下一步做什么MCP 提供做这件事的工具。“harness 和 agent 区别”这个问题也值得说一句。Harness 通常指“测试和评估 Agent 的脚手架”它不参与实际任务执行而是用来跑评测、对比不同 Agent 表现。Agent 是干活的Harness 是考核的两者别混。5. GraphRAG 与知识图谱什么时候该上什么时候别硬上5.1 GraphRAG 和普通 RAG 的本质区别普通 RAG 的检索单元是“文本块”GraphRAG 的检索单元是“实体和关系”。这个区别带来两个直接后果第一GraphRAG 能回答“关系型问题”。比如“哪些人和哪些项目有关联”“A 事件导致了哪些后续事件”这类问题在图上就是一次路径查询在普通 RAG 里却很难拼出答案。第二GraphRAG 能做“全局摘要”。普通 RAG 只能召回局部片段问“这批文档整体讲了什么主题”它答不好。GraphRAG 可以在图层面做社区发现把相关实体聚成簇再对每个簇生成摘要最后汇总。但 GraphRAG 的代价也很明显构建图谱需要额外的实体抽取和关系抽取步骤成本比普通 RAG 高不少而且抽取质量直接决定最终效果。热搜里“ontology rag”这个词说的就是用本体Ontology来约束实体和关系类型提升抽取质量。5.2 知识图谱、RAG 知识库和结构化知识库的区别热搜里“kg知识库、rag知识库和结构知识库区分以及应用场景”这个问题很典型我用一张表说清楚类型存储形态检索方式适合场景主要短板结构化知识库表格、关系数据库SQL 精确查询订单、库存、报表无法处理非结构化文本RAG 知识库文本块加向量语义相似检索文档问答、客服多跳推理弱知识图谱实体关系三元组图遍历、路径查询关系推理、风控构建成本高实际项目里这三者经常混用。比如一个企业知识助手底层用结构化库查数据中间用 RAG 查文档上层用图谱做关系推理Agent 负责根据问题类型选择走哪条路。5.3 GraphRAG 的落地步骤与成本控制如果你决定上 GraphRAG我建议按这个顺序来先做小范围验证。选一个文档子集跑一遍实体和关系抽取人工检查抽取质量。如果抽取准确率不到 80%先别急着全量构建调提示词或换模型。再定本体。明确你要抽哪些实体类型、哪些关系类型。本体定得越清晰抽取越稳定。别一上来就追求大而全先覆盖核心的几类。然后构建图谱。用 LLM 批量抽取抽取结果存进图数据库。这一步可以并行但要注意去重和实体对齐同一个实体不同叫法要合并。最后接检索。查询时先做实体识别定位到图中节点再沿关系扩展把子图转成文本喂给 LLM 生成答案。成本控制的关键在于别对所有文档都建图。只对关系密集、查询频繁的那部分文档建图其余走普通 RAG。我见过有团队一上来就全量建图结果成本爆炸效果还没普通 RAG 好。6. Agent 工程化并发、容错与安全6.1 Agent 怎么扛并发热搜里“ai agent 怎么扛并发”是个非常实际的问题。Agent 和普通 API 不一样它一次任务可能包含多轮 LLM 调用和多次工具调用单次请求耗时可能是普通接口的几十倍。扛并发的核心思路是“异步加队列加限流”。具体做法把 Agent 任务提交到消息队列由 worker 异步消费。worker 数量根据 LLM 接口的并发上限来定别超过上游限制。每个任务内部的多步调用用异步方式串起来避免阻塞。对外接口只返回任务 ID客户端轮询或走回调拿结果。限流要分两层一层是 LLM 接口的调用限流防止把上游打挂一层是工具调用的限流防止某个外部服务被压垮。两层都要有退避重试机制。6.2 Agent 的容错设计“识的llm智能体自主容错控制”这个热搜词说的就是 Agent 容错。Agent 出错的地方太多了LLM 输出格式不对、工具调用失败、参数解析错误、陷入死循环。容错设计要覆盖这几类。格式错误用结构化输出约束让 LLM 按 JSON Schema 输出解析失败就重试并附上错误信息。工具失败要区分“可重试”和“不可重试”网络超时可重试参数错误重试也没用要让 LLM 换方案。死循环要设最大步数超过就强制终止并返回当前进展。我自己的经验是给 Agent 加一个“反思”步骤很值。每完成几步让它自己检查一下“当前进展是否符合目标、有没有走偏”能显著减少跑飞的情况。6.3 Agent 安全从 AgentPoison 说起热搜里“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”和“agent安全”指向一个严肃问题Agent 的记忆和知识库是可以被投毒的。攻击者在知识库里埋入恶意内容Agent 检索到之后可能被诱导执行危险操作。防御思路有几条知识库写入要做来源审核和内容过滤Agent 执行敏感操作前要二次确认记忆内容要定期审计发现异常及时清理。这些措施不能保证百分百安全但能大幅提高攻击成本。7. 常见问题速查与避坑清单7.1 高频问题速查表问题常见原因解决方向RAG 答非所问切分粒度不当、召回不准语义切分加混合检索加重排Agent 调用工具失败Tool 描述不清、参数 schema 不严完善描述、加参数校验LLM 输出格式错乱缺少结构化约束用 JSON Schema 约束输出GraphRAG 成本高全量建图、抽取质量差小范围验证、定本体、按需建图Agent 并发上不去同步阻塞、无限流异步队列加两层限流知识库被投毒写入无审核来源审核加内容过滤加二次确认7.2 几条踩坑换来的经验第一条别迷信框架。Agent 框架更新极快今天的最佳实践明天可能就过时。核心是把“决策、工具、记忆、容错”这几个模块的职责想清楚框架只是实现手段换框架时思路不变。第二条评测要趁早。很多人做完 Agent 才想起来评测结果发现效果不行又不知道问题出在哪。正确做法是搭好骨架就先跑一批测试用例把“LLM as judge”用起来边做边评。第三条上下文要省着用。LLM 的上下文窗口再大也是有限的工具返回结果、历史对话、检索内容都在抢空间。该截断的截断该摘要的摘要别什么都往里塞。第四条日志要打全。Agent 出问题时你需要知道每一步的输入输出是什么。把 LLM 调用、工具调用、决策结果都记下来排查问题时能省大量时间。7.3 关于“LLM request failed: provider rejected the request schema or tool payload”的排查这个报错在热搜里出现说明不少人遇到过。它通常是工具调用的参数 schema 和实际传参不匹配导致的。排查顺序先看报错里提到的字段名对照 Tool 定义的 schema 检查类型和必填项再看是不是 LLM 生成了多余字段有些模型会自作主张加字段schema 里加additionalProperties: false能拦住最后看嵌套结构深层嵌套的参数最容易出错能扁平化就扁平化。8. 工具链与生态观察8.1 本地模型与开发工具热搜里“llm studio”“llm wiki”“llm框架”这些词反映的是本地开发和知识管理的需求。LM Studio 这类工具让本地跑模型变得简单适合做原型验证和隐私敏感场景。但要注意本地小模型在工具调用和结构化输出上的稳定性通常不如云端大模型选型时要按场景权衡。8.2 从聊天记录精调模型这件事“使用聊天记录模型精调llm”这个热搜词值得单独说。用聊天记录做精调数据好处是数据真实、贴近业务坑在于聊天记录噪声大、格式乱、隐私敏感。我的建议是先做严格清洗和脱敏再人工筛选高质量对话最后才拿去精调。直接拿原始聊天记录喂进去效果往往适得其反。8.3 流式输出到文件这类小需求“使用mcp工具流式输出内容到文件 cherrystudio”这个热搜词很具体说明大家在用 MCP 做实际的文件操作。流式输出的价值在于长内容生成时不用等全部完成边生成边写文件用户体验好也避免内存里堆一大坨。实现上就是在 MCP Tool 里用流式接口每收到一段就追加写入同时处理好文件锁和异常中断。9. 我个人的一点体会做 Agent 和 LLM 这条线最大的感受是“变化快但底层稳”。变化快的是工具和框架几乎每个月都有新东西底层稳的是那几个核心问题——怎么让模型理解任务、怎么给它接上外部能力、怎么保证它不出错。把底层问题想清楚上层工具换得再快也不慌。另外就是别被热搜词带着跑。热搜反映的是关注度不一定是你的项目该优先做的事。看到一个新概念先问自己“它解决的是我当前遇到的哪个具体问题”如果答不上来就先放一放。真正值得投入的永远是那些能直接改善你项目效果的技术点。 
长河君 · 2026/10/28 8:35:02 · 阅读 1.2k Agent与LLM技术生态拆解：RAG、MCP、GraphRAG核心原理与工程实践
1. 从一份日报标题说起Agent 与 LLM 技术生态的当下切面拿到“Agent / LLM 技术精选日报”这个标题的时候我第一反应不是“又一份资讯汇总”而是它背后折射出的一个现实Agent 和 LLM 这条线上信息密度已经高到单靠零散刷帖根本追不上了。热搜词里同时出现了 Agent、LLM、RAG、MCP、GraphRAG 这几个词本身就说明了一件事——这个领域已经从“单点模型能力”进入了“系统工程能力”的阶段。模型只是发动机真正让车跑起来的是围绕它搭建的整套传动、散热和控制系统。这份日报类内容的核心价值不在于告诉你“今天又出了个新模型”而在于帮你把散落在各处的技术碎片串成一条可理解的脉络。它适合谁看我的判断是三类人第一类是正在做 Agent 应用落地的工程师需要快速判断哪些新工具值得接入第二类是做 RAG 知识库的产品和技术负责人需要知道检索增强这条线又冒出了什么新玩法第三类是刚入门、被 MCP、GraphRAG 这些缩写砸得有点懵的开发者需要一份能看懂的技术地图。我自己在过去一年里陆续做过几个 Agent 相关的项目从最简单的工具调用到带记忆的多轮任务编排都踩过。最大的体会是这个领域最贵的成本不是算力而是“选型试错”的时间。一份好的技术日报本质上是在帮你压缩试错成本。下面我就围绕这份日报涉及的核心技术点把 Agent、LLM、RAG、MCP、GraphRAG 这几条线拆开讲透顺带把热搜词里那些具体问题——比如 RAG 知识库能不能存图片、MCP 到底是什么、GraphRAG 和普通 RAG 差在哪——都落到实操层面说清楚。2. 核心概念拆解Agent、LLM、RAG、MCP、GraphRAG 到底是什么关系2.1 用一条流水线理解这五个词的分工很多人一开始会被这几个缩写绕晕其实它们不是并列关系而是有层次的。我习惯用一条“智能流水线”来类比LLM是流水线上的“大脑”负责理解和生成语言。它本身不会主动做事你问它答仅此而已。Agent是给这个大脑装上了“手脚和记忆”。它能自己决定调用什么工具、分几步完成任务、失败了怎么重试。热搜里“agent是什么”“agent架构”“agent框架”这些词问的都是这层。RAG是给大脑配了一个“外部资料库”。模型训练时没见过的私有数据通过检索的方式临时喂给它解决“幻觉”和“知识过期”问题。MCP是给大脑和外部工具之间定了一套“标准插头”。以前每接一个工具就要写一套适配代码MCP 想做的就是统一接口。GraphRAG是 RAG 的进阶版把“资料库”从一堆散文档升级成一张有关系网的知识图谱解决普通 RAG “只见树木不见森林”的问题。这么一摆关系就清楚了LLM 是底座Agent 是应用形态RAG 和 GraphRAG 是知识供给方式MCP 是工具连接协议。一份技术日报之所以要把它们放在一起是因为真实项目里这几样东西往往是同时出现的。2.2 为什么现在必须关注 MCP 和 GraphRAG热搜词里 MCP 出现的频率非常高甚至出现了“unreal 5.8 mcp”“altium designer ai接口 mcp”“ida mcp下载”“x32dbg 的mcp插件”这种非常具体的组合。这说明 MCP 已经不只是聊天机器人的事了它正在往专业软件领域渗透。游戏引擎、电路设计软件、逆向调试工具都在接 MCP背后的逻辑是这些专业工具本身功能强大但操作复杂如果能让 Agent 通过 MCP 去调用它们就相当于给这些工具装了一个“自然语言遥控器”。GraphRAG 则是另一个方向的信号。普通 RAG 用久了都会遇到一个瓶颈当你问一个需要“跨多个文档综合推理”的问题时向量检索只能召回相似片段拼不出完整答案。比如问“A 项目和 B 项目之间有哪些人员重叠”普通 RAG 很难答好因为它不理解实体之间的关系。GraphRAG 通过预先构建实体关系图把这类问题变成图上的路径查询效果提升明显。热搜里“rag瓶颈”“kg知识库、rag知识库和结构知识库区分”这些词问的正是这个痛点。3. RAG 知识库实操从能存什么到怎么存好3.1 RAG 知识库到底能不能存图片这是热搜里一个非常具体的问题“rag知识库能存储图片嘛”。答案是能但要看你怎么定义“存”和“用”。这里必须把三种情况分清楚否则很容易踩坑。第一种是只存图片文件本身。你把图片当普通文件塞进知识库检索时只能靠文件名或人工打的标签。这种方式基本等于网盘RAG 的价值没体现出来。第二种是图片加文字描述一起存。用多模态模型给每张图片生成一段文字描述把描述文本做向量化图片原文件作为附件关联。检索时命中描述文本再把图片返回给用户。这是目前最实用的做法成本可控效果也够用。第三种是图片直接向量化。用 CLIP 这类多模态嵌入模型把图片和文本映射到同一个向量空间实现“以文搜图”和“以图搜图”。这种方式效果最好但对存储和算力要求高而且中文场景下的多模态嵌入模型选择还比较有限。我自己的经验是绝大多数业务场景用第二种就够了。给图片配描述这一步可以用多模态 LLM 批量生成提示词里明确要求“描述图片中的主体、场景、关键文字和可能的用途”生成质量比想象中好。唯一要注意的是描述文本要控制长度太长会稀释向量语义一般 100 到 200 字比较合适。3.2 普通 RAG 的三个典型瓶颈热搜里“rag瓶颈”这个词很值得展开。我踩过的坑主要集中在三个地方瓶颈一切分粒度两难。切得太碎单块信息不完整检索出来答非所问切得太粗一块里混了多个主题向量被平均掉检索精度下降。我的做法是先用语义切分再对超长块做二次拆分同时给每块加上“所属章节标题”作为上下文前缀这样即使块被切碎语义也不会丢太多。瓶颈二检索召回不准。纯向量检索对“关键词精确匹配”不友好比如查一个产品型号向量可能召回一堆语义相近但型号不同的内容。解决办法是混合检索向量检索加 BM25 关键词检索两路结果用 RRF 融合排序。实测下来混合检索比纯向量在专业领域文档上的召回准确率能提升不少。瓶颈三多跳问题答不了。这就是 GraphRAG 要解决的问题。普通 RAG 是“一次检索一次生成”遇到需要串联多个信息点的问题就歇菜。GraphRAG 通过实体关系图支持“先找到实体再沿关系扩展最后综合生成”的多跳流程。3.3 一个可复现的 RAG 知识库搭建流程下面这套流程是我在多个项目里验证过的适合中小规模知识库几千到几万文档。第一步文档预处理。把 PDF、Word、Markdown 统一转成纯文本保留标题层级信息。这一步用现成的解析库就行关键是别丢结构。第二步语义切分。按标题层级切一级标题下的内容如果超过 800 字再按段落切。每块前面拼上“文档标题 一级标题 二级标题”作为上下文。第三步向量化入库。嵌入模型选中文效果好的维度不用追求最高768 或 1024 维通常够用。入库时同时存原文、向量和元数据来源、标题路径、时间。第四步混合检索。查询时同时跑向量检索和关键词检索各取前 20 条用 RRF 融合后取前 5 条。第五步重排序。用一个轻量重排模型对前 5 条重新打分把最相关的放前面。这一步对最终答案质量影响很大别省。第六步生成。把重排后的内容拼进提示词明确要求“只根据给定资料回答资料中没有的信息不要编造”。提示重排序模型和嵌入模型最好用同一家或同一系列的语义空间更一致效果更稳。4. MCP 协议深入它解决了什么问题怎么用4.1 MCP 是什么为什么突然火了MCP 全称是 Model Context Protocol翻译过来叫“模型上下文协议”。热搜里“mcp是什么”“mcp协议”问的就是它。用一句话说它是一套让 LLM 应用和外部工具、数据源之间标准化通信的协议。在 MCP 出现之前每接一个工具都要写适配代码。你想让 Agent 读数据库写一套想让它调某个 API再写一套换个模型框架这些适配可能还要重写。MCP 的思路是把“工具提供方”和“工具使用方”解耦工具方按 MCP 标准暴露自己的能力使用方按 MCP 标准去调用中间不用关心对方是谁。这就像以前每个电器都有自己的充电口现在统一成 Type-C。热搜里“unreal 5.8 mcp”“altium designer ai接口 mcp”“ida mcp下载”这些词说的就是这些专业软件开始提供 MCP 接口让 Agent 能直接操作它们。4.2 MCP 的核心概念Server、Client 和 ToolMCP 的架构不复杂三个角色MCP Server工具提供方。它把自身能力包装成一个个“Tool”每个 Tool 有名字、描述和参数定义。MCP Client工具使用方通常就是你的 Agent 框架。它连接 Server获取 Tool 列表按需调用。Tool具体的能力单元。比如“查询数据库”“发送邮件”“读取文件”都是一个 Tool。调用流程是这样的Client 启动时连接 Server拉取 Tool 列表LLM 根据用户需求决定调用哪个 Tool生成参数Client 把调用请求发给 ServerServer 执行后返回结果结果再喂回 LLM 继续推理。这个流程的关键在于Tool 的描述质量直接决定 LLM 会不会正确调用。描述要写清楚“这个工具做什么、什么时候用、参数什么含义”写得含糊LLM 就会乱调或漏调。4.3 自己写一个 MCP Server 的实操要点假设你要把一个内部查询接口包装成 MCP Server步骤大致如下首先定义 Tool。给每个能力写清楚名称、描述和参数 schema。参数 schema 用 JSON Schema 描述类型、是否必填、取值范围都写明白。然后实现执行逻辑。收到调用请求后解析参数执行实际查询把结果整理成结构化文本返回。返回内容要简洁别把整个数据库 dump 回去LLM 的上下文窗口很贵。接着处理错误。工具执行失败时返回明确的错误信息而不是抛异常让 LLM 知道“这次调用失败了原因是 X”它才能决定重试还是换方案。最后做连接管理。MCP 支持多种传输方式本地工具用标准输入输出远程工具用 HTTP。选哪种取决于你的部署形态。注意MCP Server 的 Tool 数量别一次暴露太多。我试过暴露 30 多个 Tool结果 LLM 选择困难调用准确率明显下降。按场景分组一次只给相关的 5 到 10 个效果更好。4.4 MCP 与 Agent 框架的配合热搜里“agent框架”“agent架构”“harness和agent区别”这些词其实都在问同一个问题Agent 框架和 MCP 怎么配合。我的理解是Agent 框架负责“决策和编排”MCP 负责“能力接入”。框架决定下一步做什么MCP 提供做这件事的工具。“harness 和 agent 区别”这个问题也值得说一句。Harness 通常指“测试和评估 Agent 的脚手架”它不参与实际任务执行而是用来跑评测、对比不同 Agent 表现。Agent 是干活的Harness 是考核的两者别混。5. GraphRAG 与知识图谱什么时候该上什么时候别硬上5.1 GraphRAG 和普通 RAG 的本质区别普通 RAG 的检索单元是“文本块”GraphRAG 的检索单元是“实体和关系”。这个区别带来两个直接后果第一GraphRAG 能回答“关系型问题”。比如“哪些人和哪些项目有关联”“A 事件导致了哪些后续事件”这类问题在图上就是一次路径查询在普通 RAG 里却很难拼出答案。第二GraphRAG 能做“全局摘要”。普通 RAG 只能召回局部片段问“这批文档整体讲了什么主题”它答不好。GraphRAG 可以在图层面做社区发现把相关实体聚成簇再对每个簇生成摘要最后汇总。但 GraphRAG 的代价也很明显构建图谱需要额外的实体抽取和关系抽取步骤成本比普通 RAG 高不少而且抽取质量直接决定最终效果。热搜里“ontology rag”这个词说的就是用本体Ontology来约束实体和关系类型提升抽取质量。5.2 知识图谱、RAG 知识库和结构化知识库的区别热搜里“kg知识库、rag知识库和结构知识库区分以及应用场景”这个问题很典型我用一张表说清楚类型存储形态检索方式适合场景主要短板结构化知识库表格、关系数据库SQL 精确查询订单、库存、报表无法处理非结构化文本RAG 知识库文本块加向量语义相似检索文档问答、客服多跳推理弱知识图谱实体关系三元组图遍历、路径查询关系推理、风控构建成本高实际项目里这三者经常混用。比如一个企业知识助手底层用结构化库查数据中间用 RAG 查文档上层用图谱做关系推理Agent 负责根据问题类型选择走哪条路。5.3 GraphRAG 的落地步骤与成本控制如果你决定上 GraphRAG我建议按这个顺序来先做小范围验证。选一个文档子集跑一遍实体和关系抽取人工检查抽取质量。如果抽取准确率不到 80%先别急着全量构建调提示词或换模型。再定本体。明确你要抽哪些实体类型、哪些关系类型。本体定得越清晰抽取越稳定。别一上来就追求大而全先覆盖核心的几类。然后构建图谱。用 LLM 批量抽取抽取结果存进图数据库。这一步可以并行但要注意去重和实体对齐同一个实体不同叫法要合并。最后接检索。查询时先做实体识别定位到图中节点再沿关系扩展把子图转成文本喂给 LLM 生成答案。成本控制的关键在于别对所有文档都建图。只对关系密集、查询频繁的那部分文档建图其余走普通 RAG。我见过有团队一上来就全量建图结果成本爆炸效果还没普通 RAG 好。6. Agent 工程化并发、容错与安全6.1 Agent 怎么扛并发热搜里“ai agent 怎么扛并发”是个非常实际的问题。Agent 和普通 API 不一样它一次任务可能包含多轮 LLM 调用和多次工具调用单次请求耗时可能是普通接口的几十倍。扛并发的核心思路是“异步加队列加限流”。具体做法把 Agent 任务提交到消息队列由 worker 异步消费。worker 数量根据 LLM 接口的并发上限来定别超过上游限制。每个任务内部的多步调用用异步方式串起来避免阻塞。对外接口只返回任务 ID客户端轮询或走回调拿结果。限流要分两层一层是 LLM 接口的调用限流防止把上游打挂一层是工具调用的限流防止某个外部服务被压垮。两层都要有退避重试机制。6.2 Agent 的容错设计“识的llm智能体自主容错控制”这个热搜词说的就是 Agent 容错。Agent 出错的地方太多了LLM 输出格式不对、工具调用失败、参数解析错误、陷入死循环。容错设计要覆盖这几类。格式错误用结构化输出约束让 LLM 按 JSON Schema 输出解析失败就重试并附上错误信息。工具失败要区分“可重试”和“不可重试”网络超时可重试参数错误重试也没用要让 LLM 换方案。死循环要设最大步数超过就强制终止并返回当前进展。我自己的经验是给 Agent 加一个“反思”步骤很值。每完成几步让它自己检查一下“当前进展是否符合目标、有没有走偏”能显著减少跑飞的情况。6.3 Agent 安全从 AgentPoison 说起热搜里“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”和“agent安全”指向一个严肃问题Agent 的记忆和知识库是可以被投毒的。攻击者在知识库里埋入恶意内容Agent 检索到之后可能被诱导执行危险操作。防御思路有几条知识库写入要做来源审核和内容过滤Agent 执行敏感操作前要二次确认记忆内容要定期审计发现异常及时清理。这些措施不能保证百分百安全但能大幅提高攻击成本。7. 常见问题速查与避坑清单7.1 高频问题速查表问题常见原因解决方向RAG 答非所问切分粒度不当、召回不准语义切分加混合检索加重排Agent 调用工具失败Tool 描述不清、参数 schema 不严完善描述、加参数校验LLM 输出格式错乱缺少结构化约束用 JSON Schema 约束输出GraphRAG 成本高全量建图、抽取质量差小范围验证、定本体、按需建图Agent 并发上不去同步阻塞、无限流异步队列加两层限流知识库被投毒写入无审核来源审核加内容过滤加二次确认7.2 几条踩坑换来的经验第一条别迷信框架。Agent 框架更新极快今天的最佳实践明天可能就过时。核心是把“决策、工具、记忆、容错”这几个模块的职责想清楚框架只是实现手段换框架时思路不变。第二条评测要趁早。很多人做完 Agent 才想起来评测结果发现效果不行又不知道问题出在哪。正确做法是搭好骨架就先跑一批测试用例把“LLM as judge”用起来边做边评。第三条上下文要省着用。LLM 的上下文窗口再大也是有限的工具返回结果、历史对话、检索内容都在抢空间。该截断的截断该摘要的摘要别什么都往里塞。第四条日志要打全。Agent 出问题时你需要知道每一步的输入输出是什么。把 LLM 调用、工具调用、决策结果都记下来排查问题时能省大量时间。7.3 关于“LLM request failed: provider rejected the request schema or tool payload”的排查这个报错在热搜里出现说明不少人遇到过。它通常是工具调用的参数 schema 和实际传参不匹配导致的。排查顺序先看报错里提到的字段名对照 Tool 定义的 schema 检查类型和必填项再看是不是 LLM 生成了多余字段有些模型会自作主张加字段schema 里加additionalProperties: false能拦住最后看嵌套结构深层嵌套的参数最容易出错能扁平化就扁平化。8. 工具链与生态观察8.1 本地模型与开发工具热搜里“llm studio”“llm wiki”“llm框架”这些词反映的是本地开发和知识管理的需求。LM Studio 这类工具让本地跑模型变得简单适合做原型验证和隐私敏感场景。但要注意本地小模型在工具调用和结构化输出上的稳定性通常不如云端大模型选型时要按场景权衡。8.2 从聊天记录精调模型这件事“使用聊天记录模型精调llm”这个热搜词值得单独说。用聊天记录做精调数据好处是数据真实、贴近业务坑在于聊天记录噪声大、格式乱、隐私敏感。我的建议是先做严格清洗和脱敏再人工筛选高质量对话最后才拿去精调。直接拿原始聊天记录喂进去效果往往适得其反。8.3 流式输出到文件这类小需求“使用mcp工具流式输出内容到文件 cherrystudio”这个热搜词很具体说明大家在用 MCP 做实际的文件操作。流式输出的价值在于长内容生成时不用等全部完成边生成边写文件用户体验好也避免内存里堆一大坨。实现上就是在 MCP Tool 里用流式接口每收到一段就追加写入同时处理好文件锁和异常中断。9. 我个人的一点体会做 Agent 和 LLM 这条线最大的感受是“变化快但底层稳”。变化快的是工具和框架几乎每个月都有新东西底层稳的是那几个核心问题——怎么让模型理解任务、怎么给它接上外部能力、怎么保证它不出错。把底层问题想清楚上层工具换得再快也不慌。另外就是别被热搜词带着跑。热搜反映的是关注度不一定是你的项目该优先做的事。看到一个新概念先问自己“它解决的是我当前遇到的哪个具体问题”如果答不上来就先放一放。真正值得投入的永远是那些能直接改善你项目效果的技术点。