Interview Bank

Mastering Codex and the OpenAI Agents SDK in 5 Days

D1 Getting Started With the Codex CLI: Install, AGENTS.md, Approval Modes and the Sandbox, Common Commands

• 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 写的项目说明文件（比如 Codex 的 AGENTS.md）应该写什么、不该写什么？为什么它要有大小上限？

  Common in ChinaCommon overseasBasic#coding-agent#context#agents-md

  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.

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

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

  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

  答题要点

  • 写约定、禁区、环境事实和验证命令；不写 agent 自己打开文件就能发现的内容
  • 查找顺序是全局文件在前、项目文件从根到当前目录拼接，越靠近当前目录越优先
  • 大小上限逼你只保留高价值信息，避免挤占任务上下文、降低规则遵守度
  • 文字规则是建议性的，真正不能越的线交给沙箱与审批
• 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?Codex 把「什么时候问用户」和「能碰到什么」拆成 approval_policy 和 sandbox_mode 两组独立开关。为什么要拆？各自解决什么问题？

  Common in ChinaCommon overseasIntermediate#coding-agent#security#sandbox

  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.

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

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

  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

  答题要点

  • approval_policy 管流程：untrusted / on-request / on-failure / never 决定动作前是否要人确认
  • sandbox_mode 管权限：read-only / workspace-write / danger-full-access 决定操作系统放行什么
  • 两者正交才能表达「不打扰但不越界」和「步步问但只读」这类组合
  • 沙箱是操作系统级硬约束，审批是唯一的人工把关点；网络默认关闭需单独放开
• You want to introduce a coding agent that runs commands locally. How do you explain its risk boundary to skeptical teammates?你要在团队里引入一个能在本地执行命令的 coding agent，怎么向不放心的同事解释它的风险边界？

  Common in ChinaCommon overseasIntermediate#coding-agent#security#communication

  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.

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

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

  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

  答题要点

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

D2 Codex, Level Up: Cloud Tasks, Code Review, MCP Integration, Custom Instructions, IDE Integration

• A cloud coding agent can run many tasks in parallel with nobody around to approve steps. Where should its approval boundary sit?云端 coding agent 能同时跑很多任务，但没有人在旁边点头。它的审批边界应该画在哪里？

  Common in ChinaCommon overseasIntermediate#coding-agent#cloud#approvals

  How to reason about it · think before answering

  1. This checks whether you noticed the approval model changed: local means step-by-step approval, cloud means authorize upfront and review afterwards.
  2. Split the boundary across three moments: before the task (environment config decides network, variables, dependencies), during (container isolation), after (a human reviews the diff before any PR).
  3. Conclude that the cloud boundary is two gates, environment config plus pre-PR human review, with nobody in between; hence no production secrets, network off by default, merge rights stay human.
  4. Add the engineering angle: draw boundaries between parallel tasks too; tasks that touch the same files should not run concurrently.
  5. Expect the follow-up: can it auto-merge? Only in low-risk repos for fully green PRs, with rollback in place, and treat enabling auto-merge as a change that itself needs approval.

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

  1. 这题考的是你有没有意识到「审批模型变了」：本地是逐步审批，云端只能事先授权、事后审阅。答成「跟本地一样弹窗」说明没用过。
  2. 拆法是把边界分成三个时间点：任务开始前（环境配置决定能联网什么、有哪些变量、装什么依赖）、任务执行中（容器隔离，改动只在容器里）、任务结束后（人审 diff 再决定开不开 PR）。
  3. 结论是：云端的审批边界就是「环境配置 + PR 前人工审阅」这两道门，中间不再有人；所以生产密钥不能进环境、公网默认关、合并权限保留在人手里。
  4. 补一条工程视角：并行任务之间的边界也要画——互相会改同一批文件的任务不要同时派，否则合并成本吃掉并行收益。
  5. 可预期的追问：能不能让它自动合并？可以在低风险仓库对通过全部测试的 PR 这么做，但要保留回滚手段，并且把「自动合并」本身当成一个需要审批的配置变更。

  Key points

  • No step-wise approval in the cloud; the boundary becomes upfront environment config plus post-hoc human review
  • Keep production secrets out, network off by default, merge rights with humans
  • Draw boundaries between parallel tasks: never run file-overlapping tasks concurrently
  • Auto-merge only for low-risk repos with fully green PRs, with rollback ready

  答题要点

  • 云端没有逐步审批，边界变成事前的环境配置与事后的人工审阅两道门
  • 环境里不放生产密钥、公网默认关、合并权限保留给人
  • 并行任务之间也要画边界：会改同一批文件的任务不同时派
  • 自动合并只适用于低风险仓库且全绿的 PR，并保留回滚
