内部完成为什么会被外部验收拒绝

一句话收获：执行链可以稳定结束在错误结果上，外部验收必须独立存在。

这个场景在解决什么问题

一个诡异但真实的现象：Agent 内部一切正常——checklist 全打勾、Loop 正常结束、没有报错——但业务上却是错的（该创建的对象没创建）。为什么"内部完成"会撞上"外部验收拒绝"？

这个场景的目标（goal）是：展示假完成、模型替换和 Harness 消融。观察点（observation）是：同一运行同时保留内部收敛和外部验收结果——同一次运行，把"内部觉得自己完成了"和"外部验收判定失败"两个结果同时记录下来对照。

它值得单独学，因为它揭示了一个关键真相：执行链可以稳稳地停在错误结果上。内部一致、流程走完，都不等于业务成立，所以外部验收必须独立存在。

先理清这条判断链（文字版）

从"内部自认为完成"到"查清为什么会错"，是一条诊断链，先暴露假完成，再用两种方法定位原因：

先看内部收敛——Agent 的 checklist 全完成、Loop 不再产生新任务、无内部错误，但这只说明"执行链认为可以停了"。
再看外部拒绝——验收器查权威系统，发现一个关键对象没创建，业务完成依赖执行链之外的事实。
然后看固定 Harness 换模型——固定环境换多个模型跑，观察模型能力瓶颈。
最后看固定模型做消融——固定模型、关掉某个机制（如状态查询或独立验收），看假完成率变化，观察模型外机制的贡献。

逐层详解

第 1 步：内部收敛

原文：Agent checklist 全部完成，Loop 不再产生新任务。

白话：Agent 内部的 checklist（检查清单）每一项都打勾了，Loop（执行循环）也不再产生新任务了，看起来"活干完了"。

类比：像一个人照着自己的待办清单一项项打勾，勾完了、也没新事情了，就觉得"我干完了"——但他可能漏了一件清单上根本没有、却至关重要的事。

举例：订单处理 Agent 的 checklist 是"查订单→核对金额→生成处理结果→回复用户"，全勾完，Loop 也停了，没有报错。但"在系统里把订单状态改成已处理"这一步，根本不在它的 checklist 里，它没做。

为什么重要：这只说明执行链认为可以停止。内部收敛（收敛=执行链进入稳定停止状态）只代表"执行链自己觉得该停了"，不代表业务真的完成了——它是主观的"我觉得行"，不是客观的"业务行"。

怎么验证（证据点）：

checklist 完成：清单项确实都完成了。
Loop 结束：循环确实停止、不再产生新任务。
无内部错误：运行中没有内部报错。

别踩的坑（边界）：内部一致不证明外部业务成立。内部所有环节自洽、没矛盾，不代表外部业务上真的成立了——内部一致性和外部正确性是两码事。

落地检查：保留内部状态，不直接宣布成功。落地时看到内部收敛，先保留现场状态，不要急着宣布成功，等外部验收。

第 2 步：外部拒绝

原文：验收器查询权威系统，发现一个关键对象未创建。

白话：独立的验收器去查"权威系统"（真正记录业务事实的系统），发现一个关键对象根本没创建——比如订单状态根本没改、任务根本没建。

类比：像装修队说自己完工了，业主去物业系统一查，发现关键的一道工序（比如消防验收）根本没做——不是清单漏了，是业务上真没完成。

举例：订单 Agent 内部收敛了，但独立验收器去查订单系统，发现"订单状态"这个关键对象压根没被创建/更新成"已处理"，业务上的核心动作没发生，于是判定 acceptance rejected（验收拒绝）。

为什么重要：业务完成依赖执行链之外的事实。业务上"到底完成没有"，取决于执行链之外的真实系统状态，而不是执行链自己说了算——这是个外部事实，得去外面查。

怎么验证（证据点）：

外部对象缺失：权威系统里确实缺了关键对象。
义务失败：某条成功义务没满足。
acceptance rejected：验收明确判定为拒绝。

别踩的坑（边界）：拒绝不是事后新增要求。验收拒绝不是因为"事后临时加了一条新标准"，而是因为"运行前就冻结好的验收基线没被满足"——标准早就定了，不是临时为难你。

