面试题库

Codex 与 OpenAI Agents SDK 高效使用

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

• Codex 把「什么时候问用户」和「能碰到什么」拆成 approval_policy 和 sandbox_mode 两组独立开关。为什么要拆？各自解决什么问题？Codex splits 'when to ask the user' and 'what can be touched' into two independent settings, approval_policy and sandbox_mode. Why separate them, and what does each solve?

  国内高频海外高频进阶#coding-agent#security#sandbox

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

  1. 题眼是「为什么拆」。只背出每组的取值等于没答，面试官要听的是两者正交带来的好处。
  2. 先给定义：审批策略是流程控制，决定动作执行前要不要人点头；沙箱是权限控制，决定即使模型想做、操作系统允不允许。
  3. 再说为什么正交：你可能想要「不打扰我，但绝不许出工作区」（on-request 加 workspace-write），也可能想要「每步都问，但只让它读」（untrusted 加 read-only）；合成一个滑杆就表达不了这两种组合。
  4. 落到实现：沙箱靠操作系统机制（macOS Seatbelt、Linux bubblewrap），不是靠模型自觉，所以它是硬约束；审批则是唯一由人把关的环节。
  5. 可预期的追问：为什么网络默认关？因为联网是把内部代码送出去或把外部代码拉进来的通道，风险等级和改本地文件不同，需要单独授权。

  How to reason about it · think before answering

  1. The discriminating part is 'why separate'; reciting the values without explaining orthogonality earns little.
  2. Define both: approval policy is process control, whether a human must nod before an action; sandbox is permission control, whether the OS allows the action at all.
  3. Then justify orthogonality with combinations a single slider cannot express: 'do not interrupt me but never leave the workspace' versus 'ask every time but read-only'.
  4. Ground it in implementation: the sandbox uses OS mechanisms (Seatbelt on macOS, bubblewrap on Linux) rather than model goodwill, so it is a hard limit, while approval is the one human checkpoint.
  5. Expect the follow-up: why is network off by default? Because network is the channel for code leaving or entering the machine, a different risk class from local edits.

  答题要点

  • approval_policy 管流程：untrusted / on-request / on-failure / never 决定动作前是否要人确认
  • sandbox_mode 管权限：read-only / workspace-write / danger-full-access 决定操作系统放行什么
  • 两者正交才能表达「不打扰但不越界」和「步步问但只读」这类组合
  • 沙箱是操作系统级硬约束，审批是唯一的人工把关点；网络默认关闭需单独放开

  Key points

  • approval_policy governs process: untrusted / on-request / on-failure / never decide whether a human confirms first
  • sandbox_mode governs permission: read-only / workspace-write / danger-full-access decide what the OS allows
  • Orthogonality lets you express 'no interruptions but stay in the workspace' and 'ask each step but read-only'
  • The sandbox is an OS-level hard limit, approval is the human checkpoint, and network is off by default
• 你要在团队里引入一个能在本地执行命令的 coding agent，怎么向不放心的同事解释它的风险边界？You want to introduce a coding agent that runs commands locally. How do you explain its risk boundary to skeptical teammates?

  国内高频海外高频进阶#coding-agent#security#communication

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

  1. 这题考的是沟通加工程两层：既要说清技术上的边界，又要用对方能验证的方式说，不能只说「它很安全」。
  2. 拆成三层防线来讲：第一层文字规则（AGENTS.md）管习惯；第二层沙箱管能力，只读或只能写工作区、网络默认关；第三层审批管例外，越界的每一步都要人批。
  3. 给出可验证的承诺：所有改动都在 git 工作区里，`git diff` 能看、`git checkout` 能撤；脱手运行只跑在一次性分支或容器里。
  4. 主动说出剩余风险：模型可能误读需求写出错误但能通过的代码，所以审查和测试不能省；密钥不要放在它能读到的文件里。
  5. 可预期的追问：能不能完全禁止它联网？可以，沙箱默认就不通网，需要装依赖时逐次批准，或在配置里给一个允许的域名清单。

  How to reason about it · think before answering

  1. This tests communication as much as engineering: state the technical boundary in terms the listener can verify, not just 'it is safe'.
  2. Present three layers of defense: written rules (AGENTS.md) shape habits; the sandbox limits capability to read-only or workspace-only writes with network off; approvals gate every exception.
  3. Offer verifiable guarantees: every change lands in the git working tree, visible via diff and revertable via checkout; unattended runs stay on throwaway branches or containers.
  4. Name the residual risk yourself: the model can misread a requirement and produce wrong but passing code, so review and tests remain mandatory, and secrets stay out of readable files.
  5. Expect the follow-up: can network be fully blocked? Yes, the sandbox is offline by default; approve installs case by case or configure an allow-list of domains.

  答题要点

  • 三层防线：文字规则管习惯、沙箱管能力、审批管例外
  • 改动全在 git 工作区，可 diff 可撤销；脱手运行只在一次性分支或容器
  • 主动说明剩余风险：错误但能通过的代码、密钥暴露，所以审查与测试不能省
  • 网络默认关闭，联网按次批准或配置允许域名清单

  Key points

  • Three layers: written rules for habits, the sandbox for capability, approvals for exceptions
  • All edits live in the git working tree and are diffable and revertable; unattended runs use throwaway branches or containers
  • State residual risks yourself: wrong-but-passing code and secret exposure, hence mandatory review and tests
  • Network is off by default; approve per request or configure an allow-list

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