在AI Agent从概念走向工程落地的今天，我们早已跨过了“让模型说对话”的初级阶段，转而面对更现实的问题，如何让一个会思考、会调用工具，但本质上不可靠的大模型，在真实的工程环境里稳定工作、不闯祸、可复用、可治理。这个问题的答案，从来不在模型本身，而在模型之外那层容易被忽略的约束系统，也就是Harness。

近期一份深度对比文档，将业内两套极具代表性的AI Coding Agent架构，Claude Code与Codex，放在同一标尺下拆解，没有陷入功能罗列的浅层对比，而是直击核心，两套系统如何承认模型的不可靠，又如何把秩序安放在不同层级。这不仅是两种技术实现的差异，更是两种工程哲学的碰撞，运行时优先与显式控制面优先，现场经验与制度设计，灵活应变与规范治理。读懂这份对比，就能避开Agent落地的绝大多数弯路，明白什么样的架构，才能支撑起真正可用、可规模化的AI代理系统。

一、先理清核心前提：我们比较的从来不是模型，而是Harness

很多人初次接触Claude Code和Codex，会下意识陷入功能对比，谁支持的工具更多，谁的终端操作更顺滑，谁的配置更丰富。但这份对比文档从开篇就打破了这个误区，两套系统的核心差异，从来不是模型能力，而是Harness的设计逻辑。

Harness本质上不是功能的堆砌，而是一种权力分配方式，它决定了谁拥有最终控制权，谁定义系统边界，谁解释运行状态，谁承担纠错责任。无论是Claude Code还是Codex，都坚守一个共同的底层认知，大模型不能直接当作可信执行体。模型会误判、会遗忘上下文、会混淆语气自信与结论正确，一旦接入终端、文件系统、权限接口和长会话流程，风险就不再是“回答错误”，而是“破坏工程环境、留下无法收拾的烂摊子”。

正是基于对模型的“不信任”，两套系统都放弃了浪漫化的Agent想象，转而搭建严谨的约束体系，prompt分层、状态持久化、权限控制、上下文治理、失败恢复、验证机制、本地规则沉淀，这些都是成熟Harness的必备器官。区别只在于，这些器官被安放在系统的不同位置，形成了两种截然不同的驯化路线。

简单来说，Claude Code是从运行时事故复盘里长出来的系统，优先解决“会话怎么不断、工具怎么不闯祸、出错怎么恢复”；Codex是从结构化设计里规划出来的系统，优先解决“规则怎么清晰、边界怎么明确、协作怎么可追溯”。二者殊途同归，却各表一枝。

二、两种控制面：动态装配线与结构化公文系统

控制面是Agent系统的大脑，决定了模型接收什么指令、如何理解规则、如何执行动作。很多人把控制面等同于prompt文风，这是最致命的误解，控制面的核心是秩序，不是语气。Claude Code和Codex的控制面设计，从根源上就走向了两个方向。

1. Claude Code：动态prompt装配线，适配现场变化

Claude Code的控制面，是一条灵活的动态装配线。它的system prompt没有固定文本，而是由默认底板、追加要求、角色指令、CLAUDE.md、会话记忆等多个模块，根据运行时条件动态拼装而成。

这套设计的核心逻辑是，控制面必须跟着任务现场走。同一个主循环，要适配不同目录、不同团队、不同任务的约束，就需要在每一轮会话中重新计算“什么信息最重要”，通过分层注入、覆盖、折叠、压缩，让规则实时适配当前场景。比如在特定项目目录下，CLAUDE.md会自动加载本地规矩，memory会保留当前任务的关键信息，技能模块会注入专属工作流，所有内容都在运行时完成组装，没有预设的固定格式。

这种设计的优势是极强的现场适应性，能快速响应复杂多变的工程场景，不用提前定义繁琐的结构；代价是需要极强的运行时治理能力，一旦装配顺序混乱，就会出现规则覆盖、语义稀释的问题，高度依赖工程经验和主循环的稳定性。

2. Codex：带编号的公文系统，追求可识别与可程序化

