Agent之HarnessCodex概述—以开放 Agent Harness 为核心将上下文、工具、状态、沙箱、审批与代理循环嵌入既有产品通过 codex exec、Codex SDK 与 Codex app-server 构建面向工程、运营、安全、客服、销售和其他专业工作流的可控 AI 产品导读随着 Codex 从单一的编码助手逐步发展为可以被嵌入不同软件产品和业务流程的代理执行能力开发者关注的重点正在从“如何使用 Codex”转向“如何把 Codex 构建进自己的产品”。文章指出Codex App、CLI 和 IDE Extension 虽然呈现形式不同但其底层都建立在同一套 Agent Harness 之上。真正可复用的核心并非某一个界面而是围绕模型形成的完整代理执行机制包括上下文获取与管理、任务推理、工具调用、状态保持、流式执行、错误处理、沙箱控制以及人工审批。因此Codex 的价值正在从一个面向开发者的编码工具进一步延伸为一种可以服务于更广泛工作场景的开放代理基础设施。当前Codex 已经具备较完整的产品化和开放化基础开发者可以根据实际场景选择不同的集成层对于脚本、CI 或一次性后台任务可以使用 codex exec对于应用内部的程序化任务可以使用 Codex SDK当代理本身成为产品组成部分需要持续会话、事件流、工具交互和审批控制时则可以采用 Codex app-server。与此同时文章通过 Relay 以及 GitHub、JetBrains、Cisco、Thrive Holdings 和 Crete 等案例说明这种模式正在从软件工程向运营、安全、客服、税务等工作场景扩展其共同特点是由业务应用掌握上下文、数据、工具和业务规则而由 Codex 负责底层代理循环与执行。文章围绕“Codex as a platform”这一核心命题系统说明了如何将开放的 Codex Harness 转化为可嵌入产品的代理能力。首先文章阐明 Agent Harness 是真正值得复用的部分因为代理效果不仅取决于模型本身还取决于上下文管理、持续推理、工具调用和执行控制等机制其次文章介绍开源 Harness 带来的可检查、可调整和可集成能力以及 codex exec、SDK 和 app-server 各自适用的场景随后进一步提出优秀的代理产品不应只是重新制作一个聊天界面而应围绕真实工作流构建让仪表板、任务板、记录、文档和业务系统成为代理工作的天然上下文并通过工具与审批机制把“理解任务—调查信息—提出建议—获得批准—执行行动”连接起来。Relay 的示例则完整体现了这种架构即应用负责产品体验和业务控制Codex 负责代理循环、工具交互和执行过程。这篇文章的核心并不是介绍一个新的 Codex 使用入口而是在重新定义 Codex 对开发者的意义Codex 不只是一个供人使用的编码助手更可以作为一个可嵌入其他软件和业务工作流的代理执行基础设施。其中真正值得复用的是开源 harness 所提供的代理循环——它负责上下文、状态、工具、执行、审批和持续工作而具体应用则继续掌握自己的界面、业务规则、数据和操作边界。文章通过 codex exec、Codex SDK 和 Codex app-server 三种集成方式说明如何针对不同场景选择适合的技术层级。文章进一步强调代理产品的价值并不意味着“把所有工作改成聊天”。相反最有潜力的方向是进入用户已经熟悉的工作环境让现有仪表板、任务板、记录、地图、文档和业务系统获得代理能力代理负责理解上下文、调用工具、调查和提出行动建议而应用负责业务规则、数据、审批和最终控制。Relay以及 GitHub、JetBrains、Cisco、Thrive Holdings 和 Crete 的案例都在体现同一个架构思想让 AI 适应工作流而不是让工作流迁就 AI。从文章所呈现的方向来看Codex 的未来空间并不局限于编码领域而在于成为一种可以嵌入各类专业软件和工作流程的通用代理基础设施。未来更值得关注的并不是用 AI 替换现有工作界面而是让已有界面获得理解上下文、调查信息、提出行动并在授权后执行任务的能力使 AI 真正融入用户已经熟悉的工作方式。随着开放 Harness、SDK、app-server 以及应用自身工具和业务系统之间的组合更加成熟代理产品有望进一步覆盖工程、运营、安全、客服、销售、市场及其他专业领域而产品设计的核心也将从“构建一个 AI 助手”进一步转向“构建一个由 AI 驱动、但仍由业务系统和用户掌握控制权的工作环境”。目录Codex—以开放 Agent Harness 为核心将上下文、工具、状态、沙箱、审批与代理循环嵌入既有产品通过 codex exec、Codex SDK 与 Codex app-server 构建面向工程、运营、安全、客服、销售和其他专业工作流的可控 AI 产品从“使用 Codex”走向“把 Codex 嵌入产品”核心要点经验技巧第一章The reusable part is the agent loop核心要点经验技巧第二章An open harness developers can inspect and adapt核心要点经验技巧第三章Choose the right integration layer核心要点经验技巧第四章Build software around the workflow核心要点经验技巧第五章Example: Relay核心要点经验技巧第六章What developers are building核心要点经验技巧第七章Build beyond the obvious核心要点经验技巧Codex—以开放 Agent Harness 为核心将上下文、工具、状态、沙箱、审批与代理循环嵌入既有产品通过 codex exec、Codex SDK 与 Codex app-server 构建面向工程、运营、安全、客服、销售和其他专业工作流的可控 AI 产品地址《Codex as a platform: build on the open agent harness》文章地址https://developers.openai.com/blog/codex-as-a-platform时间2026年08月19日作者Nicolas Bonamy, Derrick Choi从“使用 Codex”走向“把 Codex 嵌入产品”文章开篇提出用户熟悉的 Codex App、CLI 和 IDE Extension 只是同一个底层系统的几种呈现方式其真正可复用的核心是开源的 Codex harness代理执行框架。该框架负责让模型获取上下文、推理任务、调用工具、遵循配置好的边界、请求人工批准并持续推进工作因此开发者不必要求团队迁移到一个通用的编码助手界面而可以把 Codex 直接嵌入工程、运营、安全、客服或其他专业团队已经使用的软件与工作流中。核心要点Codex 的多种形态用户通常通过 App、命令行界面或 IDE Extension 接触 Codex但这些只是同一底层系统的不同使用方式开源 Harness 是共同底层Codex 的开源 harness 为这些体验提供基础负责收集上下文、处理任务、使用工具、遵守运行边界、请求批准以及持续执行工作产品嵌入而非强制迁移开发者无需让所有团队都改变原来的工作方式而可以把代理能力嵌入工程工作流、运营仪表板、安全调查、客服控制台或专业内部应用围绕真实工作设计文章强调的核心方向不是再造一个通用编码助手而是让代理进入用户已经理解和使用的产品环境中。经验技巧保留现有工作界面不要默认把所有代理交互变成聊天窗口应考虑用户已经在使用的仪表板、编辑器、队列、地图、记录和审批流程从“工作”而非“模型”出发先确定用户正在完成什么具体任务再决定 Codex 应该嵌入哪个产品环节把 Codex 当作可嵌入的执行能力文章建议关注 Codex 底层 harness 的复用价值而不是只复制现成 Codex 产品的表面交互。第一章The reusable part is the agent loop本小节的核心观点是一个真正有能力的智能代理远不只是“提示词 模型回答”它必须拥有一整套围绕模型运行的执行机制理解任务、长期保持上下文、检查相关信息、调用工具、展示进度、处理失败、在需要时请求人工批准并最终返回有用结果。这一整套外围执行系统就是 harness。文章进一步指出harness 的设计本身会显著影响结果并以 ARC-AGI-3 为例说明保留推理和上下文压缩可以大幅提升 GPT-5.6 Sol 的表现同时降低输出 token 消耗。Codex harness 则承担会话状态、流式执行、工具使用、沙箱与审批策略以及跨回合持续工作等职责而 Codex app-server 将这些能力通过有文档的客户端协议暴露出来。核心要点代理不只是模型响应一个可用代理需要理解任务、保持上下文、检查信息、调用工具、暴露进度、处理失败、请求人工批准并产生最终结果Harness 是执行系统上述能力所依赖的外围执行机制就是 harness它承担模型之外的运行时职责Harness 会影响结果文章以 ARC-AGI-3 为例指出保留推理与上下文压缩使 GPT-5.6 Sol 的得分从 13.3% 提高到 38.3%同时输出 token 减少 六倍Codex Harness 的职责负责会话状态、流式执行、工具使用、配置好的沙箱策略、审批策略以及跨回合继续执行任务App-server 暴露执行能力通过文档化的客户端协议应用可以创建线程、启动回合、接收事件并处理审批请求降低重复造运行时的成本如果开发者的软件需要代理可以直接以 Codex 为起点而不是重新设计一套代理运行时。经验技巧把运行时能力作为独立层设计代理产品时不应只关注模型和 Prompt还要明确上下文、工具、状态、审批、错误处理和执行生命周期重视上下文生命周期文章的 ARC-AGI-3 示例表明如何保留和压缩上下文本身就可能改变代理表现优先复用现成 Harness对于需要完整代理执行能力的软件可以从 Codex harness 开始而不是首先自行创建一套新的 Agent Runtime利用 App-server 管理生命周期当应用需要线程、回合、事件流和审批交互时可以通过 app-server 获得相应能力。第二章An open harness developers can inspect and adapt本小节强调 Codex harness 的开源特性带来的控制权。开发者能够检查应用与模型之间的这一层理解它的行为并根据自己的产品需求调整集成方式。文章把这种控制具体归纳为三个方面可以保留自己的界面可以让应用提供与具体工作流相关的上下文和工具也可以由宿主应用决定代理的运行位置、文件及工具访问权限、哪些行动需要审批、如何观察工作以及结果如何回到业务系统。同时OpenAI 将 Codex CLI、app-server 和官方 Codex SDK 作为开源组件发布但文章明确区分开源的是 harness 和集成层模型访问及托管服务仍然是独立部分。核心要点可检查、可适配开发者能够查看应用与模型之间的 harness 层从而理解代理行为并调整集成界面控制权产品可以继续使用原有仪表板、编辑器、队列、地图、记录和审批流程无需把交互全部转换成通用聊天窗口上下文与工具控制权应用能够向代理提供特定工作流需要的系统、文档、数据和动作包括应用自有的 MCP 服务运行边界控制权宿主应用能够决定代理在哪里运行、访问哪些文件和工具、哪些行为需要审批、如何观察执行以及结果如何回写业务系统开放组件文章指出 Codex CLI、app-server 和官方 Codex SDK 均作为开源组件发布边界划分开源层主要覆盖 harness 与集成界面模型访问和托管服务保持独立。经验技巧让应用掌握业务边界代理并不需要自行拥有完整业务环境应用本身可以控制它所能看到和执行的内容围绕具体任务提供工具应向代理暴露真正与工作流相关的系统、文档、数据和操作而不是无差别提供所有能力把审批纳入系统设计对于需要人工确认的行为应让宿主应用定义审批边界而不是把所有操作默认交给代理区分开源集成层与模型服务采用 Codex 时应明确哪些能力来自开放的 harness/integration surface哪些部分属于独立的模型访问和托管服务。第三章Choose the right integration layer本小节说明不同场景不需要采用同一种 Codex 集成方式。对于脚本、CI 工作或一次性的后台任务可以使用 codex exec 执行有边界的代理工作流并返回结构化结果对于应用代码需要以编程方式启动、恢复或流式处理 Codex 任务则可以使用官方 Codex SDK而当代理本身成为产品的一部分时则应使用 Codex app-server使应用能够连接本地 Codex 进程、保持开放式对话、流式接收事件、中断任务、暴露工具并处理审批。文章将 SDK 定位为简化常见程序化工作流的方式而将 app-server 定位为让产品团队直接控制代理生命周期和用户体验的方案。核心要点codex exec适合脚本、CI Job 或一次性后台任务可运行有边界的代理流程并返回结构化输出官方 Codex SDK适合应用代码以编程方式启动、恢复或流式处理 Codex 任务Codex app-server适用于代理已经成为产品本身组成部分的场景App-server 的能力应用可以连接本地 Codex 进程、保持对话、流式接收事件、中断工作、向代理提供工具并响应审批请求SDK 与 app-server 的差异SDK 更偏向简化常见的程序化代理流程app-server 则更强调产品团队对生命周期和用户体验的直接控制。经验技巧按使用场景选择集成层一次性任务不要为了完整产品能力引入更重的集成产品内嵌代理则应选择能够控制生命周期的方案非交互任务优先考虑 codex exec对于脚本、CI 和后台工作流可以使用有边界的执行方式并获取结构化输出程序化任务使用 SDK当应用代码需要直接启动、恢复和流式处理任务时文章推荐使用官方 SDK代理成为产品功能时使用 app-server当用户需要持续会话、实时事件、工具交互、中断和审批等完整体验时应把 app-server 作为产品级集成层。第四章Build software around the workflow本小节把重点从“如何集成 Codex”进一步转向“产品应该如何围绕工作流设计”。文章明确指出最值得探索的方向并不是换一个品牌重新做一个 Codex App而是针对某一类人员或团队已有的工作方式构建软件。例如安全分析师可能需要调查队列、最新告警、受影响服务和创建修复工单前的审批步骤客服工程师可能需要账户历史、产品日志、内部文档及回复草稿产品团队则可能希望通过任务板中某个状态变化来触发限定范围的实现流程。共同规律是界面本身就是代理体验的重要部分因为它告诉代理用户正在查看什么为代理提供正确工具并为用户提供审核下一步动作的地方。文章的架构示意进一步强调应用拥有产品上下文、业务规则和工具而 Codex app-server 则负责代理循环和沙箱执行。核心要点拒绝“换皮 Codex”最有价值的机会不是简单复制 Codex App而是围绕具体人员和团队实际工作方式设计软件安全工作流示例调查队列、最近告警、受影响服务和开具修复工单前的审批都可以成为产品界面的一部分客服工作流示例账户历史、产品日志、内部文档以及回复草稿可以共同构成代理工作环境产品开发工作流示例任务板中的状态变化可以直接触发限定范围的实现流程界面承担工作上下文界面不仅是展示层还负责告诉代理用户正在看什么、提供正确工具同时给用户留下审核下一步工作的空间职责分工应用负责产品上下文、业务规则和工具Codex app-server 负责代理循环和沙箱执行。经验技巧从用户的真实工作界面反推代理设计先观察人员实际通过什么队列、记录、仪表板或任务板工作再决定代理应嵌入哪里让 UI 提供上下文不要让用户每次都重新描述背景而应由当前界面和业务状态自然地为代理提供任务上下文把业务规则留在应用层代理负责执行智能任务但产品自己的业务规则、记录和工具仍由应用控制将审批设计成工作流步骤把审批放在真实业务动作前而不是把它设计成脱离上下文的额外操作。第五章Example: Relay本小节通过 Relay 这一示例展示如何把上述架构落地。Relay 是建立在 Codex app-server 上的样例运营应用它把代理放在一个虚构的货运仪表板旁边接入应用自有的 MCP 工具并要求在重新预订货运这一类后果性操作之前取得人工批准。用户不是从空白提示词开始而是先选择一票货运并点击诸如“Compare recovery”的操作应用提供相关上下文Codex 获取最新的示例运营数据代理解释可用选项而涉及实际写入的动作则必须经过批准。批准后Codex 可以通过应用的 MCP 工具获取数据并执行操作工具修改底层记录后应用刷新自己的业务视图。由此harness 管理代理循环、会话状态、流式活动和工具交互而产品继续掌握自己的仪表板、记录和控制机制。文章同时说明这一模式虽然使用虚构数据却可以推广到事故响应、账户运营、研究工作流等场景。核心要点Relay 的定位它是建立在 Codex app-server 上的示例运营应用代理嵌入业务界面Codex 被放置在虚构的货运仪表板旁并连接应用自有 MCP 工具上下文由应用提供用户先选择货运并触发具体操作应用主动把相关上下文交给代理而不是要求用户重新编写完整 Prompt代理读取最新数据Codex 可以通过 MCP 工具获取最新示例运营数据并据此解释可选方案后果性写入需要审批重新预订货运等实际产生业务影响的写操作必须经过人工批准业务系统保持主导工具修改数据后应用刷新业务视图harness 负责执行过程而产品继续拥有仪表板、记录和控制权模式具有可迁移性同一集成模式还可以支持事故响应、账户运营和研究工作流等应用。经验技巧让用户从业务对象开始通过“选择一票货运 → 点击具体动作”启动任务比要求用户从零写 Prompt 更贴近实际业务流程先读数据、再做建议文章中的 Relay 先取得当前数据再由代理解释选项而不是脱离最新业务状态直接行动把人工批准放在高影响动作前对于会修改业务记录的操作应设置明确的审批环节保持系统记录同步当代理通过工具修改底层数据时应让业务应用刷新自己的视图使用户看到最新状态让代理嵌入已有产品代理负责智能执行而原有产品继续负责业务界面、数据记录与控制机制。第六章What developers are building本小节说明文章所描述的模式已经出现在公开实践中。GitHub 和 JetBrains 将 Codex 带入已有的 IDE 工作流Cisco 在 Cisco Cloud Control 的 App Builder 中使用 Codex SDKThrive Holdings 和 Crete 则把 Codex 用于融入从业人员反馈的税务准备工作流其试点处理了 7,000 份申报并将准备时间缩短了约三分之一。文章进一步指出这种模式并不限于软件工程还可以用于客服、运营、安全、销售和市场等工作其共同模式始终是由应用提供上下文、工具和审批而 Codex 提供底层代理循环。核心要点GitHub 与 JetBrains把 Codex 带入现有 IDE 工作流Cisco在 Cisco Cloud Control 的 App Builder 中使用 Codex SDKThrive Holdings 与 Crete在税务准备工作流中使用 Codex并纳入从业人员反馈试点效果相关试点处理了 7,000 份申报准备时间缩短了约 三分之一适用范围扩大模式不仅适用于工程还可以用于客户问题调查、运营协调、安全事件分诊、销售账户研究和市场活动开发共同架构应用提供上下文、工具和审批Codex 负责底层代理循环。经验技巧从已有业务系统切入不要把代理局限在纯编码环境可以优先寻找已经具有明确上下文、工具和决策流程的工作把行业经验保留在工作流中例如税务准备案例中工作流本身可以纳入从业人员反馈使代理能力嵌入实际业务过程评价代理价值时关注工作结果文章给出的公开案例不仅展示“用了 Codex”还展示了处理规模和时间改善等业务结果保持统一模式无论面向工程、客服、运营、安全、销售还是市场核心都仍是“应用提供业务环境Codex 驱动代理执行”。第七章Build beyond the obvious最后一章进一步提升文章的核心命题对于许多工作真正重要的上下文天然存在于仪表板、时间线、地图、文档或系统记录中而这些界面之所以重要不是因为视觉效果而是因为它们是人们理解发生了什么、做出决策并保持控制的实际方式。因此机会并不是用一个“万能聊天框”取代这些界面而是让这些已有界面变得更有能力让代理理解工作、调查正确上下文、提出下一步并在获得批准后采取行动。文章最后再次强调Codex App、CLI 和 IDE Extension 展示了 harness 的能力而开源 harness 则让开发者能够检查、集成并适配这些能力具体可以根据产品需要在 codex exec、Codex SDK 和 Codex app-server 之间选择。核心要点业务上下文已经存在很多工作的重要信息本来就位于仪表板、时间线、地图、文档或系统记录中界面本身具有业务价值这些视图是人们理解状态、进行决策并保持控制的方式而不仅仅是装饰性 UI不是用聊天框替代界面文章反对把所有工作都迁移到一个通用聊天框中让原有界面变得更智能代理可以理解工作状态、调查相关信息、提出下一步并执行经批准的动作开放 Harness 的价值开发者能够检查已有能力、将其集成到自己的应用并根据工作流进行适配最终集成选择非交互任务使用 codex exec程序化代理工作流使用 Codex SDK需要持久对话、流式事件和审批处理的应用则使用 Codex app-server。经验技巧优先增强既有界面不要首先考虑“做一个新的 AI 页面”而应先寻找现有工作界面中代理能够创造价值的位置让代理理解界面状态界面中的业务对象、记录和状态应该成为代理工作的直接上下文把“调查—建议—批准—行动”连接起来文章最终呈现的是一种让代理参与完整工作流程、但仍保留用户控制权的模式根据产品需求选集成方式从轻量的非交互任务到完整产品内嵌代理应匹配不同的 Codex 集成层而不是所有场景统一采用一种方式。
