Harness 循环、状态与恢复

npm run learning:harness -- resume

对应 S22～42，重点理解 AI 开发任务如何连续执行、在何处停下、凭什么恢复。代码依据是 src/learning/ai-harness/runtime.ts 和 demo.ts。当前模型为固定脚本替身，仓库为内存对象，不调用真实 LLM，不修改真实文件，也不把 checkpoint 写入磁盘。

实践校准：2026-09-12。第 10～11 节补充当前异步工具与中途调整方向的机制；其中 OpenAI API 行为按当日 OpenAI Docs 核验，任务表和时间线为本文原创设计推演，不是本仓库已实现或真实调用的结果。

1. Agent 不能只是“调用模型，直到它说完成”

普通函数往往已有明确算法：输入两个数，按确定规则求和。AI 开发任务则不同：“找出 sum 为什么算错并提议修改”规定了目标，却没规定先搜哪里、读哪个文件、怎样定位原因。模型可以补充这部分策略，但“提出下一步”与“让下一步真正发生”必须分开。

上下文 c_t = Select(任务约束, 运行状态 s_t, 可用证据)
动作建议 a_t ~ Policy(c_t)
下一状态 s_(t+1) = Transition(s_t, Validate(a_t), 工具结果)

Policy 是模型策略：根据当前所见提出 read、search 或修改建议，真实模型可能产生不同答案。Transition 是环境的状态转移规则：是否允许读取这个路径、是否还有预算、文件版本是否匹配、结果应该记到哪里。它不能因为模型说“我认为安全”就跳过这些条件。模型输出 read('.env') 不会自行获得读取权限。

因此，自主性放在动作选择里，授权与资源规则放在宿主程序里。像操作系统管理进程一样，系统不替程序决定每个业务步骤，却规定它能使用哪些资源。对于 AI 开发，模型负责提出候选行为，harness 负责把候选行为转换成受约束的调用，用户决定目标与允许的变更范围。

本例 ModelPort = (context) => Promise<unknown> 特意返回 unknown。TypeScript 类型不能保证网络响应或模型生成内容符合协议，所以必须运行 actionSchema.parse(raw)。先确认动作类型和字段，再检查具体权限及前置条件。一个字段齐全的 edit，仍可能因为基础版本陈旧而被拒绝：格式有效不等于语义有效。

执行循环依次做：构造上下文、检查上下文大小、等待模型、解析动作、执行受限工具、记录观察与事件、判断是否继续。理解这个顺序，才能知道错误发生在哪一层，以及哪些工作已经发生、哪些尚未发生。

2. 五种“记忆”分别在记什么

聊天历史、运行变量、日志、checkpoint 和交接摘要都保存信息，但它们服务的读者与正确性要求不同。

2.1 State 是运行事实，不是模型自由编写的总结

steps = 2 必须由执行器维护，不能从“我大约执行了两步”这样的文本里推断。readHashes['src/sum.ts'] = H 表示工具曾向本轮运行提供过该文件版本；proposals 保存尚未应用的修改预览。模型可以声称“已经读过”，但只有 read 成功后，运行时才更新 readHashes。

这个记录也不证明模型理解了整份文件。本例 read 最多返回 1000 个 UTF-16 code units 的内容，并附上 truncated 标记。长文件被截断时，“执行过读取”不能解释成“完整代码已检查”。记录的语义越具体，后续越不容易过度推断。

2.2 Context 是状态的投影，会丢弃信息

buildContext 只给模型最后一条 observation 和已提案文件路径，不给全部 events、全部 readHashes 或全部 proposal 内容。这样能控制大小，但较早的线索可能不再可见。完整 state 在宿主内存中，不代表模型自动“记得”；真实任务要根据下一步问题重新选取证据。

本例固定保留任务目标与权限清单，只截断工具观察。这表达了一种优先级：宁可少给材料或停止，也不能为了省空间丢掉授权边界。它仍是简单教学策略，没有实现检索、摘要质量判断或多轮记忆管理。

2.3 Events 不天然等于可重放历史

