8 月 19 日，OpenAI 正式开源了 Codex Harness。这家公司名字里的 Open，久违地兑现了一次。（雷峰网(公众号：雷峰网)）
长期深耕 Agent Harness 的开发者群体对该消息的普遍反馈是“振奋”。因为过去只有少数顶尖 Agent 产品掌握的 Harness，现在终于开始向更多开发者和企业开放了。
随着 Codex 等最佳实践的开源，Harness 正在经历从“私产”到“公器”的转化，其本身的稀缺性，正在快速下降。这也是 OpenAI 为什么终于“Open”了一回的重要原因。
当顶尖 Agent 产品积累的 Harness 方法论不断扩散，Codex 这样的最佳实践也正式开源，开发者便可以站在现成的 Agent Runtime 上继续开发。过去许多公司依靠 Harness Engineering 建立起来的技术领先，也会更快被行业学习和复制。
那究竟什么是 Harness？
对于不太熟悉这个领域的朋友，可以用一个极简公式来理解这个概念：
Agent = Model + Harness
如果说模型是输出原始推力的“发动机”，那么 Harness 就是将这种不确定推力转化为确定性输出的“传动系统”和“调压站”，负责把智能组织成可以持续完成交付任务的系统，其中包括管理模型的上下文、调用工具、保存状态、控制权限，也要在任务失败后继续推进。
在Chatbot时代，模型原本只能一轮一轮地回复，顶多起到一个解答问题，提供情绪价值的作用。但是在经过 Harness 的组织后，我们才能开始利用模型的智能去实际交付产出。
Harness 的核心价值不再是智能，而是“治理”。当我们评价一个 Agent 能力时，只看模型是不够的，同一个模型放进不同套 Harness，最终表现可能相差很大。
从去年 Claude Code，再到今年爆火的 Codex，已经有许多 Agent 产品证明了一套优秀的 Harness 系统加上顶级模型是能够释放巨大的商业潜力。
现在，开发者每月排着队为这类产品支付几十甚至几百美元，而付费用户也不再局限于开发者，越来越多的白领、知识工作者和企业主开始为 Agent 产品买单。
市场中已经出现了极端的商业案例：有小企业主为某款 Agent 产品支付了单周近 10 万元的费用。他们之所以愿意支付这么高的费用，是因为这项Agent切实帮助他获得了远超成本的收入。
刚刚是从收益角度衡量Harness的机制，从成本测出发，一套更设计的 Harness 还可能在任务质量接近的情况下，降低 Token 消耗，改善投入产出比。最近，Databricks 最近在自己的数百万行代码库上做了一次内部测试(https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase)。
测试任务来自公司内工程师真实完成过的工作，覆盖 Python、Go、TypeScript 和 Scala 等语言，比常见的公开 Benchmark 更接近大型公司的日常开发流程。
其中一组实验直观展示了 Harness 对成本的影响。Databricks 在相同模型、相同推理强度下，分别用 Claude Code、Codex 和更轻量的 Pi 三种 Harness 完成同一任务。结果显示，三者完成质量接近，但单任务成本最高相差两倍以上。原因在于 Pi 每轮送入模型的上下文量约为 Claude Code 或 Codex 的三分之一，所需轮次也更少。
这些产品与测试都说明，Harness 会直接影响 Agent 的体验、成本和商业价值。按常理，这样的技术理应成为公司的最核心资产，并且对外严防死守。但是，在过去两周发生的事情却恰好相反，顶尖模型厂商开始主动开源自己的 Harness。
八月中旬，DeepSeek 率先开放 DeepSeek Harness；不到一周，OpenAI 也开放了支撑 Codex App、CLI 和 IDE Extension 的 Agent Harness。
比如，Cisco 将 Codex 引入复杂的企业工程环境。Thrive Holdings 则与 OpenAI 合作，把 Codex 应用到税务工作流中，参与处理了 7000 份报税材料，覆盖 30 多家会计师事务所，帮助从业者将准备的工作时间缩短了约三分之一。
同一套 Agent 执行能力，已经开始进入代码托管平台、IDE、企业工程环境和专业服务流程。对于仍在从头搭建通用 Agent Harness 的创业公司，这会直接改变竞争的格局。
Codex 负责人 Tibo 的态度更耐人寻味。他甚至判断，再过两三个月，今天这套Codex Harness 也会显得原始。
图：Tibo 演示把 GPT-5.6 Sol
接入 Claude Code Harness。
Tibo 判断今天的 Codex Harness 会在两三个月后显得原始
以上一系列信号指向一个问题：
技术领先，能成为一家公司的护城河吗？
为了评估 Codex Harness 的真实价值，需要从“功能解剖”与“实战演练”两个维度切入：
先搞清楚 OpenAI 这次Codex Harness 开源到底开放了什么？
再用这套开源 Harness 实际做一个真实产品demo。
只有通过深度的实战测评，才能更具体地理解 OpenAI 为什么选择在这个时间点开源 Codex Harness，以及它想通过这次开源完成怎样的战略转换。
OpenAI 在官方文章里用一句话概括了这次开放的核心：
The reusable part is the agent loop.
这句话也划清了本次开源的边界。OpenAI 开放的是 Codex 用来持续执行任务的 Agent Loop，也就是支撑 Codex App、CLI 和 IDE Extension 运行的那一层 Harness。
开发者现在可以查看它的实现，也可以通过 SDK 和 App Server，把任务管理、工具调用、事件回传和人工审批等能力接进自己的产品。Codex 使用的模型仍然由 OpenAI 提供，背后的云端服务也没有随代码仓库一起开放。开发者拿到的是模型之外那套可以重复使用的 Agent Runtime。
技术拆解显示，在众多的接入入口中，其中最值得关注的是 Codex App Server。
你可以把 App Server 理解成 Codex 与外部产品之间的连接层。过去，用户主要在 Codex 自己的界面里发起任务；现在，开发者可以把同样的执行能力接进自己的产品：启动任务、让 Codex 持续执行、接收输出和工具调用，也可以在中途暂停，等待用户确认后继续。
在 App Server 里，一项持续进行的任务叫 Thread，其中每一轮具体执行叫 Turn。比如，“审核完这篇文章并生成修改稿” 可以放在同一条 Thread 里：第一轮 Turn 只读检查文章，用户确认以后，下一轮 Turn 再生成修改稿。
对开发者来说，他们再也不必把业务流程迁进一个通用聊天窗口。团队可以保留已有的控制台、编辑器、任务队列和审批流程，再决定 Agent 能读取哪些数据、调用哪些工具、在哪里运行，以及什么操作必须经过人工确认。
OpenAI 官方展示的物流控制台 Relay，就是开源 Harness 如何进入现有业务系统的一个具体案例。工作人员面对的仍然是熟悉的订单、运输状态和异常处理按钮。Codex 在后台分析问题并调用应用提供的 MCP 工具，涉及生产数据写入时，再把决定交给工作人员。
图：OpenAI Codex 的公开仓库。Codex CLI、核心 Runtime、SDK 和文档都在同一个项目中持续维护。
随着 Codex Harness 的开源，一个行业核心假设亟待验证：开发者能否直接利用这套 Harness，从一项真实的业务需求出发，快速做出一个可以交给用户使用的 Agent 产品？
实验选择从一个长期困扰自己的需求开始，做一套文章审核工作台。
在内容生产的典型场景中，Agent 承担着核对事实、纠正技术定义及区分立场等高频需求。在实测中，通过加载定制化的审核 Skill，这一流程在 Codex 体系下表现得非常丝滑顺手。
可一旦想把这项能力交给其他内容创作者，事情就麻烦了。大部分用户不想研究 Prompt，也不了解 Skill 和底层接口。大部分用户需要的是一套简单操作流程，选中一篇文章，点击开始审核，看见系统正在做什么，读完审核结论，再决定是否生成修改稿。
过去要做这样一款产品，团队通常需要先用 LangGraph、Agno 或 Pi 等框架搭建 Agent 的运行系统。模型怎样读取长文，什么时候调用搜索和本地工具，多轮任务怎样保持状态，执行过程如何回传前端，文件写入如何等待审批，任务中断后怎样继续 —— 这些通用能力都需要逐项实现、调试和优化。等到整套系统稳定下来，产研团队才有精力处理真正影响业务价值的问题。
依托开源的 Codex Harness，开发者的重心得以发生根本性偏移：从繁琐的底层工程重构，转向对产品核心价值（如审核标准、交互边界）的定义。
以下是验证该逻辑的产品需求 Prompt 范例：
基于https://github.com/openai/codex Codex App Server构建一个面向内容创作者的文章审核台。用户可以选择一篇待发布文章，启动 AI 审核，并看到完整的执行轨迹。第一轮审核必须保持只读。界面需要展示当前任务状态、审核结论、工具调用与执行事件、文件修改数量，以及写入前的人工审批按钮。只有用户明确批准以后，Codex 才能另存一份修改稿，不能覆盖原文。
图：这次构建从产品需求开始，描述了目标用户、核心流程、需要展示的信息和写入权限，没有重新设计一套 Agent Loop。
Codex Harness 已经解决了任务怎样持续执行、工具怎样被调用、权限怎样被控制这些通用问题，剩下真正需要开发者设计的，反而都是更靠近业务的部分。
比如，Codex 底层会产生大量命令、搜索和文件事件，但普通创作者不需要理解这些东西。更重要的是，在实际场景中，开发者还需要告诉 Codex，什么才算真正审核好一篇文章。这部分工作的难度和工作量不亚于开发一套稳定的 Harness，但它对最终产品价值的贡献更加直接。开源的 Codex Harness 省掉了重复搭建通用执行系统的时间。开发者可以把省下来的精力直接用于打磨审核标准、信息呈现和权限边界 —— 这些才是真正决定产品价值的部分。
不到 20 分钟，这个文章审核工作台 Demo 就端到端跑通了。
最终 Demo 的页面很简单，包括文章路径、“开始审核”按钮、审核结论，以及一条展示执行过程的事件流。页面通过本地 WebSocket 代理连接 codex app-server。用户点击“开始审核”后，系统启动第一轮 Turn，只读取文章和资料，不修改任何文件。
实测反馈显示，即便是不具备 Prompt 经验的非技术人员，也能在无需指导的情况下完成任务。这证明了 Harness 开源的核心价值：将 AI 能力从“专家级配置”降维为“普通用户交互”。
开发者不再需要从零构建复杂的 Agent 循环，只需在成熟的执行层之上叠加一层面向场景的应用界面。
审核完成以后，真正写入文件以前，产品把决定交还给用户
这会给新一批 Agent 创业公司和企业内部开发者带来很大的价值。创业公司可以用更低的工程成本验证垂直场景，企业开发者也能更快地把 Agent 接进客服、财务、法务、内容和研发等现有流程。现在，他们不需要推翻原来的产品和业务边界，只需要接入 Codex 的任务执行能力，再根据具体场景设计它的工作方式。
但门槛降低从来都有两面。当越来越多开发者可以直接使用一套成熟的 Harness，原本需要长期积累的工程能力，也会迅速变成一种随手可得的基础设施。
回头文章开头的问题，如果 Harness 不再稀缺，竞争优势会转移到哪里？
过去一年大模型行业已经反复证明，模型能力的领先窗口非常短。新的模型发布以后，Benchmark 会被刷新，推理成本会下降，蒸馏、合成数据和训练方法会迅速扩散，原本只有头部闭源模型才能完成的任务，会逐渐进入更便宜的模型，甚至进入开放权重模型的能力射程范围。
今天，Claude 模型在 Coding 和 Agent 场景里依然处于最强梯队，但领先本身并不等于长期壁垒。Kimi、GLM、DeepSeek 等厂商都在持续追赶，并且开源模型权重。虽然，和 Anthropic SOTA 级别的模型之间当然还存在差距。判断这项领先是否具备长期价值，还要看差距能够维持多久，以及竞争者需要付出多大成本才能追上。
最近的模型竞争里，能力与成本之间的关系越来越重要。当模型能力接近以后，谁能用更低的推理成本和更高的效率，把相近的能力交付给更多用户，就会获得更大的市场空间。
现在来看，Harness 也在经历同样的价值稀释过程。
一年前，一套优秀的 Agent Harness 还需要大量内部工程经验及和烧过大量的TOKEN才能总结沉淀下来。今天，OpenAI 已经可以把其中的通用能力直接开放给开发者。模型也一样，今天只有顶尖模型才能完成的任务，可能在下一代模型发布后迅速变成标准能力。
但如果 Anthropic 能利用这段技术领先所争取到的时间窗口，赢得更多开发者的认可，让 Claude Code 进入越来越多大型组织的研发流程，企业也开始围绕 Claude 建立权限、数据、评估体系和使用习惯，甚至参与制定行业规范，并进一步影响有利于自身发展的政策，那么情况就大大不同了。这些优势虽然形成得更慢，却更难被竞争者在下一次模型发布时一并“蒸馏”。
讨论到这里，技术领先的价值已经不用赘述了。对于企业更难回答的问题是，一家公司怎样把阶段性的技术领先，变成竞争者长期难以复制的优势。
在投资领域，人们通常用 “护城河” 描述这种能够长期抵挡竞争的能力。要判断技术领先能不能变成长期优势，可以借用 Hamilton Helmer的7 Powers 框架。Helmer 给出的判断标准其实很简单：一项优势必须同时具有Benefit和Barrier。
7 Powers 是投资人、战略学者 Hamilton Helmer 提出的一套竞争战略框架，整套理论试图回答一个问题：
面对同样聪明、行动迅速，而且全力竞争的对手，一家公司为什么还能长期获得显著的超额回报？
Hamilton Helmer 的《7 Powers》
Helmer 把支撑这种结果的竞争结构称为 Power，也可以理解为能够长期存在的护城河。一项优势能被最后认定为 Power，必须同时通过两项检验：
Benefit，收益。它确实能让公司多赚钱，比如提高价格、降低成本、加快增长，或者让客户留得更久。
Barrier，壁垒。对手即使知道你在做什么，也很难复制；或者复制时需要付出高昂代价。
能创造收益却容易复制，领先会随着竞争者追上而消失。难以复制却不能改善经济结果，守住它也没有太大意义。Benefit 和 Barrier 同时成立，优势才有机会变成 Power。
Helmer 在书中总结了七种反复出现的 Power：
这七种 Power 的来源不同，判断标准却一致，都必须同时具备 Benefit 和 Barrier。
用这套标准回看本文的问题，技术领先本身算不算一种 Power？
在 AI 行业里，几个月的领先就足以改变竞争格局。模型效果更好，可以更早吸引开发者和企业客户；Harness 更成熟，也可以让模型承担更长、更复杂的任务。从 Benefit 看，技术领先的带来的价值是巨大的。
可问题在于，Benefit 只是 Power 的一个条件。
如果这种领先会随着模型迭代、人才流动和工程经验扩散被竞争者快速追上，那么它带来的收益虽然真实，却未必拥有足够强的 Barrier。
这种领先更应被视为一种阶段性红利，也是一股势能。但这种势能会衰减——论文会传播，人才会流动，工程实现会被复刻，代码也可能被主动开源。
真正重要的是，公司能不能利用这段领先窗口，把暂时的技术优势进一步沉淀成更难复制的 Power。
技术领先只有完成这一步转换，才真正开始具有护城河的意义。
伟大的科技公司往往同时运行两个循环：一边把上一轮技术领先沉淀成 Power，一边继续创造下一轮技术领先。前者提供长期优势，后者不断创造新的时间窗口，而已经形成的 Power 又反过来为下一轮研发提供资金、数据、人才和应用场景。
有了这套判断标准，再看 Codex Harness 开源，如果暂时技术领先只提供了一段势能，OpenAI 接下来真正需要证明的就是这段势能能否继续沉淀为更持久的 Power。
OpenAI 开源 Codex Harness，直接降低了 Harness 实现本身的稀缺性。
前文提到的 Databricks 测试已经说明，外部团队可以使用更轻量的 Harness，在部分任务上以更低成本达到接近的完成质量。竞争者并不需要 1:1 复刻 Codex。只要在特定任务里做到质量接近、成本更低，就足以削弱 Codex Harness 的技术稀缺性。
但开源也让 Codex 获得了更大的分发范围。
在前面的实测里，几乎没有重新实现 Agent 的执行系统。Codex App Server 已经提供了 Thread、Turn、工具调用、事件回传和人工审批等基础能力。只需要通过 WebSocket 接收执行事件，再围绕文章审核设计界面、审核标准和权限边界，不到 20 分钟就跑通了一个可以交给普通用户试用的产品。
这件事对开发者的直接价值是降低构建 Agent 产品的工程门槛。对 OpenAI 来说，价值则在于让 Codex 从一个面向最终用户的产品，进一步变成其他产品可以复用的执行层。
按照 7 Powers 的标准，OpenAI 接下来需要证明两件事：这种开放能够带来什么 Benefit，以及它能否进一步形成竞争者难以复制的 Barrier。
首先是转换成本。
在 Demo 里，接入 Codex Harness 还很轻，只需要处理文章路径、事件流和写入审批。但放进真实企业以后，接入对象会复杂得多。Agent 需要连接企业的代码库、内部工具、权限体系、评估集、部署环境和审批流程。团队还要决定什么数据可以读取，哪些操作必须经过人工确认，任务失败后怎样恢复，以及执行结果如何进入原来的业务系统。
这些工作最终会沉淀为一套围绕 Codex 建立的配置、评估标准、历史任务和组织流程。
当企业更换底层 Harness 时，需要迁移的就不只是一套代码接口，还包括已经运行在上面的工作方式。Codex Harness 接入得越深，更换系统的成本就越高。开源降低了第一次接入的门槛，深入使用则可能逐渐形成转换成本。
第二层是规模经济。
Codex Harness 虽然开放，但它和底层模型之间仍然存在大量协同。模型怎样理解工具描述、怎样压缩上下文、什么时候继续执行、什么时候请求审批，都需要 Harness 与模型共同优化。
我在 Demo 中看到的 Thread、Turn 和事件流，表面上是产品接口，背后每一次审核、搜索和工具调用都会产生模型推理需求。当更多开发者直接基于 Codex App Server 构建产品，OpenAI 获得的也不只有更多 Harness 用户，还可能包括更多模型调用和更丰富的真实任务。
如果规模扩大能够提高推理基础设施的利用率，并帮助 OpenAI 持续优化模型与 Harness 的配合方式，开放 Harness 就可能进一步形成模型层面的规模经济。当然，这条链路能否成立，最终仍然要看新增调用能否真正转化为更低的单位成本。
第三层是独占资源。
前面的文章审核 Demo 会产生一条完整的任务轨迹：Codex 读取了什么资料，调用了哪些工具，在哪一步请求人工审批，用户是否接受审核结论，以及修改稿最后有没有被采用。
类似的轨迹如果出现在代码、财务、法务和客服等专业场景中，其中会包含大量公开语料里很少出现的信息：任务为什么失败，专家怎样纠正，什么结果可以被业务接受，以及人在什么节点选择接管 Agent。
在合规和用户授权的前提下，如果这些反馈能够进入 OpenAI 的评估和模型优化体系，它们就可能成为公开语料与合成数据之外的一类稀缺资源。外部竞争者即使拿到同样的 Harness 代码，也很难立刻获得相同规模和质量的真实任务反馈。
转换成本、规模经济和独占资源都不会因为开源自然而然地出现。开源 Codex Harness 完成的第一步，是让更多开发者能够低成本地把 Codex 接入自己的产品。OpenAI 还需要让这些产品进入真实业务、产生持续使用，并把新增使用沉淀为客户流程、模型规模和高质量反馈。
如果这条路径能够跑通，OpenAI 放弃的是正在快速扩散的 Harness 稀缺性，获得的则可能是更广的分发，以及更难被下一轮技术迭代抹平的 Power。
所以，再回答本文最初的问题：
技术领先当然重要，但其本身还不足以构成护城河。
技术领先更像一种势能，为公司争取用户、收入、数据和时间窗口。真正决定长期竞争力的，是企业能否在这段领先消失以前，把这些红利沉淀成竞争者难以复制的 Power。
技术会扩散，代码会开源，模型会被追上。
真正的护城河，不是你曾经领先过，而是领先消失以后，你还剩下什么。
2026-09-05
2026-08-28
正在生成分享图...
张嘉敏