在讨论一个编程智能体（coding agent）是否足够强时，我们通常首先问：它用了什么模型？

模型是什么版本？推理强度（reasoning effort）设在什么级别？上下文窗口有多大？工具调用是否足够稳定？这些当然重要，但基础模型只是智能体最终表现的一个组成部分。

但在实际构建智能体系统时，很快会遇到一个更难解释的现象：

同一个模型，换一个 harness，表现可能完全不同。

本文所说的 harness 是位于模型与真实执行环境之间的系统层。它决定模型能看到什么上下文，可以调用哪些工具，工具以什么形式出现，执行结果怎样返回，什么时候压缩上下文，错误之后怎样恢复，以及一项任务如何从开始持续推进到结束。

在此前的 《Harness Engineering：模型之外的工程》 中，我把 harness 看成模型之外的执行结构：工具、权限、验证、观察、记忆和反馈共同决定一个智能体能否可靠工作。继续沿着这个方向看，还会出现一个更具体的问题：即使两个 harness 提供了相同的能力，它们是否都以模型容易使用的方式提供了这些能力？

本文把这种匹配关系称为 模型易用性（Model ergonomics）。这是本文为了讨论方便使用的工程术语，并不是已经标准化的学术概念。现有研究更常使用智能体计算机接口（Agent-Computer Interface，ACI）、智能体支架（agent scaffolding）、工具接口（tool interface）或 harness 设计等说法。这里用“模型易用性”，是为了集中描述一个具体问题：

harness 是否以适合某个模型的方式提供环境能力，让它更容易理解情况、作出决策、执行操作，并在出错后恢复？

这意味着智能体的实际能力既不能只归因于模型，也不能简单归因于 harness；模型与 harness 之间的匹配同样需要研究。

Harness 不是模型外面的壳

早期的大语言模型应用很容易被理解成一条简单链路：

task
  ↓
model
  ↓
answer

但智能体系统实际运行的过程更接近：

task
  ↓
harness constructs observation
  ↓
model reasons
  ↓
harness exposes actions
  ↓
model selects action
  ↓
harness executes
  ↓
harness transforms feedback
  ↓
model reasons again
  ↓
...

模型不是直接面对计算机，而是面对 harness 为它构造出来的世界。

SWE-agent 在 2024 年提出 Agent-Computer Interface 时，已经明确指出这一点：语言模型智能体是一种新的计算机用户，因此为它设计怎样的接口，会显著影响软件工程任务中的行为和性能。1

可以用一个概念式来表达这种关系：

Observed capability = f(Model, Harness, Environment, Budget)

它不是可直接计算的公式，只是提醒我们：实际测到的是一套完整配置的表现，而不是模型权重的孤立属性。其中尤其值得单独研究的是 Model × Harness 的交互。

2026 年的 Harness-Bench 更直接地研究了这一问题。它把工具、上下文、状态、权限、约束和恢复机制都视为 harness 的组成部分，并比较不同模型与 harness 配置下的执行轨迹。论文据此主张：报告智能体能力时，更适合以 模型与 harness 的组合配置（model-harness configuration） 为单位，而不能把结果简单归因于基础模型。2

所以只问“这个模型有多强”，在智能体场景中本身就是一个不完整的问题。

更准确的问题是：

在什么 harness、什么工具环境、什么上下文策略和什么执行预算下，这个模型能够表现出怎样的能力？

模型易用性关注能力是否容易发挥

模型易用性很容易被误解为“针对某个模型多写一些提示词”，但它涉及的范围更广。

一个模型理论上能够完成某项操作，并不意味着当前 harness 给它的就是最合适的操作接口。

假设模型只有一个非常强的工具：

exec_command(command)

那么从操作覆盖范围来看，它可以临时组合出很大一部分本地工具能力。模型可以通过 shell、Python、Perl、awk 或其他程序完成文件读取、目录遍历、搜索、批量处理、修改文件和运行测试。

所以问题不在于 shell “能不能表达”这些操作。通用 shell 的表达范围已经很广，真正需要比较的是模型使用这种接口时要承担多少额外决策和操作成本。

但模型面对的问题并不只有表达能力。

它还需要决定下一步应该采取什么行动，构造正确参数，控制副作用，理解工具结果，并在失败后恢复。harness 的质量还取决于：

  • 模型是否容易选择正确的行动；
  • 一次行动的粒度是否合适；
  • 工具参数是否容易稳定生成；
  • 工具结果是否包含必要而不过量的信息；
  • 错误是否容易分类；
  • 上下文是否保留了下一步需要的状态；
  • 模型犯错后是否容易恢复，并继续有效推进任务。

