《Claude Code 和 Codex 的 Harness 设计哲学》读书笔记（第 1 章 - 第 8 章）

章节关系图

第 1 章 为什么要把 Claude Code 和 Codex 放在一起看

章节总结

这一章先把比较对象纠偏了：不是比较两个“会写代码的助手”谁更顺手，而是比较它们如何处理“模型不可靠”这件事。作者认为，真正有价值的地方在于，Claude Code 和 Codex 都没有把模型直接当作执行主体，而是各自发展出一套驯化不确定性的 harness。

Claude Code 更像一条运行时优先的路线，重点放在 query loop、工具编排、compact 与恢复这种“系统如何继续活着”的问题上; Codex 则更像显式控制面优先的路线，把 instructions、skills、sandboxing、exec policy、thread state 等边界拆成明确模块。两者都在回答同一个问题，只是起笔位置不同。

内在联系

本章奠定整本比较书的读法：后续章节不是简单横评功能，而是沿控制面、连续性、工具治理、本地制度和多代理验证五条轴线展开。第七章的“殊途同归”判断，正是从这里预埋下来的。

常见疑问

为什么不直接比较谁支持更多工具、谁体验更好？因为这些差异解释不了架构为什么长成这样。只有回到“系统如何不被模型反过来支配”这个问题，才能看出设计哲学。

现实启发

评估 agent 产品时，与其问“它会不会”, 不如问“它怎么防自己乱来”。后一个问题更接近真实工程价值。

第 2 章 两种控制面

章节总结

作者指出，控制面首先不是文风问题。Claude Code 和 Codex 都把面向模型的指令当成行为控制的一部分，但实现方式不同。Claude Code 更像动态装配线：默认 prompt、memory、本地规则、输出风格会在运行时拼装成同一控制面。Codex 则更像结构化片段系统：instruction fragment 有明确来源、边界和类型，用户指令也被有序地装入可区分的上下文单元中。

两者差异不只是实现趣味，而是系统气质差异。前者偏向按场景实时组装控制面，后者偏向先把制度层显式化、结构化，再让运行时在其上执行。

内在联系

第一章讲“为什么值得比较”, 本章则给出第一条比较轴：秩序住在动态装配过程中，还是住在更显式的制度片段里。第五章关于 AGENTS.md、CLAUDE.md 与技能系统的差异，就是这条轴线的延伸。

常见疑问

显式控制面是不是天然优于动态拼装？作者没有这样下判断。显式化更利于治理和复制，动态装配更贴近现场需求; 关键不在谁高级，而在团队当前最缺的是哪种秩序。

现实启发

如果你的 agent 经常出现“大家以为规则一样，实际注入顺序完全不同”, 那就该提升显式度; 如果规则已经写得很多却无法适应现场，就该反过来检查装配机制。

第 3 章 心跳放在哪

章节总结

本章聚焦连续性。作者强调，代理系统的关键不是多轮聊天，而是上一轮做过的事如何被下一轮可靠承接。Claude Code 把连续性压进主循环，在 loop 状态里处理消息序列、工具上下文、compact 追踪和恢复计数。Codex 则把连续性拆到线程、rollout 和状态桥等更显式的器官上，让状态的安放位置更容易被审计和管理。

两种方案带来不同结果。Claude Code 更像一台会话发动机，擅长在运行中自我校正; Codex 更像把连续性拆成多个可治理部件，牺牲一些现场流畅感，换来更清晰的状态归属和策略接口。

内在联系

第二章讨论控制面如何组织，本章继续追问“执行过程的秩序住在哪里”。它也为第四章和第六章做铺垫，因为工具治理和多代理协作最终都要落到连续性管理上。

常见疑问

为什么状态安放位置会影响产品定义？因为状态在哪里，就意味着谁对恢复、审计和生命周期负责。连续性不是技术细节，而是责任分配。

现实启发

如果团队的 agent 经常“上一轮懂、下一轮忘”, 不一定是模型记性差，更可能是连续性被放在了一个不可治理的位置上。

第 4 章 工具、沙箱与策略语言

章节总结

这一章比较的是“谁来阻止模型动手太快”。Claude Code 更偏运行时调度：并发安全、审批结果、中断处理、流式执行和上下文回填都在执行现场完成。Codex 更偏工具与策略层先设防：工具 schema、审批参数、策略引擎和 sandboxing 先把可执行边界显式定义清楚，执行时再按这些制度落地。

作者特别指出，沙箱与审批不只是安全机制，也是产品定义问题。系统究竟把多少权力交给模型，多少交给用户，多少交给策略语言，会直接影响 agent 的协作方式与风险形态。MCP 和扩展工具的出现，又把边界进一步外移，让“谁来定义外部能力的可信接口”成为新问题。

内在联系

第三章说明连续性如何组织，本章则比较执行动作的最后解释权在哪。第六章关于委派、验证与状态持久化的讨论，实际上就是这里的治理逻辑在多代理条件下的延展。

常见疑问

运行时审批和策略语言是不是二选一？不是。作者更像是在提醒：你把控制重心放在哪一层，就会得到不同的系统性格。真正糟糕的是两边都没有，只剩模型临场发挥。

现实启发

设计工具平台时，不能只看“功能接入是否统一”, 还要看审批语义、策略表达和沙箱边界是否一开始就可复用，否则规模化后会很难管。

第 5 章 技能、Hook 与本地规则

章节总结

