1. 今日视角Agent 工程不再缺模型缺的是“交接契约”这周在 Agent / LLM 这个圈子里最扎眼的不是哪个模型又刷了榜而是一批工程化基础设施在同一时间段集中补课可审计的推理日志、跨会话的短期记忆、多 Agent 协作时的故障转移、结构化输出的强制校验。放在去年这些还都是各家自己造轮子的事今年明显看得出行业正在把这些能力往“默认项”里塞。我做 Agent 开发两年多最大的体感是模型能力早就不是瓶颈真正劝退团队的往往是那些看不见的接线问题。今天这篇日报我不会逐条念新闻而是挑出 2026-10-11 前后值得细看的几件事拆开说清楚它解决的是什么问题、适合谁抄作业、以及落地时容易在哪个环节翻车。如果你是做应用开发的、做平台中间件的、或者准备把 LLM 塞进现有业务系统的这篇内容值得花十五分钟。我会把技术判断和实操经验混在一起写有些地方甚至会直接给出可用的配置片段方便你改改就能用。2. 今日快评四件正在改变 Agent 工程水位的事2.1 “推理日志”从审计要求变成了默认能力今天最值得注意的动向是多家厂商和开源项目不约而同地把“推理日志”做成了默认开启。所谓推理日志不只是记一下 prompt 和 response而是把 Agent 每一步的工具调用、中间思考、上下文截断位置、token 消耗都落成结构化记录。这件事的意义被很多人低估了。我在做多轮对话类 Agent 时碰到最头疼的问题就是用户说“你昨天还知道我的偏好今天怎么忘了”过去排查只能靠瞎猜。有了结构化推理日志问题的定位量级完全不一样我只需要查上次会话的最后上下文快照再对比这次会话的上下文注入很快就能判断是召回没查到还是摘要压缩的时候丢掉了关键信息。我的建议是无论你用什么框架尽早把日志的 schema 定下来。可以不用很复杂至少包含这几个字段会话标识、时间戳、输入 token 数、输出 token 数、工具调用列表、上下文截断位置、最终的 prompt 校验指纹。这套东西越早沉淀后面做评测、做复盘、做用户争议处理都会轻松很多。2.2 小尺寸规划模型开始攻占嵌入式场景另一个值得关注的变化是某实验室放出了一个参数规模不到主流大模型十分之一的规划模型专门负责把用户目标拆解成步骤序列。这听起来像是个技术新闻但背后是一条很清晰的工程逻辑很多 Agent 场景根本不需要大模型全程参与只需要在“拆解目标”和“最终总结”两步用强模型中间的每一步用轻量模型甚至规则引擎就够了。我在一个自动报表项目里试过类似的思路。原来的做法是让大模型每一步都参与结果成本高、延迟大而且模型偶尔会在中间步骤里发挥过度生成本不该存在的分支。改成“大模型负责规划、小模型负责填空、规则引擎负责兜底”的分层结构以后整体成本下降了七成准确率反而提升了。如果你现在做的 Agent 任务步骤比较固定我建议你重新审视一下模型调用链。不要默认每一步都走同一个模型试着把任务里“理解类”和“生成类”的环节拆开分别选不同规格的模型收益会非常明显。2.3 编排框架开始原生支持故障转移第三个值得注意的动态是几个主流 Agent 编排框架先后补上了原生故障转移能力。过去我们做多 Agent 协作最怕的就是某个子 Agent 服务不稳定超时后任务卡住。通常大家都是在业务层自己做重试和熔断但今天框架层面开始内置这套机制意味着这不再是“加分项”而是基础能力。我在生产环境里踩过这个坑。有一段时间我们的 Agent 服务会偶发返回 503当时框架不支持自动重试结果用户同一个请求被反复提交数据库里积累了十几条重复任务。后来我只能在网关层做了幂等同时在每个子任务里加了状态机才把这个坑填平。现在框架原生支持故障转移等于是把这块从业务代码里解放出来了但你自己仍然要设计好“失败任务”的可见性否则故障转移偶尔会静默地把任务切到备用节点最终结果对不上账。2.4 结构化输出校验从“建议”变成了“强制”第四件事是结构化输出的约束范式在变。以前大家做 JSON 输出都是写完 prompt 再祈祷模型听话偶尔手一抖就是缺失字段或者类型错误。最近几个项目开始把输出直接绑定到 JSON Schema模型生成结果后先校验不通过就自动重试不是靠撞运气而是靠机制。我在一个数据清洗项目里被这个坑惨过。当时模型输出的时间字段有时是“2026-10-11”有时是“2026/10/11”还有时候带个时区后缀。虽然每个格式我都能解析但下游系统的告警阈值只看其中一个格式结果在夜里连续误报。后来我在输出层统一了 schema 校验时间字段强制用标准 ISO 格式不满足就重生成问题当天就消失了。我的建议是所有需要对接下游系统的 Agent 输出都应该把 schema 校验作为强约束而不是靠运气。3. 焦点拆解Agent 的短期记忆为什么依然是最难啃的骨头3.1 短期记忆的本质问题是什么先说结论短期记忆不是“模型记性差”而是你在架构上没给 Agent 提供持续回看的能力。大模型本身是纯函数的同一个输入进去它不记得上次是什么状态所以所谓短期记忆完全要靠外置的上下文管理方案来弥补。但这里有个矛盾上下文窗口再大也装不下无限增长的历史。而且很多关键信息不是“能装下”就行而是要在合适的时机被想起。比如销售助理想给客户报价它在第 5 轮对话中提到了折扣底价到第 38 轮真正要生成合同时如果系统只做简单的滚动窗口截断前面的关键信息早就被挤掉了。这种情况我把它叫作“上下文漂移”。上下文漂移的直接后果就是 Agent 看起来“很傻”或者“很健忘”。用户不会关心你是不是被 token 预算卡住了他只感受到体验断裂。这也是为什么短期记忆方案的好坏会直接影响用户对 Agent 的信任判断。3.2 主流的短期记忆方案都有什么坑滚动窗口是最朴素的做法就是把最近的几轮对话塞进 prompt。它的优点是实现成本低缺点是一视同仁地淘汰旧信息完全不管哪条信息更重要。我见过不少团队上了这个方案以后用户满意度反而不如不做因为 Agent 会在关键节点忘了自己说过什么。摘要压缩是目前应用最广的方案。每次对话达到一定长度就用模型把前面的内容总结成一段摘要再放到上下文顶部。这个方法好用但它有一个隐藏的问题摘要过程是一种有损压缩而且是一次性的一旦摘要错了后面全都会跟着错。我遇到过的情况是摘要模型把用户的重要诉求理解偏差导致后面十几轮回复都在跑偏方向。还有一种叫结构化符号记忆的方案把关键信息抽出来写进独立的字段比如用户偏好、待办事项、约束条件。这个方案短期记忆能力强但需要你提前定义好信息抽取的规则对格式不规范的自然语言对话来说维护成本不低。3.3 一个成本不高但实用的“记忆折中方案”说点可落地的经验。我目前在用的是“滚动窗口 按重要性标注 摘要底稿”的组合方案成本不高但实测效果比单一方案稳定很多。核心做法是对话进入上下文之前先过一遍轻量分类器把消息分成“重要性高”和“重要性低”两类。重要性高的信息比如用户明确说“这个必须保留”、“我的预算是”、“截止日期是”强制放进持久化记忆区不占滚动窗口配额重要性低的信息走正常的滚动淘汰。这样做的直接好处是一段 50 轮的长对话真正塞给模型的 token 量可能只有原来的三分之一但关键信息一条都没丢。我自己的项目里用过这个方案用户重复追问老信息的次数明显下降而且不需要引入额外的向量数据库普通的关系数据库存个键值就能撑住。要注意的是重要性分类器如果做不好反而会成为新的错误源。我的建议是先小范围试验只对少量明确的高价值信息启用强制保留不要一上来把所有东西都往记忆区塞。3.4 评价短期记忆方案的三个硬指标评估短期记忆方案时我一般只看三个指标。第一个是保留率也就是关键信息经过 N 轮对话后还能不能被召回第二个是上下文密度也就是单位上下文里有多少是真正被用到的信息第三个是审计能力也就是你能不能解释清楚为什么某条信息没被保留。三个指标都要量不能只盯着保留率看。我用过一个方案保留率确实高但代价是把大量无关紧要的信息都塞进了上下文结果模型被噪声干扰反而频繁犯错这属于典型的密度失衡。现在我的团队做记忆方案优化时会刻意记录这三个指标的每周变化用数据说话而不是凭感觉调参。4. 实操记录把一个多 Agent 协作任务做成生产可用4.1 打破一个迷思多 Agent 不等于越多越好很多人一听多 Agent就先想到搞五六个角色各管一摊。我的经验是Agent 数量越多协调成本涨得越快而且往往会是指数级的。多个 Agent 互相等待、互相覆盖、甚至死锁这种问题在 Demo 阶段根本体现不出来一旦放量就彻底暴露。我在一个复杂报表生成项目里最开始设计了四个 Agent数据采集、数据分析、格式美化、质量检查。结果实际跑起来的时候质量检查 Agent 经常认为格式美化 Agent 的产出不合格然后打回去重来。两个 Agent 之间陷入循环反复十几轮最后产出时间完全不可控。后来我把格式美化并回了数据分析 Agent只保留三个角色再在它们之间明确约定“交接边界”问题立刻缓解。我现在做多 Agent 时的原则是如果单个 Agent 用规则脚本就能勉强完成绝不多上一个大模型角色。宁可每个 Agent 笨一点也不要一群聪明但混乱的家伙。4.2 最小可用的编排配置长什么样多 Agent 协作至少需要一个稳定的编排器。我不建议一上来就上重型调度框架先用一个轻量的配置描述好各 Agent 的职责、输入输出、失败策略跑通再慢慢加复杂度。下面是我常用的编排器起始配置结构你可以理解为“逻辑分拣台”agents: planner: model: strong description: 拆解用户需求生成任务清单 input_keys: [user_request] output_keys: [task_list] failure_policy: retry_once executor: model: light description: 执行单步任务产出中间结果 input_keys: [task_list, context] output_keys: [result_chunk] failure_policy: fail_fast verifier: model: strong description: 校验最终结果不通过则打回并附错误原因 input_keys: [result_chunk, user_request] output_keys: [final_result, verdict] failure_policy: escalate_to_human这段配置最核心的是 failure_policy我分别用了三种策略。planner 失败可以重试一次因为它高价值但低频率executor 失败直接终止因为它执行的任务一般可以直接重试如果连续失败说明原始规划有问题verifier 失败则必须转人工因为质量检查反复不通过时机器自行重试基本都是在浪费 token。初始化时不要急着加太多字段。先把“谁产出什么、谁消费什么、失败了怎么办”这三件事定义清楚剩下的是后面迭代出来的。4.3 职责边界怎么划分才算合理职责边界划得好不好决定协作效率。我的判断标准很简单如果两个 Agent 需要频繁交换同一个字段多半就是边界重叠了。拿我之前那个报表项目举例。数据采集 Agent 当时不只负责取数还顺手做了一部分数据脱敏而质量检查 Agent 也会复核脱敏逻辑。结果两个角色在“哪些字段该脱敏”这个问题上反复扯皮模型幻觉夹在中间越搞越乱。后来我把脱敏相关逻辑全部收敛到采集阶段质量检查只负责抽样打分不再参与具体字段判断协作立刻顺畅起来。在实际划分时我建议画一张简单的输入输出矩阵列出每个 Agent 消费的字段和产出的字段人工看一遍有没有一对多、多对一的交叉。这个动作虽然看起来笨但能避免大量后续调试时间。4.4 别忽略多 Agent 的可观测性设计多 Agent 系统里最重要的基础设施我觉得是 trace。一定要想办法让每个环节的输入输出都能回放否则出了问题完全是黑盒。我在生产环境里见过最糟糕的情况是某个 Agent 偶发地把客户的金额字段改错但问题不是必现的导致排查人员完全没有线索。后来我们在每个 Agent 的输入输出节点都做了快照存储再结合前面说的推理日志花了半天就把复现条件圈定了。如果没有这套可观测性设计这个问题可能拖上一两周都不一定有结果。实现 trace 的时候不需要用多高级的工具哪怕只是把每个 Agent 的输入哈希值和输出哈希值记录到一张表里也能帮大忙。重点是养成习惯让每一跳调用都有迹可循。5. 实战排坑这个月记录下来的五条现场经验5.1 重试风暴超时引发的 token 雪崩如果你在做 Agent 服务一定要小心“重试风暴”。最常见的形式是一个上游接口偶发超时框架自动重试但重试的时候没有做退避导致同一请求在短时间内把几个 Agent 节点全部打满token 消耗瞬间翻几倍。我的解决方法是给所有执行 Agent 的调用统一加指数退避同时限定单次任务的最大重试次数。更重要的是要在重试时携带同一条 request_id方便后端的 trace 系统发现这是同一份请求的多次重放而不是新请求。这事看着小但线上事故十次有六次跟它有关。5.2 JSON 输出里的非法控制字符比想象中更常见结构化输出在浏览器端看着正常但一旦流转到日志系统或者数据库经常因为字段里混了看不见的控制字符而报错。我遇到过模型在备注字段里输出了一个疑似零宽空格导致下游解析全部失败排查了很久才定位到。根治办法是把输出校验链路加上字符级检查白名单只允许正常的可见字符和常用的转义符控制字符直接触发替换或重生成。虽然模型不一定每次都会犯这个毛病但只要发生一次对你的系统信誉影响就很大。5.3 工具输出截断造成的“自信错误”Agent 调用外部工具时如果工具返回的内容超过了模型的上下文配额很多实现会静默截断。这时候模型会拿着半截信息继续工作而且它自己完全不知道内容被截断了。这种错误的可怕之处在于模型的表达依然自信流畅但论据已经残缺。我现在的做法是在工具调用的输出头部加一个截断标记让模型明确感知“这段内容不完整”并且在必要的时候强制触发摘要流程先把长文压缩好再进上下文。5.4 自我反思循环不收敛还烧钱我给一个复杂 Agent 加了“自我反思”节点本意是让模型自查一遍再输出。结果产物在质量上确实提升了但代价是经常陷入反思循环模型每次都觉得还能更好然后反复迭代token 消耗量肉眼可见地涨。我后来加了两个限制一是反思次数上限默认两次二是每次反思必须带着上一版的明确缺陷清单不允许模糊地“再优化一下”。加了这层约束后质量几乎没有下降但成本降了快一半。如果你也在用类似的反思机制建议检查一下自己是不是给了模型过大的自由裁量权。5.5 系统提示词越写越长但效果越来越差最后这条经验其实是反直觉的。很多时候系统提示词变长不是因为它更负责而是因为它把不该由系统提示承担的任务都揽了进来。每一次新增的历史背景、每一条边角约束都在稀释核心指令的权重。我现在控制系统提示词的策略是只放“角色、任务、边界”三件事其余全部下沉到具体的运行时上下文里比如用户偏好放到记忆区业务规则放到检索库输出格式放到 schema。经过这轮瘦身模型对核心指令的遵从度反而明显提升。如果你的 Agent 表现越来越“笨”且提示词超过了两屏建议也去做一次清理。6. 后续可以立刻动手准备的事6.1 把“评估”当成 Agent 项目的路径而不是终点我见过太多团队在 Agent 上线后把评测周期拉长到半个月一次结果模型稍微更新一版行为漂移了都不知道。现在我的习惯是给每个关键链路都准备一个迷你评估集不一定很全面但至少覆盖核心路径和两三个极端情况每次有变更就快速跑一遍看分差。这个评估集不需要用重型平台几十条样例加一个简单的打分脚本就够起步。重点是把它嵌到发布流程里让每次变更都能先看到对行为的影响而不是等线上出问题再回头翻。6.2 为“人机边界”留好 Service 入口这是我想特别强调的一件事。Agent 再自动化总有一些场景需要兜底给人工处理。很多时候团队只顾着优化 Agent 本身的准确率却忘了设计“转人工”的入口导致系统在低置信度场景下硬扛用户体验很差。我现在的做法是在编排层预留一个 escalate 节点任何 Agent 的低置信度结果都会自动转人工复核。这个设计看上去浪费了一点自动化能力但从整体体验看是值得的。做 Agent 不是追求所有事都机器代劳而是让机器干它擅长的把人留在最后一道闸上。6.3 最后分享一个做日报时的小习惯我在写这类技术日报的时候不会只盯着发布会看更关注的是那些“基础设施层的默认值变化”。默认值变说明行业对某个问题的解法正在形成共识这种信号比任何单独一篇论文都更有参考价值。做 Agent 这行判断力比堆功能值钱得多。希望今天列出来的这些变化能帮你在自己的工程判断里多一个锚点。