可以把这个区别写成：

capability completeness ≠ ergonomic fit

一个接口可能覆盖大量操作，却让模型承担过多底层决策；另一个接口可能提供很多结构化工具，却因为工具过多、语义重叠，让模型面对更多相似选项。这里所谓行动搜索空间（action search space），不是一个固定可测的数字，而是指模型在每一步需要区分和选择的可行动作集合。模型易用性关心的正是这种接口设计如何影响稳定执行。

Grok 运行在 Codex 上：协议兼容之后还有什么

这个问题在 Grok 运行于 Codex harness 的实践中表现得很具体。

我们的目标是让 Grok 尽可能沿用 Codex 已有的执行系统，而不必重新实现一个编程智能体。这些系统包括任务（Thread）和会话（session）的生命周期、上下文和历史记录、沙箱与审批、MCP、Code Mode、多智能体协作（Multi-Agent）、ToolRouter，以及 App Server 和 UI 契约。

对应的架构原则是：

Stock Codex owns the harness. Provider adaptation owns backend differences.

在当前设计中，Grok Provider 主要负责 Codex 与 Grok Responses API 之间真实存在的协议差异，例如请求与历史记录的映射、Grok Responses 特有的协议格式，以及工具名称的双向映射：把 Codex 中具有命名空间的规范工具表示（canonical namespaced tools）映射为 Grok 可以接受的扁平函数（flat functions），再将返回的调用还原为 Codex 内部的规范工具身份（canonical tool identity）。3

这些都属于 提供方兼容（Provider compatibility） 的工作。

它们回答的是：

Codex 的现有 harness 能不能通过 Grok API 正确工作？

但当模型开始执行编程任务后，又出现了另一类问题。

例如，在需要一次读取多个文件时，我们观察到 Grok 经常通过 exec_command 临时生成 Python 程序：

python3 - <<'PY'
from pathlib import Path

for path in paths:
    print(Path(path).read_text())
PY

这种做法并不意味着 Grok 无法使用 Codex。在我们观察到的任务里，它能够通过 Codex 提供的 shell 完成文件操作；真正值得研究的是，这种路径是否稳定、是否增加了不必要的步骤，以及是否影响任务成功率和恢复成本。

更值得问的是：

为什么模型会反复在 shell 内重新构造一个文件读取抽象？

这已经超出了提供方协议的问题，进入了模型易用性的范围。

Shell 是通用接口，但不是中性接口

在本文使用的、已接入 Grok 的 Codex release/rust-v0.151.0 中，Grok 4.6 的模型目录（model catalog） 配置了 UnifiedExec，而 apply_patch_tool_type 为 None。4

Codex 的工具规划代码会为 Unified Exec 注册 exec_command 和 write_stdin；原生的 ApplyPatchHandler 则只有在 model_info.apply_patch_tool_type 存在时才会进入工具注册表。5

在这个具体配置中，Grok 获得了一个表达能力很强的 shell，却没有获得 Codex 原生的 apply_patch 工具。

这个事实本身还不能证明 harness 设计有问题，更不能直接得出“给 Grok 增加更多文件工具，表现一定会更好”的结论。

但它揭示了通用 harness（generalized harness）中一个容易被忽略的问题：

通用接口并不意味着没有设计偏置。

如果所有模型都统一获得：

shell(command: string)

这种设计看起来十分通用，因为任何模型都能使用，而且大量计算机操作都能通过 shell 表达。

但选择 shell 作为所有行动的通用表示方式，本身就是一个明确的设计选择。它隐含着一个假设：模型能够稳定处理 shell 语法、引号、批处理、副作用、标准输出，以及 grep、sed、find、Python 等工具的组合。

对于擅长这些操作的模型，这种自由度可能很有用。对于另一个模型，同样的自由度可能只是增加了需要选择的行动，并带来额外的操作步骤。

这也说明，通用 harness 并不意味着完全没有专用设计。对特定交互方式的偏向，往往只是隐藏在了一个被认为足够通用的抽象之中。

GrokBuild 是一个设计信号，而不是结论

xAI 自己开源的 GrokBuild 提供了一个很有意思的对照。

它的工具运行时中存在一组明确标记为 Codex-specific 的工具：

