3.1.2 · 审计恢复与能力归因

1. 可验证状态、合约与审计

MEA 的核心是让状态只能沿合法边迁移；三个模型只是实现这种约束的一种分工。若 Manager、Executor 和 Auditor 仍靠一段自由文本互相暗示「大概做完了」，角色数量增加也不会带来可靠性。外置状态需要明确区分计划、执行结果、审计证据和已提交事实。对一个子任务 $g_i$ ，可以定义状态集合

Q_i=\{\text{pending},\text{running},\text{observed}, \text{verified},\text{failed},\text{blocked},\text{stale}\}. \tag{8}

Executor 结束只允许从 running 进入 observed，因为它只能报告自己做了什么；Auditor 读取环境证据后，才允许进入 verified 或 failed；环境版本变化会把旧证据对应的 verified 降为 stale。直接从 running 跳到 verified 等价于相信执行者自评。转移还要携带守卫。设审计报告为 $a_i$ ，当前环境版本为 $v$ ，验收谓词为 $C_i$ ，提交条件可写成

\operatorname{commit}(g_i)iff a_i.\text{env\_version}=v \land C_i(a_i.\text{evidence})=1 \land a_i.\text{scope}=g_i.\text{scope}. \tag{9}

版本不一致说明审计后环境又变了；证据不满足谓词说明结果未达标；作用域不一致说明检查了错误对象。三项都通过，状态才进入可信集合。复合任务由依赖图组成。节点 $g_i$ 只有在所有前驱已验证且证据仍有效时才可运行：

\operatorname{ready}(g_i)= \prod_{j\in\operatorname{Pred}(i)} \mathbf 1[q_j=\text{verified}]. \tag{10}

若前驱后来变成 stale，后继并非全部自动失败；系统沿依赖边标记受影响节点，重新审计或回滚。没有依赖图时，只能粗暴地重做后续所有工作，或冒险继续使用过期事实。状态机还需容纳 inconclusive。Auditor 无法观察某项，不代表执行失败，也不能算通过。它应保留已取得证据、标记缺失观察，并让 Manager 选择补充检查、换验证器或请求人工。把未知硬塞进二元成功/失败，会让系统反复执行同一动作。

事件日志与物化任务状态，只保存当前 task state，出了错很难回答「哪一轮把错误事实写进来」。更稳妥的设计把每次计划、动作、观察、审计和提交记录成追加事件，再由事件折叠得到当前状态。当前状态是物化视图，事件日志是审计依据。事件可写成

e_k=(id_k,t_k,role_k,type_k,payload_k, parent_k,env_k). \tag{11}

parent 指向所依据的目标或前一状态版本，env 记录环境快照。事件 ID 保证幂等：同一个 Executor 结果因重试送达两次，只应用一次。事件类型决定允许修改哪些字段，Auditor 事件不能偷偷改变原始目标。物化状态为

S_n=\operatorname{fold}(S_0,e_1,\ldots,e_n). \tag{12}

fold 应尽量确定。给定相同事件序列和 schema 版本，恢复出的任务状态一致；否则进程重启可能改变完成判定。模型生成的自由文本可以作为事件载荷，但关键枚举、版本与证据指针要由确定逻辑解析和验证。 checkpoint 用于缩短重放时间。系统在版本 $m$ 保存 $C_m=S_m$ 与事件前缀哈希，恢复时验证哈希后只重放 $e_{m+1:n}$ 。checkpoint 不是新权威来源；发现损坏时仍可从更早快照或完整日志重建。事件日志也保留失败价值。执行失败不会进入 verified state，但错误输出、环境差异和 Auditor 解释进入 failure evidence，下一轮 Manager 可据此避免重复。若失败只被覆盖成一句「再试一次」，长任务会在上下文刷新后重新踩坑。

删除和隐私要求需要单独处理。追加日志不意味着永久保存敏感载荷；可把事件元数据与加密内容分离，删除内容密钥后保留最小审计记录。具体治理超出论文主实验，但一旦 Harness 用于真实用户任务，这个边界不能交给模型临场决定。

子任务合约如何编译出来，Manager 生成的 subtask contract 不能只写「继续完成项目」。合约需要明确输入状态、允许动作、目标对象、成功条件、禁止副作用、预算和返回证据。Executor 拿到 fresh context 后，只靠这份合约和必要环境就能工作。一个合约可以抽象为

K_i=(G_i,I_i,A_i,C_i,F_i,B_i,E_i), \tag{13}

$G_i$ 是局部目标， $I_i$ 是依赖输入， $A_i$ 是授权动作， $C_i$ 是验收谓词， $F_i$ 是禁止条件， $B_i$ 是预算， $E_i$ 是要求返回的证据。缺少 $C_i$ ，Auditor 无法判定；缺少 $A_i$ 与 $F_i$ ，fresh context 可能扩大权限；缺少 $I_i$ ，Executor 会重新探索已知事实。合约粒度存在权衡。太大时，Executor 仍要在一轮内维护漫长状态，失败影响范围广；太小时，角色切换与审计成本吞噬执行时间，还可能把一个不可分割操作切断。合理边界常出现在可独立验证的里程碑：一个测试通过、一份文件完成、一个页面保存或一个外部事务提交。

可逆性也影响粒度。批量删除前先生成目标清单并单独审计，删除动作自身形成另一合约；写草稿可以合并多步，因为可轻易回退。不可逆操作前应缩小合约，使授权和证据更精确。从总目标编译子任务时要保持覆盖。设目标条件集合为 $R$ ，子任务验收集合为 $C_1,ldots,C_m$ ，至少要求

