AI Knowledge

外观

Codex 运行机制与工程优化专项面试题 ​

目录 ​

1. 使用说明 ​

  • 对应知识主题：运行机制篇与工程实践篇共同构成 Codex 运行机制与工程优化的单一知识单元；
  • 角色：资深面试官从模型、开源 Runtime 和产品族边界开始，逐层追问 Agent Loop、源码、项目配置、生产故障、竞品与系统评测；高级技术应聘者必须用公开源码和可复现实验证据回答；
  • 回答顺序：先给 1～3 句专业短答，再按题目层级展开；随后用有角色、目标、动作和结果的生活场景给小白解释，最后明确源码 Commit、官方文档、推断与未知；
  • 题目数量：7 题，严格覆盖 L1～L7。

事实红线｜ openai/codex 可以证明本地 Rust Runtime、CLI、SDK 和 App Server 的公开机制，但不能反推出 Codex Cloud、Desktop App、IDE Extension 与模型训练的全部私有实现。没有同仓库、同模型、同权限、同预算实验时，不能宣称 Codex 全面强于竞品。

阅读图例｜ L1～L2 概念与证据边界 · L3～L4 原理与源码 · L5 生产故障 · L6 架构选型 · L7 系统设计与评测

答案层级｜ 30 秒专业短答 · 深入展开 · 小白解释 · 事实边界 · 评分与下一问

2. 递进路线 ​

图：Codex 运行机制 L1～L7 递进路线

替代文本： L1 区分 Codex 模型、开源 Runtime 和产品形态；L2 建立官方事实、源码事实、推断与未知边界；L3 解释 Agent Loop；L4 落到源码模块和项目文件；L5 完成 Context、权限与错误完工故障闭环；L6 在固定变量下与 Claude Code、Gemini CLI 和 Copilot 选型；L7 设计并评测类 Codex 平台。

图表加载中…

读图结论： 先证明自己知道“什么是模型、什么是 Runtime、什么是开源可证”，再谈 Loop 和优化；最后必须用故障证据与公平评测回答“为什么强”。

L1 与 L2 是事实门槛，避免把产品营销、模型 Benchmark 和源码混成一层；L3 与 L4 是机制门槛，要求沿真实文件解释一次 Tool Call；L5 检验是否会按环境、工具、权限、Context 和模型的顺序排障；L6 检验选型纪律；L7 最终把这些能力重组为可实现、可验证的系统。

图：从用户目标到受控工具反馈的 Codex 主链

替代文本： 用户通过 TUI、codex exec、IDE、App、Cloud 或 SDK 提交目标；当前 TUI 与 codex exec 经进程内 App Server Client 的有界强类型 Channel 进入 App Server，跨进程客户端经 JSON 传输进入同一服务。turn/start 被转换为 Op UserInput，进入 CodexThread Submission Queue，再由 submission loop、RegularTask 和 run turn 装配 Context 并请求 Responses API。模型 Tool Call 进入 ToolRouter，再经 Approval、Rules、Sandbox 和 Network Policy 交给 Handler；输出写回 History继续采样。Rollout、State、Diff 和 Telemetry 横向记录。

图表加载中…

读图结论： 模型负责决定候选动作，Runtime 负责执行边界、工具结果和状态；Codex 的工程优势来自这条闭环，而不是模型直接拥有终端。

这张图还是 L3～L5 的共同诊断地图：错误可能发生在 Context、模型动作、Tool Spec、审批、Sandbox、Handler、Observation、验证或持久化任一层，不能一律归因于模型。

3. 一问一答 ​

第 1 题｜L1 概念｜Codex 模型、Codex Runtime 和 Codex 产品族分别是什么？ ​

核心考察点｜ 模型决策、Agent Harness、开源边界与产品 Surface

面试官提问

请说明三者职责，并解释为什么 Codex 不是“给 GPT 加一个终端”这么简单。

30 秒专业短答