apply_patch
grep_files
list_dir
read_file

源码说明这些工具来自 Codex 实现的移植和修改。6

这很容易产生一个过强的推论：

GrokBuild 有 read_file，所以 Grok 在 Codex 中也必须有 read_file。

目前没有足够证据支持这个结论。

GrokBuild 的设计只能证明：xAI 在为 Grok 构建自己的编程 harness 时，选择了向模型提供这些结构化文件操作。

不过，这个对照仍然有价值：两个都希望让 Grok 完成软件工程任务的 harness，可以为模型提供完全不同的行动词汇（action vocabulary）：

Codex                  GrokBuild

exec_command           read_file
write_stdin            list_dir
...                    grep_files
                       apply_patch
                       ...

如果同一个模型在两种环境中的行为明显不同，这个现象至少提醒我们：不能在没有控制 harness 差异的情况下，把结果全部归因于模型权重。

更值得注意的是，GrokBuild 的 ToolConfig 还区分了规范工具身份与客户端看到的呈现形式：工具名称、参数名称和描述都可以单独覆盖。7

这个设计提供了一个值得验证的架构方向：

工具的内部语义，与模型看到的名称、参数和描述，不一定要放在同一层。

这比直接复制 GrokBuild 的具体工具更值得研究，因为它允许系统保持同一执行语义，同时单独调整模型面对的接口。

通用 harness 与专用 harness 可以如何分工

承认模型易用性的重要性之后，也很容易走向另一个极端：既然不同模型适合不同的接口，就为每个模型维护一套专用 harness（specialized harness）。

例如：

Model A ToolRouter
Model B ToolRouter
Grok ToolRouter
...

短期内，这样做有时能针对某个模型改善基准测试（benchmark）表现。

某个模型不会使用一种工具，就给它换一种工具；某种上下文组织方式效果不好，就加一条针对该模型的分支；某个模型容易在特定位置停滞，就为它写一条专用的恢复规则。

但如果每个局部问题都通过复制一套模型专用实现来解决，很快会出现另一类成本：

semantic divergence
test explosion
model-version drift
duplicate runtimes
upgrade difficulty

模型本身也在持续变化。今天必要的临时补救方案，下一次模型升级后可能已经毫无价值，甚至会反过来限制新模型的能力。

问题不在于：

选择通用 harness，还是专用 harness？

而是：

哪些部分应该保持通用，哪些部分可以针对模型调整？

我目前更倾向于把它拆成三个层次。

┌────────────────────────────────────┐
│ Model Ergonomic Profile            │
│                                    │
│ tool presentation                  │
│ observation granularity            │
│ context policy                     │
│ reasoning defaults                 │
│ guidance / recovery                │
└────────────────┬───────────────────┘
                 │
┌────────────────▼───────────────────┐
│ General Semantic Harness           │
│                                    │
│ canonical tools                    │
│ ToolRouter                         │
│ sandbox / approvals                │
│ history / context                  │
│ multi-agent                        │
│ lifecycle / state                  │
└────────────────┬───────────────────┘
                 │
┌────────────────▼───────────────────┐
│ Provider / Wire Adapter            │
│                                    │
│ auth / endpoint                    │
│ request dialect                    │
│ reasoning projection               │
│ tool wire encoding                 │
│ response normalization             │
└────────────────────────────────────┘

这三层分别解决不同的问题。

语义层的 harness 应该保持通用

第一层是通用语义 harness。这一层应该尽量避免把模型偏好写进核心执行语义。

例如 Read File、Apply Patch、Exec、MCP Call、Web Search 和 Spawn Agent，可以在一个具体系统中被定义为稳定的规范语义操作（canonical semantic operations）。这里列出的不是所有 harness 都必须采用的标准工具集，而是一种架构示例。

同样，沙箱、权限、历史记录、工具生命周期、持久化和取消机制，也应该保持统一。

这一层最重要的不是让每个模型看到完全相同的界面，而是保证同一种操作最终经过一致的执行和权限边界：

specialize presentation; keep execution authority unified.

如果 Codex 已经拥有 ToolRegistry、ToolRouter、沙箱、历史记录和扩展运行时，那么为了支持 Grok 再创建一套 Grok ToolRouter，通常意味着架构开始分裂。

这也是本文引用的 Codex Third-Party Provider North Star 所采用的设计边界：Codex 核心保留统一的规范概念；能够明确归因于提供方 API 和传输契约的差异，才在后端适配边界处理。8