本例事件有 step / kind / detail，足以帮助人理解动作顺序，却没保存完整模型请求、原始响应、全部动作参数和每次环境版本，也没有实现 reduce(events) => state。所以不能宣称“删掉状态后，只用事件就能完全重建运行”。

真正的事件溯源需要定义：事件是已发生的事实，还是待执行的命令；哪些字段足以确定地重建状态；schema 变化如何迁移。日志用于解释，事件流用于重建，两者可以共享数据，却不能仅凭 event 这个名字就认为具有相同保证。

3. 沿完整执行，看状态怎样变化

npm run learning:harness -- workflow

输入是虚拟仓库与任务契约：

// 内存字符串，不是执行后被覆盖的真实源文件。
'src/sum.ts': 'export const sum = (a: number, b: number) => a - b;\n'
'README.md': 'sum(a, b) should return the sum of two numbers.\n'

objective: 'Inspect why sum subtracts and propose a minimal fix. Do not apply changes.'
readPaths: ['README.md', 'src/sum.ts']
editPaths: ['src/sum.ts']
maxSteps: 6
contextChars: 4000

虚拟仓库还有 .env 合成占位文件，但不在 readPaths 中。搜索只遍历允许读取的文件，不是先搜全库，再把不允许的结果隐藏。

3.1 初始化：没有事实就不能假装已有事实

initialState 检查预算是否合法、可编辑路径是否也可读、允许读取的文件是否存在。初始值是 steps 为 0、status 为 running、readHashes/proposals/events 为空，observation 为 No file has been read yet.。这些字段描述机器已知事实，而非模型对任务难度的判断。

3.2 Search：获得线索，不获得编辑资格

模型收到 context.step 为 0，脚本返回：

{"type":"search","query":"sum"}

收到返回值后，运行时先将 steps 加为 1，再验证动作。搜索得到 README 和源文件的匹配行，observation 变为带 untrusted_search_result 标记的 JSON，事件追加 { step: 1, kind: 'search', ... }。

此时 readHashes 仍为空。搜索摘要只是定位证据，不是完整读取，也没有建立编辑的基础版本。这里的“不可信”指文件内容不能成为新授权，而不是说搜索结果完全没用。

3.3 Read：把所见内容绑定到版本

第二次上下文 step 为 1，脚本返回 read('src/sum.ts')。工具检查路径，计算内容指纹 H，写入 readHashes['src/sum.ts'] = H，返回：

kind: untrusted_file
path: src/sum.ts
baseHash: H
content: export const sum = (a: number, b: number) => a - b;
truncated: false

H 是 64 位十六进制指纹的符号代称，不是实际值。本项目 fingerprint 先将值转成规范化 JSON 形式，再做 SHA-256；对字符串会包括 JSON 编码，因此不等同于对原始源文件字节直接运行 sha256sum。

此时 steps 为 2，两个事件已记录，proposals 仍为空。关键变化不是“模型一定懂了”，而是后续提案必须指向这个明确读过的版本。

3.4 Propose：候选变更不能冒充环境事实

第三次脚本从 lastObservation 取出 H，返回：

type: propose_edit
path: src/sum.ts
baseHash: H
before: a - b
after: a + b

执行器检查：路径允许修改；readHashes 与提案版本一致；该文件尚无其他提案；当前源内容指纹仍等于 H；before 恰好出现一次；before 与 after 不相同。通过后才在字符串副本上生成 preview，加入 proposals。

为什么检查两次版本？“读过的版本”防止对未观察文件直接猜改；“当前源版本”防止读完后文件已变化，旧判断被套到新内容上。二者分别对应证据来源与时效性。唯一替换检查消除“这个片段出现三次，到底改哪一次”的歧义，但不证明修改在业务语义上正确。

此时 steps 为 3，preview 包含 a + b，虚拟仓库仍保留 a - b。observation 明确说明未应用、未编译、未检查行为。下一轮模型得到的是“已有提案”，不是“仓库已修复”。

3.5 Finish：结束循环，留下准确边界

第四次脚本返回 finish，steps 增到 4。由于 proposals 非空，status 变为 needs_review，而非含糊的 success。proposedSource 是预览，virtualRepoUnchanged 比较运行前后的指纹，本演示应为 true：它证明虚拟仓库没变，不证明提案能编译。

