Using Agents as Tools

Towards Data Science

Towards Data Science2026年8月4日

Using Agents as Tools

8.5内容质量

TL;DR · AI 摘要

通过OpenAI Agents SDK，将其他agent作为工具的模式能有效分解复杂任务，提升系统灵活性和可维护性。

核心要点

agent-as-a-tool模式通过管理器-专家协作分解任务，降低实现复杂度
OpenAI Agents SDK支持动态调用其他agent作为工具，简化多代理系统开发
案例研究展示如何利用该模式为旅客规划长中转行程，包含具体代码实现

结构提纲

按章节快速跳转。

§引言
介绍agent-as-a-tool模式的概念及其在复杂任务中的应用价值。
·核心机制
详细解释管理器agent与专家agent的协作流程及责任划分。
›案例研究
通过旅客长中转行程规划展示模式实现，包含代码示例。
›技术实现
使用OpenAI Agents SDK配置agent及工具调用的具体步骤。
›优势分析
讨论该模式在任务边界明确但步骤不确定场景中的优势。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）

agent-as-a-tool模式
- 管理器agent
  - 任务协调
- 专家agent
  - 专项工具调用
- 技术实现
  - OpenAI Agents SDK

金句 / Highlights

值得收藏与分享的关键句。

agent-as-a-tool模式通过分解任务，使管理器无需处理每个细节，提升效率。
— 第2段
⬇︎ 下载 PNG 𝕏 分享到 X
OpenAI Agents SDK允许动态调用其他agent作为工具，简化复杂逻辑实现。
— 第3段
⬇︎ 下载 PNG 𝕏 分享到 X
案例中使用logistics_to等工具，帮助规划行程并考虑时间与风险因素。
— 第4段
⬇︎ 下载 PNG 𝕏 分享到 X

#OpenAI Agents SDK#多代理系统#AI工具#Python#Towards Data Science

打开原文

将智能体用作工具 | Towards Data Science

智能体AI

将智能体用作工具

使用 OpenAI 智能体 SDK 构建管理器-专家工作流

郭帅

2026年8月4日

7分钟阅读

由 GPT-Image 2 生成

在构建智能体时，我们会为其提供工具，使其能够委派任务，而不是自行解决所有问题。

对于明确的操作，工具可以简单地是基于脚本的函数或 API。

但一旦任务变得更加开放，要在一个预定义的脚本中捕捉解决问题的逻辑就会变得相当困难。

这引发了一个有趣的问题：

另一个智能体可以成为工具吗？

答案是肯定的。这就是所谓的“智能体作为工具”模式。

在本文中，我们将使用 OpenAI 智能体 SDK 探索这种模式，并通过一个小案例研究进行说明。

1. 智能体作为工具的模式

从其名称可以推断，在这种模式中，智能体被视为由管理器智能体调用的工具。

通常，这个管理器智能体负责管理整体任务，而其他智能体则作为专家。每当管理器需要帮助解决某个特定问题时，它会将该任务交给相关专家。

专家可以使用自己的指令和工具来解决委派的任务。完成任务后，结果会反馈给管理器，管理器可能会继续协调工作或生成最终响应。

这是多智能体系统的一个具体模式。当委派任务的边界清晰但完成所需的步骤不明确时，这种模式会变得有用。

这种模式为我们提供了明确的责任划分。可以根据需要配置不同的专家，但不需要让管理器智能体承担每个实现细节。

接下来，让我们使用 OpenAI 智能体 SDK 构建这种模式。

2. 规划漫长的中转时间

在这个案例研究中，我们构建一个智能体系统，帮助旅客规划漫长中转时间的活动。

设想这样一个场景：一个家庭在德国慕尼黑有10小时的中转时间。他们希望离开机场，进行一些观光，并享用一顿美餐，同时不耽误后续航班。

为了创建一个有用的行程，智能体需要回答几个问题，例如：

是否有足够的时间离开机场？

有哪些活动和餐饮选择适合旅客？

计划需要考虑哪些风险？

如果我们可以为智能体提供三个专门构建的工具来帮助回答这些问题，那就太好了。这是我们希望实现的智能体结构：

code

# pip install openai-agents
from agents import Agent, ModelSettings, OpenAIResponsesModel
from openai import AsyncAzureOpenAI

client = AsyncAzureOpenAI(
    api_key=os.environ["OPENAI_API_KEY"],
    azure_endpoint=os.environ["OPENAI_API_BASE"],
    api_version=os.environ["OPENAI_API_VERSION"],
)

travel_planner_agent = Agent(
    name="Travel planner",
    instructions=(
        "Create a travel plan for the user "
        "using the available tools."
    ),
    model=OpenAIResponsesModel(
        model="gpt-5.4",
        openai_client=client,
    ),
    model_settings=ModelSettings(
        reasoning={"effort": "medium"},
    ),
    tools=[
        logistics_tool,
        local_experience_tool,
        risk_tool,
    ],
    output_type=LayoverPlan,
)

这三个工具分别是：

logistics_tool：根据交通和时间安排检查行程是否可行。

local_experience_tool：查找活动和餐饮选择。

risk_tool : 识别潜在风险并提出使计划更稳健的建议。

旅行规划器随后可以调用这些工具，并将响应综合成最终的行程安排。

但问题在于：这些工具都无法轻松地作为预定义函数实现。

它们都是开放式的任务，其中一些任务（如物流检查）甚至需要在线搜索当前的交通信息。

那么，我们该怎么办呢？

这就是“代理作为工具”的模式派上用场的地方。

