同样是 Coding Agent，Codex 和 Claude Code 的 Harness 到底差在哪？Opencode弱在哪？

这是一篇运行时对运行时的对照。它不比较 GPT 和 Claude 哪个模型更聪明，而是比较模型在一轮工作中怎样被驱动、受什么约束、从哪里恢复状态、看见什么上下文、怎样调用工具，以及工具究竟在哪个运行环境中落地。

#先看地图：一轮 Coding Agent 从开始到结束

Harness 可以拆成六个要素：流程、约束、持久化、上下文、工具、运行环境。它们不是六个并列功能页，而是一条会反复循环的执行链。本文沿着任务真实经过的顺序下钻：先决定这一轮怎么走，再加载边界和状态，组装模型输入，处理工具调用，最后在宿主环境执行并把结果写回。

flowchart TD
  S([开始：用户提交“修复 checkout 超时”]) --> F["① 流程<br/>决定单 Agent、委派、继续、重试或结束"]
  F --> C["② 约束<br/>规则、技能、审批、Hook、权限策略"]
  C --> P1["③ 持久化读取<br/>history、summary、附件、项目状态"]
  P1 --> X["④ 上下文<br/>把任务、约束、状态、已选能力装成 prompt"]
  X --> M["模型推理"]
  M --> T{"需要工具或子任务？"}
  T -- 否 --> P2["③ 持久化写回<br/>保存答复与当前状态"]
  T -- 工具 --> U["⑤ 工具<br/>发现、校验、调度、截断、规范化"]
  T -- 子任务 --> F
  U --> R["⑥ 运行环境<br/>PTY、沙箱、工作目录、网络、MCP transport"]
  R --> P2
  P2 --> D{"任务完成？"}
  D -- 否 --> N["下一轮：携带新状态"]
  N --> F
  D -- 是 --> E([结束：交付结果与可审计记录])
  R -. "风险：副作用、网络边界、环境漂移" .-> RR["运行风险"]
  P2 -. "风险：摘要丢失早期证据" .-> PR["状态风险"]

#阅读路线

一句话结论：Codex 更倾向把流程、策略、会话与执行环境的开关显式交给宿主；Claude Code 2.1.88 更倾向把探索、工具包装和会话整理封装为默认运行时策略。前者的价值是可配置、可审计，后者的价值是低摩擦、默认路径完整。

#版本与四层证据边界

本文的证据纪律很简单：

• 源码回答“某段 runtime 实际读了什么、写了什么、走了什么分支”。
• Cookbook回答“开发者可怎样把这类能力用于任务设计”。它不证明 Codex 内部一定采用某个 cookbook 模式。
• CC 官方手册回答“今天产品向用户承诺什么”。它不反向证明 2.1.88 内部对象仍然相同。
• OpenCode 官方源码/文档只证明固定 release 的公开实现或当前可配置行为；Issue 和 PR 一律只是演进信号。
• CC 2.1.88 是从 npm source map 提取的非官方历史快照；其版本背景可参见 官方仓库记录。所有 CC 代码段都只解释历史实现。

#源码链怎样证明一个 Harness 模块

一段孤立代码通常只能说明“存在一个字段或函数”，不能说明一个模块真正怎样工作。本文每条源码链都只证明一个最小闭环：

因此，代码块中的 A/B/C 是同一机制切片，不是完整调用栈。为避免把跨文件片段伪装成可直接编译的程序，块内省略了无关类型、错误处理和参数，且只保留连接三步所必需的语句；每个片段的真实文件和行号都在紧邻段落中列出。相邻的链路 I/O 会用同一任务输入把三步连起来；图中的 ①/②/③ 节点与它们一一对应。

#1. 流程：一轮任务由谁推进、何时换人

#模块目标

流程模块的输入是用户任务、当前回合状态和可选子任务；输出是一个明确的下一步：继续模型回合、执行工具、委派子会话、重试或结束。它的核心不变量是：复杂探索可以离开主线程，但回到主线程的必须是可用结论，而不是无限增长的原始过程。

#用人话说