Codex 中的模型负责理解目标、代码推理和提出文本或工具动作；开源 Rust Runtime 负责 Thread、Context、Tool、Approval、Sandbox、State 和 Event；CLI、IDE、Desktop App、Cloud、SDK 与 App Server 是不同交互或执行形态。实际效果来自模型、Runtime 和环境的组合，不是一个 Prompt，也不能把所有 Surface 都说成完整开源。

深入展开

模型只返回候选动作；Runtime 装配基础指令、AGENTS.md、Skills、工具 Schema 和历史，通过 Responses API 采样，再将 Tool Call 路由到真实工具，裁决审批和 Sandbox，并把 Tool Result 回灌。CLI、SDK 和 App Server 有公开实现；Cloud 服务端、IDE 与 Desktop App 的全部实现没有公开。排障时要先区分模型理解错误、Context 缺失、工具失败、权限拒绝、环境不一致和客户端展示问题。

小白解释

小林负责判断设备怎么修，隔离工位提供手册、工具、门禁和工作日志，公司还让他通过现场终端、远程控制台或自动工单接活。小林对应模型，工位对应 Runtime，不同入口对应 CLI、IDE、App、Cloud 和 SDK。回到专业机制，模型提议动作，Runtime 执行与记录，Surface 负责交互。类比只解释职责分工：模型并不真正拥有终端，托管系统也不等于本地源码。

事实与证据边界

产品族定义、Agent Loop 与开源组件范围来自 OpenAI 官方文档；Runtime 结构可由固定提交 openai/codex@5c19155 验证。当前模型完整训练数据、Cloud 调度、Desktop App 与 IDE 全量源码无法从本地 Runtime 确认。

  • 合格线｜ 模型提议动作，Runtime 管循环、执行、安全和状态，Surface 管交互与环境；
  • 加分项｜ 指出 App Server 和 Protocol 让多端复用同一 Core，Cloud 客户端代码不等于服务端源码；
  • 工程证据｜ 官方 Open Source 页面、固定源码 Commit、cli/src/main.rs、app-server/ 与 protocol/；
  • 高频误区｜ 把 Codex 说成独立单一模型，或认为 npm 的 Node 启动器就是 Agent Runtime；
  • 下一问｜ 三层分清后，继续说明哪些结论能从源码证明、哪些必须止步。

第 2 题｜L2 边界｜你如何证明自己讲的是 Codex 机制，而不是厂商营销或社区猜测？ ​

核心考察点｜ 官方事实、开源源码、架构推断、动态快照与未知

面试官提问

请各举两个“官方文档事实、源码事实、合理推断和无法确认”的例子，并说明为什么模型 Benchmark 不能直接代表产品完成率。

30 秒专业短答

我把结论分成官方文档事实、固定 Commit 的源码事实、基于证据的推断和当前未知四类。Container Cache 与 Auto-review 是文档事实，run_turn 与 ToolRouter 是源码事实，模型和 Harness 协同优化是推断；完整训练 Reward、Cloud 调度和同条件竞品胜率无法确认。模型 Benchmark 没有控制客户端、工具、权限、环境和验证，因此不能直接等价为产品完成率。

深入展开

官方事实至少要能定位到 OpenAI 文档、工程文章或 System Card；源码事实要固定 Commit，并从类型、函数、测试或注释确认；推断必须写出证据链和反例；未知项进入待查清单。比如“Skill 渐进披露”和“Cloud Container 最长缓存 12 小时”有当前官方文档，“ToolRouter 解析 Function Call 并分派到 Registry”有源码；“联合训练使特定工具语义更匹配模型”合理但缺少因果消融；“Codex 全面胜过 Claude Code”则被公开 Benchmark 中不领先的项目直接否定。

小白解释

验车员会区分说明书、拆车看到的零件、基于结构的推测和完全不知道。说明书对应官方文档，零件对应源码，结构推测对应合理推断，无法打开的控制器对应未知。回到专业机制，证据必须带版本、Commit 和访问日期。类比忽略了软件发布速度，因此昨天的默认值今天也可能变化。