我们不再使用预定义函数，而是使用专业代理作为工具。这些专业代理可以推理任务并在需要时使用自己的工具。这样，我们就能获得代理式问题解决的全部灵活性。

最重要的是，从旅行规划器代理的角度来看，一切保持不变：它仍然调用工具并接收响应。但在这个工具背后，其实是另一个代理在执行工作。

现在，让我们逐一构建这些工具，或称为专业代理。

请注意，我们还要求代理根据LayoverPlan的模式生成结构化输出。我们稍后再详细讨论其内容。

2.1 检查旅行物流

这个工具首先专注于根据当前的交通和时间信息检查拟议的计划是否可行。

完成此任务需要在线搜索最新信息。因此，我们创建了一个具备网络搜索能力的物流代理：

code

from agents import WebSearchTool

logistics_agent = Agent(
    name="Logistics specialist",
    instructions=(
        "Check whether a travel plan is feasible using "
        "current transportation and timing information."
    ),
    model=OpenAIResponsesModel(
        model="gpt-5.4",
        openai_client=client,
    ),
    model_settings=ModelSettings(
        reasoning={"effort": "medium"},
    ),
    tools=[WebSearchTool()],
)

这里出现了关键部分：

code

logistics_tool = logistics_agent.as_tool(
    tool_name="check_logistics",
    tool_description=(
        "Check travel timing, transportation feasibility, "
        "and buffers."
    ),
    max_turns=3,
)

这就是我们将该代理作为物流工具公开的方式。

需要特别说明的一点是：我们为logistics_agent指定的指令是告诉物流代理在被调用后应执行什么角色。因此，它是面向专业代理的。

对于tool_name和tool_description，它们会显示给旅行规划器代理，用于决定何时调用此专业代理。

我们还设置了max_turns=3，这意味着物流代理最多可以进行三次交互来完成委派的任务并返回响应。

WebSearchTool是一个托管的Responses API工具。使用Azure OpenAI时，搜索通过Bing的Grounding功能提供。

由于寻找活动和餐饮选项的工作也需要开放式探索，我们为专家提供了网络搜索功能。

我们随后将该专家暴露给旅行规划器：

python

local_experience_tool = local_experience_agent.as_tool(
    tool_name="suggest_local_options",
    tool_description=(
        "Suggest activities and food options "
        "that fit the traveler."
    ),
    max_turns=3,
)

2.3 识别潜在风险

我们现在可以定义最后一个工具，该工具将审查提出的行程并识别可能失败的地方。

由于此任务仅需要判断，我们不为风险专家提供任何额外工具：

python

risk_agent = Agent(
    name="Risk specialist",
    instructions=(
        "Identify practical risks in a travel plan and "
        "suggest ways to make it more robust."
    ),
    model=OpenAIResponsesModel(
        model="gpt-5.4",
        openai_client=client,
    ),
    model_settings=ModelSettings(
        reasoning={"effort": "medium"},
    ),
)

我们以相同方式将其暴露给旅行规划器：

python

risk_tool = risk_agent.as_tool(
    tool_name="review_risks",
    tool_description=(
        "Review practical risks and robustness "
        "of the travel plan."
    ),
    max_turns=3,
)

2.4 运行慕尼黑示例

之前，我们已将旅行规划器代理配置为返回结构化输出。以下是输出模式 LayoverPlan :

python

from pydantic import BaseModel

class LayoverPlan(BaseModel):
    summary: str
    itinerary: list[str]
    airport_return_time: str
    backup_plan: str
    rationale: str

现在，我们可以用慕尼黑中转场景测试整个系统：

python

user_request = """
We have a 10-hour layover in Munich.

We arrive at Munich Airport at 8:00 AM and depart at 6:00 PM.
We are two adults and one 7-year-old.
We want to see something memorable, eat good food, and avoid
missing the flight.

Please keep the plan relaxed.
"""

以下是运行代理的方式：

python

from agents import Runner

result = await Runner.run(
    travel_planner_agent,
    user_request,
    max_turns=10,
)

我们可以这样查看结果：

python

print(
    result.final_output.model_dump_json(indent=2)
)

在我的运行中，旅行规划器代理实际上推荐参观附近的弗赖辛镇（Freising）而不是慕尼黑市中心。生成的行程包括一些观光活动，如老城区漫步，以及巴伐利亚午餐。然后在下午1:45返回机场。这在下午6点的航班前留有充足时间。

代理不建议参观慕尼黑市中心的理由是，虽然市中心是可行的，但额外的交通时间会使有7岁孩子的家庭出行变得不那么轻松。而弗赖辛则提供了观光和餐饮，并且有更大的航班缓冲时间。

3. 何时使用此模式

将代理作为工具是一种强大的模式，可以添加到您的LLM应用开发工具包中。但在使用之前，请自问：

任务的某部分是否足够开放，需要代理而不是预定义函数？

该工作是否可以作为明确界定的专业任务委托？

原始代理是否应继续负责整体结果？

如果这些问题的答案是肯定的，那么代理作为工具的模式可能是一个很好的选择。

如果委托的操作可以通过预定义逻辑捕获，则只需选择常规函数工具。

撰写人

查看Shuai Guo的所有文章

Llm

,

LLM Agents

多智能体系统

OpenAI Agents SDK

编程

分享本文

在Facebook上分享

在LinkedIn上分享

在X上分享

Towards Data Science 是一份社区出版物。提交您的见解以触达全球读者，并通过 TDS 作者支付计划获得收益。

更新 href 为您的实际投稿链接

为 TDS 撰写文章

✦ end CTA ✦