一、Harness：被低估的能力放大器
最近，两篇关于Agent Harness的文章几乎同时出现。一篇来自Earendil，以科普的口吻解释Harness是什么；另一篇来自OpenAI，宣布Codex正式升级为Agent平台。乍看两者毫无关联，实际上它们都在回答同一个问题：当模型能力逐渐商品化，Agent真正的控制层应该放在哪里？
过去一年，人们习惯把Agent的表现归功于模型本身。任务完成得好，就说模型聪明；任务搞砸了，就说模型不行。但只要同时用过Claude Code、Codex、Pi、OpenCode等不同Coding Agent，就会发现事情没那么简单。同一个模型放进不同的Agent，表现可能天差地别。Earendil将Harness拆解为四个部分：系统提示词（System Prompt）定义模型的身份和行为边界；工具（Tools）让模型能够读写文件、搜索网页、运行命令；Agent循环（Agentic Loop）驱动模型调用工具、检查结果、持续行动直到任务完成；翻译层（Translation Layer）则负责把不同模型的接口和消息格式统一起来。OpenAI的定义本质上没有区别，只是更偏向工程实现——Codex Harness负责维护会话状态、管理上下文、调用工具、流式返回进度、处理失败、执行沙箱策略、发起人工审批，并让任务跨多个回合继续运行。
OpenAI在文章中给出了一个极具说服力的数据：在ARC-AGI-3测试中，仅仅加入保留推理和上下文压缩等Harness机制，GPT-5.6 Sol的得分就从13.3%提升到38.3%，输出Token同时减少到原来的六分之一。模型没有换，结果却接近三倍。这说明Agent的能力不只存在于模型权重里，上下文怎样保存、工具怎样暴露、循环怎样收敛，都会直接改变效果和成本。Harness不是可有可无的包装，而是决定Agent上限的关键组件。
二、OpenAI的野心：把Codex变成基础设施
大多数用户接触Codex，是通过桌面App、CLI或IDE插件。OpenAI这次想说的是：这些只是Codex Harness的几个官方界面。开发者现在可以把同一套Agent能力放进自己的产品，而不必要求用户离开原来的工作台，打开一个通用聊天框。OpenAI给出了三层入口，其中最值得关注的是app-server。它通过一套有文档的JSON-RPC协议暴露Codex内部能力，应用可以创建Thread、启动Turn、接收工具执行和文件修改事件、暂停任务，也可以在高风险操作发生前弹出自己的审批界面。
这意味着开发者不必再做“套壳Codex”。安全团队可以把Agent放进告警调查台；客服团队可以把它放进客户记录和日志旁边；物流团队可以让它查看异常订单，比较补救方案，并在改签之前等待人工批准。OpenAI的示例Relay就是一个物流操作台——用户不需要从空白输入框开始描述问题，只要选中一票延误货物，点击“比较恢复方案”。应用负责提供订单、业务规则和可调用的MCP工具，Codex负责调查、推理和执行循环。OpenAI对双方边界划得很清楚：应用拥有界面、业务上下文、数据、工具和审批规则；Codex Harness负责会话状态、Agent Loop、工具编排和沙箱执行。
这是一条典型的平台路线。OpenAI不再要求所有工作都迁入Codex，而是让Codex进入已有的软件。对开发者来说，这确实省去了从零搭建Agent Loop的麻烦，可以直接调用经过验证的底盘。但这也意味着，应用的Agent能力被绑定在Codex的协议和托管服务上。
三、Pi的立场：用户必须保留退出权
Earendil的文章没有讨论SDK的易用性，也没有展示企业控制台。它更关心Harness最后属于谁。模型通常由大公司训练，普通用户不可能真正拥有。但Harness可以运行在自己的电脑上，系统提示词可以修改，工具可以增减，会话记录可以保存在本地，背后的模型也可以替换。这正是Pi的设计方向：默认保持一个很薄的核心，用户再按自己的工作方式添加扩展。有人改变提示词，有人增加新工具，有人把它接进特定工作流。Earendil在文章中透露，Pi用户已经共享了超过5000个扩展。
这里的模型翻译层不只是一个兼容功能，而是一种产品立场。如果Anthropic涨价，可以换OpenAI；如果云端模型不合适，可以尝试本地开放权重模型；如果同一个任务需要比较三个模型，历史记录也不必散落在三个厂商的应用里。Earendil想保留的是用户的退出权。用户真正拥有的不是某个模型，而是积累下来的会话、工具、偏好和工作方式。模型只是其中可以替换的一层。
这和OpenAI的平台路线有一个细微但重要的区别。OpenAI文章里的主体是“应用开发者”，开发者拥有产品界面和业务规则，再把Codex嵌进去。Earendil文章里的主体是“最终用户”，用户拥有Harness，再决定接入哪个模型和哪些工具。两种开放，不是同一回事。
四、两种开放，未来可能汇合
把这两条路线简单概括成“Pi开放、Codex封闭”并不准确。Codex CLI、app-server和SDK都有开源组件，主仓库采用Apache 2.0许可证。开发者可以检查模型与应用之间的代码，理解沙箱、审批和工具调用怎样工作，也可以改造自己的集成。Codex也不是完全不能切换模型，官方配置支持自定义Model Provider，还内置Ollama和LM Studio作为本地模型入口。只是自定义Provider目前需要兼容Responses API协议，某些工具和模型特性未必能在不同Provider上得到一致表现。OpenAI自己也明确写道：开源的是Harness和集成层，模型访问与托管服务仍是分开的。
所以，双方强调的是两种不同的开放：Pi给用户的是退出权，Codex给开发者的是组合权。前者允许你替换发动机，后者允许你把整套动力系统装进自己的车。真正被争夺的，已经不是聊天框。早期AI产品的竞争集中在聊天界面：谁响应更快，谁能上传更多文件，谁的答案看起来更聪明。Agent普及以后，聊天框的重要性正在下降。一个长期运行的Agent会积累项目历史、工具权限、审批习惯、个人偏好、失败经验和可复用技能。换掉模型也许只需要改一个配置，迁走这些东西却可能非常麻烦。这也是Harness开始成为平台的原因。
OpenAI希望开发者把Codex Loop当成现成基础设施，优势很现实：线程管理、上下文压缩、流式事件、沙箱和审批都已经完成，产品团队可以把精力放在业务本身。Earendil则提醒用户，便利也可能形成新的绑定。如果会话、记忆、工具和身份都沉淀在某个平台里，模型能不能切换就不再是唯一问题。对个人开发者来说，Pi这类中立Harness更像一套自己的工作台，你愿意花时间维护它，换来的是自由度和本地控制。对企业产品团队来说，Codex app-server更像一块已经验证过的Agent底盘，它未必最中立，但能少走很多工程弯路，而且审批、沙箱和事件流正是企业落地时最费时间的部分。
两者没有简单的胜负。如果你要给现有运维系统加一个能调查、建议并执行的Agent，Codex Platform是更直接的选择。如果你想建立一套跟着自己走、可以不断换模型和改工具的个人AI环境，Pi的路线更符合目标。最有可能的未来，是两条路线汇合。OpenAI正在把Codex从一个完整应用拆成CLI、SDK、app-server和MCP接口，让外部产品拿走界面与业务控制权。Pi则从另一端出发，把Harness做薄，让用户拿走模型选择权和扩展权。两边都在拆掉“一个模型配一个聊天App”的旧结构。
更合理的下一步，可能是一种类似浏览器的关系：业务应用定义当前工作流、数据和审批规则；用户选择自己信任的Harness、模型和记忆系统；双方通过标准协议交换上下文、工具和执行结果；高风险动作由应用和用户共同授权。到了那一步，用户进入一个物流、财务或研发系统时，不必使用平台指定的唯一Agent。应用也不必自己训练模型、重写Agent Loop，只需要声明它能提供什么上下文、哪些动作可调用、什么操作必须确认。这比“所有软件最后都变成聊天框”更接近真实世界。人们不会因为有了Agent就放弃地图、时间线、表格和业务面板。这些界面仍然是理解工作最有效的方式。Agent应该进入这些界面，而不是把它们全部抹掉。OpenAI已经在解决“怎样把Agent放进软件”，Earendil追问的则是“放进去以后，Agent到底归谁”。这两个问题，最终必须一起回答。