附录 B 检查清单：如何判断你的 Harness 更像 Claude Code、Codex，还是半成品

比较如果不能落成检查清单，最后很容易只剩一些表述完整却难落地的判断。下面这份附录，就是把前面几章压成团队可直接讨论的清单。

B.1 控制面清单 (invariants)

assert every instruction has {source, type, precedence}        # fragment 可识别
assert prompt 中 control-plane 与 output-style 明确区分         # 文风不等于秩序
assert 本地规则的作用域（CLAUDE.md / AGENTS.md）显式标注
assert team 规则变更可通过 diff 追踪                           # 非口头约定

答不清这些，说明控制面还停留在"能用就行"。

B.2 连续性清单 (invariants)

assert 连续性主权 ∈ {main loop, thread+rollout+state}          # 明确归属
assert 中断 ⇒ tool_result 同步闭账（synthetic 兜底也算）
assert 长会话有 compact / truncation / recovery 三件套
assert thread.id / 会话索引 / 状态落地为系统一等概念

长会话若主要靠模型自己"记得住"，基本不必再看。

B.3 工具与审批清单 (invariants)

assert tool = schema 化接口，additional_properties=false
assert approval policy 可独立评估（不混在代码 if/else 里）
assert 危险工具（Bash 等）有专门治理                           # 非一视同仁
assert {workdir, network, sandbox, approval} 可显式表达

系统只能回答"我们也有权限控制"，基本等于没设计权限。

B.4 本地治理清单 (invariants)

assert 本地规则可按 {目录, 团队, 任务类型} 分层
assert skill 视为可复用制度切片，非长 prompt                   # 有版本/来源
assert hook 挂在明确生命周期事件（pre/post/session_start/stop）
assert {skill, rule, hook} 具备 {version, source, trigger boundary}

B.5 多代理与验证清单 (invariants)

assert 多代理的第一目的是职责分离，并行是附带           # 否则是把混乱并行化
assert 存在独立 verifier（verifier ≠ implementer）
assert 委派为显式工具或显式状态事件，非 runtime 魔法
assert 子代理 {failure, timeout, cancel} ⇒ 明确 cleanup owner

B.6 你更像哪一类系统

更像 Claude Code 的信号：

• 你最重视 query loop、工具编排、中断、compact 与恢复
• 你擅长让规则快速进入现场会话
• 你更关心 agent 如何在复杂任务里持续运行

更像 Codex 的信号：

• 你最重视 instruction fragment、tool schema、approval policy、thread / rollout / state
• 你擅长把本地规则做成结构化资产
• 你更关心 agent 如何在组织里被长期治理

更像半成品的信号：

• 两边的名词都说得出来，但谁负责秩序说不清
• 有很多能力入口，但没有清楚的恢复路径
• 有很多规则文本，但没有作用域和优先级
• 有多代理，但没有责任分离和收尾机制

B.7 最后六问

要是时间不够，只问这六句：

• 谁拥有最终控制权，模型还是 harness
• 连续性主要住在 loop 里，还是住在线程和状态里
• 工具动手前，谁来拦最后一道
• 本地规则怎么进入系统，怎么分层
• 验证由谁负责，如何独立
• 出事以后，团队靠什么追溯

这六句问下来，系统大概属于哪一派，通常也就露出来了。

B.8 阈值与顺序速查 (thresholds & orderings)

事件顺序速查：

• session_start → user_prompt_submit → pre_tool_use → tool exec → post_tool_use → stop
• spawn_agent → send_input* → wait_agent → close_agent（cascade 关闭后代）
• PTL → collapse → reactive compact → 若仍 PTL 则 surface 错误（不再循环）