Tools vs. Subagents: Building Effective AI Agents Without Over-Engineering

工具与子代理：无需过度设计的高效AI代理构建

By

Bala Priya C

on

July 8, 2026

in

Artificial Intelligence

0

Share

Post

本文将教你如何判断特定代理功能应该以工具形式还是子代理形式实现，并在过程中避免过度设计代理架构。

我们将涵盖以下内容：

• 工具和子代理的定义及其关键差异
• 工具更优的场景与子代理值得增加复杂度的场景
• 如何应用简单的三问决策框架，以及添加子代理的实际成本

明确这个框架后，让我们看看各部分如何协同工作。

引言

你构建的每个AI代理最终都会面临同样的决策点。你有一个需要完成的任务——调用API、搜索数据库、执行计算——你需要决定：这应该是一个代理直接调用的工具，还是应该是一个独立处理任务的子代理？

如果判断失误，一方面可能导致代理功能臃肿，在单一上下文窗口中试图完成过多任务；另一方面则会为本可通过简单函数解决的问题增加协调开销、额外的LLM调用和调试复杂度。

本文将解释工具和子代理的定义、适用场景，以及每次决策时如何做出选择。

工具是什么

工具是代理用来与外部系统交互、执行超出模型内置知识范围操作的能力。实际上，工具通常是通过定义接口暴露给模型的函数、API调用、数据库查询、搜索、文件操作或其他可执行代码。

典型的工具交互流程如下：

• 模型接收到任务并判断需要外部信息或操作
• 模型生成包含必要参数的结构化工具调用
• 你的应用执行该工具并返回结果
• 结果被重新加入对话，使模型能继续推理并决定下一步操作

关键区别在于工具本身不执行推理。它们执行预定义操作并返回数据，而模型负责这些操作的规划、解释和决策。

工具是代理与外部世界交互的主要方式。它们可以查询数据库、调用API、搜索网络、读取文件、执行计算或触发工作流。由于工具执行代码而非启动另一个LLM，相比创建子代理，它们通常更快、更确定且成本更低。

子代理是什么

子代理是一个独立的LLM调用——通常是一个具有独立系统提示、独立上下文窗口，通常还拥有自己工具集的独立代理实例——它接收任务，独立处理并返回结果给协调代理。

从协调器的角度来看，调用子代理与调用工具看起来完全相同：发送任务，获取结果。区别在于中间过程。子代理会运行自己的多步骤推理循环，可能进行自己的工具调用，并管理自己的状态。协调器无法看到这个过程，它只能在最后获得总结结果。工具与子代理

工具与子代理：关键差异

工具执行代码。子代理执行推理。

方面

Tools

子代理

执行内容

你的代码

另一个 LLM

上下文窗口

与协调器共享

独立隔离

推理

无；确定性执行

完整的多步骤推理循环

错误处理

结构化返回，同一循环中重试

子代理内部处理或反馈给协调器

成本

仅执行成本

额外的 LLM 调用

延迟

低；一次函数调用

高；完整推理周期

可见性

完整；结果在协调器上下文中

部分；协调器仅看到摘要

失效场景

模式错误、API 失败、参数错误

子代理幻觉、上下文丢失、协调失败

上下文窗口的差异比初看更重要。当代理调用工具时，结果会返回到代理当前推理的上下文中——之前的推理、工具结果和所有其他内容共同构成完整上下文。当协调器生成子代理时，该子代理会从零开始，仅包含协调器传递给它的内容。

何时使用工具

在操作定义明确、行为确定且不需要多步骤推理时使用工具。

调用外部 API。获取用户记录、发布到 Slack 或查询数据库等任务属于纯执行任务。模型决定调用这些工具，你的代码负责执行。

转换或验证数据。运行正则表达式、格式化日期、计算哈希或转换单位。确定性操作应放在函数中，而非 LLM 调用。

读写文件。打开文件、写入输出、检查是否存在。当以直接工具调用实现时，文件系统操作是可预测且快速的。

执行搜索。对向量数据库进行语义搜索、对数据库执行 SQL 查询、进行网页搜索。搜索本身以确定性方式运行并返回结果，模型会解释这些结果，但搜索本身作为工具运行。

实际测试标准：如果你能用带有类型输入和输出的 Python 函数编写该行为，并且不需要多步骤推理，那么它应该是一个工具。

何时使用子代理

在任务需要多步骤推理、中间步骤会干扰协调器上下文，或任务可以并行执行时使用子代理。

任务包含非显性的中间步骤。“研究 X 的竞争格局”需要决定搜索内容、阅读结果、决定下一步搜索、跨来源综合信息并生成结构化摘要。每一步都依赖于前一步。这是推理过程，应放在独立上下文中。

工作可以并行化。处理 k 个文档时，通过 k 个并发子代理独立执行比在单一上下文中顺序执行更快。微软的 AutoGen 框架部分基于此模式，协调专门的代理并行处理独立子任务。

子任务需要专属工具集。代码编写子代理需要代码执行器和文件系统工具。研究子代理需要网络搜索和文档工具。让协调器访问所有工具会导致工具过载。关于代理工具调用的研究表明，工具数量增加会导致准确性下降。按子代理范围限定工具可保持每个代理的决策空间较小。