这像项目负责人安排工作：能直接答的就答，需要查资料的派人查，查完再决定继续还是收工。流程模块要保证“派人”和“回来汇报”都有边界。

#常用场景

• 修复 checkout 超时前，先并行定位支付入口、测试失败点和最近改动。
• 一条命令失败后，决定缩小查询、改用另一工具，还是终止任务。
• 主线程不应装入陌生仓库侦察产生的全部 grep 命中。

#模块机制图

flowchart TD
  S([开始：收到任务与当前回合状态]) --> A["① 读取任务、已有状态与委派参数"]
  A --> B{"可由主线程直接完成？"}
  B -- 是 --> C["运行模型回合"]
  B -- 否 --> D{"需要独立探索？"}
  D -- 是 --> E["② 创建子会话，分配 history 与策略"]
  E --> F["③ 子会话返回证据、结论、未解项"]
  F --> C
  D -- 否 --> C
  C --> G{"继续、重试还是完成？"}
  G -- 继续 --> H["把下一动作交给工具或下一轮"]
  H --> I([结束：进入约束与状态读取])
  G -- 完成 --> J([结束：交付最终答复])
  E -. "风险：子任务带入过多 history 或权限" .-> R["隔离失效"]

读图结论：流程模块不是“多 Agent 功能列表”，而是控制面。子 Agent 只是其中一条分支，必须在返回主线程前压缩成对主任务有用的证据。

#Codex 源码解读

下面不是完整调用栈，而是一条委派最小闭环：先读取调用方给定的 history 语义，再创建受策略约束的 child，最后把 child turn 的结论交还主流程。片段 A 见 codex_delegate.rs，第 63–98 行，片段 B/C 见 第 105–138 行（公开源码备份，2026-03-31 快照）。

// 片段 A：读取。调用者没有指定时，默认是 New history。
let history = initial_history.unwrap_or(InitialHistory::New);

// 片段 B：决策/创建。父级执行策略不是子会话的隐式全权限。
let child = Codex::spawn(CodexSpawnArgs {
    conversation_history: history,
    inherited_exec_policy: Some(inherited_exec_policy),
    config: child_config,
    skills_manager,
}).await?;

// 片段 C：写回。主流程消费的是 child turn 的结果，不是 child 内存。
let result = run_child_turn(child, task).await?;
return Ok(result);

Cookbook 实践旁证（辅助，不证明上述实现）：Cookbook 的 Orchestrating Agents: Routines and Handoffs 将“按任务转交给另一 routine”作为工作流设计手法。它支持本文的实践建议：只有当子任务能用清晰产物回传时才委派；但它不说明 Codex 内部如何 spawn 子会话。

#CC 2.1.88 源码解读

CC 2.1.88 的相应闭环由运行入口和 Agent 定义共同构成：入口准备子会话，Explore 定义收窄其角色，运行结果再回到父调用。片段 A/C 见 runAgent.ts，第 85–217 行，片段 B 见 exploreAgent.ts，第 24–56 行（非官方历史快照备份）。

// 片段 A：入口选择 agent definition，并建立 agent session。
const definition = resolveAgent(agentName);
const session = await createAgentSession(definition, input);

// 片段 B：Explore 的可用动作和模型被定义为只读探索。
const exploreAgent = {
  tools: ['Glob', 'Grep', 'Read'],
  model: 'haiku',
  skipClaudeMd: true,
};

// 片段 C：运行器将完成结果格式化后回给 Task 的父调用。
const result = await runAgent(session, definition, prompt);
return formatAgentResult(result);

当前官方手册旁证（辅助）：Subagents 文档 说明当前产品支持独立上下文、工具和模型配置；它不能证明当前 Explore 仍使用上述工具或跳过规则。

#实现对比与取舍

#OpenCode：现状与改进路线

#适用场景

#2. 约束：哪些规则必须在模型前和执行时都生效

#模块目标

约束模块将系统指令、项目规则、技能、审批、Hook 与权限策略转成可执行边界。输入是仓库和宿主提供的规则、工具请求和风险目标；输出是受约束的 prompt、允许/拒绝/待审批的动作。核心不变量是：模型看见一条规则不等于运行时会执行它，真正的副作用还需在执行点复核。