R\subseteq\operatorname{Closure} \left(\bigcup_{i=1}^{m}C_i\right). \tag{14}

也就是说，每条最终要求都能由若干已验证子条件推出。若某项没有任何子任务覆盖，它会成为孤儿要求；所有局部任务都成功，最终仍无法证明总目标完成。 Manager 还应检查重叠。两个合约同时修改同一文件或 GUI 对象，会产生写冲突；若必须并行，分别声明读写集合并在提交时检测版本。仅靠自然语言说「不要互相影响」不足以隔离环境。

1.1. Auditor 的独立性来自信息和权限

换一个角色名不会自动获得独立审计。若 Auditor 直接读取 Executor 的长篇自述并沿用其中结论，它容易被锚定；若使用同一上下文缓存和工具状态，也可能继承执行者的错误假设。独立性需要在输入与权限上实现。 Auditor 最少读取原始合约、当前环境和必要的执行痕迹。Executor 的声明可以作为待验证清单，不能作为事实。验证文件应重新读取文件与 diff，验证程序应运行测试，验证 GUI 应观察实际界面。环境提供不了的事实明确标成 unknown。

只读权限是为了防止审计过程顺手修复结果。Auditor 若一边检查一边改文件，最终通过时无法分清成功属于 Executor 还是审计者，也破坏了失败重现。官方实现将 Manager/Auditor 与可写 Executor 分配不同角色权限，这属于 MEA 语义的一部分。只读并非绝对无副作用。运行测试可能写缓存、数据库或临时文件，打开 GUI 也可能触发自动保存。环境层需要定义「观察动作」及其允许副作用，必要时使用快照或隔离副本。否则 Auditor 仍可能改变被审对象。

模型相关错误会在相同模型的多个角色间相关。使用不同 prompt 能降低上下文污染，却不能保证认知独立。高风险条件可使用确定性验证器、不同模型或人工检查。角色分离提供流程独立，不等于统计独立。审计深度应随风险调整。低风险格式检查用脚本即可；事实正确性需要来源对照；不可逆发布还需权限与目标确认。若每轮都调用最强模型完整复查，成本过高；若只做表面文件存在检查，verified state 没有多少价值。

完成判定是一项证明义务，长程系统常把「没有下一步」误当完成。Manager 找不到动作，可能因为状态丢失、预算耗尽或规划失败。完成必须由最终要求与有效证据推出，而非由 Agent 停止生成推出。设最终要求为 $R={r_1,\ldots,r_n}$ ，当前有效证据集合为 $E$ ，完成条件为

\operatorname{Done}(S,E)= \bigwedge_{i=1}^{n}\operatorname{prove}(E,r_i) \land \operatorname{Open}(S)=\varnothing \land \operatorname{Conflict}(S)=\varnothing. \tag{15}

每条要求都要有证据，不能还有未决阻塞或状态冲突。证据还需绑定当前环境版本；旧版本上的通过记录不能证明当前产物。某些要求无法机器证明，如文章是否有阅读欲望。Harness 可以保存人工审查或多模型判断，但要标明证据类型与置信边界。unknown 不能自动当 pass。若用户允许在证据不足时停止，应单独记录为内容上限或已接受风险。提前停止也有合法情况：预算达到上限、外部依赖不可用或用户取消。它们对应 stopped、blocked、cancelled 等终止原因，不应统一显示 completed。清楚的终止语义让后续恢复知道还欠什么。

最终回复只能从 verified state 生成，官方仓库的新版本也强调这一点。若回复重新读取全部未审计对话，Executor 的夸大陈述可能绕过状态门。自然语言交付可以润色，但完成清单和证据链接来自同一可信状态。

1.2. 恢复、预算与环境一致性

checkpoint 能恢复内部状态，却不能撤销所有外部副作用。发送邮件、发布内容、扣费和删除远程资源往往不可逆。Harness 需要在动作前区分可回滚、可补偿和不可逆操作。可回滚操作保存旧版本并原子替换；可补偿操作不能消除历史，但能执行反向业务动作，例如发送更正或恢复备份；不可逆操作只能在事前加强确认和审计。Manager 的计划应把这些类别写进合约。一个长事务可用 saga 表示为动作与补偿对

(a_1,c_1),(a_2,c_2),\ldots,(a_k,c_k). \tag{16}

若 $a_j$ 失败，按逆序尝试 $c_{j-1},\ldots,c_1$ 。补偿本身也可能失败，因此每一步要记录执行证据与当前外部状态，不能假设调用成功。幂等性降低重试风险。Executor 超时不代表动作未发生，盲目重试可能创建两次订单或提交两份表单。给动作分配幂等键，恢复后先查询结果，再决定是否重发。无法查询时，状态进入 inconclusive，交给人工或专门核对。代码和文件任务常利用版本库实现回滚，但工作区可能包含用户未提交修改。checkpoint 不能用破坏性 reset 覆盖整库，应记录本次动作的精确文件与补丁，回滚只触碰授权范围。Harness 的恢复语义必须尊重环境所有权。

故障注入应覆盖 Executor 进程崩溃、动作完成但回复丢失、Auditor 超时、审计后环境变化和补偿失败。仅测试「命令返回非零」无法代表真实长任务的模糊故障。