提供方兼容层只负责协议差异

第二层是提供方兼容层。不同后端存在真实的 API、认证、请求格式和工具编码差异，这一层负责把这些差异投影回统一语义。

以 Grok 为例，这一层可以处理：

logical Codex reasoning
        ↓
Grok wire reasoning

canonical namespaced tool
        ↓
backend-safe function name
        ↓
reverse projection
        ↓
canonical Codex identity

canonical history
        ↓
Grok-compatible request representation

这种专用适配有明确依据：各后端的契约不同。

它回答的是：

怎样在接入不同提供方时，仍然正确保留 Codex 的统一语义？

如果某个差异不能用提供方 API、传输协议或后端行为来解释，就需要谨慎判断：它是否真的应该由提供方兼容层处理？

例如，“Grok 更喜欢 read_file 而不是 shell”即使最终被实验验证，也不是 Grok Responses API 的协议事实。

它属于另一层。

模型易用性配置决定如何呈现能力

第三层才是模型易用性配置（Model ergonomic profile）。

它解决的是：

当 harness 已经能够正确运行以后，应该怎样把这些能力呈现给当前模型？

这一层可以控制的内容可能包括：

  • 哪些规范工具直接提供给模型；
  • 工具名称和描述如何呈现；
  • 参数模式（schema）如何组织；
  • 一次行动的粒度；
  • 上下文如何压缩；
  • 工具结果的详细程度；
  • 默认推理配置；
  • 出错后的恢复提示；
  • 直接提供（direct）、延迟提供（deferred）或其他工具呈现策略。

最重要的边界是：

specialize the interface, not the execution authority.

假设未来的基准测试确实证明 Grok 使用 read_file 明显优于通过 exec_command 自己组织文件读取。

正确的方向更可能是：

model-facing read_file
        ↓
canonical filesystem operation
        ↓
stock Codex execution environment

而不是：

GrokReadFileRuntime
GrokFileSystem
GrokToolRouter

前者只改变模型看到的接口，后者则开始复制 harness 的语义实现。

能力支持与易用性偏好需要区分

如果未来把模型易用性引入模型配置，还需要区分易用性偏好（ergonomic preference）与能力支持（capability），不能把前者当成后者。

例如：

supports_image = true

描述的是能力支持情况。

它回答：

这条执行链是否支持图像？

而：

prefer_file_tools_over_shell = true

如果未来存在类似策略，它描述的就是易用性偏好。

它回答：

根据当前基准测试，这种接口是否更容易让模型稳定发挥？

两者的稳定性完全不同。

能力是否受支持，通常可以从 API 契约、模型声明和端到端执行结果中得到相对明确的证据。易用性策略则更像经验性假设，可能随着模型版本、系统提示词、工具实现、预算或训练方式变化而失效。

因此，模型易用性策略需要满足几个条件：

  • 有基准测试或执行轨迹作为证据；
  • 可以单独替换；
  • 可以进行回归验证；
  • 不把经验偏好固化为长期语义契约；
  • 不因为一次观察就写入长期架构。

这也是为什么看到 Grok 使用 Python，并不足以成为增加 read_file 的理由。

观察到异常行为，只是调查的起点，还不足以得出设计结论。

模型标识可能也不是最终的抽象依据

进一步说，模型易用性最终也未必应该完全围绕模型标识（model ID）建模。

我们当然可以从：

grok-4.6
model-a
model-b

选择不同的配置。

但模型标识本身也可能只是一个粗粒度代理。更值得研究的是一些可通过实验观察的行为维度，例如：

shell fluency
tool-schema adherence
parallel-call reliability
context-noise tolerance
self-recovery strength
action-granularity preference
planning reliability

这些名称目前只是候选维度，并没有形成成熟、统一的测量标准。现在就把它们固定成长期数据模式还为时过早，更合理的是先把它们当作实验假设。

但它们指出了更重要的研究问题。

我们想知道的不是：

Grok 应该有哪些特殊代码？

而是：

采用怎样的交互方式，Grok 才能最稳定地完成任务？

同样的问题也适用于同一模型家族中的不同模型、不同推理配置，甚至模型升级前后的不同版本。

使用同一个 API，并不意味着最适合它们的智能体交互方式也完全相同。

Harness 的质量：通用性与适应性

接受这个判断以后，评价“一个 harness 是否优秀”，也需要更明确的标准。

第一个维度仍然是 通用性（Generality）：

