模型能力决定上限，但真正拉开 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 与任务环境组成的完整运行系统

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 查看报错日志；
2. 定位登录相关代码；
3. 找到失败条件；
4. 修改代码；
5. 运行测试；
6. 检查结果

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

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 是中间的运行控制层，通常包含七组能力：

1. Agent Loop 与调度：何时请求模型，何时执行工具，何时停止；
2. Context 管理：选择、组装、压缩、外部化、恢复每一步输入；
3. Session 与 Runtime State：保存对话树、当前运行进度、待处理消息和恢复点；
4. Tool Lifecycle：注册、描述、调用、校验、重试和返回工具结果；
5. Policy 与 Approval：权限、Sandbox、预算、超时和人工批准；
6. Durability 与 Recovery：持久化关键状态，处理中断、重放和恢复；
7. 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 中用更少步骤完成任务，也可能有更低的成功任务成本

2026 年 8 月提交到 arXiv 的论文《The Scaffolding Matters More Than the Interface: A Controlled Comparison of MCP and CLI Tool Use Across Seven Agent Scaffoldings, Five Language Models, and One Software Task》给出了一组值得重视的受控比较。研究者让 7 种 Agent Scaffolding、5 种模型执行同一个固定软件任务，并通过检查私有 Git 仓库的真实状态验证是否完成，而不是相信 Agent 的自我汇报

结果显示：

• 一个本地 27B 模型在不同 Scaffolding 下都完成了任务，但成本最多相差 139 倍；
• 13 组严格配对的 MCP 与 CLI 成本比，从 0.43 倍一直跨到 29 倍；
• 两种接口的失败频率接近，但失败造成的成本并不相同；
• 一些 Agent 没有遵守指定接口，说明不检查真实轨迹的实验会测到未知混合物

论文结论是：外围执行系统可以成为比工具接口更大的成本变量。它只有一个固定软件任务，仍是 arXiv v1。

3. 行动治理权：安全从内容审核扩展到真实操作

生成一段不准确的文字，与修改生产数据的风险不是一个等级

Agent 开始行动后，安全系统需要回答：

• 这个用户是谁？
• 这个 Agent 当前代表谁行动？
• 哪些数据可以读，哪些操作可以写？
• 哪些动作可以自动执行？
• 哪些动作必须人工批准？
• 失败后能否安全重试？
• 结果怎样审计、回滚或补偿？

这些都发生在模型外部。谁掌握 Harness，谁就掌握了 Agent 进入企业工作流的安全边界

4. 反馈数据权：掌握真正有价值的运行轨迹

只提供模型 API 的供应商，通常主要看到单次调用侧的请求与响应。掌握应用侧 Harness 的一方，还能看到更完整的任务现实：

• 模型在某个状态下看见了什么 Context；
• 它在什么 Context 下选择了哪个工具；
• 工具返回了什么；
• 用户在哪一步打断或批准；
• 哪次失败由专家修正；
• 外部环境最后是否真的达到目标

这类带业务状态、行动和最终结果的轨迹，比孤立的对话文本更适合优化 Agent。它既能用于 Prompt 和 Context 策略改进，也能用于工具设计、评测集建设、风险规则和模型选择

因此，大厂补 Harness 绝不只是补一个工具调用 Loop。它们在争夺模型能力的兑现方式、成功任务的成本结构、Agent 的行动边界，以及下一轮系统优化所需要的数据

这些控制权最终会落到六类可衡量的产品效果：

字段 1：效果

字段 2：Harness 通过什么产生

字段 1：任务成功率

字段 2：给模型正确 Context，提供合适工具，并用环境状态验收

字段 1：长任务稳定性

字段 2：持久化状态，设置停止、恢复、重试和人工介入

字段 1：成本效率

字段 2：压缩、缓存、外部化大结果，减少无效循环和失败消耗

字段 1：行动安全

字段 2：Sandbox、权限、审批、幂等和高风险动作拦截

