【智能体构建】构建智能体的实用指南（中）

编号	步骤描述
01	设置评估（evals）以建立性能基准
02	使用当前最佳模型，专注于达成准确率目标
03	在可能的情况下，用较小模型替换较大模型，以优化成本和延迟

3.定义工具

工具通过使用底层应用程序或系统的 API 来扩展智能体的能力。对于没有 API 的传统系统，智能体可以通过计算机操作模型，像人类一样通过网页和应用程序的用户界面直接与这些系统进行交互。

每个工具应具有标准化的定义，从而在工具与智能体之间建立灵活的、多对多的关系。良好文档、充分测试并可复用的工具能够提高可发现性，简化版本管理，并避免重复定义。

智能体需要的工具类型：

类型	描述	示例
数据（Data）	使智能体能够获取执行工作流所需的上下文和信息	查询交易数据库或CRM系统、读取PDF文档、搜索网络
动作（Action）	使智能体能够与系统交互并执行操作，例如向数据库添加新信息、更新记录或发送消息	发送电子邮件和短信、更新CRM记录、将客服工单转交给人工处理
编排（Orchestration）	智能体本身也可以作为其他智能体的工具	退款智能体、研究智能体、写作智能体

使用 Agents SDK 时，为智能体配备工具的方式：

4.配置指令（instructions）

高质量的指令对于任何基于大语言模型（LLM）的应用程序都至关重要，而对于智能体来说尤其关键。清晰的指令可以减少歧义，提升智能体的决策能力，从而实现更顺畅的工作流执行并减少错误。

为智能体编写指令的最佳实践：

建议	描述
使用现有文档	在创建流程时，使用现有的操作规程、支持脚本或政策文件来构建适合 LLM 的流程。例如在客服场景中，流程可以沉淀到知识库中的单个文档，并给智能体。
提示智能体分解任务	从密集型资源中提供更小、更清晰的步骤，有助于减少歧义，并帮助模型更好地遵循指令。
定义明确的动作	确保流程中的每一步都对应一个具体的动作或输出。例如，某一步可能指示智能体要求用户提供订单号，或调用 API 获取账户详情。对动作（甚至用户面向消息的措辞）进行明确描述，能减少理解上的错误。
捕获边缘情况	实际交互中常会出现决策点，例如当用户提供不完整信息或提出意外问题时该如何处理。一个健壮的流程应预见到常见边界case，并包含如何通过条件步骤或分支处理这些情况的说明，例如当缺少必要信息时执行替代步骤。

你可以使用高级模型（如 o1 或 o3-mini），从现有文档中自动生成指令。以下是一个展示该方法的示例提示：

你是一位为 LLM 智能体编写指令的专家。请将以下帮助中心文档转换为一个清晰、有序号的指令列表。该文档将成为 LLM 遵循的政策。请确保指令无歧义，并以对智能体的操作指引方式撰写。需要转换的帮助中心文档如下：{{help_center_doc}}

5.智能体构建

在基础组件准备好后，你可以考虑采用编排模式构建智能体，以使智能体能够高效地执行工作流。

尽管直接构建一个具有复杂架构的完全自主智能体可能很诱人，但通常很难一步位，因此建议通过逐步推进的方法以取得更好的效果。

编排模式可以分为两类：

编号	类型	描述
01	单智能体系统	一个配备了适当工具和指令的单一模型，通过循环执行工作流
02	多智能体系统	工作流的执行分布在多个协同工作的智能体之间

5.1 单智能体系统

通过给智能体添加工具，一个单一的智能体可以处理许多任务，从而保持复杂度可控，简化评估和维护成本。每增加一个新的工具，都会扩展其能力，不建议在早期就进行多智能体的编排（复杂度高）。

每种编排方法都需要“运行（run）”的概念，通常通过一个循环来实现，使智能体持续运行直到满足退出条件。常见的退出条件包括调用工具、生成特定结构的输出、发生错误，或达到最大交互轮次。

例如，在 Agents SDK 中，智能体是通过某个方法启动的，该方法会循环调用 LLM，直到以下任一情况发生：

编号	描述
01	调用了最终输出工具，该工具由特定的输出类型定义
02	模型返回了不包含任何工具调用的响应（例如，直接的用户消息）

调用示例：

while 循环这一概念是智能体运行的核心。在多智能体系统中，可以在多个智能体之间依次调用工具并进行交接，但模型仍会连续执行多个步骤，直到满足退出条件。

一种在不切换到多智能体框架的情况下管理复杂性的有效策略是使用提示模板。与其为不同的使用场景维护大量独立的提示语，不如使用一个灵活的基础提示模板，该模板可以接受策略变量作为输入。这种模板方法能够轻松适应各种上下文，大大简化维护和评估工作。当新的使用场景出现时，只需更新变量，而无需重写整个工作流。

你是一名客服中心的智能体。你正在与{{user_first_name}}进行交流，该用户已注册{{user_tenure}}。用户最常见的投诉是关于{{user_complaint_categories}}。请向用户打招呼，感谢他们作为忠实客户，并回答用户可能提出的问题！

5.2 什么时候应该考虑构建多智能体？

建议是首先最大化单个智能体的能力。虽然使用多个智能体可以在概念上提供更直观的分离，但也可能引入额外的复杂性和开销。很多情况下，一个配备了工具的单一智能体就已足够。对于复杂的工作流来说，将提示和工具分配到多个智能体中，有助于提升性能和可扩展性。当你的智能体无法遵循复杂的指令，或者持续选择错误的工具时，你可能需要进一步拆分系统，并引入更多功能明确的智能体。

拆分智能体的原则：

类型	描述
复杂逻辑	当提示中包含大量条件语句（多个 if-then-else 分支），并且提示模板难以扩展时，考虑将每个逻辑段分配给不同的智能体处理。
工具过载	问题不仅在于工具的数量，还在于它们之间的相似性或重叠度。有些智能体能管理超过15个定义良好且互不重叠的工具，而另一些则在少于10个重叠工具的情况下就遇到困难。如果通过提供描述性的名称、清晰的参数和详细的说明来提高工具的清晰度仍无法改善性能，则应使用多个智能体。

5.3 多智能系统

多智能体主要有两类广泛适用的模式：

类型	描述
中心化管理器（智能体作为工具）	一个中心化的“管理者”智能体通过调用工具的方式协调多个专业化的智能体，每个智能体负责处理特定的任务或领域。
去中心化（智能体之间交接任务）	多个智能体以对等的方式运行，根据各自的专长将任务交接给其他智能体。