Agent 竞争转向 Harness：四家路线拆解与选择指南

模型能力决定上限，但真正拉开 Agent 产品差距的，是模型与任务之间的运行控制层——Harness。Anthropic、OpenAI、DeepSeek 等大厂纷纷公开补 Harness，背后是 Context、成本与验证成为新瓶颈。本文从 AI 产品交付视角，拆解 Harness 边界与四条技术路线差异。

只看模型，已经解释不了今天的 Agent 产品差距。

同一个模型，接入不同的工具、上下文策略、权限规则和执行环境，可能表现得像两个完全不同的模型。一个能连续工作几十轮、修改文件、运行测试并在失败后继续；另一个会重复调用工具、忘记约束、烧掉大量 Token，最后还把半成品当作完成结果

这也是为什么过去几个月，越来越多团队开始公开补 Harness：

• Anthropic 通过 Claude Agent SDK，向开发者提供与 Claude Code 相同的工具、Agent Loop 和 Context Management；
• OpenAI 明确把 Codex App、CLI、IDE Extension 背后的开源系统称为 Codex Harness，并通过 SDK 和 app-server 向产品开放；
• DeepSeek 直接发布 DeepSeek Harness，把模型、工具、Session、Sandbox、Storage、Loop、Scheduling 和 UI 都拆成插件；
• Pi Agent 则提供轻量、跨模型、可修改的 Agent Runtime，并在 Harness V2 设计中继续探索耐久运行和故障恢复

表面看，各家都在做 Agent 框架。真正发生的变化是：模型公司与框架团队正在争夺模型与真实任务之间的运行控制层

大厂现在补 Harness，是因为模型已经强到足以执行真实任务，Context、成本、安全、状态和验证反而成为能力兑现的新瓶颈

作为 AI 产品经理，我关心的不是某个仓库怎样命名自己，而是一项真实任务怎样被模型持续执行、怎样受到控制、怎样被证明已经完成。因此，这篇文章直接给出我的边界：

只要一个系统开始负责模型每一步看见什么、可以做什么、怎样继续、何时停止、失败后如何恢复，以及凭什么证明任务已经完成，它就进入了 Harness 的边界

下面的判断会引用官方资料、源码和论文。这些材料负责提供可核验的事实；Harness 的边界、四家路线的差异，以及 Context 在其中的位置，由我从 AI 产品交付视角给出判断

模型决定能力上限。Harness 决定系统兑现率。Context 决定模型每一步基于什么任务现实做判断

换成一个公式就是：

Agent 实际表现 = 模型能力上限 × 系统兑现率

我把系统兑现率定义为：模型的潜在能力在成本、时间和安全约束下，最终转化为可验收任务结果的程度

在这三者里，我把 Context 放在最重要的位置。产品团队做的状态、权限、恢复和验收工程，最终都在为模型生产、约束和更新下一步所处的任务现实

Agent 的竞争单位，已经从裸模型扩大为模型、Harness 与任务环境组成的完整运行系统

这篇文章会回答五个问题：

• Agent 从一次模型调用，为什么一步步长成了 Harness？
• Product、Application、Harness、资源与执行环境四层怎样分工，Loop Engineering 与 Graph Engineering 又分别解决什么？
• 为什么大厂现在都在补 Harness，Claude、Codex、DeepSeek、Pi Agent 四条路线又为什么不同？
• 独立开发者应该怎样选，AI 产品经理为什么需要一份 Agent Runtime Spec？
• 为什么 Harness 代码很难成为壁垒，真正难复制的垂直运行资产，本质上仍然是 Context？

一、Harness 是 Agent 一层层长出来的

理解 Harness，最好的方式不是背定义，而是按任务复杂度重建它的能力叠加过程

我们用一个贯穿全文的任务来讲：

用户让一个 Coding Agent 定位登录失败的问题，修改代码，运行测试，提交变更，并创建一个 Pull Request

如果模型只需要解释报错，单次生成就够了。可一旦要求它真的完成这个任务，系统会不断长出新的能力

1. 第一层能力：模型只负责生成

最简单的 AI 产品链路很短：

用户输入 → Prompt → 模型 → 文本输出

模型可以解释登录失败的常见原因，也可以生成一段修复建议。它没有读取代码库，不知道当前分支，更无法修改任何文件