• If the same model both writes and reviews code, is the review still meaningful? How do you make it more independent?让同一个模型既写代码又审代码，审查还有意义吗？怎么让审查更独立？

  Common in ChinaCommon overseasIntermediate#code-review#coding-agent#workflow

  How to reason about it · think before answering

  1. The crux is 'still meaningful'; a flat yes or no fails. Explain what it catches and what it misses.
  2. What it catches: the input changes (diff instead of requirements) and the stance changes (find faults instead of finish the job), which surfaces missed edge cases, unsynced callers and style violations.
  3. What it misses: reviewer and author share one understanding of the requirement, so a misread requirement passes; they share blind spots too.
  4. Conclude with three independence levers: review with a different vendor's model, feed the reviewer different information (original requirement plus acceptance criteria, not just the diff), and run deterministic checks first.
  5. Expect the follow-up: auto-apply review comments? No; review is input, not verdict, and both false positives and misses exist.

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

  1. 题眼在「还有意义吗」——直接答「没意义」或「有意义」都不及格，要说清它能抓什么、抓不到什么。
  2. 先说能抓的：审查时输入变了（看 diff 而不是需求）、立场变了（找问题而不是完成任务），这种角色切换能抓出漏掉的边界情况、没同步的调用方、明显的风格违规。
  3. 再说抓不到的：审查者和生成者共享同一份对需求的理解，需求理解错了两边一起错；也共享同样的盲区与偏好。
  4. 结论给三条提高独立性的手段：换一家模型审、给审查者不同的信息（需求原文加验收标准而不是只给 diff）、用确定性工具（测试、lint、类型检查）做第一道审查。
  5. 可预期的追问：审查意见要不要自动应用？不要，审查是输入不是判决，误报与漏报都存在，最终判断留给人。

  Key points

  • Yes: the switch of input and stance catches edge cases, unsynced callers and style issues
  • It misses requirement misreads because author and reviewer share one understanding
  • Increase independence: a different vendor's model, richer reviewer context, deterministic checks first
  • Treat comments as input, never auto-apply

  答题要点

  • 有意义：输入与立场的切换能抓出边界情况、未同步的调用方、风格违规
  • 抓不到与需求理解相关的错误，因为审查者与生成者共享同一份理解
  • 提高独立性：换一家模型审、给审查者需求原文与验收标准、先跑确定性检查
  • 审查意见是输入不是判决，不要自动应用
• 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 server 和 skill 都是在给 coding agent 加能力，什么时候该用哪一个？项目说明文件又放什么？

  Common in ChinaCommon overseasBasic#mcp#skills#coding-agent

  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.

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

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

  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

  答题要点

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

D3 The Responses API and Built-in Tools: Function Calling, Web Search / File Search / Computer Use, Structured Output

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

  Common in ChinaCommon overseasBasic#responses-api#openai#migration

  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.

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

  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 和自己维护历史怎么选？原型用前者省事，生产多半自己落一份历史做审计与恢复，或两者混用。

  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

  答题要点

  • 输入：messages 变 input 加顶层 instructions；输出：choices 变按类型排列的 output items 与 output_text
  • 状态：默认 store 为 true，用 previous_response_id 接上一轮，不再每轮重发历史
  • 改的动机是给工具动作独立的 item 类型，内置工具由此接入
  • 迁移坑：store 默认开、output 是数组、回填要用 function_call_output 且 call_id 对上
