OpenAI开源34页AI智能体最佳实践白皮书

最近OpenAI发布了一份34页的《构建AI Agent实用指南》（A practical guide to building agents），内容非常详实，相较于Google之前的Agent白皮书，感觉在深度上更进一步。这份指南从基本定义出发，涵盖了模型选择、工具设计、指令编写，以及复杂的编排模式和安全防护措施，提供了一套完整且切实可行的建议。今天，我们来梳理这份OpenAI Agent开发指南的核心内容精华。

到底什么是AI Agent？

OpenAI对Agent的定义相当清晰：它不仅仅是聊天机器人或简单的LLM调用，关键在于能够独立执行工作流程。Agent可以代表用户，在某种程度上自主地完成一系列步骤以实现目标，例如订餐、处理客服请求，或者提交代码变更。

Agent的决策核心是由LLM驱动——利用大模型来管理工作流程的执行，做出判断，识别任务何时完成，甚至在必要时主动纠正自身行为。同时，Agent需要借助工具与外部世界进行交互，必须能够访问并动态选择合适的工具（如API、函数调用，甚至模拟UI操作）来获取信息或执行具体操作。

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

什么时候应该构建Agent？

那么，是否所有自动化场景都适合使用Agent？未必。我们应该优先考虑那些传统自动化方法难以有效处理的复杂工作流程。

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

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

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

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

Agent的三大设计基础

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

模型

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

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

工具

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

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

• 数据类工具：用于获取执行任务所需的信息和上下文，比如查询数据库、读取PDF文档内容，或者进行网页搜索。
• 行动类工具：用于在外部系统中执行具体操作，从而改变其状态，例如发送电子邮件、更新CRM系统里的客户记录，或者提交一个新订单。
• 编排类工具：一个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能够顺畅地执行复杂的工作流。这就是编排要解决的问题。

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

单Agent系统

这是最基础的模式。其核心机制可以理解为一个“运行循环”。在这个循环中，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系统

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

• Manager模式（Agents as Tools）：

  这种模式下有一个中心的“Manager”Agent扮演协调者角色。它负责接收初始的用户请求，然后像调用普通工具一样，通过工具调用的方式将任务的不同部分分配给下属的多个“专家”Agent来处理。每个专家Agent都专注于特定的任务或领域。最后，Manager Agent负责收集和整合来自各个专家Agent的结果，形成最终统一输出。

  这种模式的优点在于控制流程非常清晰，易于管理和理解。它特别适合那些需要一个统一的对外交互界面，并且需要对多个子任务的结果进行综合处理的复杂工作流。在技术上，通常将每个专家Agent封装成一个函数或API，使其可以像普通工具一样被Manager Agent调用。

• 去中心化模式（Agents Handing Off to Agents）：

  在这种模式中，Agent之间是相对平等的关系，通过一种叫做“移交”的机制来传递工作流的控制权。Handoff通常是一个单向的控制权转移。当一个Agent决定将任务移交给另一个Agent时，它会调用一个特殊的Handoff工具或函数。

  一旦Handoff被调用，系统的执行焦点会立即切换到被移交的那个Agent，并且通常会将当前的对话状态（上下文信息）一并传递过去。新的Agent接管后，就可以独立地继续处理任务并与用户进行交互。

  这种模式特别适合那些不需要一个中心协调者来统一管理或合成结果的场景。一个典型的应用就是对话分诊——比如一个初始的Triage Agent先接收用户的请求，判断问题类型后，直接将对话Handoff给专门负责销售、技术支持或订单管理的Agent。你可以设计成完全的单向移交，也可以在目标Agent上配置相应的Handoff工具，允许它在需要时将控制权再移交回来。

护栏机制 - 确保Agent安全可靠运行

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

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

常见的护栏类型包括：

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

构建护栏的策略建议：

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

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

别忘了规划人工干预

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

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

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

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

总结

把核心要点再串一遍：

Agent的本质是LLM、工具和指令的结合，能够自主执行复杂工作流。基础工作很重要：选择合适的模型能力，设计标准化、文档清晰的工具集，编写明确、覆盖全面的指令。根据实际的复杂性需求选择恰当的编排模式，从简单的单Agent系统开始逐步迭代。分层、健壮的安全护栏机制是生产级Agent部署的必备条件。最后，拥抱迭代优化的思想，善用人工干预机制来发现问题、收集反馈，持续提升Agent的性能和可靠性。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：OpenAI开源34页AI智能体最佳实践白皮书要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题