Codex的控制面，则是一套严谨的结构化公文系统。它拒绝把指令当作自由文本，而是将所有控制信息拆分成带明确边界的片段，instructions fragment，每一段指令都有类型、起止标记、来源、优先级，是可识别、可包裹、可序列化的独立单元。

在Codex的设计里，AGENTS.md不是简单的本地规则文本，而是带层级、带作用域的制度片段；skill不是附录说明，而是用标签包裹的标准化单元；用户指令会被序列化成带目录信息的消息，连“规则来自哪个文件、哪个目录”都明明白白告诉模型，不让模型自行猜测。

这套设计把控制面彻底显式化，每一段信息的来源、用途、边界都清晰可查，调试成本极低，也方便后续扩展优先级规则、合并规则、可见性规则等治理能力。但代价是系统更“重”，需要提前定义大量标记、类型、序列化逻辑，维护结构的成本更高，灵活性稍弱。

可以说，Claude Code的控制面是“现场编导”，灵活应变；Codex的控制面是“制度秘书”，规范严谨。前者靠经验把控现场，后者靠制度明确秩序。

三、心跳放在哪：主循环与线程状态，两种连续性逻辑

Agent系统的核心不是“多轮对话”，而是“连续性”，上一轮的动作如何衔接下一轮，工具结果如何回填，中断后如何收口，上下文膨胀如何处理，失败后如何恢复。这些问题决定了系统是“真正的Agent”，还是“带工具的问答接口”。Claude Code和Codex，把连续性的“心跳”放在了完全不同的位置。

1. Claude Code：把心跳压进query loop主循环

Claude Code的连续性，完全寄托在query()和queryLoop()构成的主循环里。系统的所有关键状态，当前消息序列、工具调用上下文、compact压缩跟踪、令牌恢复计数、轮次计数、状态转换，全都压在循环内部处理。

这种设计的底层逻辑是，连续性是运行时的核心问题，必须在现场直接解决。它不回避工程里的“脏活”，模型输出截断、上下文超长、历史消息裁剪、微压缩、用户插话、工具中断，所有真实场景的麻烦，都被当作主循环的合法状态，在运行时直接校正。

就像一个不停自我修复的发动机，Claude Code的主循环时刻盯着会话状态，一旦出现异常，立刻触发compact压缩、令牌回收、中断处理等机制，不用依赖外部状态模型，恢复速度极快，现场稳定性极强。但缺点是，状态主权都在运行时，审计和追溯的难度更高，用户很难直观感知会话的完整状态。

2. Codex：把心跳拆进线程、回放与状态桥

Codex没有把连续性交给单一主循环，而是拆分成thread（线程）、rollout（回放）、state bridge（状态桥）、state（状态）、message history（消息历史）这套基础设施。

在Codex里，thread是一级产品概念，开发者可以直接操作线程ID、运行流、执行参数，线程持有会话的所有关键信息，工作目录、沙箱模式、网络权限、审批策略；rollout负责记录会话的每一步动作，支持回放和索引；state bridge则把状态持久化，让会话状态脱离运行时也能被查询、被恢复。

这套设计让连续性不再是运行时的副产品，而是基础设施本身。系统能清晰回答“上一轮发生了什么”“每一步动作的依据是什么”，可审计性、可追踪性拉满，适合团队级治理和长期维护。但代价是，系统更偏向“执行记录器”，现场响应的灵活性不如主循环模式，恢复流程需要经过状态层，稍显繁琐。

简单总结，Claude Code是“现场救火队”，离问题最近，处理最快；Codex是“调度中心”，记录最全，追溯最清。一个保障“能持续跑”，一个保障“跑得清”。

四、工具、沙箱与策略：谁来拦住模型“动手太快”

如果说控制面和连续性是Agent的“大脑和心脏”，那工具调用就是Agent的“手脚”，也是最危险的部分。模型说错话只是浪费时间，跑错命令可能直接破坏文件、仓库、进程，因此工具治理的核心，是“在模型动手前拦住风险”。Claude Code和Codex，用两种方式守住了这条安全线。

1. Claude Code：运行时编排+现场审批，工头式监管

