Interview Bank

Mastering Codex and the OpenAI Agents SDK in 5 Days

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 控制路由质量
• 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 关掉或换成自己的导出器