我要投稿

OpenAI开源34页Agents最佳实践白皮书~

发布日期：2025-04-18 15:34:53 浏览次数： 1593 作者：探索AGI

嘿，大家好！这里是一个专注于前沿AI和智能体的频道~

OpenAI 昨天又悄悄放出了一份资料——一份 34 页的官方《构建 Agent 实用指南》(A practical guide to building agents)！（所以这是在对标Google agents 白皮书？）

整体的内容还算全面，感觉上比google的Agents白皮书内容要更深度一点。定义了什么是 Agent，从模型选择、工具设计、指令编写，到复杂的编排模式和安全护栏，给出了一些具体和实用的建议。

到底什么是 AI Agent？

OpenAI 明确了 Agent 的核心特征。它不仅仅是聊天机器人或简单的 LLM 调用，关键在于能够独立执行工作流。Agent 能代表用户，在某种程度上独立地完成一系列步骤以达成目标，无论是订餐、处理客服请求，还是提交代码变更。

Agent 的决策核心是 LLM 驱动。它利用大模型来管理工作流的执行，做出判断，识别任务何时完成，甚至在必要时主动纠正自己的行为。

同时，Agent 需要通过工具与外部世界交互。它必须能够访问并动态选择合适的工具（如 API、函数调用，甚至模拟 UI 操作）来获取信息或执行具体动作。

简单总结一下：Agent = LLM (大脑) + 工具 (手脚) + 指令 (行为准则) + 自主工作流执行。那些仅仅进行信息处理而不控制整个流程的 LLM 应用，比如简单的问答机器人或情感分析工具，在 OpenAI 看来，并不能算作 Agent。

什么时候应该构建 Agent？

并非所有自动化场景都天然适合引入 Agent。我们应该优先考虑那些传统自动化方法难以有效解决的复杂工作流。

特别是当你的工作流涉及复杂的决策制定时，比如需要细致的判断、处理各种异常情况，或者严重依赖上下文信息（客服场景中的退款审批就是个典型例子）。

或者，当你面对一个规则极其复杂、难以维护的系统时，Agent 可能是更好的选择。例如，对于那些规则集庞大且不断变化的供应商安全审查流程。

此外，如果流程重度依赖非结构化数据，需要深入理解自然语言、从文档中提取关键信息，或者与用户进行多轮对话交互（比如处理复杂的房屋保险索赔流程），那么 Agent 的能力将大有用武之地。

如果你的场景不符合以上几点，那么一个设计良好的确定性解决方案或许就已经足够，不必强行上 Agent。

Agent 的三大设计基础

构建一个 Agent，无论简单还是复杂，都离不开这三个核心的基石：

模型

选择合适的模型是第一步。OpenAI 给出的选型策略非常务实：先用能力最强的模型（比如当前的 GPT-4o）来构建你的 Agent 原型。这样做是为了首先摸清性能的上限，建立一个可靠的基准。

然后，在此基础上，再尝试将工作流中的某些步骤替换为更小、更快、成本更低的模型（如 GPT-4o mini 或o3-mini/o4-mini）。通过评估效果，看是否依然能满足业务需求。这样可以在不牺牲核心能力的前提下，逐步优化成本和响应速度。关键是要在任务复杂度、延迟和成本之间找到最佳平衡点。

工具

工具是 Agent 与外部世界交互的桥梁，极大地扩展了它的能力范围。这些工具可以是各种 API 接口、自定义的函数，甚至对于那些没有提供 API 的老旧系统，还可以借助所谓的“计算机使用模型”（可以理解为更智能的 UI 自动化）来直接操作应用程序界面。

指南将工具大致分为三类：

数据类 (Data) 工具：用于获取执行任务所需的信息和上下文，比如查询数据库、读取 PDF 文档内容，或者进行网页搜索。
行动类 (Action) 工具：用于在外部系统中执行具体操作，从而改变其状态，例如发送电子邮件、更新 CRM 系统里的客户记录，或者提交一个新的订单。
编排类 (Orchestration) 工具：一个 Agent 本身也可以被封装成一个工具，供另一个 Agent 调用。这在后面要讲到的 Manager 编排模式中会用到。

设计工具时，OpenAI 强调要遵循标准化定义、文档清晰、充分测试和可复用的原则。这不仅能提高工具被发现和理解的可能性，还能简化版本管理，避免团队内部重复开发相似的功能。

指令

高质量的指令对于 Agent 的表现至关重要，其重要性甚至超过了普通的 LLM 应用。清晰、明确的指令能够显著减少模糊性，改善 Agent 的决策质量，从而让整个工作流执行得更加顺畅，减少错误发生的概率。

如何写出好的指令？OpenAI 提供了一些最佳实践：

