OpenAI联合创始人Greg Brockman近日在社交平台透露，Codex的定位已发生根本转变——它不再局限于代码生成领域。一个税务准备试点项目利用Codex处理了7000份申报表，平均准备时间缩短约三分之一。这个数字背后，是Codex作为通用agent平台的潜力正在被验证。
从编码助手到通用agent平台
大多数用户认识Codex，是通过其三个官方产品：图形化App、命令行CLI和IDE扩展。但这三款产品只是冰山一角，它们共享同一套开源的Codex harness——一个负责上下文管理、推理迭代、工具调用、沙箱边界、审批流程和跨轮次状态保持的执行系统。OpenAI开发者博客指出，开发者可以将agent嵌入自己的产品中，让agent主动走进团队原本使用的工具，而非强迫所有人迁移到通用编码助手。
这一转变的意义在于：agent的适用场景从程序员写代码扩展到了税务、客服、安全、运营等专业工作流。税务试点正是典型案例——agent不再只是生成代码，而是处理真实的业务申报流程。
harness：被低估的性能倍增器
一个可用的agent远不止于提示词与模型输出的简单组合。它需要理解任务、维护上下文、检视信息、调用工具、汇报进度、处理失败、请求审批，最终交付可用结果。这套将模型响应包装起来的执行系统，就是harness。其设计优劣直接决定agent的能力上限。
OpenAI给出了一个极具说服力的数据：在ARC-AGI-3基准上，仅调整harness的“保留推理痕迹+上下文压缩”两项设置，同一个GPT-5.6 Sol模型的得分从13.3%跃升至38.3%，输出token减少至原来的六分之一。这组数据揭示了一个常被忽视的事实：当模型能力接近天花板时，工程实现的细节往往决定最终效果。harness怎么做，比模型用什么更能影响agent的实际表现。
平台架构与集成：三种方式满足不同场景
Codex app-server暴露的客户端协议将系统划分为三层：应用层拥有产品上下文，harness层负责agent loop，模型访问与托管服务则保持闭源。这个边界设计很巧妙——开源harness和集成面，闭源模型服务，既让开发者能审查和定制，又为OpenAI保留了护城河。
针对不同的集成深度，OpenAI提供了三种方式：codex exec面向命令行非交互任务，适合CI脚本和一次性运行；Codex SDK是程序化agent工作流的库；Codex app-server则适合产品内嵌场景，支持长对话、流式事件和审批处理。简单区分：exec是命令行，SDK是库，app-server是协议。选择哪种，取决于agent是辅助工具还是产品本身。
笔者认为，这种分层策略相当务实。它没有强迫所有场景都使用重型协议，而是让开发者根据实际需求选择合适粒度。尤其app-server的出现，意味着产品团队可以完全控制agent的生命周期和用户体验，而不必被聊天框束缚。
工作流嵌入：agent的未来在仪表盘里
OpenAI在博客中强调，真正有趣的机会不是复制Codex App换一个logo，而是构建反映特定团队工作方式的软件。安全分析师需要告警调查队列和审批步骤；客服工程师需要账户历史和内部文档；产品团队需要任务看板，将issue拖到ready状态即启动实现工作流。在这些场景中，界面本身就是体验的关键——它告诉agent用户正在看什么，提供对路工具，并给用户审查下一步动作的地方。
为了演示这一模式，OpenAI展示了名为Relay的示例应用：一个跑在Codex app-server之上的货运运营原型。用户选中一票货，点击“Compare recovery”，应用提供上下文，Codex拉取最新运营数据并解释可选方案，任何写入动作都需人工审批。这个模式已经落地到生产环境，包括税务处理、思科App Builder等团队。值得注意的是，这些案例不限于工程领域——客服、运营、安全、销售、市场都能套用同一套模式。
回顾Greg的帖子，OpenAI想传达的核心信息是：Codex现在是一个平台。它提供了可直接使用的agent loop、可在自有产品中运行的协议、清晰的开源/闭源边界，以及已验证的应用案例。对于非工程团队而言，这意味着不必自建agent框架，也不必把工作搬进通用聊天框，而是让Codex走进你原本就在使用的仪表盘和看板。执行权始终在人手中，关键写入必须经过审批。
笔者认为，OpenAI将harness彻底开源是一步险棋，但也可能借此扩大生态影响力。agent平台的护城河不在模型，而在harness和协议。开源这层核心，等于把护城河变薄，但同时也让Codex有机会成为agent应用的事实标准。下一步的竞争焦点，将是谁能用好这套harness，做出真正有人用的产品。