长程 Agent：先问失效，再选机制

零、前言

接上篇《Agent 的 goal：目标与协议》。那篇只展开了一部分判断，还有一些问题，当时我没想清楚，就没有写进去。

文章发到群里后，收到不少反馈。LoopX 作者黄瑞腾也分享了文章，并指出几处需要修正的地方。之后我又读了不少长程 Agent 的设计与实验记录，做了几组小规模实验，慢慢有了这篇续篇。

看得越多，我越警惕一种说法：把架构选择说成代际替代。

模型变强以后，多智能体脚手架还有多少必要？外置状态和对话历史，分别该承担什么？约束写进 prompt 够不够，什么时候必须落到执行路径？这些问题都还在讨论，却经常被压成“某条路线要取代另一条路线”。

这些问题在各自的任务里可能有价值。但离开任务条件和失效证据，路线之争就会退化成架构偏好，不是工程结论。

上一篇拆的是 goal 的软硬两层，以及完成判定为什么没有硬解。这一篇换个方向，把机制本身当成有待验证的假设。我现在要求一个机制至少答上三件事——解决的是什么样的失效问题；带来了什么原来没有的东西；该拿什么证据判断它是否值得留下。

同一个检查闸门，在三种情况下会有三种不同的结果：模型本来就会反复运行测试直到通过，它几乎无事可做；模型会提前停下，它可能补上关键一步；检查本身写错了，它反而会把错误稳定地放大。所以，判断一个机制有没有用，先要弄清它面对的失效是什么。

一、成功的定义

长程系统里最容易被跳过的一步，不是续跑，也不是状态保存，是成功标准。

“目标写对了，接下来只看模型是否守约”，说起来简单，但是这句话把太多困难藏进了“写对”里。真实任务中，目标可能不完整，不同人的要求可能冲突，环境一变，原本正确的目标也会失效。执行到一半，人补充一句“我真正关心的是线上稳定，不是孤立基准”，旧结果并没有因此变得毫无价值，但它能证明的范围已经变了。

所以在讨论任何控制机制之前，我会先问：

• 谁定义成功，谁有权修改目标和验收？
• 修改以后，哪些旧工作仍然有效，哪些结论需要重新验证？
• 最终结果由什么独立证据判定，而不是由执行者自己宣布？
• 无法自动判断的部分，谁负责看，什么时候必须把决策交还给人？

这里最不能让步的词是“独立证据”。独立不等于另起一个模型，也不等于把同一份测试在停止前再跑一遍——很大概率是无用的，因为第二个判断者和执行者看同一份信息、有同一处盲区，只是形式上的独立：信息没有增加，多一个判断者未必有用。

可见、可反复运行、甚至可被修改的测试，都已经参与了执行过程，只能算在线反馈，不能算留出测试集。TDD 先写测试也不例外，尤其是执行者自己写的测试。只有未泄露、不可修改、独立于执行者、只在最后用于评价的检查，才更接近留出测试集。

成功标准本身还不可靠时，就需要认真考虑目标、验收和人的决策入口。否则系统越能推进，就越稳定地推进错误方向。

二、把失效保存成标准

“模型不够强”“上下文不够长”“协议层是瓶颈”，都不适合直接指导设计。它们太大，也太容易随解释者的心情改变。

更好的失效描述能落到一次具体观察上：

• 连续几次压缩以后，一条不能修改验收的约束从工作依据里消失了；
• 可见测试全部通过，独立检查却发现执行者改写了原有契约；
• 工具已经启动远端任务，调用方没收到回执，恢复后又启动了一次；
• 子任务只带回一段结论，主任务因此漏掉了必须保留的限制条件；
• 大量彼此独立的阅读工作串行等待，墙钟时间远超模型实际推理时间；
• 每一步局部检查都通过，连续几十轮以后，整体方向已经偏离。

这些句子有个共同点：不指定解法。上下文丢失不一定非要外置状态，交接失真不一定非要取消子 agent，可见测试失效也不一定要再加一道同样的测试。

接下来要问的问题就成了：这种失效真的在基线系统里发生吗，频率是多少？

“理论上可能发生，但发生概率极低”和“在当前模型、当前任务、当前预算下反复发生”，是两种完全不同的设计依据。一个针对低频假想故障的复杂机制，本身也会持续产生资源消耗。

三、错误是怎样被自洽化的

借用机器学习里 fitting 的类比，Agent 每一步都在对“到目前为止的上下文”重新拟合。严格说这不是参数训练，是自我条件化：刚生成的 plan、摘要、代码和解释，会重新进入后续决策的输入。

