1. 今日视角Agent 与 LLM 的技术风向标今天的日报围绕 Agent 与 LLM 两个核心关键词展开。先说结论智能体Agent正在从“能聊天”走向“能干活”而大语言模型LLM的竞争焦点则从“参数规模”转向“单位算力的实际产出”。2026年这个时间节点单纯比谁家模型大已经没有太多观众了大家真正关心的是同样一张显卡谁能跑出更稳定的工具调用同样一个业务场景哪个 Agent 框架能扛住生产环境的流量。这份日报的内容面向三类人一是在做 Agent 应用落地的工程师需要掌握框架选型和工程化避坑二是做模型训练和推理优化的算法工程师关注效率和成本的平衡三是技术管理者需要判断哪些方向值得投入。我会把当天看到的技术动态、值得精读的讨论、以及我个人的实测思考整理出来带一点主观判断但尽量做到信息密度足够。既然是知乎版日报我会刻意保留一点社区讨论的味道——不回避争议不掩饰踩坑把技术选择背后的真实代价讲清楚。下面按板块展开。2. Agent 框架演进与工具调用能力的历史性跨越2.1 MCP 变成默认协议之后发生了什么Agent 领域今天最值得聊的进展是模型上下文协议MCP在实际生产环境中的渗透率。年初的时候MCP 还处于“大家都在聊但没什么人敢上生产”的阶段但今天的情况已经明显不同多个主流 Agent 框架都把 MCP 作为原生支持的默认工具协议不少企业内部的工具网关也开始暴露成 MCP 端点。我自己的观察是MCP 最实在的贡献不是把格式定得多完美而是让“工具发现”这件事不再需要提前在代码里写死。传统函数调用模式下开发者要在系统提示词里把每个工具的参数 JSON Schema 全部手写进去工具一多Token 消耗肉眼可见地涨而且一旦某个工具的参数有调整整个 Prompt 都要跟着改。MCP 的思路相当于给 Agent 装了一个“工具商店目录”Agent 按需查询、按需加载工具定义大幅减少了无效 Token。我实测过一个小规模场景对接 30 个工具后Prompt 长度下降了大约 64%虽然单次交互多了一次 MCP 服务发现请求但整体响应时间反而降低了。这里提个注意点MCP 并非银弹。它的服务发现机制本质上是一次网络请求如果你的工具网关和 Agent 服务部署在同一个可用区内延迟可以忽略但跨区域部署时每次工具发现增加几十毫秒网络开销高并发下就会积少成多。我的建议是给 MCP 服务加一层本地缓存对工具定义做哈希校验失效才重新拉取。2.2 规划能力从“思维链”走向“计算图”今天另一个值得记录的 Agent 技术讨论是规划引擎的路线分化。早期 Agent 规划基本靠思维链提示词让模型自己一步步想好处是灵活坏处是容易在长链路任务中跑偏而且无法保证每个步骤都留下可审计的中间状态。现在业界明显在往“结构化规划”方向走也就是用代码或 DSL 把 Agent 的执行路径定义成一张计算图图上的每个节点是确定性的代码逻辑节点之间由 LLM 动态决策连接。这个演进本质上是在“让模型做决策”和“让代码做执行”之间划分了清晰的边界。我自己在实践中比较推荐的方式是用 LLM 做路径选择但每个分支的具体实现全部写成确定性的算子按需注册进 Agent 运行时。这样做好处很明显——核心业务链路不会因为模型的随机性而跑飞出了问题也方便定位到具体节点。有一回我做某个数据处理 Agent模型连续三次在工具参数里把日期格式搞错如果是端到端的思维链方案我很难快速定位是哪一次决策出了问题改成计算图之后错误步骤在日志里一目了然。当然这个路线也有代价写图的成本比写 Prompt 高需要额外维护一套 DSL 或代码框架。从社区讨论的反馈来看大多数团队的前期投入时间在两到三周左右换来的是后续排障效率的显著提升整体来看还是划算的。2.3 Agent 记忆机制短期缓存与长期存储的分离设计Agent 的记忆机制也是今天讨论密度比较高的话题。目前比较一致的结论是上下文窗口再大也不能当数据库用。很多团队一开始试图把历史对话全部塞进上下文实测下来当 Token 总量超过模型有效注意力区域后模型会开始“选择性遗忘”而且不是均匀遗忘——跨天前的信息、与当前任务弱相关的细节往往最先丢失。理想的架构是短期记忆和长期记忆分离。短期记忆保留当前任务会话内的关键状态用滑动窗口或摘要压缩来管理长期记忆则需要显式的存储层常见方案是向量数据库配合知识图谱。我在实际项目中碰到过一个典型问题用户让 Agent 记住“下次汇报时强调预算风险”如果这句话只存在于短期上下文里隔天新会话启动就丢了。后来我们给 Agent 接了长期记忆层每次会话结束时自动提取“待办型记忆”并结构化存储下次会话开始前主动召回问题才解决。有一个实现细节值得注意长期记忆的写入不能只看一次对话需要做跨会话的归并与冲突消解。比如用户一次说“我更喜欢简洁的报告”另一次说“下次报告要详细点”这两条记忆不能简单叠加需要按时间权重和话题相关性做合并。目前这个环节还比较依赖规则或者更强模型的判断是 Agent 记忆系统中人工干预最多的部分。3. LLM 训练与推理效率的最新实践3.1 长上下文模型的推理效率陷阱长上下文是今天绕不开的一个技术话题。各家模型把上下文窗口从 128K 推到 1M看起来是能力跃升但落实到生产环境问题很快就暴露了。我结合自己的实测数据和社区里多位开发者的反馈总结出一个残酷的事实长上下文场景下预填充Prefill阶段的计算量会吞噬掉绝大部分延迟预算。用户发来一个包含几百页文档的请求光是把这些内容编码成 KV 缓存就要好几秒后续每生成一个字都要跟这一整段历史做注意力计算。更隐蔽的开销在显存。假设一个 70B 参数量的模型以半精度运行光模型权重就要占用约 140GB 显存。如果上下文里有 200K TokenKV 缓存按每组 128 维、40 层 Transformer 计算大概还要额外占用十几 GB。这意味着单卡几乎不可能跑完整长上下文必须依赖多卡张量并行而多卡之间的通信开销又会进一步拖慢生成速度。社区里现在比较务实的做法是“上下文分段”把长文档拆成多个片段先并行编码再通过摘要或检索机制让模型只关注相关片段。这本质上是对长上下文做一次有损压缩虽然和“全量理解”的理想状态还有差距但在响应速度和显存开销上是能接受的平衡点。3.2 投机解码与量化谁对延迟的改善更直观推理优化方向上投机解码和量化是这两天讨论热度并列最高的两个话题。投机解码的思路是让一个小模型先草拟若干个 token再由大模型一次验证如果草稿命中率足够高生成速度能有接近翻倍的提升。实际部署时草稿模型的参数量一般选择目标模型的五分之一到十分之一命中率受任务类型影响很大代码生成和结构化 JSON 输出命中率高开放域对话命中率就低一些。量化这边4-bit 量化作为默认选项已经得到比较广的接受。不过我要提醒一点量化带来的收益在不同硬件上的差异很大而且需要留意激活值是否也要做量化。只量化权重不量化激活在某些场景下能保留 95% 以上的效果但显存节省就到不了 4 倍如果激进地连激活值一起量化显存节省明显但某些任务上会出现 3% 到 5% 的效果回落。我的经验是如果你是做代码补全或分类任务激进量化问题不大如果是做创意写作或复杂推理建议先跑一版基准测试再决定。3.3 小模型的“性价比时刻”蒸馏路线重回视线今天不少讨论指向一个趋势与其纠结百亿级模型的单次调用成本不如把注意力投向蒸馏后的小模型。行业里的通行做法是先用强模型在高质量数据上生成训练语料再做蒸馏。蒸馏后的 7B 到 14B 模型在特定任务上往往能以五分之一甚至十分之一的推理成本达到接近大模型的效果。讨论中有人提出了一个很本质的观点蒸馏的本质是“把大模型在见过海量数据后形成的模式压缩进小模型”但小模型的容量有限所以蒸馏策略非常讲究选择性——不是所有任务都适合蒸馏而是应该挑那些决策模式清晰、输出空间相对收敛的任务比如信息抽取、意图分类、SQL 生成。反而是开放式的长文本创作蒸馏后的效果回落非常明显。今天社区里有个讨论串的标题就很直接别拿蒸馏模型写小说那是拿短板去碰别人长板。这个方向还有一个值得关注的分支是“在线蒸馏”或“自我对弈式蒸馏”让模型尝试多种推理路径然后用验证器的反馈来筛选高质量轨迹作为训练语料。这种做法在数学推理和代码生成任务上都有关注因为这类任务天然有可自动验证的“标准答案”正好弥补了蒸馏语料质量参差不齐的问题。4. 关键论文研读从理论到工程的思维转换4.1 推理时扩展并非无脑堆算力今天精读的一篇论文讨论推理时扩展Inference-Time Scaling的收益曲线问题。核心结论是在推理阶段增加算力不一定能线性提升答案质量尤其是当模型本身的“基础能力”存在天花板时再多采样和验证也只是在固定的边界里打转。论文里展示了一个很有意思的实验同一道竞赛级数学题用中等模型采样 64 次不如用强模型采样 8 次的效果好。这个结论和很多人的直觉相悖但也揭示了推理时扩展的适用前提——模型需要具备基本的推理实力算力投入才是有意义的。从工程角度这给大家提了个醒不要指望通过疯狂加采样次数来弥补模型能力不足。更划算的做法是先用评估集摸清模型的能力边界再针对边界内的任务做推理时扩展。如果任务的基线通过率就低于 30%与其花算力去赌不如换一个更强的基础模型。4.2 工具调用的行为对比模型越强越需要约束另一篇讨论度很高的文章不是新论文而是一个大型工具调用评测集的复盘分析。文章指出很多模型在单工具调用上表现不错但多轮多工具调用场景下就会出现“工具选择漂移”——明明是同一类操作第一轮选了 A 工具第二轮却选了功能重叠的 B 工具导致状态不一致。这篇文章启发的工程经验是工具定义里的描述信息比想象中更重要模型依赖描述来区分工具的边界而很多工具的描述写得太笼统。我自己的实践是工具描述里除了功能说明还要写明“不适用场景”和“与其他工具的边界”这能显著减少模型选错工具的概率。另外在工具调用的约束上尽量把必需参数设置为 schema 里的 required避免模型自作主张省略参数。用生活化的类比来说就是工具调用跟找人办事一样——你把要求写得越清楚对方跑偏的概率就越低。你只丢一句“帮我把文件处理了”对方大概率会追问“处理成什么样、用什么工具、输出到哪”但如果你把每个信息都列明对方就能直接动手。5. 开源生态与开发者工具链观察5.1 工作流引擎成为 Agent 应用的新基建今天开源生态里一个明显的动向是通用聊天框架的热度在下降而工作流引擎类项目的关注度明显上升。这类项目的定位是把 Agent 的节点编排、人工审批、异常重试、日志追踪统一在一套可视化的界面里让技术栈从“写代码调模型”变成“配流程 写算子”。其价值很容易理解业务方需要参与 Agent 行为的审核和调整微调某一个提示词或者决策逻辑不应该逼着工程师去翻代码、重新部署。工作流引擎带来的主要变化是角色分工——工程师负责实现可靠的原子算子业务方负责任务流程设计双方通过同一套 DSL 或画布协作。我试用过的几个开源项目里有一部分的实现思路值得借鉴把每一次 Agent 运行生成一个不可变的事件日志Event Log不管后续需要回放、审计还是调试都从这个日志出发。这种方式比打点日志要严谨得多定位问题的时候尤其有用。5.2 向量库选型从“用什么”到“怎么用”向量数据库的讨论热度已经不如前两年了但这不是坏事说明这个赛道已经过了“选型焦虑期”进入了务实深化阶段。当前社区讨论的重点转向了两个实践问题一是过滤条件与向量检索的融合二是多租户隔离下的性能衰减。关于第一个问题一个比较高效的实现方式是先做结构化预过滤再做向量近邻搜索。由于布尔过滤通常能显著缩小候选集实际查询效率往往比纯向量检索高出一大截。关于第二个问题多租户场景下如果数据集按租户做了物理隔离那向量索引的构建成本会成倍增加这时候可以考虑共享索引加行级权限过滤的组合方案在建成本和查询性能之间取一个中间值。5.3 可观测性LLM 应用排障的新共识今天好几个讨论都指向同一个方向——LLM 应用的可观测性正在成为刚需。传统的监控体系只能看到请求量和错误码但对于 Agent 应用来说你要知道的远不止这些模型接收到的完整上下文是什么、中间做了哪些工具调用、每步 Token 消耗多少、最终输出前触发了几次重试。社区里有个比喻我觉得特别贴切“用传统日志排障 Agent 问题相当于蒙着眼睛拆炸弹”。你需要知道模型在哪个节点产生了错误的中间判断但传统日志只会告诉你“步骤三的结果不符合预期”你还得靠猜。现在已经有开源工具提供了比较完整的 tracing 能力能把一次 Agent 的完整执行链路渲染出来从用户提问到最终输出的每一步都有记录。实践之后我的体会是接入可观测性的第一周我就找到了三个此前完全无法解释的“灵异 Bug”根因分别是上下文被截断、工具返回超时被静默吞掉、以及历史记忆被错误覆盖。6. 知乎热议话题社区在争论什么6.1 “Agent 会不会取代程序员”——争议背后是分工之变这个老话题今天被重新翻了出来起因是一位开发者发了一篇长文记录了自己用 Agent 完成技术方案落地、代码编写和测试的过程其中大部分编码工作是由 Agent 完成他只负责人工把关架构和评审。评论区自然分成了两派一派认为辅助编程是 Agent 最有价值的落地场景另一派认为“这不叫取代这叫换了一种编程方式”。我个人的看法是争议的核心与其说是 Agent 会不会取代人不如说“程序员的工作重心会不会转移”。当 Agent 能承担大量样板代码和基础函数的编写时工程师真正不可替代的部分在于目标拆解、架构设计、以及关键节点的经验判断——这些能力恰恰是当前 Agent 最难学会的。这篇长文里有个细节值得关注作者提到Agent 写出来的代码他都要逐行审查尤其是涉及资源释放和错误处理的逻辑。这不叫“取代”这叫“人机结对编程”。6.2 推理成本真实性别被 Demo 骗了今天另一个热度很高的讨论是关于推理成本的真实估算。有用户晒出了自己跑某个开源 Agent 从 Demo 到上线的完整开销记录结论是 Demo 阶段看着很便宜一旦上了多用户、长上下文、多轮工具调用的真实场景成本会变成 Demo 阶段的 20 到 50 倍。这个数字引发了不少共鸣。成本暴涨的根源在于几个被低估的因素工具返回内容占用的上下文 Token 往往比预期大得多、重试机制会成倍放大 Token 消耗、多轮 Agent 会话中累计上下文越来越大导致每次请求的 Prefill 成本持续走高。一位答主总结了很实在的建议不要以 Prompt 的 Token 数做成本模型要以“完整事件轨迹”的 Token 数为准。我深表认同并且想补充一条经验上线前用历史真实流量做一次回放压测比任何理论估算都靠谱。6.3 开源模型追新还是守成技术债的博弈还有一个讨论聚焦在开源模型的使用策略一个新版本发布后是立刻升级还是等社区反馈稳定后再上评论区里不少人分享了自己“追新翻车”的教训——新版本在某些能力上确实提升了但可能在一些隐藏的细分场景里出现了退化而这些细分场景恰恰是自己业务里最核心的环节又因为升级太快没来得及做回归测试。这个观点触及了一个更底层的逻辑模型升级的本质是技术债的博弈。每升一次级你的系统都要重新经历一遍 Prompt 微调、工具调用验证、输出格式校验甚至缓存策略调整。我的建议是可以追新但步子别太大。具体操作上我会先在一个隔离的测试环境里用影子模式跑上几天把新旧模型的结果做一次系统性对比确认无回归之后再切生产。影子模式的实现不算复杂核心思路是同时把请求发给新旧模型新模型只记录不响应不直接影响线上。7. 实操心得与避坑清单日报最后照例分享几条我个人近期在 Agent 和 LLM 项目中积攒的经验都是代码和文档里不会写的东西。第一Prompt 不是越长越好。很多团队一股脑地把所有约束都塞进系统提示词里结果模型反而不容易抓住重点。我尝试过把系统提示词精简到原来三分之一模型行为反而更加稳定了。核心约束和背景知识分开存放核心约束留在系统提示词里背景知识通过检索按需注入效果更可控。第二工具调用的超时处理一定要加。我在实际生产环境碰过不少次工具接口偶尔超过预期响应时间的情况。如果 Agent 的超时上限跟工具接口的上限设成一样网络稍微抖动就会让整个链路失败重试白白消耗 Token。正确做法是给工具调用设一个额外的缓冲时间并且考虑重试时的上下文裁剪——重试时不需要把第一次的完整输出重新发给模型。第三评估集比模型本身更值得投入。很多团队花大量时间选模型、调 Prompt却忽视了在业务场景里建立一套可持续演进的评估集。一套好的评估集应该包含正常案例、边界案例和典型错误案例每次模型升级或 Prompt 修改后都自动跑一遍。这件事越早做越好越到后期越能体会到它的价值——它相当于给你的 Agent 应用装了一个安全网让后续所有的优化都能在“可控”的前提下进行。第四别迷信“全自动”。当前 Agent 技术的现实是在明确、有限、可验证的任务域内表现优秀但跨域多步骤开放性任务的不确定性还是比较高的。设计系统的时候把人工审批和兜底环节作为一等公民而不是事后补丁反而能让整个系统更敢于自动化。让 Agent 在自信的领域放手干在关键节点停下来请示是当前阶段最好的解决方案。以上是我基于今天社区动态、论文阅读和自身实践的完整复盘。Agent 和 LLM 的发展速度确实很快快到一个季度前的“最佳实践”可能就过时了。但越是这种时候越需要我们把那些不变的东西抓住——可靠的评估、可控的成本、可观测的链路、绝对清晰的人机分工。这些东西无论模型怎么迭代都不会过时。
