第一层 codex exec → “跑一次就走"​
最轻量。相当于你喊一声"帮我修个 bug”，它跑完就结束，不留状态。适合嵌在 CI 流水线里当自动化脚本的一个环节——测试挂了，自动触发，修完收工。没有上下文延续，干完就走人。
第二层 Codex SDK → “编排多个干活的"​
在第一层之上。你不再只是单次调用，而是用代码把多个 Codex agent 串起来、并行跑。比如一个负责写代码、一个负责跑测试、一个负责改文档——你来编排它们怎么协作。从"一个人干一件事"变成"你当项目经理，带一个 AI 小团队”。
第三层 codex app-server → "常驻后台，随时派活"​
最重、最核心。Codex 变成一个一直在后台跑的服务进程​，不会干完就退出。你通过 JSON-RPC 接口随时给它派任务、开新会话、收结果。OpenAI 内部那套 Symphony（agent 自己从工单系统拉活干）就是建在这层之上的。
三者的关系一句话概括：​
第一层是一次性外卖​，第二层是你自己组了个厨房​，第三层是开了家餐厅常驻营业​。
每一层都包住了下面那层的能力——能用 app-server 的人，自然也能做 SDK 能做的事；能用 SDK 的人，exec 的场景也不在话下。所以选哪层，取决于你想把 Codex 嵌入到什么程度：​只是跑个脚本？编排多任务？还是做成产品级服务？​

详细解释下开源的codex app-server是啥，开发者可以怎么使用
codex app-server 是什么
一句话：​它让 Codex 从一个"用完即走"的命令行工具，变成一个一直在后台运行的常驻服务。​
打个比方——
codex exec​（第一层）像叫外卖：下单、送达、吃完、结束，下次得重新点。
codex app-server​（第三层）像雇了一个常驻厨师：他一直待在厨房里，你随时可以派活，他记得上次的上下文，干完等你下一个指令。
技术上说，app-server 是一个持久运行的服务进程​，对外暴露一套 JSON-RPC 接口​。你通过这套标准协议跟它通信：开会话、发任务、收结果、管理多个并行的工作流。
开发者怎么用
核心流程大致是这四步：

1. 启动 app-server
   把 Codex 作为服务进程拉起来，它会监听你的请求。这时候它不是跑完一条命令就退出，而是一直常驻。
2. 通过 JSON-RPC 建会话
   JSON-RPC 是一套标准的远程调用协议，你发一个 JSON 请求，它回一个 JSON 响应。你用代码告诉 app-server：“给我开一个新会话，工作目录在某个项目下”——它就给你创建一个独立的上下文环境。
3. 派任务、收结果
   会话建好后，你可以往里面塞任务，比如"修这个文件的 bug"“跑一下测试”“重构这个函数”。app-server 会在沙箱里执行命令、调用工具、管理对话状态，然后流式返回结果给你。你不用管中间怎么调度的，只管收活。
4. 多会话并行管理
   这是 app-server 最有价值的地方——你可以同时开多个会话，每个会话独立工作。比如一个会话在写新功能，另一个在修 bug，第三个在跑 lint。相当于你自己编排了一个"AI 工人小组"。
   它为什么重要
   OpenAI 自己内部的 Symphony 系统（就是那个让 agent 从工单系统自动拉活干、合并 PR 数量涨 500% 的方案）就是构建在 app-server 这层之上的。
   这意味着什么？​OpenAI 把自己内部搞自动化的那套基础设施直接开源了。​ 你拿到手的不只是一个"能跑代码的 AI"，而是"能被你当成后端服务来编排的 AI 基础设施"。

对比一下三层的能力边界：
exec SDK app-server
调用方式 命令行一次性执行 代码内 API 调用 常驻服务，JSON-RPC 通信
状态管理 无状态 可编排多步骤 持久会话，多会话并行
适用场景 CI 脚本自动化 自定义 agent 工作流 做成产品级服务
典型使用者 运维/CI 配置 应用开发者 平台/产品构建者
实际使用场景举几个例子
做自己的 AI Code Review 服务​：app-server 常驻，每次有 PR 提交就自动触发一个会话去审查、给意见。
做团队级 AI 编程助手​：多个开发者共享一个 app-server，各自开自己的会话，互不干扰。
搭一套类似 Symphony 的自动化流水线​：对接你的工单系统，让 agent 自己拉活、干完等验收。
简单说，app-server 是这次开源里最硬核的一层​，它把 Codex 从"开发者工具"升级成了"可以被你嵌入产品的 AI 后端引擎"。OpenAI 自己怎么用这套东西搞内部自动化，现在全摊开给你看了——能不能复刻，就看你的工程能力了。

"用 CLI 自己搭"和"app-server 原生支持"差在哪

CLI 搭的话，你得自己解决这些问题：

1. 状态管理——谁来管？