Claude Code的工具治理，核心是“运行时调度纪律”。它把工具调用当作“带后果的过程”，而不是单点动作，通过toolOrchestration.ts、toolExecution.ts、StreamingToolExecutor.ts等模块，实现全流程管控。

具体来说，它会严格控制工具的执行顺序，区分串行与并发，标记并发安全的工具；危险工具比如Bash，会有专属prompt和权限约束，反复提醒模型规避风险；调用前会触发ask/allow/deny审批逻辑，根据上下文、工具类型、用户操作实时判断；执行中支持中断、流式返回、 synthetic result合成结果；执行后规范回填结果，保证上下文稳定。

这套设计像一个经验丰富的工头，时刻盯着模型的每一个操作，哪里能做、哪里不能做、做到一半叫停、做完如何记账，全在运行时现场决策，灵敏度极高，能快速应对突发风险。但缺点是，审批规则散落在运行时逻辑里，难以统一管理和迁移。

2. Codex：Schema化+策略引擎，制度式约束

Codex的工具治理，走的是“标准化+策略化”路线。它先把所有工具变成schema化的接口，每个工具都有明确的字段定义，cmd、workdir、shell、tty、approval参数等，关闭额外属性，杜绝模型乱传参数；再把审批和执行限制抽成独立的execpolicy策略引擎，形成Policy、Rule、Evaluation、Decision、parser这套完整的策略语言。

在Codex里，工具不是运行时对象，而是规范化的API；权限不是零散判断，而是可解析、可评估、可补丁的策略。比如shell工具会明确要求设置workdir，禁止滥用cd命令；request_permissions是单独的标准化工具；策略引擎提供阻塞前缀、网络规则等官方补丁，方便团队快速配置安全规则。

这套设计把风险控制制度化，规则清晰、可复用、可审计，适合多团队、多场景的规模化落地。但代价是，系统需要维护大量schema和策略，配置成本更高，现场应变的灵活性稍弱。

二者的区别很直观，Claude Code是“值班经理现场拍板”，Codex是“按公司制度合规审批”，一个快，一个稳。

五、本地治理：让Agent学会“守乡约”，经验收编与制度挂载

真正能落地的Agent，从来不是通用的“万能助手”，而是能适配团队、仓库、目录专属规则的“本地化代理”。公司有规范、项目有禁忌、目录有习惯，系统必须吸收这些本地规则，才能走出演示环境，进入真实工作流。Claude Code和Codex，给出了两种本地化方案。

1. Claude Code：现场记忆收编，快速适配本地场景

Claude Code的本地治理，核心是“把现场经验带进会话”。它通过CLAUDE.md、skill、hook、session memory四大模块，快速收编本地规则。

CLAUDE.md是目录级的现场公告板，记录当前项目的常识、禁忌、工作规范；skill把本地工作流打包成可调用的技能；hook把团队治理逻辑挂在Agent生命周期节点；session memory保留当前任务的关键信息，避免每轮都“重新开始”。

这套设计极度贴近工程现场，走到哪、记到哪、用到哪，能快速适配多项目、多目录、多约束的复杂环境，实用性拉满。但缺点是，本地规则以“现场补丁”的形式存在，长期下来容易杂乱，跨团队复制的成本较高。

2. Codex：结构化资产挂载，规范管理本地规则

Codex的本地治理，核心是“把规则变成可管理的资产”。它的skill是可安装、可版本化、可指纹校验的标准化资产，系统会自动检测skill版本，无需重复安装；AGENTS.md带层级和优先级，明确规则的作用域；hook是完整的事件系统，绑定session_start、pre_tool_use、post_tool_use等明确生命周期事件，支持预览、执行、异常告警。

在Codex里，本地规则不是临时文本，而是有来源、有版本、有触发边界、有生命周期的结构化资产，方便统一分发、审计、升级，组织可复制性极强。但缺点是，团队需要先接受一套规范体系，学习成本更高，快速适配临时场景的能力稍弱。

形象来说，Claude Code是“熟悉现场的老员工”，看一眼就懂本地规矩；Codex是“制度严谨的项目经理”，先贴规则再干活，一个快，一个稳。

六、多代理与验证：避免系统“自己给自己打高分”

