面试题库

Codex 与 OpenAI Agents SDK 高效使用

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

• 平台内置的工具（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