#用人话说

规则像施工图和门禁：施工图告诉工人不能拆承重墙，门禁则在真要进机房时拦下来。只把规则写进 prompt，相当于只贴了提示牌；只在执行时阻拦，又会让模型白做规划。

#常用场景

• 项目规定只能改 src/payment，不能改数据库 schema。
• 访问 api.example.com:443 前必须让用户单次确认。
• 团队用 Hook 阻止未经测试的提交或生产写操作。

#模块机制图

flowchart TD
  S([开始：任务与候选动作进入]) --> A["① 读取系统、项目、技能与策略规则"]
  A --> B["把稳定约束提供给上下文装配"]
  B --> C{"模型请求是否触及受控动作？"}
  C -- 否 --> D["保留约束快照"]
  C -- 是 --> E["② 运行时按审批和权限策略复核"]
  E -- 允许 --> D
  E -- 拒绝或待确认 --> F["③ 写回拒绝或审批请求"]
  D --> G([结束：进入状态读取或工具调用])
  F --> G
  E -. "风险：只靠 prompt、策略粒度过宽" .-> R["约束绕过"]

读图结论：约束有两次落点：进入 prompt 时影响计划，进入执行器时阻止副作用。本文把前者放在“上下文”的输入中，把后者留在“运行环境”的真实边界。

#Codex 源码解读

Codex 的约束闭环需要同时看“规则怎样进入 session”和“动作怎样在执行点被复核”。片段 A 是 compact.rs，第 191–223 行 中稳定上下文重建；片段 B/C 是 network_approval.rs，第 77–127 行 的审批与结果分支（公开源码备份）。

// 片段 A：读取。稳定规则来自 session，而不是只靠模型记住。
let initial_context = sess.build_initial_context(turn_context.as_ref()).await;

// 片段 B：决策。审批对象由目标主机、协议和端口共同组成。
let key = HostApprovalKey { host, protocol, port };
let decision = approval_policy.check(&key);

// 片段 C：写回或执行。AskUser 产生事件，不等同于放行。
match decision {
    Allow => execute_request(),
    AskUser => request_network_approval(key),
    Deny => deny_request(),
}

Cookbook 实践旁证（辅助）：OpenAI Cookbook 目录 中的工具与 agent recipe 可用于设计 guardrail 与人工确认工作流；截至本文查阅，没有一篇直接描述 Codex 的 host/protocol/port 审批键，因此不以 cookbook 取代源码。

#CC 2.1.88 源码解读

CC 2.1.88 的机制链由 context 规则来源、MCP 包装的权限调用与 client 调用分支共同组成。片段 A 见 context.ts，第 152–188 行，片段 B/C 见 MCPTool.ts，第 27–75 行（非官方历史快照备份）。

// 片段 A：读取。项目规则和记忆先聚合为执行上下文。
const context = await buildContext({ messages, claudeMd, memory });

// 片段 B：决策。MCP 包装把工具名和参数送进外层权限链。
const permission = await context.canUseTool(this.name, input);

// 片段 C：写回或执行。拒绝被透传，允许后才调用服务。
if (!permission.allowed) return permission.result;
return this.client.callTool(this.serverName, this.toolName, input);

当前官方手册旁证（辅助）：Permissions 与 Hooks 说明当前用户可配置的权限和生命周期约束；不要把它们的当前配置名外推回 2.1.88。

#实现对比与取舍

#OpenCode：现状与改进路线

#适用场景

#3. 持久化：跨回合留下什么，窗口满时改写什么

#模块目标

持久化模块负责从 session 中恢复可继续工作的状态，并在一轮完成后写回新的消息、工具结果、摘要和附件关系。输入是已存 history 与当前回合产物；输出是下一轮能读取的状态。核心不变量是：压缩可以是有损的，但必须保住当前目标、标记边界，并让稳定规则不只寄托于摘要。

#用人话说

这像交接班。下一班不需要重看所有监控录像，但必须知道事故还没结束、已经排除了什么、报告附件在哪里。压缩不是删除历史的借口，而是写一份能继续干活的交接单。

