1. 从一份日报的选题逻辑说起为什么这几个词值得盯做 Agent 和 LLM 方向的人大概都有同感信息密度太高高到每天刷完一圈时间线脑子里剩下的往往只有几个模糊的名词具体谁解决了什么问题、哪条路线正在被验证、哪些坑已经被踩过全糊成一团。所以当我看到Agent / LLM 技术精选日报这种形态时第一反应不是又一个资讯聚合而是它背后那套选题逻辑——把 Agent、LLM、RAG、GraphRAG、MCP 这几个词放在同一天里并列本身就说明它们已经构成了当前一条完整的技术链路而不是五个孤立的热点。这条链路大致是这样的LLM 是底座能力负责理解和生成Agent 是在底座之上加了一层感知—决策—行动的循环让它能自己调用工具、自己推进任务RAG 解决的是底座知识陈旧和幻觉的问题把外部知识在推理时喂进去GraphRAG 是 RAG 在关系密集型场景下的进化形态用图结构去补向量检索抓不住的多跳关系MCP 则是把上面这些能力标准化地接进各种宿主环境的协议层。你把这五个词串起来看会发现它们分别对应了模型能力、执行框架、知识注入、知识组织、接入标准五个层次缺一环整个系统就跑不顺。这也是为什么这份日报值得单独拆一篇来聊。它表面上是一堆热词的罗列实际上每个词背后都对应着一批正在真实推进的项目、一批正在被反复讨论的工程问题。比如RAG 知识库能存储图片嘛这种看起来很小白的问题背后其实是多模态检索的工程落地AI Agent 怎么扛并发背后是状态管理和资源调度harness 和 agent 区别背后是评测范式和产品形态的边界之争。我打算按这条链路的层次把每个环节里最值得关注的技术点、最容易踩的坑、以及可以直接上手的做法一条条摊开讲清楚。不管你是刚接触这块、还在搞明白agent 到底是什么的阶段还是已经在做 RAG 实战、被检索瓶颈卡住的工程同学下面这些内容应该都能对上你的某个具体问题。我不打算写成名词解释而是尽量按这个技术点解决什么问题、怎么落地、哪里会翻车的顺序来讲能抄的配置和步骤我会直接给出来。2. LLM 底座从 token 三要素到评测榜单的取舍2.1 token 的三个点key、query、value 的直觉理解热词里有一条特别有意思——llm 的 token 三个点 key 我是谁、query 我在找什么、value 我能提供什么。这个说法其实是用注意力机制里的 Q/K/V 来类比 token 在语义空间里的角色虽然严格来说 Q/K/V 是每个 token 在每一层都会投影出来的三组向量不是三个固定的点但这个类比对理解注意力在干什么非常有用。你可以这样想一句话里每个 token 都同时扮演三个身份。作为 key它在说我是谁、我代表什么概念作为 query它在说我现在想找什么信息来补全我自己作为 value它在说如果别人选中了我我能贡献什么内容。注意力计算的过程就是每个 token 拿自己的 query 去和所有 token 的 key 做匹配匹配度高的那些 token 的 value 会被加权求和汇入当前 token 的表示里。这个直觉为什么重要因为它直接解释了 RAG 里一个常见困惑为什么有时候检索回来的文档明明关键词都对上了模型却用不好。因为向量检索匹配的是语义相似度相当于只对了 key 这一层但模型真正需要的是这段内容和当前 query 的意图是否互补——也就是 query 和 value 的匹配。这就引出了后面要讲的 RAG 瓶颈问题单纯堆相似度是不够的得让检索结果在信息互补性上过关。2.2 评测榜单怎么读才不被带偏open llm leaderboard 等公开榜单这类词经常出现在选型讨论里。我的经验是榜单能看但只能当粗筛不能当决策依据。原因很实在——榜单任务大多是静态的、单轮的、有标准答案的而真实业务里的 LLM 调用往往是多轮的、带工具调用的、答案开放且需要格式约束的。一个在榜单上排前几的模型放到你的 Agent 流程里可能因为函数调用格式不稳定而频繁失败。读榜单我一般看三件事。第一看任务类型和你场景的重合度数学推理强不代表指令遵循强代码强不代表长上下文稳定。第二看评测方式是 zero-shot 还是 few-shot是精确匹配还是模型打分不同方式出来的分数不可直接横比。第三看版本和日期模型迭代太快半年前的榜单结论基本可以作废。真正靠谱的做法是自己搭一个小而狠的评测集二三十条覆盖你核心场景的 case用 LLM as judge 加上人工抽检跑出来的结论比任何公开榜单都贴合你的需求。2.3 LLM as judge 的边界与实操说到 LLM as judge热词里也单独列了。这东西好用但容易用歪。它的核心价值是在没有标准答案的场景下提供一个可扩展的打分器比如评估摘要质量、回答相关性、格式合规性。但它有几个必须知道的偏差位置偏差倾向于选第一个或最后一个选项、长度偏差倾向于给长回答高分、自我偏好倾向于给自己或同族模型的输出高分。实操上我一般这么处理打分时把候选顺序随机打乱跑两遍取平均抵消位置偏差评分标准里明确写简洁性也是加分项压制长度偏差judge 模型尽量选和被测模型不同族的减少自我偏好。还有一个细节judge 的 prompt 里一定要给评分 rubric 和几个锚点示例否则分数会飘。我试过同一批数据rubric 写清楚和写模糊打分一致性差出一大截。3. Agent 这一层架构、并发与安全的真实战场3.1 agent 到底是什么和 harness 差在哪agent 是什么和harness 和 agent 区别这两个词放在一起看说明很多人卡在概念边界上。我的理解是Agent 是一个能自主循环的系统它接收目标自己决定下一步做什么、调什么工具、什么时候停。它的核心特征是决策权在模型手里。而 harness 更像是给模型套的一个执行外壳或测试夹具它规定了模型能做什么、怎么被调用、输出怎么被解析但决策流程往往是预设的、固定的。打个比方Agent 像是一个能自己规划路线的司机harness 像是驾校的考试路线——路线是定死的考的是你在既定流程里的表现。所以你会看到 harness 大量出现在评测和红队测试场景里因为它需要可复现、可控而 Agent 出现在产品场景里因为它需要应对开放任务。两者不是替代关系很多时候一个成熟的 Agent 系统内部就包含多个 harness 式的子流程用来约束高风险动作。理解这个区别的实际意义在于当你要评测一个 Agent 时你不能只测单步输出得测它的整条决策轨迹而当你调试一个 harness 时你关注的是单点行为的稳定性和边界。搞混了就会用错工具比如拿单轮评测去衡量一个多步 Agent结论必然失真。3.2 Agent 扛并发状态、资源与幂等三件事AI Agent 怎么扛并发是个特别工程化的问题也是从 demo 走向生产必须迈过的坎。Agent 和普通 API 最大的不同是它是有状态的、多步的、耗时的。一个请求可能要跑十几步工具调用中间还涉及外部 API、数据库、文件系统。并发一上来问题就集中爆发。第一件事是状态管理。Agent 的会话状态不能放在进程内存里否则多实例部署就乱套。常见做法是把状态外置到 Redis 或数据库每一步的中间结果都持久化这样即使某个实例挂了任务也能被另一个实例接管继续跑。我踩过的坑是早期图省事把状态放内存单机测试没问题一上多副本就出现任务跑到一半丢失的诡异现象排查了半天才定位到是负载均衡把后续请求打到了另一个实例。第二件事是资源隔离。Agent 会调用各种工具有的工具慢、有的工具会失败重试、有的工具吃内存。如果不做隔离一个慢工具能把整个线程池拖垮。我的做法是给不同类型的工具配独立的并发池和超时慢工具单独限流避免它拖累快路径。第三件事是幂等。Agent 重试是常态但工具调用往往有副作用——发消息、写数据库、下单。如果重试不幂等就会出现重复操作。解决办法是给每个工具调用生成一个幂等键服务端根据键去重。这个键一般用会话 ID 步骤序号 工具名组合生成简单可靠。3.3 Agent 安全从 AgentPoison 看记忆投毒agentpoison: red-teaming llm agents via poisoning memory or knowledge base这个词点出了一个容易被忽视的攻击面Agent 的记忆和知识库是可以被投毒的。传统安全关注的是输入层的 prompt 注入但 Agent 因为有长期记忆和外部知识库攻击者可以通过污染这些持久化数据让 Agent 在未来的某次决策里做出错误甚至危险的动作。这个攻击的可怕之处在于它的延迟性和隐蔽性。投毒发生在写入阶段触发可能在几天后的某个不相关任务里中间没有任何异常信号。防御上我总结了几条一是记忆写入要做来源校验不是所有内容都值得进长期记忆二是敏感操作前要有独立的确认环节不能完全信任记忆里的指令三是定期审计记忆库对异常写入做告警。这些做法会增加一些工程成本但对于任何要长期运行的 Agent 系统这笔投入是必要的。4. RAG 与 GraphRAG检索瓶颈到底卡在哪4.1 RAG 知识库能不能存图片以及多模态检索的现实做法rag 知识库能存储图片嘛这个问题问得很实在。答案是能但要看你怎么定义存和检索。最朴素的做法是把图片的文本描述caption存进向量库检索时匹配描述文本命中后返回原图。这种做法实现简单但依赖 caption 的质量图里的细节信息容易丢。进阶做法是用多模态 embedding 模型把图片和文本映射到同一个向量空间这样可以用文本 query 直接检索图片也可以用图片检索图片。工程上要注意的是多模态向量的维度和距离度量跟纯文本不一样别混用同一个索引。还有一种混合方案是把图片 OCR 出的文字、caption、以及图片本身的向量都存进去检索时多路召回再融合召回率会明显好于单路。我实际做过的项目里纯图片检索的需求其实不多更多是图文混排的文档检索。这种场景下把文档按版面切块每块保留文字和对应的图片引用检索命中块之后把图文一起返回给模型效果比单独处理图片好得多。因为模型看到的是完整的上下文而不是一张孤立的图。4.2 RAG 瓶颈的四个典型位置rag 瓶颈这个词能上热词说明踩坑的人多。我把常见的瓶颈归到四个位置。第一个是切块块切得太大检索精度下降噪声多切得太小语义不完整模型拿到碎片拼不出完整意思。我的经验是块大小要跟着文档结构走有标题层级就按层级切没有就按语义段落切别机械地按固定字数切。第二个是 embedding 质量。很多团队直接用通用 embedding 模型但垂直领域的术语和表达它未必理解得好。这时候要么换领域适配的模型要么在检索前做 query 改写把用户的口语化问题改写成更接近文档表述的形式。第三个是召回与重排的配合。单靠向量召回top-k 里经常混进语义相似但实际无关的内容。加一层重排模型cross-encoder 类能显著提升精度代价是延迟增加。我的做法是召回阶段多召回一些比如 top-50重排后取 top-5 给模型精度和延迟能取得不错的平衡。第四个是上下文组织。检索回来的内容怎么塞进 prompt 也有讲究。顺序、分隔、以及是否附带来源信息都会影响模型的使用效果。我一般会把最相关的放最前面和最后面中间放次相关的利用模型对首尾位置更敏感的特性。4.3 GraphRAG 与 ontology rag什么时候图结构真的有用graphrag和ontology rag这两个词经常一起出现它们解决的是同一类问题当答案需要跨多个文档、多个实体做多跳推理时纯向量检索力不从心。比如问某公司的某个产品线在某个地区的负责人是谁答案可能分散在三份文档里向量检索只能召回其中一两份拼不出完整链路。GraphRAG 的思路是先用工具体系把文档里的实体和关系抽出来建成知识图谱检索时沿着图的关系边走边找。它的优势在多跳和全局性问题上很明显但代价也不小建图需要额外的抽取和消歧工作图的质量直接决定效果而且维护成本比向量库高。我的判断标准是这样的如果你的问题大多是某段内容讲了什么这种单跳事实型向量 RAG 足够如果问题经常是这些实体之间是什么关系整体趋势如何这种需要聚合和推理的才值得上图。别为了追新而强行上 GraphRAG建图那套流程的复杂度会让你怀疑人生。ontology rag 更进一步它要求你先定义好领域本体抽取时按本体约束来好处是图结构规范、可推理坏处是本体设计本身就很费功夫适合领域边界清晰、长期维护的场景。4.4 零基础本地 RAG 的最小可行路径ollama 简易本地 rag 知识库【零基础可复制教程】和langchain4j easy rag这两个词说明很多人想先跑通一个最小闭环。我给一条我验证过的路径用 Ollama 拉一个本地模型做生成用它的 embedding 接口做向量化向量库选轻量的比如内存版或本地文件版文档加载和切块用现成框架。整个链路不依赖外部服务跑通之后再逐步替换组件。关键步骤上切块参数我一般从 500 字、重叠 50 字起步然后根据实际召回效果调。检索 top-k 从 3 开始试看模型回答是否够用。prompt 模板里明确要求只根据提供的资料回答资料里没有就说不知道这一句能挡掉大量幻觉。跑通之后你会发现真正花时间的不是搭链路而是调切块和检索参数这部分没有捷径只能拿你的真实数据反复试。5. MCP 与工具接入协议层正在发生的事5.1 mcp 是什么为什么它突然到处都是mcp 是什么和mcp 协议高频出现说明这个协议正在成为工具接入的事实标准。简单说MCP 定义了一套模型和外部工具、数据源之间通信的规范让工具提供方和模型调用方解耦。以前每接一个工具都要写一套适配代码现在工具方按 MCP 实现一个 server任何支持 MCP 的宿主都能直接调用。它的价值在于生态效应。当大家都按同一个协议实现工具就能复用宿主就能快速扩展能力。这也是为什么你会看到ruoyi-vue-pro 合并 mcp 功能codex 接入 figma mcpx32dbg 的 mcp 插件cheat engine 桥接 mcp 教程这类词——不同领域的工具都在往这个协议上靠。它把给模型接工具这件事从定制开发变成了配置组装。5.2 接入 MCP 时最容易卡住的授权环节codex 接入 figma mcp 怎么授权这个问题特别典型。MCP 的授权模型是接入时最容易翻车的地方因为它涉及宿主、MCP server、以及被访问的第三方服务三方之间的凭证传递。常见的坑有这么几个一是 token 的作用域没配对导致 server 能连上但访问不了具体资源二是回调地址配置错误授权流程走一半断掉三是凭证过期没有刷新机制跑一段时间就失效。排查这类问题的顺序我一般是先确认 server 本身能不能独立跑通不经过宿主直接调能跑通说明凭证和网络没问题问题在宿主侧的配置再检查宿主的 MCP 配置里环境变量和参数有没有正确传入最后看授权回调的日志定位是哪个环节断的。这个顺序能帮你快速缩小范围避免在错误的方向上瞎试。5.3 从 ruoyi-vue-pro 合并 MCP 看企业系统的接入模式ruoyi-vue-pro 合并 mcp 功能这个案例值得单独说因为它代表了一类典型需求把已有的企业系统能力通过 MCP 暴露给模型。这类系统的特点是接口多、权限复杂、有审计要求。直接暴露原始接口是不行的得做一层封装。我的做法是先梳理出哪些能力适合给模型用读多写少、幂等、低风险的优先然后为这些能力设计 MCP 工具描述描述里把参数约束和返回格式写清楚最后在封装层做权限校验和审计日志。写操作一定要加确认机制不能让模型直接改数据。这套模式跑下来企业系统接入模型的门槛会低很多而且风险可控。6. 框架选型与工程实践中的几个真问题6.1 agent 框架怎么选别被 star 数带跑agent 框架llm 框架rag 框架这几个词背后是选型焦虑。我的建议是先明确你要什么是要一个开箱即用的编排框架还是要一套可深度定制的底层库。编排框架上手快但遇到非标准需求时容易被框架的设计绑住底层库灵活但什么都要自己搭。选型时我会重点看三件事一是状态管理是否外置友好能不能接你自己的存储二是工具调用的抽象是否清晰加一个新工具要改多少代码三是可观测性能不能看到每一步的输入输出和耗时。第三点经常被忽略但生产环境出问题时没有可观测性基本等于盲人摸象。star 数只能说明热度说明不了它适不适合你的场景。6.2 用聊天记录精调 LLM 的可行性与陷阱使用聊天记录模型精调 llm这个方向很多人感兴趣因为聊天记录是现成的、带场景的语料。但直接拿来精调有几个陷阱。第一是数据质量聊天记录里大量噪声、口语、错别字不清洗直接训会污染模型。第二是隐私聊天记录里可能含敏感信息必须做脱敏。第三是目标错位聊天记录是人怎么说话但你可能想要的是模型怎么回答两者分布不一样。我的做法是先把聊天记录转成指令-回答对只保留有明确问答结构的片段然后人工抽检一批确认质量再考虑精调。精调的目标通常是风格对齐或领域术语适配而不是灌知识——灌知识用 RAG 更合适成本低且可更新。这个区分很重要很多人拿精调去干 RAG 的活结果又贵又不好维护。6.3 基于 LLM 的单元测试能做什么不能做什么基于 llm 的单元测试是个有意思的方向。LLM 在生成测试用例、补充边界条件、解释失败原因上确实能帮上忙。但它不能替代传统单元测试因为它的输出不确定同一个函数跑两次可能生成不同的测试这在 CI 里是灾难。我的用法是让 LLM 做测试用例的初稿生成和覆盖率盲区提示生成的结果由人审核后固化成确定性的测试代码。这样既利用了 LLM 的广度又保证了测试的稳定性。另外用 LLM 去判断这个测试失败是不是真 bug也有价值能减少误报带来的排查成本但同样需要人做最终判断。7. 把这些串起来一条可落地的技术路线把上面这些点串成一条路线大概是这样的底座选一个指令遵循稳定的 LLM别只看榜单知识层先用向量 RAG 跑通遇到多跳和聚合问题再考虑 GraphRAG工具接入统一走 MCP把授权和权限封装好Agent 层把状态外置、资源隔离、幂等这三件事做扎实再谈并发安全和评测贯穿始终记忆要审计效果要自建评测集。这条路线里没有哪个环节是上了就一劳永逸的每个环节都需要根据你的真实数据和场景反复调。我自己踩过的最大的坑就是早期总想找一个完美框架把所有问题一次解决结果在选型上耗了大量时间真正跑起来才发现瓶颈全在数据和参数上。后来我改成先用最小闭环跑通再哪里疼治哪里效率反而高得多。最后分享一个我一直在用的小习惯每接一个新工具或新模型先写一个最小验证脚本只测它最核心的那个能力跑通了再往系统里集成。这个习惯帮我挡掉了不少文档看着很美、实际用起来一堆坑的组件。技术更新快但先验证再集成这条原则什么时候都不过时。