OpenAI 34页最佳构建Agent实践

penAI发布O4，也发布34页最佳构建Agent实践，值得阅读。

什么是Agent？

传统软件使用户能够简化和自动化工作流程，而代理能够以高度独立的方式代表用户执行相同的工作流程。

代理是能够独立地代表您完成任务的系统。

工作流程是必须执行的一系列步骤，以满足用户的目标，无论是解决客户服务问题、预订餐厅、提交代码更改，还是生成报告。

集成了大型语言模型(LLM)但不使用它们来控制工作流程执行的应用程序——例如简单的聊天机器人、单轮LLM或情感分类器——不是代理。

更具体地说，代理具有以下核心特征，使其能够可靠且一致地代表用户行动：

1、 它利用LLM来管理工作流程执行并做出决策。它能够识别工作流程何时完成，并可以在需要时主动纠正其行动。在失败的情况下，它可以停止执行并将控制权转回给用户.

2、它可以访问各种工具来与外部系统交互——既可以收集上下文，也可以采取行动——并根据工作流程的当前状态动态选择适当的工具，始终在明确定义的护栏内运行.

何时构建代理？

构建代理需要重新思考您的系统如何做出决策和处理复杂性。与传统自动化不同，代理特别适合那些传统的确定性和基于规则的方法不足的工作流程。

考虑支付欺诈分析的例子。传统的规则引擎像清单一样工作，根据预设标准标记交易。相比之下，LLM代理更像一个经验丰富的调查员，评估上下文，考虑微妙的模式，并识别可疑活动，即使没有违反明确的规则。这种细微的推理能力正是使代理能够有效管理复杂、模糊情况的原因。

在评估代理可以增加价值的地方时，优先考虑以前抵制自动化的工作流程，特别是传统方法遇到摩擦的地方：

### 01 复杂决策

涉及细微判断、例外或上下文敏感决策的工作流程，例如客户服务工作流程中的退款审批。

### 02 难以维护的规则

由于广泛和复杂的规则集而变得笨重的系统，使更新成本高或容易出错，例如执行供应商安全审查。

### 03 严重依赖非结构化数据

涉及解释自然语言、从文档中提取意义或与用户进行对话交流的场景，例如处理家庭保险索赔。

在决定构建代理之前，验证您的用例是否能够明确满足这些标准。否则，确定性解决方案可能就足够了。

# Agent设计基础

在其最基本的形式中，一个agent由三个核心组件组成：

01 模型 驱动agent推理和决策的大语言模型

02 工具 agent可以用来执行操作的外部函数或API

03 指令 明确定义agent行为方式的指导和约束

## 选择您的模型

不同的模型在任务复杂性、延迟和成本方面具有不同的优势和权衡。正如我们将在下一节关于编排的内容中看到的，您可能需要考虑在工作流中的不同任务使用各种模型。

并非每项任务都需要最智能的模型——简单的检索或意图分类任务可能由更小、更快的模型处理，而像决定是否批准退款这样的更困难任务可能会从更强大的模型中受益。

一种行之有效的方法是使用每个任务的最强大模型构建代理原型，以建立性能基准。从那里开始，尝试引入较小的模型，看看它们是否仍能达到可接受的结果。这样，您就不会过早地限制代理的能力，并且可以诊断较小模型在哪些方面成功或失败。

总之，选择模型的原则很简单：
01 设置评估以建立性能基准
02 专注于使用最佳可用模型达到您的准确性目标
03 通过在可能的情况下用较小的模型替换较大的模型来优化成本和延迟

## 定义工具

工具通过使用底层应用程序或系统的API来扩展代理的能力。对于没有API的传统系统，代理可以依靠计算机使用模型通过网页和应用程序UI直接与这些应用程序和系统交互——就像人类一样。

每个工具都应该有一个标准化的定义，使工具和代理之间能够建立灵活的多对多关系。文档完善、经过充分测试且可重用的工具可以提高可发现性，简化版本管理，并防止冗余定义。

广义而言，代理需要三种类型的工具：

| 类型 | 描述 | 示例 |
| --- | --- | --- |
| 数据 | 使代理能够检索执行工作流所需的上下文和信息。 | 查询交易数据库或CRM等系统，阅读PDF文档，或搜索网络。 |
| 动作 | 使代理能够与系统交互，执行诸如向数据库添加新信息、更新记录或发送消息等操作。 | 发送电子邮件和短信，更新CRM记录，将客户服务工单转交给人工处理。 |
| 编排 | 代理本身可以作为其他代理的工具——参见编排部分的管理器模式。 | 退款代理，研究代理，写作代理。 |

## 配置指令

高质量的指令对于任何基于LLM的应用都至关重要，对于智能代理尤为关键。
清晰的指令可减少歧义并改善代理决策，从而实现更流畅的
工作流程执行和更少的错误。

## 代理指令的最佳实践

| 最佳实践 | 描述 |
|---------|------|
| 使用现有文档 | 创建例程时，使用现有的操作程序、支持脚本或政策文档来创建适合LLM的例程。例如，在客户服务中，例程可以大致对应知识库中的单个文章。 |
| 提示代理分解任务 | 从密集资源中提供更小、更清晰的步骤有助于最小化歧义，并帮助模型更好地遵循指令。 |
| 定义明确的行动 | 确保例程中的每一步都对应一个特定的行动或输出。例如，一个步骤可能指示代理询问用户的订单号，或调用API检索账户详情。明确说明行动（甚至是面向用户的消息的措辞）可减少解释错误的空间。 |
| 捕捉边缘情况 | 现实世界的交互经常会产生决策点，例如当用户提供不完整信息或提出意外问题时如何继续。健壮的例程会预见常见变化，并包含如何通过条件步骤或分支（例如在缺少必要信息时的替代步骤）来处理它们的指令。 |

编排

护栏