OpenAI 近期发布了三份面向企业客户的研究报告，此次从中挑选出了“Building AI agents 的实用指南”这一篇并进行了翻译。
如果不是 Agent 资深开发大佬，那么强烈建议 AI 行业的大家都来读一下这篇报告。
Agent 和 Workflow 有哪些区别？它们各自的使用场景是什么？在什么情况下使用单智能体系统？在什么情况下使用多智能体系统？如何用简单代码实现各类功能？多智能体系统有哪些设计模式？怎样保证 Agent 的各项安全？OpenAI 对这些问题都进行了通俗的表达。
本文章是由 Coze Space 进行翻译的，并且经过了特工们的精校。以上的三份英文原文件能够加入我们的 ima 知识库，并且可以免费获取。后续将会更新剩下两篇的精校翻译。
以下为正文：
引言
大语言模型处理复杂多步骤任务的能力在不断增强。在推理方面有了进展，在多模态方面有了进展，在工具调用方面也有了进展，这些进展催生了一类新型系统，这类系统是由大语言模型驱动的，它被称为 Agent。
本指南是为了探索构建首个 Agent 的产品和工程团队而设计的。它把众多客户部署案例中的见解提炼出来，形成了实用且可操作的最佳实践。这些最佳实践涵盖了 Agent 框架、设计 Agent 逻辑和编排模式，还包括确保 Agent 安全、可预测且高效运行的内容。
阅读完本指南后，你就能够拥有开始构建第一个 Agent 所需要的那些基础知识。
什么是 Agents？
传统软件能够帮助用户把工作流进行简化以及实现自动化。Agent 则可以高度自主地去执行与传统软件相同的工作流。
Agent 是能够代表你独立完成任务的系统。
Workflow 是一系列必须执行的步骤，目的是实现用户目标。这些目标包括解决客户服务问题、预订餐厅、提交代码更改以及生成报告等。
集成了大语言模型，然而没有用其来控制工作流执行的应用不属于 Agent 。例如简单的聊天机器人，以及单轮大语言模型或者做情感分类任务的应用都不属于 Agent 。
具体而言，Agent 拥有以下这些核心特征，凭借这些特征它能够可靠且始终如一地替用户执行任务。
它利用大语言模型来管理工作流的执行并且做出决策。它可以识别出工作流完成的时间，在需要的时候能够主动纠正自身的行动。如果执行出现失败的情况，它可以停止执行并且把控制权交还给用户。
第二，它能够访问各类工具，用于与外部系统展开交互。它既可以收集相关的上下文信息，又能够采取行动。并且会依据工作流的当下状态，动态地挑选出合适的工具，始终在有着明确界定的约束范围之内运行。
何时需要构建 Agent？
构建 Agent 时需要重新思考系统做出决策的方式，以及处理复杂任务的方式。传统自动化与之不同，Agent 尤其适合那些传统的确定性方法和基于规则的方法难以发挥作用的工作流。
以交易风险识别作为例子。传统系统就如同“打勾清单”，只要交易符合某些既定条件，就会被标记为异常。然而，大语言模型驱动的 Agent 更像是一位经验丰富的调查员，它会将上下文相结合，会观察细节，即便没有违反明确的规则，也能够识别出可疑的活动。这种细致的推理能力，正是 Agent 能够对复杂、模糊的情况进行有效处理的原因所在。
在评估 Agent 能在哪些方面创造价值时，要先考虑那些以往难以实现自动化的工作流，尤其要关注传统方法遇到阻碍的领域。
涉及细节判断、处理例外情况或基于上下文做敏感决策的工作流属于复杂决策，就像客户服务工作流中的退款审批那样。
规则非常广泛且复杂，这使得系统难以管理，变得难以维护。其更新成本高，也容易出错，比如进行供应商安全审查。
严重依赖非结构化数据的情况存在于以下场景：需要解释自然语言，能够从文档中提取含义，或者可以与用户进行对话交互，比如在处理家庭保险理赔时。
在构建 Agent 之前，你需要确保你的用例能够明确地满足某些标准。如果不能满足，那么确定性解决方案或许就已经足够了。
Agents 设计基础
从最基本的形式来看， Agent 由三个核心组件组成：
1. 模型：驱动 Agent 推理和决策的大语言模型。
工具包括可以用来采取行动的外部函数或 API，这些是 Agent 所具备的。
3. 指令：明确界定 Agent 行为的准则和约束。
使用 OpenAI 的 Agent 软件开发工具包（SDK）在代码中会有相应体现。同时，你能够使用自己心仪的库，或者从一开始就实现相同的概念。
选择模型
不同的模型在任务复杂性方面有各自的优势和劣势，在延迟方面也有不同的表现，在成本方面同样各有特点。就像我们在接下来的编排部分将会看到的那样，你或许需要考虑针对工作流中的不同任务选用多种模型。
有些任务不需要最强大的模型。像简单的检索或意图分类这类任务，能够由较小且速度更快的模型来处理。而像决定是否批准退款这样复杂的任务，则可能需要更强大的模型。
一种有效的方式是，首先用最强大的模型为每个任务构建 Agent 原型，去观察它在最佳状态下能够达到何种程度。接着，尝试用较小的模型来进行替换，查看是否依然能够获得可接受的结果。如此一来，既不会过早地对 Agent 的能力进行限制，又能够找出较小模型在哪些方面能够成功或者失败。
总之，选择模型的原则很简单：
1. 建立评估机制以确定性能基线。
2. 专注于使用现有最佳模型达到你的准确性目标。
在有可能性的情形下，使用较小的模型去替换较大的模型，这样能对成本和延迟进行优化。
定义工具
工具借助底层应用或系统的 API 以扩展 Agent 的能力。通常是利用各种系统和应用所提供的 API，协助智能体调用功能并获取数据。倘若一些老系统不存在 API，那么智能体可以采用“模拟人操作”的方式，例如点击网页、填写表单，如同人一样去使用系统。
每个工具都需要有标准化的定义，这样才能在工具与 Agent 之间构建起灵活的多对多关系。文档完备、经过充分测试并且可以复用的工具，能够提升其可发现性，还能简化版本管理，同时避免重复定义。
一般来说，Agent 需要三种类型的工具：
在使用 Agent SDK 时，你能够以如下方式为上述所定义的 Agent 配备一系列工具：
随着所需工具的数量增多，能够考虑把任务分配给多个 Agent 。（可参考编排部分）
配置指令对于任何由大语言模型驱动的应用都很重要，对于 Agent 更是如此。清晰的指令能够减少歧义，提升 Agent 的决策能力，这样就能让工作流执行更顺畅，减少错误。
Agent 指令的最佳实践：
整理流程模板时，能够直接参照你已有的操作手册、客服话术或公司政策文档，然后将其改写成适合大模型理解的形式。
用提示词给 Agent 分解任务，从密集的资源中提供步骤，这些步骤要更小且更清晰，这样有助于减少歧义，能让模型更好地遵循指令。
定义清晰的行动：要保证流程模板里的每个步骤都有一个特定的行动或者输出与之对应。比如说，某一个步骤或许会要求 Agent 向用户询问订单号，又或者调用 API 来检索账户的详细信息。明确的行动能够降低解释出现错误的可能性。
考虑特殊情况，也就是 Corner Case。在真实使用的时候，用户常常会给出不完整的信息，或者提出一些意料之外的问题。在这种情况下，系统就需要进行判断，要确定下一步该如何走。一个设计良好的流程需要提前考虑“常见偏差”或“异常情况”，并且在指令中进行说明：若遇到此类情况，能够知道如何处理，例如加入条件判断，或者设置一个“备用步骤”，即便缺少某项信息也能继续运行。
你能够运用先进的模型，像 o1 或者 o3 - mini 那样，从已有的文档里自动生成指令。以下是一个能够阐释这种方式的示例 prompt：
编排
具备基础组件之后，就可以考虑编排模式了，这样能让 Agent 有效地执行工作流。
直接构建具有复杂架构的完全自主的 Agent 具有吸引力，然而客户通常通过渐进式方法能取得更大的成功。
一般来说，编排模式分为两类：
单智能体系统中，一个模型配备了适当的工具和指令，在循环里执行工作流。
多智能体系统是指在多个 Agent 之间进行协调并执行工作流。 多个 Agent 相互协调，然后在它们之间执行工作流。 多个互相协调的 Agent 会执行工作流。
让我们详细探讨每种模式。
单智能体系统
单个 Agent 能够通过逐步增添工具的方式来处理诸多任务，这种方式能够对复杂性进行控制，同时也能让评估和维护变得更加简单。每一个新的工具都可以拓展其自身的能力，并且不会过早地就必须要对多个 Agents 进行编排。
每个编排方法都包含“运行”的概念，一般会将其实现为一个循环，使智能体持续运行，直至满足退出条件。常见的退出条件有工具调用、特定的结构化输出、出现错误或者达到最大轮数。
在 Agents SDK 里，通过使用 `Runner.run()` 这个方法来启动 Agent，此方法会持续循环执行，直至满足以下这些条件中的某一个：
1. 调用了最终输出的工具，由特定的输出类型定义。
模型给出了没有调用任何工具的回应，比如直接的用户消息。
示例用法：
这种循环概念是 Agent 功能的关键所在。在多智能体系统里，存在着一系列的工具调用以及 Agent 之间的交接情况，不过能够允许模型运行多个步骤，直至退出条件得以满足。
一种在无需使用多 Agent 架构的情况下，能够管理复杂流程的有效办法是运用提示词模板（prompt templates）。不要为每一个特定的场景都去撰写一套全新的提示，而是采用一套通用的基础模板，接着通过填充不同的“变量”，以适应不同的需求。
这种做法具有很大的灵活性，它可以适应各种各样的上下文。同时，这种做法还大大降低了维护成本以及测试的难度。当新的使用场景出现时，只需对变量进行更新，而无需从头开始重新编写整个流程。
何时考虑使用多智能体系统？
我们的一般建议是：优先充分发挥单智能体系统的能力。
引入多个 Agents 有助于清晰划分任务概念，然而也会带来额外的复杂度与系统开销。所以在多数情况下，一个 Agent 配合合适的工具就已经足够了。
在面对流程复杂度较高的场景时，把提示词和工具合理地拆分到多个 Agents 里，这样能够显著地提升系统的性能以及可扩展性。
如果你发现现有的 Agent 不能够正确地执行复杂的指令，那么就可能需要将任务进一步细化。如果你发现现有的 Agent 频繁地调用错误的工具，那么也可能需要将任务进一步细化，并且创建分工更加明确的 Agent。
以下是常见需要拆分 Agent 的两个参考标准：
当提示词中包含众多条件判断，像多个 if-then-else 分支那样，或者模板逻辑变得难以进行维护时，建议依据逻辑片段把任务拆分开来，交给不同的 Agents 分别去处理。
工具过载的情况是，问题并非仅仅在于工具的数量，而是在于这些工具之间的相似度以及重叠度。有些系统能够成功地管理 15 个及以上定义清晰的工具，然而，还有一些系统在不到 10 个模糊且重叠的工具中就会出现混乱的状况。
如果你的系统中工具的名称不清晰，边界模糊，用途相互重叠，那么就可以考虑将其拆分为多个 Agents，每个 Agents 负责更清晰的子任务，这样能够提升执行效率。
多智能体系统
多智能体系统能够依据不同的业务流程以及场景需求，设计出各式各样的结构。
从实际客户的经验方面来看，我们总结出了两种设计模式，这两种模式是通用的且可以落地的。
一个中心 Agent 担任“管理者”角色，采用管理者模式（Agent 作为工具本身），通过工具调用来调度多个专职 Agent，每个专职 Agent 负责一个具体的任务或领域。
去中心化模式下，多个 Agent 平行运行。Agent 之间相互交接，彼此依据各自的专长进行任务接力，也进行分工协作。
多 Agent 系统可被抽象成一张图谱，其中的节点代表 Agent。在管理者模式里，连线意味着工具调用。在去中心化模式中，连线则表示任务的转交与流转。
采用任何编排模式时，在设计方面都要遵循这些通用原则。其一，要保持模块具有灵活性且可组合；其二，任务的定义需清晰明了；其三，提示词的结构要明确。
管理者模式
管理者模式的核心在于有一个处于中心位置的 LLM（也就是“管理者”），它通过对工具的调用，来协调一组专业化的 Agent 一起去完成任务。
它不会丢失上下文和控制权，能在合适的时间把任务智能地分派给合适的 Agent，还能将各部分结果自然整合为一次流畅的交互。
这种模式带来的好处如下：用户的体验是统一且顺畅的；每个专业能力都能够根据需求随时被调用。
管理者模式适合这样的场景：你期望有一个 Agent 来负责掌控整个流程的执行，同时它能够直接和用户进行交互。
例如，你可以通过 Agents SDK 如此实现：
有些框架是以声明式的方式来运作的。它要求开发者在起始阶段就清晰地界定出流程里的每一个分支、循环以及条件判断。通常是通过由节点（Agent）和边（这些边代表着确定性或者动态的任务交接）所构成的图来对整个流程进行描述。
这种方式的可视化效果较好。然而，当流程变得更动态且更复杂时，维护成本会迅速提升。开发者或许还需要额外去学习一些专用领域语言（DSL），其使用门槛是比较高的。
相比之下，Agents SDK 所采用的方式更为灵活，是代码优先的方式。开发者能够直接借助熟悉的编程结构去表达流程逻辑，不必预先去定义完整的图结构，这样就能实现更为动态且可扩展的 Agent 编排能力。
去中心化模式
在去中心化模式下，Agent 之间呈现“平等协作”的关系。它们能够将手中的任务交接给其他 Agent 以继续完成。这种“交接”类似于传接力棒，即一个 Agent 跑到某个阶段后，可把流程与对话状态一并“交给”另一个 Agent，然后继续向前跑。在 Agents SDK 里，handoff 是一种能实现交接机制的特殊事物，它可以是工具，也可以是函数。
这种模式具有以下特点：所有的 Agent 地位是相等的，不存在谁是总指挥的情况。每个 Agent 都能够依据自身的专长，直接把任务交给另一个更为合适的 Agent 去处理，并且不需要在中间设置一个进行统一协调的“管理者”。
它适合那些场景，这些场景不需要中央控制，且任务分布明确，每个 Agent 各自负责一摊事情。
如果你使用 Agents SDK 去实现一个客服流程，并且需要处理销售和售后支持这两个方向的需求，那么你就能够用去中心化模式来搭建这个系统。
在上述例子里，用户发来的消息首先会进入一个任务分发 Agent，也就是 triage_agent。接着，它会依据用户的内容来确定要把任务交给哪个人。
如果发现用户正在咨询订单方面的问题，那么它就会将对话转交给专门负责订单处理的 order_management_agent，接着由该 agent 继续接手并处理后续的流程。
这种做法尤其适合这样的场景，即希望先对用户需求进行判断，然后将其精准分流到合适的 Agent。你也能够让处理订单的 Agent，在完成处理后把对话交还给任务分发 Agent 继续跟进，例如进行结束语的处理以及满意度的收集等。
防护
在构建基于大模型的系统时，护栏机制就如同 AI 的“安全防护栏”。它能够帮助我们避免隐私泄露，例如提示词被暴露等情况；也能防止出现不当言论，像说出与品牌不符的内容等风险。单个护栏或许无法抵挡所有问题，然而，多个不同类型的护栏协同使用，就可以构建出更为稳健的防线。常见做法有以下几种：一是结合大模型自身的限制机制；二是进行基于规则的检查，例如使用正则表达式；三是加上像 OpenAI Moderation API 这样的内容审核工具。
护栏不能单独发挥作用，它最好与身份认证等传统技术搭配使用，也最好与权限控制等传统技术搭配使用，还最好与标准安全策略等传统技术搭配使用，从而形成一套“多层防御网”。
防护的类型
构建护栏
首先，针对您用例中已知的风险点设置防护措施。接着，当在实践中遇到新的边缘案例或者系统出现失效情况时，便逐步增添额外的防护层。我们发现以下这些实践经验是很有效的：
1. 首要关注数据隐私和内容安全。
根据实际运行中碰到的边缘案例以及出现的失败情况，持续增添新的护栏。
在保障安全的同时，需要兼顾用户体验，并且要随着 Agent 的迭代而对护栏策略进行优化。
以下代码展示了怎样在 Agents SDK 里设置护栏。
Guardrails 被 Agents SDK 视为核心功能。默认情况下，由 Agent 主动生成响应。同时，有多条护栏机制在后台并行运行。一旦发现有违规情况，就会立刻触发异常。这些护栏可以是函数，也可以是专门的 Agent，它们用于阻止越狱、过滤敏感词、识别不相关内容、执行黑名单或进行风险分类等。如果用户输入一道数学题，系统会首先进行“乐观执行”。然而，倘若触发了 math_homework_tripwire 这种护栏，系统就会立刻进行拦截。
人工介入机制
除了有系统自动进行拦截这一情况外，还需为人工介入预留相应机制。当 Agent 无法对某件事进行判断或者无法完成某项任务时，能够迅速将控制权转交给人工。这样做一方面可以保障相关体验，另一方面也能够防止错误进一步扩大。尤其在系统刚刚上线的初期阶段，更加需要人工介入来对问题进行识别、积累相关案例以及持续进行优化。
常见的人工介入触发点有两种：
失败次数较多，例如连续数次都无法领会用户的意图，这种情况下就应当转交人工进行处理。
风险较高。像取消订单以及批准大额退款这类敏感操作，建议必须要有专人进行把关。
结论
Agent 代表了工作流自动化的一个新的时代。它能够在信息不明确时进行判断，还可以跨系统调用工具，并且能以高度自主的方式完成多步骤的任务。
与那些功能较为简单的大模型应用相比，Agent 具备能够从头到尾执行整个流程的能力，这种能力非常适合以下场景：需要进行复杂决策的场景、处理非结构化数据的场景，以及依赖传统规则系统的场景。
打造一个稳定可靠的 Agent，首先要打好基础。使用能力强的大模型，搭配定义清晰的工具，并且写出结构明确、指令清楚的任务描述。依据业务的复杂程度来选择合适的编排模式，一开始可以仅使用一个 Agent，在需要的时候再将其扩展为多 Agent 协同的系统。
在各个阶段，护栏机制都起着关键作用。它能对输入内容进行检查，能调用工具，在后期需要人工接手时，也能帮助系统更安全、更稳定地上线运行。
成功部署 Agent 系统无需一蹴而就。你可以先从一些小流程着手，让真实用户先使用来验证效果，接着再逐步扩大 Agent 的能力和范围。只要基础扎实且方法正确，再持续进行优化，Agent 最终不但能自动完成任务，还能灵活地使整个工作流实现自动化，为业务切实带来价值。
如果你正在考虑在公司引入 Agent，那么可以随时联系特工宇宙 AgentUniverse。如果你准备开始第一次上线试用，同样可以随时联系特工宇宙 AgentUniverse。
我们的团队能够提供专业的经验，能够给予指导建议，还能够提供实操支持，以此帮助你顺利地推进相关事宜，让你真正能够落地并取得成功。