• 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?平台内置的工具（web search、file search、computer use）和自己写的函数工具，各适合什么场景？为什么 computer use 要单独对待？

  Common in ChinaCommon overseasIntermediate#tools#responses-api#security

  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.

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

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

  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

  答题要点

  • 内置工具由平台执行、不用回填、不可干预；函数工具由你执行、全部可控
  • 外部通用数据用内置工具，系统内数据与业务逻辑写函数，生产混用
  • 按副作用排序：web search、file search、函数调用、computer use，能力越强隔离越重
  • computer use 的起点是隔离环境与白名单，不是代码
• What does strict mode in structured outputs solve, what does it not solve, and what must your code still do after receiving the output?结构化输出的 strict 模式解决了什么问题，没解决什么问题？拿到输出之后代码里还要做什么？

  Common in ChinaCommon overseasIntermediate#structured-output#responses-api#validation

  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.

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

  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 里，可选字段用可空类型表达；这些限制正是它能给出保证的原因。

  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

  答题要点

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

D4 The OpenAI Agents SDK: Agents, Handoffs, Guardrails, Sessions, Tracing

• When should you split one agent into several connected by handoffs, and when is a single agent with many tools the better design?什么时候该把一个 Agent 拆成多个、用 handoff 交接？什么时候「一个大 Agent 加很多工具」反而更好？

  Common in ChinaCommon overseasIntermediate#agents-sdk#handoffs#architecture

  How to reason about it · think before answering

  1. This tests your splitting criterion, not API fluency; 'split when there are many tools' is the common wrong answer.
  2. First separate handoffs from tools: a tool call fetches an answer and returns; a handoff transfers the whole conversation so the receiving agent owns it, even though it is implemented as a transfer_to_xxx tool.
  3. The criterion is whether instructions conflict: when two task groups need independent, clashing background, constraints and tone, one instruction block forces constant context switching, longer prompts and more errors, so split; many tools sharing one background do not justify a split.
  4. Name the costs: an extra model call for triage, possible misrouting, input guardrails only on the first agent, and history trimming across agents via inputFilter.
  5. Expect the follow-up: what if triage misroutes? Use RECOMMENDED_PROMPT_PREFIX, assert on lastAgent in regression tests, inspect the handoff turn in tracing, and allow experts to hand back.

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

  1. 这题考的是拆分判据，不是会不会用 API。答「工具多了就拆」是最常见的错误，工具数量不是判据。
  2. 先说清 handoff 与工具的区别：调工具是替你去问一句再回来，handoff 是把对话整个交给另一个 Agent，之后由它负责；实现上 handoff 也是一个名为 transfer_to_xxx 的工具，但语义是转移控制权。
  3. 判据是「指令会不会互相打架」：两组任务需要的背景知识、约束、语气彼此独立且冲突时，塞进一份 instructions 会让模型反复切换上下文、提示越长越贵、出错率上升，这时拆；工具虽多但共享同一套背景的，不拆。
  4. 补拆分的代价：多一次模型调用（分诊那一跳）、路由可能错、输入护栏只在第一个 Agent 上跑、跨 Agent 的历史要靠 inputFilter 裁剪。
  5. 可预期的追问：分诊错了怎么办？用 RECOMMENDED_PROMPT_PREFIX 提高交接准确率，用 lastAgent 做回归断言，用 tracing 看交接发生在哪一轮，必要时让专家 Agent 也能交接回分诊台。

  Key points

  • A handoff transfers conversational control; a tool call only fetches a result
  • Split on conflicting instructions, not on tool count
  • Costs: an extra hop, possible misrouting, input guardrails only on the first agent
  • Control routing quality with the recommended prefix, lastAgent assertions and tracing

  答题要点

  • handoff 转移的是对话控制权，工具调用只是取一次结果
  • 拆分判据是指令是否互相打架，不是工具数量
  • 拆的代价：多一跳、可能路由错、输入护栏只在第一个 Agent 生效
  • 用前缀提示、lastAgent 断言与 tracing 控制路由质量