四步轨迹由脚本按 step 返回动作产生，不是 LLM 自主完成任务的实测成绩。演示价值在于让状态转移可见，分清模型建议、运行记录与环境变化。

4. 暂停恢复的是程序状态，不是模型的脑内过程

npm run learning:harness -- resume

示例传入 pauseAfter: 2。循环在下一次模型调用前发现已经用掉两步，设置 paused 并序列化 state。此时 search/read 已完成，没有第三次模型调用处于进行中。

恢复先 parse JSON，再按 stateSchema 验证字段；随后检查任务与仓库指纹、状态必须为 paused、steps 不超过 maxSteps、事件数等于步数。通过后只将 status 改回 running。steps 仍是 2、readHashes 仍有 H、预算还剩 4 步。脚本接着 propose，不重做 search，事件最终按 1、2、3、4 连续出现。

这里 pauseAfter 是累计步数阈值，不是“恢复后再做几步”。恢复时若仍传 pauseAfter: 2，循环会立即再次暂停。如果 maxSteps 恰好也是 2，while 条件先因预算耗尽而结束，返回 budget_exhausted 而不是 paused。配置的真实语义取决于分支检查顺序。

当前只有 paused 状态会返回 checkpoint，其他终态不能通过 restoreCheckpoint 继续。不能把 budget_exhausted 的 JSON 改个 status 就称为正式的追加预算流程。真实系统允许追加时，应记录新授权及已消费量，而不是重置账目。

4.1 为什么一句“下一步改加号”不够

这句话没保存旧源版本、授权范围、已消耗预算和已产生提案。如果跨会话后用户已修改函数，盲目替换就可能覆盖新工作。checkpoint 保留这些前提，handoff 帮人快速理解；前者求精确，后者求可读。

摘要仍有价值，但应指向结构化事实，不应凭记忆重新创造事实。Anthropic 的长任务工程文章讨论跨上下文窗口的交接与增量进展；本例只借此学习状态交接，并未实现其完整工程环境。官方工程文章

4.2 同样状态，不保证真实模型走同样路径

脚本只看 step，恢复轨迹因此确定。真实 provider 还受模型版本、采样配置、输入序列等因素影响，即使状态相同，也不应承诺逐字复现。合理目标是“从已知事实和未完成动作继续”，而非重演隐藏推理过程。

如果需要知道过去一步到底建议过什么，应保存当时接受的动作和必要请求元数据，不能重新调用模型来猜原答案。外部工具恢复后也可能读到变化的世界。程序状态能恢复，与外部环境保持不变，是两个不同条件。

5. 内容指纹检测变化，不认证来源

本例字段名叫 signature，实现却是 fingerprint({ harness: 'teaching-v1', task, repo })。它检查任务、虚拟仓库、教学 harness 标识是否一致，没有密钥或公私钥操作，所以是内容一致性指纹，不是密码学签名。

README 变化后，即使代码文件未变，恢复也被拒绝，因为需求材料可能改变修复含义。指纹还包含未开放给模型的虚拟 .env 字符串，所以它变化也会使恢复失败。真实仓库可以考虑任务依赖快照以缩小范围，但范围太窄会漏掉影响判断的配置与依赖，不能只为恢复方便就随意排除。

这个指纹更不是对完整 checkpoint 的认证。有人若能修改 JSON，可以保留 signature，再篡改 observation、提案或计数。schema 只保证形状基本合法；事件数等于 steps，也不证明这些事件真实发生。本例明确假设状态来自可信调用方。

实际保存状态时，先解决谁能读写；跨信任域传递时，再按威胁模型选择消息认证或数字签名。加密解决保密问题，认证解决来源与完整性问题，不能互相替代。版本方面，当前没有将 provider、模型配置、上下文构建器版本完整纳入指纹，teaching-v1 也不是自动计算的源码版本。

6. 预算控制资源，不给学习者评分

6.1 步数预算数的是什么

本例每当模型正常返回一个值就 steps++，之后才解析动作。因此合法动作和被拒绝的坏动作都消耗一步；模型端口抛异常则不增加 steps、不追加动作事件，而是进入 model_error。step 不是成功工具调用数，更不是推理 token 数。

