事件回顾：从 CLI 前端到完整 Agent 运行时
2026 年 8 月 19 日，OpenAI 在官方开发者博客宣布，驱动 Codex 智能体的核心执行框架 Codex Harness 正式以平台形式开源，采用 Apache-2.0 协议，仓库地址为 github.com/openai/codex。这不是去年 5 月那次仅开源 CLI 前端的"半成品"，而是把底层 Rust 核心 codex-rs、app-server 持久会话层、官方 SDK 一并放出。
OpenAI 自己给 Harness 的定位很直白：它管理对话状态、流式执行、工具调用、沙箱边界、人工审批，是 Codex App、CLI 和 VS Code 插件共用的一套基础设施。用官方博客的话说，"your application owns product context, business rules, and tools; Codex app-server provides the agent loop"。
这次开源包含三层集成接口：
- codex exec：非交互式 CLI，适合 CI/CD、一次性后台任务；
- Codex SDK：TypeScript/Python 双接口，用于在自有应用中编排 Agent 生命周期；
- Codex app-server：通过客户端协议与本地 Codex 进程保持长连接，支持流式事件、中断、审批请求。
最吸睛的数据来自 ARC-AGI-3 基准测试：仅通过优化 Harness 的" retained reasoning"和上下文压缩机制，GPT-5.6 Sol 的得分就从 13.3% 提升到 38.3%，输出 token 数量降至原来的六分之一。OpenAI 还举了一个税务准备试点的例子：处理 7000 份申报，整体准备时间缩短约三分之一。
同一天，DeepSeek 也更新了 API 文档，上线 DeepSeek V4 Flash Vision Exp 多模态模型，并宣布 DeepSeek Harness 支持官方多模态。两个"Harness"遥相呼应，把"Agent 运行时"这个概念推到了舞台中央。
深度分析：Harness 到底改变了什么？
1. 模型能力之外，执行框架成为新的竞争壁垒
过去两年，AI 编程工具的叙事一直围绕"模型智商"展开：谁家的 SWE-bench 分数更高、谁的上下文更长、谁的定价更低。但 Codex Harness 的开源揭示了一个被长期低估的事实------同样的模型，套在不同的执行框架里，表现可能天差地别。
ARC-AGI-3 上 13.3% 到 38.3% 的跳跃，不是换了一个更强的基座模型，而是换了一个更会"带模型干活"的 harness。这类似于：你招了一个绝顶聪明的实习生，但如果任务拆解混乱、上下文管理糟糕、工具调用没有边界，他的产出大概率一团糟；反之，一个中上水平的员工配上清晰的 SOP、审批节点和记忆系统，反而能稳定交付。
这对行业的影响是，竞争焦点从"模型参数"向"模型编排"迁移。当 DeepSeek V4 Pro、Qwen3.7 Max、GLM 5.2 等模型在基础能力上快速趋同，"怎么把模型嵌入真实工作流"就成了决胜点。Harness 就是那个嵌入层。
2. 从"聊天框优先"到"工作流优先"
OpenAI 在博客中明确批评了传统模式："与其强行将工作流适配到通用助手，不如让智能体直接嵌入业务场景中的专用软件。"安全分析师的威胁看板、客服工程师的工单系统、产品经理的数据仪表盘------这些才是真实上下文，聊天框只应是辅助入口。
这是一个重要的产品哲学转向。过去，AI 应用的标准形态是"一个超级对话框+插件"；未来，更可能是一种"深度内嵌"形态：Agent 的能力通过 SDK/app-server 被拆进企业自有系统，用户在自己熟悉的界面里与 Agent 协作，而不是迁移到某个统一的 AI 客户端。
对开发者而言，这意味着两个机会：一是把现有 SaaS/内部工具改造成 Agent 原生 ；二是围绕特定垂直场景打造 Agent 驱动的新产品。OpenAI 已经用 Cisco 云管理工具和 Thrive Holdings 的案例做了背书，接下来会有更多企业效仿。
3. 开源策略背后的商业算计
OpenAI 选择 Apache-2.0 而不是自家更封闭的协议，看起来很慷慨，但商业逻辑很清晰：
- 锁定生态：当开发者和企业把 Harness 嵌入自己的产品后，模型调用、托管服务、企业版审批等企业级功能自然回流到 OpenAI 的商业化体系；
- 建立标准：与 DeepSeek Harness、Claude Code、Cursor Router 等竞品争夺"Agent 运行时"的事实标准；
- 降低获客成本：通过开源把 Harness 变成基础设施，让企业主动找上门来购买模型 API 和管理服务。
这几乎复刻了 Kubernetes、React 当年的路径：核心框架开源，周边云服务收费。区别只在于，AI 时代的"周边"是模型调用、安全审查、审计日志、多租户隔离等高附加值服务。
4. "Everything through the harness" 的行业共振
无独有偶，DeepSeek 也在推自己的 Harness，并喊出"Everything through the harness"的口号。两家公司的 harness 设计高度相似：模型不直接面向用户，而是被 harness 封装后以可控、可审批、可持久化的方式对外提供能力。
这种共振说明，行业正在形成一个新的共识：裸模型调用不够用了，Agent 需要一层操作系统 。这层 OS 负责记忆、工具、审批、沙箱、并发、可观测性，而模型只是其中的一个计算单元。对 Kimi K3、MiniMax M3 等国产旗舰来说，能不能被主流 harness 良好封装，可能比单纯跑分更重要。
观点预判
-
2026 年底将出现"Agent 运行时"独立赛道：类似当年的 Service Mesh，Harness 会从一个工具内部模块演变为独立品类，出现专门做 Agent OS 的初创公司和开源项目。
-
模型价格战让位于"编排效率"比拼：当各家模型 API 价格都降到可接受区间，企业更关心的是"用同样的 token 预算，谁能完成更复杂的长程任务"。Harness 的上下文压缩、推理保留、工具路由能力将成为新的卖点。
-
垂直行业 Agent 迎来爆发：金融合规、医疗质控、工业运维、政务审批等场景对审批链、审计、沙箱有强需求，Harness 提供的边界控制能力正好匹配。未来半年会看到大量"某行业 Copilot"涌现。
-
国产模型需要主动拥抱 harness 生态：DeepSeek 已经迈出一步，但 Qwen、GLM、Kimi、MiniMax 等还需要在 SDK 兼容性、MCP 协议支持、多模态 harness 集成上持续投入，否则会被排斥在开发者首选工具链之外。
实操建议
给技术负责人
- 把 Harness 纳入技术雷达：不要只看模型更新，要评估 Codex Harness、DeepSeek Harness、LangGraph、AutoGen 等框架的成熟度，选择与企业现有技术栈兼容的方案。
- 先从一个低风险场景试点：比如内部代码审查、文档生成、测试用例补全，验证 harness 的审批流、错误处理和审计能力后再扩大范围。
给开发者
- 熟读官方 SDK 的 approval policy：auto/manual/suggest 三种模式适用于不同信任等级，生产环境建议从 suggest 开始，逐步过渡到 manual 再考虑 auto。
- 练习把现有工具封装成 MCP 服务：Harness 强调应用自有的 context 和 tools，能把内部系统通过 MCP 协议暴露给 Agent，是接下来最吃香的技能之一。
给产品经理
- 重新设计人机协作界面：不要再把 AI 功能设计成"聊天侧边栏"，思考 Agent 如何在用户当前工作的界面中主动推送结果、请求审批、展示进度。
- 定义清晰的边界和回退策略：哪些操作 Agent 可以自动执行，哪些必须人工确认，出错时如何优雅回退，这些产品设计问题比模型选择更关键。
给创业者
- 避开"再造一个 Codex App"的陷阱：OpenAI 官方博客明确说，"最有趣的机会不是用不同 logo 复制 Codex App，而是围绕特定团队的真实工作方式构建软件"。找一个小而具体的垂直场景，做深做透。
标签：Codex, Agent, DeepSeek V4 Pro, Qwen3.7 Max