行业必读：OpenAI最新报告Agents构建最佳实践_AI热点日报

大语言模型处理复杂多步骤任务的能力日益增强。在推理、多模态交互以及工具调用等方面的技术进展，催生了一类由大语言模型驱动的新型系统——智能体（Agent）。本指南专为那些希望构建首个Agent的产品与工程团队而设计，它将众多客户实际部署案例中的经验与洞见，提炼为实用且可操作的最佳实践方案。指南内容覆盖了Agent框架的选择、Agent逻辑与编排模式的设计，以及确保Agent安全、可预测且高效运行的核心方法。阅读完本指南后，你将掌握着手构建首个Agent所需的基础知识与关键策略。

什么是Agents？

传统软件能够帮助用户简化和自动化工作流程，而Agent则能以高度自主的方式，代表用户执行相同的工作流。Agent是一类能够独立为你完成任务的智能系统。工作流（Workflow）是指为实现特定用户目标而必须执行的一系列步骤，这些目标可能包括解决客户服务问题、预订餐厅、提交代码更改或生成业务报告等。那些集成了大语言模型，但并未利用模型来控制工作流执行的应用——例如简单的聊天机器人、单轮问答的大语言模型，或仅做情感分类任务的程序——并不属于Agent的范畴。

更具体地说，一个Agent具备以下核心特征，使其能够可靠且一致地代表用户执行任务：第一，它利用大语言模型来管理工作流的执行过程并做出决策。它能够识别工作流何时完成，并在必要时主动纠正自身的行动。若执行失败，它可以停止操作并将控制权交还给用户。第二，它能够访问多种工具，以便与外部系统进行交互——无论是收集上下文信息，还是采取具体的行动——并根据工作流的当前状态，动态地选择合适的工具，且始终在明确界定的约束范围内运行。

何时需要构建Agent？

构建Agent需要对系统如何做出决策以及如何处理复杂任务进行重新思考。与传统自动化方案不同，Agent特别适用于那些传统的、确定性的和基于规则的方法难以发挥作用的复杂工作流。以交易风险识别为例。传统系统通常像“打勾清单”，只有当交易满足某些固定条件时，才将其标记为异常。而由大语言模型驱动的Agent，则更像一位经验丰富的调查员——它会结合上下文、观察细微细节，即使没有违反明确规则，也能识别出可疑活动。这种精细的推理能力，正是Agent能够有效处理复杂、模糊情境的根本原因。

在评估Agent能够在哪些领域创造价值时，应优先考虑那些以往难以实现自动化的工作流，尤其是传统方法遇到阻碍的领域：

复杂决策：涉及细节判断、例外情况或上下文敏感决策的工作流，例如客户服务流程中的退款审批决策。
难以维护的规则：由于规则体系非常广泛且复杂而变得难以管理的系统，更新成本高昂或容易出错，例如进行供应商安全审查。
严重依赖非结构化数据：涉及解释自然语言、从文档中提取含义或与用户进行对话交互的场景，例如处理家庭保险理赔。

在决定构建Agent之前，请确保你的应用场景能够明确满足上述标准。否则，确定性的解决方案可能已经足够。

Agents设计基础

从最基本的形式来看，一个Agent由三个核心组件构成：

模型：驱动Agent进行推理和决策的大语言模型。
工具：Agent可以用来采取行动的外部函数或应用程序接口（API）。
指令：明确界定Agent行为边界与操作准则的规则和约束。

以下是使用OpenAI的Agent软件开发工具包（SDK）时在代码中的体现。你也可以使用自己偏好的库，或者从零开始实现相同的核心概念。

选择模型

不同的模型在任务复杂性、响应延迟和成本方面各有优劣。正如我们将在接下来的编排部分看到的，你可能需要考虑为工作流中的不同任务选用多种模型。并非每个任务都需要功能最强大的模型——简单的检索或意图分类任务可以由较小、速度更快的模型处理，而像决定是否批准退款这样的复杂任务，则可能需要更强大的模型。

