1. 从一份日报标题说起Agent 与 LLM 生态到底在卷什么看到“Agent / LLM 技术精选日报”这个标题很多人的第一反应是又是一份信息聚合。但如果你真的在一线做 Agent 开发就会明白这类日报的价值不在于“汇总”而在于它暴露了整个生态当前最活跃的神经末梢。2026 年这个时间节点Agent 和 LLM 已经从“能不能跑通”进入“能不能扛住生产环境”的阶段热搜词里同时出现 RAG、MCP、GraphRAG、Agent 安全、并发扛压这本身就说明问题——大家不再满足于 demo而是在补工程化的课。我自己从 2023 年开始折腾 LLM 应用从最早的 prompt 拼接到后来的 RAG 检索增强再到现在的 MCP 工具协议和 GraphRAG 知识图谱踩过的坑基本覆盖了这条演进路线上的每一个阶段。这份日报标题里提到的关键词几乎每一个我都实际落地过或者至少做过 PoC。所以这篇文章不打算复述日报内容而是借这个标题把 Agent / LLM 这条技术线上真正值得关注的核心问题拆开讲透RAG 的瓶颈到底在哪、MCP 协议解决了什么、GraphRAG 和传统 RAG 的边界、Agent 并发怎么扛、Agent 安全为什么突然变成热词。适合谁看如果你正在做 RAG 知识库、正在选 Agent 框架、正在纠结要不要上 MCP、或者被“Agent 怎么扛并发”这个问题卡住这篇内容应该能给你一些直接可用的判断依据。我会尽量用从业者之间交流的方式来讲不堆术语该给参数给参数该给踩坑经验给踩坑经验。2. RAG 知识库从“能检索”到“检索得准”的瓶颈突破2.1 RAG 的真实瓶颈不在检索而在“检索之后”热搜词里有个很典型的问题“rag瓶颈”。很多人做 RAG 的第一反应是换个更好的 embedding 模型、调大 top_k、上 rerank。这些都对但实测下来真正卡住效果的往往不是检索环节而是检索之后的处理。我做过一个内部文档问答系统embedding 用的是当时榜单靠前的模型top_k 设到 10rerank 也加了但回答质量就是上不去。后来发现问题出在 chunk 切分上——文档里一个完整的操作步骤被切成了三段检索命中了其中一段但 LLM 拿到的上下文是残缺的自然答不对。RAG 的瓶颈通常集中在三个地方。第一是 chunk 策略固定长度切分对结构化文档是灾难表格、代码块、步骤列表被拦腰截断是常态。第二是检索结果的去重和排序top_k 拿回来的内容经常高度重复真正有用的那条反而排在后面。第三是上下文窗口的利用效率把 10 条检索结果一股脑塞进去LLM 的注意力被稀释关键信息反而被淹没。提示如果你的 RAG 效果不好先别急着换模型把检索命中的原始 chunk 打印出来看一眼十有八九问题出在切分和排序上。2.2 RAG 知识库能不能存图片多模态检索的现实做法“rag知识库能存储图片嘛”这个问题问得很多答案是能但做法和纯文本 RAG 完全不同。图片本身没法直接做向量检索常规做法是给图片生成文本描述用描述文本做 embedding检索时命中描述再把原图返回给多模态 LLM。我试过两种方案一种是用多模态模型对每张图生成 caption另一种是人工标注关键信息。实测下来纯自动 caption 对图表类图片效果一般因为模型经常漏掉坐标轴、图例这些关键信息。更稳的做法是混合方案自动 caption 打底对重要的图表类图片补充人工标注的结构化描述比如“这张图展示了 2025 年 Q1 到 Q4 的营收趋势Q3 出现明显下滑”。检索时用这个描述做匹配命中率比纯自动 caption 高不少。另外要注意图片存储和文本存储要分开管理向量库里存的是描述文本的 embedding原图存在对象存储里通过 ID 关联。这样检索和展示解耦后续换 embedding 模型也不用重新处理图片。2.3 从 RAG 到 GraphRAG什么时候该上知识图谱“GraphRAG”和“ontology rag”这两个词放在一起说明大家开始意识到纯向量检索的天花板。向量检索擅长“找相似”但不擅长“找关系”。比如你问“A 项目的负责人同时负责哪些其他项目”纯向量 RAG 很难答对因为它需要跨文档的关系推理。GraphRAG 的思路是把文档里的实体和关系抽出来构建知识图谱检索时先在图谱上做关系查询再把相关子图喂给 LLM。但 GraphRAG 不是银弹。我做过一个对比测试同样一批文档纯 RAG 和 GraphRAG 在事实型问答上差距不大但在多跳推理问题上 GraphRAG 明显更好。代价是构建成本高——实体抽取、关系抽取、图谱维护每一步都要额外投入。我的判断是如果你的问答场景里超过 30% 的问题涉及跨文档关系推理GraphRAG 值得上如果大部分问题是“某文档里说了什么”纯 RAG 加好的 rerank 就够了。方案适用场景构建成本多跳推理能力纯向量 RAG事实型问答、文档检索低弱RAG Rerank中等复杂度问答中中GraphRAG关系推理、多跳问答高强Ontology RAG强结构化领域知识很高强2.4 KG 知识库、RAG 知识库、结构知识库的区分与选型这三个概念经常被混着用但实际落地时区别很大。KG 知识库知识图谱存的是实体和关系适合做推理和关系查询。RAG 知识库存的是文本 chunk 的向量适合做语义相似检索。结构知识库一般指关系型数据库或者结构化文档适合精确查询和聚合统计。我见过不少项目一上来就想搞知识图谱结果发现 80% 的查询其实是“某文档里有没有提到 X”用向量检索又快又便宜。选型的核心是看查询类型。精确匹配、聚合统计走结构知识库语义相似、模糊检索走向量 RAG关系推理、多跳查询走知识图谱。实际项目里往往是三者组合比如先用结构知识库过滤范围再用向量 RAG 做语义匹配最后用知识图谱补关系。别追求单一方案通吃组合才是常态。3. MCP 协议Agent 工具调用的标准化尝试3.1 MCP 到底是什么为什么突然火了“mcp是什么”这个问题在热搜里反复出现说明很多人还没搞明白它的定位。MCPModel Context Protocol本质是一套让 LLM 和外部工具、数据源交互的标准化协议。在 MCP 之前每个 Agent 框架都有自己的工具调用格式LangChain 一套、AutoGPT 一套、各家自研的又一套工具提供方要适配 N 个框架成本极高。MCP 想做的就是统一这个接口层让工具提供方写一次所有支持 MCP 的客户端都能用。我实际用下来的感受是MCP 的价值在“生态复用”。以前我要给 Agent 接一个数据库查询工具得自己写 function calling 的 schema、处理参数解析、做错误处理。现在如果有现成的 MCP server直接配置一下就能用。热搜里提到的“x32dbg 的 mcp插件”“cheat engine 桥接 mcp教程”“unreal 5.8 mcp”说明 MCP 已经开始渗透到各种专业工具领域不再局限于 Web 和数据库。3.2 MCP 工具流式输出到文件的实操要点“使用mcp工具流式输出内容到文件”这个场景很实用但坑也不少。MCP 工具调用默认是请求-响应模式流式输出需要工具端和客户端都支持。我试过用 MCP 做一个日志分析工具把分析结果流式写到文件里遇到的主要问题是缓冲和刷盘时机。如果工具端攒够一批才写客户端会以为卡住了如果每条都写IO 开销又太大。实操建议是设置合理的缓冲阈值比如每 4KB 或者每 100 条记录刷一次盘同时在 MCP 协议层发送进度通知让客户端知道工具还在工作。另外文件路径要做安全校验防止路径穿越。我见过一个案例工具接收用户传入的文件名直接拼接路径结果被构造了../../的路径写到了不该写的地方。MCP 工具涉及文件操作时路径白名单是必须的。# MCP 工具流式写文件的简化示例 import os ALLOWED_DIR /data/output def safe_path(filename): full os.path.realpath(os.path.join(ALLOWED_DIR, filename)) if not full.startswith(os.path.realpath(ALLOWED_DIR)): raise ValueError(path traversal detected) return full def stream_write(filename, chunks, buffer_size4096): path safe_path(filename) buf [] buf_len 0 with open(path, w, encodingutf-8) as f: for chunk in chunks: buf.append(chunk) buf_len len(chunk) if buf_len buffer_size: f.write(.join(buf)) f.flush() buf, buf_len [], 0 if buf: f.write(.join(buf))3.3 MCP 与现有框架的合并ruoyi-vue-pro 的启示“ruoyi-vue-pro合并mcp功能”这个热搜词很有意思它代表了一类需求把 MCP 能力集成到已有的企业级框架里。ruoyi-vue-pro 是国内很流行的后台管理框架如果它能原生支持 MCP意味着大量存量系统可以低成本接入 Agent 能力。我研究过类似的集成方案核心难点不在协议本身而在权限和审计。企业系统里每个操作都要有权限校验和操作日志MCP 工具调用也不例外。直接把 MCP server 挂上去等于开了一个绕过原有权限体系的旁路。正确做法是把 MCP 工具调用纳入现有的权限模型每个工具声明自己需要的权限调用时走统一的鉴权中间件。审计日志也要记录完整的调用链谁、什么时候、通过哪个 Agent、调用了什么工具、参数是什么、结果是什么。这块做不好Agent 能力越强安全风险越大。3.4 MCP 选型与自研的边界判断不是所有场景都值得上 MCP。我的判断标准是如果你只需要接一两个工具且框架本身支持 function calling直接写原生工具更简单。MCP 的价值在工具数量多、需要跨框架复用、或者工具提供方和 Agent 开发方是不同团队的时候。比如你公司有十几个内部系统都要接 Agent每个系统团队自己维护 MCP serverAgent 团队只管调用这种分工下 MCP 的标准化优势才能体现。自研 MCP server 的成本主要在协议实现和错误处理。协议本身不复杂但要做好超时、重试、并发控制、结果序列化这些工程细节。我建议先用官方 SDK 跑通再根据实际需求做定制。别一上来就自己从头实现协议容易在细节上翻车。4. Agent 架构与并发从 demo 到生产的鸿沟4.1 Agent 框架选型的核心考量“agent框架”“agent架构”“agent是什么”这几个词放在一起说明很多人还在选型阶段。我用过 LangChain、LangGraph、AutoGen、CrewAI也自己写过轻量级 Agent 循环。选型的核心不是看功能列表而是看你的场景需要多复杂的控制流。如果只是“LLM 调用工具、拿结果、再调用”自己写一个循环可能比框架更可控。如果涉及多 Agent 协作、复杂状态机、人工介入节点那 LangGraph 这类图式框架更合适。我踩过的一个坑是过早引入重框架。早期项目用 LangChain结果发现大部分抽象用不上调试时还要穿透好几层封装才能看到实际发给 LLM 的 prompt。后来换成自己写的轻量循环代码量少了一半排查问题也直接。框架的价值在复杂场景简单场景别为了“用框架”而用框架。4.2 Agent 怎么扛并发连接池、限流与状态隔离“ai agent 怎么扛并发”是个实打实的工程问题。Agent 的并发瓶颈通常不在 LLM 调用本身而在工具调用和状态管理。LLM API 一般有速率限制工具调用可能涉及数据库、外部 API这些才是并发上不去的原因。我的做法是分层处理LLM 调用层做请求队列和重试工具调用层做连接池和超时控制Agent 状态层做隔离。状态隔离特别重要。多个并发请求如果共享同一个 Agent 实例上下文会串。正确做法是每个请求一个独立的 Agent 上下文共享的只有工具连接池和配置。我用过的一个方案是用 contextvars 做请求级上下文隔离配合异步 IO单机扛几百并发问题不大。但要注意如果工具调用是同步阻塞的异步也救不了必须把阻塞操作放到线程池里。# Agent 并发处理的核心结构示意 import asyncio from contextvars import ContextVar request_ctx ContextVar(request_ctx) async def handle_request(user_input, agent_pool, tool_pool): ctx {history: [], user_input: user_input} request_ctx.set(ctx) async with tool_pool.acquire() as tools: result await agent_pool.run(ctx, tools) return result async def main(): tasks [handle_request(q, agent_pool, tool_pool) for q in queries] results await asyncio.gather(*tasks, return_exceptionsTrue)4.3 Agent 安全被忽视的攻击面“agent安全”和“agentpoison”这两个词放在一起指向一个越来越严重的问题Agent 的记忆和知识库可以被投毒。AgentPoison 这类研究展示的攻击方式是在 Agent 可访问的知识库里注入恶意内容当 Agent 检索到这些内容时会被诱导执行非预期操作。这不是理论问题任何开放知识库写入权限的 Agent 都面临这个风险。防御的核心是知识库写入的审核和检索结果的信任分级。不是所有检索到的内容都同等可信用户上传的文档、外部抓取的内容、内部审核过的文档应该有不同的信任级别。高信任级别的操作比如执行代码、发送请求只能基于高信任级别的知识触发。另外Agent 的记忆写入也要做校验防止通过对话诱导 Agent 记住恶意指令。注意如果你的 Agent 能执行写操作发邮件、改数据、调 API知识库投毒的后果可能是灾难性的。写入审核和操作确认这两道防线一道都不能省。4.4 LLM as Judge 在 Agent 评估中的实战用法“llm as judge”是评估 Agent 输出质量的常用手段但用不好会引入偏差。我做过一组对比实验同一个 Judge 模型prompt 里给评分标准和不给评分标准结果差异很大。不给标准时Judge 倾向于给高分给了明确的评分维度和示例一致性明显提升。实操建议是Judge prompt 里必须包含评分维度、每个维度的分值范围、以及正反示例。另外Judge 模型最好和被评估的模型不同避免自我偏好。如果条件允许用多个 Judge 模型投票取一致性高的结果。我一般会用两个不同厂商的模型做 Judge分歧大的样本人工复核这样既能控制成本又能保证评估质量。5. 工具链与生态那些容易被忽略的细节5.1 LLM 框架与本地部署的现实选择“llm框架”“llm studio”“ollama 简易本地 rag 知识库”这些词反映了本地部署的需求。Ollama 确实是本地跑模型最省心的方案一条命令拉模型API 兼容 OpenAI 格式接 RAG 很方便。但本地部署的坑在显存和量化。7B 模型 4bit 量化大概需要 6GB 显存13B 需要 10GB 左右再大就得考虑多卡或者 CPU 推理速度会明显下降。我的建议是本地部署先明确用途。如果是开发和测试7B 量化模型够用如果是生产要么上足够大的显存要么用 API。别指望本地小模型能达到云端大模型的效果差距是客观存在的。Ollama 适合快速验证和隐私敏感场景不适合对质量要求高的生产环境。5.2 基于 LLM 的单元测试能做什么不能做什么“基于llm的单元测试”这个方向我试过结论是LLM 适合生成测试用例的草稿不适合直接作为测试断言。让 LLM 根据函数签名和文档生成测试用例能覆盖不少边界情况但生成的断言经常有幻觉比如期望值写错。正确用法是 LLM 生成用例框架人工审核断言或者用 LLM 做模糊测试的输入生成断言还是用传统方式。另一个用法是用 LLM 做测试覆盖率分析找出哪些分支没被覆盖然后针对性生成用例。这个场景下 LLM 的价值在“理解代码意图”比纯静态分析工具更灵活。但同样需要人工确认不能全自动。5.3 常见报错与排查从 codex 沙盒到 provider 拒绝“codex无法发送消息显示更新agent沙盒”和“llm request failed: provider rejected the request schema or tool payload”这两个报错很典型。前者通常是沙盒环境更新导致的消息通道中断排查思路是检查沙盒状态、网络配置、以及是否有版本不匹配。后者一般是请求体不符合 provider 的 schema 要求常见原因是工具调用的参数格式不对或者消息角色顺序有问题。排查这类问题的通用方法是把实际发送的请求体完整打印出来对照 provider 的文档逐字段检查。我遇到过好几次是工具调用的 JSON schema 里 required 字段和实际传参不匹配provider 直接拒绝。还有一次是消息历史里出现了连续两条 user 消息某些 provider 不接受这种格式。打印请求体这个习惯能省掉大量猜测时间。报错现象常见原因排查方向provider rejected schema工具参数格式错误打印请求体对照文档沙盒更新后无法发送版本不匹配/通道中断检查沙盒状态和版本检索结果不相关chunk 切分/rerank 问题打印命中 chunkAgent 并发串上下文状态未隔离检查 context 管理工具调用超时连接池/超时配置检查工具层配置5.4 公开榜单的参考价值与局限“open llm leaderboard 等公开榜单”是选型时的重要参考但不能全信。榜单测的是通用能力你的场景可能是特定领域的问答、代码生成、或者结构化抽取榜单排名和实际表现经常不一致。我的做法是榜单用来缩小候选范围最终选型一定要用自己的场景数据做评测。哪怕只有几十条测试样本也比盲目信榜单靠谱。另外要注意榜单的时效性。模型迭代很快半年前的榜单排名可能已经过时。选型时优先看最近三个月的榜单同时关注模型的实际更新日志有些模型版本号没变但底层做了优化。6. 我在这条路上踩过的几个真实坑第一个坑是过早优化 RAG。项目初期就花大量时间调 chunk 大小、换 embedding 模型结果发现真正的问题是文档本身质量差很多文档是扫描件 OCR 出来的错字连篇。后来先做文档清洗效果提升比调参明显得多。教训是RAG 的上限由数据质量决定别在脏数据上雕花。第二个坑是 Agent 工具调用的错误处理。早期没做超时和重试一个外部 API 卡住整个 Agent 就挂在那里。后来加了超时和降级策略工具调用失败时 Agent 能继续用其他信息回答而不是直接报错。这个改动让线上可用性提升了一个档次。第三个坑是忽视 MCP 工具的权限校验。内部测试时为了方便MCP server 没做鉴权结果测试环境被误操作改了一批数据。虽然数据能恢复但教训很深。任何能执行写操作的工具权限校验和操作确认都不能省测试环境也一样。第四个坑是并发测试做得太晚。上线前才做压测发现状态串了紧急改架构。如果早期就用并发场景做测试这个问题能提前暴露。现在我的习惯是Agent 功能开发完第一件事就是跑并发测试哪怕只有 10 个并发也能发现大部分状态管理问题。这些坑说起来都不复杂但每一个都是实际踩过才知道疼。Agent 和 LLM 这条线理论上的东西网上很多真正值钱的是这些工程细节。希望这些经验能帮你少走点弯路。