1. 从一份日报说起Agent 与 LLM 技术生态的当下切面做 AI 应用开发的人最近一两年应该都有同感技术栈的迭代速度已经从“季度”压缩到了“周”。我自己的收藏夹里关于 Agent、LLM、RAG、GraphRAG、MCP 这几个方向的资料几乎每周都要重新整理一遍因为上周还在用的方案这周可能就有了更成熟的替代品。这份“Agent / LLM 技术精选日报”本质上就是我在长期跟踪这些方向时把碎片化的信息按主题沉淀下来的一种方式。它不是一个产品也不是一个框架而是一套持续更新的技术观察笔记服务于那些正在做 AI 应用落地、或者准备进入这个方向的开发者。如果你正在纠结“Agent 到底该怎么搭”“RAG 检索效果为什么总是不稳定”“MCP 协议值不值得投入时间学”那这份日报式的梳理应该能帮你省下不少翻文档和踩坑的时间。我会把 Agent 架构、LLM 工程化、RAG 与 GraphRAG 的取舍、MCP 协议的落地场景这几个核心板块拆开来讲每个板块都尽量给出可复现的思路和实际项目中的经验判断而不是停留在概念科普层面。需要先说明一点这个领域变化太快任何“最佳实践”都有时效性。我今天写下的这些判断是基于当前阶段主流方案和实际项目反馈得出的你在参考的时候一定要结合自己的业务场景做二次验证。下面进入正题。2. Agent 架构设计从“能跑”到“扛得住”的关键分水岭2.1 Agent 到底是什么和普通 LLM 调用差在哪很多人第一次接触 Agent 这个概念时容易把它和“带工具调用的 LLM”画等号。实际上这两者之间有本质区别。普通的 LLM 调用是一次性的你给一个 prompt模型返回一个结果流程结束。而 Agent 的核心在于自主决策循环——它会根据当前状态判断下一步该做什么调用什么工具拿到结果后继续判断直到任务完成或触发终止条件。我习惯用一个类比来解释普通 LLM 调用像是你问路人“最近的加油站怎么走”他给你指个方向就结束了而 Agent 像是你雇了一个司机他会自己看导航、判断路况、决定要不要绕路、油不够了主动去找加油站整个过程你只需要告诉他目的地。这个“自主循环”的能力才是 Agent 的真正价值所在。从工程实现角度看一个最小可用的 Agent 通常包含四个部分规划模块决定下一步动作、工具集可调用的外部能力、记忆模块短期上下文和长期知识、执行器实际调用工具并处理返回。这四个部分的组合方式直接决定了 Agent 的可靠性和上限。2.2 主流 Agent 架构的选型逻辑目前市面上常见的 Agent 架构大致可以分成三类我在不同项目里都用过各有适用场景。第一类是ReAct 风格的线性循环。它的逻辑很简单Thought → Action → Observation 循环直到任务完成。优点是实现简单、调试直观适合任务步骤不多、工具数量有限的场景。缺点是当任务复杂度上升时容易陷入死循环或者反复调用同一个工具。我早期做的一个客服问答 Agent 就是用这个架构处理单轮查询没问题但一旦用户问题涉及多步推理稳定性就明显下降。第二类是Plan-and-Execute 架构。它先让模型生成一个完整的执行计划然后逐步执行执行过程中可以根据结果调整后续步骤。这种架构适合步骤明确、可以提前规划的任务比如“帮我整理一份周报包含数据统计、图表生成和文字总结”。但它的弱点在于计划一旦生成如果中间某步失败整个计划可能需要重来容错成本较高。第三类是多 Agent 协作架构。把不同职责拆给不同的 Agent比如一个负责检索、一个负责推理、一个负责校验通过消息传递协作完成任务。这种架构在复杂任务上表现更好但工程复杂度也最高调试起来相当痛苦。我目前只在少数对准确性要求极高的场景下用这种方案比如涉及多源数据交叉验证的分析任务。架构类型适用场景优势主要风险ReAct 线性循环单轮查询、工具数量少实现简单、调试直观复杂任务易死循环Plan-and-Execute步骤明确、可提前规划执行路径清晰中途失败重来成本高多 Agent 协作多源验证、复杂分析准确率高、职责清晰工程复杂度高、调试难选型的时候我的经验是先从最简单的架构开始遇到瓶颈再升级。很多团队一上来就搞多 Agent 协作结果连基本的工具调用稳定性都没解决最后项目推进不下去。先把 ReAct 跑通把工具调用的错误处理、超时重试、结果校验做扎实再考虑更复杂的架构。2.3 Agent 自主容错可靠 AI 系统的工程实践“Agent 自主容错”这个词最近被提得很多本质上是因为大家发现 Agent 在真实环境里太容易出错了。工具调用失败、返回结果格式不对、模型幻觉导致错误决策这些问题在 demo 阶段可能不明显但一上生产环境就集中爆发。我在实际项目里总结了几条容错设计的经验。第一工具调用必须要有超时和重试机制。不要假设任何外部工具是永远可用的网络抖动、服务限流、返回超时都是常态。我的做法是给每个工具调用设置独立的超时时间超时后触发重试重试次数超过阈值就降级处理或者返回明确的错误信息给 Agent让它自己决定下一步。第二结果校验不能省。模型返回的工具调用参数经常有格式问题比如该传 JSON 的地方传了字符串该传数组的地方传了单个值。我通常会在工具执行前加一层参数校验校验不通过就把错误信息返回给模型让它重新生成。这个机制看起来简单但能挡掉相当一部分低级错误。第三要有全局的终止条件。Agent 循环最怕的就是停不下来。我会设置最大循环次数、最大 token 消耗、最大执行时间三个维度的限制任意一个触发就强制终止并返回当前已完成的部分结果。这个设计在早期救过我好几次避免了一次失控的 Agent 调用把整个月的 API 预算烧光。提示容错设计的原则是“假设一切都会出错”。工具会挂、模型会幻觉、网络会断把这些当成常态而不是异常你的 Agent 系统才能真正扛住生产环境的压力。3. LLM 工程化落地从模型选型到评测闭环3.1 LLM 选型的几个实际考量维度选模型这件事网上的对比文章很多但真正落到项目里考量的维度往往和 benchmark 排名关系不大。我自己的选型框架大概包含这几个方面任务匹配度、响应延迟、调用成本、上下文长度、以及可控性。任务匹配度是最容易被忽略的。有些模型在通用 benchmark 上分数很高但在你的具体任务上表现平平。我的做法是先用一批真实业务数据做小规模对比测试而不是只看公开榜单。比如做代码生成任务某些通用模型的表现可能不如专门优化过的代码模型做中文长文本理解也要看模型在中文语料上的实际表现。响应延迟和调用成本是生产环境绕不开的。流式输出能改善用户体验但首 token 延迟才是关键指标。成本方面除了显性的 API 费用还要考虑重试、校验、多轮调用带来的额外消耗。我一般会算一个“单次任务平均成本”而不是只看单次调用的价格。上下文长度这个维度很多人只看最大值但实际可用长度往往要打折扣。模型在超长上下文中的注意力衰减是普遍现象中间部分的信息容易被忽略。我的经验是如果任务需要处理长文档不要指望把整个文档塞进去就完事配合 RAG 做分段检索效果通常更好。3.2 LLM as Judge自动化评测的实践与边界“LLM as Judge”这个思路在评测环节越来越常见核心逻辑是用一个能力较强的模型去评判另一个模型的输出质量。它的优势很明显比人工评测快、比传统指标灵活能处理开放式生成任务的评估。但我在实际使用中发现LLM as Judge 有几个必须注意的边界。第一评判标准要足够具体。如果你只告诉评判模型“判断这个回答好不好”结果会非常不稳定。我的做法是把评分维度拆开比如准确性、完整性、格式规范性各占多少分每个维度给出明确的评分标准这样结果的一致性会好很多。第二位置偏差要处理。评判模型在对比两个回答时往往倾向于选择排在前面或者更长的那个。解决办法是交换顺序多评几次取平均结果。这个技巧在对比测试中特别有用。第三评判模型的能力上限决定了评测的上限。用一个较弱的模型去评判强模型的输出结果参考价值有限。我一般会选择比被测模型能力相当或更强的模型来做评判同时保留一部分人工抽检作为校准。评测方式成本一致性适用场景人工评测高高关键任务、校准基准LLM as Judge中中批量测试、迭代对比传统指标低高有标准答案的任务3.3 基于聊天记录精调 LLM 的实操要点用聊天记录精调模型是很多团队想做的事因为聊天记录里包含了大量真实的用户表达和业务知识。但这件事的坑比想象中多。首先是数据清洗。原始聊天记录里充斥着口语化表达、错别字、无关闲聊、甚至敏感信息。直接拿来训练模型会学到很多噪音。我的流程通常是先做敏感信息过滤再做质量筛选去掉过短、无意义的对话然后做格式统一最后人工抽检一批确认质量。其次是数据配比。精调数据不是越多越好质量比数量重要得多。我一般会控制精调数据在几千到几万条之间同时保留一部分通用数据混合训练避免模型在精调任务上过拟合而丢失通用能力。最后是评测闭环。精调完必须做对比评测看精调后的模型在目标任务上是否真的有提升同时检查通用能力有没有明显下降。这个环节很多人会跳过结果上线后才发现模型变得“偏科”了。注意精调数据的隐私合规是红线。使用聊天记录前必须确保已获得用户授权并做充分的脱敏处理。这个环节不要抱侥幸心理。4. RAG 与 GraphRAG检索增强的进阶之路4.1 RAG 的核心瓶颈到底在哪RAG 这个概念已经不新鲜了但真正做过 RAG 项目的人都知道它的瓶颈从来不在“能不能检索”而在“检索得准不准”。我见过太多 RAG 系统demo 阶段效果惊艳一上真实数据就拉胯。问题通常出在几个环节。切分策略是第一道坎。固定长度的切分方式简单但容易把完整的语义单元切碎。比如一份技术文档按 500 字切分可能把一个完整的操作步骤切成两半检索到一半的信息反而误导模型。我的做法是根据文档结构做语义切分标题、段落、列表作为切分边界同时保留一定的重叠区域。检索召回是第二道坎。向量检索擅长语义相似但对精确匹配、关键词匹配的支持较弱。用户问“MCP 协议怎么配置”向量检索可能召回一堆讲“协议”的泛泛内容而真正讲 MCP 配置的文档反而排在后面。解决办法是混合检索向量检索加关键词检索结果做融合排序。重排序是第三道坎。初步召回的结果往往有几十条直接塞给模型会超出上下文限制而且噪音太多。加一层重排序模型把最相关的几条挑出来效果提升非常明显。这个环节的投入产出比很高建议优先做。4.2 GraphRAG 适合什么样的场景GraphRAG 这两年被讨论得很多它的核心思路是把知识组织成图结构利用实体之间的关系来增强检索。相比传统 RAG 的“片段检索”GraphRAG 更擅长处理需要跨文档推理的问题。举个例子如果用户问“A 公司的创始人和 B 公司的投资人之间有什么关联”传统 RAG 可能分别检索到 A 公司和 B 公司的信息但很难把两者关联起来。而 GraphRAG 通过实体关系图可以沿着“创始人—投资—公司”这样的路径找到答案。但 GraphRAG 不是银弹。它的构建成本远高于传统 RAG需要做实体抽取、关系抽取、图构建、图查询等一系列工作。我的建议是只有当你的业务问题确实涉及大量跨文档、跨实体的推理时才考虑上 GraphRAG。如果只是简单的问答检索传统 RAG 加混合检索和重排序性价比高得多。维度传统 RAGGraphRAG构建成本低高检索方式向量/关键词图遍历向量擅长场景单点问答、文档检索跨文档推理、关系查询维护难度低高4.3 RAG 知识库能不能存图片这个问题被问到的频率很高。答案是可以但方式和你想象的可能不一样。RAG 知识库本身存储的是文本向量图片不能直接转成向量存储。常见的做法有两种。一种是图片转文本描述。用多模态模型给图片生成详细的文字描述把描述文本存入知识库。检索时匹配到描述再关联回原图。这种方式实现简单但描述的质量直接决定了检索效果对于信息密集的图表、流程图文字描述容易丢失细节。另一种是多模态向量检索。用支持图文统一向量的模型把图片和文本映射到同一个向量空间检索时可以直接用文本查图片或者用图片查图片。这种方式效果更好但技术门槛和成本都更高。我的经验是如果图片主要是配图、截图这类辅助信息用第一种方式就够了如果图片本身承载核心信息比如产品设计图、数据图表建议用第二种方式或者至少对图片做结构化标注把关键信息提取成文本。5. MCP 协议工具生态的标准化尝试5.1 MCP 是什么为什么值得关注MCP 全称是 Model Context Protocol简单说就是一套让 LLM 应用和外部工具、数据源之间标准化通信的协议。在 MCP 出现之前每个 Agent 框架都有自己的工具接入方式你为框架 A 写的工具换到框架 B 就得重写。MCP 试图解决的就是这个碎片化问题。它的核心价值在于解耦工具提供方只需要按照 MCP 标准实现一次任何支持 MCP 的客户端都能调用。这对生态建设意义很大就像 USB 接口统一了外设连接一样MCP 试图统一 LLM 和外部世界的连接方式。我实际用下来的感受是MCP 在简单工具接入上确实方便配置好之后基本不用写胶水代码。但在复杂场景下比如需要流式输出、需要处理大文件、需要精细的权限控制时MCP 目前的规范还在完善中有些地方需要自己扩展。5.2 MCP 的典型应用场景从我看到的使用案例来看MCP 目前主要落地在几个方向。开发工具集成是其中一个热门方向。比如把代码编辑器、调试工具、数据库客户端通过 MCP 接入 AI 助手让 AI 能直接操作这些工具。我试过用 MCP 把数据库查询工具接入 Agent效果不错Agent 可以自己写 SQL、执行查询、分析结果整个流程很顺畅。办公自动化是另一个方向。把文档处理、表格操作、邮件发送这些能力封装成 MCP 工具Agent 就能自动完成一些重复性的办公任务。这个方向的想象空间很大但实际落地时要注意权限控制避免 Agent 误操作造成损失。知识管理方面把笔记系统、知识库通过 MCP 接入让 AI 能直接读写笔记内容。我自己的笔记系统就接入了 MCP现在可以让 AI 帮我整理笔记、生成摘要、建立关联效率提升明显。5.3 MCP 工具流式输出的实现思路流式输出是 MCP 使用中的一个常见需求尤其是当工具执行时间较长时用户需要看到实时进度。MCP 协议本身对流式输出的支持还在演进中目前的实现方式通常是在工具层面做文章。一种做法是把长任务拆成多个短任务每个短任务完成后返回一次结果客户端轮询获取进度。这种方式实现简单但实时性一般。另一种做法是在 MCP 传输层使用支持流式的协议比如基于 SSE 或者 WebSocket 的传输方式工具执行过程中持续推送进度事件。这种方式实时性好但对客户端和服务端的实现都有要求。我在实际项目里用的是第一种方式因为改动最小兼容性最好。具体做法是给工具加一个进度查询接口Agent 在执行长任务时定期查询进度并反馈给用户。虽然不如真正的流式优雅但胜在稳定可靠。提示MCP 生态还在快速变化建议关注官方规范更新同时在实际项目中做好抽象层避免和具体实现绑得太死。6. 常见问题与排查技巧实录6.1 Agent 开发中的高频问题速查在实际开发中有些问题反复出现我整理了一个速查表方便快速定位。问题现象可能原因排查方向Agent 陷入死循环终止条件缺失或过松检查最大循环次数、超时设置工具调用参数格式错误模型输出不稳定加参数校验层错误回传重试检索结果不相关切分策略或检索方式问题调整切分粒度加混合检索响应延迟高模型选型或调用链过长检查首 token 延迟优化调用链精调后通用能力下降数据配比失衡调整精调数据比例混合通用数据6.2 几个容易踩的坑第一个坑是过度依赖模型能力。很多问题其实用工程手段解决更可靠比如格式校验、结果过滤、规则兜底。不要指望模型能处理所有边界情况该写代码的地方就写代码。第二个坑是忽略成本监控。Agent 的多轮调用很容易让成本失控尤其是当循环没有正确终止时。我建议在项目早期就加上 token 消耗监控和预算告警避免月底看到账单时才发现问题。第三个坑是评测环节偷懒。没有评测就没有迭代方向。哪怕先做一个简单的人工抽检流程也比完全凭感觉调优强。评测数据要持续积累形成回归测试集每次改动都跑一遍确保没有引入退化。第四个坑是忽视安全边界。Agent 能调用工具意味着它能产生实际影响比如发邮件、改数据、执行命令。权限控制、操作审计、敏感操作二次确认这些机制在早期就要设计进去不要等出了问题再补。6.3 性能优化的几个实用技巧Agent 系统的性能优化我总结下来主要是三个方向减少不必要的调用、并行化可并行的步骤、缓存可复用的结果。减少调用方面可以在 prompt 里明确告诉模型哪些情况下不需要调用工具直接回答即可。很多模型有“过度调用工具”的倾向明明自己知道答案还要去查一下白白增加延迟和成本。并行化方面如果多个工具调用之间没有依赖关系可以并行发起。比如同时查询多个数据源最后汇总结果。这个优化在数据聚合类任务上效果很明显。缓存方面对于频繁查询且结果变化不大的内容可以加一层缓存。比如知识库检索结果、工具调用结果在一定时间内可以复用。缓存策略要根据业务特点设计避免返回过期数据。7. 一些个人体会和后续方向做 Agent 和 LLM 应用这段时间最大的感受是这个领域没有“一劳永逸”的方案。今天调好的系统明天可能因为模型更新、工具变更、数据变化就需要重新调整。所以与其追求一个完美的架构不如建立一套快速迭代和验证的流程。我自己的做法是保持小步快跑每次只改一个变量改完立刻用评测集验证确认有效再继续。这样虽然看起来慢但避免了大规模重构带来的风险。另外就是多和同行交流很多坑别人已经踩过了一份日报、一次讨论可能就帮你省下几天的调试时间。后续我还会继续关注 MCP 生态的演进、GraphRAG 在垂直领域的落地案例以及 Agent 安全方面的实践。这些方向都还在快速变化有新的经验我会继续整理分享。如果你也在做类似的事情欢迎交流互相少踩点坑。
