Appearance
Coding Agent 如何形成闭环：Planner / Generator / Evaluator、Recovery 与 Artifact Contract
前置：Coding Agent 如何跨 Context 持续推进：Skills、Incremental Progress 与 Handoff
核心问题：Planner、Generator、Evaluator 中任一步失败或进程重启后，Coding Agent 怎样从可验证 artifact 恢复并继续闭环？
Planner 决定修改 3 文件，Generator patch，Evaluator 先跑 formatter/tests；只有设计质量才可能用模型 review。sandbox 崩溃但 snapshot 完整可创建新 session；git working tree 与预期 hash 不符则停止自动 patch 并重新 diff。
Planner / Generator / Evaluator
Planner、Generator、Evaluator 是三个认知责任：前者决定小步目标，中间产生修改，后者验证结果。它们可以由同一个 Agent 在不同阶段承担；验证优先复用 compiler/formatter/tests 等确定性证据，只有无法程序判定的设计质量才需要模型 review。
Workspace Failure Recovery
command crash、patch partial、test fail、sandbox restart 都要能从 git/checkpoint/snapshot 恢复，并区分环境失败和代码失败。
恢复需区分 command failed、workspace corrupted、patch conflict、dependency/environment drift、sandbox lost。不同情况选择 retry、restore snapshot、re-read 或人工介入。
Artifact Lifecycle / Output Contract
最终输出应引用 artifact 而非只说“已生成”。
Artifact 从创建、验证、发布、引用到过期/删除应有生命周期；Output Contract 规定最终必须有哪些产物及验证元数据。
Coding Agent 的闭环不是“生成一次代码”
一个更稳定的阶段循环是：
text
inspect evidence
→ plan small change
→ apply patch
→ run targeted verification
→ inspect diff/result
→ update progress/artifact
→ decide next step是否拆成多个物理 Agent，应由 context isolation、权限隔离或独立质量责任驱动，而不是因为流程里出现了三个角色名称。
Recovery 要从 Workspace 事实重新判断，而不是续写上一句
进程 crash 后，新 Agent 先读取 base revision、dirty diff、test report、progress record 和 pending command，而不是假设旧 transcript 的最后一句仍然准确。若上一次 patch 已写入但 test 未跑，恢复路径应从 verification 继续，而不是再次生成相同 patch。
这要求 Artifact Contract 明确每个阶段输出什么：patch/ref、test evidence、review decision、final artifact。恢复因此成为普通状态推进，而不是“让模型回忆之前做了什么”。
🔍 源码对照：Turn settle 把完成事实、Checkpoint 与后处理分开
完整源码与通用分析见 09-06 Checkpoint / Pause / Resume。这里不重复代码；这里关注 Coding Workflow Recovery：恢复应基于已提交的 checkpoint、artifact 与 test evidence 推进，而不是让模型重新猜测已经完成了什么。
源码说明
Workflow、subagent runtime、crash guard、observation 同时存在，说明 Coding Agent 的闭环不是 Planner 单独完成：探索策略可以由模型动态决定，但 patch/test/artifact verification、crash recovery 和最终 acceptance 需要 deterministic Runtime facts。
工程边界
不要从 Grok 的 workflow 结构推导我们的 Planner/Generator/Evaluator 必须是三个 Agent；它们可以只是角色、函数或不同 step。
Shadow Harness 对照
- 完成条件由 verification artifact 驱动，例如 test exit code/diff，而不是“模型认为已修复”。
- 每个增量 patch 后写 progress/checkpoint，避免长任务失败时重新探索全部仓库。
验证
在 patch 成功、test 尚未执行时 crash；resume 后必须从“待验证”继续，而不是把 patch 重放或直接宣告任务完成。
关联源码
自测
- Generator 修改代码后 Evaluator 发现测试失败。Recovery 应回到“重新生成全部”还是保留哪些已验证 artifact 再继续？
- Planner、Generator、Evaluator 三个角色如果都能直接改 Runtime state，会破坏什么 ownership？