附录 B：检查清单 — 如何判断你的 Harness 更像 Claude Code、Codex，还是半成品
出处
来源：原网页 · 状态：已读 · PDF：book2-comparing.pdf p.46–49
一句话
原则如果不能落成检查清单，最后很容易只剩一些表述完整却难落地的判断。 这张表不是给两套产品打分，是用来露出自己系统把秩序放在哪一层——或者还没放。
核心概念
B.1 控制面
- 每条 instruction 是否有
{source, type, precedence}，fragment 可识别 - prompt 中 control-plane 与 output-style 是否明确区分（文风不等于秩序）
- 本地规则的作用域（
CLAUDE.md/AGENTS.md）是否显式标注 - team 规则变更是否可通过 diff 追踪（非口头约定）
答不上来，控制面仍停在「能用就行」。
B.2 连续性
- 连续性主权是否属于
{main loop, thread+rollout+state}之一，归属明确 - 中断是否同步闭账（synthetic tool_result 兜底也算）
- 长会话是否有 compact / truncation / recovery 三件套
thread.id/ 会话索引 / 状态落地是否为系统一等概念
若长会话主要靠模型自己「记得住」，基本不必再看。
B.3 工具与审批
- tool 是否为 schema 化接口，
additional_properties=false - approval policy 是否可独立评估（不混在代码 if/else 里）
- 危险工具（Bash 等）是否有专门治理（非一视同仁）
{workdir, network, sandbox, approval}是否可显式表达
只会说「我们也有权限控制」，基本等于没设计权限。
B.4 本地治理
- 本地规则是否可按
{目录, 团队, 任务类型}分层 - skill 是否视为可复用制度切片，而非长 prompt（有版本/来源）
- hook 是否挂在明确生命周期事件（pre/post/session_start/stop）
{skill, rule, hook}是否具备{version, source, trigger boundary}
B.5 多代理与验证
- 多代理的第一目的是否职责分离，并行只是附带（否则是把混乱并行化）
- 是否存在独立 verifier（verifier ≠ implementer）
- 委派是否为显式工具或显式状态事件，而非 runtime 魔法
- 子代理
{failure, timeout, cancel}是否有明确 cleanup owner
B.6 你更像哪一类系统
更像 Claude Code：看重主循环、工具编排、中断、compact 与恢复；规则能迅速进现场会话；关心 agent 在复杂任务中持续跑。
更像 Codex：看重 instruction fragment、tool schema、approval policy、thread / rollout / state；本地规则做成结构化资产；关心组织内长期治理。
更像半成品：名词两边都会说，秩序归属却说不清；入口很多，恢复路径不清；规则文本很多，却缺作用域与优先级；有多代理，却无责任分离与收尾。
B.7 最后六问
- 谁拥有最终控制权，模型还是 harness
- 连续性主要住在 loop 里，还是住在线程和状态里
- 工具动手前，谁来拦最后一道
- 本地规则怎么进入系统，怎么分层
- 验证由谁负责，如何独立
- 出事以后，团队靠什么追溯
这六句问下来，系统大概属于哪一派，通常也就露出来了。
B.8 阈值与顺序速查
| 名称 | 值 | 作用 | 源 |
|---|---|---|---|
MAX_ENTRYPOINT_LINES | 200 | 入口文件行数上限 | Book 1 第 5 章 / memdir/memdir.ts |
MAX_SECTION_LENGTH | 2_000 | session memory 单节上限 | SessionMemory/prompts.ts |
MAX_TOTAL_SESSION_MEMORY_TOKENS | 12_000 | 会话记忆总预算 | SessionMemory/prompts.ts |
AUTOCOMPACT_BUFFER_TOKENS | 13_000 | autocompact 警戒缓冲 | compact/autoCompact.ts |
MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES | 3 | 熔断阈值 | compact/autoCompact.ts |
yield_time_ms | per-tool | 单次 exec 阻塞毫秒上限 | local_tool.rs |
wait_agent.timeout | min/default/max | 子代理等待窗口 | agent_tool.rs |
| Bash 子命令数 cap | implicit | 复合子命令上限 | bashPermissions.ts |
事件顺序：
session_start→user_prompt_submit→pre_tool_use→ tool exec →post_tool_use→stopspawn_agent→send_input*→wait_agent→close_agent（cascade 关闭后代）- prompt too long → collapse → reactive compact → 若仍过长则 surface 错误（不再循环）
关键洞察
清单的作用不是保证系统自动变好，而是防止一些最常见、也最无聊的错误反复出现。半成品的典型信号不是「功能少」，而是名词两边都会说、秩序归属说不清。六问比功能表快。
个人思考
对照 Book 1 附录 A：那边按器官列（runtime / prompt / tool / compact / recovery / verification / team）。这边按比较轴列，并多了一栏「你更像哪一类」。自己做 harness 时，先拿 B.7 六问过一遍，比先画架构图有用。过不了 B.2 和 B.5 的，先别谈 skill 市场。