O'Reilly Radar：应按控制层而非厂商选择编码 harness

O'Reilly Radar· Nicole Koenigstein·2026-11-06 19:54· 34 分钟前AI 评分65

按你需要控制的内容而非构建者来选择编码 harness

AI 导读

O'Reilly Radar 作者提出应按需要控制的层级而非厂商来选择编码 harness，并对比了 Claude Code（运行内控制）、Codex（执行隔离）、Pi（外层生命周期）和 DeepSeek harness（插件组合）的控制重心。

正文 · 原文

还记得 2019 年吗？那时只有寥寥几个语言模型可选，而且上下文窗口都很有限。那个世界已经一去不复返，感觉像是被遗忘的过去。如今，旗舰厂商和开源项目在模型家族、规模、能力和部署选项上展开竞争。编码 harness 似乎也在朝同一方向发展。

表面上看，Claude Code、Codex、Pi、DeepSeek Harness 以及其他编码 harness 似乎都在做同一件事：借助模型帮你构建软件。但仔细观察就会发现，每个 harness 让你控制的是不同的部分。模型能看到和改变什么？它如何使用工具？它在哪里运行，失败时会发生什么？所以，与其问哪个编码 harness 整体最好，不如问：

你需要控制 harness 的哪些层？

感谢所有这些 harness！然后呢？

选择编码 harness 不只是看哪个模型写的代码最好。你还在选择 harness 提供什么、你能改变什么，以及你必须自己构建什么。如果它不提供验证、持久状态、修复路由或强制的执行边界，这些责任就仍在你身上。你仍需对工作流的可靠性和治理负责。

一般来说，每个 harness 都有一个重心：一个让你获得最直接控制的层。下表刻意做了高层概览，说明这个重心在哪里。它不是功能矩阵，而且在实际中边界是重叠的。Claude Code 也能以非交互方式运行并在沙箱内运行，Codex 也会读取仓库指令，而且它们都在快速变化。重点在于展示每个 harness 默认在哪些方面给你杠杆，以及哪些工程工作很可能仍要由你承担。

表 1. 每个编码 harness 的主要控制所在

把这张表当作地图，而不是排名。给你更多控制的 harness 也让你需要构建更多东西，而开箱即用做得更多的 harness 也会替你决定更多。哪种权衡合适，取决于你的项目实际需要拥有哪一层。

Claude Code：运行内部的控制

Claude Code 让你能细致控制实现如何展开。CLAUDE.md 提供常驻指令，技能添加任务专属的操作手册，子代理分担工作，钩子在工具调用前后拦截操作。与只是拒绝某项操作的权限规则不同，钩子可以解释拒绝原因，或立即把编译器或策略失败返回给代理。

这些控制让你能够深度引导编码循环，但它们运行在 Claude Code 现有的生命周期之内。如果你需要控制外层生命周期本身，就需要另一层。

Codex：通过分离实现控制

Codex 为你带来编码任务与其执行环境之间的分离。非交互式的 codex exec 运行可以在指定仓库中处理一个范围明确的任务，运行在由操作系统强制实施的沙箱之下，并返回受 schema 约束的结果。

这对独立验证很有用。你可以给 Codex 一个干净的检出，排除构建者的指令，限制可写路径，并针对代码质量、测试缺口、持久性或用户可见行为分别运行审查。沙箱取决于操作系统，但它把范围约束从提示词中移到了执行边界上。

Pi：对循环的控制

Pi 为你带来对编码循环本身的控制。它的工具、命令、事件处理器、上下文、模型和会话状态都可以被扩展或替换。这让你能够决定哪些步骤保持智能体驱动，哪些遵循确定性策略。

例如，局部缺陷可以返回实现阶段，重复出现的缺陷可以强制重新规划，相互冲突的发现可以触发复查或人工审查。Pi 还可以在这个生命周期内运行智能体，因此它不只是一个确定性编排器。在下面的示例中，我利用它的可编程性让外层决策变为确定性的——这是我的设计选择，而不是 Pi 的定义。

DeepSeek 的 harness：通过组合实现控制

当你想要替换 harness 的整个部分，而不是引导或包装它们时，DeepSeek 的 harness 就很有用。工具、会话、生命周期行为、验证和治理都是可组合的插件，循环本身也是如此。这让你可以替换一个组件而无需重建其余部分。

代价是，你的控制效果取决于你所组合的插件。Pi 给你一个可在此基础上构建的最小核心，而 DeepSeek 的 harness 给你一组可组装的部件。

一个实际示例

