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 为什么把 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 工具，涉及生产数据写入时，再把决定交给工作人员。
20 分钟做出一个 Agent：
Harness 开源到底降低了什么门槛？
图：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 不再稀缺，竞争优势会转移到哪里？