事实与证据边界

本题快照日期是 2026-07-11，源码 Commit 是 5c19155cbd93bfa099016e7487259f61669823ff。GPT-5.6 页面同时显示 Codex 在部分终端和长工程评测领先，也在 SWE-Bench Pro 与 Toolathlon 不领先，这正说明不能写绝对结论。

  • 合格线｜ 四类证据分开，至少说出 Cloud、模型训练和全面竞品胜率不能由 CLI 源码证明；
  • 加分项｜ 说明公开源码也只是某个 Commit，不是未来兼容承诺；供应商 Benchmark 与独立复测仍要区分；
  • 工程证据｜ 官方 URL、访问日期、Commit SHA、源码行、测试、可复现实验配置与原始输出；
  • 高频误区｜ 把 main 当前行为当永久契约，或把一个模型分数当所有客户端的端到端分数；
  • 下一问｜ 事实边界建立后，按 Thread、Turn、Tool Result 展开真实 Agent Loop。

第 3 题｜L3 原理｜一次 Codex 请求如何从目标走到验证完成？ ​

核心考察点｜ Context 装配、Responses API、ToolRouter、Policy、Observation、Compaction 与终止

面试官提问

请以“修复失败测试”为例，讲清模型和 Runtime 每一步分别做什么。

30 秒专业短答

客户端先经 App Server 创建或恢复 Thread；当前 TUI 与 codex exec 的本地热路径使用有界强类型 Channel。turn/start 转成 Op::UserInput，经 CodexThread → submission_loop → RegularTask → run_turn 装配 Context 并请求模型。Tool Call 再经 ToolRouter、Approval、Rules、Sandbox 和 Network Policy 执行，Observation 回灌后继续采样、压缩或基于外部验收结束。

深入展开

以失败测试为例，App Server 的 Turn Processor 先把请求转换为 Core Operation，session/handlers.rs 的 Submission Loop 选择 tasks/regular.rs，再进入 session/turn.rs 的 run_turn。模型先请求 Shell；Orchestrator 判断是否需要审批、是否进入 Sandbox，Handler 运行测试并返回 stderr 与退出码。结果写入 History 后，模型请求搜索或读取代码，再提出 Patch；写入经过权限裁决，Diff 继续回灌，模型重跑目标测试。client.rs 负责流式模型请求，tools/spec_plan.rs、router.rs、registry.rs 与 orchestrator.rs 形成工具主链。Context 超限时进入 Compaction。

小白解释

小林先读取工单和项目手册，请求在测试台复现；门禁允许后，测试台返回错误，他再查线、换件并复测。工单与手册对应 Context，操作请求对应 Tool Call，门禁对应 Policy 与 Sandbox，读数对应 Observation，重新判断对应下一次模型采样。回到专业机制，Runtime 执行动作并把结果重新交给模型。类比没有表达模型随机性，也不能保证测试台覆盖全部真实故障。

事实与证据边界

Agent Loop、Tool Result 回灌、自动压缩和停止条件可从官方文章与固定源码确认；模型内部为什么选择某个工具、隐藏推理内容和所有启发式没有公开。最终文本只是结束候选，正确性仍依赖测试、Diff 与人工 Review。

  • 合格线｜ Context → 模型 → Tool Call → Policy → 执行 → Observation → 继续/停止；
  • 加分项｜ 说明 Turn 可能有多次模型调用、同 Turn 复用 ModelClientSession、Subagent 是独立 Thread；
  • 工程证据｜ Response Item、Tool Call ID、Approval Event、退出码、Diff、Token Status、Compaction Item 与 Rollout；
  • 高频误区｜ 认为模型直接执行 Shell，或一个 API 请求就是整个 Turn；
  • 下一问｜ Loop 讲清后，把调用链落到源码和普通项目配置文件。

第 4 题｜L4 实现｜Codex 源码模块与业务项目文件如何分工？ ​

核心考察点｜ 入口、Core、Protocol、Tool、安全、State，以及 Instructions、Config、Rules、Skills 的生命周期