这个阶段的核心问题是生成质量。团队主要研究 Prompt、模型参数、上下文窗口和输出格式

2. 第二层能力：推理让模型学会分解任务

模型具备更强推理能力后，可以把任务拆成步骤：

• 查看报错日志；
• 定位登录相关代码；
• 找到失败条件；
• 修改代码；
• 运行测试；
• 检查结果

推理解决了下一步做什么的问题，却没有给模型行动能力。它仍然只能提出计划

3. 第三层能力：工具调用让模型开始改变环境

接入文件读取、搜索、Shell、代码编辑和 Git 工具后，链路变成：

目标 ↓判断下一步 ↓调用工具 → 获取结果 ↓更新判断 → 继续调用 ↓满足停止条件 → 返回结果

这就是最基础的 Agent Loop

从这一刻开始，问题发生了质变。模型不再只生成内容，它开始读取私有数据、修改文件、启动进程、访问网络，甚至向外部系统写入结果

工具带来了执行能力，也同时带来四类新问题：

• 该给模型哪些工具？
• 每个工具在什么条件下可以调用？
• 返回结果过长时，哪些内容应该进入下一轮上下文？
• 修改文件、发消息、创建工单这类动作，失败后能否重试？

4. 第四层能力：信息源与持续状态增加后，难题变成 Context 选择

任务一长，模型会忘记用户要求、已完成步骤和前面的工具结果，于是团队开始增加：

• 对话历史；
• 项目规则；
• 用户偏好；
• 长期记忆；
• 向量检索；
• 自动摘要；
• 工具结果缓存

信息越来越多，新的问题随之出现：模型每一步到底应该看到什么？

登录故障任务可能产生上万行日志、几十个搜索结果、多次测试输出和大量代码差异。全部塞进上下文会变贵、变慢，也会让关键证据被噪声淹没。直接截断又可能删掉真正的报错位置

DeepSeek Harness 的spill-policy展示了一种具体做法：过大的纯文本工具结果可以把完整内容写入 Session 级的外部对象，模型当前只看到头尾预览、位置和检索提示；需要时再通过路径和范围读取原文。这里最值得关注的原则是：压缩可以改变信息所在的位置，但不应轻易破坏信息的可恢复性。

Memory 解决的是信息能否被保存。Context Engineering 决定的是，在当前这一步，哪些信息应该以什么形式被模型看见

5. 第五层能力：Workflow 和 Graph 开始约束路径

模型自由循环太容易跑偏，产品团队开始加入 Workflow 和 Graph：

• 测试没有通过，不能进入提交阶段；
• 修改核心认证逻辑前，必须先生成变更计划；
• 创建 PR 前，必须通过单元测试和静态检查；
• 高风险操作需要人工批准

裸 Loop 和裸 Graph 只能描述基本运行结构。进入真实任务后，团队必须继续把它们工程化

6. 第六层能力：任务进入真实环境，Harness 成为必要的控制系统

当 Agent 需要持续工作几十轮，并且真的改变外部世界，分散的 Context、工具、状态、权限、恢复、观测和验证能力就必须汇合为统一运行控制层

在我的定义里，Harness 是连接产品与模型、任务与环境的运行控制系统。它负责让模型在时间中持续工作，并让每一步行动处于可控、可追踪、可恢复、可验收的边界内

7. 两个核心工程对象：Loop Engineering 与 Graph Engineering

Harness 真正要工程化的，不只是一次工具调用，而是两种不同尺度的运行问题

Loop Engineering处理 Agent 每一步怎样运行。当前 Context 怎样组装，模型怎样决定下一步，工具结果怎样回到下一轮，失败后怎样纠偏，何时压缩、重试、暂停和停止，都属于 Loop Engineering

Graph Engineering处理整项任务怎样穿过业务状态。任务有哪些节点和依赖，何时分支、并行和汇合，哪些节点允许 Agent 自由循环，哪些节点必须人工批准，中断后从哪里恢复，失败后进入重试、补偿还是转人工，都属于 Graph Engineering

二者不是替代关系。一个 Graph 节点内部可以运行 Agent Loop；Graph 负责全局任务结构，Loop 负责局部自主执行

Loop Engineering 决定 Agent 每一步怎样想、怎样做、怎样纠偏。Graph Engineering 决定整项任务经过哪些状态、分支和人工节点