字段 1：可调试性

字段 2：记录 Trace、事件、成本、失败点和环境变化

字段 1：产品可运营性

字段 2：将运行轨迹与业务结果连接，持续更新评测和运行策略

五、为什么各家 Harness 会这么不同？

把四套 Harness 放到同一张功能清单里，很容易陷入谁的功能更多。真正决定路线差异的，是它们替开发者承担多少运行责任，又把多少控制权留给产品团队

Harness 架构差异 = 目标任务 × 产品边界 × 控制权归属 × 风险等级 × 团队愿意承担的工程责任

变量：目标任务

它会改变什么：Coding、研究、运营任务需要不同的工具、Context、停止条件和恢复策略

变量：产品边界

它会改变什么：越靠近最终用户，默认交互、权限和状态管理通常越完整

变量：控制权归属

它会改变什么：强默认、开放接口、全插件化和最小内核，分别交换上手速度与可控程度

变量：风险等级

它会改变什么：任务后果越大，越需要最小权限、审批、幂等、补偿和独立验收

变量：团队能力

它会改变什么：自由度越高，团队承担的部署、治理、稳定性和维护责任越多

因此，选 Harness 的关键从来不是功能最多，而是决定：哪些运行责任交给框架，哪些必须留在自己的产品里

六、四条路线一次记住：用现成、嵌产品、组 Runtime、改内核

截至 2026 年 8 月，最值得横向研究的四条路线，是 Claude、Codex、DeepSeek Harness 与 Pi Agent。下面比较的是产品定位和责任边界，不是性能 Benchmark

以下 GitHub 首页均截于 2026 年 8 月 28 日。页面中的 Star、版本、提交和 Release 只代表当日快照

6.1 Claude：用

Anthropic 把 Claude Code 已经形成的运行方式开放成 Agent SDK。开发者可以直接复用同类工具、Agent Loop、Context Management、Session、Permissions 和扩展点，不必从模型 API 开始手写整套 Runtime。

Claude Agent SDK TypeScript官方主仓首页

这条路线的核心是强默认值。平台替你承担更多通用运行能力，产品团队继续负责业务 Context、自定义工具、产品界面、部署隔离和最终验收。Agent SDK 仍然运行在开发者自己的进程与基础设施中

Claude 代表“用”：少造 Runtime 的轮子，直接复用成熟运行方式

6.2 Codex：嵌

OpenAI 公开说明，Codex App、CLI 和 IDE Extension 都由同一套开源 Codex Harness 驱动。codex exec面向脚本和 CI，Codex SDK 面向应用代码，app-server 则把 Thread、Turn、Event、打断和 Approval 暴露给产品。

OpenAI Codex官方仓库首页

Codex 路线的重点是让 Agent 进入已有的专业界面和业务流程。Harness 处理 Agent Loop、会话状态、流式活动和工具交互；产品继续拥有业务对象、界面、业务 Context、MCP、回写和验收

Codex 代表“嵌”：把开源 Harness 嵌进已有产品，而不是重新做一个聊天框

6.3 DeepSeek Harness：组

DeepSeek Harness 把 Everything is a plugin 作为架构原则。Models、Tools、Skills、Sessions、Sandboxes、Storage、Loops、Scheduling 和 UI 都进入插件体系，底层 Cordis 提供 Service 与 Event 的组合机制

官方页面把四种 Agent Preset 称为 Standard、Code、Minimal、Creator；当前源码对应的 preset ID 是standard、code、minimal、cordis。

DeepSeek Harness官方仓库首页

它们展示了同一套内核怎样被重新组装。模型看到的 System Prompt、Reasoning、Tool Call、Tool Result、Subagent Scheduling 和 Context Injection，则写入 append-only Session Log，Trajectory、Resume、Fork、Search 和 Replay 都围绕这条事件流工作。DeepSeek Harness 官方页面

