卷疯了!OpenAI 全面开源 Codex Harness

👉这是一个或许对你有用的开源项目

国产Star破10w的开源项目，前端包括管理后台、微信小程序，后端支持单体、微服务架构

RBAC权限、数据权限、SaaS多租户、商城、支付、工作流、大屏报表、ERP、CRM、WMS、MES、HRM、AI大模型、IoT物联网、IM聊天等功能：

• 多模块：https://gitee.com/zhijiantianya/ruoyi-vue-pro
• 微服务：https://gitee.com/zhijiantianya/yudao-cloud
• 视频教程：https://doc.iocoder.cn

01

一个能真干活的 Agent，拆开看远不止模型加一段提示词。模型想完之后那一摊子事得有人管。先弄明白任务是什么，对话拉长了还得记得前面聊过什么，要去调各种工具，要把进度展示出来，中间出错要处理，碰上要紧的操作得停下来等人点头，最后再把结果交回去。

这整套围着模型转的执行系统就是 Harness。作者打了个比方，不一定特别准但好记。模型是赛车手，Harness 是后面那支车队，车手只管开，进站换胎、调参数、看遥测全是团队的事。

ruoyi-vue-pro

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro

视频教程：https://doc.iocoder.cn/video/

02

官方博客给了一组数据。在 ARC-AGI-3 这个难度很高的基准上，模型没换，只在 Harness 上动了两处，保留推理过程加上下文压缩，GPT-5.6 Sol 的得分从 13.3% 提到 38.3%，输出 token 反而少了六倍。

模型决定天花板，外面那层执行系统决定你能不能摸到它。平时大家都盯着模型跑分看，其实同一个模型，底下这套系统搭得好不好，出来的效果能差出好几倍。

yudao-cloud

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/yudao-cloud

视频教程：https://doc.iocoder.cn/video/

03

仓库还是老地方，现在 Star 已经十二万七千多，Apache-2.0，商用和修改都允许，主体是 Rust 写的，大部分代码在 codex-rs 目录里。

具体放出来的是三样东西，按集成深度排。

最浅的是 codex exec，在命令行跑一次性任务，比如 CI 里跑个检查、后台跑个脚本，它有头有尾，跑完返回结构化结果，不需要一直开着。中间是官方 SDK，TypeScript 和 Python 都有，要启动、恢复或者流式读取一个任务直接调它就行，思科那个案例走的就是这条路线。

最深的是 app-server，也是最值得看的一层。你的应用通过一套文档化的 JSON-RPC 协议连到本地的 Codex 进程，能保持长对话不会丢、实时收到事件流、随时打断它、把自己的工具暴露给它用，还能处理审批请求。命令就是 codex app-server，默认走 stdio 传输，也支持 Unix socket。

想自己先跑一遍的话，Mac 和 Linux 上一行 curl -fsSL https://chatgpt.com/codex/install.sh | sh 就装好了，Windows 有对应的 PowerShell 一行，npm 上也能装。官方另外放了一份开源组件指南，写明每个组件放在哪个仓库。

官方博客那张图把这个分工画得挺清楚，左边是你的应用，管界面、业务上下文和业务规则；中间 app-server 管 Agent 循环和沙箱执行；右边是你们自己的 MCP 工具和数据。审批通过的操作回流到产品里，界面自动刷新。

有件事得说清楚，开源的是框架和集成层，模型访问和托管服务不在里面。博客原话是 The open-source layer is the harness and integration surface; model access and managed services remain separate。

所以这次拿到的是一个现成的 Agent 运行时，省得自己从零搭；模型那头接什么，还得自己解决。

官方文档现在把 app-server 命令和 WebSocket 传输都标成了实验性，写明不支持生产负载，这条边界容易被略过。拿它做原型没问题，真要上生产，先看一眼文档上那行提示。

04

放出来的这几批案例都在真实业务里跑过，有数据撑着。

思科用 Codex SDK 在自己的云管平台 Cisco Cloud Control 里做了个 App Builder，客户用自然语言描述需求就能生成自定义应用，底下的活全是 Harness 在跑。

税务那套系统叫 Tax AI，是 Thrive Holdings 和 Crete 两家跟 OpenAI 前线工程师一起做的，专门给 Crete 的会计师用，近期一篇专题文章里放了细节。试点季处理了 7000 份申报表，准备时间缩短约三分之一，起草准确率最高到 97%，业务吞吐提升约一半。

官方还给了完成度的爬坡曲线。上线时字段完成率达标（75% 以上）的申报表只占四分之一，六周内爬到 86%，7 月的预测值是 98%。

另有一条更直观的，有位资深会计师去年的报税准备花了 180 小时，今年只花了 15 小时。

GitHub 和 JetBrains 则把 Codex 接进了 IDE 现有工作流。在 JetBrains 的 AI 面板里能直接选 Codex 当 Agent，权限可以自己调，从只允许问答到放开网络和命令执行，分档给。

05

官方示例里我最喜欢的是 Relay，一个虚构的物流调度看板。调度员选中一张延误的货单，点一下「比较恢复方案」，应用自动把这张货单的所有信息作为上下文交给 Agent。

Agent 通过应用自己的 MCP 工具去查实时运营数据，算出几个方案摆出来；但重新订舱这种真改数据的操作，必须人点了同意才执行，执行完看板自动刷新。

整个流程走下来，聊天框基本没出现。用户不用写提示词，也不用描述背景，界面本身就是上下文，你点的是哪张货单，Agent 处理的就是哪张。官方也补了一句，Relay 用的是虚构的种子数据，能带走的是这套接法。

博客里还有一段我挺认同，大意是看板、时间线、地图、记录系统都有实际用处，人平时就靠这些东西理解工作、做决策。合理的做法是让 AI 进到这些界面里去帮忙，反过来让大家放下看板、都去对着一个聊天框说话，那就走偏了。

06

这次开源最值得留意的地方，是 OpenAI 把一件事摆上了台面。Agent 做到后面，模型外面这层执行系统和模型本身一样要紧。

对正在做内部系统的团队，好处很直接。Agent 循环、对话状态、沙箱、审批这些基础设施，以前得自己一点点搭，现在有一套现成实现摆在那，Apache-2.0，OpenAI 自己的产品也在用，代码全部能看。就算最后不打算用 Codex，它这种分层方式也值得拿回去对着自己家的方案看一看。

聊天框不会消失，我自己每天也还在用。只是往后做正经业务系统的时候，AI 多半会直接待在业务界面里。

仓库地址是 https://github.com/openai/codex 。