一种有效的方法是，先用当前最强大的模型为每个任务构建Agent原型，观察其最佳性能表现。然后，尝试用较小的模型替换，并评估是否仍能达到可接受的结果。这样，你既不会过早限制Agent的能力，也能找出较小模型在哪些方面表现成功或失败。总之，选择模型的原则可以概括为：

建立评估机制，以确定性能基线。
初期专注于使用现有最佳模型来达成你的准确性目标。
在可能的情况下，用较小的模型替换较大的模型，以优化成本和延迟。

定义工具

工具通过调用底层应用或系统的API来拓展Agent的能力。它们通常是通过各种系统和应用提供的接口，帮助智能体调用功能、获取数据。若部分老旧系统没有提供API，那么智能体也可以采用“模拟人工操作”的方式，例如点击网页、填写表单，就像人类一样去使用这些系统。每个工具都应具备标准化的定义，以便在工具和Agent之间实现灵活的多对多关系。文档完善、经过充分测试且可复用的工具，能够提高可发现性、简化版本管理并避免重复定义。

一般来说，Agent需要三种类型的工具：

例如，使用Agent SDK时，你可以按以下方式为上述定义的Agent配备一系列工具：随着所需工具数量的增加，可以考虑将任务分配给多个Agent（具体请参阅编排部分）。

配置指令

高质量的指令对于任何由大语言模型驱动的应用都至关重要，对于Agent来说尤其如此。清晰的指令能够减少歧义，提高Agent的决策能力，从而使工作流执行更加顺畅，并减少错误发生的概率。

配置Agent指令的最佳实践包括：

利用现有文档：在整理流程模板时，可以直接参考你现有的操作手册、客服话术或公司政策文档，将它们改写成适合大模型理解的版本。
用提示词为Agent分解任务：从密集的资源中提炼出更小、更清晰的步骤，有助于减少歧义，使模型更好地遵循指令。
定义明确的行动：确保流程模板中的每个步骤都对应一个特定的行动或输出。例如，一个步骤可能指示Agent向用户询问订单号，或调用API以检索账户详细信息。明确行动可以减少解释错误的空间。
考虑特殊情况（Corner Case）：在真实使用场景中，用户经常会提供不完整的信息，或者提出意料之外的问题，这时系统就需要做出判断：下一步该怎么走。一个设计良好的流程，应该提前考虑这些“常见偏差”或“异常情况”，并在指令中给出说明：如果遇到这种情况，可以如何处理——比如加入条件判断，或设置一个“备用步骤”，在缺少某项信息时也能继续运行。

你可以使用先进的模型，如o1或o3-mini，从现有文档中自动生成指令。以下是一个说明这种方法的示例Prompt：

编排

在具备了基础组件之后，需要考虑编排模式，以使Agent能够有效地执行工作流。虽然直接构建具有复杂架构的完全自主Agent很有吸引力，但客户通常通过渐进式方法取得了更大的成功。

一般来说，编排模式分为两类：

单智能体系统：由一个配备了适当工具和指令的模型在循环中执行整个工作流。
多智能体系统：在多个互相协调的Agent之间执行工作流。

让我们详细探讨每种模式。

单智能体系统

单个Agent可以通过逐步添加工具来处理许多任务，这样可以有效控制复杂性，并简化评估和维护工作。每个新工具都能扩展其能力，而无需过早地必须编排多个Agents。

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

例如，在Agents SDK中，使用Runner.run()方法启动Agent，该方法会循环执行，直到满足以下条件之一：

调用了用于最终输出的工具，该工具由特定的输出类型定义。
模型返回了没有任何工具调用的响应（例如，直接回复用户消息）。

这种循环概念是Agent功能的核心。在多智能体系统中，可以有一系列的工具调用和Agent之间的交接，但核心仍是允许模型运行多个步骤，直到满足退出条件。

一种在不使用多Agent架构的前提下管理复杂流程的有效方法，就是使用提示词模板（prompt templates）。与其为每一个具体场景都编写一套新的提示，不如使用一套通用的基础模板，然后通过填写不同的“变量”来适配不同需求。这种做法非常灵活，能够适应多种上下文，而且大大降低了维护成本和测试难度。当有新的使用场景出现时，只需要更新变量，而不必从头重写整个流程。