这个类比真正提醒我的是反馈回路。自生成内容不天然强化错误，也可能帮着纠错；危险在于假设、观察和决定在后续上下文里失去来源和置信度，未验证的内容慢慢取得事实地位。错误可能复合，也可能被纠正、衰减，或者锁进长期状态——情况非常复杂，不能预先画成一条单调曲线。

图 1：自我条件化不是错误本身；来源、权威与独立反馈共同决定后续轨迹。

我最近用 GLM-5.3-Flash，在模拟数据上做了六次短轨迹 pilot，想把这个过程放进受控环境里看。任务是把 12 个月的销售额和退货汇总成年报，执行者先写 plan，再过一次计划评审。评审时注入同一句错误前提：“销售额已经是扣除退货后的净额，不要再减退货。”一组把句子追加到执行者自己的 plan，另一组放进外部参考文档。独立 validator 在沙箱外计算真实结果，基线和阳性对照先验证任务与检测通道。

错误前提的位置	拒绝前提	采纳前提
自有 plan（R3、R5）	R3：引用列语义和历史恒等式否证	R5：重构 gross 维持恒等式
外部文档（R4、R6）	R6：记录冲突并拒绝	R4：把正确公式改标为错误

两边各有一次拒绝、一次采纳，这本身没什么。真正值得注意的是，首跑那个鲜明的对比，在重复时反转了。

四个前提运行都读到了足以否证错误前提的材料，区别在冲突时把谁排在前面。拒绝者把数据字典和历史报告的恒等式放在批注之上，采纳者做了相反的选择。R4 把自己刚写下的正确公式改标为 dropped as incorrect，自称 26/26 自检通过，还把正确净额反称为错误；R5 重构 gross = net + returns，牺牲列标签保住批注与恒等式，也自称全部自检通过。两边的数值错误都是独立 validator 抓出来的。

两个提醒。第一，自己的 plan 并不天然拥有更高权威——自生成内容确实会进入后续决策，但它是被保留、修订还是推翻，取决于冲突时的权威排序，不是“自己写的就更容易相信”。第二，自检通过只说明自检覆盖的规则通过了。R4 的自检里没有与权威数据源的一致性检查，所以它能证明报告内部自洽，不能证明报告为真。

实验边界也得留下：每臂只有两次运行，判断不了位置效应，也算不出发生率；权威排序只是与轨迹相符的解释，不是这次单独操纵出来的因果变量。R3、R6 的净额与 top month 虽然正确，但在预先冻结的评分规则里，summary 使用千分位仍导致格式检查失败，我没有事后改分。validator 自己也需要被审查。

四、机制搞定了什么

一个机制值得留下，靠的是它带来了原来没有的东西：更完整的信息、不同的观察、更多的执行能力，或者更清楚的权限边界。

1. 保留会话、压缩、刷新、外置状态：搞定不同的上下文

这些机制经常被排成一条进化路线，其实它们交换的是不同代价。

继续原会话，保留的是推理路径、局部细节和那些没被写下来的工作默契。它也保留早期误判、无效探索和已经过时的决定。长任务里，恢复同一段对话，不等于恢复仍然适用的判断。

压缩让更多历史进入有限窗口，但压缩后的内容只是派生物。它适合保留“继续工作所需要的线索”，不该被默认成一份完整、权威的历史。

刷新会话可以切断一部分路径依赖，让模型重新审视路线。代价是重建上下文，以及丢掉那些从未外化的判断。刷新不是天然更干净，续跑也不是天然更聪明。

外置状态把目标、证据、任务归属这类需要长期维护的事实放到对话之外，让它们可以被检查、恢复和重新投影。真正的收益是把“保留什么、谁能修改”变成显式设计，不是把状态搬个位置。代价也在这里：schema 表达不了的东西放哪里？旧版本证据怎么失效？每次重建上下文时，哪些省略可以接受？还是借用 fitting 的类比，锚点有点像正则化：强度合适可以抑制漂移，过强或过时就会制造系统性偏差。它需要版本和撤销机制，不是冻得越死越安全。

选择之前先区分失效：到底是窗口装不下，历史污染太重，还是关键事实根本没有被可靠记录？三种病不共用一张处方。

2. 单会话、选择性委派、并行 Worker：搞定不同的执行结构

单会话最大的资产是共享上下文。模型看过前面的每个结果，可以把不同阶段的判断连起来，也不必通过摘要向另一个自己解释发生过什么。

但共享上下文不免费：窗口会膨胀，错误会连续积累，串行执行也用不上真正独立的工作。