• Should guardrails sit on the input side or the output side? What does each cost, what does it catch, and what slips through?guardrail 应该放在输入侧还是输出侧？各自的成本、能拦住什么、拦不住什么？

  Common in ChinaCommon overseasDeep dive#agents-sdk#guardrails#safety

  How to reason about it · think before answering

  1. The crux is 'what slips through'; saying 'use both' without naming each side's blind spot signals no production incidents survived.
  2. Division of labor: input guardrails decide whether to act at all (off-topic, obvious injection, out of scope) and are cheapest early; output guardrails decide whether the answer may be said (leaks, format, policy) and can only run after generation.
  3. Cost: input guardrails run in parallel with the main agent and cancel its expensive run on a tripwire, so a cheap classifier there saves money; output guardrails wait for the full run and only prevent incidents.
  4. Blind spots: input cannot catch a normal question with a drifting answer; output cannot undo a side-effecting tool already called, hence a third layer of tool-level guardrails around each function call.
  5. Add the SDK constraint: input guardrails run only on the first agent, output guardrails only on the agent producing the final answer; misplaced guardrails never execute.
  6. Expect the follow-up: the common failure mode? Too strict, not too loose; regex blocklists over-block real users, so keep a regression set of legitimate requests and watch the false-block rate.

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

  1. 题眼在「拦不住什么」。只说两边都要放而不说各自的漏网情况，就是没在生产里被漏网案例打过脸。
  2. 先给分工：输入侧管「该不该做」——话题越界、明显注入、超出服务范围，越早拦越省；输出侧管「能不能说」——泄露敏感信息、格式不合规、违反业务规则，只有模型说完才能查。
  3. 再说成本：输入护栏与主 Agent 并行跑，警报一响就取消主 Agent 的昂贵运行，所以用便宜小模型做输入护栏是省钱手段；输出护栏必须等主 Agent 跑完，省不了钱，只能防事故。
  4. 漏网情况：输入侧拦不住「问题正常但回答跑偏」；输出侧拦不住「模型已经调了有副作用的工具」——所以有副作用的工具需要第三层，围着每次函数调用跑的工具级护栏。
  5. 补一条 SDK 约束：输入护栏只在链条第一个 Agent 上跑，输出护栏只在产出最终回答的 Agent 上跑，挂错位置等于没挂。
  6. 可预期的追问：护栏最常见的失败模式是什么？太严而不是太松——正则黑名单误拦正常用户；上线前要有正常请求的回归集，误拦率是必看指标。

  Key points

  • Input side decides whether to act and is cheapest early; output side decides what may be said and only runs afterwards
  • Input guardrails run in parallel and cancel the main run, so cheap models save money there; output guardrails only prevent incidents
  • Input misses drifting answers, output misses side effects already taken; tool-level guardrails add the third layer
  • Input guardrails run only on the first agent; the common failure is over-blocking, so keep a regression set

  答题要点

  • 输入侧管该不该做，越早拦越省；输出侧管能不能说，只能事后查
  • 输入护栏与主 Agent 并行、触发即取消，便宜模型在此省钱；输出护栏省不了钱只防事故
  • 输入侧漏「回答跑偏」，输出侧漏「已调有副作用的工具」，需工具级护栏补第三层
  • 输入护栏只在第一个 Agent 生效；常见失败是太严，需正常请求回归集
