面试题库

Codex 与 OpenAI Agents SDK 高效使用

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
• 平台内置的工具（web search、file search、computer use）和自己写的函数工具，各适合什么场景？为什么 computer use 要单独对待？When do you use platform built-in tools (web search, file search, computer use) versus your own function tools, and why does computer use deserve special treatment?

  国内高频海外高频进阶#tools#responses-api#security

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

  1. 题眼有两个：一是「谁来执行」，二是「副作用有多大」。只答功能对比不谈执行方与风险，就是没做过工程。
  2. 先给执行方的判据：内置工具由平台在服务端执行，你只声明、不回填、也控制不了它怎么搜；函数工具由你执行，样样自己写，但每一步都在你手里。
  3. 落到场景：数据在外面且通用（公网、你上传的文档）用内置工具；数据在你系统里（数据库、内部服务、业务逻辑）写函数；生产系统几乎总是混用。
  4. 再按副作用排一条光谱：web search 只读公网，file search 只读你给的文件，函数调用的副作用由你的代码决定，computer use 由模型直接产生副作用——越往右能力越强，需要的隔离越重。
  5. computer use 单独对待的原因：它能点任何按钮、输任何文字，还可能被页面内容诱导，所以正确起点是隔离环境、受限账号和站点与动作白名单，不是代码。
  6. 可预期的追问：内置的 file search 和自己搭 RAG 怎么选？前者是托管版，省掉切分、向量化、检索三步，代价是可控性与可观测性弱，需要自定义切分或重排时才自己搭。

  How to reason about it · think before answering

  1. Two cruxes: who executes the tool, and how large its side effects are; comparing features alone signals no production experience.
  2. Executor test: built-in tools run server-side, you declare but never fill results and cannot steer the search; function tools run in your code, more work but full control.
  3. Map to scenarios: external, generic data (the web, your uploaded documents) fits built-ins; data inside your systems (databases, internal services, business logic) needs functions; production mixes both.
  4. Order by side effects: web search reads the public web, file search reads your files, function calls have whatever side effects your code allows, computer use lets the model act directly; more capability demands heavier isolation.
  5. Computer use is special because it can click anything, type anything and be steered by on-screen content, so the starting point is an isolated environment, a restricted account and an allow-list, not code.
  6. Expect the follow-up: built-in file search versus your own RAG? The built-in is a managed pipeline that skips chunking, embedding and retrieval work at the cost of control and observability; build your own when you need custom chunking or reranking.

  答题要点

  • 内置工具由平台执行、不用回填、不可干预；函数工具由你执行、全部可控
  • 外部通用数据用内置工具，系统内数据与业务逻辑写函数，生产混用
  • 按副作用排序：web search、file search、函数调用、computer use，能力越强隔离越重
  • computer use 的起点是隔离环境与白名单，不是代码

  Key points

  • Built-ins run on the platform with no result filling and no steering; functions run in your code with full control
  • External generic data suits built-ins, in-system data and business logic need functions, production mixes both
  • Rank by side effects: web search, file search, function calls, computer use; more power needs more isolation
  • Computer use starts with an isolated environment and an allow-list, not with code
• 结构化输出的 strict 模式解决了什么问题，没解决什么问题？拿到输出之后代码里还要做什么？What does strict mode in structured outputs solve, what does it not solve, and what must your code still do after receiving the output?

  国内高频海外高频进阶#structured-output#responses-api#validation

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

  1. 这题考的是对「格式正确」与「内容正确」的区分，答成「有了 strict 就不用校验了」是典型的错误。
  2. 先说解决了什么：strict 加 json_schema 保证输出一定能通过 schema 校验——枚举只会是给定值、必填字段一定在、类型不会错，解析层的 try/catch 与重试基本可以删掉。
  3. 再说没解决什么：schema 管不了语义。verdict 一定是两个枚举之一，但判断可能是错的；数字一定是数字，但可能是编的。业务层校验一行不能省。
  4. 然后是拒答分支：模型因安全原因拒绝时返回 refusal 类型的内容块，而不是硬塞一个不合法的 JSON；不处理它，下游会拿到空的解析结果直接崩，处理了才能区分「不愿意」与「没做对」。
  5. 给出代码里的顺序：先查 refusal，再读 output_parsed，再做业务校验（范围、引用是否存在、与上下文是否一致），最后才落库或执行。
  6. 可预期的追问：strict 对 schema 有什么限制？每个对象都要 additionalProperties 为 false、字段都要在 required 里，可选字段用可空类型表达；这些限制正是它能给出保证的原因。

  How to reason about it · think before answering

  1. This tests the distinction between well-formed and correct; claiming strict mode removes the need for validation is the classic mistake.
  2. What it solves: strict plus json_schema guarantees the output validates against the schema, so enums are always allowed values, required fields exist and types are right; parsing-layer try/catch and retries can largely go.
  3. What it does not solve: semantics. The verdict is one of two enums but may be wrong; a number is a number but may be invented. Business validation stays.
  4. Then refusals: a safety refusal comes back as a refusal content block, not malformed JSON; unhandled, downstream code crashes on an empty parse, handled, you can separate unwilling from incorrect.
  5. Give the order in code: check refusal, read output_parsed, run business checks (ranges, referenced entities exist, consistency with context), then persist or act.
  6. Expect the follow-up: schema restrictions under strict? Every object needs additionalProperties false and all fields in required, optional fields become nullable; these constraints are exactly what makes the guarantee possible.

  答题要点

  • 解决：输出保证符合 schema，解析层防御代码可以删
  • 没解决：语义正确性，业务校验一行不能省
  • 先查 refusal 再读 output_parsed，再做业务校验，最后落库
  • strict 要求 additionalProperties 为 false、字段全在 required 里，可选用可空类型表达

  Key points

  • Solves: output is guaranteed to match the schema, so parsing defenses can go
  • Does not solve: semantic correctness, so business validation stays
  • Check refusal first, then output_parsed, then business checks, then persist
  • Strict requires additionalProperties false and all fields required, optional fields become nullable