TECH OTAKUS SAVE THE WORLD

什么是 AI Harness#

今天评价一个 coding agent，已经不能只看模型 benchmark 了。

同一个模型放到不同 harness 中，会表现出非常不同的行为：它能看到哪些上下文，以什么格式调用工具，修改文件之前是否必须读取，失败以后收到什么反馈，计划如何保存，context window 不够时留下什么，子 agent 能继承多少状态，这些都会直接影响最后的成功率。

如果用一个不太严谨但比较直观的公式表达：

1
Agent 能力 ≈ 模型能力
2
           × 上下文组织
3
           × 工具的表达能力
4
           × 状态恢复能力
5
           × 反馈与约束

LLM 只是其中的决策核心。把模型包装成一个可以长时间工作的 agent 的其余部分，都可以被视作 AI harness。

这里有一个很重要的区别：harness 可以约束操作边界，也可以约束工作方法。

例如，“不能写 workspace 以外的文件”“执行危险命令需要用户批准”，属于操作边界；“修改文件前必须 Read”“一个任务必须先进入 Plan Mode”“完成三个 task 时必须启动 verifier”，则已经开始进入工作方法。

操作边界越明确通常越好，因为它们对应安全、权限和不可逆影响。工作方法却不一定如此。它可能弥补当前模型的能力缺陷，也可能在模型升级以后成为过时的脚手架。

从这个角度看，Codex 的 harness 可以概括为：语义上较薄，操作上很厚。它较少规定模型应该如何理解和分解任务，但会严格处理 patch 语法、沙箱、审批、工具执行和错误回传。

Claude Code 则在语义和操作两个层面都更厚。除了安全边界，它还把 Read/Edit 的前置条件、plan 的生命周期、task 状态、hooks、compaction 恢复和 agent 角色等内容做进了客户端运行时。

两种路线在 Edit Tool 上表现得最明显。

Edit Tool：输出最终动作，还是声明局部意图#

1
*** Begin Patch
2
*** Update File: src/example.ts
3
@@
4
-const timeout = 1000
5
+const timeout = 3000
6
*** End Patch

1
模型负责：我要把代码改成什么
2
Harness 负责：这个动作是否合法、能否在当前环境执行

1
{
2
  file_path,
3
  old_string,
4
  new_string,
5
  replace_all
6
}

1
Codex：模型提交最终动作，harness 验证动作能否执行
2
Claude Code：模型提交局部意图，harness 根据内部状态构造并约束动作

Plan Mode：对话中的认知产物，还是可恢复的运行时状态#

Edit Tool 体现的是一次动作如何发生，Plan Mode 体现的则是一个长任务如何被组织。

Agent Loop：相同的基本循环，不同的流程密度#

几乎所有 coding agent 的最小循环都一样：

1
组织上下文 → 调用模型 → 执行工具 → 返回结果 → 再次调用模型

Codex 的核心 turn loop 基本忠实地保留了这个结构。源码注释直接描述了两种情况：模型返回 function call，就执行并把结果送入下一次请求；模型只返回普通 assistant message，这个 turn 就结束。

当然，实现内部还要处理流式事件、并发工具调用、重试、审批、compaction、diff tracking 等大量工程细节。但这些机制大多服务于“让模型可靠地观察—行动—再观察”，没有试图替模型预先规定完整的解题过程。

Claude Code 的 query loop 则明显更像一个工作流状态机。除了消息和工具结果，它还持续维护 tool-use context、自动压缩、token 恢复、stop hooks、turn count、permission transition、queued commands、agent 状态、memory 和 skill discovery 等状态。

每轮调用之前和之后，都有一系列 harness 级判断：

• 是否需要 micro-compaction 或 auto-compaction；
• hook 是否要求停止或继续；
• 是否有新的 memory、skill、command 和 agent 状态需要附加；
• MCP tools 是否发生变化；
• 是否达到 max turns；
• 当前 continuation reason 应该进入哪个分支。

这让 Claude Code 更容易在模型输出之外实现确定性流程，也意味着客户端本身拥有更多可能出 bug 的状态。