#常用场景

• 120 轮排障后又出现一批测试日志。
• 用户隔天回来继续同一个修复任务。
• 长会话里既有文本、工具输出又有附件。

#模块机制图

flowchart TD
  S([开始：① 读取 session history 与附件]) --> A{"窗口是否足够？"}
  A -- 足够 --> B["恢复原 history"]
  A -- 不足 --> C["选择旧 history、近期目标、附件"]
  C --> D["② 生成 compact summary"]
  D --> E{"摘要请求是否超窗或失败？"}
  E -- 否 --> F["重建 boundary、summary、保留消息与附件"]
  E -- 是 --> G["退避：裁短输入后重试"]
  G --> C
  B --> H["写入本轮新消息与工具结果"]
  F --> H
  H --> I([结束：③ 保存下一轮可恢复状态])
  F -. "风险：早期反例被摘要吞掉" .-> R["状态失真"]

读图结论：持久化不是数据库名词，而是让下一轮能继续做对事的状态迁移。压缩策略的关键在于保留对象、失败退避与边界标记。

#Codex 源码解读

Codex 的持久化闭环由 history 快照、超窗退避和 replacement history 重建组成。片段 A/C 见 compact.rs，第 191–223 行，片段 B 见 第 154–230 行与 324–389 行（公开源码备份）。

// 片段 A：读取。先取得本轮可替换的 session history 快照。
let history_snapshot = sess.clone_history().await;
let history_items = history_snapshot.raw_items();

// 片段 B：决策。compact 自身超窗时，按最早项退避再重试。
if turn_input_len > 1 {
    history.remove_first_item();
    continue;
}

// 片段 C：写回。summary、近期用户目标与重建规则组成新 history。
let new_history = build_compacted_history(Vec::new(), &user_messages, &summary_text);
sess.replace_history(new_history).await;

Cookbook 实践旁证（辅助）：OpenAI Cookbook 目录 收录的长文总结和 agent 状态处理类示例可帮助设计“摘要后仍可验证”的工作流，但没有直接公开 Codex compact 的保留算法；本文的删除顺序与重试结论只来自源码。

#CC 2.1.88 源码解读

CC 2.1.88 的闭环是：检测压缩边界、生成摘要、用 boundary/消息/附件构成新数组。片段 A/C 见 compact.ts，第 325–334 行，片段 B 见 第 596–610 行（非官方历史快照备份）。

// 片段 A：读取。compact 选择保留的消息与附件。
const { messagesToKeep, attachments } = selectPostCompactState(messages);

// 片段 B：决策。旧 history 被折叠为模型生成的 summary。
const summary = await createCompactSummary(messages);

// 片段 C：写回。新的边界、摘要、近期消息和附件按顺序重建。
return [
  createCompactBoundaryMessage(),
  createSummaryMessage(summary),
  ...messagesToKeep,
  ...attachments,
];

当前官方手册旁证（辅助）：Context window 确认当前产品会管理上下文窗口；它不能确定今天仍以 2.1.88 的对象顺序重建 history。

#实现对比与取舍

#OpenCode：现状与改进路线

#适用场景

#4. 上下文：本轮模型究竟带了哪些行李

#模块目标

上下文模块把已生效约束、恢复状态、当前用户任务和此刻必要的工具说明装配成模型请求。输入来自前三章，输出是本轮 prompt。核心不变量是：稳定规则要能重注入，易失 history 要有预算，工具 schema 要按必要程度进入，而不是无差别塞满窗口。

#用人话说

Agent 出门要带工作证、目的地、上次交接单和必要工具。把所有仓库资料和所有工具说明都装进背包会超重；只带摘要又会忘记“不能改 schema”这种硬约束。

#常用场景

• 有目录、测试、审批限制的仓库修复。
• 从已经压缩过的会话继续实现。
• 同时接入许多 MCP、技能和工具，但首轮 token 预算有限。

#模块机制图