何时考虑使用多智能体系统？

我们的一般建议是：优先充分发挥单智能体系统的能力。虽然引入多个Agents有助于更清晰地划分任务概念，但也会带来额外的复杂度和系统开销，因此在多数情况下，一个Agent配合合适的工具就已足够满足需求。

不过，在面对流程复杂度较高的场景时，将提示词和工具合理拆分到多个Agents中，可以显著提升系统的性能和可扩展性。如果你发现现有Agent无法正确执行复杂指令，或者频繁调用错误的工具，可能就需要将任务进一步细化，创建分工更加明确的Agent。

以下是常见需要拆分Agent的两个参考标准：

逻辑复杂：当提示词中包含大量的条件判断（如多个if-then-else分支），或模板逻辑变得难以维护时，建议按逻辑片段将任务拆分给不同Agents分别处理。
工具过载：问题不在于工具数量本身，而在于它们之间的相似度和重叠度。有些系统能成功管理15个以上定义清晰的工具，而另一些则在不到10个模糊重叠的工具中就出现混乱。如果你的系统中工具名称不清、边界模糊、用途重叠——可以考虑拆分为多个Agents，各自负责更清晰的子任务，以提升执行效率。

多智能体系统

多智能体系统可以根据不同的业务流程和场景需求，设计出各种结构。但从实际客户经验来看，我们总结出两种通用、可落地的设计模式：

管理者模式（Agent作为工具本身）：由一个中心Agent担任“管理者”角色，通过工具调用的方式调度多个专职Agent，每个Agent负责一个具体任务或领域。
去中心化模式（Agent之间相互交接）：多个Agent平行运行，彼此间根据各自专长进行任务接力和分工协作。

多Agent系统可以被抽象为一张图谱，图中的节点代表Agent：在管理者模式中，连线表示工具调用；在去中心化模式中，连线表示任务的转交和流转。无论采用哪种编排模式，设计时都应遵循以下通用原则：保持模块灵活、可组合，任务定义清晰，提示词结构明确。

管理者模式

管理者模式的核心是由一个中心大语言模型（即“管理者”）通过工具调用，协调一组专业化的Agent协同完成任务。它不会丢失上下文或控制权，而是能在恰当的时间，将任务智能地分派给合适的Agent，并将各部分结果自然整合为一次流畅的交互。这种模式带来的好处是：用户体验统一顺畅，每个专业能力都能按需随时调用。

管理者模式非常适合这样的场景：你希望由一个Agent负责控制整个流程的执行，并且它能直接与用户交互。例如，你可以通过Agents SDK如此实现：有些框架采用声明式方式，要求开发者在一开始就明确地定义出流程中的每一个分支、循环和条件判断——通常通过由节点（Agent）和边（代表确定性或动态任务交接）构成的图来描述整个流程。这种方式虽然可视化效果好，但随着流程变得更动态、更复杂，维护成本会迅速上升。开发者可能还需要额外学习一些专用领域语言（DSL），使用门槛较高。

相比之下，Agents SDK采用的是更灵活的代码优先（code-first）方式。开发者可以直接用熟悉的编程结构来表达流程逻辑，无需预先定义完整的图结构，从而实现更加动态、可扩展的Agent编排能力。

去中心化模式

在去中心化的模式中，Agent之间是“平等协作”的关系，它们可以把手上的任务交接（handoff）给其他Agent去继续完成。这个“交接”有点像传递接力棒：一个Agent跑到某个阶段后，可以把流程和对话状态一起“交给”另一个Agent，接着往下跑。在Agents SDK中，handoff就是一种特殊的工具或函数，用来实现这种交接机制。

这种模式的特点是：所有Agent地位相当，没有谁是总指挥。每个Agent都可以根据自己的专长，直接把任务交给另一个更合适的Agent来处理，而不需要中间有一个统一协调的“管理者”。它特别适合那些不需要中央控制、任务分布明确、Agent各自负责独立事务的场景。

