8月24日，OpenAI在Codex Release Notes里放了一条不算长的更新：

codex mcp-server 命令正式被标记为 deprecated，官方建议改用Codex App Server。

另外，如果以前是在Claude Code里通过MCP方式调用Codex，OpenAI现在给出的建议是直接使用 Codex plugin for Claude Code。

这条更新很短，但背后的变化值得聊一下。

因为它不是简单的：

旧命令
↓
换一个新命令

更像是OpenAI开始明确：

以后要把完整Codex能力嵌进IDE、桌面应用或者自己的Agent产品，App Server才是主要接口。

先把一个容易误解的地方说清楚。

一、不是MCP被OpenAI淘汰了

看到mcp-server deprecated，很容易理解成：

OpenAI不用MCP了？

不是。

MCP在Codex里仍然存在。

Codex本身依旧可以连接MCP Server，OpenAI的开发者页面也还在把MCP、Skills等作为Codex扩展能力的一部分。

变化的是另一件事：

以前你可以运行：

codex mcp-server

把整个Codex包装成一个MCP Server，再让其他MCP Client把Codex当成一个Tool调用。

现在OpenAI不准备继续把这种方式作为主要集成路线了。

这两件事不要混在一起。

简单说：

Codex调用MCP工具
→ 仍然存在

把Codex本身做成MCP Server
→ codex mcp-server开始退出

---

二、为什么OpenAI觉得MCP不太适合完整Codex？

这个问题OpenAI其实早就解释过。

今年2月，OpenAI在介绍App Server架构时提到，他们最早做VS Code扩展时，确实试过把Codex直接暴露成MCP Server。

后来发现不太顺手。

原因不是MCP不好，而是Codex的交互比普通Tool Call复杂得多。

普通MCP工具调用，很容易理解：

输入参数
↓
调用工具
↓
返回结果

比如：

查数据库
读取文件
搜索网页

Codex不是一次请求结束。

你给它一句：

修复这个项目的登录Bug，然后跑测试。

后面可能发生：

读取项目
↓
搜索代码
↓
修改文件
↓
输出diff
↓
请求执行命令
↓
等待用户批准
↓
运行测试
↓
测试失败
↓
继续修改
↓
再次测试
↓
完成

这中间有大量状态。

还需要处理：

• 对话Thread；
• 多轮Turn；
• 工具执行；
• 流式进度；
• 文件Diff；
• 用户审批；
• 中断和恢复；
• 登录状态；
• 配置；
• 多Agent并行。

MCP当然可以封装其中一部分。

问题是，当你想把完整Codex体验塞进去时，就比较容易遇到协议能力和Codex自身语义之间的映射问题。

OpenAI自己给出的说法也很直接：通过MCP调用Codex比较适合“把Codex当成一个可调用工具”，但像Diff更新这类Codex专有交互，并不容易完整映射到MCP接口。

这就是App Server出现的原因。

---

三、App Server到底是什么？

不要被Server这个名字吓到。

可以把它理解成：

Codex核心Agent和外部应用之间的一层标准通信接口。

Codex现在有很多入口：

Codex CLI
Codex Desktop
VS Code
Codex Web
第三方IDE
自己的Agent产品

这些产品不应该每一个都重新实现一次Codex的Agent逻辑。

OpenAI把真正负责：

模型
+
Agent Loop
+
工具
+
线程
+
配置
+
权限

的部分放在Codex Core里。

App Server负责把这些能力提供给外部客户端。

架构大概可以理解成：

IDE / Desktop / 自己的应用
            ↓
       App Server
            ↓
       Codex Core
            ↓
 Model + Tools + MCP + Skills

OpenAI目前把App Server定义为一个长期运行的进程 + 双向JSON-RPC接口。

---

四、为什么一定要“双向”？

这是App Server比较关键的地方。

普通API大部分是：

Client
→ Request
→ Server
→ Response

Agent不是这么简单。

例如Codex准备执行：

rm -rf build/

可能需要先问用户：

是否允许执行这个操作？

这时候Server本身要主动向Client发请求。

流程会变成：

Client发送任务
↓
Codex开始执行
↓
Server持续推送进度
↓
Codex请求操作权限
↓
Client显示Allow / Deny
↓
用户确认
↓
Codex继续执行

OpenAI的App Server支持这种双向通信。

官方现在把交互拆成三个比较核心的概念：

Thread
Turn
Item

Thread

一整个持续的Codex会话。

可以：

创建
恢复
Fork
归档

Turn

用户发起的一次任务。

比如：

“跑测试，然后把失败原因告诉我。”

从开始执行到本轮结束，就是一个Turn。

Item

Turn里面的具体事件。

例如：

用户消息
Agent消息
工具调用
审批请求
Diff

每一个Item还可以继续产生流式更新。

这种设计明显更适合Agent UI。

---

五、MCP和App Server其实解决的不是同一个问题

可以简单看这个表：