flowchart TD
  S([开始：① 接收任务、约束与可恢复状态]) --> A["读取稳定规则与当前用户目标"]
  A --> B["取回 history、summary、附件引用"]
  B --> C{"哪些能力本轮必要？"}
  C -- 常驻 --> D["② 加入必要工具 schema 与技能说明"]
  C -- 按需 --> E["② 保留 Tool Search 等发现入口"]
  D --> F["按预算装配 prompt"]
  E --> F
  F --> G([结束：③ 向模型发送本轮输入])
  F -. "风险：规则漏注入、schema 过大、摘要被当原文" .-> R["上下文失真"]

读图结论：上下文不是历史的原样拼接，而是一个预算内的装配产物。约束、持久化和工具三层在此相遇，但它们的治理逻辑各自独立。

#Codex 源码解读

Codex 的上下文闭环可分成三层：从 history 提取近期目标、从 session 重建稳定约束、把两者插入 replacement history；按需工具发现再避免未使用 schema 长驻。片段 A/B 见 compact.rs，第 191–223 行，片段 C 见 tool_search.rs（公开源码备份）。

// 片段 A：读取。近期用户目标从 history snapshot 提取。
let user_messages = collect_user_messages(history_items);

// 片段 B：决策/装配。稳定规则由当前 session 重建后插入新 history。
let initial_context = sess.build_initial_context(turn_context.as_ref()).await;
new_history = insert_initial_context_before_last_real_user_or_summary(
    new_history, initial_context);

// 片段 C：按需能力。Tool Search 只在模型选择发现时返回匹配工具说明。
let discovered = tool_search_handler(query, deferred_tools).await?;

Cookbook 实践旁证（辅助）：OpenAI Cookbook 目录 中的 agent、prompt 与工具示例能帮助开发者把稳定指令、状态和工具描述拆层；它不提供 Codex 的 initial_context 组装顺序，因此顺序结论仍仅由源码支持。

#CC 2.1.88 源码解读

CC 2.1.88 的链同样不应只看 Tool Search：先聚合 messages、CLAUDE.md 和 memory，再以 query 选 deferred tools，最后把它们送给本轮模型。片段 A/C 见 context.ts，第 152–188 行，片段 B 见 ToolSearchTool.ts，第 21–45 行（非官方历史快照备份）。

// 片段 A：读取。会话、项目规则和 memory 汇入 context。
const context = await buildContext({ messages, claudeMd, memory });

// 片段 B：决策。deferred tools 由 query 选择，而不是全量注入。
const tools = searchDeferredTools(query);

// 片段 C：写入模型输入。context 与已选 tools 共同构成请求。
return createModelRequest({ context, tools, messages });

当前官方手册旁证（辅助）：How Claude Code works 说明当前产品如何使用项目指令与上下文；今天具体的自动加载时机仍以官方文档为准。

#实现对比与取舍

#OpenCode：现状与改进路线

#适用场景

#5. 工具：模型说要做，工具结果怎样安全回流

#模块目标

工具模块把模型的工具调用转成可校验请求，把异构原始输出转成下一轮可读取的 tool result。输入是工具 schema、调用参数与原始结果；输出是规范化、截断状态可见、可写入 history 的结果。核心不变量是：工具发现、调用和结果治理是三件相连但不同的事。

#用人话说

工具像一间器材室。模型先要知道有哪些器材，再借某一件，最后拿回结果。拿回一整车 10,000 行日志会堵住走廊，所以 Harness 要裁剪，还得贴上“已裁剪”的标签。

#常用场景

• CI、构建和宽搜索产生数千行日志。
• MCP 服务返回大 JSON、表格或分页数据。
• 工具很多，希望 schema 不全部常驻 prompt。

#模块机制图

flowchart TD
  S([开始：① 模型提出工具调用]) --> A["定位已注册工具或执行 Tool Search"]
  A --> B["② 校验工具名、参数与调用协议"]
  B --> C["把请求交给运行环境执行"]
  C --> D["取得原始 stdout、文件或 MCP 结果"]
  D --> E{"超过结果预算？"}
  E -- 否 --> F["规范化完整 tool result"]
  E -- 是 --> G["截断并保留截断事实"]
  F --> H["③ 写回 history"]
  G --> H
  H --> I([结束：模型获得下一轮证据])
  G -. "风险：根因在被裁掉的尾部" .-> R["需二次窄读"]

