大语言模型（LLM）的能力正经历快速迭代，尤其在推理能力、多模态理解以及工具调用等关键领域，其发展迅猛。这一趋势催生了一类全新的、由LLM驱动的系统——即Agent，开始进入业界视野。本指南源自OpenAI官方，专为希望从零起步构建首个Agent的产品与工程团队而设计。其中总结了大量实战中沉淀的宝贵经验，涵盖如何判断一个场景是否适合引入Agent、如何设计Agent的决策逻辑与执行流程，以及如何确保Agent在生产环境中安全、可预测且高效地运行。阅读本文后，你将系统掌握构建Agent所需的基础知识与实战技巧。
什么是Agent系统？
简而言之，Agent是一个能够独立地代表你完成任务的智能系统。与传统软件仅仅简化操作流程不同，Agent是直接“替你执行任务”。工作流（workflow）是实现用户目标所必须遵循的一系列步骤。那些虽然集成了LLM，但并未让LLM主导流程执行的应用——例如简单的聊天机器人、单次LLM调用，或情感分类器——均不属于Agent的范畴。
真正的Agent必须具备两大核心特征：
- 利用LLM来管理流程的执行与决策。它能够依据任务完成状态自主决策，必要时还会主动修正自身行为。若遇到无法解决的失败情况，它会适可而止，将控制权交还给用户。
- 能够访问多种工具，以与外部系统交互（例如获取信息或执行操作）。它能根据流程当前状态，动态选择最合适的工具，并始终在明确定义的“护栏”范围内运行。
何时适合构建一个Agent？
构建Agent，首先需要重新思考系统如何做决策、如何处理复杂问题。Agent特别适合那些传统、确定性、基于规则的自动化方法难以胜任的流程。在评估应用场景时，应优先考虑那些过去自动化尝试效果不佳，尤其是面临以下困难的工作流：
- 复杂的决策制定：需要细微判断、处理各种例外情况，或严重依赖上下文做决策的场景，例如客服流程中的退款审批。
- 难以维护的规则：系统因规则集过于庞大复杂而变得臃肿，更新成本高且易出错，比如执行供应商的安全审查。
- 严重依赖非结构化数据：需要理解自然语言、从文档中提取信息，或与用户进行对话式交互的场景，例如处理一份房屋保险索赔。
在决定动手构建之前，务必确认你的应用场景确实符合这些标准。否则，一个更简单的确定性解决方案可能就足够了。
Agent核心设计要素
一个Agent最基本的形态，包含三个核心组成部分：模型、工具和指令。
选择你的模型
不同模型在处理任务复杂性、延迟和成本方面各有千秋。在一个工作流中，完全可以针对不同任务的需求，组合使用不同的模型。并非所有任务都需要调用最强大的模型。
一个稳妥的做法是：先用能力最强的模型构建Agent原型，跑出一个性能基线。然后，再尝试换成更小、更快的模型，评估它们是否仍能达到可接受的效果。
选择模型的简单原则：
- 构建评估体系，以确定性能基线。
- 使用当前可用的最佳模型，达成你的准确度目标。
- 在可能的情况下，用较小的模型替换较大的模型，以优化成本与延迟。
定义工具
工具通过调用底层应用或系统的API，来扩展Agent的能力边界。对于没有API的老旧系统，Agent可以像人类一样，通过操作网页或应用界面进行交互。每个工具都应具备标准化的定义、清晰的文档、经过充分测试，并且是可重用的。
Agent通常需要三种类型的工具：
- 数据：让Agent能获取执行工作流所需的上下文与信息，例如查询数据库、读取PDF、搜索网页。
- 行动：让Agent能与系统交互并采取具体行动，例如发送邮件、更新CRM记录、将工单转给人工客服。
- 编排：Agent本身也可以作为其他Agent的工具，这会在后面“编排”部分的“管理者模式”中详细说明。
配置指令
高质量的指令对任何基于LLM的应用都至关重要，对Agent而言更是如此。清晰的指令能减少模糊性，改善Agent的决策能力，让工作流执行更顺畅，并减少错误。
配置指令的最佳实践：
- 利用现有文档：使用已有的操作流程、客服脚本或政策文件，创建适合LLM理解的指令。
- 提示Agent分解任务：将复杂冗长的内容拆分成更小、更清晰的步骤，帮助模型更好地理解和遵循。
- 定义清晰的行动：确保指令中的每一步都对应一个具体的动作或输出。明确说明动作，可减少误解的空间。
- 覆盖边缘情况：现实世界中的交互常有意外。指令要能预见常见变化，并包含处理这些情况的说明，例如用户提供信息不全时如何应对。可以使用像o1或o3-mini这样的高级模型，从现有文档自动生成指令。
编排模式
有了基础组件，就可以考虑采用编排模式，让Agent高效地执行工作流。通常，采用增量方法比一开始就构建复杂系统更容易成功。
编排模式主要分两类：单Agent系统和多Agent系统。
单Agent系统
通过不断给单个Agent增加工具，可以处理很多任务，同时保持复杂性可控，简化评估与维护。Agent的运行通常是一个循环，直到达到某个退出条件为止，例如调用了表示最终输出的工具、模型直接回复用户、发生错误或达到最大交互轮次。可以使用提示词模板加变量的方式来管理复杂性，而不是为每个场景维护单独的提示。
何时考虑创建多个Agent
通常建议先尽量发挥单个Agent的能力。但在以下情况，你可能需要将任务拆分给多个Agent：
- 复杂逻辑：当提示中包含大量条件分支，并且提示模板变得难以扩展时。
- 工具过载：问题不只在于工具数量，更在于它们的相似性或重叠。如果Agent难以区分和选择功能相似的工具，或者工具数量确实很多，可以考虑拆分。
多Agent系统
多Agent系统可以看作一个图，其中Agent是节点。有两种常见的模式：
- 管理者模式：有一个中心的管理者Agent，通过工具调用来协调多个专门的Agent。每个专门Agent处理特定的任务或领域。管理者Agent负责理解用户需求，将任务分配给合适的专业Agent，最后整合结果。这种模式适合只需要一个Agent来控制流程并与用户交互的场景。例如，一个翻译Agent作为管理者，根据用户需要调用西班牙语、法语等专门的翻译Agent工具。
- 去中心化模式：多个Agent作为对等体工作，它们之间可以相互“交接”工作流的控制权。交接是一种单向的转移，允许一个Agent把任务委托给另一个Agent。当一个Agent调用交接函数时，执行会立即转移到被交接的那个Agent上，并且会传递最新的对话状态。这种模式适合不需要单一Agent维持中心控制或合成结果的场景，比如客服分诊，或者让每个专业Agent完全接管特定任务。例如，一个分诊Agent接到用户关于订单的问题，直接将对话交接给订单管理Agent处理。
注意：Agents SDK采用的是更灵活的、代码优先的方式，开发者可以直接用熟悉的编程方式表达工作流逻辑，而不需要预先定义整个图。
护栏机制
设计良好的护栏有助于管理风险，比如数据隐私风险或声誉风险。护栏应被视为分层防御机制。单一护栏通常不够，多种专门护栏结合使用能构建更具韧性的Agent。可以结合基于LLM的护栏、基于规则的护栏和OpenAI Moderation API等。
常见的护栏类型：
- 相关性分类器：确保Agent的回应在预定范围内，标记离题的查询。
- 安全分类器：检测不安全的输入，如越狱或提示注入。
- PII过滤器：审查模型输出，防止不必要的个人身份信息泄露。
- 内容审核：标记有害或不当的输入，如仇恨言论、骚扰、暴力。
- 工具安全防护：评估Agent可用工具的风险级别，基于读/写权限、操作可逆性、所需账户权限、财务影响等因素。根据风险级别触发自动化措施，比如执行高风险功能前暂停进行护栏检查，或在需要时升级给人工处理。
- 基于规则的保护：使用简单的确定性措施来阻止已知威胁，如黑名单、输入长度限制、正则表达式过滤器。
- 输出验证：通过提示工程和内容检查，确保Agent的响应符合品牌价值，防止输出损害品牌形象。
构建护栏
从你为应用场景已经识别出的风险开始设置护栏。随着发现新的漏洞，逐步增加额外的护栏层。一个有效的策略是：
- 首先关注数据隐私和内容安全。
- 根据遇到的真实世界的边缘案例和失败情况，添加新的护栏。
- 随着Agent的发展，不断调整护栏，以优化安全性和用户体验。
规划人工干预
人工干预是一个关键的保障措施，使你能在不牺牲用户体验的情况下改进Agent的真实世界表现，在部署初期尤其重要。实现人工干预机制，可以让Agent在无法完成任务时，优雅地将控制权转移。
通常需要人工干预的两种主要触发条件：
- 超出失败阈值：为Agent的重试或操作次数设置限制。如果Agent超出这些限制，则应升级到人工干预。
- 高风险操作：对于敏感、不可逆或风险高的操作，应该触发人工监督，直到对Agent的可靠性有足够信心为止。例如取消用户订单、批准大额退款或进行支付。
结论
Agent系统能够理解模糊性、跨工具采取行动，并高度自主地处理多步骤任务。这使得它们非常适合处理涉及复杂决策、非结构化数据或脆弱的基于规则的系统。要构建可靠的Agent，需要从坚实的基础开始：将强大的模型与定义良好的工具和清晰、结构化的指令配对。使用与你的复杂性级别相匹配的编排模式，从单个Agent开始，仅在需要时才演进到多Agent系统。护栏在每个阶段都至关重要，从输入过滤和工具使用到人工干预，有助于确保Agent在生产环境中安全、可预测地运行。
成功部署并非一蹴而就。从小处着手，通过真实用户进行验证，并随着时间的推移逐步扩展能力。凭借正确的基础和迭代的方法，Agent可以提供真正的商业价值——不仅仅是自动化任务，而是以智能和适应性自动化整个工作流。