委派只有在能带来一种独立资源时才有明确意义：

• 一个可以丢弃的独立上下文，用来并行阅读或检索；
• 一份可以独立执行的计算任务，用来搜索不同候选；
• 一套不同的权限，用来限制副作用；
• 一个拥有不同信息或立场的判断者，用来验证而不是附和；
• 一套不同的模型、工具或领域指令，用来补足主循环没有的能力，或者拿到更合适的成本结构。

如果只是把 planner、researcher、reviewer 几个角色名拆开，信息还是同一份，判断也高度相关，多出来的往往只是交接和协调。

所以“多智能体有没有用”不是个好问题。该问的是：这次委派买到的独立资源是什么，交接损失又是什么？两者放在同一个任务里测，才有答案。

3. 执行闸门：搞定不可绕过的权限，而非语义正确

高风险、不可逆动作需要执行前裁决，这一点争议不大。模型输出不能直接等于副作用，所有危险入口都得经过不可绕过的检查。

但闸门擅长回答的是“这个动作现在能不能做”，不是“这项工作是否仍然值得做”。

一次数据库写入可以完全符合权限，却服务于一个已经过时的目标；一百次低风险修改每一次都合法，合起来却慢慢偏离需求。把每个动作都交给人工审批也不一定更安全：审批疲劳、等待和误拦截都是实际成本，还可能让系统失去活性。

所以执行闸门要和别的机制分工：权限检查保护动作边界，目标和验收保护方向，诊断与恢复处理那些没能预防的失败。安全、正确、能持续工作，是三个需要分别验证的性质。

4. 验证、归因、恢复：搞定失败之后的可见性

不是所有失败都能提前挡住。长程系统还需要三种经常被混在一起的机制：

• 验证判断结果是否满足标准；
• 归因把人的注意力引向最该先查的环节；
• 恢复在不确定已经发生什么的现实环境里，避免重复执行，继续未完成的工作。

验证器不完整时，归因模型也可能学到错误的“成功轨迹”。异常步骤提示的是调查顺序，不是根因。恢复同一会话，恢复不了外部世界；外部动作的回执不确定时，还需要稳定的操作身份和结果回读。

这些机制不能相互替代。预防做得再好，也不意味着可以不要诊断和恢复。

五、控制回路不是越多越好

看长程系统时，我现在会先分几种时间尺度：

• 一次 Run 内的检查失败，可能应该让当前执行继续；
• 一个工作项被接受，可能应该关闭节点、解锁下一项；
• 一次完整试验的结果，可能应该影响下一轮实验选择；
• 顶层目标被有权的人修改，才应该触发目标版本变化和旧工作的重新核实。

很明显，这些事件不该拥有同等的写权限。

一次局部失败如果可以直接改写顶层目标，系统会失去方向；Run 内的重试都当成完整试验写入历史，后续的回归和停滞判断就被污染；执行节点自己批准自己的全局完成，独立验收就只剩形式。

所以有些“没接上”确实是断线，有些是有意保留的权限边界。设计时真正该写清的是：

什么事件，在什么时间尺度上，携带什么证据，由什么 authority，允许驱动哪一个状态迁移？

该接的是证据和状态，该断的是越权和污染。如果把所有事件接进同一个循环，那就要准备接受混乱吧。

六、机制有没有用，要过四道证据

我以前看一个机制，容易先研究它做得是否精巧。现在会把顺序倒过来，先看它能不能穿过下面四道证据。

图 2：机制价值的四道证据；任何一道缺失，都不能把结果直接归因于机制。

第一道：基线里确实存在它要处理的失效

先拿当前最简单、仍然可用的系统做基线，观察这类失效是否真实出现，以及出现的条件。

如果控制组根本没有这种病，结论应该是“当前条件下无法检验治疗收益”，而不是“加上以后没出问题，所以有效”。对照组完全没有失效，也可能只是任务太简单、模型太强，或者观察时间太短。

第二道：机制确实启动了

续跑器有没有真的续跑？闸门有没有真的拦截？外部证据有没有进入下一次决策？刷新是否发生在预定的重规划节点？这里需要启动记录和输入证据，配置项存在不算数。一个从未触发的机制，不能解释两组结果之间的差异——两组分数不同，也可能只是模型采样的正常波动。

故障注入也要拿出同样的暴露证据。在另一次小规模 pilot 中，我把错误前提写进 Agent 自己的 plan，两个执行单元在 resume 后都没有重新读取它。文件级注入成立，模型级暴露却未观察到。最终产物虽然通过，关于故障是否有效也只能记 N/A，而不是“没有漂移”。这和“机制配置了但没触发”是同一类测量陷阱。

