QT与Python跨语言通信：基于UDP的QUdpSocket与Socket实战解析
2026/10/24 7:12:32
【Codex with ChatGPT 源码学习①】整体架构：为什么要分离控制平面与数据平面？
系列说明：本文是对社区开源项目 XiaoDuoYa/codex-with-chatgpt 的技术解读，非 OpenAI 官方教程、非该项目维护者发布的文档。研究基于 2026-10-22 可访问的
main分支；分支内容会变化，建议阅读时核对具体 commit。
证据标记：[源码]表示能从对应源文件确认；[文档]是项目约定；[推断]为技术分析；[建议]为改进方案，不能误当作已经实现的能力。文中命令和请求示例若未专门注明，均为教学示例，并非实际执行结果。
推荐 CSDN 标签：AI AgentCodexChatGPTMCP软件架构
摘要：从组件图和一次开发任务的时序入手，解释 Codex、ChatGPT、Skill、内置浏览器、MCP Bridge 与 Workspace 的关系，认识 Control Plane / Data Plane 的分离设计。
1. 不要把它理解成“ChatGPT 嵌入 Codex 模型”
[文档] 项目的基本分工：Codex 执行编辑、命令、Git 与测试；ChatGPT 负责规划、分析和审查。ChatGPT 通过浏览器网页访问云端模型；Codex 使用自己的浏览器工具与该页面交互。两边仍是不同的运行时。
这种连接分为两条链路：
- 控制平面（Control Plane）：Codex 在 ChatGPT 网页发送
[C2C]格式的简短消息，读取 PLAN、DONE 等回复。 - 数据平面（Data Plane）：ChatGPT 通过远程 MCP 请求文件、目录、Git Diff 和执行证据；不要求 Codex 每轮粘贴整个文件。
2. 逐个认识组件
| 组件 | 是否是独立程序 | 核心职责 |
|---|---|---|
| Codex | Agent 及其执行运行时 | 编辑、Shell、Git、测试、调用浏览器 |
skill/SKILL.md | 否，指令文本 | 约定何时连接、如何发消息、如何恢复 |
In-App Browser（iab） | 浏览器控制接口 | 操作 ChatGPT 网页会话 |
| ChatGPT | 云端服务 | 给出计划、审查意见 |
| C2C Bridge | Node.js 服务 | OAuth、MCP、路径限制与只读工具 |
| Workspace | 磁盘工程目录 | 源码和 Git 状态 |
[源码]docs/architecture.md将mcp/、auth/、pairing/、workspace/、tunnel/、execution/、process/、cli/分层。工具端使用 TypeScript、Express 和 MCP SDK。
其中最容易混淆的是 Skill 和 Bridge。
Skill 不是一个独立运行的程序
skill/SKILL.md 本质是一份结构化行为指令。Codex 读取它后，按照其中的步骤组织任务。
它本身不会启动模型，也不是 HTTP 服务。
Bridge 才是真正运行的服务程序
Bridge 是 Node.js/TypeScript 编写的软件，监听本地端口，处理认证、文件访问和 MCP 请求。
所以整个项目是两类技术结合：
- 提示词/Agent 编排层：Skill、消息协议、状态转换。
- 传统软件工程层：Node.js 服务、HTTP、OAuth、文件系统、Git、网络隧道。
这也解释了为什么项目既有 .md 指令文件，又有大量 .ts 源代码。
3. 最重要的两条通信通道
这是整套架构的核心。
为什么要区分两条通道？
假设你要求开发一个登录模块，工作区里有 300 个文件。
如果没有 MCP，Codex 可能需要把相关源码、差异和测试日志全部粘贴进聊天中。
有了 MCP，Codex 只需要告诉 ChatGPT：
[C2C] task_id: login-001 phase: PLAN 请分析当前工程，实现用户登录功能。ChatGPT 再自行调用：
list_directory("src") read_file("src/auth.ts") search_workspace("login")这里的工具调用只是说明工作机制的示意，并非仓库的精确请求 JSON。
控制信息走浏览器，工程数据走 MCP。 两者分离后，可以减小浏览器交互中传递的消息体积，也便于单独管理文件访问权限。
4. 哪个组件掌握真正的执行权？
从权限角度理解架构，比只看通信连接更重要。
| 操作 | Codex | ChatGPT（经 C2C MCP） |
|---|---|---|
| 阅读源码 | 可以 | 可以，受权限约束 |
| 搜索源码 | 可以 | 可以，受权限约束 |
| 读取 Git Diff | 可以 | 可以 |
| 修改文件 | 可以 | 不可以 |
| 执行终端命令 | 可以 | 不可以 |
| 运行测试 | 可以 | 只能读取记录 |
| 决定开发步骤 | 可以 | 提供规划和审查意见 |
| 控制 ChatGPT 浏览器会话 | 可以 | 不承担此职责 |
仓库文档明确规定 V1 Bridge 不包含写文件或执行命令的 MCP 工具，并采用一个 Bridge 对应一个 Workspace 的隔离原则。
这说明 ChatGPT 的“规划与审查”是一种角色分工，而不是系统内核级别的主从关系。
Codex 仍然保留真正的工程执行权。
5. 一次真实任务在架构上怎样走？
以“为一个 Python 小程序添加 CSV 导出”为教学示例：
- 用户向 Codex 提需求；Codex 按 Skill 选择协作流程。
- Codex 通过浏览器发
STATE: INIT和目标。 - ChatGPT 通过 MCP 读取指定 Workspace 的相关文件。
- ChatGPT 发出
STATE: PLAN；Codex 接收计划。 - Codex 编辑文件、运行测试、记录结果。
- Codex 发
STATE: EXECUTED，不粘贴整个日志。 - ChatGPT 用 MCP 审查实际 Diff、测试记录，返回
PLAN（下一轮）、DONE或BLOCKED。
这是[文档]规定的目标流程；网页、网络、模型输出都可能失败，不能当作原子事务。
6. 最容易混淆的四件事
第一，浏览器是 ChatGPT 云服务的前端，不是本地模型进程。
第二，Skill 不是脚本解释器，真实工具调用由 Codex 执行。
第三，MCP 默认只读，是指此 Bridge 的工具接口不提供写入；Codex 自己仍拥有编辑能力。
第四，只读并不意味着数据不出本机。远程 MCP 返回的片段会被发送给 ChatGPT 服务。
7. 为什么这样分工？
把聊天消息缩小为任务指令，有利于降低每轮复制源码的负担；MCP 可以按需提供最新文件。独立审查实际 Diff，则减少 Codex “自说自话”的情况。但浏览器控制有 UI 变化风险，独立模型审查也不等于形式化验证。
8. 本章小结
请记住一个公式：Codex（执行）+ ChatGPT（规划/审查）+ 浏览器（控制）+ MCP（数据）+ Bridge（权限）。下一篇我们将进入SKILL.md，看看 Markdown 怎样约束 Codex 的行为。
源码阅读：架构文档 · 协议
版权与引用：本文为独立整理与分析，引用项目名称、接口名称和少量必要代码片段以解释技术原理；原项目的代码许可证为 MIT。本文不代表原作者或 OpenAI 的立场。转载请保留原项目地址及本文出处。
系列导航：参见同一系列的「导读」及其他章节。
ChatGPT 负责思考，Codex 负责干活？从源码读懂 Codex with ChatGPT（系列导读）