Electrolux_blog01 — 仓库与架构总览
Codex 在本仓库中的定位
根 README 说明：Codex CLI 是运行在用户本机的 coding agent，可通过 npm、brew 或 Release 二进制安装。同一产品族还包括 IDE 扩展、桌面应用与云端形态；本仓库主要承载 CLI / 核心引擎 / 协议与部分 SDK。
从工程师视角，可以把本仓库理解为：
- 一个 Rust 单体工作区（
codex-rs/）实现 agent 核心逻辑、终端 UI、应用服务器、沙箱辅助进程等； - 一个「薄」的 Node 发布层（
codex-cli/等）用于 npm 分发； - 多语言 SDK（如
sdk/typescript、sdk/python）消费 app-server 或 HTTP API。
顶层目录速览
| 路径 | 作用 |
|---|---|
codex-rs/ | 主 Rust workspace，业务逻辑、TUI、app-server、exec、沙箱、协议类型等 |
codex-cli/ | CLI 相关脚本与说明 |
docs/ | 用户向与部分实现向文档（不少条目指向官网文档） |
.codex/skills/ | 仓库内示例/工具类 skill |
sdk/ | 多语言客户端示例与 API 文档 |
核心运行时链路（概念）
- 入口：
codex-rs/cli解析子命令；默认无子命令时进入交互 TUI 或把参数交给 exec 路径。 - 会话：
codex-core中的Codex/CodexThread持有会话状态，通过Op提交用户回合与系统操作。 - 模型：
ModelClient/ModelClientSession负责与 OpenAI Responses 等上游通信（含 WebSocket 预连接等优化）。 - 工具：shell、apply_patch、MCP 工具等经统一执行与安全策略层落地。
- UI / 集成：TUI 订阅事件流；app-server 以 JSON-RPC 向 VS Code 等客户端推送同样语义的事件。
设计动机：为何「核心」与「界面」分离
codex-protocol 的 README 写明：该 crate 定义 CLI 内部类型以及对外 app-server 类型，依赖应尽量少、避免把业务逻辑塞进协议层。
codex-core 的 README 则强调 跨平台沙箱假设（macOS Seatbelt、Linux bubblewrap/Landlock、Windows 多种后端），说明核心层直接承担 安全与可移植性 的复杂度，而 UI 只负责呈现与收集用户输入。
这种拆分的简明表述可以是：
- 协议稳定、实现迭代：UI 换皮或新增 IDE 客户端时，不反复改动核心状态机。
- 测试与模拟：协议类型 +
core的test_support便于端到端测试挂载假 SSE/WS。 - 安全边界清晰：沙箱与审批在 core 统一裁决，避免每个 UI 各自实现一套。
与「前端工程师」的关联点
- JSON-RPC + 事件流：与 IDE/LSP 类架构同源，适合用「语言服务器 / DAP」经验类比。
- 终端 UI（ratatui）：渲染性能、键盘路由、流式文本分块，对应 Web 的虚拟列表与 rAF 节流。
- 结构化配置与 schema：
config.schema.json、app-server 的 TS/JSON Schema 生成，对应前端的类型安全配置层。