二、为什么能力越多，Agent 反而越容易失控？

很多 Agent 在 Demo 里看起来很聪明，进入真实产品后却迅速暴露问题。原因很简单：单次回答主要考察模型，长任务考察的是整个运行系统

可以把问题压缩成三组

1. 信息问题：看见太少会盲，看到太多也会盲

一次登录故障排查里，模型需要同时知道：

• 用户真正要求修复什么；
• 当前仓库和分支处于什么状态；
• 哪些文件已经读过和修改过；
• 最新测试失败在哪里；
• 团队编码规范和安全要求；
• 哪些动作已经得到批准；
• 最终完成标准是什么

少一项，模型可能基于错误前提行动。全部长期保留，Token 成本、延迟和注意力噪声又会持续上升

长上下文只扩大容量，不会自动完成优先级判断、版本管理、去重、压缩和按需恢复。Context 管理失败时，更大的上下文窗口只会容纳更多混乱

2. 行动问题：错误会产生真实副作用

文本答错了，可以重新生成。工具调用错了，可能覆盖文件、删除数据、重复创建工单，或者向错误的人发送消息

最棘手的是外部动作存在一个无法彻底消除的模糊窗口：

系统写入工具 Intent ↓外部工具已经执行 ↓系统还没来得及记录结果，进程崩溃

恢复后，系统无法仅凭本地状态判断外部动作是否成功。直接重试可能重复执行，不重试又可能丢失结果

Pi Harness V2 在工具效果发生前写入 Intent，并记录工具的safe或never重放策略。恢复时，只有持久化记录与当前工具声明都为safe，才会重新执行；否则写入 syntheticinterruptedresult，不自动重放。设计文档同时把 exactly-once Hook Side Effects 明确列为 non-goal。因此，产品若要确认外部动作的真实结果，仍需额外增加状态查询、幂等键或人工核验

这不是某个框架的缺陷，而是所有会改变外部世界的 Agent 都必须面对的系统问题

3. 控制问题：没有 Trace 和验收，就不知道错在哪里

一个 Agent 最终没有修好登录问题，可能有完全不同的原因：

• 模型推理错了；
• Context 缺少关键日志；
• 工具描述让模型选错了动作；
• 工具执行失败但错误被截断；
• 权限策略阻止了必要操作；
• Loop 没有正确停止；
• 测试只检查了局部结果；
• Agent 自己声称完成，但仓库状态并未达到要求

如果系统只保存最终回答，团队会把所有问题都归因于模型。只有保留模型请求、上下文注入、工具调用、状态变化、批准记录、成本和最终环境结果，才可能做真正的归因

Harness 不会凭空提高模型智商。它减少的是信息、行动和控制链路中的系统损耗

OpenAI 在 Codex Harness 的公开案例里给出过一个很直观的结果：在 ARC-AGI-3 上，保留推理与 Context Compaction 将 GPT-5.6 Sol 的成绩从 13.3% 提高到 38.3%，同时把输出 Token 降低到原来的六分之一。这个数字不能外推到所有 Agent 任务，但它至少证明了外围运行策略可以同时改变效果与成本。OpenAI：Codex as a platform

三、用一张架构图看清产品层、应用层和 Harness 层

市场上的混乱，很大一部分来自把不同层级的东西放在同一张表里比较

Claude Code、Codex App、Pi Coding Agent 是用户可以直接使用的产品入口；Claude Agent SDK、Codex app-server、DeepSeek Harness、pi-agent-core更接近运行和开发组件；MCP 是连接工具与数据的协议；模型只是完整系统中的一个能力源

要把它们放进同一张图，可以使用下面四层架构

第一层：产品层

产品层是用户真正接触的体验，包括：

• Chat、IDE、Terminal、任务列表、运营后台；
• 任务创建、进度展示、打断和继续；
• 证据、Diff、成本和风险提示；
• 审批、反馈和人工接管；
• 最终结果如何回到业务系统

这一层回答：用户怎样把任务交给 Agent，又怎样知道它做了什么？

第二层：应用层

应用层表达具体业务，包括：

• 用户、订单、工单、设备、仓库等业务对象；
• 业务规则、状态机和固定 Workflow；
• 工具的业务语义与前置条件；
• 成功标准、风险等级和人工职责；
• 数据回写、补偿和系统记录

