这篇是 Codex 设计解读路线的第一块。目标不是一次性读完整个系统， 而是先把一条最常见的链路看清楚：用户在界面里发起动作，app server 接住请求，core loop 推进任务，最后事件流把状态和结果送回界面。
如果能把这条链路讲清楚，后面再看工具调用、权限、子 agent、上下文压缩和 恢复都会容易很多。
UI action
入口通常是一个界面动作：发送消息、点击工具、恢复会话、打开某个工作区， 或者让 Codex 继续一个正在跑的任务。
这一层最重要的不是按钮本身，而是界面把什么状态交给服务端：当前会话、 用户输入、选中的 workspace、工具参数、以及这次操作允许触发哪些能力。 换句话说，UI action 是用户意图变成系统请求的地方。
Server call
app server 接到请求后，要做的第一件事是把它变成一个可执行的服务端调用。 这里会处理会话身份、权限、workspace 位置、运行环境、工具边界和请求分发。
从设计上看，server 是界面和执行系统之间的窄口。它不应该只是一个转发层， 也不能把所有执行细节都暴露给前端。它负责把用户动作整理成 core 能理解的 任务输入。
Core loop
core loop 是任务真正被推进的地方。模型调用、工具运行、文件读写、终端命令、 中间状态记录，都会在这里围绕同一个任务持续发生。
这一层的关键问题是：系统如何保持任务不跑偏。它需要知道当前目标、已有上下文、 工具结果、失败信息和下一步动作。Codex 不是只生成一段回答，而是在一个持续变化 的执行状态里做下一次决策。
Event stream
执行过程不会等全部结束后才一次性返回。事件流会把增量输出、工具状态、错误、 完成信号和需要用户介入的节点持续送回界面。
这也是为什么用户能看到 Codex 一边思考、一边运行工具、一边更新结果。对界面来说， event stream 是把服务端执行重新变成可感知体验的通道。
读完这一块应该得到什么
读完这篇，至少应该能回答三个问题：
- 一次用户动作在哪里进入 server
- server 和 core loop 分别负责什么
- 为什么执行结果可以持续回到界面，而不是等任务结束才出现
后面的路线可以在这条链路上继续展开：工具调用、权限模型、事件类型、 状态恢复，以及多 agent 如何接入同一套执行通道。