截至 2026 年 8 月，它仍处于 Developer Preview。可组合性越强，开发者承担的插件组装、权限政策、部署、治理和生产稳定性责任也越多

DeepSeek Harness 代表“组”：把 Runtime 拆开，再按目标任务重新组合

6.4 Pi Agent：改

Pi 把项目拆成面向用户的pi-coding-agent、负责 Loop 与 State 的pi-agent-core、负责多供应商模型适配的pi-ai，以及终端和遥测组件。它用较小的代码面换取跨模型和源码级改造能力。

Pi Agent官方仓库首页

自由度的另一面是更多工程责任。Pi 默认继承启动用户与进程的文件、网络和凭证权限，没有内置系统级隔离。更强边界需要外接容器或 Sandbox。Harness V2 正在独立开发分支中探索 Durable Run、Intent Record 和 Replay Policy，不能当作主线已经稳定上线的能力。Pi Harness V2 设计分支

Pi Agent 代表“改”：从最小内核出发，直接理解和修改运行逻辑

6.5 一张表记住四家的责任边界

路线：Claude

记忆词：用

平台主要替你承担：强默认的工具、Loop、Context、Session、Permission Mode 与审批控制

开发者继续承担：业务授权、Context、界面、自定义工具、进程或容器隔离、部署与验收

更适合：希望少做 Runtime、快速交付产品

路线：Codex

记忆词：嵌

平台主要替你承担：开源 Harness、跨轮状态、事件、工具、Sandbox 与 Approval 集成面

开发者继续承担：业务对象、专业界面、MCP、回写与验收

更适合：已有产品，希望把 Agent 嵌进去

路线：DeepSeek Harness

记忆词：组

平台主要替你承担：插件内核、Agent Preset、Session Log 与组件接口

开发者继续承担：插件组装、权限政策、部署、稳定性与业务能力

更适合：希望重组整套 Runtime

路线：Pi Agent

记忆词：改

平台主要替你承担：轻量 Loop、State、Events、多模型适配与 Coding Agent 入口

开发者继续承担：隔离、审批、业务 Context、产品化与生产治理

更适合：想理解并直接修改最小内核

Claude 用现成，Codex 嵌产品，DeepSeek 组 Runtime，Pi 改内核

这不是性能排行。它比较的是四家分别替开发者做了哪些决定，又把哪些工程后果留给了使用者

七、独立开发者和 AI 产品经理应该怎样选？

不存在脱离场景的最佳 Harness。选型目标是用最低的系统复杂度，满足任务对效果、成本和风险的要求

7.1 独立开发者先判断自己在做哪一层

场景一：只是验证用户是否需要这个 Agent

优先使用 Claude Code、Codex CLI、Pi Coding Agent 等已经可以直接工作的产品，不要一开始就重写 Runtime

这个阶段最重要的是验证：用户会不会把任务交给 Agent，结果是否有价值，失败在哪里，愿不愿意再次使用

场景二：需要把 Agent 嵌入自己的产品

如果你的优势在产品界面、业务流程和用户入口，可以选择 Claude Agent SDK、Codex SDK 或 app-server，把成熟运行能力接入自己的应用

此时要重点评估：

• 能否传入产品当前页面和业务对象作为 Context；
• 是否有流式事件、打断、恢复和审批接口；
• 工具调用怎样映射到你的后端；
• 运行状态怎样回到系统记录；
• 最终结果由谁验证

场景三：需要跨模型并深度修改 Runtime

Pi 更适合轻量、多模型和源码级改造。DeepSeek Harness 更适合替换和组合大量运行组件

两者都意味着你需要承担更多工程责任。选择前要确认团队是否真的需要这种自由度，以及是否有能力维护权限、部署、追踪、评测和版本升级

场景四：要让 Agent 进入生产系统并执行高风险动作

任何通用 Harness 都只解决一部分问题。你还需要在应用层增加：