预算分配是受约束控制问题，MEA 每轮会产生 Manager、Executor 与 Auditor 三份开销。增加审计强度通常提高可靠性，也减少可用于执行的预算。固定三等分没有依据，预算应随任务风险和剩余不确定性变化。设第 $t$ 轮选择合约 $g_t$ 与审计强度 $d_t$ ，期望进展为 $\Delta P(g_t,d_t)$ ，成本为 $C(g_t,d_t)$ ，失败损失为 $L(g_t,d_t)$ 。调度可写成

\max\sum_t\mathbb E[\Delta P_t-\lambda L_t] \quad\text{s.t.}\quad\sum_tC_t\le B. \tag{17}

系统不需要精确求解这个优化，但分解说明决策变量。高价值不可逆步骤提高 $d_t$ ，探索性只读步骤降低审计，重复失败的合约缩小范围或更换执行器。角色模型也可不同。Manager 需要稳定分解和状态理解，Executor 需要工具能力与领域知识，Auditor 需要怀疑性和证据读取。按角色选择模型比所有调用统一最高档更容易控制成本。论文显示不同模型与后端均有收益，但没有证明任意廉价组合都保持效果。

预算耗尽前应预留收尾。若全部 token 花在执行，收尾阶段没有能力做全局审计和生成交付，局部进展再多也无法证明完成。可以设置验证储备 $B_v$ ，执行阶段不得使用。成本曲线需要与成功率一起报告。Terminal-Bench 的结果同时出现成功率上升和 token 减少，说明 fresh context 与有界子任务可能避免重复；在 GUI 任务中，额外观察和审计也可能显著增加开销。不能从一个基准推断所有环境都更省。

并发执行需要读写集合，MEA 的基本循环是串行的，但真实任务常有互不依赖的子任务。并行可以缩短墙钟时间，也会引入状态合并和环境竞争。Manager 只有在知道每个合约读写哪些对象时，才能判断是否安全并行。令合约 $K_i$ 的读集合为 $R_i$ 、写集合为 $W_i$ 。两个合约无冲突的充分条件是

W_i\cap(R_j\cup W_j)=\varnothing, \qquad W_j\cap(R_i\cup W_i)=\varnothing. \tag{18}

若都只读同一对象，可以并行；一方写入另一方读取或写入，就需要排序、锁或版本校验。自然语言任务很难一次准确列出全部集合，因此环境层还应在实际提交时检查 diff。文件路径只是粗粒度对象。同一 Markdown 文件中两个 Agent 修改不同章节，路径集合仍冲突；尝试自动行级合并可能破坏目录、引用或术语一致性。对共享结构频繁的文档，串行合约往往更安全。对不同论文文件，文件级隔离已经足够。

数据库和 GUI 的隐含状态更复杂。两个合约操作不同页面，却共享登录态、剪贴板或筛选条件；终端任务共享当前工作目录和环境变量。Environment 协议要暴露这些全局资源，否则 Manager 会错误地判定独立。并行结果基于同一个父状态版本 $v_0$ 。合并时分别验证 $v_a,v_b$ 的环境差异，若写集合无交集且验收仍成立，可以形成 $v_{ab}$ ；发现冲突则保留两个审计结果，不直接把自然语言报告拼接。状态合并需要三方比较：共同祖先、分支 A、分支 B。

失败分支也不能污染成功分支。一个 Executor 改坏共享依赖后失败，另一个 Auditor 可能在受污染环境上通过。最稳妥的方式是每个并行写任务使用隔离工作区或快照，审计通过后再合并。没有隔离能力时，必须扩大冲突范围并串行执行。

2. 验证器覆盖率决定可信状态上限

Auditor 再强，也只能验证环境中可观察的性质。单元测试通过能证明被测输入，无法证明所有边界；页面截图能证明某一时刻的外观，无法证明交互流程；文件存在无法证明内容正确。verified 的语义必须限定在验证器覆盖范围内。对要求集合 $R$ 和验证器集合 $V$ ，定义覆盖矩阵

M_{ij}=\mathbf 1[v_j\text{ 能对 }r_i\text{ 提供有效证据}]. \tag{19}

若某一行全零，该要求目前不可验证。Manager 应生成新的检查、请求人工或把它保留为未知，不能因为其他要求都通过就整体完成。覆盖还有强弱。静态检查只证明语法，运行测试证明特定环境行为，生产观测可能证明真实部署结果。可以为证据定义等级与有效期，高风险要求必须达到最低等级。低等级证据可推动计划，却不能关闭最终义务。组合验证器能覆盖更复杂条件。文章长度由脚本计数，事实由一手来源核对，风格由人工审查，三者共同支持「内容达到要求」。若只用字符数，系统会学会灌水；若只用语言模型判断，长度和 NUL 等硬条件可能漏掉。

验证器自身也会出错。测试可能 flaky，judge 可能偏好某种措辞，截图识别可能漏掉遮挡。对随机验证器记录多次运行和置信区间；对确定脚本保存版本与命令；对关键结论使用异质证据，降低同源错误。覆盖率可以指导下一步投入。若失败主要来自执行，换强 Executor；若大量状态停在 unknown，优先增强观察与验证；若验证通过后仍终局失败，检查要求分解和覆盖矩阵。把所有问题归因于模型能力，会掩盖 Harness 本身的瓶颈。

环境漂移会使正确证据过期，长任务跨越数小时甚至数天，文件、网页、依赖服务和登录态都会变化。Auditor 在版本 $v$ 上得到的真结论，不自动适用于 $v+1$ 。任务状态需要保存证据的环境版本和失效条件。设证据 $e$ 支持要求 $r$ ，有效性谓词为

