01

60 秒回答模板

我不会把 OpenAI Agents SDK 或任何开源框架说成默认最优，而是先看项目约束。选型维度包括：第一，编排复杂度，是否需要多 Agent handoff、工具调用、人工确认、沙箱执行或长任务状态；第二，工具和模型生态，是否能方便接入现有函数、MCP、内部服务、向量库和非 OpenAI 模型；第三，可观测和评测，是否支持 trace、日志、失败样本归因、离线评测和线上监控；第四，生产控制，权限、安全、超时、取消、重试、幂等和成本预算能否落地；第五，团队成本，语言栈、部署方式、学习曲线、调试体验和社区维护；第六，锁定风险，后续是否能迁移模型、替换编排层或保留自研能力。如果团队主要用 OpenAI 生态、需要较快构建代码优先的 Agent，并且官方能力覆盖当前需求，可以优先试点；如果已有复杂内部编排、强多模型要求或深度定制运行时，自研或开源框架可能更合适。最后用 POC 和评测结果决策，而不是凭框架名决策。

考点 选型矩阵
难度 真实面经题
回答目标 讲清机制、训练与评估取舍
02

深入解析

01

先明确业务和运行时需求

框架选型要从任务出发：是单 Agent 工具调用、长流程工作流、多 Agent 协作、代码执行沙箱，还是需要人工确认和恢复。任务越复杂，越要关注状态、编排和可观测性；任务很简单时，直接 API 加少量自研封装可能更清楚。

02

比较编排和工具能力

需要看框架是否支持清晰定义 Agent、工具、handoff、状态、取消、重试和人工确认，也要看能否接入内部函数、MCP 服务、数据库、检索系统和已有权限体系。这里比较的是工程适配度，不是只看 demo 是否跑得通。

03

可观测和评测决定能否上线

生产 Agent 必须能记录模型输入输出、工具调用、错误、成本和延迟，并支持失败样本回放和离线评测。没有 trace 和评测闭环，框架越自动化，线上问题越难定位。

04

锁定风险要提前设计

如果框架深度绑定某个模型接口、工具协议或运行时，后续迁移成本会很高。可以通过抽象业务工具、保留统一状态模型、分离评测数据和输出契约，降低替换编排层或模型供应商的成本。

05

生态成熟度和维护成本要量化

要看文档、版本稳定性、社区活跃度、问题响应、语言栈匹配、部署形态和团队经验。一个功能很强但团队难以调试和运维的框架，未必适合核心生产链路。

06

用 POC 而不是偏好决策

选型可以用同一批真实任务做 POC，比较任务完成率、工具成功率、平均轮次、调试耗时、成本、P95 延迟、失败恢复和代码复杂度。通过数据决定采用、混用还是自研。

03

易错点

  • 把 SDK 选型答成模型选型，只比较模型效果。
  • 直接宣称某个框架最好，没有结合任务复杂度和团队约束。
  • 只看 demo 能跑，不看权限、取消、重试、观测和评测。
  • 忽略非 OpenAI 模型、内部服务和现有部署体系的集成成本。
  • 没有设计锁定风险，业务工具和状态完全绑死在框架里。
  • 凭框架热度决策，不做真实任务 POC。
04

面试官追问

什么时候适合直接用 OpenAI Agents SDK？

当团队主要使用 OpenAI 生态、希望快速构建代码优先的 Agent，并且当前需求能被其编排、工具、观测和运行时能力覆盖时，可以优先做 POC。

什么时候更适合自研编排？

当已有复杂内部工作流、强权限体系、多模型供应商、特殊状态机、深度定制沙箱或严格部署约束时，自研或轻量封装可能更可控。

如何降低框架锁定？

把业务工具、状态模型、评测集、输出契约和权限策略抽象在框架外，框架只负责运行时编排，避免业务逻辑完全嵌入某个 SDK。

POC 最该测什么？

测真实任务完成率、工具调用成功率、失败恢复、trace 可读性、集成代码量、P95 延迟、成本和团队调试耗时。