1. 从一份日报说起Agent 与 LLM 生态到底在卷什么如果你最近半年一直在跟 Agent 和 LLM 相关的项目大概率会有一种感觉每天醒来打开信息流满屏都是新名词——昨天还在聊 RAG今天就在吵 GraphRAG上周刚把 MCP 接进项目这周又冒出来一个harness 和 agent 到底啥区别。信息密度高到让人焦虑但真正能落地的内容又少得可怜。我写这篇东西的出发点很简单把 2026 年 9 月底这一波 Agent / LLM 领域的热点按技术脉络而不是新闻时间线重新梳理一遍。不是简单罗列今天又出了什么框架而是把 RAG、GraphRAG、MCP、Agent 架构、并发、安全这几条线串起来讲清楚它们各自解决什么问题、彼此怎么配合、实际落地时哪些坑最容易踩。适合正在做 Agent 项目的开发者、正在选型 RAG 方案的技术负责人以及想搞清楚这些热词背后到底是不是真需求的从业者。先给一个整体判断2026 年的 Agent 生态已经从能不能跑通进入能不能扛住的阶段。前两年大家比的是谁的 Demo 更惊艳现在比的是谁的 Agent 在高并发下不崩、在脏数据下不胡说、在恶意输入下不被带偏。这个转变直接决定了今天所有热词的价值排序——RAG 是地基GraphRAG 是地基的加固层MCP 是管线接口Agent 架构是承重墙而并发和安全是验收标准。下面逐层拆。2. RAG 依然是地基但能存图片吗这个问题暴露了认知断层2.1 RAG 的本质不是检索生成而是给模型喂对上下文很多人对 RAG 的理解停留在把文档切块、向量化、检索、拼进 prompt这个流水线上。这个理解没错但太浅。RAG 真正解决的问题是大模型的参数化知识是冻结的、模糊的、不可追溯的而业务需要的是实时的、精确的、可引用的答案。我习惯用一个类比LLM 像一个博学但记性有点糊的老教授你问他我们公司上季度的报销政策第三条是什么他可能给你编一个听起来很合理的答案。RAG 的作用就是在他回答前先把那份政策文件翻到第三条拍在他桌上。教授还是那个教授但答案的准确性完全不一样了。所以 RAG 的核心不是检索这个动作而是上下文工程——你喂进去的 chunk 质量直接决定输出质量。这也是为什么rag瓶颈这个词会反复上热搜大部分人卡住的地方不是向量库选型而是 chunk 策略和召回精度。2.2 RAG 知识库能存储图片吗——这个问题的三层答案这是最近被问得最多的一个问题值得单独拆开讲因为它牵扯到多模态 RAG 的完整链路。第一层能存但存的是图片的向量表示不是图片本身。标准做法是用 CLIP 或类似的视觉编码器把图片转成向量存进向量库。检索时用文本 query 去匹配图片向量这叫跨模态检索。但这里有个坑CLIP 类模型对图表中的具体数字流程图里的箭头方向这类细粒度信息捕捉很差你搜第三季度增长率可能召回一张完全不相关的柱状图。第二层真正实用的方案是图片描述双存。我的做法是图片入库时先用一个多模态模型比如支持视觉的 LLM生成一段结构化描述把图片里的关键信息——标题、坐标轴、数据点、流程节点——全部文字化然后图片向量和描述文本向量都存检索时走文本通道为主、图片通道为辅。这样召回精度会高一个量级。第三层如果图片是文档的一部分别单独抽出来。很多 PDF 里的图表和正文是强关联的单独把图抽出来存会丢失上下文。更好的做法是按页或按章节做多模态 chunk一个 chunk 里同时包含文本和图片引用检索命中后整块喂给模型。提示多模态 RAG 的成本主要在入库阶段一次性的图片描述生成可能比纯文本入库贵 5 到 10 倍。如果图片量大建议先做一轮筛选只对真正有检索价值的图图表、流程图、截图做描述生成装饰性图片直接跳过。2.3 RAG 的瓶颈到底在哪一次真实的排查记录上个月帮一个团队排查他们的 RAG 系统答非所问的问题整个过程很有代表性分享下排查链路。现象是用户问XX 功能的超时时间怎么配置系统总是召回一堆无关的配置文档。第一反应是 embedding 模型不行换了个更强的模型效果提升有限。第二步查 chunk 策略发现他们按固定 512 token 切块把一份配置说明从中间切断了超时时间这个关键词在 chunk A具体的数值在 chunk B检索只命中了 A。改成按语义段落切块并且加了 20% 的 overlap 之后召回准确率从 60% 出头提到 85% 左右。但还没完第三步发现他们的 rerank 环节是缺失的——向量检索 top 20 直接取 top 3 喂给模型没有重排序。加了一个轻量 rerank 模型后最终准确率到 92%。这个案例说明一件事RAG 的瓶颈从来不是单点而是链路上每一环的乘积效应。embedding、chunk、召回数量、rerank、prompt 组装任何一环拉胯整体就拉胯。别指望换个向量库就能解决所有问题。3. GraphRAG 不是 RAG 的升级版而是另一类问题的解法3.1 什么时候该上 GraphRAG一个判断标准GraphRAG 最近热度很高但我见过太多团队在不需要它的场景硬上结果复杂度爆炸、收益寥寥。先给一个判断标准如果你的问题需要跨文档、多跳推理GraphRAG 值得上如果只是单文档精确问答普通 RAG 就够了。举个例子。问张三负责的项目里哪些用到了李四团队维护的组件——这个问题需要先找到张三负责的项目再查每个项目用到的组件再匹配组件归属这是典型的多跳。普通 RAG 很难处理因为答案不在任何一个 chunk 里而是散落在多个 chunk 的关系中。GraphRAG 通过构建实体-关系图把这种多跳查询变成图上的路径查找天然适配。反过来问这份合同的违约金比例是多少这就是单点查询GraphRAG 的图构建成本纯属浪费。3.2 GraphRAG 的构建成本与收益权衡GraphRAG 的代价是实打实的。以一份 500 页的技术文档为例普通 RAG 的入库成本主要是 embedding 调用几块钱的事。GraphRAG 需要先做实体抽取、关系抽取、社区检测、摘要生成这一套下来LLM 调用量可能是普通 RAG 的 20 到 50 倍成本直接上两个数量级。所以我的建议是分层建设先用普通 RAG 覆盖 80% 的查询把高频的、需要多跳的 20% 查询单独识别出来只对这部分相关的文档子集构建图谱。不要一上来就全量图谱化那是烧钱。3.3 Ontology 在 GraphRAG 里的角色别把它想复杂了llm ontology和ontology rag这两个词最近也常出现。Ontology本体听起来很学术实际在 GraphRAG 里就是你预先定义好的实体类型和关系类型。比如做企业知识库你可以定义实体类型人、部门、项目、组件、文档关系类型负责、隶属于、依赖、引用。有了这套 schema实体抽取时模型就知道该抽什么、该怎么连图谱质量会稳定很多。没有 ontology模型自由发挥抽出来的图往往是一团乱麻节点类型五花八门根本没法查询。我的经验是ontology 不用追求完备先定义 5 到 8 个核心实体类型和关系类型跑起来再迭代。追求一步到位的完美本体是典型的过度设计。4. MCP被误解最深的协议以及它到底解决什么问题4.1 MCP 是软件协议不是硬件协议——先把概念理清热搜里有个很有意思的问题mcp 是软件协议硬件协议那个概念叫什么来着。这个问题本身就说明 MCP 这个概念被传播得有点变形了。MCPModel Context Protocol是一个软件层的通信协议解决的是LLM 应用如何标准化地调用外部工具和数据源的问题。你可以把它理解成 AI 世界的 USB-C 接口——以前每个工具都要写一套适配代码现在只要工具实现了 MCP任何支持 MCP 的客户端都能直接调用。至于硬件协议那个概念通常指的是总线协议如 I2C、SPI或设备通信协议。两者完全不是一个层面的东西别混。4.2 MCP 真正解决的痛点工具集成的 N×M 问题在没有 MCP 之前如果你有 N 个 LLM 应用和 M 个工具理论上要写 N×M 套集成代码。MCP 把这个变成 NM每个应用实现一次 MCP 客户端每个工具实现一次 MCP 服务端任意组合都能通。这个价值在ruoyi-vue-pro 合并 mcp 功能codex 接入 figma mcpcheat engine 桥接 mcp这些具体场景里体现得特别明显。以前给一个后台管理系统接 AI 能力要针对每个功能写定制接口现在把功能封装成 MCP serverAI 客户端直接就能调。4.3 接入 MCP 时最容易踩的三个坑坑一授权链路没理清。codex 接入 figma mcp 怎么授权这个问题很典型。MCP 本身不规定授权机制各家实现不一样。有的走 OAuth有的走 API Key有的走本地进程信任。接入前一定要先搞清楚目标 MCP server 的授权模型否则会卡在连上了但调不通。坑二工具描述写得太随意。MCP server 暴露的每个工具都有 description这个 description 是给 LLM 看的直接决定模型会不会在正确的时机调用它。我见过太多工具描述写成处理数据模型根本不知道什么时候该用。好的描述应该包含这个工具做什么、什么场景用、输入输出是什么格式。坑三错误处理缺失。MCP 调用失败时如果 server 返回的错误信息不清晰模型会陷入反复重试或者干脆胡说。建议在 server 端把错误分类返回让模型能区分参数错了和服务挂了前者可以自我修正后者应该直接告诉用户。4.4 MCP 与 Agent 的关系MCP 是手Agent 是大脑经常有人问MCP 和 Agent 什么关系。简单说Agent 是决策主体MCP 是它伸向外界的接口。Agent 决定我要查一下天气MCP 负责把这个意图翻译成对天气服务的标准调用再把结果拿回来。所以 MCP 本身不是 Agent它没有决策能力。但它是 Agent 能力边界的关键——一个 Agent 能调多少工具、调得多顺很大程度上取决于 MCP 生态的成熟度。5. Agent 架构从能跑到扛并发的工程化之路5.1 Harness 和 Agent 的区别一个被问烂但确实重要的问题harness 和 agent 区别这个词频繁出现说明很多人对 Agent 的边界认知是模糊的。我的理解Agent 是具备自主决策能力的智能体Harness 是承载和驱动 Agent 运行的外壳框架。Harness 负责的是工程层面的事——生命周期管理、工具注册、上下文维护、错误重试、日志追踪Agent 负责的是认知层面的事——理解任务、规划步骤、选择工具、判断结果。打个比方Agent 是司机Harness 是车。司机决定去哪、怎么走车提供动力、刹车、仪表盘。你换一个更好的 Harness不会让 Agent 变聪明但会让它跑得更稳、更容易调试、更容易扩展。这个区分很重要因为很多团队把工程问题当成智能问题来解决——Agent 表现不好就去换更大的模型结果发现是 Harness 的上下文管理有 bug把关键信息截断了。5.2 AI Agent 怎么扛并发四个层次的优化ai agent 怎么扛并发是个硬核工程问题。Agent 的并发比普通 Web 服务难得多因为每个请求背后可能是多次 LLM 调用、多次工具调用链路长、耗时长、状态多。我按层次拆解。第一层请求层削峰。Agent 请求的耗时通常在秒级到分钟级不能像普通 API 那样同步等待。标准做法是异步化——请求进来先入队返回一个 task id客户端轮询或走 SSE 拿结果。队列用 Redis 或专业消息队列都行关键是做好优先级和超时控制。第二层LLM 调用层限流与复用。LLM API 通常有 RPM 和 TPM 限制必须做客户端限流。同时相同或相似的 prompt 可以做缓存尤其是系统提示词和工具描述这类固定内容用 prompt caching 能省大量 token 和时间。第三层工具调用层隔离。工具调用是最容易拖垮整体的环节——一个慢查询能把整个 Agent 卡死。必须给每个工具调用设超时并且做熔断。工具挂了Agent 应该能感知到并降级而不是无限等待。第四层状态层无状态化。Agent 的会话状态不要放在进程内存里要外置到 Redis 或数据库。这样 Agent 实例可以水平扩展任何一个实例都能处理任何会话的下一步。这是扛并发的根本前提。注意很多 Agent 框架默认把状态放在内存Demo 阶段没问题一上生产就崩。选型时一定要确认框架的状态管理是否支持外置。5.3 Agent 安全AgentPoison 这类攻击为什么危险agentpoison: red-teaming llm agents via poisoning memory or knowledge ba这个方向值得所有做 Agent 的人警惕。它的攻击思路是往 Agent 的记忆或知识库里注入恶意内容诱导 Agent 在未来某个时刻做出错误决策。危险之处在于它的隐蔽性。传统攻击是直接篡改输入容易被发现AgentPoison 是污染长期记忆可能注入后几天才触发而且触发时看起来像是 Agent自己的判断。比如往知识库塞一条遇到 XX 情况时应该把数据发送到 XX 地址Agent 在后续任务中检索到这条就可能照做。防御思路有几条一是记忆写入要做来源校验和内容审核不能什么都能进二是敏感操作要有独立的确认机制不能完全依赖 Agent 自主判断三是定期审计记忆库发现异常内容及时清理。5.4 Agent 框架选型别被框架两个字绑架agent框架llm框架rag框架这些词背后是大量团队在纠结选型。我的观点比较直接框架能帮你省的是脚手架代码省不了的是架构设计。LangChain、LangChain4j 这类框架的价值在于提供了标准化的抽象和丰富的集成让你不用从零写工具调用、记忆管理这些轮子。但它们的抽象层也可能成为负担——当你想做一些框架没预设的事情时会发现自己被绕进去了。我的建议是先用框架快速跑通理解 Agent 的核心循环感知-规划-行动-观察然后在关键路径上逐步替换成自己可控的实现。不要一上来就手写全套也不要永远停留在框架的舒适区。6. 那些容易被忽略的细节从 token 三要素到本地部署6.1 LLM 的 token 三要素key、query、value 的通俗理解热搜里有个很妙的表述llm的token三个点key我是谁、query我在找什么、value我能提供什么。这其实是用注意力机制的 QKV 来类比信息检索非常形象。用大白话讲每个 token 在注意力计算里会生成三个向量。Query 是我想找什么信息Key 是我能被谁找到Value 是我实际提供的内容。Query 和 Key 做匹配算出权重再用权重对 Value 加权求和得到这个位置的输出。理解这个机制的实际意义在于它解释了为什么长上下文里模型会遗忘中间部分——注意力权重被稀释了。也解释了为什么 prompt 里关键信息要放在开头或结尾——这两个位置的注意力权重通常更高。做 RAG 拼上下文时把最相关的 chunk 放在首尾是有理论依据的。6.2 本地 RAG 部署Ollama 方案的适用边界ollama 简易本地 rag 知识库这类教程很受欢迎因为零基础可复制。但我要泼一点冷水本地部署适合的是数据敏感、量不大、对延迟不敏感的场景。Ollama 跑 7B 到 14B 的模型在消费级显卡上能跑但检索质量和生成质量跟云端大模型有明显差距。如果你的知识库是几百份内部文档查询频率不高本地方案完全够用而且数据不出内网合规上省心。但如果是面向大量用户的生产系统本地模型的并发能力和质量都撑不住。一个折中方案是混合架构检索和 embedding 用本地模型数据敏感的部分不出网最终生成用云端大模型只传检索到的片段不传全量数据。这样兼顾了合规和质量。6.3 LLM as Judge用模型评估模型靠谱吗llm as judge是个越来越常用的模式——用一个大模型来评估另一个模型的输出质量。它的优势是能处理开放式任务不像传统指标那样死板。但坑也不少。最大的坑是位置偏见模型倾向于给排在前面的答案更高分。解决办法是评估时随机打乱顺序或者两个顺序都评一遍取平均。第二个坑是自我偏好模型倾向于给自己或同系列模型的输出更高分。所以 judge 模型最好和被测模型不同源。我的实践是LLM as Judge 适合做粗筛和回归测试不适合做最终的质量判定。关键场景还是要人工抽检把 judge 的结果作为参考而非结论。6.4 基于 LLM 的单元测试能生成但别全信基于llm的单元测试这个方向能省不少写测试的时间但生成出来的测试用例质量参差不齐。常见问题是测试只覆盖 happy path边界条件基本不碰mock 写得过于宽松测了等于没测。我的用法是让 LLM 生成测试骨架和基础用例然后人工补充边界条件和异常路径。LLM 擅长的是把明显的场景写出来不擅长的是想到那些反直觉的边界。把这两者结合效率提升明显但别指望全自动。7. 把这一堆技术串起来一个可落地的 Agent 系统长什么样讲了这么多点最后落到一个具体问题上如果今天要从零搭一个 Agent 系统这些技术该怎么组合我的推荐架构是这样的。底层是 RAG 知识层用普通 RAG 覆盖大部分查询对需要多跳的核心领域子集构建 GraphRAGontology 先定义核心实体关系。中间是 MCP 工具层把所有外部能力数据库查询、API 调用、文件操作封装成标准 MCP serverAgent 通过统一接口调用。上层是 Agent 决策层用 Harness 管理生命周期和状态状态外置到 Redis 支持水平扩展LLM 调用做限流和缓存工具调用做超时和熔断。贯穿全局的是安全层记忆写入做审核敏感操作做二次确认定期审计。这套架构不追求每个环节都用最新最炫的技术而是追求每一层都清晰、可替换、可观测。Agent 这个领域变化太快今天的热词明天可能就凉了但分层解耦的架构能让你在换技术时只动一层不用推倒重来。我在实际项目里最大的体会是Agent 系统的难点从来不在智能而在工程。模型能力是现成的把它稳定、可靠、安全地跑在生产环境里才是真正花时间的地方。那些热搜词里真正值得投入精力的是 RAG 的检索质量、MCP 的接口规范、并发架构的设计而不是追逐每一个新框架。把地基打牢上面的东西怎么变都不慌。