\operatorname{valid}(e,t)= \mathbf 1[e.\text{object\_version}=v_t] \mathbf 1[t<e.\text{expiry}] \mathbf 1[e.\text{assumptions hold}]. \tag{20}

对象未变化、未超过时效且前提仍成立，证据才能继续使用。文件哈希适合内容版本，数据库事务 ID 适合数据状态，网页则可能需要抓取时间和内容快照。漂移检测要区分相关与无关变化。仓库里另一目录被修改，不应使当前测试全部失效；依赖库版本变化可能影响整个构建。依赖图把环境对象连到证据，只重验受影响闭包。没有依赖信息时，只能全量重审或冒险沿用。

外部服务尤其难。一次 API 成功不保证稍后仍可用，价格和权限也可能改变。对即时完成条件，审计时刻的成功足够；对持续性要求，需要观察窗口或健康检查。验收语义要明确是「曾经成功」还是「当前持续满足」。环境漂移也可能使失败证据失效。旧版本缺少某功能，更新后已经修复，Manager 若永久记住「这条路不可行」会错过机会。failure evidence 同样带版本和适用前提，恢复规划时重新判断。

2.1. Fresh Context、故障与适配器

每轮给 Executor 空白上下文，可以切断错误自我叙述和不断膨胀的聊天历史，也会丢掉难以结构化的局部推理。Harness 的效果取决于合约和状态能否把真正需要的信息重新提供。可把上一轮历史 $H$ 对当前动作的必要信息记为最小充分状态 $T(H)$ 。fresh context 实际提供 $hat T(H)$ 。若 $hat T$ 缺少关键约束，Executor 会重复探索或做错；若包含大量未经验证叙述，污染又被带回来。状态设计目标是让 $hat T$ 接近可审计充分统计量。

fresh context 也改变模型行为。长历史中的失败尝试可能产生锚定，新会话更愿意换路；同时，上一轮形成的短期技巧和工具格式消失。对照实验应固定总 token，比较原始历史、摘要历史、verified state 和 fresh contract，而非把上下文刷新与预算变化混在一起。某些任务需要连续交互态，例如 GUI 中已经打开的模态框或终端里的交互式进程。Executor 上下文可以刷新，环境状态不能被误重置。新 Executor 要从观察恢复当前态，或由环境 adapter 提供会话句柄。把 fresh context 理解成重启所有工具，会破坏任务连续性。

反过来，危险的隐式状态应清理。shell 当前目录、临时凭证、剪贴板内容和浏览器焦点若未进入合约，下一轮可能继承意外条件。Environment 在每轮开始时应重置可重置部分，并显式报告保留部分。

角色错误不是独立事件，Manager、Executor 和 Auditor 即使分别调用，也可能共享同一模型、训练数据和盲点。Manager 错误理解目标后，Executor 会忠实执行，Auditor 又按同一错误合约验证，整个循环形式正确但方向错误。设三个角色各自错误概率为 $p_M,p_E,p_A$ 。若错误独立，整体漏检概率可以按乘积估算；现实中存在相关性 $\rho$ ，共同误解会显著提高同时失败概率。仅增加相同模型的角色数，并不能获得独立投票的指数收益。降低相关性有几种手段：Auditor 直接读取原始目标而非只读 Manager 合约；关键条件使用确定性脚本；不同角色使用不同模型或提示；对高风险动作加入人工批准；用反例和负向测试而非只验证期望路径。

原始目标应始终可追溯。Manager 分解多轮后可能发生语义漂移，最终局部合约彼此一致，却遗漏用户最初的一条边界。每次全局 checkpoint 或最终审计都要将 verified state 对回原始要求，而非只对上一轮状态。 Auditor 也可能过度严格。它把未覆盖但无关的条件当失败，会造成无休止循环；把风格偏好当硬权限，会阻塞安全动作。验证规则需要区分硬约束、软偏好和未知，并记录失败原因供 Manager 调整。

3. 故障注入比成功案例更能说明问题

正常轨迹通过只能证明系统在理想条件下工作。Harness 声称可恢复，就应主动破坏不同环节，观察可信状态是否保持、重复副作用是否避免、进展能否恢复。对 Manager，可注入遗漏要求、循环生成相同合约、使用过期状态和预算估计错误。系统应由覆盖检查、重复检测、版本门和预算守卫捕获。若只能等 Executor 失败才发现，管理层保护不足。对 Executor，可注入进程退出、部分写入、超时后实际成功、越权修改和伪造完成声明。环境 diff 与独立审计应区分这些情况；动作幂等键用于处理「回复丢失但副作用已发生」。

对 Auditor，可注入假阴性、假阳性、无法访问环境、读取旧快照和验证器超时。状态机应把无法判断与失败分开，对关键阳性可要求第二证据。Auditor 崩溃不能让 observed 自动升级为 verified。对存储层，可损坏 checkpoint、重复事件、乱序送达或丢失收尾阶段一条提交。事件 ID、哈希链和重放测试应检测异常。若恢复结果与崩溃前不同，要能定位分叉事件。对环境，可在审计后提交前修改文件、撤销登录、升级依赖或删除外部资源。乐观版本检查应拒绝过期 commit，再由 Manager 计算受影响范围。不能让旧审计覆盖新现实。

实验报告至少给故障检测率、错误提交率、恢复成功率、恢复轮数、重复副作用数和有效进展损失。只报告最终是否做成，会掩盖系统可能通过昂贵全量重做偶然恢复。