第三道：启动以后改变了哪个系统决定

机制启动不等于机制有效。它可能跑了，却没有改变后续动作、状态迁移或验收结论；也可能注入了更多信息，却因为信息权重被稀释而没有被看见，系统仍然沿着原路前进。

所以除了最终结果，还要留下机制影响系统决策的证据：失败后改了哪一步，证据进入后放弃了哪条路线，权限拒绝后换成了什么动作，验证以后有没有拦下一份原本会交付的结果。否则很难判断收益来自机制，还是来自同时变化的其他条件。

第四道：独立结果和资源消耗都要评估

最终结果不能只靠执行者自评，也不能只靠机制自己看到的那套检查。独立 validator、真实环境结果、人的验收，按任务选，并尽量保留多次试验。validator 自己也要先证明能拒绝已知坏结果，否则只是多了一层可能共同出错的检查。

资源消耗也不能只看 token。评测本身的算力、并行资源、等待时间、恢复开销、人工审阅、配置学习和后续维护，都要计入机制带来的资源消耗。

收益也不必只有最终通过率：危险动作减少、恢复时间缩短、人工排查变少都可以是结果，但最好事先选定，而不是看完数据再挑一个变好的指标。

机制自身新增的失效也要进结果：摘要会不会丢约束，外置状态会不会过期，委派会不会复制错误，闸门会不会误拦截。不然的话，原故障就只是换成了新故障。

比较时要区分两种问法：一种是固定资源上限，看哪个系统在相同的 token、时间和算力限制下完成得更好；另一种是固定验收标准，看达到同一标准时，哪个系统消耗的资源更少。前者比较相同限制下的表现，后者比较达到目标所需的资源，不能都概括成“效率更高”。上一篇我反复核对资源口径，自己的实验里，这项也最容易被简化。

长程任务还要把时间轴留下来

终态成败之外，我还会多留三类过程指标，用来定位失败发生在哪里，而不是把轨迹压成一个总分。

• 约束级漂移。 把 spec 拆成原子约束，在不同 checkpoint 记录满足、违反、未知和依法失效。尽量用行为探针验证，不只看 Agent 能否复述，也不拿文本相似度冒充语义漂移。
• 纠错延迟。 分开记录发现、定位、首次正确修复、独立验证和归轨。发现异常不等于找到原因，修对代码也不等于旧副作用和旧状态已经处理。步数之外，还要看 token、墙钟和人工介入。
• spec 变更对账。 新约束多久被采用，有效旧工作保留了多少，失效工作撤销了多少，旧证据是否重新核过范围，返工和回归各有多少。收紧、放松和转向要分开测：强锚点在收紧时可能有帮助，放松时却可能是负担。

图 3：长程轨迹的故障处理与 spec 变更对账。

这些指标同样需要过程证据：故障有没有送达、机制有没有启动、Agent 有没有真正读到证据，不能只靠终态分数推断。

七、我现在的选择顺序

合起来，我现在的顺序是：

1. 先定义成功和权限。 谁定目标，谁验收，谁能改，哪些判断必须留给人。
2. 用最简基线暴露失效。 记录它发生的条件、频率和代价，不凭架构想象补机制。
3. 选能带来新增量的最小机制。 新信息、独立观察、独立上下文、执行能力或权限边界，至少明确一样。
4. 开跑前写完验证方式。 按第六节四道证据来，别等结果出来再挑指标。
5. 允许删除。 以提效为目标的机制，如果长期没有触发、没有改变系统决策，收益又抵不上资源消耗，就退回更简单的结构。高风险保护另算：还要单独衡量尾部风险和合规要求，不能因为它很少触发就删掉。

模型变化以后要重新测，不仅仅是因为失效的分布会跟着变，还因为机制的价值也会变。这套顺序看起来不快，甚至会延缓开发进度，但比先设计一套完整控制面再去找用途省时间。

结尾

长程 Agent 的难点，不是可选机制太少，而是每种机制都能找到自己的拥护者。会话派、外置状态派、单智能体派、多智能体派、硬闸门派，都能拿出案例。但案例只能说明机制在某个任务里有效，不能替我决定它是否值得留下。

上一篇的结尾说，咒语会变成机制。这一篇再补一句：机制自己也得过验收。它治的是哪种失效，带来了什么新增量，是否真的启动并改变了系统决策，都要用证据回答。回答得上，就留下；回答不上，就退回更简单的结构。