令剩余步数 R = maxSteps − steps。只要每次模型调用能结束、收到结果就让 R 减一，正常动作不会无限执行。但若一次 await model(context) 永不返回，循环就没机会检查 R。有限调用次数不保证有限墙钟时间。

重复 search('sum') 可能一直成功，却不产生新信息。预算最终能停下它；进一步可以结合重复动作与信息增量判断停滞，但重复不一定无用，例如查询尚未完成的外部任务。需要根据工具语义区分等待和空转，不能仅凭文本相同就禁止。

6.2 字符预算不是 token 与费用预算

本例比较 JSON.stringify(context).length 和 contextChars，计量的是 JavaScript 字符串的 UTF-16 code units，不是字节，也不是模型 tokenizer 的 token 数。模型输入受限，也不意味着 events 和提案的存储增长已获得完整管理；上下文大小与状态大小是两个维度。

真实调用会同时消耗输入 token、输出 token、工具次数、时间与费用，不能统一成“最多六步”。六次长输入可能比六十次短输入更贵；一个工具只调用一次也可能等待十分钟。

一种轻量资源策略是调用前保留本次允许开销，调用后按实际 usage 结算并释放多余量。如果有并发，要计入尚未结算的在途消耗，否则多个请求都看到“还剩预算”就会共同超支。超时且 usage 未知也不能一律算免费，应暂记未知并在取得记录后校准。当前示例没有实现这些账目。

7. 真实 provider 的超时、取消与重试

当前 model_error 仅捕获端口异常，不区分限流、网络失败、认证错误，也没有自动重试。这是教学简化，不能称为生产容错层。

先区分三件事：超时是调用方不愿再等；取消是向进行中的操作发出停止信号；远端确认停止又是另一条事实。Promise.race 让等待先结束，不会自动终止另一个 Promise 背后的网络请求。Node AbortController 为支持它的 API 传递取消信号；适配器与底层调用必须实际消费这个信号。Node 官方说明

真实适配器应接收任务截止时间和取消信号，调用前计算剩余时间并向下传递。超时后不要让迟到响应更新已终止的运行；旧工作进程被替换时，可以通过任务版本或租约代次阻止旧执行器继续提交。取消也不必然表示远端已停止计算或不再计费，要依具体 provider 协议判断，不能从本地 Promise 状态推断。

重试还需要区分原因。临时不可用可在时间与次数预算内退避；认证错误、权限拒绝、明确无效输入需要修正条件。模型动作格式不合法，可以带错误说明重新询问，但那是一次新决策，不是把旧工具动作再执行一遍。两者消耗和风险不同。

模型重试可能提出不同动作。应在动作被接受后给它稳定 actionId，再围绕该逻辑动作处理工具投递；不能每次网络失败都让模型重新决定操作，否则恢复对象已经变化。

8. 副作用与幂等：结果未知比明确失败更难

本例搜索、读取、修改预览都不写外部环境。若加入写文件、创建 PR 或触发构建，就会遇到典型失败窗口：

1. Harness 记录准备执行 action A
2. 工具完成外部操作，例如创建变更请求
3. 连接中断，成功响应没到达 Harness
4. Harness 只知道没有收到结果，不知道外部是否成功

不能将第 4 步直接解释成“失败，再创建一次”。没收到确认不等于没执行。聊天历史即使记住“我试过”，也不能消除这个分布式系统问题。

幂等指同一逻辑操作重复提交，不会产生第二份业务效果。可以让 actionId 在重试中保持不变，由真正实施副作用的工具服务保存 actionId → 已完成结果。重复请求查询或返回原结果，而不是再次执行。只在 harness 本地缓存成功响应不够，因为它覆盖不了“外部成功、本地未收到”的窗口。

Temporal 官方文档也区分了工作流恢复和 Activity 的重复执行，强调副作用应考虑幂等。这里学习的是这个失败模型，项目未接入 Temporal。Activity 与幂等说明