善用现有文档：把你手头已有的标准操作流程（SOP）、客服支持脚本或者相关的政策文档，作为编写 LLM 指令的基础。
拆解复杂任务：将复杂、冗长的任务分解成一系列更小、更清晰的步骤，这样有助于模型更好地理解和遵循。
明确具体动作：确保指令中的每一步都清晰地对应一个特定的动作或输出。例如，明确指示 Agent “询问用户的订单号”，或者“调用 get_account_details 这个 API 来获取账户详情”。甚至可以明确规定 Agent 回复用户时应该使用的具体措辞。
周全考虑边缘情况：真实世界的工作流充满了各种意外。要预见到用户可能提供不完整信息、提出意料之外的问题等情况，并在指令中包含相应的处理逻辑，比如设计条件分支或备选步骤。

OpenAI 还给出了一个“偷懒”小技巧：你可以利用像 GPT-4o 或 o3-mini 这样更强大的模型，让它帮你把现有的文档自动转换成结构化的 Agent 指令！指南里提供了一个可以直接使用的 Prompt 示例。

You are an expert in writing instructions for an LLM agent. Convert the 
following help center document into a clear set of instructions, written in 
a numbered list. The document will be a policy followed by an LLM. Ensure 
that there is no ambiguity, and that the instructions are written as 
directions for an agent. The help center document to convert is the 
following {{help_center_doc}}

Agent 的编排 (Orchestration)

有了模型、工具和指令这三大基础组件后，下一步就是思考如何将它们有效地组织起来，让 Agent 能够顺畅地执行复杂的工作流。这就是编排（Orchestration）要解决的问题。

OpenAI 强调，采用增量的方法通常会比一开始就构建宏大复杂的系统更容易成功。建议先从相对简单的单 Agent 系统入手，根据实际需求再逐步演进到多 Agent 协作的模式。

单 Agent 系统 (Single-Agent Systems)

这是最基础的模式。其核心机制可以理解为一个“运行循环” (Run Loop)。在这个循环中，Agent 会持续地运行：调用 LLM 进行思考和决策，根据决策结果选择并使用工具与外部交互，然后带着新的信息进入下一轮循环。

这个循环会一直持续下去，直到满足某个预设的退出条件。常见的退出条件包括：Agent 调用了一个被特殊标记为“最终输出”的工具；或者 LLM 在某一步的响应中没有调用任何工具，而是直接给出了面向用户的回复。

当单个 Agent 需要处理多种不同但逻辑相似的任务时，维护大量的独立 Prompt 会变得非常麻烦。这时，一个有效的策略是使用Prompt 模板。设计一个包含变量（例如 {{user_first_name}}, {{policy_document}} 等）的基础 Prompt 框架，在处理不同任务时，动态地填充这些变量。这种方法可以显著简化 Prompt 的维护和评估工作。

何时需要引入多 Agent？

虽然多 Agent 系统听起来更强大，但 OpenAI 的建议是：首先要充分挖掘和发挥单个 Agent 的潜力。因为引入更多的 Agent 必然会带来额外的复杂度和管理开销。

只有在遇到以下两种典型情况时，才需要认真考虑将任务拆分给多个 Agent：

逻辑分支过于复杂：当你的核心 Prompt 中包含了大量的条件判断语句（例如，多层嵌套的 if-then-else），导致 Prompt 本身变得难以理解、维护和扩展时。
工具过载或功能重叠：问题的关键并非工具数量的绝对多少，而是这些工具是否定义清晰、功能独特。如果 Agent 经常在多个功能相似或描述模糊的工具之间选择困难，即使优化了工具的名称、描述和参数定义后，性能依然无法改善，那么将相关的工具和逻辑拆分到不同的专用 Agent 可能就是必要的。有趣的是，指南提到，有些成功的案例中，单个 Agent 能有效管理超过 15 个定义良好的工具，而另一些情况下，即使少于 10 个功能重叠的工具也可能导致混乱。

多 Agent 系统 (Multi-Agent Systems)

当你确定需要使用多个 Agent 来协同完成任务时，OpenAI 主要介绍了两种常见的、具有广泛适用性的编排模式：

Manager 模式 (Agents as Tools)
这种模式下，有一个中心的“Manager” Agent 扮演协调者的角色。它负责接收初始的用户请求，然后像调用普通工具一样，通过工具调用 (tool calls) 的方式，将任务的不同部分分配给下属的多个“专家” Agent 来处理。每个专家 Agent 都专注于特定的任务或领域。最后，Manager Agent 负责收集和整合来自各个专家 Agent 的结果，形成最终的、统一的输出。
这种模式的优点在于控制流程非常清晰，易于管理和理解。它特别适合那些需要一个统一的对外交互界面，并且需要对多个子任务的结果进行综合处理的复杂工作流。
在技术实现上，通常会将每个专家 Agent 封装成一个函数或 API，使其可以像普通工具一样被 Manager Agent 调用（例如，在 OpenAI 的 Agents SDK 中，可以使用 agent.as_tool() 方法）。

