使用 OpenAI Agents SDK 构建智能体——模型与上下文管理

到目前为止，我们在用 OpenAI Agents SDK 构建代理时大多依赖默认的 GPT-4o 模型。不过，OpenAI Agents SDK 的一大强项是“与模型解耦”。换句话说，你并不被某一家模型提供商或某个固定配置锁死。这种灵活性在复杂流程或多代理系统里尤其有价值——流程的不同阶段可能需要不同的能力、成本或时延特性。

想象一个多代理系统：起手的分诊代理只需向用户发些简单问题。为这一步动用 GPT-4 可能并不合适；更可取的是一个更轻量的模型，甚至是像 LLaMA 这样的开源模型，成本几乎为零。与此同时，更吃力的任务（比如深度检索或数学推理）也许需要更强的 Anthropic 模型。而头脑风暴型代理可能仍然使用标准的 GPT-4o，但把 temperature 调得更高。

OpenAI Agents SDK 天然支持这种架构模式。每个代理都可以使用不同的模型及其专属配置。

本章你将学到：

• 模型管理：如何调整模型、模型参数，以及把第三方模型集成到代理中；
• 上下文管理：如何利用本地上下文把信息传给工具，同时不让 LLM 看见这些信息。

读完本章，你就能在代理方案里有效管理模型与上下文。

在 OpenAI Agents SDK 中，每个代理都必须由某个 LLM 驱动。LLM 是代理的大脑：读取信息、调用工具、生成回复。此前我们一直用默认配置（即 GPT-4o 与默认参数）。本节讲如何以及何时修改这些设置。

Agents SDK 允许你显式选择要用的模型。不同模型各有优劣，为不同类型的代理选对模型很重要。比如 GPT-4o 快且准，而 o3-pro 更擅长复杂推理但速度更慢。

通过在实例化代理时设置 参数即可：

该参数可取任意有效的 OpenAI 模型名。模型列表、特性与费用见：platform.openai.com/docs/models 。

来看一个为什么“选对模型”至关重要的例子。我们创建两个代理（GPT-4o 与 o3-pro），让它们回答同一道题，并比较用时：

运行结果：

实践中，GPT-4o 一般几秒就答复，但在这道较复杂的数论题上给错了；o3-pro 虽然更慢（且可能更贵），但答对了。因此，准确性 vs. 时延/成本 是天然权衡；Agents SDK 让你为每个代理自由选择。

很多时候你想用同一个模型，但需微调生成风格。比如让回答更短、更有创意。OpenAI API（以及大多数 LLM API）提供“模型参数”。在 Agents SDK 中，通过 传入 参数。

常用参数包括：

• ：控制随机性。越低（如 0.2）越稳定，越高（如 0.8）越有创造性。
• ：限制单次生成的最大 token 数，控制输出长度。

示例：两个代理，一个高温度+更长上限，一个低温度+更短上限：

运行后你会看到两种截然不同的风格： Agent 智能体 更长更天马行空； 更短更克制，而且因为 很小，甚至可能被截断。通过调参，你无需换模型就能获得不同语气与篇幅，便于把同一模型分别用于销售型客服与创意研究等不同代理。

正如开头所说，Agents SDK 是“模型无关”的：只要满足接口特征，就能使用任意厂商的模型。虽然 GPT-4o 等是很好的默认选择，但很多场景下用别家更合适。比如 Anthropic 的 Claude 在某些指令遵循上更好；又或者为了成本选择 Meta 的 LLaMA。

Agents SDK 借助 LiteLLM 来适配第三方模型。LiteLLM 是一个为多家主流 LLM 提供统一 API 的轻量库（Anthropic、Google 等）。用它接入第三方模型非常顺滑：它处理 API Key、路由与响应格式，你几乎不用改代理代码就能切换。

先安装：

然后获取非 OpenAI 提供商的 API Key。这里以 Anthropic 为例：在 www.anthropic.com/ 创建账号、生成 API Key。把它写入第 3 章中设置的 ：

接着在代理的 参数中填 LiteLLM 的模型字符串，例如：

示例：

输出示例：

这样你就能在不重构逻辑的前提下，随意把代理背后的 LLM 从 GPT-4o 切到 Claude 或 LLaMA（只要 LiteLLM 支持即可）。这在基准评测、不同部署环境（隐私/时延/成本）切换时非常有用。比如开发期用 GPT-4o 原型，生产用 Claude 做摘要。

“上下文”指代理能够访问到的一切信息。一个恰当的类比是：代理的 LLM 是它的“大脑”，而上下文就是传递给大脑、用于生成回答的信息。前文我们已讨论了多种向代理暴露关键信息的方式：系统指令、过往对话历史、提示注入，甚至通过工具调用进行的知识检索。

本节我们把范围收窄到本地上下文（也称运行上下文，run context）。它指为实例化代理而需要的信息，并作为工具及其他钩子的依赖。

本地上下文让你的代理在不把数据显式放进 LLM 提示词的情况下，访问（在实例化时提供的）信息。这最适合存放用户相关数据（如用户 ID、姓名、偏好），好让工具据此抓取或计算答案。这解锁了一个强大的设计模式：让代理在不把敏感/私有数据写进模型提示的前提下，仍可用带权限或应用特定的数据（例如用户偏好、鉴权令牌或内部状态）做出决策或生成个性化输出。

在 OpenAI Agents SDK 中，你通过创建一个上下文对象，并在调用 时用 参数传入来实现本地上下文。只要工具函数也声明了接收上下文参数，任何工具都能使用该上下文。

下面用一个具体示例说明。设想客服代理可基于用户档案及其当前订单来查询物流状态。我们用一个 对象（含用户姓名与订单详情）来模拟，再写一个使用这些信息返回物流进度的工具函数。

首先，新建 ，写入如下代码：

我们先定义了一个数据类 ，包含三项：用户姓名、订单号、当前物流状态。它就是我们希望代理能访问的本地上下文（供工具函数消费的信息）。

接着，我们创建一个示例的 实例。在真实应用中，上下文通常会依据“代理被调用的位置/会话”按用户动态生成。

然后，我们定义工具函数 ，使其接收上下文对象（）作为参数。这告诉代理：调用工具时把上下文对象一起传入。我们还在实例化代理时将其参数化为同一上下文类型（），让代理知道会收到何种上下文——这一步非常关键。

有了这些，调用 时就必须传入该类型的上下文对象。SDK 会自动把查询路由到工具，由工具基于上下文数据生成响应。

示例输出如下，说明代理已把上下文信息传给了工具函数：

这体现了本地上下文的一大益处：代理能用从未进入模型提示词的敏感信息，生成精准、个性化的回答。归纳起来，本地上下文让代理拥有一种不直接暴露给用户或模型提示的“内部记忆”，是一种将领域知识或用户特定数据注入工具层的方式。

本章介绍了如何为每个代理选择与配置底层模型；如何调整模型与其参数；以及如何通过 LiteLLM 集成第三方模型（如 Claude、Gemini、LLaMA），从而在不同提供商间轻松切换。最后，我们引入了本地上下文：一种在不把数据写入模型提示的情况下，为代理提供敏感或会话特定数据的机制。

结合这些技术，你就能全面掌控代理“如何思考、如何作答”。下一章我们将把重心转向代理的管理、运维与安全：你将学习如何监控代理活动、设置防护栏，并在生产环境中采用最佳治理实践。