• Both Agents SDK sessions and the Responses API's previous_response_id remember multi-turn state. How do you choose, and what role does tracing play?Agents SDK 的 session 和 Responses API 的 previous_response_id 都能记住多轮，怎么选？tracing 在这里起什么作用？

  Common in ChinaCommon overseasIntermediate#agents-sdk#sessions#tracing

  How to reason about it · think before answering

  1. This probes your sensitivity to who holds the state, the SDK-level echo of 'you carry the history yourself'.
  2. Ask three questions: can the history be audited, trimmed or replayed, and kept within data-residency rules? previous_response_id keeps history server-side with minimal requests but answers all three poorly; sessions keep it in your store and answer all three, at the cost of managing storage.
  3. Conclude: prototypes and internal tools take previous_response_id; user-facing production keeps its own copy, for which sessions are the ready-made path; both can coexist.
  4. Of the four session operations, pop_item deserves mention: removing the last turn to honor a user's undo is only possible when you own the history.
  5. Tracing makes multi-agent behavior explainable: on by default, one trace per run recording turns, tool calls, handoffs and guardrail results; group a conversation with withTrace or group_id; disable via env var or swap in your own exporter for sensitive data.
  6. Expect the follow-up: does tracing ship user data out? By default it goes to the platform dashboard, so regulated settings must disable it or replace the processors.

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

  1. 这题考的是对「状态放在谁手里」的敏感度，是 30 天课 D1「历史靠你自己搬」在 SDK 层的翻版。
  2. 拆法是问三件事：历史能不能审计、能不能裁剪或重放、能不能满足数据驻留要求。previous_response_id 的历史在服务端，请求最小、代码最简，但三个问题都答不好；session 的历史在你手里（内存、SQLite、Redis），三个都能做，代价是自己管存储。
  3. 结论：原型与内部工具用 previous_response_id 省事；面向用户的生产系统至少自己落一份历史，session 是现成的落法；两者可以同时用。
  4. session 的四个接口（取、追加、弹出最后一条、清空）里 pop_item 值得点出：用户撤回上一句时把最后一轮拿掉再重跑，这是自己持有历史才能做的事。
  5. tracing 的作用是让多 Agent 系统的行为可解释：默认开启，每次 run 一条，记录每轮、每次工具调用、交接与护栏判断；用 withTrace 或 group_id 把一段对话归到一起；敏感数据场景用环境变量关掉或换成自己的导出器。
  6. 可预期的追问：tracing 会不会把用户数据传出去？默认会传到平台面板，所以合规场景要么关、要么 setTraceProcessors 换成自己的后端。

  Key points

  • previous_response_id keeps history server-side, small and simple, but weak on audit, trimming and residency
  • Sessions keep history in your store, auditable and replayable, with pop_item for undo; production keeps its own copy
  • Tracing is on by default, one trace per run, capturing turns, tools, handoffs and guardrails, grouped via group_id
  • For sensitive data disable it with OPENAI_AGENTS_DISABLE_TRACING or swap in your own exporter

  答题要点

  • previous_response_id 历史在服务端，请求小代码简，但难审计、难裁剪、难满足数据驻留
  • session 历史在自己手里，可审计可重放，pop_item 支持撤回；生产至少自己落一份
  • tracing 默认开、每次 run 一条，记录每轮工具、交接与护栏，用 group_id 归组
  • 敏感数据场景用 OPENAI_AGENTS_DISABLE_TRACING 关掉或换成自己的导出器

D5 Choosing and Combining Claude and Codex: A Real Side-by-Side on the Same Task, a Write-One-Review-One Mixed Workflow