从论文数字读出什么，论文报告 Qwen 3.7-Plus 在 WeaveBench 从 51.8% 提升到 80.7%，Terminal-Bench 2.1 从 69.7% 到 77.2%，OSWorld 2.0 从 2.8% 到 8.3%；Claude Opus 4.7 在一个 OSWorld 子集从 20.0% 到 34.3%。这些数字支持跨模型和多环境的一致方向，但增益大小强烈依赖基准可观测性。 WeaveBench 的 GUI+CLI 任务通常能通过文件、界面和命令共同验证，MEA 容易积累可靠进展。Terminal-Bench 有强终态测试，基础 harness 已较高，绝对增益较小。OSWorld 的视觉状态和应用交互更难观察，即使相对提升明显，绝对成功率仍低，说明 Harness 无法弥补底层模型与环境控制的全部缺口。

比较时还要注意指标。OSWorld 同时报 Binary 与 Partial，部分进度上升不等于完整任务完成；WeaveBench 的 Overall 与 PassRate衡量不同层面。不能把不同指标的百分点放在一起排序。样本数决定不确定性。WeaveBench 114 个任务、OSWorld 108 个任务时，单个任务就接近一个百分点；子集结果区间更宽。若没有逐任务配对结果，仅凭端点难判断增益是否集中在少数任务类型。复现应保存任务级成功和成本。论文证明的是特定模型、后端、提示、环境与版本组合。官方仓库后续增加 Codex、OpenCode、DeepSeek Harness 和 Web workbench，属于产品扩展；不能用论文数字直接担保这些新组合的同等增益。每个 adapter 都要重新验证权限、输出解析和进程清理。

AgentAdapter 必须保持哪些语义，Adapter 要把不同 Agent 的运行方式映射到同一角色合约，远不只是替换命令行参数。后端可以有自己的工具循环、消息格式和权限系统，Harness 仍要保证 Manager/Auditor 只读、Executor 在限定工作区可写、退出状态和输出事件可解析。一个 adapter 至少实现启动、输入合约、流式事件、终止、取消和结果归一。归一结果应区分正常完成、模型拒绝、工具错误、超时、被取消和进程崩溃。全部压成非零退出码，会让恢复策略失去信息。

权限映射最容易产生语义裂缝。Harness 声明 read-only，后端却允许 shell 写入；或 workspace-write 被后端解释成整个用户目录可写，都会破坏隔离。集成测试应让 Manager 尝试创建文件、Auditor 尝试修改环境，确认操作在运行时被拒绝，而非只检查配置文本。取消同样需要真实实现。用户停止任务或目标变化时，Harness 发出取消信号；后端若忽略，旧 Executor 可能稍后写回过期结果。优雅停止超过期限后升级为强制终止，并标记可能存在的部分副作用。仓库后续版本专门加强这条路径，说明它不是普通 UI 细节。

输出解析不能只抓收尾阶段一句。原生 Agent 可能产生 JSONL 事件、工具输出、增量文本和最终消息。adapter 要保留工具执行证据与最终状态，避免一段截断日志被当完整报告。解析版本应随后端升级测试。替换后端时需要契约测试，而非只跑一次 demo。准备同一组假任务：只读角色越权、Executor 部分成功、超时取消、长输出截断、Unicode 路径和环境变量隔离。所有 adapter 应产生等价规范事件，MEA 上层才真正可替换。

3.1. 安全、进度与能力归因

Manager 和 Auditor 的只读、Executor 的有限写入，都要由操作系统、沙箱或工具层强制。提示词写着「不要修改」只能降低误操作概率，无法抵抗提示注入或模型失控。角色权限属于可信计算基。最小权限还随合约变化。编辑一个目录不需要访问浏览器 cookie，操作网页不需要读取整个仓库密钥。Manager 根据读写集合生成能力令牌，Environment 在动作时校验。授权在子任务结束后失效，避免后续 fresh Executor 继承旧权限。外部内容可能向 Executor 注入指令，Auditor 也可能在读取恶意文件时受影响。来源数据与 Harness 控制消息必须分通道，网页中的「忽略验收标准」不能修改合约。Auditor 应验证环境事实，不执行被审内容提出的操作。

秘密处理需要特殊规则。Executor 可能需要令牌完成任务，但报告和事件日志不能保存明文；Auditor 可以验证操作结果，不一定需要读取凭证。工具层提供句柄或受限调用，比把密钥放进 prompt 更安全。审批属于授权升级。系统发现下一步需要发送消息、发布或删除时，暂停并向用户展示精确对象与影响；批准绑定该动作和状态版本。环境在等待期间变化，旧批准不能扩大到新对象。把一次「允许」保存成永久全局权限会破坏合约边界。

进度不能由动作数量计算，执行十个命令可能毫无进展，一个正确修改也可能完成大半任务。Harness 的进度应来自已验证要求，而非轮数、token 或工具调用量。前文的 $P_i$ 使用条件权重，权重本身也需有明确来源。对依赖图，简单按节点均权会高估细碎步骤。可以按最终要求分配总权重，再在其证明子图内分摊，确保拆成更多子任务不会凭空增加进度。若一个条件必须与另一个共同成立，二者完成前的部分分数要谨慎解释。

有些进展可被后续动作破坏。测试通过后修改同一模块，旧测试证据过期，进度应下降；用户看到回退并不代表系统退步，而是可信度更新。隐藏下降、始终单调显示百分比，会把过期事实伪装成成果。进度还可以区分「实现完成」与「证据完成」。文件已经写好但未审计，前者上涨、可信进度不变；审计通过后才进入完成。这样能解释 Auditor 队列积压，而不会误报任务已经结束。