落地检查：验收基线在运行前已经冻结。落地时验收的标准（基线）必须在运行开始前就冻结好，不能跑完才现定，否则验收就不公平、不可信。

第 3 步：固定 Harness 换模型

原文：比较多个模型在相同环境和任务集中的差异。

白话：为了定位"是不是模型不行"，做法是固定 Harness（运行框架）和任务集不变，只换模型——用多个不同模型在完全相同的环境和任务上跑，看结果差异。

类比：像做对照实验，别的条件全不变，只换"执行的人"，看换人之后结果差多少，从而判断是不是人的问题。

举例：固定同样的订单处理 Harness 和测试任务集，分别用模型 A、B、C 跑，看谁能在外部验收上通过。如果换模型后结果明显不同，说明瓶颈在模型能力；如果都差不多，说明瓶颈在别处。

为什么重要：这样观察模型能力瓶颈。只有把环境、任务都固定，只让模型这一个变量变，才能看出"结果差异到底是不是模型造成的"。

怎么验证（证据点）：

Harness 固定：运行框架没变。
任务固定：任务集没变。
模型变化：只有模型这一项在变。

别踩的坑（边界）：单次最好结果不能代表连续可靠性。某个模型某一次跑出了最好成绩，不代表它连续跑都可靠——单次最好 ≠ 稳定可靠。

落地检查：报告重复运行分布。落地时要报告"重复跑多次的结果分布"（不是只报最好一次），才能反映真实可靠性。

第 4 步：固定模型做消融

原文：关闭状态查询或独立验收，假完成率明显变化。

白话：为了定位"是不是模型外的机制在起作用"，做法是反过来——固定模型不变，做"消融"（ablation，逐一关掉某个机制看影响）：比如关掉"状态查询"、或关掉"独立验收"，看"假完成率"（内部完成但外部失败）会不会明显变化。

类比：像排查电路，固定主板不变，一根根拔掉外设（拔掉这个传感器、那个报警器），看哪根拔了之后故障率飙升，就知道是哪根在兜底。

举例：固定模型不变，做消融实验：关掉"状态查询"机制后，假完成率大幅上升，说明状态查询是防止假完成的关键机制；关掉"独立验收"后，假完成再也抓不出来，说明独立验收是最后的守门员。

为什么重要：这样观察模型外机制贡献。固定模型、只改模型外的某个机制，就能看清这个机制本身贡献了多少——很多可靠性不来自模型，而来自这些外部机制。

怎么验证（证据点）：

模型固定：模型没变。
机制单变：每次只改变一个机制。
失败类型变化：失败类型随机制变化而变化。

别踩的坑（边界）：消融结果不能证明其他系统必然同样变化。在这个系统上消融得出的结论，不能直接推广到别的系统——换个环境、换个任务，结果可能不一样。

落地检查：结论绑定当前任务与环境。落地时消融得出的结论，要明确绑定"当前这个任务、当前这个环境"，不能当成普适定律。

落地可行性小结

本场景涉及的核心技术栈：checklist（检查清单）、Loop（执行循环）、内部收敛、外部验收器（acceptance）、权威系统、Harness（运行框架）、模型替换对照、消融实验（ablation）。

真实落地要检查的事：

内部收敛（checklist 全勾、Loop 停、无报错）不能宣布成功，要保留现场等外部验收。
外部验收器要查权威系统，验收基线在运行前就冻结好。
定位模型瓶颈用"固定 Harness 换模型"，报重复运行分布，不看单次最好。
定位机制贡献用"固定模型做消融"，每次只改一个机制，结论绑定当前任务与环境。

常见坑：

内部 checklist 全绿就宣布成功，结果业务上对象根本没创建。
验收标准跑完才现定，让"拒绝"显得像临时找茬。
用单次最好成绩判断模型可靠性，忽略分布。
把消融结论当成普适规律，没绑定当前环境。

回顾

执行链可以稳定结束在错误结果上，内部收敛 ≠ 业务成立。
外部验收必须独立存在，查权威系统、验证关键对象，且基线在运行前冻结。
固定 Harness 换模型，用来观察模型能力瓶颈，报重复运行分布。
固定模型做消融，用来观察模型外机制（状态查询、独立验收）的贡献。
假完成（内部完成但外部失败）是必须主动防御的，不是模型够强就自动消失。