面试题库

Codex 与 OpenAI Agents SDK 高效使用

D4 OpenAI Agents SDK：agents、handoffs、guardrails、sessions、tracing

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

  国内高频海外高频进阶#agents-sdk#handoffs#architecture

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

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

  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.

  答题要点

  • handoff 转移的是对话控制权，工具调用只是取一次结果
  • 拆分判据是指令是否互相打架，不是工具数量
  • 拆的代价：多一跳、可能路由错、输入护栏只在第一个 Agent 生效
  • 用前缀提示、lastAgent 断言与 tracing 控制路由质量

  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
• guardrail 应该放在输入侧还是输出侧？各自的成本、能拦住什么、拦不住什么？Should guardrails sit on the input side or the output side? What does each cost, what does it catch, and what slips through?

  国内高频海外高频深入#agents-sdk#guardrails#safety

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

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

  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.

  答题要点

  • 输入侧管该不该做，越早拦越省；输出侧管能不能说，只能事后查
  • 输入护栏与主 Agent 并行、触发即取消，便宜模型在此省钱；输出护栏省不了钱只防事故
  • 输入侧漏「回答跑偏」，输出侧漏「已调有副作用的工具」，需工具级护栏补第三层
  • 输入护栏只在第一个 Agent 生效；常见失败是太严，需正常请求回归集

  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
• Agents SDK 的 session 和 Responses API 的 previous_response_id 都能记住多轮，怎么选？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#sessions#tracing

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

  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 换成自己的后端。

  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.

  答题要点

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

  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