工具与子代理：构建有效AI代理而不过度工程化

在构建AI代理时，每个开发者最终都会面临一个决策点：某个功能应该实现为工具还是子代理？选择错误会导致代理臃肿或过度复杂。本文详细解释两者的区别、适用场景以及如何做出正确选择。

工具是代理与外部系统交互的能力，通常表现为函数、API调用、数据库查询等确定性操作。代理调用工具时，工具本身不进行推理，只执行预定义操作并返回结果。工具的优点是快速、确定且成本低。子代理则是一个独立的LLM调用，拥有自己的系统提示、上下文窗口和工具集。它接收任务后独立进行多步推理，返回结果给编排代理。子代理的优点是上下文隔离、能够处理复杂推理任务，但代价是更高的延迟和成本。

关键区别在于：工具执行代码，子代理执行推理。工具与编排代理共享上下文窗口，而子代理拥有独立的上下文。子代理的推理循环完整，但编排代理只能看到最终结果。工具错误处理通常是结构化返回和重试，子代理的错误可能内部处理或上报。成本方面，工具只有执行成本，子代理需要额外LLM调用。延迟上，工具低，子代理高。

何时使用工具？当操作定义明确、行为确定且不需要多步推理时。例如API调用、数据验证、文件读写、搜索等。如果可以用Python函数实现，且不需要多步推理，就应该用工具。

何时使用子代理？当任务需要多步推理、中间工作会对编排代理上下文造成噪音、或任务可并行执行时。例如研究竞争格局（需要多步搜索和综合）、并行处理多个文档、需要专用工具集的任务。上下文隔离还能提高可靠性，子代理在工作时不会被编排代理的累积历史干扰。

决策框架基于三个问题：1. 任务是执行还是推理？2. 中间工作对编排代理是否重要？3. 任务能否独立运行？工具适合执行，子代理适合推理。如果结果小且直接有用，用工具；如果产生大量中间结果，用子代理。如果任务可独立或并行运行，子代理更合适。

常见陷阱是过早引入子代理。好的实践是先从单一代理和少量工具开始，只有在工具无法简洁解决问题时才引入子代理。回顾问题：“子代理真正给我带来了什么？”如果只是少量处理，工具足够；如果需要独立推理、上下文隔离、专门能力或并行执行，子代理才合理。

引入子代理的实际成本包括：编排代理必须明确定义任务，子代理不会自动继承编排代理的上下文。需要清晰的交接：发送聚焦的任务，子代理独立推理并使用工具，返回简洁的结果。例如研究子代理可能返回“确定了三个竞争对手以及它们的定价模型和关键差异化因素”，而不是每个搜索查询和中间观察。保持边界清晰能防止编排代理上下文被中间工作填满，并使系统更易理解和调试。一个有用的原则是：将任务向下传递，将结论向上传递。