场景	MCP	Codex App Server
给Agent增加工具	很适合	不是主要用途
调数据库/搜索/文件系统	很适合	不需要专门用它
把Codex当一个工具调用	可以	可以
做完整Codex IDE体验	能力有限	更适合
实时Diff	不够自然	支持
Approval交互	有局限	原生支持
Thread状态	通用能力有限	Codex原生
长时间Agent任务	取决于实现	专门设计
多Agent客户端	较复杂	更合适

所以OpenAI这次调整其实挺合理。

MCP继续负责“Agent怎么连接外部工具”。

App Server负责“客户端怎么控制完整的Codex Agent”。

两者不是非此即彼。

---

一个更直观的例子

假设你正在开发一个自己的AI代码Review工具。

需求是：

1. 用户选择Git仓库；
2. Codex读取代码；
3. 自动Review；
4. 页面实时显示进度；
5. 找到问题后展示Diff；
6. 修改文件前弹窗让用户批准；
7. 用户关闭页面以后任务继续；
8. 下次回来还能恢复任务。

如果只把Codex当成：

MCP Tool

你会发现很多东西需要自己补。

而App Server本身已经围绕这些交互设计。

比如OpenAI的Codex Web就是让App Server在容器里长期运行，浏览器关闭以后，任务状态仍然可以保留；重新连接时继续恢复Thread。

这才是App Server真正有价值的地方。

---

六、App Server怎么接？

如果只是普通Codex用户，其实不用因为这次更新做什么。

主要受影响的是：

• 自己集成Codex的开发者；
• 用codex mcp-server做二次开发的项目；
• IDE开发者；
• Agent平台开发者。

OpenAI当前的App Server使用JSON-RPC over stdio。

TypeScript可以生成类型定义：

codex app-server generate-ts

其他语言可以生成JSON Schema：

codex app-server generate-json-schema

OpenAI目前已经提到，相关客户端实现覆盖Go、Python、TypeScript、Swift、Kotlin等语言。

如果需要做完整集成，官方现在明确建议：

优先：
Codex App Server

如果只是CI里跑一次Codex任务，则还有更轻量的：

Codex Exec

如果是TypeScript程序里直接控制本地Codex Agent，也可以继续看：

Codex SDK

并不是所有场景都必须上App Server。

---

七、已经用了 mcp-server，现在需要马上改吗？

deprecated和removed不是一回事。

截至8月24日，官方表述是：

codex mcp-server已经弃用，推荐使用App Server。

所以现有项目不需要看到公告就立刻重写。

更实际的做法是先看自己属于哪种情况。

只是把Codex当工具调用

例如：

主Agent
↓
调用Codex
↓
让它Review一次代码
↓
拿结果

这种架构没有很强的交互需求。

可以先评估迁移成本。

正在做IDE或完整Agent产品

如果需要：

流式状态
Diff
Approval
Thread恢复
长期任务
配置和登录

那就比较建议开始往App Server迁移。

因为OpenAI已经明确说了，App Server会是后续维护的first-class integration method。

---

八、这次变化还透露出一个趋势

我觉得这件事真正值得注意的，其实不只是MCP。

过去一年大家很喜欢说：

MCP会不会统一所有Agent？

现在看下来，我觉得没那么简单。

MCP非常适合：

Agent ↔ Tool

但Agent本身越来越复杂以后，又需要：

Client ↔ Agent Runtime

这里会涉及状态、审批、流式事件、任务恢复、身份和UI。

这些东西不一定都适合塞进一个通用Tool协议。

所以未来很可能是几层东西共存：

App Server / Agent Runtime Protocol
↓
负责Agent生命周期

MCP
↓
负责工具连接

Skills / Plugins
↓
负责能力封装和复用

而不是一个协议包打天下。

---

九、企业项目还要多考虑一层：成本和账号怎么拆

真正做多Agent或者多模型系统以后，还有一个很现实的问题：

Codex
Claude
Gemini
其他API
海外开发工具

很容易同时出现在一个项目里。

技术侧一般会做：

模型路由
API Key隔离
调用限额
日志和审计

付款层最好也保持类似思路。

比如测试环境、正式环境、不同AI服务分别设置预算，不要全部混在一个付款渠道里。

如果本身使用MXK8虚拟卡这类方案，也可以考虑按照AI平台或项目拆分费用卡，主要用于海外AI工具付款、项目费用归集和额度管理。

实际绑定前还是要看具体平台当时接受的付款方式、卡类型、地区和Billing要求。

虚拟卡解决的是付款管理问题，不替代API本身的Usage Limit、权限控制和Agent预算。

---

写在最后

codex mcp-server被弃用，并不代表MCP失去价值。

更准确的理解应该是：

OpenAI发现“把Codex当一个MCP工具”不足以完整表达一个现代Coding Agent，于是开始把App Server作为完整Agent集成的主接口。

以后可能会越来越清楚：

MCP负责连接工具

App Server负责运行Agent

Plugin / Skill负责封装能力

从开发者角度看，这其实是一件好事。

以前所有Agent相关能力都往MCP里塞，看起来统一，做复杂产品时反而容易别扭。

现在开始把：

工具协议、Agent运行时、插件能力

拆开，各自解决自己的问题。

Codex这次弃用mcp-server，更像是Agent基础设施开始进入第二阶段，而不是MCP退场。