02 · 核心概念：代理循环、沙箱与审批
建立理解 Codex 后续所有功能所需的底层模型：代理循环、上下文、工具、沙箱、审批与 Git 工作区。
在真正上手之前，值得花十分钟建立一套底层概念。因为 Codex 后面所有的功能——权限、配置、MCP、子代理——都建立在这几个词之上。你不需要记住细节，但你需要建立一个心智模型，看到任何新功能时能立刻归位到这套模型里。
最核心的是「代理循环」（Agent Loop）。你可以把它想成一个不断重复的闭环：理解任务 → 决定下一步 → 调用工具执行 → 看结果 → 再决定下一步。它不是一次性吐出一大段代码，而是像人一样一步步推进。举个具体的例子：你让 Codex「修一下登录失败的问题」，它可能先读 login.py 看现有逻辑，再读测试用例找复现路径，再尝试修改，再跑测试验证——每一步都基于上一步的结果推进。
代理循环有三个关键特征值得记一下：一是「它自己决定下一步」，所以你不用一步一步指挥；二是「可以中途被你打断」，你随时可以喊停或纠正方向；三是「可以停在「需要你拍板」的地方」，比如该不该删某个文件，它不会擅自动手。
flowchart LR A[想<br>读文件 看报错] --> B[做<br>改代码 跑命令] B --> C[看<br>跑测试 对输出] C -->|继续推进| A C -->|任务完成| D[交付结果] C -->|需要拍板| E[停下等审批] style A fill:#5eead4,color:#050a0f style D fill:#5eead4,color:#050a0f style E fill:#22d3ee,color:#050a0f style C fill:#0f1a24,color:#e6f1f5 style B fill:#0f1a24,color:#e6f1f5
支撑这个循环运转的是「上下文」（Context）。简单说，就是它「此刻能看到的全部信息」：你的任务描述、它读过的文件内容、跑过的命令输出、它的推理过程、以及你和它的对话历史。上下文是有限的——窗口装满了，最旧的信息会被挤掉。这就是为什么会有「清理上下文」「控制修改范围」「避免塞无关文件」这些技巧，本质都是在节省上下文空间。
理解上下文的关键一个比喻是：把它当成「它的短期记忆」。短期记忆是有限的，所以它不会像你一样「记住三个月前项目的所有细节」——它只记得「现在这一刻需要知道的」。
「工具」（Tools）是它的「手脚」。Codex 自带一批内置工具，每个工具都对应一种能力。常见的有：读文件、写文件、编辑文件、搜索代码、执行 shell 命令、访问网络、调用 MCP 服务器等。每个工具都有「能做什么」「不能做什么」「需要什么前置条件」这些边界，而**这些边界正是安全机制起作用的地方**。
举几个具体工具的例子：读文件工具只能读项目内的文件，不能读系统文件；写文件工具只能写到被授权的目录；执行命令工具只能跑被允许的命令。这些边界是写死的，你不能通过任务描述绕过——这是底线。
「沙箱」（Sandbox）是一层隔离，让它即便在执行任务时，也不会「逃出」你设定的范围。默认情况下：写文件只能在项目目录内、跑命令不能碰系统目录、联网要么被禁止要么要审批。它不是「关在笼子里」，而是「在一个可控范围内干活」。
- 沙箱模式 read-only：能改文件？不能。 能联网？不能。 何时用：只想让它读代码、做审查、出方案。
- 沙箱模式 workspace-write：能改文件？仅限工作区内。 能联网？默认不能。 何时用：日常开发最常用。
- 沙箱模式 danger-full-access：能改文件？全机器。 能联网？能。 何时用：完全信任的环境，慎用。
沙箱有「多层防御」：第一层是文件系统边界（只允许动项目内文件）；第二层是网络边界（默认禁网或受限）；第三层是命令白名单（只允许跑安全的命令）。每一层都是独立的，少一层都会让整体安全性下降。
flowchart LR
A[Codex 要做的每一步] --> B{沙箱检查<br>在不在圈内?}
B -->|在圈内| C[直接执行]
B -->|出圈了| D{审批策略<br>问不问你?}
D -->|on-request| E[停下来问你]
D -->|never| F[直接出圈]
D -->|untrusted| G[陌生命令问]
C --> H[继续推进]
E --> H
F --> H
G --> H
style A fill:#5eead4,color:#050a0f
style B fill:#a78bfa,color:#050a0f
style D fill:#22d3ee,color:#050a0f
style C fill:#0f1a24,color:#e6f1f5
style E fill:#0f1a24,color:#e6f1f5
style F fill:#0f1a24,color:#e6f1f5
style G fill:#0f1a24,color:#e6f1f5
style H fill:#0f1a24,color:#e6f1f5
「审批」（Approval）是人的最后一道闸门。当它要做一件有风险的事——删除文件、执行某条命令、访问外网——系统会先停下来问你「要不要批准」。你可以全自动放行（适合低风险、反复操作）、可以每次手动确认（适合高风险、新场景）、可以按规则放行（适合批量同类型操作）。
审批的本质是「让人类保留否决权」。AI 再聪明也不能替你做不可逆的决定——删文件、改数据库、生产部署这些动作，它都应该停下来等你点头。这是人和 AI 的合理分工。
- 审批策略 untrusted：不在可信集合的命令跑之前先问。
- 审批策略 on-request：默认在沙箱里干，出圈才停下来问，最常用。
- 审批策略 never：不弹审批闷头干，权限仍由沙箱决定，适合自动化。
「Git 工作区」是它的安全网，也是你的后悔药。它做的改动通常都在 Git 的追踪之下：你可以随时用 diff 看它改了什么、可以一键回退到改动前的状态、可以在觉得不对劲的时候整个丢弃这次尝试。**没有 Git 用 AI 干活，相当于不系安全带开车**——可能没事，但出事了就是大事。
Git 的几个关键习惯：开始前 `git status` 看一下干净状态、改完用 `git diff` 看具体改了什么、确认满意后再 `git commit`、不满意就 `git checkout` 扔掉。这四个动作加起来，比任何「AI 安全机制」都管用。
把这六个概念串起来，Codex 的完整工作方式就清楚了：在一个受控的沙箱里，借助工具和上下文，沿着代理循环推进任务，遇到风险动作就停下等你审批，所有改动都有 Git 兜底。理解了这一层，后面每一篇其实都是往这套模型上做加法——MCP 是「加工具」，Skills 是「沉淀流程」，子代理是「拆人并行」。
flowchart TB P[Codex 代理<br>主角] P --> S1[沙箱<br>圈] P --> T[工具<br>手脚] P --> C[上下文<br>短期记忆] P --> A[审批<br>出圈问] P --> G[Git<br>安全网] P --> M[AGENTS.md<br>项目规矩] style P fill:#5eead4,color:#050a0f style S1 fill:#a78bfa,color:#050a0f style A fill:#22d3ee,color:#050a0f style T fill:#0f1a24,color:#e6f1f5 style C fill:#0f1a24,color:#e6f1f5 style G fill:#0f1a24,color:#e6f1f5 style M fill:#0f1a24,color:#e6f1f5
一个自查清单：当你看到 Codex 的某个新功能时，问自己三个问题——它动了哪个工具？它怎么用上下文？它受沙箱和审批管吗？想清楚这三个，你就永远知道它能干什么、不能干什么、什么时候该按 Ctrl+C 停下来。
用一句话总结这一篇的核心：Codex 的所有行为都可以归结为「在受控环境下、用有限信息、按循环推进任务」。这句话看着抽象，实际上后面每一篇都是它的具体展开——权限是受控环境的细节、MCP 是扩展工具的细节、Skills 是循环推进的具体策略。
理解这一篇的「副作用」：当你真的吃透这六个概念，你以后看到 Codex 的任何新功能，都能用「它属于哪个概念？」这个问题来归类。比如新出的某个安全机制，你立刻能想到「这是沙箱/审批的具体实现」。这就是底层模型的价值——它让你能用最少的时间理解最多的事。
常见误区：很多新手会把这一篇讲的「基本规则」当成「教条」——什么都严格遵守。其实这些规则的核心是「降低风险、提高效率」，理解了动机，规则就自然内化了，不用死记硬背。
动手试一下：你可以花 5 分钟做一个最小验证——找一个真实的代码任务，让 Codex 跑一遍，看它的行为是不是和这一篇描述的一致。理论与实践对照，才知道「懂」和「会用」是两件事。
与其他篇的关系：这一篇是本组的基础。如果你跳过了前面几篇，建议先回去看，否则这里有些概念可能看着突兀。如果都看过了，那你可以直接进入更后面的实战环节，把这里学到的东西用上。
实用清单（速记版）：① 适用场景：{场景}。 ② 关键动作：{动作}。 ③ 风险点：{风险}。 ④ 验证方法：{验证}。把这四点记住，能让你在大部分场景下做出正确决策。