• Your team must pick between two coding agents. How do you propose a comparison that teammates can both understand and verify?团队要在两家 coding agent 之间选一个，你怎么给出一套可以向团队解释、也能被验证的对比维度？

  Common in ChinaCommon overseasIntermediate#coding-agent#evaluation#decision-making

  How to reason about it · think before answering

  1. This tests methodology, not a verdict; leading with 'I prefer X' signals weak engineering judgment. Show how you make the comparison reproducible.
  2. Give the dimensions: instruction effort (prompt and instruction-file size), approvals (how many interruptions and why), verification (does it run tests unprompted, what happens on red), cost (time, tokens, money). All are measurable in your own repo.
  3. State the preconditions for comparability: same starting commit, identical requirement text, identical instruction-file content, default permissions, and 'run tests before reporting' on both sides.
  4. Then the reading order: check comparability, then structural differences (permission model, placement and wording of rules), and only then capability differences, which need several runs and a median.
  5. For the team: label every differing row as 'workflow' or 'capability'; workflow gaps are closed by configuration, capability gaps drive the choice.
  6. Expect the follow-up: why not benchmarks? They score standard problems with one number, while teams change legacy repos and care about four dimensions.

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

  1. 这题考的是方法论而不是结论。上来就说「我觉得 X 好」会被判为没有工程判断；面试官想听的是你怎么让比较可复现。
  2. 先给维度：交代（写多少需求、准备多少说明文件）、审批（中断几次、为了什么）、验证（是否主动跑测试、红了怎么办）、成本（时间、token、钱）。这四项都能在自己的仓库里量出来。
  3. 再给可比性的前置条件：同一个起点 commit、同一段需求文字、说明文件同内容、默认权限、都要求跑完测试再汇报；有一项不同，差异就说不清来源。
  4. 然后是读数的顺序：先查可比性，再看结构性差异（权限模型、说明文件的位置与措辞导致的行为差别），最后才看能力差异，而且能力差异要多次运行取中位数。
  5. 落到团队沟通：报告里每一行差异都标「来自工作方式还是能力」，工作方式的差异靠配置弥补，能力差异才影响选型。
  6. 可预期的追问：榜单为什么不够？榜单测标准题，团队干的是有历史包袱的仓库里的改动，且榜单只给一个分数、不给四个维度。

  Key points

  • Four measurable dimensions: instruction effort, approvals, verification, cost, all measured in your own repo
  • Comparability first: same commit, same prompt, same instruction file, default permissions, tests required
  • Read in order: comparability, structural differences, then capability, with medians over several runs
  • Label each gap as workflow or capability; only capability gaps should drive the decision

  答题要点

  • 四个可量维度：交代、审批、验证、成本，全部在自己仓库里测
  • 可比性前置：同起点、同需求、同说明文件、默认权限、都要求跑测试
  • 读数顺序：可比性、结构性差异、能力差异；能力差异要多次运行取中位数
  • 每行差异标「工作方式还是能力」，前者靠配置弥补，后者才决定选型
• Where does the 'one vendor writes, the other reviews' workflow pay off, and when is it not worth it?「一家写、另一家审」的混用工作流收益在哪？什么情况下不值得？

  Common in ChinaCommon overseasIntermediate#code-review#workflow#coding-agent

  How to reason about it · think before answering

  1. The crux is 'not worth it'; listing benefits without costs reads as never having sat in front of a budget.
  2. Source of value: when one model both writes and reviews, they share one reading of the requirement, so misreads slip through; a second vendor catches exactly those, plus complementary blind spots.
  3. How to make it pay: the reviewer needs the original requirement and acceptance criteria, not just the diff, or it degrades into lint; demand structured output so acceptance can be measured; a human makes the final call.
  4. Not worth it when the task is smaller than the review, when only one vendor's quota exists and the extra bill outweighs extra findings, or when nobody reads review comments carefully.
  5. Most worth it when a change touches many callers, the requirement is ambiguous, or the change ships to production; one caught misread pays for it.
  6. Expect the follow-up: can it be automated? Both vendors have headless modes so writing and reviewing can be scripted, but the human adjudication step cannot be removed.

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

  1. 题眼在「不值得」。只讲收益不讲代价，是没在预算表前坐过的人的答法。
  2. 先说收益的来源：同一家模型写与审共享同一份对需求的理解，需求理解偏差抓不出来；换一家审，最大的增量正是这类偏差，其次是不同模型的盲区互补。
  3. 再说怎么做才有收益：审查方必须拿到需求原文与验收标准而不只是 diff，否则退化成 lint；必须要求结构化输出，否则无法统计采纳率；最后一步必须由人裁决。
  4. 不值得的三种情况：任务小到审查成本高于任务本身；团队只有一家的额度，跨家意味着双份账单且多抓出的问题不值这笔钱；审查意见没人认真看，多一家只是多一层噪音。
  5. 最值的三种情况：改动影响多个调用方、需求本身有歧义、改动要上生产——抓出一个理解偏差就回本。
  6. 可预期的追问：能不能自动化？两家都有脱手模式，写与审都能脚本化，但「人裁决」这一步不能省，否则前两步就是浪费。

  Key points

  • Value comes from an independent reading of the requirement, catching misreads a same-vendor review misses
  • The reviewer needs the requirement and acceptance criteria, must output structured findings, and a human adjudicates
  • Not worth it for tiny tasks, single-vendor budgets, or teams that do not read reviews
  • Most valuable for multi-caller changes, ambiguous requirements and production deploys

  答题要点

  • 收益来自独立的需求理解：换一家审能抓出同家审查抓不到的理解偏差
  • 审查方要拿到需求原文与验收标准、输出结构化意见，最后由人裁决
  • 不值得：任务太小、只有一家额度、没人认真看意见
  • 最值：影响多个调用方、需求有歧义、要上生产