• 业务状态机；
• 最小权限与审批；
• 幂等键、对账和补偿；
• 人工接管；
• 专业验收；
• 审计和合规记录

框架可以缩短起步时间，不能替你承担业务后果

7.2 AI 产品经理的新增交付物：Agent Runtime Spec

Harness 不是工程团队独自决定的底层实现。它直接决定用户可以把什么任务交给 Agent，系统怎样行动，哪里必须等待人工，以及什么证据才代表真正完成

所以，只写模型、Prompt、功能入口和输出样式的 AI PRD 已经不够

AI 产品经理需要补一份 Agent Runtime Spec，把 Context、工具、状态、权限、失败、预算、验证和评测写成一套完整运行契约。它至少回答：

字段 1：规格项

字段 2：产品必须回答的问题

字段 1：任务目标

字段 2：用户真正委托什么，什么结果才算完成？

字段 1：Context

字段 2：每个状态需要哪些信息，来源、版本和权限是什么？

字段 1：工具

字段 2：可以调用什么，触发条件、参数、返回和副作用是什么？

字段 1：状态

字段 2：任务有哪些阶段，如何进入、退出、暂停和恢复？

字段 1：权限

字段 2：哪些动作自动执行，哪些需要批准，批准人是谁？

字段 1：失败

字段 2：哪些错误可重试，哪些需要对账、补偿或转人工？

字段 1：预算

字段 2：最大轮次、Token、运行时间、工具成本和并发是多少？

字段 1：验证

字段 2：谁用什么证据确认完成，Agent 自我汇报是否有效？

字段 1：可观测

字段 2：需要记录哪些 Context、Event、Tool Call、成本和结果？

字段 1：评测

字段 2：用哪些真实任务集做上线前回归和上线后监控？

下面给一个填写后的设备故障诊断示例。它不是某家框架的功能清单，而是产品团队应该拥有的运行规格

字段 1：规格项

字段 2：设备故障诊断 Agent 示例

字段 1：任务目标

字段 2：基于指定设备的实时状态与历史记录，定位无法启动的候选原因，给出可执行检查方案，并形成工程师可验收的处理记录

字段 1：初始 Context

字段 2：设备 ID、型号、配置版本、当前告警、工单描述、操作人身份

字段 1：追加 Context

字段 2：实时传感器、近期维修历史、同型号故障案例、最新检查结果、专家备注

字段 1：工具

字段 2：读取监控、查询维修记录、检索手册、执行只读诊断、创建或更新工单

字段 1：状态

字段 2：待诊断 → 证据收集 → 假设排序 → 待批准检查 → 结果验证 → 已解决或转人工

字段 1：权限

字段 2：读取自动执行；可能影响设备状态的命令需要工程师批准；Agent 不直接执行停机或复位

字段 1：失败

字段 2：查询类工具有限重试；控制类调用结果不确定时停止自动流程，进入对账或人工确认

字段 1：预算

字段 2：限制最大检查轮次、最长运行时间和外部调用成本；超限时返回已收集证据与未完成项

字段 1：验证

字段 2：候选原因必须绑定证据；检查步骤必须可复现；关闭工单前需要健康检查结果与工程师确认

字段 1：Trace

字段 2：保存关键 Context 版本、工具参数与结果、批准记录、状态变化、最终原因和专家修正

这张表的意义在于，它会逼迫产品团队从能不能调用模型，转向完整任务如何运行

八、Harness 代码很难成为壁垒，真正难复制的是垂直运行资产

通用 Harness 的代码会越来越开放，也会越来越同质化

Agent Loop、工具注册、Session、Context Compaction、Sandbox、Approval、Event Stream、Trace，这些能力会持续进入开源框架、云服务和标准组件。竞争对手可以阅读代码、复刻机制，企业也可以更换供应商

所以我不认为一套通用 Harness 仓库本身能长期构成产品壁垒

真正难复制的是团队围绕垂直任务长期积累的运行资产。它们决定系统在每个业务状态下怎样理解现实、采取行动并证明结果