估计剩余时间时，历史轮次平均值往往失真，因为后期集成和终局验证更贵。Manager 可按未完成条件类型估算成本，并给区间。无法估计就报告未知，不能用线性外推制造确定性。

3.2. 三类反例界定 Harness 的上限

第一类是不可观测任务。用户要求「让文章更有感染力」，环境没有客观测试，Auditor 只能做主观判断。多角色能提供第二意见，却不能把审美变成真值。系统应保留证据类型和分歧，而非宣称独立审计已经证明质量。第二类是不可恢复环境。一次外部交易失败就造成永久损失，没有快照、补偿或查询接口。Harness 可以在事前缩小权限并加强确认，事故发生后仍无法恢复。流程可靠性不能突破环境物理边界。

第三类是错误目标分解。Manager 漏掉核心要求，所有子任务和 Auditor 都围绕错误合约工作。最终原始目标审计能发现遗漏，却可能已经浪费大量成本。模型能力和要求编译质量仍决定上限。还有一种常见假成功：验证器与实现共享同一个错误假设。代码按错误公式实现，测试也复制同一公式，Auditor 运行测试全部通过。异质证据、手算样例和外部规范对照可以降低风险，无法彻底消除。

这些反例不否定 MEA。它们说明 Harness 擅长把可观察、可分解、可恢复的长任务变成稳定状态推进；面对主观目标、不可逆世界和共同认知错误时，仍需要人工判断、领域验证与更强模型。

任务分解也需要被验证，Manager 把总目标拆成子任务，本身就是一次高影响推理。分解结果若遗漏、重叠或顺序错误，后续执行再可靠也无法完成原目标。Harness 需要对计划结构做静态检查和动态修订。静态检查先看覆盖、依赖与边界。每条最终要求至少映射到一个验收条件；依赖图无环或明确允许迭代；每个子任务有有限作用域；不可逆动作具有前置确认。计划还要检查是否存在永远无法满足的组合条件。

动态检查使用执行反馈。连续两轮合约都没有增加 verified progress，可能是粒度过大、验证器缺失或路径错误。Manager 应缩小任务、补充观察或换方案，而非用不同措辞重复同一指令。可以定义停滞指标

Z_k=\sum_{t=k-m+1}^{k} \mathbf 1[P_t-P_{t-1}=0], \tag{21}

最近 $m$ 轮全部零进展时触发重规划。失败证据表明环境暂时不可达，则进入等待或 blocked，不继续消耗执行预算。分解还要避免「验收替代目标」。例如用户要正确分析论文，Manager 把它拆成字符数、标题数和链接数，所有机器条件都满足，事实仍可能错误。硬检查只是部分证明，语义要求需要来源与内容审查。容易验证的代理指标不能取代原要求。反事实计划测试能发现隐含依赖。假设跳过子任务 $g_i$ ，最终要求是否仍可由其余证据推出？若可以， $g_i$ 可能冗余；若删除某节点导致多个看似无关条件失去依据，说明依赖图需要显式记录。这个测试不必实际重跑所有轨迹，可以先在证明图上分析。

Auditor 错误的代价并不对称，假阳性把错误结果写进可信状态，后续计划会在错误地基上继续；假阴性拒绝正确结果，主要造成返工和成本。高风险任务通常更怕假阳性，因此审计阈值应偏保守，但过度保守会让系统无法推进。设假阳性概率为 $p_{fp}$ 、损失为 $L_{fp}$ ，假阴性概率为 $p_{fn}$ 、损失为 $L_{fn}$ ，审计策略的期望风险为

R=p_{fp}L_{fp}+p_{fn}L_{fn}+C_{audit}. \tag{22}

发布、删除和资金操作的 $L_{fp}$ 很大，应使用强证据或人工确认；草稿格式检查的 $L_{fn}$ 可能更大，因为重复审查只浪费时间，阈值可以宽松。多重审计能降低风险，但前提是错误不完全相关。两个相同模型读同一截图，可能同时漏掉遮挡；脚本加人工视觉形成异质证据更有效。串行验证还可以先用便宜检查过滤，只有通过后调用昂贵审计。 Auditor 应输出证据与理由，不能只给分数。理由使 Manager 知道修哪一项，证据使最终状态可复查。模型置信度不是校准概率，高置信 pass 仍需满足客观谓词。

审计规则升级后，旧证据可能失效。发现测试漏掉关键边界，应标记所有依赖旧版本验证器的状态，并按影响重跑。只从下一轮采用新规则，会让同一任务内出现两套完成标准。

4. 模型能力与 Harness 能力应分开测

模型决定一轮内能理解和执行什么，Harness 决定多轮之间如何保存、验证和恢复。把二者混在终局成功率里，难以知道升级哪一层。可以固定模型比较不同 Harness，观察状态漂移、重复工作和恢复；也可以固定 Harness 更换模型，观察单轮合约成功率和审计质量。二维矩阵比只比较端点更有解释力：弱模型可能连有界子任务也做不好，强模型则可能在简单任务上不需要复杂 Harness。单轮能力指标包括合约遵守、工具成功、局部验收和越权率。Harness 指标包括 verified progress 保留率、错误提交率、故障恢复、重复副作用和跨轮要求召回。终局指标由两层共同决定。