面试官提问

请先说官方仓库最值得读的文件，再说明普通项目里的主要 Codex 文件分别存什么、何时加载、是否提交 Git，以及为什么不能把所有内容塞进 AGENTS.md。

30 秒专业短答

源码从 cli/src/main.rs 进入；TUI/Exec 的共同入口看 app-server-client/，跨进程边界看 app-server-transport/，请求转换看 app-server/，Submission 主链看 session/handlers.rs、tasks/regular.rs 和 session/turn.rs。模型 I/O 看 client.rs，工具看 tools/，安全和恢复看 sandboxing/、rollout/、state/。业务项目用 AGENTS.md 管常驻指令，Config 管受信配置，Rules 管命令策略，Skills 管按需流程；本机 State 和凭据不提交。

深入展开

AGENTS.md 从项目根到当前目录合并，越近的内容越晚进入 Prompt；.codex/config.toml 只有 Trusted Project 才加载，并不能覆盖机器本地的 Provider、Auth 与 Telemetry 等敏感键；.codex/rules/*.rules 控制 Sandbox 外命令决策；.agents/skills/{name}/SKILL.md 只先暴露元数据，匹配后加载全文及 scripts/references/assets；Hooks 把确定性检查移到模型外。强制业务事实进 AGENTS，偶用流程进 Skill，命令进脚本，安全边界进 Approval/Sandbox/外部 RBAC，轨迹进本机 Rollout/State。全部塞进 AGENTS 会永久消耗 Context，并把建议、配置、安全和运行状态混为一层。

小白解释

工厂的总手册对应 AGENTS.md，工位配置对应 .codex/config.toml，门禁规则对应 Rules，临时专项手册对应 Skill，自动检测仪对应 Hook，工作录像对应 Rollout。专业上，它们分别影响 Prompt、Runtime 配置、命令裁决、按需知识、确定性校验和持久状态。类比只解释分层：手册不能代替门禁，录像也不能撤销已经发出的远程命令。

事实与证据边界

路径、加载顺序、Trusted Project、Skill Context 预算和 Rules 扫描位置有官方文档与源码支持；项目级哪些配置应该提交仍取决于团队安全策略。任何 Token、OAuth 凭据、个人 Session、SQLite State 和敏感日志都不能因为“Codex 需要”而进入 Git。

  • 合格线｜ 能说出入口、Loop、Tool、Protocol、安全和 State 的源码位置；能把 Instructions、Config、Rules、Skill、Script 与 Runtime Data 分开；
  • 加分项｜ 说明 npm Node 文件只是原生二进制启动薄层，MCP 外部工具不自动继承 Shell Sandbox；
  • 工程证据｜ 固定 Commit、Config Layer Trace、Instruction Sources、Skill Load Event、Rule Match Test、Git Status 和 Secret Scan；
  • 高频误区｜ 只看 codex-cli/bin/codex.js 就下结论，或把所有项目知识、权限和秘密塞进 AGENTS.md；
  • 下一问｜ 文件职责清楚后，用一次长任务异常检验排障顺序。

第 5 题｜L5 工程｜Codex 长任务出现重复工作、命令未执行和错误完工，你怎么排查？ ​

核心考察点｜ 现象、影响、证据、根因、止损、修复、回归与防复发

面试官提问

一个长任务在 Compaction 后重复修改，最终说测试通过，但 CI 失败；期间某条命令似乎没有执行。请给出完整故障闭环。

30 秒专业短答

我先冻结写入并保留 Rollout、Diff、Approval 和 CI 证据，再按环境基线、Tool Call、权限/Sandbox、Instructions、Context/Compaction、模型理解的顺序排查。命令没执行要先看 Tool Spec、Approval、Rule、Sandbox 和超时，不能靠最终文字猜；重复修改要核对 Compaction 是否丢验收，CI 失败要对照实际命令、退出码和测试范围。修复后强制重演压缩、拒绝和错误目录场景，并把验收固化进 AGENTS、测试和 CI Gate。

深入展开

止损时停止当前 Turn，保存未提交 Diff 和外部请求 ID，禁止盲目重试。第一层确认 Commit、依赖、CWD 和 CI 命令；第二层查模型是否真的发出 Tool Call、Router 是否找到 Handler、Approval/Rules/Sandbox 是否拒绝、进程是否超时；第三层查 AGENTS.md、Skill、MCP 与版本是否加载正确；第四层对比 Compaction 前后目标、未完成项和测试命令，检查 Cache Miss 与工具结果截断；最后才评估模型误解。长期修复包括权威测试写入项目指令、Stop Hook 或 CI 强制验收、输出摘要保留退出码、Compaction Handoff 外置、权限 Profile 与 Rule 测试、Rollout 完整性和告警。

小白解释

小林换班后重复拆了已经修好的部件，还说检测通过，但总检失败；同时一把工具其实被门禁拦住。主管先封存现场和录像，再查检测台、门禁记录、交接单，最后才判断小林是否误解。现场对应仓库和依赖，门禁记录对应 Approval/Sandbox，交接单对应 Compaction，录像对应 Rollout，总检对应 CI。类比边界是软件还可能有缓存、网络和非确定测试，人类现场交接也不等于模型摘要算法。

事实与证据边界

这是故障演练，不代表本文确认发生过同一生产事故。Compaction 有损、Approval 与 Sandbox 分层、Rollout 和 OTel 可观测有官方依据；具体根因必须由目标项目原始 JSONL、日志、版本、配置和 CI 复现确认。

  • 合格线｜ 环境 → Tool → 权限/沙箱 → 指令/配置 → Context/State → 模型的证据顺序完整；
  • 加分项｜ 区分“未发 Tool Call、被拒绝、执行超时、输出被截断、测试范围错误”五种不同现象；
  • 工程证据｜ Rollout Item、Call ID、Approval Decision、Rule Match、Sandbox Denial、CWD、exit code、Compaction Boundary、CI 与 Diff；
  • 高频误区｜ 直接换 Prompt 或模型，盲目重跑有副作用命令，或把 Final Message 当测试证据；
  • 下一问｜ 故障闭环完成后，再讨论 Codex 与其他工具的架构选型。

第 6 题｜L6 架构｜为什么不能直接说 Codex 比 Claude Code、Gemini CLI 和 Copilot 强？ ​

核心考察点｜ 工作流匹配、变量控制、开源透明度、安全与生态权衡

面试官提问

请给出条件性选型：什么场景优先 Codex，什么场景应优先其他方案？

30 秒专业短答

这些产品的 Agent Loop、Skills、MCP、Memory、Sandbox 和 Subagent 已高度重叠，真正差异是模型、Runtime 透明度、交互形态、生态、安全治理和恢复组合。Codex 更适合需要开源 Rust Runtime、终端长任务、本地到 Cloud 协同、多 Agent 监督和协议嵌入的场景；Claude Code、Gemini CLI、Copilot Cloud Agent 在本地长会话、开放互操作或 GitHub PR 治理上也可能更合适。没有同仓库、同权限、同预算和隐藏测试，只能列候选，不能宣布冠军。

深入展开

如果组织要审计或自研客户端，Codex 的 Core、Protocol、App Server 与 SDK 是强项；如果任务是复杂本地交互调试，要把 Codex 与 Claude Code 同条件实测 Steering、恢复和成本；如果依赖 Google 生态与开放 Agent 互操作，Gemini CLI 值得优先；如果流程是 Issue 到受限分支 PR、企业治理重于本地接管，Copilot Cloud Agent 更直接。只要任务固定且高风险，应优先确定性 Workflow。公开 GPT-5.6 数据也显示 Codex 在 Terminal-Bench 和 DeepSWE 很强，但 SWE-Bench Pro 和 Toolathlon 并非领先，进一步否定绝对结论。

小白解释

山路抢修、赛道竞速和工厂运输需要不同车辆。道路、载重、油耗、安全规则和终点对应仓库、模型、权限、预算和隐藏测试；车辆对应不同 Agent 产品。专业上要固定变量后比较完成率、人工干预、总成本、回归和危险动作。类比边界是软件工具会快速升级，同一品牌也有 CLI、Cloud 和 IDE 等不同车型。

事实与证据边界

竞品公开机制来自各厂商一手文档；本文没有运行完全同条件的长期竞品实验。OpenAI 发布页中的竞争数据由 OpenAI 汇总，即使部分指标来自外部机构，也不能代替本项目独立复测；模型成绩不能直接等价为完整产品成绩。

  • 合格线｜ 至少按任务形态、透明度、安全、生态、恢复和成本给条件性选择；
  • 加分项｜ 区分本地 CLI、Cloud Agent 和 Inline Completion，指出强耦合高风险流程应使用确定性系统；
  • 工程证据｜ 固定 Commit、模型与 Effort、权限矩阵、隐藏测试、重复次数、Token、费用、人工干预与风险事件；
  • 高频误区｜ 只数功能、引用一次 Demo、拿不同模型和权限直接比较，或把厂商 Benchmark 当独立产品结论；
  • 下一问｜ 选型标准明确后，设计一套可落地的类 Codex 平台和评测。

第 7 题｜L7 项目复盘｜如何设计、上线并评测一个类 Codex Coding Agent 平台？ ​

核心考察点｜ 约束、架构、难点、可验证亮点、故障闭环、评测与经验迁移

面试官提问

假设公司要建设一个支持本地与云端、多人治理、可恢复和可审计的 Coding Agent。请给出 2～3 分钟项目回答，并明确哪些机制交给模型、哪些必须放入确定性 Runtime。

30 秒专业短答

我会把系统分成模型网关、Thread/Turn Core、Context Manager、Tool Registry、Policy/Sandbox、Environment、State/Telemetry 和 Eval 八层。模型负责理解、规划和选择候选动作；Runtime 负责权限、幂等、执行、超时、状态、压缩、恢复和终止证据。亮点不写“用了大模型”，而用验证成功率、人工干预、总成本、危险动作和恢复时间证明；首版先做单 Agent、少工具和强验收，再逐步加入 Subagent 与 Cloud。

深入展开

背景是研发任务跨仓库、人工上下文交接慢，但系统必须保护源码、凭据和生产环境。架构上，API/客户端通过版本化 Protocol 创建 Thread；Context 层合并项目指令、Skill 与历史并执行 Token Budget；Model Gateway 统一 Responses/Streaming、Cache 和重试；Tool 层注册 Shell、Patch、Search 与 MCP；Policy 层执行 Approval、Rule、Sandbox、Network 和外部 RBAC；Environment 用 Worktree 或容器隔离；State 保存 Rollout 与 SQLite/对象存储索引；OTel 记录 Prompt、Tool、Approval 与结果；Eval 用版本化仓库、隐藏测试和风险 Fixture。

最难的不是调用模型，而是在有限 Context 与真实副作用下保证可验证完成和恢复。我会先只开放只读工具与测试仓库，再加入 Workspace Write、Patch 和受限网络；所有副作用工具必须有 Idempotency Key、查询真实状态与补偿。Subagent 只处理独立调查，Writer 使用 Worktree，主 Agent 整合。上线以灰度和 Kill Switch 控制，故障演练覆盖 Prompt Injection、Compaction 丢约束、工具超时、外部成功但响应丢失、Rollout 损坏和多 Agent 冲突。

小白解释

公司要建立一座“智能维修中心”：工程师负责判断，调度台分配任务，工具柜保存工具，门禁限制权限，独立工位避免互相覆盖，录像和质检负责追溯。工程师对应模型，调度台对应 Thread/Turn，工具柜对应 Registry，门禁对应 Policy/Sandbox，独立工位对应 Worktree/Container，录像与质检对应 Rollout、Telemetry 和 Eval。类比边界是模型并非稳定员工，工具调用可能非幂等，质检也必须覆盖真实业务。

事实与证据边界

这是系统设计与故障演练，不是本文声称已上线的真实平台。具体 QPS、成功率、成本与收益必须由目标公司 PoC 测量；OpenAI Codex 架构只能作为公开参考，不能证明复制模块名就能获得同等模型、服务和产品效果。

  • 合格线｜ 模型与 Runtime 职责清楚，至少包含 Context、Tool、Policy、State、Environment、Telemetry 和 Eval；
  • 加分项｜ 有版本化 Protocol、幂等/对账、Worktree Ownership、Compaction 验收、灰度、Kill Switch 和数据治理；
  • 工程证据｜ Verified Success、Human Interventions、Total Cost、Regression Escape、Unsafe Attempt、Recovery Time、OTel Trace 和隐藏测试；
  • 高频误区｜ 先上无限工具与多 Agent、用模型自评代替验收、把本地 Git 回滚当远程事务、虚构收益；
  • 下一问｜ 选择一个真实仓库做 PoC，并把第一次失败按证据链整理为 Runbook 与回归集。

4. 自测与评分 ​

  • [ ] 先只看“面试官提问”，每题用 20～30 秒直接回答，第一句先给结论；
  • [ ] L1 能准确区分模型、Runtime 与 Surface，L2 能给四级证据；
  • [ ] L3 能不看文档说完整的 Context、Tool、Policy、Observation 与停止链；
  • [ ] L4 能从固定 Commit 定位入口、Loop、Tool、安全、State，并说明项目文件 Git 边界；
  • [ ] L5 能完成现象、影响、证据、根因、止损、修复、验证和防复发闭环；
  • [ ] L6 能给条件性选型并主动指出公开 Benchmark 的反向证据；
  • [ ] L7 能把架构、难点、亮点、风险、评测和演进说成 2～3 分钟项目回答；
  • [ ] 每题的小白解释都有角色、目标、动作、结果、技术映射和类比边界；
  • [ ] 按准确性、原理深度、工程意识、项目表达、沟通结构各 0～5 分复盘；
  • [ ] 任一动态事实不确定时记录版本、Commit 和待查证项，不用猜测补齐。

建议评分：

维度1 分3 分5 分
准确性把模型和产品混为一谈主链正确但有边界遗漏事实、源码、推断和未知严格分开
原理深度只说“会调用工具”能讲 Tool Result 回灌能讲 Thread/Turn、Cache、Compaction 与 Tool 主链
工程意识只关注生成代码提到测试和权限有幂等、可观测、恢复、并行和风险演练
项目表达罗列功能有背景、方案和结果有约束难点、证据亮点、故障与演进
沟通结构长篇无结论结论后能展开30 秒、90 秒和项目层次清晰，主动说明边界

5. 事实边界与参考资料 ​

当前无法确认｜ 模型权重、完整训练数据与 Reward；Cloud 调度和容器基础设施全部细节；Desktop App 与 IDE 全量源码；Auto-review 全部阈值；每项优化的独立因果增益；同版本、同权限、同预算的长期独立竞品胜率。

所有动态产品事实访问于 2026-07-11。面试前应重新核对默认模型、版本、权限模式、Feature Maturity 和 Benchmark。

6. 总结 ​

一句话记忆： Codex 专项面试要从“模型、开源 Runtime、产品族”出发，沿 Context、Agent Loop、Tool、安全、State、故障和评测七层推进，最后用证据而不是品牌回答“为什么强”。

  • L1～L2 先建立概念和证据边界；
  • L3～L4 用固定源码 Commit 讲清 Loop、工具主链与项目文件；
  • L5 必须完成生产故障的证据闭环，不能把失败一律归因于模型；
  • L6 用工作流、透明度、安全、生态、成本和隐藏测试做条件性选型；
  • L7 把模型能力放入受控 Runtime，并用验证成功率、人工干预、总成本、风险和恢复时间验收。