Skip to main content

9.6.7 OpenAI Agents SDK【选修】

本节定位

很多框架是在帮你组织：

  • 图
  • 链
  • 角色

而 OpenAI Agents SDK 这类高层 SDK 更像是在说：

我们把 Agent、Tool 和运行时统一成一套更标准化的开发接口。

它的重点不一定是“最灵活”，而是“更统一的 Agent 编程体验”。

学习目标​

  • 理解这类 Agents SDK 想抽象的核心对象是什么
  • 理解为什么“Runner / Runtime”常常是这种 SDK 的关键价值
  • 看懂一个最小高层抽象示例
  • 建立什么时候适合这种 SDK、什么时候不一定适合的判断

为什么会出现“Agents SDK”这种层？​

因为直接手写 Agent 很快会有大量重复样板​

一个稍微像样的 Agent 系统通常都会涉及：

  • 工具注册
  • 参数校验
  • 运行循环
  • 结果包装
  • trace
  • 状态推进

如果每个项目都手写一遍，很快就会出现：

  • 结构不一致
  • 可维护性差
  • 团队风格不统一

SDK 真正想做什么？​

它不是替你做产品逻辑，而是在替你统一：

  • Agent 这个对象怎么表达
  • Tool 怎么挂上去
  • 一次执行过程怎么跑

可以先记一句：

SDK 的价值不是“更强”，而是“更统一”。

几个最关键的抽象对象​

Agent​

一个带着目标和工具集合的智能体单元。

Tool​

Agent 可以调用的外部能力，例如：

  • 搜索
  • 计算
  • 文件访问

Runner / Runtime​

这个特别重要。 它通常负责：

  • 真正运行 agent
  • 管理执行过程
  • 收集结果

很多时候，这类 SDK 最大的工程价值恰恰就在：

它把“如何跑 Agent”统一起来了。

一个最小高层抽象示例​

下面我们用纯 Python 模拟这种 SDK 风格。

class Tool:
    def __init__(self, name, fn):
        self.name = name
        self.fn = fn

class Agent:
    def __init__(self, name, tools):
        self.name = name
        self.tools = {tool.name: tool for tool in tools}

class Runner:
    def run(self, agent, tool_name, **kwargs):
        if tool_name not in agent.tools:
            return {"error": "unknown_tool"}
        result = agent.tools[tool_name].fn(**kwargs)
        return {"agent": agent.name, "tool": tool_name, "result": result}

def get_weather(city):
    return f"{city} 当前晴天 22 度"

weather_tool = Tool("get_weather", get_weather)
assistant = Agent("weather_assistant", [weather_tool])
runner = Runner()

print(runner.run(assistant, "get_weather", city="北京"))

预期输出：

{'agent': 'weather_assistant', 'tool': 'get_weather', 'result': '北京 当前晴天 22 度'}

这段代码为什么很有“SDK 感”？​

因为它已经把三件事明确拆开了：

  • Agent 本身
  • Tool 本身
  • 执行层 Runner

这正是很多高层 SDK 最想统一的结构。

这种抽象到底帮你省掉了什么？​

统一工具接入方式​

你不需要每个项目都重新定义：

  • 工具怎么挂
  • 工具怎么调

统一执行入口​

当系统越来越复杂时，“谁来跑 Agent”其实会变成很重要的问题。 Runner / Runtime 让这件事更统一。

更容易形成团队一致风格​

因为：

  • Agent 怎么定义
  • Tool 怎么挂
  • 结果怎么返回

这些地方都不会每次乱写。

为什么说 Runner / Runtime 特别关键？​

因为 Agent 不是普通函数​

一个 Agent 不只是：

  • 输入 -> 输出

它通常还可能包含：

  • 工具选择
  • 执行过程
  • 中间状态
  • 错误返回

所以“怎么跑它”本身就是一个独立层。

一个直觉类比​

你可以把 Runner 想成：

Agent 的执行调度器。

Agent 是参与者，Runner 是负责把它真正跑起来并管理过程的人。

这种高层 SDK 什么时候会特别顺手？​

当你想要的是统一开发体验​

例如：

  • 多个 Agent 项目都想用同一种结构
  • 团队想少写重复运行逻辑
  • 希望工具和 Agent 的表达更统一

特别适合​

  • 中小型 Agent 应用
  • 原型到产品的中间阶段
  • 需要一致运行体验的团队项目

在这些场景里，高层抽象往往很省力。

它的局限也必须看清​

高层抽象意味着更多约束​

你得到的是：

  • 统一
  • 清晰
  • 省样板代码

你失去的可能是：

  • 很细的底层控制自由

如果你的系统特别特殊​

例如：

  • 自己有非常复杂的状态图
  • 有非常定制的执行策略

这时高层 SDK 可能就不是最舒服的表达方式。

所以它的关键判断不是“强不强”，而是：

它的抽象是不是贴合你的系统。

和别的框架怎么区分？​

和 LangGraph​

LangGraph 更偏：

  • 图
  • 状态流
  • 条件边

Agents SDK 更偏：

  • Agent
  • Tool
  • Runner

和 CrewAI​

CrewAI 更偏：

  • 团队角色和协作表达

Agents SDK 更偏：

  • 统一 Agent 运行模型

所以它不是在和所有框架正面竞争同一层，而是：

更像一种高层开发接口风格。

初学者最常踩的坑​

只看 SDK 名字，不看抽象边界​

结果就是：

  • 用着用着觉得“不顺”

觉得“高层抽象 = 更高级”​

不是。 高层只是意味着更省样板代码，不代表总更适合。

还没理解 Agent 本身，就先背 SDK API​

这样很容易会写调用，但不会做架构判断。

小结​

这一节最重要的不是记住类名，而是理解：

OpenAI Agents SDK 这类框架的价值，在于把 Agent、Tool 和运行过程统一成一套更稳定的编程模型。

当你需要的是“一致的 Agent 开发体验”时，它会非常有帮助； 当你需要极细的底层控制时，它未必是第一选择。

练习​

  1. 用自己的话解释：为什么说 Runner / Runtime 往往是这类 SDK 的关键价值？
  2. 想一想：这种高层 SDK 和 CrewAI 的“团队协作抽象”有什么不同？
  3. 如果你的系统已经有一套复杂状态机，你还会优先选这种高层 SDK 吗？为什么？
  4. 用自己的话说明：SDK 真正帮你省掉的是哪类高频样板工作？