客服从问行李转到改座位，OpenAI Agents SDK 怎样接住这次交接

用户先问行李规定，下一句又想换座位。客服助手如果每次都从头分诊，会重复提问；若所有职责塞进同一个角色，也很难看清它为什么调用某个工具。OpenAI Agents SDK 的航空客服样例，把这次转换写得很具体。

样例有分诊、FAQ、座位处理三个 Agent。它展示的成果是一次能继续对话的职责交接，包括谁在接待、已经知道哪些字段、工具做了什么。它是一份教学程序，座位工具没有连接航空公司的真实系统。

问题换了，接待者也可以换

分诊 Agent 可以把问题 handoff 给 FAQ 或座位 Agent。FAQ 被要求先识别用户的问题，再调用查询工具回答；查不到时交回分诊。座位 Agent 则按流程询问确认编号和期望座位，再调用 update_seat；遇到不相关问题，也能返回分诊。

这份代码值得读的地方，是职责与可用工具一起定义。FAQ 查询和座位变更有不同的输入与操作路径，交接因此不仅是换一句角色介绍，还会改变接下来的处理方式。

FAQ 工具返回的是样例里写好的行李、座位和 Wi-Fi 文字。这些是演示内容，不是可直接对旅客承诺的航空政策。

AirlineAgentContext 保存乘客名、确认编号、座位号与航班号。交给座位 Agent 时，on_handoff 回调先设置航班号，update_seat 再修改确认编号和座位字段。

这里的航班号是随机生成的，update_seat 也只更新这个上下文对象。没有真实订座查询、座位库存或改签接口。因此，“程序回复改座位成功”只能说明样例函数返回了结果，不能推出一张真实机票已变更。

对开发者更有用的材料是这处接口：交接前能准备专门职责需要的数据，工具执行后又把结果放回程序持有的上下文。把它接成业务产品时，需要在这些位置实现真实数据访问与动作。

样例的运行循环每次取回 result.to_input_list()，作为后续输入历史；同时把 current_agent 更新为 result.last_agent。前者保留对话与运行项目，后者决定下一轮由哪位 Agent 开始接待。只保存最终回答文字，会漏掉这种接续关系。

终端还区分普通消息、交接、工具调用与工具返回。整个会话通过同一个 group_id 关联 trace，便于回看转交发生在哪里。官方入门文档也强调，在交接后需要专员继续控制对话时，应复用 lastAgent。

SDK 代码采用 MIT 许可；实际模型请求与追踪服务按配置使用。若你正在做多职责客服，这个样例最值得借鉴的是交接后的连续性：职责能切换，历史和业务字段仍有明确归属，开发者也能追踪每次切换究竟做了什么。