这一层回答：这个 Agent 在完成哪一种工作，什么才算完成？

应用层定义业务规则、风险等级和成功标准；Harness 把这些定义执行为工具暴露、审批、状态迁移、恢复和验证机制

第三层：Harness 层

Harness 是中间的运行控制层，通常包含七组能力：

• Agent Loop 与调度：何时请求模型，何时执行工具，何时停止；
• Context 管理：选择、组装、压缩、外部化、恢复每一步输入；
• Session 与 Runtime State：保存对话树、当前运行进度、待处理消息和恢复点；
• Tool Lifecycle：注册、描述、调用、校验、重试和返回工具结果；
• Policy 与 Approval：权限、Sandbox、预算、超时和人工批准；
• Durability 与 Recovery：持久化关键状态，处理中断、重放和恢复；
• Events、Trace 与 Runtime Verification：让执行过程可见、可归因、可验证

这一层回答：模型怎样在真实环境里持续、可靠、低成本地运行？

第四层：资源与执行环境层

这一层提供 Agent 可以调用的真实资源：

• Claude、GPT、DeepSeek、本地模型等模型服务；
• 数据库、搜索、浏览器、企业 API、文件系统；
• MCP Server、CLI、HTTP API 和自定义工具；
• 向量库、对象存储、Session Store；
• 本地进程、容器、虚拟机、云 Sandbox；
• 代码仓库、生产系统和外部世界

这一层回答：Agent 调用哪些能力，又可以读取和改变什么？

安全、成本、评测和可观测性是横向约束，应当贯穿四层

Harness 处理的是让这条路径能够在真实环境中长期运行的全部条件

公开产品与底层组件怎样对应？

字段 1：用户看到的产品或入口

字段 2：公开的底层关系

字段 3：所在层级

字段 1：Claude Code CLI

字段 2：Anthropic 表示 Agent SDK 提供与其相同的工具、Agent Loop 和 Context Management

字段 3：产品入口；Agent SDK 是可编程运行组件

字段 1：Codex App、CLI、IDE Extension

字段 2：OpenAI 明确表示三者由同一套开源 Codex Harness 驱动

字段 3：产品入口；SDK 与 app-server 提供集成面

字段 1：DeepSeekdsh web

字段 2：DeepSeek Harness 建立在 Cordis 插件系统上；官方页面以 Standard、Code、Minimal、Creator 展示四种 Agent Preset

字段 3：dsh web是操作入口；Harness 与 Cordis 属于运行和框架组件

字段 1：Pi Coding Agent

字段 2：Pi 官方仓库公开拆分为pi-coding-agent、pi-agent-core、pi-ai、pi-tui等包

字段 3：Coding Agent 是使用入口；Core 是 Runtime，AI 是模型适配层

这个映射也给出一条判断规则：产品名回答谁在用、解决什么任务；Harness 名回答模型怎样运行；底层模型名只回答系统调用了哪一种智能能力

四、为什么大厂现在都在补 Harness？

因为模型已经足够强，强到外围运行系统开始成为新的瓶颈

过去，模型答不出来，团队只能换模型或等待模型升级。现在很多失败发生在另外几个位置：关键信息没有进入 Context，工具返回没有被正确处理，状态在长任务里丢失，权限边界与任务不匹配，最终结果没有经过真实环境验收

大厂补 Harness，本质上是在争夺四种控制权

1. 能力兑现权：决定模型能力能发挥多少

一个会推理、会写代码的模型，进入产品后仍然需要：

• 正确理解当前任务；
• 拿到最新且相关的 Context；
• 选择合适的工具；
• 看懂工具反馈；
• 在失败后修正路径；
• 知道什么时候已经完成

这里每一项都可能损耗模型能力。Harness 的价值，就是减少这条链路上的损耗

2. 成本控制权：成本核算不能停在 Token

企业购买 Agent，不是为了购买更多 Token，而是为了完成工作

真实成本应该按一次通过验收的任务计算：

模型调用成本+ 工具与基础设施成本+ 重试和无效循环成本+ 恢复与人工接管成本+ 验证和返工成本= 每个成功任务的完整成本

便宜的模型如果反复失败，最终可能更贵。昂贵的模型如果在合适的 Harness 中用更少步骤完成任务，也可能有更低的成功任务成本