• How do you judge the quality of a coding agent's output on a task, beyond whether it ran?怎么评价一个 coding agent 这次任务的输出质量，而不只是看它跑没跑通？

  Common in ChinaCommon overseasDeep dive#coding-agent#evaluation#quality

  How to reason about it · think before answering

  1. This tests whether you treat green tests as the finish line; 'check the tests' is the pass mark, differentiation lies beyond it.
  2. Four layers: correctness (do the tests cover the requirement's edges such as overly long titles or a string for done), contract (does the error shape match the spec exactly or did it improvise), scope (did it touch forbidden files, add dependencies or change defaults silently), maintainability (constants extracted, tests isolated, naming consistent with the repo).
  3. How to measure: correctness by adding your own counterexamples beyond its tests; contract and scope by diffing against the requirement line by line; maintainability via a structured review by a second model or a person.
  4. Add variance: one run proves nothing; run the same requirement three times and treat high variance as a quality signal in itself.
  5. Expect the follow-up: can you trust its 'done, tests pass'? Only what you can reproduce; rerun tests and read the diff yourself, the agent's report is a lead, not evidence.

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

  1. 这题考的是你有没有把「测试绿了」当终点。答「看测试」是及格线，区分度在测试之外。
  2. 拆成四层：正确性（测试是否覆盖了需求里的边界，比如 title 超长、done 传字符串）、契约（错误响应形状是否与需求一字不差，还是它自作主张改了）、范围（有没有改不该改的文件、有没有偷偷加依赖或改默认值）、可维护性（校验规则是否抽成常量、测试是否隔离、命名是否与仓库一致）。
  3. 再说怎么量：正确性看它写的测试之外你再补的反例能不能过；契约与范围看 diff 与需求逐条对照；可维护性交给第二家模型或人做结构化审查。
  4. 补一条随机性：单次结果不能下结论，同一需求跑三次看方差，方差大本身就是一个质量信号。
  5. 可预期的追问：它自己说「已完成并通过测试」能信吗？只信你能复现的部分——在你的机器上重跑测试、看 diff，agent 的汇报是线索不是证据。

  Key points

  • Four layers: correctness, contract, scope, maintainability; green tests cover only part of correctness
  • Verify correctness with your own counterexamples, contract and scope by diffing against the spec, maintainability via structured review
  • Run the same requirement several times; high variance is itself a quality signal
  • The agent's report is a lead, not evidence; trust only what you reproduce

  答题要点

  • 四层：正确性、契约、范围、可维护性，测试绿只是正确性的一部分
  • 正确性用自己补的反例验证，契约与范围对照需求逐条看 diff，可维护性做结构化审查
  • 同一需求跑多次看方差，方差大本身是质量信号
  • agent 的汇报是线索不是证据，只信自己能复现的部分