Decentralized 模式 (Agents Handing Off to Agents)
在这种去中心化的模式中，Agent 之间是相对平等的关系。它们之间通过一种叫做“移交” (Handoff) 的机制来传递工作流的控制权。Handoff 通常是一种单向的控制权转移。当一个 Agent 决定将任务移交给另一个 Agent 时，它会调用一个特殊的 Handoff 工具或函数。
一旦 Handoff 被调用，系统的执行焦点会立即切换到被移交的那个 Agent，并且通常会将当前的对话状态（上下文信息）一并传递过去。新的 Agent 接管后，就可以独立地继续处理任务，并与用户进行交互。
这种模式特别适合那些不需要一个中心协调者来统一管理或合成结果的场景。一个典型的应用就是**对话分诊 (Conversation Triage)**。比如，一个初始的 Triage Agent 先接收用户的请求，判断问题类型后，直接将对话 Handoff 给专门负责销售、技术支持或订单管理的 Agent。
这种模式的灵活性在于，你可以设计成完全的单向移交，也可以在目标 Agent 上配置相应的 Handoff 工具，允许它在需要时将控制权再移交回来。

Guardrails) - 确保 Agent 安全可靠运行

对于任何希望在生产环境中部署的 Agent 系统来说，设计和实施有效的护栏 (Guardrails) 都是不可或缺的关键环节。护栏的主要目的是帮助你管理和减轻各种潜在的风险，比如防止敏感数据（如系统 Prompt）泄露，或者避免 Agent 产生不当言论损害品牌声誉，以及抵御恶意的指令注入攻击等。

OpenAI 强调分层防御的理念。单一的护栏措施往往难以提供全面的保护，需要将多种不同类型、不同侧重点的护栏结合起来，构建一个纵深防御体系。

常见的护栏类型包括：

相关性分类器 (Relevance Classifier)：用于判断用户的输入或 Agent 的响应是否偏离了预设的主题范围，防止对话跑题。
安全分类器 (Safety Classifier)：专门检测那些试图利用系统漏洞的恶意输入，例如越狱提示 (Jailbreaks) 或 Prompt 注入攻击。
PII 过滤器 (PII Filter)：在 Agent 的输出内容发送给用户之前进行检查，移除或屏蔽其中可能包含的个人身份信息 (Personally Identifiable Information)。
Moderation API：利用 OpenAI 或其他提供商的内容审核服务，来过滤掉涉及仇恨言论、骚扰、暴力等有害或不适当的输入或输出。
工具使用保障 (Tool Safeguards)：对 Agent 可用的每个工具进行风险评估（例如，区分只读操作和写入操作、操作是否可逆、是否需要特殊权限、是否涉及资金等），并根据风险等级设置不同的安全策略。比如，在执行高风险工具调用前，强制进行额外的安全检查，或者直接暂停执行并请求人工确认。
基于规则的保护 (Rules-based Protections)：采用一些简单但有效的确定性规则来防御已知威胁，例如维护一个禁止词列表 (Blocklists)、限制输入内容的长度，或者使用正则表达式 (Regex) 来过滤潜在的 SQL 注入等攻击模式。
输出内容验证 (Output Validation)：通过精心的 Prompt 工程设计和对 Agent 输出内容的检查，确保其响应符合品牌形象和价值观，避免产生可能损害声誉的内容。

构建护栏的策略建议：

首先重点关注数据隐私保护和内容安全这两个最核心的领域。
在系统运行过程中，根据实际遇到的边缘案例和失败模式，逐步识别新的风险点，并有针对性地添加或完善相应的护栏措施。
持续在安全性和用户体验之间寻求平衡。过于严苛的护栏可能会影响 Agent 的正常功能和用户体验，需要根据 Agent 的发展和应用场景的变化，不断进行调整和优化。

值得一提的是，在 OpenAI 自家的 Agents SDK 中，默认采用了一种叫做“乐观执行”(Optimistic Execution) 的策略：主 Agent 会先尝试生成输出或执行动作，而相关的护栏检查则在后台并发进行。如果检测到违反策略的情况，护栏会及时抛出异常来中断不安全的操作。

别忘了规划人工干预 (Human Intervention)

最后，指南特别强调了规划人工干预机制的必要性。尤其是在 Agent 部署的早期阶段，建立一个顺畅的人工介入流程至关重要。

这不仅是最终的安全保障，更是持续改进 Agent 性能的关键环节。通过分析需要人工介入的案例，你可以发现 Agent 的不足之处、识别未曾预料到的边缘情况，并为模型的微调和评估提供宝贵的真实世界数据。

通常需要触发人工干预的主要时机有两个：

超出预设的失败阈值：例如，可以设定 Agent 在连续几次尝试后仍然无法理解用户意图，或者某个操作连续失败达到一定次数时，就自动将任务升级给人工处理。
执行高风险操作：对于那些具有敏感性、不可逆转性或者涉及重大利益的操作（比如取消用户订单、批准大额退款、执行支付等），在 Agent 的可靠性得到充分验证之前，应当默认触发人工审核或确认环节。