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 这行，判断力比堆功能值钱得多。希望今天列出来的这些变化，能帮你在自己的工程判断里多一个锚点。