中间输出会引入噪声到协调器的上下文中。单个数据库查询结果简洁且在上下文中具有实用性。跨数十个检索文档的多步骤研究综合属于噪声。将这些工作隔离到子代理中并仅呈现结论，能保持协调器推理的清晰性。何时使用子代理 上下文隔离可提高可靠性。子代理在全新上下文中运行，不会受到协调器累积历史的干扰。对于需要专注的任务（如代码生成、结构化数据提取或多步骤分析），隔离通常能产生更一致的输出。

决策框架

大多数决策归结为三个问题。

1. 任务主要是执行还是推理？

如果任务是定义明确的操作且具有可预测的输入和输出，工具通常是更合适的选择。数据库查询、API调用、搜索、计算和文件操作都属于此类。

如果任务需要探索、分析、综合或进行一系列依赖前一步骤的决策，通常更适合使用子代理。

2. 中间工作对协调器是否重要？

工具结果通常足够小且有用，可以直接保留在协调器的上下文中。数据库记录、搜索结果或API响应通常可以立即使用。

当任务生成大量中间工作（如多次搜索、文档评审、迭代或分析）时，子代理可以隔离这些工作并仅返回最终结论。

3. 任务能否独立运行？

工具作为协调器工作流的一部分执行，并在工作流继续前返回结果。

当工作可以委派、独立运行或与其他任务并行执行时，子代理通常是更合适的选择。这在处理多个文档、研究多个主题或协调专业工作流时尤其有用。

工具最适合确定性执行：

• 从数据库、API或搜索系统获取数据
• 执行计算、转换或验证
• 读取、写入或更新文件和记录

子代理最适合有限推理任务：

• 研究主题并跨来源综合发现
• 编写、评审和优化复杂内容
• 并行分析大量文档或数据集合

过度设计陷阱

最常见的错误是在真正需要之前引入子代理。

子代理可以使架构更清晰，但也会增加复杂性。每个子代理都会引入另一个上下文窗口、另一个推理循环和组件间的另一个交接点。这意味着更多延迟、更高成本和更多需要调试的组件。

在许多情况下，精心设计的工具就足够了。如果任务可以通过简单的API调用、数据库查询、搜索或其他确定性操作完成，添加独立代理通常会带来比价值更多的开销。

总体原则是从单个代理和一组精心设计的工具开始。仅在子代理能解决工具无法清晰解决的具体问题时（如隔离大量中间工作、启用并行执行或为复杂任务提供专用推理空间）才引入子代理。

一个有用的问题是：“子代理实际上能给我带来什么？”

• 如果答案只需在返回结果前进行少量处理，使用工具通常就足够了。

• 如果答案需要独立推理、上下文隔离、专业能力或并行执行，使用子代理可能是合理的。

工具应作为默认选择。只有在子代理能提供明确的架构优势时，才应引入子代理。

添加子代理的实际成本

调用工具很简单：提供输入，获取结果。调用子代理则不同。你同时也在委托部分思考过程。

这意味着协调器必须明确地定义任务，以便子代理能够独立工作。子代理不会自动继承协调器的目标、假设或完整的对话历史。它只知道自己被赋予的内容。

因此，优秀的子代理架构依赖于清晰的交接：

• 协调器发送一个聚焦且自包含的任务。

• 子代理进行自己的推理和工具使用。

• 子代理返回一个简洁的结果，供协调器使用。

例如，一个研究子代理可能返回：“识别出三个竞争对手，以及他们的定价模型和关键差异点。”

它通常不应返回所有导致该结论的搜索查询、文档摘录和中间观察结果。

保持边界清晰有两个好处。首先，它能防止协调器的上下文被不必要的中间工作填满。其次，它使系统更容易理解和调试，因为每个子代理都有明确的责任和明确定义的输出。实践中子代理的注意事项：一个有用的规则是：向下传递任务，向上返回结论。干净的任务输入和简洁的总结输出是保持多代理系统可调试的契约。允许子代理共享可变状态或在任务中途传递部分结果的系统，会引入协调复杂性，这种复杂性很快就会超出原始问题的范围。

总结

在代理系统中选择工具和子代理是关键的架构决策。虽然两者都能帮助完成任务，但它们在执行模型、推理能力、成本和操作复杂性方面存在显著差异。以下比较突出了每种方法最适用的场景。

| 概念 | 另一个具有自身推理循环的LLM | |------|-----------------------------| | 最适合 | 确定性执行：API调用、搜索、计算、文件操作 | 复杂推理：研究、代码生成、并行处理 | | 上下文 | 隔离；每个任务有独立的新上下文窗口 | 一次或多次额外的LLM调用 | | 成本 | 低 | 更高 | | 可调试性 | 高；结果在协调器上下文中可见 | 较低；内部步骤不透明 | | 使用场景 | 任务可以写成确定性函数 | 任务需要多步骤推理、并行性或工具隔离 | | 过度设计风险 | 高；如果过早使用会增加协调开销 | | | 通信契约 | 类型化函数输入 → 结构化输出返回 | 自包含任务字符串 → 摘要字符串 | | 起始点 | 是；默认使用工具 | 仅在工具遇到具体限制时 |

这种分离使系统默认保持简单，同时仅在工具设计不再足够时才允许添加子代理。

关于此主题的更多内容

• 人工智能代理的有效上下文工程：A…
• 理解机器学习算法的5种方法…
• 不增加GPU的3种加速模型训练方法
• 与ChatGPT进行有效头脑风暴的策略

• 提示工程：与ChatGPT进行有效交互

• 处理不平衡数据的5种有效方法…

/.entry /think