当 AI Agent 开始自己写代码、跑命令、动数据库……
谁来守护企业的"数字员工"？

第 ① 步：会话初始化 (Session Bootstrap)

Codex CLI 启动，做几件事：

• 读取 ~/.codex/config.toml（用户配置：默认模型、approval_policy、sandbox_mode、MCP 服务器列表）
• 认证：检查 ~/.codex/auth.json（ChatGPT 登录态或 API Key）
• 读取仓库根目录的 AGENTS.md 和当前目录的 AGENTS.md（项目知识、编码规范、测试命令）
• 读取 ~/.codex/memories/MEMORY.md（跨项目长期记忆，如"Alice 习惯用 pnpm 而不是 npm"）
• 建立到 OpenAI 的 HTTPS 会话（通常通过 codex-network-proxy 代理）

第 ② 步：构建初始 Prompt

Codex Core 把以下内容拼装成一个巨大的 prompt 发给 OpenAI：

• 系统提示词（System Prompt）：Codex 内置的角色定义（"你是一个编码代理…"）
• 项目上下文：根目录 + 当前目录的 AGENTS.md 全文
• 长期记忆：MEMORY.md 中相关的内容
• 用户输入："帮我看看 CI 为什么失败，修复它，然后提一个 PR"
• 可用工具列表：shell、apply_patch、update_plan、view_image、web_search、MCP 工具…
• 沙盒能力声明：当前是 workspace-write，可以读写仓库目录

第 ③ 步：LLM 思考 → 生成"行动计划"

OpenAI 的 GPT-5 模型（或 Codex 专用模型）开始推理。它通过 SSE 流把响应分块返回。第一个返回通常是 update_plan 工具调用：

{
  "tool": "update_plan",
  "plan": [
    { "step": "查看最近的 CI 日志", "status": "in_progress" },
    { "step": "定位失败的测试", "status": "pending" },
    { "step": "分析根因", "status": "pending" },
    { "step": "修复代码", "status": "pending" },
    { "step": "本地跑测试验证", "status": "pending" },
    { "step": "提交 PR", "status": "pending" }
  ]
}

这个计划立刻在 TUI 上以 ToDo 列表的形式展示给 Alice。

第 ④ 步：第一次工具调用 → "Shell 命令"

LLM 决定先看 CI 日志，发起 shell 工具调用：

{
  "tool": "shell",
  "command": ["gh", "run", "view", "--log-failed"],
  "cwd": "/Users/alice/project"
}

Codex Core 拦截这次调用，检查 approval_policy：

• 如果是 untrusted：弹窗问 Alice "允许执行这条命令吗？"
• 如果是 on-request：自动执行（不弹窗）
• 如果是 never：自动执行

命令在沙盒里执行（macOS 用 sandbox-exec，Linux 用 landlock + seccomp）。命令输出被截取，回传给 LLM。

第 ⑤ 步：循环：思考 → 行动 → 观察 → 思考…

LLM 拿到 CI 日志后，又发起新的 shell 调用查看具体失败的测试文件，然后调用 apply_patch 工具修改代码：

*** Begin Patch
*** Update File: src/utils/parser.ts
@@ export function parse(input: string) {
-  return JSON.parse(input);
+  if (!input) return null;
+  return JSON.parse(input);
*** End Patch

Codex 在打补丁前会显示完整的 diff 给用户审核（如果 approval_policy 要求）。补丁应用后，LLM 再次调用 shell 跑测试 npm test，确认问题解决。

这个 "思考 → 行动 → 观察" 循环可能持续几分钟，包含十几次 LLM 调用、几十次工具调用。每一步 LLM 都根据上一步的观察结果（observation）决定下一步做什么——这就是"自主决策"的本质。

第 ⑥ 步：MCP 调用 → "调用外部工具"

当需要提 PR 时，LLM 调用 GitHub MCP Server（在 config.toml 中配置）：

{
  "tool": "github.create_pull_request",
  "title": "Fix: handle empty input in parser",
  "body": "Resolves CI failure...",
  "branch": "fix/parser-empty-input"
}

MCP 协议负责把这个调用翻译成对 GitHub API 的真实 HTTP 请求。注意：这个请求会从你的电脑出网，目标是 api.github.com。

第 ⑦ 步：任务完成 → 更新记忆 → 持久化

LLM 输出最终的总结消息，标记 update_plan 中所有步骤为 completed。Codex Core 做收尾：

• 记录会话：所有交互写入 ~/.codex/sessions/{uuid}/rollout.jsonl，可以用 codex resume 恢复
• 更新长期记忆：异步触发 memory 写入流程（Phase 1: 提取、Phase 2: 整合到 MEMORY.md）
• 遥测数据：发送匿名使用统计（可关闭）