写文件也不是附上 idempotency key 就结束。必须检查基础版本，防止旧提案覆盖新代码；如果“读版本—写文件”之间有其他写者，单独前置比较仍有竞态，需要适合存储系统的条件写入、锁或版本化工作区。远端操作若没有可靠幂等接口，可以先查询可识别的已有结果，必要时交给人判断，不能随意承诺精确一次。

补偿不是时间倒流：提交后再 revert 是新操作，消息发出后更正也抹不掉已读内容。先把未知结果、重试与补偿的语义理解清楚，比立即搭复杂事务平台更有价值。

9. 从内存状态走向持久恢复

当前 checkpoint 只是返回对象里的 JSON 字符串，没有文件落盘、数据库、加密或崩溃恢复。进程退出后若外部未保存，它就消失。“能够序列化”只是有保存格式，不等于已可靠保存。

小型实现可以先用单一可信存储，不必直接建分布式平台。每条运行至少记录 runId、schemaVersion、revision、status、已消费预算、最近完成 actionId 和必要证据引用。revision 表达乐观并发条件：存储中的版本仍等于读取时的版本，执行器才可提交下一版本，以免两个恢复进程互相覆盖。

暂停成功应意味着必要状态已提交，然后才向调用者确认。对远端写操作，状态存储和外部副作用通常不能共享同一数据库事务，因此还要区分“待投递、结果未知、已确认”，并与幂等查询结合。增加状态字段不会自动产生可靠性，必须说明谁写、何时写、失败后怎么解释。

恢复也不能让旧权限永久有效。要确认当前用户仍有权访问任务与工具，同时保留原任务不能无声扩大的范围。权限收回就应停止，不能因为 checkpoint 写着允许而绕过现行授权。敏感工具输出还需要访问范围与保留周期，而不是无限存下整段上下文。

10. 异步不是一个开关：谁在等待，谁拥有未完成的工作

前面的串行循环每轮只有一个动作，因此“最后一条观察”暂时够用。接入慢工具以后，模型可能已经在回答另一部分问题，先前的查询却尚未完成。此时最重要的变化不是把函数前面加上 async，而是承认系统里同时存在多个未完成事实。

10.1 三种经常被混为一谈的异步

当前 await model(context) 属于第一行：等待期间 JavaScript 可以调度别的工作，但这个 Harness 循环不会进入下一轮。若应用并发启动两个 I/O，再等 Promise.all 成功后才把结果给模型，正常路径仍要等两者完成，模型没有在工具运行期间继续这轮工作。Promise 的调度与失败传播，是应用控制流；模型能否提前继续，是另一层协议。

OpenAI 当前异步工具允许模型发起工具后继续处理独立内容；工具仍由应用执行，结果使用原始 call_id 回传。官方兼容性说明限定为 GPT-6 Astra 及以后模型、应用执行的 function/custom 工具；不适用于 hosted 内建工具，也不应配置为 programmatic tool calling；多代理模式另有并行调用限制。这里是版本相关能力，不是所有模型的默认协议。OpenAI Docs：Async tool calling

Background mode 则让长响应先返回身份与状态，再查询结果；它解决的是生成生命周期与连接生命周期不同的问题。当前文档还说明后台执行会临时保存响应数据，即使使用 store=false 也不能把它理解为“服务端完全不存储”。这份远端状态不是自己任务的永久 checkpoint，采用前应核对模型支持、保留语义和恢复方式。OpenAI Docs：Background mode

从架构上看，三个机制可以服务不同需求，不能因名字都有“异步”就互相替代。用户关闭页面，可能只意味着客户端不再显示；一次模型响应结束，也可能仍有应用工具在运行。是否继续、谁接收结果、多久清理，都是宿主必须明确的生命周期。

10.2 四个身份：关联答案、恢复动作、查询工作和判断时效

考虑原创设计场景：AI 分析页面加载慢的原因，发起一个耗时的调用链查询，同时读取本地数据加载器。应用可保存如下任务记录。字段仅用于解释设计，不是 OpenAI 请求 schema，也不是现有 runtime 类型。