LLM API、KV Cache 与 Reasoning：产品哲学之外的基础设施差异#

讨论两套 harness 时，还有一部分差异不能完全归因于 OpenAI 和 Anthropic 对 agent 的主观理念，因为底层 API 本身就在塑造客户端。

先澄清一个经常被混用的概念：Codex 和 Claude Code 都不直接管理推理服务中的原始 KV Cache。它们能做的是稳定 prompt prefix、设置 API cache 标记，或者利用服务端 continuation，让后续请求尽可能复用已有推理状态。

Skills 与 MCP：给模型知识，还是给运行时增加一个模块#

Skills 经常被理解成一份“告诉模型如何做某件事的 Markdown”。在 Codex 中，这个理解基本接近它的核心形态，但也不完全。

Codex skill 除了 name、description 和路径，还可以声明依赖工具、调用策略、scope 和 plugin 等元数据。harness 会把可用 skill 的说明放入 developer context，模型再根据任务选择并阅读具体 SKILL.md。

所以 Codex skill 更像一个提供给模型的“可发现操作手册”：harness 负责发现、注入、权限和依赖，如何把手册应用到当前任务，主要仍由模型判断。

Claude Code 的 skill frontmatter 能直接影响更多运行时行为，包括 allowed tools、model、effort、hooks、execution context、agent 和是否允许模型自动调用等。

一个 skill 甚至可以要求 context: fork，让 Claude Code 在隔离的 subagent 中执行，并拥有自己的模型、effort 和 token budget。

从这个意义上说，Claude Code 的 skill 不只是文档，也更接近一个声明式运行时模块。

但 Anthropic 最近的调整又让这里发生了有趣的变化。随着模型判断力增强，它开始把更多规则从常驻 system prompt 移到按需加载的 skill，同时删减 skill 中不必要的解释和例子。skill 的定位也随之变得更轻：它承担的职责逐渐从“详细教模型每一步怎么做”，转向“在需要时提供目标、边界和参考资料”。

MCP 也存在类似问题。MCP 只规定了工具、资源和提示如何被发现与调用，并不会自动解决上下文膨胀、权限或工具选择。

Codex 的 MCP 调用链重点处理动态刷新、tool binding、审批、sandbox、参数改写、结果清洗和截断。这延续了它一贯的边界设计：模型选择工具，harness 保证调用在受控环境中发生。

Claude Code 则把 MCP 更深地接入了 cache 和 agent 配置：MCP tools 要保持稳定顺序，可以在 turn 之间刷新，也可以只暴露给某个特定 agent。它更关心“当前工作流中的这个角色，此刻应该看到哪些工具”。

工具越多，单纯把所有 schema 永久塞进 prompt 的成本就越高。无论是 tool search、deferred loading 还是 skill discovery，本质上都在解决同一个问题：让模型拥有很多潜在能力，但每一轮只为当前相关的那部分付 context 和 cache 成本。

Memory 与 Compaction：任务连续性与长期经验#

长任务一定会遇到 context window。真正的问题不是会不会 compact，而是 compact 以后系统还记得什么。

Codex 的 compaction 会从历史中保留用户消息和模型生成的 summary，再重新注入初始上下文与当前 world state。源码也明确提醒，长 thread 和多次 compaction 会降低准确性。

这意味着过程连续性在较大程度上依赖模型把重要信息写入 summary：之前为什么放弃某个方案、计划进行到了哪一步、用户刚刚修改了什么。如果 summary 没保住这些语义，后续模型只能从压缩结果中重新推断。

Claude Code 除了 summary，还会显式重建一批运行时 attachments。compaction 完成以后，它会重新附加最近读取的文件、plan 内容、已调用的 skills、当前 plan mode 和异步 agent 状态。

这里的设计差异非常清楚：

1
Codex：尽量让压缩后的语义摘要延续任务
2
Claude Code：摘要之外，再由 harness 恢复关键操作状态

后者对 resume、handoff 和 multi-agent 更稳定，却需要定义哪些状态值得恢复、恢复到什么版本，以及它们和摘要冲突时相信谁。