我认为，这套资产的核心就是 Context

8.1 Context 不是一堆资料，它是当前任务现实

很多团队把 Context 理解成聊天记录、RAG 片段或长期记忆。这些都只是原材料

Context 是模型在某个业务状态下，完成下一步决策所需要的任务现实

我说所有工程最终服务于 Context，不等于把所有工程细节都塞进上下文窗口

状态机决定哪些事实属于当前状态。权限和 Sandbox 决定哪些行动能够被系统实际执行。恢复机制负责重建中断后的任务现实。验收器把环境结果翻译成继续、完成或转人工的反馈

这些机制运行在模型外部，但它们对下一步决策的影响，最终都会进入三类 Context：

Context 类型：事实 Context

包含什么：目标、业务状态、证据、历史动作

对应的运行工程：Business State、Runtime State、Memory、RAG、Session、Compaction、Recovery

Context 类型：行动 Context

包含什么：可用工具、权限、预算、风险和批准状态

对应的运行工程：Tool、Policy、Sandbox、Approval

Context 类型：反馈 Context

包含什么：工具结果、错误、验证结果和专家修正

对应的运行工程：Tool Result、Error Normalization、Runtime Verifier、Human Feedback

Trace 和离线 Evals 不一定进入当前这次运行。它们消费运行轨迹，帮助团队更新下一版 Context 策略、工具契约和验证规则，构成系统持续优化的闭环

Harness 的工程价值，就是持续生产、约束和更新这份任务现实

上面的三类 Context，是按它对当前决策的作用划分。按具体内容展开，一份任务 Context 通常由九类信息动态组装：

1. 当前目标与完成标准；
2. 用户身份、角色和意图；
3. 当前业务对象；
4. 实时业务状态；
5. 已经执行的动作与结果；
6. 可用工具、参数、限制和副作用；
7. 权限、预算与风险约束；
8. 外部证据和专业知识；
9. 当前阶段的验证标准

Memory 保存候选信息，RAG 负责检索，Business State 描述业务现实，Runtime State 记录执行位置，Tool 提供行动与反馈，Harness 在正确时间把它们投影成模型可用的 Context

大模型真正稀缺的不是信息总量，而是在某个业务状态下，拿到恰好足够、可执行、可验证的 Context

8.2 垂直运行资产包括什么？

第一类是业务对象与状态模型

系统必须知道设备、订单、工单、用户、合同等对象分别有哪些状态，哪些状态可以转换，哪些事实必须保持一致。这些知识通常分散在产品规则、数据库字段、人工经验和组织流程中

第二类是Context 投影规则

同一份业务数据，不应该在每一步全部进入模型。团队要长期积累：在什么状态下必须出现哪些字段，哪些历史应该摘要，哪些原文必须保留，哪些冲突需要显式提示

第三类是工具语义与风险资产

真正有价值的工具定义不仅有名称和参数，还包含触发条件、前置状态、业务后果、权限等级、常见失败、是否可重试，以及执行后如何验证

第四类是权限、恢复与人工协作规则

哪些动作能自动执行，哪类不确定性必须暂停，谁来批准，失败后怎样对账，何时把任务连同证据交给专家。这些规则来自真实事故和运营经验

第五类是验证与评测资产

Agent 说完成没有意义。代码是否通过测试，设备告警是否消失，订单状态是否正确，客户问题是否解决，才是环境层的验收。团队需要把这些结果变成可重复的评测集和在线指标

第六类是带结果的运行轨迹

最有价值的轨迹不只是模型说过什么，而是某个业务状态、某份 Context、某次工具调用、某个专家修正，最终对应了什么结果

这些资产会形成一个持续增强的闭环：

真实任务运行 ↓收集 Context、动作、失败与业务结果 ↓区分模型问题、Context 问题、工具问题和策略问题 ↓更新 Context 投影、工具契约、权限与验证 ↓系统兑现率提高 ↓承接更多高价值任务

