面试题库

Codex 与 OpenAI Agents SDK 高效使用

D1 Codex CLI 入门：安装、AGENTS.md、审批模式与沙箱、常用命令

• 给 coding agent 写的项目说明文件（比如 Codex 的 AGENTS.md）应该写什么、不该写什么？为什么它要有大小上限？What belongs in a project instruction file for a coding agent (such as Codex's AGENTS.md), what does not, and why is there a size limit?

  国内高频海外高频基础#coding-agent#context#agents-md

  分析过程 · 先想清楚再作答

  1. 这题考的不是文件格式，而是你对「上下文是有限资源」有没有工程直觉。把它答成「写项目介绍」会被判为没真用过。
  2. 拆法是一个判断句：这条信息 agent 打开文件自己能不能发现？能发现的不写（目录结构、用了什么框架），发现不了的才写（约定、禁区、环境事实、测试命令）。
  3. 再补一层查找规则：全局层在用户目录，项目层从根目录到当前目录依次拼接，越靠近当前目录越靠后、越优先，所以子目录可以覆盖根规则。
  4. 大小上限（Codex 默认 32 KiB）的意义是逼你做取舍：手册太长会挤占任务本身的上下文，还会让模型对每一条规则的遵守度下降。
  5. 可预期的追问：写在说明文件里的规则模型一定会遵守吗？不一定，它是提示词的一部分，会被长对话稀释；硬约束要靠沙箱与审批，不是靠文字。

  How to reason about it · think before answering

  1. This probes whether you treat context as a scarce resource, not whether you know the file format; answering with a project overview signals inexperience.
  2. Use one test: can the agent discover this by opening files? If yes, leave it out (directory layout, framework); if no, write it down (conventions, no-go areas, environment facts, test commands).
  3. Add the lookup rules: a global file in the home directory, then project files concatenated from the repo root down to the current directory, so closer files override earlier ones.
  4. The size cap (32 KiB by default in Codex) forces prioritization: a long manual crowds out the task and dilutes adherence to every rule.
  5. Expect the follow-up: will the model always obey the file? No, it is prompt text and fades over long sessions; hard limits belong to the sandbox and approvals.

  答题要点

  • 写约定、禁区、环境事实和验证命令；不写 agent 自己打开文件就能发现的内容
  • 查找顺序是全局文件在前、项目文件从根到当前目录拼接，越靠近当前目录越优先
  • 大小上限逼你只保留高价值信息，避免挤占任务上下文、降低规则遵守度
  • 文字规则是建议性的，真正不能越的线交给沙箱与审批

  Key points

  • Write conventions, no-go areas, environment facts and verification commands; skip anything discoverable from the files
  • Lookup goes global first, then project files concatenated root-down, with closer files taking precedence
  • The size cap forces you to keep only high-value guidance so the task itself keeps its context budget
  • Instruction files are advisory; hard limits come from the sandbox and approval policy

D2 Codex 进阶：云端任务、代码审查、MCP 接入、自定义指令、IDE 集成

• MCP server 和 skill 都是在给 coding agent 加能力，什么时候该用哪一个？项目说明文件又放什么？MCP servers and skills both extend a coding agent. When do you reach for each, and what goes in the project instruction file instead?

  国内高频海外高频基础#mcp#skills#coding-agent

  分析过程 · 先想清楚再作答

  1. 这题考的是抽象层次的区分，是国内面试开始高频出现的「Function Call / MCP / Skills 三者区别」的工具侧版本。
  2. 拆法是问「加的是什么」：加的是访问外部系统的能力（查工单、读数据库、调内部服务）就是 MCP，它是协议层的工具；加的是一套多步骤的做法（发版检查、迁移流程）就是 skill，它是提示词层的流程包；每次会话都要遵守的约定就是项目说明文件。
  3. 再给触发方式的差别：MCP 工具由模型在需要数据时调用；skill 由用户显式点名或由模型按描述匹配；说明文件每次会话开头无条件读入。
  4. 结论落到一句话：规矩归说明文件、外部系统归 MCP、流程归 skill；同一件事只放一处，避免三处互相矛盾。
  5. 可预期的追问：skill 里能不能调 MCP 工具？可以，skill 的步骤里可以要求使用某个工具，两者是正交的层次，不是替代关系。

  How to reason about it · think before answering

  1. This tests separation of abstraction levels, the tooling-side version of the increasingly common 'function calling vs MCP vs skills' question.
  2. Ask what is being added: access to an external system (tickets, databases, internal services) is MCP, a protocol-level tool; a multi-step procedure (release checklist, migration flow) is a skill, a prompt-level workflow package; conventions to obey every session belong in the instruction file.
  3. Contrast triggers: MCP tools are invoked by the model when it needs data; skills are invoked explicitly by name or matched by description; instruction files are loaded unconditionally at session start.
  4. Conclude: rules in the instruction file, external systems via MCP, procedures as skills; keep each fact in one place to avoid contradictions.
  5. Expect the follow-up: can a skill use MCP tools? Yes; a skill's steps can call for a tool, the layers are orthogonal, not substitutes.

  答题要点

  • MCP 加的是访问外部系统的工具，由模型按需调用
  • skill 加的是多步骤流程，由用户点名或按描述匹配触发
  • 项目说明文件放每次会话都要遵守的约定、禁区与环境事实
  • 三者正交：规矩、外部系统、流程各放一处，skill 里可以要求用某个 MCP 工具

  Key points

  • MCP adds tools that reach external systems, invoked by the model on demand
  • Skills add multi-step procedures, triggered by name or matched by description
  • The instruction file holds conventions, no-go areas and environment facts read every session
  • The three are orthogonal: rules, external systems, procedures each live in one place; a skill may call for an MCP tool

D3 Responses API 与内置工具：函数调用、web search / file search / computer use、结构化输出

• Responses API 和 Chat Completions 的区别是什么？从 Chat Completions 迁移过去最容易踩什么坑？How does the Responses API differ from Chat Completions, and what are the common pitfalls when migrating?

  国内高频海外高频基础#responses-api#openai#migration

  分析过程 · 先想清楚再作答

  1. 这题考的是你有没有真迁移过，而不是能不能背出字段名。只答「新接口更强」会被判为看过文档没写过代码。
  2. 拆成三个维度：输入形态（messages 数组变成 input 加顶层 instructions）、输出形态（choices 变成按类型排列的 output items，SDK 给 output_text 助手）、状态管理（无状态变成默认 store 加 previous_response_id）。
  3. 再说为什么要改：聊天记录模型装不下工具动作；items 让搜索、函数调用、回填各有自己的类型，这是内置工具能接进来的前提。
  4. 迁移坑给三条：默认 store 为 true 意味着数据会被存下来，合规场景要显式关掉；output 是数组不是单个消息，取文本要用 output_text 或遍历 message item；函数调用的回填从 role 为 tool 的消息变成 function_call_output item，call_id 要对上。
  5. 可预期的追问：previous_response_id 和自己维护历史怎么选？原型用前者省事，生产多半自己落一份历史做审计与恢复，或两者混用。

  How to reason about it · think before answering

  1. This tests whether you have actually migrated code, not whether you can recite field names.
  2. Split into three axes: input shape (messages array becomes input plus top-level instructions), output shape (choices becomes typed output items with an output_text helper), and state (stateless becomes store by default plus previous_response_id).
  3. Explain the motivation: a chat-transcript model cannot hold tool actions; items give search, function calls and their outputs distinct types, which is what makes built-in tools possible.
  4. Name three pitfalls: store defaults to true so compliance-sensitive apps must disable it; output is an array, so read output_text or walk message items; tool results move from role tool messages to function_call_output items keyed by call_id.
  5. Expect the follow-up: previous_response_id versus self-managed history? Prototypes take the former; production usually keeps its own history for audit and recovery, or mixes both.

  答题要点

  • 输入：messages 变 input 加顶层 instructions；输出：choices 变按类型排列的 output items 与 output_text
  • 状态：默认 store 为 true，用 previous_response_id 接上一轮，不再每轮重发历史
  • 改的动机是给工具动作独立的 item 类型，内置工具由此接入
  • 迁移坑：store 默认开、output 是数组、回填要用 function_call_output 且 call_id 对上

  Key points

  • Input: messages become input plus top-level instructions; output: choices become typed output items plus output_text
  • State: store defaults to true and previous_response_id chains turns without resending history
  • The motivation is distinct item types for tool actions, enabling built-in tools
  • Pitfalls: store on by default, output is an array, tool results go back as function_call_output keyed by call_id