单Agent的能力有限，多代理协作是提升效率的关键，但多代理的核心问题从来不是“并行干活”，而是“责任分离”。如果同一个Agent既执行、又总结、又验证，最后一定会得出“自己做得很好”的错误结论。Claude Code和Codex，都解决了这个问题，但思路不同。

1. Claude Code：运行时职责分离，独立验证不走过场

Claude Code的多代理设计，围绕主循环的任务推进展开，核心是“职责拆分”。它把explore探索、execute执行、synthesis汇总、verification验证拆分成独立角色，让验证环节完全独立于执行环节，不允许执行Agent自己验收成果。

同时，它严格管控子代理的生命周期，负责任务清理、中断传播、生命周期钩子，确保子代理跑完后能顺利收口，不留下状态污染。这套设计把多代理变成运行时的分工协作，聚焦“把任务做好”，现场实用性强，能有效避免自我美化。

2. Codex：工具化委派，可审计的协作体系

Codex的多代理，是标准化的工具接口。spawn_agent、send_input、wait_agent、close_agent都有专属schema，支持中断抢占、超时设置、批量关闭子代理，委派动作是可记录、可审计、可组合的显式操作。

它依托thread、rollout、state基础设施，让多代理协作留下完整的结构化证据，验证环节有充足的状态依据，不会沦为形式主义。这套设计把多代理变成平台级能力，适合规模化、系统化的协作场景，可维护性极强。

二者的目标一致，都是避免系统“自说自话”，Claude Code靠角色分离，Codex靠接口规范，一个重现场，一个重治理。

七、殊途同归：两种政体，一个目标

读到这里就能明白，Claude Code和Codex从来不是“谁优谁劣”的竞争关系，而是两种成熟的Harness政体。

Claude Code是运行时共和制，权力集中在主循环和现场调度，制度服务于会话现场，靠灵活的现场协商维持秩序，适合追求长会话稳定、现场应变、快速落地的场景。

Codex是控制面立宪制，权力写在类型、片段、策略、线程、事件系统里，运行时在规范框架内运作，靠明确的制度定义维持秩序，适合追求规则清晰、权限可控、团队规模化的场景。

它们的共同点，是都承认模型不可靠，都把Harness当作秩序的核心，都跨过了“靠模型能力解决一切”的幼稚阶段，这是殊途同归。

它们的不同点，是秩序安放的位置，一个在运行时，一个在控制层，一个从现场经验生长，一个从结构设计规划，这是各表一枝。

八、给落地团队的建议：别折中，先抓主矛盾

读懂两套架构的差异，最终是为了指导自己的工程实践。文档最后给出的建议，值得所有做Agent的团队牢记：不要盲目拼贴功能，不要追求两头兼顾，先解决自己的核心矛盾。

如果你的团队痛点是，长会话容易失控、上下文混乱、工具调用断裂、中断后无法恢复，优先学Claude Code，把query loop主循环、compact上下文治理、工具编排、中断恢复、独立验证做扎实，先保证系统“能稳定跑下去”。

如果你的团队痛点是，规则来源分散、权限边界模糊、审批逻辑混乱、多团队难以复用，优先学Codex，把指令片段化、工具schema化、策略引擎、线程状态、hook事件系统做显式化，先保证系统“能被清晰治理”。

最危险的误区，是既想要Claude Code的灵活，又想要Codex的规范，最后拼出一个“两头不牢”的半成品，运行时没纪律，控制层不清晰，只能靠堆砌prompt文本撑场面，看似功能齐全，实则token消耗高、语义不稳定、长期无法维护。

九、结语：Harness才是Agent的真正灵魂

从Claude Code到Codex，这场深度对比最终指向一个真相，AI Agent的核心竞争力，从来不是模型有多强，而是Harness有多稳。

模型是不可靠的生产力，而Harness是驯服生产力的规则。它决定了Agent能不能在工程环境里不闯祸，能不能在长会话里不崩溃，能不能在团队里可复用，能不能在规模化里可治理。

Claude Code教会我们，工程系统要直面现场的“脏活累活”，用运行时纪律守住稳定性；Codex教会我们，工程系统要重视制度的“规范严谨”，用显式结构守住可控性。