这才是难复制的部分。开源代码可以 Fork，业务语义、结果数据、专家修正和组织协作无法从仓库里下载

8.3 从登录 Bug 切到设备诊断，就能看见垂直壁垒

前文一直用登录 Bug 解释通用 Harness。现在切换到设备诊断，看看 Context 如何随着业务状态变化

状态一：识别设备

模型需要设备 ID、型号、配置版本、客户现场和当前工单。此时大量维修手册还不必进入 Context

状态二：判断故障

Context 增加实时告警、关键传感器、近期变更、维修历史和同型号案例。系统需要把时间和版本对齐，避免拿旧配置解释新故障

状态三：执行检查

Context 增加诊断工具的输入要求、操作前提、潜在影响、当前权限和批准状态。模型此时需要知道的不只是怎样检查，也包括哪些动作不能做

状态四：准备修复

Context 转向候选原因、证据强度、修复方案、停机影响、备件情况和批准人。不同风险等级进入不同 Workflow

状态五：验证结果

Context 再次变化，重点变成告警前后对比、健康检查、关键指标、观察窗口和验收标准。过去的检索噪声可以退出工作上下文

状态六：沉淀经验

系统把最终原因、有效步骤、失败尝试、工程师修正和业务结果写回知识与评测体系，为下一次任务提供更好的 Context

同样的模型和通用 Harness，拿不到这套动态业务 Context，也很难稳定完成设备诊断。这就是垂直运行资产的含义。

8.4 哪些场景最容易形成垂直运行壁垒？

通常同时满足五个条件：

• 任务重复发生，并且每次都有真实业务价值；
• 任务依赖私有、实时、结构复杂的业务状态；
• 结果可以被环境或专家验证；
• 错误有成本，因此权限和恢复规则重要；
• 专家修正能够被记录并回流到系统

工业运维、软件工程、风控、客服运营、供应链和企业流程，往往具备这些条件

轻量消费产品未必如此。如果任务低频、后果很小、结果难验证，长期壁垒可能仍然来自分发、品牌、内容和用户体验。不能因为 Harness 重要，就把所有产品竞争都解释成 Runtime 竞争

8.5 垂直 Harness 能降低模型依赖，但不能消除模型耦合

当 Context、工具、权限和验证掌握在产品手里，团队更容易替换模型，也能针对任务做模型路由

但切换不会是零成本。模型可能已经在特定 Tool Schema、Prompt 结构和 Harness 行为上形成习惯。Armin Ronacher 记录过一个值得警惕的现象：较新的 Claude 模型在 Pi 的edit工具上生成额外字段，反而比旧模型更容易触发 Schema 校验失败。他把后训练与原生 Harness 的耦合作为一种解释假设，而不是已经证明的事实。Better Models: Worse Tools

因此，每次模型切换都必须在真实任务、真实工具和真实 Context 上做回归测试。模型选型测试的对象应该写成：

模型+ System Prompt 与 Context 策略+ Tool Schema 与错误反馈+ 权限、恢复与停止条件+ 任务环境与验收器= 完整 Agent 系统

九、模型是上限，Harness 是兑现，Context 是资产

模型竞争不会结束。更强的推理、更长的上下文和更好的工具调用，仍然会不断抬高 Agent 的能力上限

回到最开始的登录 Bug。真正拉开差距的，不是谁更会解释报错，而是谁能拿到正确的仓库状态，安全地修改，失败后继续，并用测试和 PR 证明任务真的完成

但用户购买的是完成工作的系统

Harness 决定模型每一步看见什么、可以做什么、怎样继续、何时停止、失败后怎样恢复，以及凭什么证明完成

通用 Harness 会越来越开放。真正难复制的，是一支团队能否在每一个业务状态下，持续为模型提供恰好足够、可执行、可验证的 Context

模型是能力上限，Harness 是兑现系统，Context 是长期资产