存在互补效应。fresh context 降低强模型的长上下文负担，独立审计约束其过度自信；较弱模型得到清晰小任务后也可能改善。但 Harness 无法创造模型从未拥有的视觉识别、领域推理或工具操作能力。训练 Agent 时也应匹配 Harness。若训练轨迹允许模型依赖全部聊天历史，部署时每轮 fresh context 会分布偏移；若训练要求输出结构化证据和 bounded subtask，适配更自然。推理框架与训练目标并非完全独立。

完整轨迹、复现与验收，考虑任务「修改程序、通过 Linux 与 Windows 测试、生成报告且不得发布」。初始要求集合为四项：实现 $r_1$ 、Linux 验证 $r_2$ 、Windows 验证 $r_3$ 、禁止发布 $r_4$ 。所有状态为 pending，环境版本为 $v_0$ 。第一轮 Manager 生成修改合约 $K_1$ ，写集合是两个源码文件，验收为 diff 符合接口并能编译。Executor 修改后声称成功，状态进入 observed；Auditor 重新读取 diff 并编译，在 $v_1$ 上通过，于是 $r_1$ 获得证据 $e_1$ 。第二轮运行 Linux 测试，得到 $e_2$ ， $r_2$ verified。第三轮 Windows 服务不可用，Auditor 返回 inconclusive， $r_3$ 保持 pending，并记录外部依赖。系统此时的可信进度若四项等权为 $2/4$ ；禁止发布是持续约束，不能因为「没有发布」就提前关闭。

第四轮用户修订接口，源码版本变为 $v_2$ 。依赖图显示 $e_1,e_2$ 都绑定旧实现，因此 $r_1,r_2$ 降为 stale；Windows 未验证仍 pending。进度回落诚实反映证据过期，并不代表状态丢失。第五轮重新审计实现并跑 Linux，第六轮 Windows 服务恢复并通过。最终审计确认三项积极要求都有当前版本证据，环境事件中没有发布动作， $r_4$ 作为全轨迹不变量通过。Done 才变为真。若第三轮 Executor 私自发布，Auditor 应记录违反 $r_4$ 。后续删除发布内容可能是补偿动作，却不能抹掉已经发生的外部传播；最终状态需要说明事故和补偿，不能简单恢复为从未发布。

这条轨迹展示了 observed、verified、inconclusive、stale 与 violation 的区别。把它们全压成 success/fail，无法正确处理外部等待、目标修订和持续约束。

4.1. 复现实验需要冻结哪些条件

第一步冻结任务与环境。GUI 应用版本、屏幕尺寸、登录态、初始文件和网络条件都会影响 OSWorld；Terminal-Bench 要固定容器镜像、测试脚本与超时。环境不一致时，成功率差异无法归因于 Harness。第二步冻结模型与采样参数。Manager、Executor、Auditor 可以使用不同模型，必须分别记录版本、temperature、reasoning effort 和最大 token。只写一个「backbone」不足以复现角色分配。再次冻结 adapter 与 prompt。官方仓库快速迭代，不同 release 的权限映射、进程清理和最终回复逻辑可能变化。论文实验应对应特定提交，产品最新版结果应另行报告。评测目录中的 frozen compatibility copy 也不能与主库代码混用。

每项任务保留逐轮事件、合约、环境版本、审计证据、token 与墙钟成本。只有终局分数无法复查失败原因，也不能计算进度与恢复指标。涉及隐私的轨迹可脱敏，但脱敏规则同样要记录。随机性要求多次运行或至少固定种子。长任务昂贵时样本有限，应报告任务级配对变化：哪些从失败变成功、哪些反向退化。平均提升可能掩盖 Harness 对某类任务有害。复现还要核对统计口径。PassRate、Binary、Partial、Overall 和 token 分解不是同一指标；子集结果注明筛选方式。超时算失败、跳过还是缺失，也会改变分母。

LongHorizon-Harness 真正改变了什么，它没有给基础模型增加新的参数或知识，也没有保证每个 Auditor 都正确。它改变的是可信状态的生成路径：执行者的陈述先降级为待验证观察，独立角色从环境取证，只有通过验收的事实进入跨轮记忆；下一轮从原始目标和 verified state 重建，而非继续继承完整聊天。这条路径把长任务的主要风险从「模型能否一直记住」改写成几个更可检查的问题：状态 schema 是否覆盖目标，合约是否有界，验证器是否观察到真实条件，证据是否仍适用于当前版本，故障后能否从可信 checkpoint 继续。每项都可能失败，但失败位置更清楚。

对短任务，额外循环可能不划算；对无法观察的目标，独立审计也没有神奇真值；对不可逆世界，恢复能力受环境限制。它最适合依赖多、执行时间长、环境可检查且局部成果可保存的任务。理解这篇工作的关键，是把 Harness 看成状态管理与验证协议，而非三个 Agent 轮流说话。模型给出候选动作，环境给出事实，状态机决定哪些事实可以跨轮。真正的长程能力就建立在这条边界上。

人工接管如何进入同一状态机，长任务里人工接管不应成为绕过审计的旁路。用户可能纠正目标、直接完成某一步、批准高风险动作或提供外部事实，这些都要形成带来源的事件，并按类型进入状态。用户修改目标时，Manager 先生成目标版本差异，标出受影响合约与证据；用户完成环境动作时，Auditor 仍需观察结果，不能因为操作者是人就自动 verified；用户提供事实若无法从环境核对，可标记为 user-asserted，并明确它的信任等级。

审批事件至少绑定动作、对象、范围、环境版本和有效期：