runId:          learn-loader-01      整个用户任务
taskRevision:   3                    发起时的目标与范围版本
actionId:       inspect-callers-01   已接受的逻辑动作
call_id:        call_A               Provider 协议中的这次工具调用
jobId:          worker-job-41        实际执行工作的查询句柄
inputSnapshot:  repo-R7              输入对应的仓库版本
execution:     running              实际工作仍在执行
delivery:      not_ready            还没有可交给模型的结果
applicability: current              当前任务仍需要这个结果

call_id 回答“这份结果属于模型提出的哪一次调用”；actionId 回答“这是同一个已接受操作的再次投递，还是一个新操作”；jobId 回答“去哪里查正在执行的工作”；taskRevision / inputSnapshot 回答“结果对现在的问题是否仍有效”。它们可以有映射，语义却不能合并。

例如连接断开，应用重新查询同一个 worker job，不应产生新的业务操作。若原工具服务支持幂等，重投时也应围绕同一个 actionId 查回已有结果。反过来，用户把查询范围从 R7 改为 R8，这已经是新输入，不能为了“去重”强行返回旧结果。协议 call_id 本身不证明外部服务实现了去重，更不能当成写操作精确一次的保证。

为什么将 execution、delivery、applicability 分开？因为“工具成功了”与“答案已经交给模型”是两件事；“答案交付失败”也不意味着应该重跑工具。一个查询可以 execution=completed，但 delivery=pending；一个取消请求可以已经发出，而 execution 仍为 running；旧版本结果可能完成，却已不再适用。用一个 success/failed 字段会抹掉这些恢复所需的信息。

10.3 双任务事件时间线：先完成的不一定先使用

下面只有事件顺序，没有测量延迟或声称并发加速。任务最初允许分析调用链并准备建议，不允许真正修改文件；所有数据均为教学设定。

T5 最容易出错：如果代码只是 state.observation = result，晚到的 A 会覆盖 B，模型以为现在又要分析全调用链。正确的接收端先按身份定位任务，再检查当前范围与输入版本，最后决定是否投递，而不是谁最后回来就相信谁。若权限已被收回，还要按当前保留策略处理结果正文；“为了日志完整”不是继续存储敏感数据的理由。

在采用异步工具协议且仍继续同一对话时，应用应给原调用返回真实结果或明确的取消/过时状态，而不是无声遗失关联；已经关闭的任务则不应被一个回调擅自唤醒。状态文本由自己的工具契约定义，不能凭空捏造 Provider 的通用 cancelled 输出 schema。新任务若确实需要旧证据，应重新核对授权、输入版本与用途，再明确引入。

10.4 等待是依赖关系，不是空转

如果下一步需要 A 和 B 才能比较，应等待缺少的依赖；如果只解释 B 就足够，就不该为凑齐结果拖住用户。应用可以用一个小型 pending 表维护这些关系，不必先部署通用工作流平台。给模型的观察应有“哪些结果已到、哪些仍在途、下一结论依赖谁”，而不是每次塞入全部后台日志。

并发也会消耗额外资源。假设当前还允许三次外部查询，已有两次在途，就只剩一次可以发起，而不是等它们返回后才扣减。将模型等待改为异步，没有改变工具的成本，也没有使失败更便宜。对同一文件写入、必须使用上一步生成 ID 的操作、权限尚未确认的查询，应先解决依赖与授权，再讨论并行。

对于本仓库四步 sum 演示，工具本来就很短，propose 又依赖 read 的 baseHash，串行模式更容易理解，也避免为了一个不存在的延迟问题增加任务表。应先识别真实关键路径，再选择异步；“更现代”不能替代“这个等待是否真的能与有用工作重叠”。

11. 中途调整方向：新指令不是把旧执行历史擦掉

用户在运行中说“先只解释，不要修改”，不是普通日志消息，而是目标与授权边界的更新。需要将两个问题分开：模型何时看到新要求，以及执行器从什么时候开始阻止已经不再允许的动作。前者是推理/通信问题，后者是控制问题。

11.1 Provider 接受了消息，不等于模型已经按新要求行动