读图结论：Tool Search 解决“说明何时入窗”，截断解决“结果如何回流”。二者都节省上下文，却不能互相替代。

#Codex 源码解读

Codex 的工具结果闭环至少有三处：先按需发现工具说明，再保留原始执行字节，最后按 token 预算形成写回文本。片段 A 见 tool_search.rs，片段 B/C 见 tools/context.rs，第 284–362 行；PTY 的原始字节上限见 pty/src/lib.rs，第 10 行。

// 片段 A：读取/发现。只返回模型查询命中的 deferred tool 定义。
let tools = tool_search_handler(query, deferred_tools).await?;

// 片段 B：保存执行事实。原始字节与模型回流预算分离。
let output = ExecCommandToolOutput {
    raw_output,
    max_output_tokens,
    original_token_count,
};

// 片段 C：写回。将字节转文本后按 token 预算裁剪为 tool result。
let text = String::from_utf8_lossy(&output.raw_output).to_string();
let visible = formatted_truncate_text(&text, TruncationPolicy::Tokens(max_tokens));
history.push_tool_result(visible);

Cookbook 实践旁证（辅助）：OpenAI Cookbook 目录 的 function calling、MCP 与 agent tool 示例适合说明“工具要设计成窄输入、窄输出”；没有一篇直接规定 Codex 的 token 截断算法，因此上限与对象字段仍只据源码。

#CC 2.1.88 源码解读

CC 2.1.88 的工具链包括 deferred tool 发现、MCP Tool 的容量定义与结果截断识别，而不是只是一条 maxResultSizeChars 常量。片段 A 见 ToolSearchTool.ts，第 21–45 行，片段 B/C 见 MCPTool.ts，第 27–75 行（非官方历史快照备份）。

// 片段 A：读取/发现。query 选择 deferred tools。
const discovered = searchDeferredTools(query);

// 片段 B：决策。MCP Tool 将结果字符预算声明为协议的一部分。
const mcp = buildTool({ isMcp: true, maxResultSizeChars: 100_000 });

// 片段 C：写回提示。结果被回传前提供截断状态。
const truncated = isOutputLineTruncated(output);
return createToolResult({ output, truncated });

当前官方手册旁证（辅助）：Tools reference 与 MCP 描述当前可用工具和 MCP 使用方式；当前结果上限不由 2.1.88 片段推断。

#实现对比与取舍

#OpenCode：现状与改进路线

#适用场景

#6. 运行环境：工具真正在哪儿跑，副作用由谁承接

#模块目标

运行环境模块是工具调用真正发生的宿主：PTY、工作目录、文件系统、沙箱、网络通道和 MCP transport 都在这里起作用。输入是已校验、已获准的工具请求；输出是执行结果、错误、审批事件和审计痕迹。核心不变量是：模型和工具协议不能越过宿主边界直接拥有环境副作用。

#用人话说

工具模块像下了一张工单，运行环境才是实际施工现场。命令在哪个目录跑、能访问哪些文件、能不能出网、MCP 请求送到哪里，决定了同一张工单最后会发生什么。

#常用场景

• 在受限工作目录运行测试、构建或迁移预览。
• 访问外部 API、浏览器自动化或企业 MCP 服务。
• 排查“模型已经请求执行，但为什么被沙箱、端口或环境变量拦住”。

#模块机制图

flowchart TD
  S([开始：① 收到已校验的工具请求]) --> A["绑定工作目录、沙箱与执行策略"]
  A --> B{"请求类型？"}
  B -- shell / 文件 --> C["② PTY 或本地执行器"]
  B -- 网络 --> D["② 按 host、protocol、port 经过审批"]
  B -- MCP --> E["② MCP client / transport 调用服务"]
  C --> F["采集退出码、stdout、stderr"]
  D --> F
  E --> F
  F --> G["形成执行事件与原始结果"]
  G --> H([结束：③ 交给工具模块规范化和写回])
  A -. "风险：cwd、沙箱、重定向、服务端副作用" .-> R["环境漂移或越权"]