能接入多少模型？能通过多少种提供方运行？能支持多少种环境？

这是传统意义上的可移植性（portability）。

还应该考察第二个维度：适应性（Adaptability）。

它关心的是：接入一个新模型以后，harness 能否通过范围有限、可验证、可回退的接口调整改善执行表现，而不必复制整套运行时。这里的重点不是“为模型增加多少特殊代码”，而是适配成本是否局部、可测、可维护。

于是会出现两种完全不同的系统。

一个 harness 可以支持一百个模型，却只给所有模型提供同一个接口，功能限于它们都能使用的最小公约数。

另一个 harness 则可能保留同一套语义内核，同时让不同模型使用各自经过验证的工具呈现方式、上下文策略和恢复策略。

只统计“支持多少模型”，无法区分这两种 harness 的质量。

这里不适合强行定义一个“harness efficiency”比率，因为所谓模型的“潜在能力上限”既不可直接观测，也依赖任务、环境和预算。更实际的目标是做成对照实验：固定模型、任务和预算，只改变 harness 的某个因素，再观察成功率、成本、延迟、恢复行为和执行轨迹如何变化。

一个好的 harness 不只是让模型“能运行”，还应该减少接口、上下文组织和执行循环给任务完成带来的额外摩擦。

基准测试应该评估 Model × Harness

基准测试的设计也需要随之调整。

假设我们观察到：

Model A + Harness X = 70
Model A + Harness Y = 48

Model B + Harness X = 52
Model B + Harness Y = 69

那么单独问“Model A 和 Model B 谁更强”就缺少必要条件，因为观察结果明显依赖 harness。

至少应该改成：

在怎样的 harness、预算和环境下，哪一种模型与 harness 的组合更有效？

近期的 Same Model, Different Harness 采用了更直接的做法：固定模型，改变上下文管理和任务停滞时的处理方式，再观察编程智能体的结果如何变化。这个工作仍是较新的预印本，因此具体结果不宜单独视为成熟共识，但研究设计本身清楚地展示了如何单独考察 harness 带来的影响。9

Self-Harness 则从另一个方向出发：从执行轨迹中发现特定模型的失败模式，再提出范围较小的 harness 改动，并通过回归测试验证。10

这些工作虽然研究设置不同，却支持同一种方法论：

模型易用性应该通过受控实验研究，而不是通过“这个调用看起来不够优雅”来决定。

回到 Grok：怎样验证模型易用性

对于 Grok 在 Codex 中频繁通过 Python 组织文件操作这件事，我不会从“怎样阻止它写 Python”开始。

使用 Python 本身并不代表失败。

应该首先定义重要的观测量，例如：

  • 任务是否成功；
  • 补丁是否正确；
  • token 用量；
  • 工具调用次数；
  • 延迟；
  • 无效行动比例；
  • 错误恢复率；
  • 不必要的 shell 复杂度；
  • 涉及审批和沙箱的操作范围。

然后在受控条件下比较不同的 harness 配置，例如：

A. current Codex tool surface

B. current surface
   + improved tool guidance

C. current surface
   + stock apply_patch

D. current surface
   + read_file

E. current surface
   + read_file / list_dir / grep_files

下面的数字只是示意。假设实验结果是：

A  61%
B  62%
C  69%
D  69%
E  72%

而且改善能在重复实验和回归任务中保持，那么针对模型易用性作出的专用调整就有明确价值。

如果结果只是：

A  61%
E  62%

差异又落在实验噪声范围内，而维护成本和工具接口范围明显增加，那么即使 Python 调用比例从 80% 降到 10%，也不足以证明这个调整有工程价值。

工具调用变得“更漂亮”，不等于智能体变得更强。

为什么 apply_patch 是一个更合适的早期实验

在本文讨论的 Grok × Codex 配置里，我会优先把 apply_patch 作为一个较窄的实验，而不是立即增加完整的 read_file / list_dir / grep_files 工具组。

原因首先是架构成本。

Codex 已经拥有原生的 ApplyPatchHandler，只是当前 Grok 模型目录 没有启用对应的 apply_patch_tool_type。

相比增加全新的工具集合，更窄的实验是验证 Grok 是否可以通过现有的可逆工具映射正确使用原生 apply_patch。

其次，结构化工具在模型易用性之外还有一项价值：它把操作意图保留在工具调用的结构中。

当模型调用：

apply_patch

时，harness 知道模型正在修改文件。