让我给出我实际想要解决的问题：可靠地迁移一个遗留的 Python 2.7 应用，同时不改变多年积累的行为，也不破坏其持久化数据。让代码在 Python 3 上运行只是其中一部分。我还需要保留行为、在两种运行时下验证数据、控制编码智能体可以更改什么，并决定当测试或验证步骤失败时应该发生什么。

因此，我从一个非常不同的角度来处理编码 harness 的选择。我不再问哪一个最好，而是问每一个能在控制、隔离和生命周期管理方面为我带来什么。答案让我使用了不止一个：

• Claude Code 构建了移植，因为我想要内部引导、专用技能、钩子，以及一个由实现和审查子智能体组成的工厂。
• Codex 在隔离运行中进行了验证，因为我想要独立的模型上下文、干净的工作区、受约束的写入和结构化的发现。
• Pi 掌管外层生命周期，因为我想要持久状态、证据验证、有界修复、重新规划规则和人工升级。
• 冻结验收，包括 Playwright 和 Python 2/3 差分检查，在智能体之外运行，因此构建者和验证者都无法重新定义成功。

我在这里没有使用 DeepSeek 的 Harness，是因为我想要一个非常小、可以端到端读懂的外层生命周期，而不是因为它无法胜任这项工作。为了先检查这套设置是否真的会带来差别，我构建了一个小型 Python 2 应用，其中包含与真实迁移相同类型的陷阱。然后，我将组合式设置与单个 Claude Code 会话进行了比较，在该会话中 Claude 可以验证并测试自己的代码。

有趣的是，两套设置都通过了全部 25 个隐藏行为测试。然而，单会话设置在未加提示的情况下，将两个不同的 Python 2 字典键——Unicode 的 u’é’ 和字节字符串 ‘é’——合并成了一个 Python 3 字符串。数据保存后，一个条目被永久丢失。单会话设置还在未记录的情况下，将 Python 2 的 Unicode 值改成了字节。

测试套件漏掉了它。Claude 自己的测试漏掉了它。数百条记录的行为比较漏掉了它。甚至我手写的参考移植版也有同样的漏洞。

但接下来发生的事情更有意思。两个独立的 Codex 验证器各自复现了该缺陷。Claude 并没有简单接受这一发现；它提出了异议。随后 Pi 启动了一次新的 Codex 运行，只向它提供该发现和 Claude 的论点。独立复核维持了该发现，Claude 接受了它。Pi 将该缺陷转入一次有边界的修复，下一轮验证确认两个键及其原始类型现在都得以保留。

这也颇具讽刺意味，因为模型常常因谄媚而受到批评。你一问 “你确定吗？”，它们就会道歉并重写原本能正常工作的代码。而在这里，情况恰恰相反。Claude 对两个独立验证器已复现的缺陷提出了异议。它的会话上下文中包含自己的实现历史和通过的测试，所有这些都支持该补丁。一个全新的验证器上下文打破了这种自我强化的框架。独立验证之所以重要，不是因为第二个模型自动就是对的，而是因为它没有被锚定在同一段历史上。

重要的一点是，没有任何单个 harness 值得获得全部功劳。更好的结果来自组合我所需要的控制手段：内部引导、独立执行、冻结的行为证据，以及确定性的生命周期策略。

如何选择你的编码 harness

在选择编码 harness 时，首先要考虑你需要的控制级别，以及你准备自己构建剩余 harness 的多少部分。一个有用的比较可以从以下问题开始：

• 我是想配置一个现有的编码循环、扩展它，还是替换它的部分内容？
• 我能否在项目所需的级别上控制工具、上下文、记忆和模型选择？
• 权限、允许列表和策略在哪里强制执行：在指令中、应用逻辑中，还是在操作系统中？
• 我能否在操作和生命周期事件发生前后拦截它们？
• 编排、状态管理和会话生命周期中，有多少部分是我可以更改或编排的？
• 该 harness 为可观测性、验证和结构化证据暴露了什么？
• 该 harness 提供了哪些可靠性和治理控制，哪些仍然需要我自己构建？
• 如果我的需求跨越多个控制层，该 harness 能否与其他工具和 harness 协同工作？

这些只是帮你入门的示例，并非详尽无遗的清单。对你而言重要的问题还取决于你在构建什么、你愿意给编码智能体多少自主权，以及当它失败时你仍需承担哪些责任。

你的答案可能会把你引向 Claude Code、Codex、Pi、DeepSeek 的 harness，或者完全另一个编码 harness。归根结底，开发者的名字只能告诉你谁打包了运行时，而不能说明你的保障在哪里。无论你最终选定一个 harness，还是编排多个 harness，原则都是一样的：根据它给你的控制边界来选择工具，并问自己是否想让智能体自行定义其成功的标准。

来源：O'Reilly Radar · oreilly.com