1. 从一份日报说起Agent 与 LLM 生态到底在卷什么如果你最近半年一直在跟 Agent 和 LLM 打交道大概率会有一种信息过载的窒息感。今天刚把 RAG 的召回率调上去明天 GraphRAG 的论文就刷屏了这边 MCP 协议刚接进项目那边又冒出来一个Agent 沙盒更新失败的报错。我自己的收藏夹里躺着几十篇没来得及看的文章标签从agent架构一直排到llm as judge最后发现真正落地的没几个。这篇内容我想换个角度来写。不是再给你堆一堆本周必读论文而是把 2026 年这个时间点上Agent 与 LLM 领域真正在发生结构性变化的东西拆开讲清楚。核心围绕几个关键词展开Agent、LLM、RAG、GraphRAG、MCP。这五个词基本构成了当前智能体应用的技术骨架——LLM 是大脑Agent 是手脚和决策循环RAG 是外挂记忆GraphRAG 是记忆的结构化升级MCP 则是把这些能力标准化接出去的那根通用数据线。适合谁看如果你正在做 Agent 项目、在搭 RAG 知识库、在纠结要不要上 GraphRAG、或者被 MCP 的授权和沙盒问题卡住过那这篇就是写给你的。我会尽量用从业者之间聊天的口吻把每个技术点的为什么讲透再补上我自己踩过的坑和实测有效的做法。不追求面面俱到但求每一段都能让你拿去用。先说一个我观察到的现象很多人把 Agent 理解成会调用工具的 LLM这个理解在 2024 年勉强够用放到现在明显不够了。真正的 Agent 系统里LLM 只是其中一个组件围绕它还有记忆管理、工具编排、权限控制、并发调度、失败重试、可观测性等一大堆工程问题。这也是为什么热词里会出现ai agent 怎么扛并发agent安全harness和agent区别这类问题——大家已经从能不能跑通进入到能不能扛住生产的阶段了。2. LLM 的底层认知token、ontology 与三个点的直觉模型2.1 把 token 理解成三个点key、query、value热词里有一条特别有意思llm的token三个点key我是谁、query我在找什么、value我能提供什么。这个说法其实是在用注意力机制Attention的 QKV 框架给非科班的人一个直觉入口。我试着把它讲得更落地一点。你可以把 LLM 处理一句话想象成一场圆桌会议。每个 token 都是一个参会者它手里拿着三样东西key我是谁我的身份标签比如我是一个动词我是一个专有名词。query我在找什么我这次发言想跟谁产生关联比如我需要找一个主语。value我能提供什么如果别人选中了我我能贡献出去的实际信息。注意力机制干的事就是让每个 token 拿自己的 query 去和所有 token 的 key 做匹配匹配度高的就多听它的 value。这就是为什么同一个词在不同上下文里含义完全不同——因为它的邻居变了加权的结果就变了。理解这个模型的实际价值在哪在于你能预判模型的行为边界。比如你写 prompt 时把关键约束放在很长的上下文中间它的 query 很可能被前后无关 token 稀释掉导致说了等于没说。我实测下来把最重要的指令放在开头和结尾中间放参考资料遵循率会明显高一些。这不是玄学是注意力权重分布的直接结果。2.2 ontology 为什么突然和 LLM 绑在一起llm ontology和ontology rag这两个词最近出现频率很高。ontology本体本来是知识工程里的老概念指的是一套对某个领域概念及其关系的显式规范描述。它和 LLM 结合的逻辑是这样的LLM 擅长模糊理解和生成但不擅长保证事实一致性ontology 擅长定义什么是什么、什么和什么有关系但构建和维护成本极高。两者一结合就出现了用 LLM 辅助抽取本体再用本体约束 LLM 输出的玩法。举个具体场景。你在做一个医疗问答的 RAG 系统如果只靠向量检索用户问二甲双胍能不能和某类药一起吃检索出来的片段可能来自不同年代的指南互相矛盾。但如果你先构建一个轻量 ontology把药物—适应症—禁忌—相互作用这些关系显式定义出来检索时就能沿着关系图走而不是靠语义相似度碰运气。这就是 ontology 给 RAG 带来的确定性。我的经验是不要一上来就搞大而全的本体。先挑你业务里最痛的那 3 到 5 类实体和它们之间的关系手工定义清楚跑通之后再考虑用 LLM 去半自动扩展。全自动构建本体目前还是个坑抽取出来的关系噪声很大清洗成本可能比手工还高。2.3 公开榜单能信几分open llm leaderboard 的正确用法open llm leaderboard 等公开榜单是很多人选型的第一站。我的态度是榜单要看但只能当排除法用不能当选择法用。榜单的价值在于帮你快速排除掉明显不行的模型。比如某个模型在推理类基准上分数低得离谱那你做数学和逻辑任务时基本可以跳过它。但榜单的局限也很明显评测集和你的真实业务分布往往差很远而且很多模型在榜单上刷分靠的是数据污染。我见过一个模型在通用榜单上排名很靠前结果接到实际客服场景里对行业黑话的理解一塌糊涂。更靠谱的做法是从榜单里挑出 3 到 5 个候选然后用你自己业务里的 50 到 100 条真实 query 做小规模对比测试。测试维度至少包括任务完成率、输出格式稳定性、延迟、单位 token 成本。这四个维度里格式稳定性和成本往往比聪明程度更影响你能不能上线。我踩过的坑就是选了一个特别聪明的模型但它输出 JSON 时经常多带一句解释导致下游解析天天报错最后不得不换掉。3. RAG 的真实瓶颈不是检索不到而是检索到了也没用3.1 rag瓶颈到底卡在哪一层rag瓶颈这个词被搜了很多次说明大家普遍遇到了天花板。我把 RAG 的链路拆成四层来看文档解析、切分与索引、检索召回、生成融合。绝大多数人以为瓶颈在检索其实我观察下来瓶颈最常出现在文档解析和切分这两层。文档解析的坑在于PDF 里的表格、双栏排版、页眉页脚、扫描件 OCR 错误这些都会污染后续所有环节。你检索得再准喂给模型的原文本身就是错的那结果必然错。我做过一个项目客户的知识库全是扫描版的产品手册OCR 把0识别成O、把1识别成l导致型号检索几乎全废。后来我们专门加了一层型号纠错规则才把召回率拉回来。切分的坑在于固定长度切分会把一句完整的话拦腰截断。比如该药物禁用于……后面跟的禁忌症被切到了下一个 chunk检索时只召回了前半句模型就会给出完全相反的结论。我的做法是优先按语义边界切段落、标题、列表项实在要按长度切也要设置 10% 到 20% 的重叠区并且把标题层级作为元数据带上检索时一起参与过滤。3.2 rag知识库能存储图片吗多模态检索的现实做法rag知识库能存储图片嘛这个问题问得很实在。答案是能但要分清存和用是两回事。存储层面图片本身当然可以存进对象存储然后在向量库里存它的描述文本或图片 embedding。问题在于用如果你的 LLM 不支持视觉输入那检索出来的图片对它来说就是一堆二进制毫无意义。所以现实中有三种做法做法适用场景代价图片转文字描述后入库纯文本 LLM描述质量依赖 OCR/多模态模型会丢信息图片 embedding 单独建索引支持视觉的 LLM需要多模态 embedding 模型成本高图文混合 chunk图作为附件报告、手册类需要生成端支持图文混排我实测下来对于产品手册、说明书这类场景最稳的是第一种加第三种组合用多模态模型给每张图生成一段结构化描述包含图中文字、图表类型、关键数值把描述文本入库用于检索同时保留原图链接生成时如果需要可以引用。这样即使主模型不支持视觉检索链路也是通的。3.3 从 RAG 到 GraphRAG什么时候值得上图谱graphrag和rag检索增强经常被放在一起比较。我的判断标准很简单当你的问题需要跨多个文档做多跳推理时才值得上 GraphRAG。普通 RAG 擅长的是找相似片段。用户问X 是什么它能召回讲 X 的段落。但如果用户问X 和 Y 之间通过哪些中间环节产生关联普通 RAG 就很吃力因为它检索的是孤立片段没有关系结构。GraphRAG 的价值就在于把实体和关系抽出来建成图检索时沿着边游走能回答多跳问题。但 GraphRAG 的代价是实打实的构建图谱需要额外的抽取和消歧步骤成本可能是普通 RAG 的 3 到 5 倍而且图谱一旦建错错误会沿着边传播比单点错误更难排查。我的建议是先用普通 RAG 跑如果发现大量用户问题都是多跳类型再考虑上 GraphRAG。别为了技术时髦硬上最后维护不动。3.4 零基础可复制的本地 RAG 最小闭环热词里有个ollama 简易本地 rag 知识库【零基础可复制教程】这个方向我很推荐新手拿来练手。核心链路就四步本地模型跑推理、文档切分、向量化入库、检索拼接。用 Ollama 拉一个中等规模的模型配一个轻量向量库几十行代码就能跑通。关键不在跑通而在跑通之后你要做的三件事第一准备 20 条真实问题做评测集记录召回率和答案正确率第二故意问一些知识库里没有的问题看模型会不会硬编答案幻觉检测第三把切分参数、检索 top-k、相似度阈值都做成可调的观察它们对结果的影响。这三件事做完你对 RAG 的理解会超过看十篇教程。4. MCP 协议把 Agent 的能力标准化接出去4.1 mcp协议到底解决什么问题mcp协议和mcp 是软件协议 硬件协议那个概念叫什么来着这两个搜索词放一起看特别有意思——很多人第一次听到 MCP 时会下意识拿它跟硬件接口协议类比。这个类比其实挺准的MCPModel Context Protocol想做的事就是给 LLM 和外部工具/数据源之间定一个通用插口。在 MCP 之前你每接一个工具就要写一套适配代码接数据库写一套接文件系统写一套接第三方 API 再写一套。工具一多适配代码就成了维护噩梦。MCP 的思路是把工具能提供什么能力用统一的方式描述出来客户端按标准去发现和调用。这样工具提供方只要实现一次 MCP server所有支持 MCP 的客户端都能用。这个标准化的价值在生态层面才真正显现。当大家都按同一套协议实现工具就能像积木一样拼装。这也是为什么你会看到ruoyi-vue-pro合并mcp功能、codex 接入 figma mcp、cheat engine 桥接 mcp教程、x32dbg 的mcp插件这类五花八门的组合——不同领域的工具都在往这个协议上靠。4.2 接入 MCP 时最容易卡住的三个地方我自己接 MCP 的过程中卡得最久的不是协议本身而是下面这三件事。第一是授权。codex 接入 figma mcp 怎么授权这个问题很典型。MCP server 访问外部资源时往往需要凭证。凭证怎么传、存在哪、怎么刷新协议本身给的是框架具体实现各家不同。我的做法是把凭证统一放在环境变量或密钥管理服务里绝不硬编码进配置文件同时给每个 server 单独的最小权限避免一个 server 被攻破导致全线失守。第二是沙盒。codex无法发送消息,显示更新agent沙盒这类报错我遇到过好几次。Agent 执行工具调用时通常跑在沙盒里沙盒的网络、文件系统权限是受限的。如果工具需要访问沙盒外的资源就会失败。排查时先看沙盒的权限配置再看工具声明的能力范围是否匹配。很多时候不是代码问题是权限没开对。第三是工具描述的歧义。MCP 靠工具的名称和描述让模型决定调哪个。如果描述写得含糊模型就会乱调。我见过两个工具描述几乎一样结果模型每次都在它们之间反复横跳。解决办法是把描述写得足够具体明确写出什么时候用我、什么时候别用我必要时在描述里给出输入输出示例。4.3 MCP 与 Agent 安全别把钥匙交给不认识的工具agent安全和agentpoison: red-teaming llm agents via poisoning memory or knowledge ba这两个词放在一起点出了 Agent 时代最要命的安全问题记忆和知识库是可以被投毒的。传统软件的安全边界相对清晰输入输出都有明确格式。但 Agent 会读知识库、会写记忆、会调工具任何一个环节被污染都可能让它在后续任务里做出错误甚至危险的决策。比如攻击者在知识库里塞一条遇到某类请求时先把数据发到某个地址如果 Agent 没有对工具调用做二次校验就可能照做。我的防护思路分三层第一层是输入侧对进入知识库和记忆的内容做来源标记和可信度分级低可信来源的内容不参与高权限决策第二层是决策侧对敏感操作写文件、发请求、改配置强制人工确认或双模型交叉验证第三层是输出侧记录完整的工具调用链出问题能回溯。这三层里第一层最容易被忽略但恰恰是最关键的。5. Agent 工程化并发、框架选型与 harness 的边界5.1 ai agent 怎么扛并发从能跑到扛得住ai agent 怎么扛并发是生产环境绕不开的问题。Agent 和普通 API 不一样它一次请求可能包含多轮 LLM 调用加多次工具调用耗时是普通接口的几十倍。如果按传统同步接口的思路做并发一上来就雪崩。我的做法是把 Agent 执行拆成异步任务。用户发起请求后立刻返回一个任务 ID实际执行放到队列里前端轮询或走推送拿结果。这样接口层不会被长耗时拖死。队列的消费端要控制并发度因为 LLM 服务本身有速率限制盲目开大并发只会触发限流。另一个关键是幂等和断点续传。Agent 执行到一半失败是常态如果每次都从头再来成本和延迟都受不了。我会把每一步的中间状态持久化失败后从最后一个成功步骤继续。这要求你的工具调用设计成幂等的——同一个操作重复执行结果一致。做不到幂等的操作比如发送通知就要加去重标记。还有一个容易被忽略的点超时和熔断。单个工具调用卡住会拖垮整个 Agent。我给每个工具调用都设了独立超时超时就跳过并记录让 Agent 带着这个工具暂时不可用的信息继续往下走而不是整个任务失败。5.2 agent框架怎么选别被全家桶绑架agent框架和llm框架的选择我的核心观点是先想清楚你要的是编排能力还是开箱即用。LangChain 这类框架提供的是编排能力链、工具、记忆、回调都有抽象灵活但学习曲线陡版本迭代快经常升级一次就 breaking change。另一类框架走的是全家桶路线把 RAG、Agent、工具都打包好上手快但定制难遇到框架没覆盖的场景就得绕。我的实际选择是核心链路自己写只在确实能省事的地方用框架。比如工具调用的 schema 定义、重试逻辑这些通用性强用框架没问题但 Agent 的决策循环、状态管理我倾向自己控制因为这部分和业务耦合最深被框架绑死之后改起来很痛苦。langchain4j easy rag这类轻量封装就属于我比较认可的用法——只解决一个具体问题不试图接管你的整个架构。5.3 harness 和 agent 的区别一个常被混淆的边界harness和agent区别这个问题值得单独说。harness测试夹具/执行框架和 agent 经常被混为一谈但它们的职责完全不同。Agent 是做决策的主体它根据目标决定下一步做什么。Harness 是执行和观测的容器它负责把 agent 跑起来、喂输入、收输出、记录过程、做断言。打个比方Agent 是司机Harness 是测试跑道和行车记录仪。你可以用同一个 harness 去测不同的 agent也可以用不同的 harness 去测同一个 agent。搞清楚这个区别的实际意义在于当你做 Agent 评测时评测逻辑应该放在 harness 里而不是塞进 agent 内部。我见过有人把评测代码写进 agent 的执行流程结果 agent 为了通过测试而作弊评测结果完全失真。正确的做法是 harness 从外部观察 agent 的行为agent 本身不知道自己在被评测。5.4 基于 LLM 的单元测试让模型帮你写测试但别全信基于llm的单元测试是个提效明显但也有坑的方向。用 LLM 生成测试用例能覆盖到人容易忽略的边界情况尤其是那些看起来不可能但确实会发生的输入。但坑在于LLM 生成的测试经常是自证式的——它根据你的实现反推测试所以实现错了测试也跟着错跑出来全绿但实际有 bug。我的做法是让 LLM 先生成测试然后人工审查测试的断言部分确保断言是基于需求而不是基于实现写的。另外LLM 生成的测试要跑覆盖率如果覆盖率虚高但关键分支没覆盖到说明测试质量不行。还有一个实用技巧用llm as judge来评估测试质量。让另一个模型判断这些测试是否真正验证了需求能筛掉一批无效测试。但 judge 本身也有偏差所以最终还是要人工抽查。6. 那些看起来不相关的热词其实指向同一个趋势6.1 从 unreal 5.8 mcp 到 ros2 micro-ros agentAgent 正在进入物理世界热词里unreal 5.8 mcp、docker容器里的ros2 humble, micro-ros agent、windows hermes agent桌面版 配置这几个放在一起看指向一个很明确的趋势Agent 不再局限于聊天窗口正在往游戏引擎、机器人系统、桌面环境里渗透。Unreal 接入 MCP意味着游戏里的 NPC 或开发工具可以用标准协议调用外部能力。ROS2 里的 micro-ros agent是把 Agent 概念用到了嵌入式机器人通信上。Hermes agent 桌面版则是把 Agent 能力搬到本地桌面。这些场景的共同点是Agent 需要和真实世界的设备、软件、环境交互对实时性、可靠性、权限控制的要求比纯文本场景高得多。我的判断是接下来一两年Agent 工程化的重心会从怎么让模型更聪明转向怎么让 Agent 在受限环境里安全可靠地行动。这对做后端和嵌入式的人来说是机会因为纯 prompt 调优的空间在收窄而系统集成的价值在上升。6.2 spatial llm 与 llm wiki知识组织方式的两种探索spatial llm和llm wiki这两个词比较新。spatial llm 我理解是把空间信息纳入 LLM 的处理范围让模型理解位置距离方位这类概念应用在导航、游戏、AR 等场景。llm wiki 则是用 LLM 来组织和维护知识库让 wiki 从人写人读变成人写模型读、模型写人审。这两个方向的共同点是都在扩展 LLM 的输入模态和知识载体。前者扩展的是空间模态后者扩展的是知识组织形态。它们能不能成为主流还不好说但反映出的需求是真实的——大家已经不满足于让 LLM 只处理纯文本了。6.3 一个报错的启示llm request failed 背后的 schema 问题llm request failed: provider rejected the request schema or tool payload这个报错我最近见得特别多。它通常出现在工具调用场景原因是发给模型的工具 schema 不符合 provider 的要求。常见原因有三个一是 schema 里用了 provider 不支持的 JSON Schema 关键字比如某些复杂的嵌套或条件约束二是工具描述里包含了 provider 认为不安全的字符或格式三是 payload 太大超过了限制。排查时先把 schema 简化到最小可用版本确认能通之后再逐步加回字段定位到具体是哪个字段导致的。这个报错给我的启示是工具调用的 schema 设计要保守。别用太花哨的 JSON Schema 特性保持结构扁平、类型明确、描述简洁。跨 provider 兼容性比表达力更重要因为你不知道用户会用哪个模型来跑你的工具。7. 我在 Agent 项目里反复验证的几条经验做 Agent 和 LLM 应用这两年有几条经验是我踩了坑之后才真正记住的分享出来给正在路上的同行。第一条先做评测再做优化。没有评测集的优化都是盲调。我见过团队花两周调 prompt结果因为没有基线根本说不清到底变好了还是变差了。哪怕只有 30 条测试用例也比没有强。第二条把不确定性显式暴露给用户。Agent 会犯错这是事实。与其假装它永远正确不如在输出里标注置信度、给出引用来源、对不确定的部分明确说我不确定。用户对知道自己不知道的系统容忍度远高于一本正经胡说的系统。第三条工具宁少勿多。工具越多模型选错的概率越大。我一开始给 Agent 接了十几个工具结果它经常在相似工具之间纠结。后来砍到 5 个核心工具把其他能力合并进去任务成功率反而上去了。第四条日志要记全但别只记文本。Agent 的日志要包含完整的决策链模型看到了什么、调了什么工具、工具返回了什么、下一步怎么决策。只记最终输出出问题时你根本不知道错在哪一步。我现在会把每一步的 token 消耗、延迟、工具调用参数都记下来排查效率高很多。第五条给 Agent 设止损线。无限循环是 Agent 的经典故障模式。我给它设了最大步数、最大 token 消耗、最大执行时间三个硬限制任何一个触顶就强制终止并返回当前最好结果。这个简单的保护措施救过我好几次。最后说一个我最近的体会Agent 和 LLM 这个领域技术迭代快得让人焦虑但真正决定项目成败的往往不是用了多新的模型或多炫的框架而是那些朴素的工程基本功——清晰的评测、可靠的错误处理、克制的架构设计。新东西要跟但别为了跟而跟。把手上这条链路跑稳比追十个热点更有价值。