a=(op,target,scope,v_{env},t_{expire}). \tag{23}

Executor 只能执行匹配的动作。目标文件在等待审批期间变化，旧批准失效；批准删除一个缓存目录，不扩展到其他相似目录。精确绑定能防止自然语言「可以」被解释成无限授权。人工也可能撤回要求。撤回事件使未执行合约取消，运行中动作尝试停止，已产生副作用按补偿协议处理。历史事件保留撤回记录，当前状态不再把旧要求列为义务。简单从 prompt 删除旧句子无法达到同样语义。

接管后恢复自动执行时，Manager 从最新目标和 verified state 重新规划，而非接着接管前的 pending 动作。这样能避免用户刚修正方向，后台旧 Executor 又把结果写回来。所有仍运行的 worker 要带目标版本，提交时进行版本门检查。

4.2. 如何比较不同长程循环

单 Agent 长上下文、摘要循环、反思循环、MEA 和更重的多角色 runtime 都能提高部分任务。公平比较需要固定基础模型、工具、环境、总预算和最终验证器，分别改变跨轮状态协议。比较维度至少包括状态来源、执行上下文、验证独立性、恢复单位和副作用控制。单长上下文把聊天历史当状态；摘要循环用生成文本替换历史；MEA 只允许审计事实进入持久状态。它们的 token 长度可能相近，可信语义却不同。

对每条任务记录同一组过程指标：首次错误出现轮次、错误进入持久状态的比例、重复动作、有效进度、恢复损失、审计成本和最终成功。若 MEA 只靠更多调用取胜，成本曲线会显现；若 fresh context 真正减少自我污染，错误提交率和重复动作应下降。还应比较失败类型。摘要循环可能遗漏约束，反思循环可能强化错误叙述，MEA 可能被弱 Auditor 阻塞，多角色系统可能花费过高。一个平均成功率无法告诉使用者应在哪种任务上选哪条路线。

预算扫描比单点更可靠。在低、中、高三档调用预算下绘制成功率与成本，观察哪种方法先饱和。Harness 若只在极高预算有效，部署价值有限；若中等预算已经减少返工，则状态协议本身有贡献。

任务结束时，Harness 从状态生成机器可查、人能读懂的结果。每条原始要求对应状态、证据 ID、环境版本和仍存在的限制；跳过项保留原因，补偿过的事故继续留在记录中。生成过程遍历要求—证据图，把当前有效证据投影成自然语言。模型可以组织措辞，但不能新增未在状态中的成功声明。若某项证据只支持部分范围，报告也保持相同范围。

提交记录、测试输出、截图和人工批准都可作为证据，但应引用稳定对象。临时终端文字若未保存，最终报告无法复核；截图没有时间和对象标识，也难证明对应版本。证据采集应在每轮 Auditor 阶段完成。清单还要暴露成本与风险：总轮次、角色 token、墙钟时间、恢复次数、未知项和不可逆动作。用户由此判断结果是否值得信任，也能决定是否继续投入预算。若最终验收发现一项失败，任务重新打开相应节点，而非把整条运行判为毫无成果。verified state 保留仍有效部分，Manager 从缺口继续。这正是外置状态相对一次性长对话最实际的收益。

4.3. MEA 应满足的最小性质

把前面的机制压成形式约束，MEA 至少要满足安全性、活性、幂等性和可恢复性。安全性要求没有有效审计证据的声明永远不能进入 verified state：

\Box\left(q_i=\text{verified} \Rightarrow \exists e:\operatorname{valid}(e)\land e\vdash r_i\right). \tag{24}

活性要求在环境可达、预算充足且合约持续有可执行动作时，系统不会永久停在 pending。它不保证任务必然成功，只排除调度器无故饿死某个可推进节点。幂等性要求重复接收同一事件、审计报告或动作确认，不会产生两次状态提交。网络重试和进程恢复都依赖这条性质。外部动作若无法天然幂等，要用动作键、结果查询或补偿协议封装。可恢复性要求从可信 checkpoint 与之后事件重放，得到与故障前一致的任务状态；外部环境发生不可重放变化时，系统至少能检测差异并把相关证据降级，不能静默假装一致。

还有一条容易被忽略的保守性：未知不能提升为已完成。观察缺失、验证器超时和模型没有提到某项，都保持 pending 或 inconclusive。长程系统最大的诱惑是为了继续推进而把空白补成成功，状态门必须明确拒绝。这些性质可由小规模确定性测试验证。构造几条人工事件序列，穷举重复、乱序、崩溃和环境版本变化，检查不变量；再让真实模型填充合约内容。先证明状态内核，再测试语言模型表现，比只跑昂贵端到端任务更容易定位错误。

最终，Harness 的价值不取决于角色名称，而取决于这些性质在真实工具和环境中是否成立。Manager、Executor、Auditor 可以换模型、换后端，可信状态的边界不能随之漂移。验收这些性质时还要覆盖用户中途修改目标。旧版本下合法的动作在新版本中可能越界，旧证据也可能只支持已撤销要求。事件日志应保留两版目标的关系，正在运行的 Executor 返回时先核对版本，再决定复用、重验或丢弃产物。若系统只在每轮开始读取目标，长时间动作仍可能把过期结果写入当前状态。

同一套版本门也适用于人工审批和外部回调。任何迟到结果都先证明自己仍对应当前目标，才有资格进入审计与提交阶段。

产品落地对照见 ../../../essays/oasis-improvements-2026-08-harness-wave.md。