8月20日凌晨，OpenAI联合创始人Greg Brockman在X上发了条推文，浏览量很快破了18万。他没聊新模型，没聊跑分，只说了一件事：把Codex背后的发动机开源了。知乎再加上刚过一周DeepSeek放出的DeepSeek Harness，AI Agent圈的两个头部玩家，在一周之内把各自的"发动机"都交了出来。
如果你印象里的开源还停留在"放出模型权重"，这波有点不一样。这次放出来的，是Harness——驱动模型干活的那套执行系统。
Harness到底是个啥？
很多人认识Codex，是通过App、CLI或者IDE插件，但这些只是同一套底层系统的不同入口。真正可复用的部分，是agent loop：理解任务、维持上下文、调用工具、处理失败、请求人类确认、返回结果。OpenAI给Harness的官方定义，是负责conversation state、流式输出、工具调用、sandbox、审批策略、跨turn工作这些东西。知乎包在这个循环外面的执行系统，就是Harness。
这次OpenAI放出来三样东西：在终端本地跑的轻量级coding agent——Codex CLI，提供直接编程接口的Codex SDK，以及负责持久会话、流式事件和审批处理的Codex app-server。知乎外加一个演示应用Relay——一个货运运营看板，旁边挂着一个由app-server驱动的agent：Harness管agent loop、对话状态和工具调用，看板、记录和控件依然是产品自己的。
翻译成大白话：不是只卖你一台整车，而是把发动机和变速箱亮出来，让你搬回家装进自己的车里。
为什么突然开源发动机？因为发动机决定上限。
OpenAI官方博客里引了一个ARC-AGI-3实验：同一个GPT-5.6 Sol模型，在加入retained reasoning和context compaction后，成绩从13.3%提升到38.3%，输出token还降到约六分之一。知乎模型一个字节没变，只是执行层的设置变了，成绩差出近三倍。
还有个更生动的例子：沃顿商学院教授Ethan Mollick把GPT-5.6 Sol交给Codex，让它控制电脑玩《Slay the Spire 2》的每日挑战——每次随机生成、没法靠背答案过关的关卡。Agent连续工作了五个多小时，一路做复杂决策，最终通关。知乎撑起这五个小时的，正是context compaction——它让agent没被上下文膨胀拖垮。
也就是说，现在比拼的早就不只是模型，而是"模型+Harness"的组合。这也是最近一周社区吵得最凶的地方：DeepSeek V4 Pro正式版跑在自家Harness的"极简模式"里会明显变强，有实测发现官方版只能跑出85-90分的任务，极简模式能跑出96-99分。知乎到底是深度协同优化，还是对着自家框架"特调"，社区还在争论。但能吵起来本身就说明：模型和Harness的关系，已经从"驱动和软件"变成了协同设计、共同进化。
两家都开源，但走的是两条完全不同的路。
DeepSeek走的是"社区游乐场"：微内核架构，一切皆插件，模型、工具、Skills、UI全都能拆换重组，TypeScript代码库对开发者也友好。开源的GitHub仓库上线不到一天，就冲到了7万多Star。知乎
五天之后，这个数字超越了151k，社区插件也迅速涨到近千款。知乎哔哩哔哩B站教程视频动辄几十万播放，最火的一条接近68万。当然，评价也两极分化：不少实测用户说它门槛偏高、界面简陋，“现阶段不推荐普通用户”。
OpenAI走的是"企业生产线"：SDK管嵌入集成，app-server管会话和审批流，官宣里摆的全是落地案例——Cisco把它接进了Cloud Control的App Builder；过去六个月，OpenAI的前线工程师和Thrive Holdings合作打造的税务系统Tax AI，在试点季处理了7,000份申报，准备时间缩短约三分之一，起草准确率最高到97%，业务吞吐提升约50%。知乎
不过先别急着兴奋。有上手体验过的开发者泼了盆冷水：Codex Harness和OpenAI的模型生态是强绑定的，“实际上如果你不用OpenAI的话，用处不是很大，可以参考借鉴，但估计不会直接基于Codex SDK和App Server去开发一个不用GPT的Agent产品”。知乎这波开源的本质，是把开发者和产品拉进OpenAI的体系——毕竟你很难在OpenAI的Harness里，塞一个别家的模型进去。而DeepSeek的开源策略恰好相反：它赌的是插件和社区长得更快。
那对你来说，这意味着什么？
如果你是AI编程的日常用户，不用急着折腾迁移，这波开源短期不改变你的日常体验。倒是可以看看B站社区的同任务实测：同一个模型、同一个项目、同一个需求，只换Harness，DeepSeek Harness用时4分57秒，Codex用时8分02秒，两边28项原有质检全部通过。哔哩哔哩Harness对效率的影响是实打实的，但哪个更顺手，取决于你的任务类型。
如果你想把agent嵌进自己的产品，这波值得认真评估：Codex app-server提供thread管理、执行审批、review这类完整API，能省下自建agent运行时的功夫；DeepSeek Harness的插件体系则适合想深度定制、不折腾TS生态就难受的人。判断标准其实很朴素：你的业务绑哪个模型，就优先看哪家的Harness。
如果只是围观，记住几个观察信号：DeepSeek Harness的插件生态能不能长出真正被企业用起来的东西，有没有企业系统真的跑在Codex app-server上，以及最关键的——跑分测试以后会不会开始标注Harness配置。哪天"跑分"必须注明"在哪个Harness上跑的"，这场变革才算真正落地。
有知乎答主打了个挺贴切的比方：现在的Agent产业，很像早期Android——开放底座让大家不用再重复造轮子。知乎但最后长出来的是真正的Android生态，还是一个被全行业模仿的参考实现，要看接下来半年：接口能不能稳定，插件体系能不能建立信任，有没有带着真实用户和收入的垂直软件愿意长期驻扎。
发动机已经交出来了，接下来比的不是谁的马力大，而是谁家的底盘上，愿意跑别人的车。