作者把这一章概括为“系统如何学会守乡约”。任何通用 coding agent 真正落地以后，都必须吸收公司、仓库、目录和团队的局部制度。Claude Code 的答案更像现场经验沉淀：CLAUDE.md、skill、hook 和 session memory 共同把局部规则注入当前会话。Codex 的答案更偏结构化挂载：把本地规则、技能和事件系统做成更明确的注入点与生命周期接口。

因此，Claude Code 偏“经验收编”, 适合复杂而多变的现场; Codex 偏“制度挂载”, 更利于组织复制和统一治理。两者的差异，其实就是第二章控制面差异在地方化层面的具体表现。

内在联系

前四章讨论的是通用控制层，本章开始进入局部制度与组织环境。第八章之所以能给出“不同团队该先学谁”的建议，基础就在这里。

常见疑问

为什么本地规则不是简单文档问题？因为只有进入会话、执行和生命周期，规则才算真正成为系统能力。留在 Wiki 里的规则，对 agent 来说仍然是系统外信息。

现实启发

如果团队想让 agent 稳定适配多仓库、多目录和多角色，就必须尽早决定：本地知识是作为现场记忆沉淀，还是作为结构化制度挂载。这两种路径会影响后续全部扩展方式。

第 6 章 委派、验证与持久状态

章节总结

这一章的切口很硬：多代理问题的核心不是效率，而是责任。Claude Code 更强调用多代理处理运行时职责分区，把探索、执行、综合和验证拆开，防止“完成”由执行者自己宣布。Codex 则把委派做成正式工具能力，让 spawn、wait、send、close 等协作动作进入显式工具系统，与线程和状态桥一起构成更清晰的协作接口。

作者还指出，持久状态的重要性在于让验证不只是礼貌动作。只要状态可被桥接、记录和回放，验证与恢复就有了真正的抓手。否则多代理再华丽，最后仍可能退化成自我表扬链。

内在联系

第五章处理局部制度如何进入系统，本章处理这些制度在多人协作与长任务中如何维持责任清晰。第七章的总判断，正是在这里完成从“局部差异”到“整体路线”的收束。

常见疑问

为什么验证必须单独拿出来？因为执行代理天然有完成偏见。无论是 Claude Code 还是 Codex, 真正成熟的地方都在于不让系统自己给自己打高分。

现实启发

团队做多代理协作时，最容易忽视的不是分工，而是收口。谁来验证，谁来等待，谁来关闭上下文，谁来记录状态，这些都必须有明确答案。

第 7 章 殊途同归

章节总结

作者在这一章先说“同归”: Claude Code 和 Codex 都已经越过“模型更强就能自动解决系统问题”的幼稚阶段。它们都承认 prompt 不足以控制全部、工具必须受约束、长会话需要状态治理、本地规则必须进入系统、多代理必须有验证。

但作者也强调“各表一枝”。Claude Code 的主轴是从 query loop 出发，用运行时调度、compact、中断与恢复维持秩序; Codex 的主轴则更像先把 instructions、tool schema、approval policy、thread state、hook event 和 skills 这些制度层显式化，再让运行时按制度执行。目标相同，重心不同。

内在联系

这是全书的总比较章，前六章的所有轴线都在这里汇合。第八章之所以能进一步给出“怎么学”的建议，也是因为这一章已经把分歧归纳成可操作的路线判断。

常见疑问

既然都能到达同一个目标，是否说明实现路径无关紧要？不是。路径决定团队最先解决什么问题，也决定后续系统更擅长在运行时补救，还是更擅长靠显式制度提前设防。

现实启发

比较两个 agent 系统时，不要只看结果是否相似，还要看秩序被放在哪一层。因为维护成本和扩展方式通常就藏在这里。

第 8 章 如果你要自己做

章节总结

最后一章把比较转成方法论建议。作者反对把比较文写成“二选一购买指南”, 认为真正的问题是：如果你要自己做一套 harness, 或准备重构现有 agent, 应该先学谁的哪一部分。Claude Code 适合提醒团队重视 query loop、工具收口、中断恢复和验证独立这些运行时脏活; Codex 适合提醒团队尽早把 instruction 来源、tool schema、approval policy、thread state 和 hook event 显式化。

书中还给出面向不同团队的起手方向：已有原型但长会话经常失控的，往往先学 Claude Code; 已经出现规则不清、审批混乱和组织复制困难的，往往更该先学 Codex。比较的真正用途，不是站队，而是少走弯路。

内在联系

这是建立在前七章之上的应用章。它把“控制面差异”“连续性差异”“工具治理差异”和“本地制度差异”重新翻译成团队起手顺序。

常见疑问

“显式”与“灵活”是不是天然对立？作者明确反对这种误区。显式制度可以为灵活运行提供边界，灵活运行也可以检验显式制度是否过于僵硬，两者本应互相校正。

现实启发

自己做 agent 时，最现实的路径往往不是全学某一家，而是先诊断团队当前最痛的问题在运行时还是制度层，再决定先借哪一套骨架。

全书脉络小结

《Claude Code 和 Codex 的 Harness 设计哲学》不是一篇产品横评，而是一部关于“秩序住在哪一层”的比较笔记。它先说明比较对象是两种驯化模型不确定性的路线，再依次对照控制面、连续性、工具治理、本地规则和多代理责任分区，最后收束为一个判断：两者确实殊途同归，但一条更偏运行时纪律，一条更偏制度层先设防。

对读者真正有用的，不是得出谁更先进，而是学会在自己的系统里辨认短板：你缺的是会话心跳与恢复能力，还是显式控制面与本地制度挂载能力。只有先把这个问题答清楚，比较阅读才会转成实施路线。