上面讨论的是一次长会话经过 compaction 以后如何继续。到了跨会话 memory 这一层，Codex 和 Claude Code 又选择了两种目标不同的实现。

从产品目标上看，Codex 的 memory 更类似我们在 ChatGPT 网页端使用的记忆功能：它关注的是如何从多次使用中沉淀能够长期复用的经验和知识，例如稳定的用户偏好、反复出现的工作习惯、验证过的操作流程、仓库中的关键路径以及曾经遇到过的失败模式。它服务于未来的 agent，不只服务于生成这条记忆的当前会话。

这套 memory pipeline 会在 root session 启动时异步运行。第一阶段扫描近期符合条件的 rollout——也就是一次 agent 会话留下的完整执行记录——并让模型从每个 rollout 中提取结构化记忆；第二阶段再从多个会话的结果中选择高价值内容，由 consolidation subagent 合并成 MEMORY.md、memory_summary.md 和可复用 skills。由于它使用的是用户级 memory workspace，输入可能来自不同会话和不同项目，最终记忆也会保留各自的项目或工作目录边界，避免把只适用于某个仓库的经验错误推广到其他任务。

claim、lease、并行提取、重试、敏感信息清理、全局锁和 heartbeat 等机制，都是围绕这套自动化长期记忆流水线产生的。它要从许多历史会话中持续提炼知识，同时处理多个 Codex session 并发启动的问题，因此需要解决重复提取、全局一致性和失败恢复。

Claude Code 的 memory 实现相对直接一些。每种 agent 可以选择 user、project 或 local 作用域，harness 为这个 agent 准备对应的 memory 目录和 MEMORY.md，再把读写说明及已有内容注入 agent 上下文：

• user memory 保存跨项目通用的经验；
• project memory 保存当前项目内、可以随版本库共享的知识；
• local memory 保存只适用于当前项目和当前机器的内容。

不同 agent type 拥有各自的 memory 文件，因此 verifier、explorer 或其他自定义 agent 可以长期保留与自身职责相关的信息。

从这份实现看，Claude Code 没有采用 Codex 那种扫描大量历史 rollout、再进行两阶段全局整合的流水线。它更强调在明确的 agent 和作用域下保存一份可以直接阅读、修改和注入的文件化记忆，机制更简单，也更容易让用户或项目维护者理解记忆从哪里来、会作用到哪里。

因此二者虽然都叫 memory，解决的问题并不完全相同：

1
Codex Memory：从多个历史会话中自动沉淀长期经验和可复用知识
2
Claude Code Memory：为特定 agent 和作用域维护直接可用的持久化上下文

Codex 为自动提取、跨会话整合和全局复用付出了更高的后台工程成本；Claude Code 选择了更明确、更轻量的作用域文件。这里的复杂与简单主要反映设计目标的差异，并不直接代表哪一种记忆能力更强。

Subagent 与 Multi-Agent：上下文、角色与协作状态#

Codex 创建 subagent 的基础操作是启动一个 child thread，并向它发送任务。调用 spawn_agent 时，父 agent 可以选择让 child 继承全部历史、最近若干轮历史或完全不继承，接口还提供 model、reasoning effort 和 agent_type 等参数；其中 full-history fork 不允许再覆盖 role。

这里的 agent_type 就是 Codex 的 role。选中 role 后，Codex 会使用与 config.toml 相同的配置合并机制，把 role 作为高优先级配置层应用到 child thread。role 可以调整 developer instructions、model、reasoning、sandbox、skills 等设置，Codex 也内置了 explorer、awaiter 等常用角色。

因此，一个 Codex subagent 可以理解为“带有独立任务、选定上下文和 role 配置的 Codex thread”。父 agent 根据当前任务决定如何拆分工作、创建多少 child、为每个 child 选择什么上下文和角色，并在它们返回以后综合结果。

Claude Code 的 subagent 同样会进入正常的 query loop，并使用独立的 system prompt、上下文和 tool-use context。它的 agent definition 集中暴露了更完整的子代理参数，包括 tools、disallowed tools、model、effort、permission mode、MCP servers、hooks、max turns、skills、memory、background mode 和 worktree isolation。