截至 2026-09-12，OpenAI 的 mid-turn steering 指南要求 GPT-6 Astra 与 Responses WebSocket；response.steer.accepted 表示输入进入队列，而不是已经执行。它不会撤回已输出文本、回滚动作或自动取消已启动工具。需要应用补工具结果时，已接受输入可以继续 pending；应用应使用保存的结果继续，而不重复提交已接受的更新。OpenAI Docs：Mid-turn steering

可以把产品交互理解成三条不同事实：“已收到你的更新”“执行器已收紧后续动作范围”“后续响应已纳入新要求”。只有第一条时，不应向用户保证“全部旧工作已停止”。同样，模型已停止输出也不能证明远端工具没有产生效果。

这里有一个重要设计推论：如果更新收紧了权限，宿主应立即在自己的动作接收与投递边界应用约束，不能等待模型承诺遵守。如果新消息扩大了范围，则仍需要确认它确实来自有权限的用户；工具返回文本中的“顺便发布”不属于这类更新。模型负责据此调整策略，执行器负责保证新策略落实前不会继续放行越界动作。

11.2 版本栅栏：让旧回答失去继续执行的资格

设旧目标 revision 为 3。用户收窄范围后，宿主保存 revision 4，并把当前动作许可改为“只读解释”。随后旧模型响应才返回一份 revision 3 的修改提案。即使 JSON 完全合法，也不能按旧许可投递；执行器应将它归类为目标已变化下的陈旧建议，给后续推理提供新要求。

这和 H03 的文件版本检查是不同维度。baseHash 确认“代码还是所见的代码”，taskRevision 确认“用户还是要求做这件事”。源文件一字未变，用户也可能已经取消修改；用户目标未变，代码也可能已被另一人更新。安全继续至少需要两类前提都仍成立。

版本号不是魔法。检查版本与真正投递之间仍可能插入新更新；若需要严格防止这段竞态，动作调度器与范围更新应在同一个串行控制入口处理，或采用相应存储的条件提交。对已经发往远端的动作只能请求取消并核对结果，不能仅在本地把 revision 加一就假定它从未执行。学习时先画清这个边界即可，不需要先造分布式调度系统。

11.3 断线与降级：保留进展，不盲目重放

当前 steering 指南还说明，排队中的更新依附当前连接，并非原响应的持久内容。断线后应结合已记录输入和响应事件判断哪些更新已经生效，不能假定队列仍在，也不能看到断线就重复发送全部更新。OpenAI Docs：失败与断线处理

通用的学习模型是把每条用户更新记为“待发送、已确认接收、已进入后续响应、结果未知”中的明确状态。确认丢失时，unknown 比随意写 failed 更诚实。对于不支持原生 steering 的模型，可以在工具边界暂停，保存已经完成的结果，将新要求与仍适用的证据组成下一次普通请求；这能实现任务级改方向，但不应宣传为同一轮原生流式 steering。

无论采用何种传输，都应沿用任务级总预算。一个后续响应是新的 Provider 响应，不代表用户重新授权了一整套费用和工具次数。目标修订、模型响应、工具执行各有生命周期，Harness 的作用就是把它们连起来，又不混成一个含糊的“正在思考”。

12. 结束状态表达事实，不制造完成感

本任务只要求检查原因并提议修改，定位明确且未应用的提案就是合理交付；若目标是修复实际应用，同样状态显然不够。完成判定来自任务契约和已有证据，不来自模型自信程度，也不需要把所有任务升级成重型发布流程。

S22～28 沿执行链理解模型等待、工具等待和总延迟；S29～35 掌握状态与上下文的区别；S36～42 将恢复连接到动作身份、未知结果与幂等。任选一次 resume 演示，手工对照四步状态表即可，不需要额外故障矩阵。

最值得留下的认识是：可靠 Harness 不是强迫模型永不犯错，而是让动作有边界、进展有状态、恢复有前提、“完成”有明确含义。当前真实具备的是内存教学机制；远程 provider、持久执行、真实写操作与运行隔离仍属于后续设计。新增的异步 job 表、目标版本栅栏和 steering 时间线是理解这些机制的设计案例，现有代码仍串行等待 ModelPort、同步操作内存工具，没有实现这些新增能力，也没有运行对应的真实 API 调用。