举个例子：如果你用Agents SDK来实现一个客服流程，同时要处理销售和售后支持两个方向的需求，你就可以用去中心化模式来搭建这个系统。在上面的例子中，用户发来的消息会先进入一个任务分发Agent（triage_agent），它会根据用户的内容来决定将任务交给谁。例如，发现用户是在咨询订单问题，它就会把对话“转给”专门负责订单处理的order_management_agent，由它继续接手并处理后续流程。这种做法特别适合那些希望先判断用户需求，再精准分流到合适Agent的场景。你还可以让处理订单的Agent，在处理完后把对话再交还回来，由任务分发Agent继续跟进，例如进行结束语、满意度收集等工作。

防护

在构建基于大模型的系统时，Guardrails（护栏机制）就像AI的“安全防护栏”，可以帮助我们防止隐私泄露（例如提示词被暴露）、不当言论（例如说出与品牌不符的内容）等风险。一个护栏可能挡不住所有问题，但多个不同类型的护栏配合使用，就能构建出更稳健的防线。常见做法包括结合大模型本身的限制机制、基于规则的检查（比如正则表达式），再加上像OpenAI Moderation API这样的内容审核工具。同时，护栏不能单打独斗，最好与身份认证、权限控制、标准安全策略等传统技术一起搭配使用，形成一套“多层防御网”。

防护的类型：构建护栏时，首先要针对您用例中已知的风险点设置护栏，然后在实践中遇到新的边缘案例或系统失效时，再逐步增加额外的防护层。我们发现以下实践经验颇为有效：

首要关注数据隐私和内容安全。
根据实际运行中遇到的边缘案例和失败情况，不断补充新的护栏。
在保障安全的同时，也要兼顾用户体验，随着Agent的迭代优化护栏策略。

例如，以下代码展示了如何在Agents SDK中设置护栏：Agents SDK把Guardrails当作核心功能来看待，默认由Agent主动生成响应，同时由多条护栏机制在后台并行运行，一旦发现有违规，就会立即触发异常。这些护栏可以是函数或专门的Agent，用于阻止越狱、过滤敏感词、识别不相关内容、执行黑名单或风险分类等。比如用户输入一道数学题，系统会先“乐观执行”，但如果触发了math_homework_tripwire这种护栏，就会立即拦截。

人工介入机制

除了系统自动拦截外，还要为人工介入（human intervention）预留机制。当Agent无法判断或完成任务时，能及时将控制权交给人工，这样既能保障体验，又能防止错误扩大。特别是在系统上线初期，更需要人工介入来识别问题、积累案例、持续优化。

常见的人工介入触发点有两种：

失败太多：例如连续几次都无法理解用户意图，就应转交人工处理；
风险太高：例如取消订单、批准大额退款等敏感操作，建议必须有人把关。

结论

Agent代表了工作流自动化的一个新时代。它们能够在信息不明确的情况下进行判断，跨系统调用工具，并以高度自主的方式完成多步骤任务。相比那些功能比较简单的大模型应用，Agent能够从头到尾执行整个流程，非常适合需要复杂决策、处理非结构化数据，或者依赖传统规则系统的场景。

要打造一个稳定可靠的Agent，第一步就是打好基础：选用能力强的大模型，配上定义清晰的工具，再写出结构明确、指令清楚的任务描述。根据业务的复杂程度选择合适的编排模式：初期可以先使用一个Agent，等需要时再扩展成多Agent协同的系统。

在每个阶段，护栏机制（Guardrails）都很关键——无论是输入内容的检查、工具的调用，还是后期需要人工接手，都能帮助系统更安全、更稳定地上线运行。成功部署Agent系统，并不需要一口气做完。你可以先从小流程开始，先让真实用户使用并验证效果，然后再逐步拓展Agent的能力和范围。只要基础扎实、方法对头，再通过不断优化，Agent最终不仅能自动完成任务，还能灵活地自动化整个工作流，为业务真正带来价值。