读图结论：运行环境不是“工具的另一个名字”。工具层管理调用协议与结果回流；运行环境决定请求能否在真实机器、网络和服务端产生副作用。

#Codex 源码解读

Codex 的运行环境闭环不能只看 PTY 常量：工作请求先携带策略进入执行器，PTY 限制原始输出，网络目标再落到审批事件或真实请求。片段 A 是 network_approval.rs，第 77–127 行，片段 B 是 pty/src/lib.rs，第 10 行，片段 C 回到 tools/context.rs，第 284–362 行（公开源码备份）。

// 片段 A：读取/准入。网络执行先从 target 构造审批键。
let key = HostApprovalKey { host, protocol, port };
let decision = approval_policy.check(&key);

// 片段 B：执行环境。PTY 对单个进程积累的原始输出设硬边界。
pub const DEFAULT_MAX_OUTPUT_BYTES: usize = 1024 * 1024;
let pty = spawn_pty(command, cwd, exec_policy).await?;

// 片段 C：写回。进程事件和原始输出成为工具层的输入。
let raw_output = pty.collect_output().await?;
return ExecCommandToolOutput::from(raw_output);

Cookbook 实践旁证（辅助）：OpenAI Cookbook 目录 的 coding、MCP 与工具执行范例强调将外部副作用封装成受控工具调用；没有直接公开 Codex PTY 或其沙箱实现，故本文不把 cookbook 当作环境机制证据。

#CC 2.1.88 源码解读

CC 2.1.88 的外部运行边界同样可拆成三段：请求进入 MCP Tool、外层权限决定是否允许、client 将获准调用送到 server 并把结果返回。片段 A/C 见 MCPTool.ts，第 27–75 行，其调用调度上下文见 runAgent.ts，第 85–217 行（非官方历史快照备份）。

// 片段 A：读取。Agent 调度将模型选择的工具调用送入 MCP Tool。
const request = { serverName: this.serverName, toolName: this.toolName, input };

// 片段 B：准入。环境调用前仍由外层权限决定。
const permission = await context.canUseTool(this.name, input);
if (!permission.allowed) return permission.result;

// 片段 C：执行/写回。client 调用 server，结果交回 Tool 层。
const result = await this.client.callTool(request.serverName, request.toolName, input);
return formatToolResult(result);

当前官方手册旁证（辅助）：MCP 与 Permissions 说明当前 MCP 接入与授权体验；本文不从 2.1.88 推断今天的 transport 实现。

#实现对比与取舍

#OpenCode：现状与改进路线

#适用场景

#从地图回到选择：任务形状决定 Harness 策略

六要素的差异只有放回任务链路才有意义：流程决定是否隔离探索；约束决定哪些计划根本不可执行；持久化决定长任务还能记住什么；上下文决定模型当轮能推理什么；工具决定证据怎样回流；运行环境决定副作用最终在哪发生。

最短的结论仍然是：Codex 把更多 Harness 开关留给宿主，因此更适合强调审计、编排和环境治理的工程团队；CC 2.1.88 把更多常见策略封装成默认 runtime，因此更适合先隔离探索、再回收结论的低摩擦工作流。二者都不能替代对规则、关键证据与外部副作用的人工复核。

#OpenCode 的三阶段改进路线

这里的“改进”只针对本文选取的 Harness 保证，不比较模型质量、生态规模或产品偏好。

这条路线的收益不是“功能更多”，而是把现有工具、session、权限和 MCP 连接成可验证闭环；任何尚未合入的 PR 或 Issue 都只能作为候选方向。

#附录 A：六要素证据矩阵

#附录 B：怎样正确使用四层证据

• 每段代码只解释紧邻片段直接读取、写入或分支的对象；未展示部分不作确定断言。
• 文中的 I/O 例子是从相邻代码可直接推演的最小案例，不是性能基准或 UI 录屏。
• 若决策依赖当前 Claude Code 行为，先复查官方手册与实际安装版本；若依赖 Codex 实现，使用本文固定 commit，而非未来变化的 main 分支。