当模型调用：

exec_command("python3 ...")

修改文件时，操作的具体含义就隐藏在了通用的代码执行中。

前一种形式更容易被沙箱、审批、执行跟踪、遥测、回放和失败分类直接识别。结构化工具的价值因此不只在于模型是否更容易使用，还在于它能让 harness 在不解析任意代码的情况下知道“这是一项文件修改”。

增加文件工具时，继续共用运行时

假设基准测试最终证明 Grok 确实明显受益于 read_file、list_dir 或 grep_files。

这仍然不意味着应该把 GrokBuild 的整个工具运行时移植进 Codex。

Codex 已经允许扩展工具接入同一个 ToolRegistry 和 ToolRouter。11

更合理的结构是：

model-facing compatibility tool
        ↓
Codex extension adapter
        ↓
stock filesystem / sandbox context
        ↓
stock ToolRouter

模型获得了更容易使用的行动词汇，而系统继续保持：

one history
one router
one sandbox
one execution authority

这正是通用语义 harness 与针对模型的易用性适配能够同时成立的关键。

语义通用，交互可特化

最终，我认为通用 harness 与专用 harness 之间最有价值的分工可以用一句话概括：

语义尽可能保持通用；易用性方面，允许根据测量结果进行专用适配。

对应的系统结构是：

Generalized Semantic Harness
        +
Thin Provider Compatibility Layer
        +
Measured Model Ergonomic Profiles

第一层阻止系统随着模型数量增加而不断分裂。

第二层处理不同后端实际存在的协议差异。

第三层承认一个需要通过实验持续验证的事实：不同模型即使接入同一 API，也可能表现出不同的工具选择习惯、上下文容忍度、行动粒度和恢复模式。

成熟的 harness 应该承认这些差异，同时避免因此为每个模型重新实现一套智能体运行时。

难点在于保留统一的语义、安全边界和执行权，同时允许根据模型的实际行为，对接口进行范围有限、可以验证的调整。

过去，我们首先关心的是：

Can the model run?

后来变成：

Can the model use tools?

再后来是：

Can the model finish long-horizon tasks reliably?

模型易用性把问题又向前推进了一步：

Does this harness allow this model
to use its capabilities efficiently and reliably?

这可以成为评价智能体 harness 的一个基本维度。

更准确地说，可观测的智能体能力由模型、harness、环境、任务和预算共同约束。优化其中任何一个部分，都不应假设其他部分是透明的常量。需要被测量和改进的，是模型与 harness 共同组成的执行系统。

Footnotes

  1. John Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, 2024. ↩

  2. Yilun Yao et al., Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows, 2026. ↩

  3. 本文 Grok × Codex 案例基于 Harness-X-Harness/codex 的 release/rust-v0.151.0 分支。其中 Grok Provider 负责请求映射、Responses 协议格式和扁平函数映射等提供方特有的适配工作。 ↩

  4. grok_catalog.rs 中当前 Grok 4.6 模型目录配置 shell_type: UnifiedExec、apply_patch_tool_type: None 和 tool_mode: None。 ↩

  5. spec_plan.rs 中，Unified Exec 注册 ExecCommandHandler 和 WriteStdinHandler；ApplyPatchHandler 只有在 model_info.apply_patch_tool_type.is_some() 时注册。 ↩

  6. xAI GrokBuild 的 implementations/codex 模块包含 apply_patch、grep_files、list_dir 和 read_file，源码将其描述为从 Codex 移植并修改的专用工具实现。 ↩

  7. GrokBuild 的 ToolConfig 支持 name_override、params_name_overrides 和 description_override，将内部工具身份与面向客户端的呈现形式分开。 ↩

  8. Codex Third-Party Provider North Star 将目标定义为保留原生 Codex harness，只在提供方映射边界处理已经验证的后端 API 差异。 ↩

  9. Sydney Lewis, Same Model, Different Harness: Different Coding-Agent Results, 2026. 该工作在本文写作时仍属于较新的预印本，因此这里主要引用其研究问题和实验设计，而不把单篇结果视为最终定论。 ↩

  10. Self-Harness: Harnesses That Improve Themselves, 2026. ↩

  11. 当前 Codex spec_plan.rs 会把核心工具、MCP 工具、扩展工具和动态工具汇入同一个 ToolRegistry，再构造统一的 ToolRouter。这样，面向模型的兼容工具就可以通过现有接口接入，无须复制执行运行时。 ↩