这些参数基本覆盖了 Claude Code 主 Agent Loop 中已有的 harness 控制范围。subagent 沿用相同的工具执行、权限、hooks、MCP 和 turn limit 机制，agent definition 只是为某个角色预先固定其中一部分配置。

所以在单个 subagent 的抽象上，两者的差异没有看起来那么大：

1
Codex：spawn child thread → 选择上下文、模型和 role → role 配置覆盖 session config
2
Claude Code：spawn subagent → 加载 agent definition → 带角色配置进入同一套 query loop

更具体的区别在于参数的组织方式。Codex 把即时参数放在 spawn_agent 中，把角色能力放在可复用的 config layer 中；Claude Code 则在 agent definition 里直接集中声明工具白名单与黑名单、权限、hooks、memory 和隔离方式，更容易从一份定义中看到这个 subagent 的完整运行边界。

前面提到的 verification agent 就是这种配置方式的例子。它通过 agent definition 限制可用工具，再通过角色 prompt 规定验证步骤和 verdict 格式。Codex 也可以通过 role config 创建专门角色，只是相关约束会沿用 Codex 自身的配置层体系。

到了 Multi-Agent 协作层，两者的侧重点才进一步拉开。Codex 已经提供 child thread、agent communication 和状态查询等原语，任务如何拆分以及结果如何汇总主要由父 agent 判断。Claude Code 在这些调用能力之外，还把 plan approval、task ownership、mailbox 和 agent status 做成显式运行时状态，使权限、交接和验收过程更容易追踪。

模型主导的任务分解可以临时形成很灵活的协作方式，也可能产生重复分工、无价值 subagent 或 compaction 后的目标漂移。显式协调状态有助于长任务恢复和审计，同时增加了 task、角色、消息和权限之间的同步成本。这里更接近“模型负责多少协调、harness 保存多少协作状态”的取舍。

两种路线的最终权衡#

到这里可以看出，Codex 和 Claude Code 的区别并不只体现在某个工具的 schema 上。Edit、Plan、Compaction、Skills 和 Multi-Agent 其实都在回答同一个问题：

当模型已经能够理解任务并根据反馈纠错时，harness 还应该替它决定多少事情？

1
是否应该进入 harness
2
≈ 错误的不可逆性
3
× 状态的并发程度
4
× 恢复成本
5
× 审计要求

删除 80% 提示词真正说明了什么#

回到开头 Anthropic 删除 80% system prompt 的事情。

我认为它最值得关注的地方，不是证明了“prompt engineering 已经没有意义”，也不是证明 Claude Code 正在变成 Codex，而是暴露了 AI harness 中一种很常见的技术债。

模型每出现一种失败行为，开发者就很自然地在 system prompt 中补一条规则：

1
模型忘记验证 → 加一句必须验证
2
模型过早结束 → 加一句不要过早结束
3
模型探索不足 → 加几段搜索示例
4
模型滥用工具 → 再解释一次工具边界

在当时，这些规则可能真的提升了效果。但 prompt 只会增加，很少有人在模型升级以后系统地检查旧规则是否仍然必要。

久而久之，system prompt 就变成一份历史模型缺陷的兼容层。新模型已经学会了某些能力，旧约束却还在要求它按旧模型需要的步骤工作；大量示例还可能收窄它的探索空间，让模型倾向于复制已有路径，而不是根据当前环境作出更好的判断。

Anthropic 这次清理 prompt，实际上做了三件事：

第一，承认约束有保质期。针对旧模型有效的 harness，不一定适合新模型。

第二，把常驻规则和按需知识分开。verification、review 和特定工作流仍然可以存在，但不必进入每一个请求的 system prompt，而可以通过 skill 渐进式加载。

第三，重新把一部分判断权交还给模型。新模型能够利用工具描述、仓库上下文和任务目标推断正确行为时，就不需要再用几十条互相重叠的指令规定过程。

这和 Codex 一直以来表现出的设计倾向非常接近：让工具接口拥有足够表达力，让模型看到真实环境和明确反馈，然后把可以低成本纠正的错误交给模型自己处理。

