Codex CLI 架构解析：四层堆栈与事件驱动Agent设计范式

1. 为什么说 Codex CLI 是当前最值得深挖的 Coding Agent 架构样本“openai/codex88k Stars 的开源 Coding Agent 完整架构”——这个标题里藏着一个被多数人忽略的关键事实它不是一份“能跑就行”的玩具 Demo而是一套经过生产环境千锤百炼、由 OpenAI 工程师亲手打磨、并完整开源的Agent 系统级设计范本。我第一次在 GitHub 上点开codex-rs仓库时看到那 4547 次 commit 和 Apache 2.0 协议第一反应不是“哇又一个 CLI 工具”而是“这玩意儿的core/目录怕是能当 Rust Agent 开发的教科书来读”。你可能已经用过 VS Code 的 Codex 插件或者在终端里敲过codex run --file main.rs。但真正让它从“好用”跃升为“值得研究”的是它背后那套严丝合缝、层层解耦、每一层都带着明确工程取舍痕迹的四层堆栈。这不是把 prompt API 调用简单拼起来的脚手架而是一个把“人类如何与 AI 协同编程”这个抽象命题拆解成可落地、可验证、可替换的硬核模块的系统工程。它的核心价值不在于 Rust 代码本身虽然代码质量极高而在于它把 Agent Loop、Sandbox、App Server 这些听起来玄乎的概念变成了有边界、有接口、有 tradeoff 记录的实体组件。比如当你看到codex-rs/core/src/context_manager.rs里那一段自动触发 compaction 的逻辑时你看到的不是一个函数调用而是一个明确的工程决策我们选择让客户端承担 context 管理的复杂度以换取服务端零数据留存的确定性。这种决策在官方文档里不会写在 API Reference 里找不到但它就明明白白躺在源码注释和 commit message 里。更关键的是它解决了一个几乎所有自研 Agent 团队都会撞上的墙如何让同一个核心逻辑无缝适配 TUI、VS Code、JetBrains、macOS App、Web 甚至 XcodeCodex 没有为每个平台重写一遍 agent loop而是把core做成一个纯 Rust 库只通过 async channel 和事件协议与外界通信。TUI 是它的消费者VS Code 插件是它的消费者Web 前端也是它的消费者。这种“核心归核心界面归界面”的解耦直接把跨平台复用成本砍掉了 70% 以上。我去年帮一个团队重构内部代码助手时光是统一不同 IDE 插件的 prompt 组装逻辑就花了三周而 Codex 的AGENTS.md层级加载机制三行配置就解决了。所以如果你正在评估是否要基于某个开源 Agent 二次开发或者正纠结于该自己从零造轮子还是找现成方案Codex CLI 的价值就在这里它不是给你一个“能用的轮子”而是给你一套轮子该怎么设计、各部件怎么咬合、出问题时该往哪层查的完整图纸。它不教你“怎么调 OpenAI API”它教你“怎么设计一个能活过三年迭代的 Agent 系统”。这才是那 88k Stars 真正买账的地方——不是因为它是 OpenAI 出的而是因为它把最难啃的工程骨头嚼碎了喂给你。提示别被“Rust”吓退。Codex 的最大启示不在语言层面而在架构分层逻辑。即使你团队主攻 Python 或 TypeScriptThread/Turn/Item的三层协议、system prompt AGENTS.md Skills的 prompt 组装层级、read-only/workspace-write/danger-full-access的沙箱权限模型这些设计思想完全可平移。语言只是实现载体分层才是灵魂。2. 四层堆栈Codex 架构的物理边界与责任划分Codex CLI 的架构不是凭空画出来的 UML 图而是由真实生产需求倒逼出来的四层物理堆栈。每一层都有清晰的职责边界、明确的输入输出契约以及不容妥协的工程约束。理解这四层是读懂整个系统的第一把钥匙。2.1 表面层Surface Layer同一核心多种形态表面层是用户直接接触的部分它不包含任何 agent 核心逻辑纯粹是core的“皮肤”。它的存在意义只有一个让同一个codex-rs/core库能以不同形态接入不同宿主环境。这里没有魔法只有严格的接口约定TUI终端界面最轻量的实现通过std::io读取键盘输入将Op::UserInput发送到 submission channel接收Event::TextChunk或Event::ToolCallResult后直接渲染到终端。它不关心 session 状态持久化也不处理复杂的 diff 渲染。App Server应用服务器这是最关键的表面层实现。它暴露一个 JSON-RPC 双向协议供 VS Code、JetBrains、Xcode 等 IDE 插件调用。它负责管理Thread的生命周期创建、恢复、fork、归档将 IDE 的编辑操作如文件保存、光标移动翻译成Item::FileEdit事件再推送给 core。MCP ServerModel Control Protocol 服务器专为与其他 Agent 交互设计。它把 Codex 自身当作一个 tool provider暴露标准 MCP 接口。当另一个 Agent 需要调用 “执行 shell 命令” 或 “编辑文件” 时它就是后端。SDK软件开发工具包面向 CI/CD 流水线或自动化脚本。提供codex_sdk::run()这样的高层 API隐藏所有 channel 和事件细节只返回ResultExecutionOutput。它甚至不启动 TUI纯后台运行。这四者共享同一个core但交互模式天差地别。TUI 用 stdin/stdoutApp Server 用 JSON-RPC over STDIO 或 Streaming HTTPMCP Server 用 gRPCSDK 用 Rust 函数调用。它们唯一的共同点是都遵循core定义的SubmissionChannel和EventChannel协议。这种设计意味着你今天给 VS Code 写的插件明天想移植到 Emacs只需重写一个符合 JSON-RPC 协议的 clientcore 逻辑一行不用动。2.2 会话层Session Layer状态管理与身份认证的中枢如果表面层是“脸”会话层就是“神经系统”。它不参与具体推理但掌控着所有状态流转、权限校验和上下文生命周期。Celia Chen 在她的博客中称之为 “the full agent experience beyond the core loop”意思是agent 的体验远不止于模型调用那一瞬间。这一层的核心实体是Thread。一个Thread就是一次完整的对话会话它被持久化存储默认在$CODEX_HOME/threads/包含完整事件历史从第一个Op::UserInput到最后一个Event::TurnCompleted所有Item的完整序列。认证凭证ChatGPT OAuth token、GitHub Copilot token 或 Anthropic API key 的加密存储。它不把 token 明文传给 core只在需要时解密并注入请求头。配置快照当前Thread启动时所用的profile如fast或careful、model_provider、sandbox_mode等设置。Thread的关键能力在于断点续传。当你在 VS Code 里写到一半关机第二天打开 IDEApp Server 会从磁盘加载上次的Thread恢复所有未完成的Item比如一个正在执行的git diff并继续推送Event::ProgressUpdate。这种能力不是靠“记住最后一行 prompt”实现的而是靠Thread对Item生命周期的精确建模每个Item都有Started → InProgress → Completed/Failed的状态机Thread持久化的是这个状态机的当前节点。会话层还负责多租户隔离。Thread之间完全独立一个Thread的 sandbox 权限、API key、甚至 model provider 都不影响另一个。这使得 Codex 能安全地同时为多个项目、多个用户、甚至多个客户在企业版中服务而无需担心状态污染。2.3 核心层Core LayerAgent Loop 的心脏地带codex-rs/core/目录就是整个系统的绝对心脏。它是一个纯 Rust 库不依赖任何网络框架、不绑定特定 UI、不处理文件系统权限——它只做一件事执行一个严格定义的、事件驱动的 Agent Loop。它的入口是session::run()出口是两条异步 channel一条收Op操作一条发Event事件。这个 Loop 的精妙之处在于它的三层嵌套结构而非简单的 while 循环最外层submission_loop这是一个永不停止的循环监听SubmissionChannel。它只做两件事接收Op如UserInput,UserTurn,Shutdown然后根据类型分发给 handler。它不关心Op具体内容只做路由。Op::Shutdown是唯一能终止它的信号。中间层handlers::user_input_or_turn当submission_loop收到Op::UserInput时它启动这个 handler。handler 的任务是初始化一个新的Turn并启动内层循环。它不处理模型响应只负责“开始一轮对话”。最内层turn_loop这才是真正干活的循环。它执行一个原子性的“单轮对话”组装 Prompt从AGENTS.md、Skills、当前文件树、Git 状态、历史对话中提取信息拼成一个不超过 32 KiB 的 prompt。调用 API向 Responses API 发送流式请求监听text_chunk、function_call、error等事件。处理响应如果是text_chunk直接发Event::TextChunk如果是function_call则解析参数匹配到对应Tool执行Tool::execute()并将结果拼回 prompt再发起下一次 API 调用。判定结束当模型返回纯assistant_message无function_call时认为本轮结束发Event::TurnCompleted。这个设计的关键在于turn_loop的执行次数没有硬性上限。一个Turn内Agent 可以执行 5 次shell命令、3 次file_edit、2 次mcp_tool_call直到它自己认为任务完成。这彻底摆脱了传统 LLM 应用“一问一答”的僵化模式实现了真正的“自主规划-执行-反思”闭环。2.4 执行层Execution Layer安全沙箱与真实世界的桥梁核心层决定“做什么”执行层决定“怎么做”以及“能不能做”。它把core的抽象指令如ToolCall { name: shell, args: [git, status] }翻译成操作系统层面的真实动作并施加铁腕安全控制。执行层的两大支柱是Sandbox沙箱这是 Codex 与 Claude Code 最根本的差异。Codex 在内核层面拦截 syscallClaude Code 在应用层 hook 进程。Codex 的沙箱基于macOSSeatbelt沙箱配置文件精确控制进程能访问哪些路径、能否联网、能否 fork 子进程。LinuxLandlock强制访问控制 seccomp系统调用过滤直接在内核态禁止openat、connect、execve等危险调用。WindowsJob ObjectsWin32 API权限限制文档较少但原理一致。沙箱权限被抽象为三个预设模式read-only只读文件系统、workspace-write可写当前项目目录、danger-full-access完全开放。danger-full-access不是后门而是为极少数场景如调试时需要curl下载依赖设计的显式开关必须在config.toml中手动启用并伴随严重警告。Tool Execution工具执行执行层定义了所有内置工具的实现shell在沙箱内启动受限 shell执行命令捕获 stdout/stderr。file_edit解析 diff安全地修改文件内容确保不越界写入。mcp_client作为 MCP client调用外部 MCP server如 Jira、Figma 的 MCP 实现。builtin_tools如list_files、read_file这些是core直接调用的不经过沙箱因为它们只读取元数据。执行层与核心层的边界极其清晰core只知道Tool::execute()返回ResultString执行层负责确保这个execute()调用在沙箱内安全完成并处理所有底层异常如PermissionDenied、ConnectionRefused。这种隔离让core可以专注逻辑执行层可以专注安全。注意MCP Server是个特例。它作为 child process 在沙箱外启动因此不受沙箱保护。Codex 文档明确指出“Only built-in tools are sandboxed; MCP tools must secure themselves.” 这意味着如果你集成一个不可信的第三方 MCP server它理论上可以绕过 Codex 的沙箱。这是设计上的主动取舍而非漏洞。3. Agent Loop事件驱动的三层状态机与无界执行Agent Loop 是 Codex 的灵魂但它绝非教科书上那个简单的“Prompt → LLM → Parse → Execute → Repeat”流程图。它是一个精密的、事件驱动的三层状态机其设计哲学是让 Agent 拥有与人类程序员同等的“工作节奏”和“决策自由度”。理解它是理解 Codex 为何能写出高质量代码的关键。3.1 双 Channel 架构天然的异步解耦Codex Loop 的基石是两条独立的异步 channel这是它实现高响应性和长任务执行能力的根本Submission Channel提交通道单向从表面层TUI/IDE流向session。它传输的是OpOperation枚举包括Op::UserInput(String)用户在终端敲下的文字。Op::UserTurn(VecItem)IDE 发来的批量操作如“保存文件 A然后在文件 B 第 10 行插入代码”。Op::Shutdown优雅关闭信号。Op::Interrupt用户按下 CtrlC要求中断当前Turn。Event Channel事件通道单向从session流向表面层。它传输的是Event枚举包括Event::TextChunk(String)模型流式输出的文本片段。Event::ToolCall(ToolCall)模型决定调用工具附带参数。Event::ToolCallResult(ToolCall, ResultString)工具执行完毕返回结果。Event::Error(String)任何环节发生的错误。Event::TurnCompleted本轮对话结束。这两条 channel 的分离带来了两个革命性效果用户永不阻塞当turn_loop正在执行一个耗时的shell命令如cargo build时用户依然可以在 TUI 里输入Op::Interrupt这个操作会立刻被submission_loop捕获并通知turn_loop中断当前Tool::execute()。用户感觉不到卡顿。Agent 永不等待turn_loop在等待Tool::execute()返回时不会阻塞整个 loop。它通过tokio::spawn异步执行工具并在EventChannel上监听结果。这使得一个Turn内可以并发执行多个工具如同时read_file和list_files极大提升效率。3.2 三层嵌套循环从“开始”到“完成”的精细控制Codex Loop 的三层结构是对“一次有效编程交互”最真实的建模submission_loop宏观调度器它像一个永不疲倦的前台接待员。它不关心客人用户要办什么业务Op只负责把客人引导到正确的窗口handler。它的唯一退出条件是收到Op::Shutdown。它的存在保证了整个 agent 进程的长期存活和稳定路由。handlers::user_input_or_turn会话启动器当接待员收到“我要开户”Op::UserInput时它启动这个 handler。handler 的任务是创建一个新的Turn实例为其分配唯一 ID。将Turn的初始状态如当前文件路径、Git 分支注入context。启动turn_loop并将Turn的引用传递进去。 这个 handler 是“会话”的起点它把一次用户输入正式升级为一个有生命周期、有状态、可追踪的Turn。turn_loop微观执行引擎这是真正的“大脑”。它在一个Turn的生命周期内反复执行以下步骤直到模型返回终结信号loop { // 1. 组装 Prompt含最新 context let prompt assemble_prompt(turn_context).await?; // 2. 调用 API流式监听 let mut stream call_responses_api(prompt).await?; // 3. 逐块处理流式响应 while let Some(event) stream.next().await { match event { TextChunk(chunk) { send_event(Event::TextChunk(chunk)).await?; } FunctionCall(call) { // 解析 call找到对应 Tool let tool find_tool(call.name)?; // 异步执行不阻塞 loop tokio::spawn(async move { let result tool.execute(call.args).await; send_event(Event::ToolCallResult(call, result)).await; }); // 立即返回继续监听下一个 event break; } Error(e) { send_event(Event::Error(e)).await?; return Err(...); } } } // 4. 如果本轮没触发 ToolCall且收到终结消息则退出 if !has_pending_tool_calls() is_turn_complete() { send_event(Event::TurnCompleted).await?; break; } }关键洞察在于turn_loop的每一次迭代都可能触发一次新的 API 调用而这个新调用又可能再次触发FunctionCall形成递归式的“思考-行动”循环。一个Turn的深度完全由模型自身决定Codex 从不强行打断。这正是它能完成复杂任务如“重构整个模块添加单元测试并更新 README”的底层保障。3.3 Stateless 设计无状态 API 与客户端 Compaction 的权衡Codex 选择了一条激进的路线让 Responses API 调用完全无状态Stateless。这意味着每次请求core都会把整个对话历史messages数组原封不动地发给服务端而不是只发增量previous_response_id。这个决策背后有三个硬性理由简化服务端OpenAI 的 Responses API 服务端无需维护任何 session 状态降低了服务端的复杂度和故障点。对 OpenAI 而言这是一个巨大的运维收益。零数据留存Zero Data Retention服务端不存储任何用户数据。这对金融、医疗等强监管行业是刚需。core把所有状态保留在客户端内存或磁盘服务端只做“计算黑盒”。Provider-Agnostic任何实现了 Responses API 协议的 providerOllama、LM Studio、甚至自研模型服务都能被 Codex 直接接入无需 provider 侧做任何状态管理改造。但天下没有免费的午餐。Stateless 的代价是Token 消耗爆炸式增长。随着对话变长每次请求的messages数组越来越大很快就会触及模型的 context window 上限如 GPT-4 的 128K。Codex 的解决方案是客户端自动 Compaction触发时机当messages的 token 总数超过阈值默认 100K时context_manager模块自动触发 compaction。执行过程context_manager识别出哪些ToolCall和ToolCallResult是冗余的例如git status的输出已被后续git add操作覆盖。它调用一个专用的Compaction API EndpointPOST /v1/compact将需要压缩的历史片段发送过去。服务端目前仅 OpenAI 提供返回一个加密的content_item它包含了被压缩内容的语义摘要如 “已确认当前分支为 main暂存区有 3 个文件待提交”。context_manager将这个content_item替换掉原始的长文本保留在messages中。这个设计的精妙在于压缩后的content_item仍能被模型理解。当模型看到 “已确认当前分支为 main...”它能据此做出后续判断就像看到了原始的git status输出一样。这保证了压缩不损失关键信息只牺牲了细节。实操心得--oss模式对接 Ollama下Compaction 功能会失效因为 Ollama 没有/v1/compactendpoint。此时你需要手动在config.toml中调低compaction_threshold_tokens或接受更短的对话长度。这不是 bug而是 Stateless 设计的必然代价。4. Prompt 组装32 KiB 上限与路径层级注入的工程智慧Codex 的 prompt 组装机制是它区别于其他 Agent 工具的最显著特征之一。它不是把一堆 markdown 文本简单拼接而是一套基于文件系统路径、有严格大小上限、支持动态覆盖的层级注入系统。这套机制直接决定了 Agent 对项目上下文的理解深度。4.1 32 KiB 上限硬性约束催生的架构创新Codex 对单次 prompt 的大小设定了一个看似武断的硬性上限32 KiB约 8000 tokens。这个数字不是随意拍脑袋定的而是工程权衡的结果性能考量过大的 prompt 会导致 API 请求时间显著增加影响用户体验。成本考量token 消耗与费用直接挂钩32 KiB 是一个在“足够上下文”和“可控成本”之间的平衡点。可靠性考量超大 prompt 更容易触发模型的 attention 机制失效导致输出质量下降。这个上限直接催生了 Codex 最核心的架构创新AGENTS.md 的路径层级加载机制。它迫使开发者必须把信息“分散”到项目的各个目录中而不是堆砌在一个巨型文件里。4.2 路径层级注入从 Git Root 到 Current Dir 的精准上下文捕获Prompt 组装的过程是一场从项目根目录Git Root开始逐层向下扫描的“寻宝之旅”System Prompt系统提示硬编码在core里定义 Codex 的身份和能力边界。例如“You are Codex CLI, a terminal-based coding assistant. You can execute shell commands, edit files, and call tools. Output only valid JSON for tool calls.”Developer Instructions开发者指令来自$CODEX_HOME/config.toml中的developer_instructions字段。这是全局配置适用于所有项目。路径层级 AGENTS.md这是精华所在。Codex 从当前工作目录$PWD开始向上遍历到 Git Root依次读取每一层目录下的AGENTS.md和AGENTS.override.md/path/to/project/AGENTS.md项目级规范定义通用编码风格、CI/CD 流程、安全策略。/path/to/project/backend/AGENTS.md模块级规范定义 backend 模块特有的 API 规范、数据库 schema。/path/to/project/backend/src/AGENTS.md目录级规范定义此目录下 Rust 代码的clippy规则、rustfmt配置。/path/to/project/backend/src/lib.rs/AGENTS.override.md文件级覆盖针对lib.rs的特殊要求如必须使用async_trait。Skills技能来自config.toml中定义的skills列表。每个Skill是一个 markdown 文件描述一个具体能力如 “如何运行单元测试”、“如何部署到 staging 环境”。Codex 会将这些文件的内容按需注入 prompt。环境上下文Environment Context实时生成包括当前文件树tree -L 3的输出。Git 状态git status --porcelain。当前打开的文件内容如果适用。完整的对话历史messages数组。这个层级注入的威力在于Agent 能够根据你当前所在的代码位置自动加载最相关的上下文。当你在backend/src/handlers/目录下运行codex explain时它会优先加载backend/src/handlers/AGENTS.md而不是整个项目的AGENTS.md。这极大地提升了上下文的相关性避免了信息过载。4.3 覆盖与合并override.md 的优先级规则AGENTS.override.md的存在是为了应对“例外情况”。它的优先级永远高于同级的AGENTS.md。规则如下/project/backend/src/AGENTS.override.md会完全覆盖/project/backend/src/AGENTS.md的内容。/project/backend/AGENTS.override.md会部分覆盖/project/backend/AGENTS.md只替换其中被明确声明的部分通过 YAML front matter 指定。这种设计让团队既能建立统一的项目规范AGENTS.md又能为特定模块或文件保留灵活的定制空间AGENTS.override.md完美平衡了标准化与灵活性。实操心得不要试图在AGENTS.md里写满所有规则。把它当作“宪法”只规定最高原则如 “所有 PR 必须有单元测试”。把具体执行细则如 “backend 模块的测试覆盖率必须 80%”放在backend/AGENTS.md里。这样当新成员加入时他只需要看自己当前目录下的AGENTS.md就能立刻知道“在这里我该怎么做”而不是在万行文档里大海捞针。5. Sandbox内核级隔离与三种权限模式的工程取舍Codex 的 Sandbox 不是锦上添花的功能而是其架构哲学的集中体现宁可牺牲一点灵活性也要守住安全底线。它与 Claude Code 的沙箱设计形成了鲜明对比这种对比背后是两种截然不同的安全观。5.1 内核级实现Seatbelt 与 Landlock/seccomp 的硬核防护Codex 的沙箱其防护能力来源于操作系统内核而非应用层的模拟。这意味着任何绕过沙箱的尝试都会在内核态被无情拦截根本无法到达应用层。macOS (Seatbelt)Seatbelt 是 Apple 为 App Store 应用设计的沙箱框架。Codex 为每个Tool::execute()创建一个独立的seatbeltprofile精确控制read-path/write-path只能读写指定路径如workspace-write模式下只允许写入./src/。network-outbound是否允许联网。process-exec是否允许execve系统调用。sysctl-read是否允许读取系统信息。这个 profile 在进程启动前就被加载一旦生效连dlopen加载恶意 dylib 都会被拒绝。Linux (Landlock seccomp)Landlock提供强制访问控制MAC可以定义一个规则集规定进程只能访问哪些文件路径。Codex 的workspace-write模式就是通过 Landlock 规则只允许进程对./目录及其子目录进行openat、write等操作。seccomp提供系统调用过滤。Codex 的read-only模式会禁用所有write、connect、execve等危险 syscall。即使你的代码里写了system(rm -rf /)seccomp也会在内核态直接返回EPERM错误。这种内核级防护其强度远超任何应用层的chroot或docker。它不依赖于你写的代码是否“干净”而是从根本上剥夺了恶意代码的执行能力。5.2 三种预设模式read-only / workspace-write / danger-full-accessCodex 将复杂的权限控制抽象为三个清晰、易懂、可配置的模式模式允许的操作典型用途安全等级read-only读取任意文件、列出目录、git status代码审查、静态分析、生成文档⭐⭐⭐⭐⭐workspace-write读写当前工作目录$PWD及其子目录、git add/commit日常编码、重构、运行测试⭐⭐⭐⭐danger-full-access读写任意路径、联网、执行任意命令仅限调试如需要curl下载依赖、ssh连接远程服务器⚠️⚠️⚠️这个设计的智慧在于它把安全决策权交给了用户但用清晰的命名和文档强烈暗示了风险。danger-full-access这个名字本身就是一道心理防线。它不会阻止你启用但会让你在启用前认真思考“我真的需要这个吗”。5.3 与 Claude Code 的对比安全哲学的分野Blake Crosley 的架构对比文章一针见血地指出了两者的核心差异CodexProcess Isolation (进程隔离)优点安全性极高几乎无法绕过。seccomp禁用connectAgent 就真的不能联网。缺点灵活性低。你无法编写一个“动态决定是否联网”的 hook因为 syscall 已被内核禁止。所有权限必须在启动前静态声明。Claude CodeApplication Hooks (应用钩子)优点灵活性极高。你可以编写一个 hook在curl命令执行前检查 URL 是否在白名单内你可以在git push前自动运行pre-commit钩子。缺点安全性依赖于 hook 代码的质量。一个有缺陷的 hook就可能成为后门。Codex 团队负责人 Tibo 的原话道破天机“We take a stance with the sandboxing that hurts us in terms of general adoption. However, we do not want to promote something that could be unsafe by default.” 这句话翻译过来就是我们宁愿让产品在初期显得笨拙也不愿让用户在默认设置下就暴露在风险之中。这种取舍在金融、政府等对安全零容忍的领域是无可争议的胜利。但在需要高度定制化工作流的 DevOps 场景Claude Code 的 hooks 可能更受欢迎。没有优劣只有适配。注意MCP Server是 Codex 沙箱的一个已知缺口。由于 MCP server 作为独立进程在沙箱外运行它不受上述任何保护。Codex 文档坦率承认“MCP tools must secure themselves.” 这意味着集成一个不可信的第三方 MCP server如一个未经审计的 Jira connector确实可能带来风险。这是设计上的主动妥协而非疏忽。6. App ServerThread/Turn/Item 三层协议与开放生态的基石如果说core是 Codex 的心脏那么App Server就是它的血管系统。它不是一个封闭的私有协议而是一个完全开源、文档完备、支持多种传输方式的开放协议。正是这个协议让 Codex 从一个 CLI 工具蜕变为一个可被任何 IDE、任何平台集成的 Agent 平台。6.1 为什么需要 App Server从 CLI 到平台的跃迁Codex 最初只有 TUI。当团队决定开发 VS Code 插件时面临一个根本性选择是为 VS Code 重写一套 agent logic还是复用core他们选择了后者并为此创造了 App Server。App Server 的诞生源于一个朴素的观察IDE 插件的需求远比终端复杂。TUI 只需要显示文本流而 IDE 需要实时 Diff 渲染在编辑器里高亮显示 Agent 即将修改的代码。用户审批流在file_edit前弹出一个 diff preview让用户点击 “Accept” 或 “Reject”。多文件协同一个Turn可能同时修改src/main.rs和tests/integration.rsIDE 需要分别打开这两个文件。中断与取消用户在 IDE 里按 Esc应该能立即中断当前Turn。这些需求TUI 无法满足core也不该去满足。App Server 就是这个需求的中间层它把core的通用能力包装成 IDE