CLI 是无状态的：跑完一次，上下文就没了。你要维持会话，就得自己搞一套状态存储——记住上次对话到哪了、执行了什么命令、结果是什么、沙箱环境是什么状态。

app-server 天生就管这些：会话是持久化的，上下文保留在服务进程里，你不用操心。

2. 并发——同时多个任务怎么办？

你想让多个 agent 同时干活，用 CLI 的话得自己起多个进程、管理进程间通信、避免资源冲突（比如同时改同一个文件）。

app-server 原生支持多会话并行，每个会话独立沙箱，互不干扰——这套并发管理和隔离机制，自己从零搭非常容易踩坑。

3. 沙箱安全——agent 跑危险命令谁拦着？

CLI 的安全审批机制依赖交互式终端——它停下来问你"这个操作危险，要不要继续？"。但你做成后台服务后，没有人在终端前面坐着。

app-server 把这套安全策略内置在了服务层，什么能自动执行、什么需要人工确认，都有一套成熟机制。你自己搭的话，这块是最容易出安全事故的。

4. 流式输出——结果怎么实时返回？

CLI 的输出是往终端打印的。你要做成服务，就得自己把输出捕获、转成流式 JSON、通过某种协议推给你的前端或下游。

app-server 直接用 JSON-RPC 标准协议流式返回，你对接就行了。

一句话对比

	用 CLI 自己搭	app-server 原生
状态管理	自己造轮子	内置持久会话
多任务并行	自己管进程和隔离	原生多会话沙箱
安全审批	自己实现策略层	内置安全机制
输出协议	自己抓终端输出做转换	JSON-RPC 标准流式
稳定性	你来背锅	OpenAI 已经趟过坑

说白了，CLI 是给你"手动用"的，app-server 是给你"做成产品"的。

你确实可以用 CLI 包一层壳子硬搭出来，但你要重新实现的那套东西——状态持久化、并发隔离、安全策略、流式协议——恰恰是 OpenAI 内部已经踩过无数坑、打磨过的核心工程。harness 开源的价值就在于：这些"看似能用 CLI 模拟"的东西，真要从零做到生产级稳定，投入的成本远比你想象的大。

当然，如果你只是自己玩、跑跑小场景，CLI 包一层确实够用。但要做产品级的 AI 编程服务，app-server 帮你省掉的工程量是巨大的。

OpenClaw 和 Codex app-server

OpenClaw 的"app-server"早就有了，但思路不同

OpenClaw 是一个本地优先的 AI Agent 网关（Gateway），它从出生开始就自带一个常驻服务进程——叫 Gateway Server。这个 Gateway 默认监听 ws://127.0.0.1:18789，本质上就是 OpenClaw 版的"app-server"：

	Codex app-server	OpenClaw Gateway
本质	Codex 的常驻服务进程	OpenClaw 的常驻服务进程
协议	JSON-RPC	WebSocket + JSON-RPC
核心能力	起会话、派任务、收结果	会话路由、工具调度、多渠道接入
并发管理	多会话并行	多会话串行 + 全局并发池
状态持久化	会话 thread + turn	SQLite + Markdown 记忆文件

所以OpenClaw 不需要再单独开源一个 app-server——它的 Gateway 本身就是。从第一天起，OpenClaw 的设计就是一个 24×7 常驻运行的服务进程，而不是"先有 CLI，再补 app-server"的路线。

两者的设计哲学差异很大

虽然都是"常驻服务"，但侧重点完全不同：

Codex app-server：面向编程场景的 agent 运行时
• 核心是管理 coding agent 的执行生命周期：thread（会话线程）、turn（执行轮次）、sandbox（沙箱）、approval（审批）、tools（工具集）
• 偏向被嵌入到你的产品里，作为后端引擎
• 接口是 JSON-RPC，适合程序化编排

OpenClaw Gateway：面向个人助手场景的网关
• 核心是连接一切：接 Telegram、WhatsApp、飞书、Slack 等十几个聊天渠道，所有消息路由到同一个 Agent
• 内置心跳机制（Heartbeat），每 30 分钟主动醒来检查有没有活要干
• 有完整的记忆系统（MEMORY.md 长期记忆 + 日志文件 + SQLite 检索）
• 还能反过来调用 Codex app-server 作为自己的 backend——当你选 GPT 模型时，OpenClaw Gateway 会通过 stdin/stdout 和 Codex app-server 做 RPC 通信，把它当成一个 agent runtime 来用

一句话总结

Codex 的 app-server 是"把编程 agent 做成服务"；OpenClaw 的 Gateway 是"把个人助手做成服务"，而且后者还能把前者当插件调。

两者不是同一个赛道的东西。OpenClaw 的 Gateway 从一开始就是常驻服务架构，不存在"先开源 CLI 再开源 app-server"的递进关系——它一开始就全给你了。