但它并不意味着所有约束都应该删除。Anthropic 删掉的主要是语义脚手架，而不是权限、文件一致性、cache 正确性或恢复机制。模型能力可以替代很多“应该怎么工作”的提示，却不能自动替代并发控制、安全边界和持久化协议。

那么，一个好的 AI Harness 应该做到什么#

经过上面的对比，一个好的 AI Harness 首先应该清楚划分模型与系统的职责：让模型负责需要理解上下文和权衡取舍的语义决策，让 harness 保证可以被确定性验证的工程不变量。

对于代码应该如何设计、任务应该如何拆分、接下来应该查看哪些文件等问题，harness 应该提供高带宽、可组合的工具和清晰的环境反馈，让模型充分发挥自身判断力。把当前模型的每个弱点都固化成工作流规则，会让 harness 随着模型升级迅速过时。

以下场景则适合由 harness 提供结构化约束：

• 写入对象可能被用户或其他 agent 并发修改；
• 动作不可逆，或者会影响外部真实系统；
• 任务会跨 session、跨 context compaction 或跨 agent handoff；
• 状态需要审计，不能只存在于模型生成的摘要中；
• 某个不变量可以被系统低成本、确定性地验证。

因此，一个好的 harness 应该具有清晰的分层：

1
语义决策层：尽量相信模型
2
操作执行层：提供强反馈和可恢复性
3
安全与并发层：由系统保证不变量
4
长任务协调层：按需启用持久状态

例如，Edit Tool 可以保留 Codex patch 的高表达力，同时在实际写入前加入版本检查，防止覆盖用户并发修改；Plan 默认只是一段对话中的认知产物，但当任务需要 resume、handoff 或多人协作时，再升级为持久化 artifact；verification 默认由模型根据风险决定，高风险任务则自动进入只读 verifier。

这类设计的关键在于让约束与风险匹配。低成本、可观察、可恢复的失败，可以更多交给模型和反馈循环；涉及安全、并发、不可逆动作和跨会话一致性的问题，应该由 harness 直接保证。

一个好的 harness 还需要具备随模型演进而调整的能力。system prompt、tool description、skill 和客户端状态机都应该定期通过新模型重新评估：仍然必要的约束继续保留，已经被模型能力覆盖的脚手架及时删除，需要时才有价值的知识则迁移到按需加载的位置。

结语#

Codex 和 Claude Code 代表了两种都很合理的 agent 工程路线。

Codex 更相信模型能力可以直接转化成 agent 能力，因此尽量保持工具高带宽、流程低假设。它的设计对 frontier model 更敏感，也更容易随着模型升级自然获得收益。

Claude Code 更关注模型行为的方差和长任务中的状态一致性，因此愿意用更多工具约束、运行时状态和角色协议换取确定性。它在模型不稳定、任务复杂或协作链路很长时更有韧性，但也承担了更高的 token 税和 harness 维护成本。

而 Claude Opus 5 之后删除 80% system prompt 的变化，说明这两条路线并不是固定不动的阵营。随着模型变强，Claude Code 也开始把一部分流程判断交还给模型；同样，当 Codex 面对跨会话 memory、安全审批和并发一致性时，它也会采用非常严格的状态机。

所以真正重要的问题不是 harness 应该有多少约束，而是：

哪些事情可以交给模型通过环境反馈自行修正，哪些不变量必须由系统保证？

这个边界不会有一次性的答案。模型每升级一代，工具能力、context window 和推理接口每发生一次变化，我们都应该重新检查它。

这也解释了为什么模型公司往往需要开发并长期维护自己的 Agent Harness。Harness 需要适配模型的工具调用方式、reasoning 状态、context 特性、cache 机制和常见失败模式，再随着模型迭代不断调整。OpenAI 可以让 Codex 的工具接口和 Responses API 一起演进，Anthropic 也可以围绕 Claude 的 thinking blocks、prompt cache 和行为特点持续修改 Claude Code。模型与 harness 共同设计，才能更充分地发挥这一代模型的能力。

一个优秀的 AI harness，不应该只是不断给模型增加护栏。它还应该知道，什么时候可以把已经不再必要的护栏拆掉。