跳转至

OpenAI 智能体设计模式

概述

OpenAI 发布的智能体构建实践指南，从大量客户部署经验中提炼出可落地的设计模式，面向产品与工程团队。指南涵盖如何识别有价值的智能体应用场景、设计智能体逻辑与编排方案，以及在生产环境中安全运行智能体。无论使用 OpenAI Agents SDK 还是基于任意库从头构建，这些模式均适用。

OpenAI 智能体设计模式 OpenAI 智能体设计模式全景概览

何时构建智能体

智能体适合用于传统确定性方案力不从心的工作流。在投入开发前，请对照以下三项标准进行验证：

判断标准 说明 示例
复杂决策 工作流需要细致的判断、处理例外情况或依据上下文做出决策 客服退款审批
规则难以维护 系统规则集庞杂，更新成本高且易出错 供应商安全审查
大量依赖非结构化数据 场景涉及自然语言理解、文档信息提取或对话交互 处理家庭保险理赔

将 LLM 集成到应用中但不用其控制工作流执行的系统——如简单聊天机器人、单轮 LLM 调用、情感分类器——不属于智能体。若确定性方案足以解决问题，优先使用确定性方案。

核心智能体结构

三要素基础

每个智能体都由三个基本构建块组成：

  • 模型：驱动推理与决策的 LLM
  • 工具：智能体用于执行操作的外部函数或 API
  • 指令：明确定义智能体行为方式的指导原则与护栏

单一编排循环

所有编排方案都需要一个"运行"过程——通常是一个循环，让智能体持续运行直至满足退出条件： - 调用了最终输出工具（指定输出类型） - 模型返回响应但未调用任何工具 - 进入错误状态 - 达到最大轮次限制

模型选型

步骤 原则
1. 建立基线 原型阶段为每项任务选用能力最强的模型
2. 达到精度目标 在优化前先满足精度要求
3. 优化成本与延迟 在能力不降的前提下换用更小的模型；简单检索或意图分类任务可使用快速、低成本的模型；复杂判断类任务（如退款审批）则受益于能力更强的模型

工具定义

工具通过 API 扩展智能体能力；对于没有 API 的遗留系统，可使用 computer-use 模型通过 Web 与应用界面进行交互。每个工具应具备标准化定义，从而支持工具与智能体之间灵活的多对多关系。

工具类型 用途 示例
数据类 检索执行工作流所需的上下文与信息 查询交易数据库、读取 PDF 文档、搜索网络
操作类 与系统交互以执行操作——添加记录、更新状态、发送消息 发送邮件、更新 CRM 记录、移交客户工单
编排类 将智能体本身作为其他智能体的工具 退款智能体、调研智能体、写作智能体

指令配置

实践方法 说明
利用现有文档 将 SOP、支持脚本和政策文件转化为 LLM 友好的执行流程
拆分任务 将复杂资源拆解为更小、更清晰的步骤，减少歧义
明确定义操作 将每个流程步骤映射到具体操作或输出，对面向用户的消息措辞要明确规定
覆盖边缘情况 通过条件步骤或分支预判常见变体（例如：所需信息缺失时如何处理）

高级模型（o1、o3-mini）可自动从现有政策文件中生成指令。

编排模式

编排模式分为两大类。优先采用单智能体模式，仅在确有必要时才演进为多智能体。

单智能体模式

一个配备工具的智能体在循环中处理工作流。该模式更简单、更易于评测。在无需引入多个智能体的情况下管理复杂度，可使用提示词模板——通过一个带有策略变量的灵活基础提示词适配不同上下文，而非维护大量独立的提示词。

何时拆分为多智能体

信号 说明
逻辑过于复杂 提示词包含大量条件分支，难以扩展
工具超载 工具相似或重叠，优化工具描述也无法解决选择错误（注：15 个以上定义明确的独立工具，其表现可优于不足 10 个有重叠的工具）

多智能体模式

管理者模式（智能体作为工具）

中心"管理者" LLM 通过工具调用编排各专业智能体。管理者负责分配任务、综合结果，并维护统一的用户界面。适用于只需一个智能体控制工作流执行并与用户交互的场景。

User → Manager Agent → [Spanish Agent, French Agent, Italian Agent]

每个专业智能体通过 agent.as_tool(tool_name=..., tool_description=...) 暴露为工具。管理者根据请求决定调用哪些工具。

最适合：翻译流水线、调研工作流，以及任何需要跨领域综合结果的场景。

去中心化模式（智能体交接）

各智能体作为对等节点运行，通过单向交接转移控制权。当智能体调用交接函数时，执行权连同当前会话状态立即转移给目标智能体。无需中心控制器，每个智能体完全接管其负责的领域。

User → Triage Agent → [Technical Support Agent | Sales Agent | Order Management Agent]

最适合：客服分诊、领域专属流程（接收方智能体需完全掌控交互过程）。

声明式与代码优先图的对比

部分框架（如 LangGraph）要求开发者将所有分支和循环预先定义为显式图。OpenAI Agents SDK 采用代码优先方式——工作流逻辑以熟悉的编程结构表达，无需预先定义完整的图，从而实现更动态的编排。

护栏模式

护栏是分层防御机制——单一护栏无法提供充分保护，需要将多个专用护栏叠加使用。

护栏类型

类型 用途 示例
相关性分类器 标记偏题查询 向客服智能体提问"帝国大厦有多高？"
安全分类器 检测越狱行为与提示词注入企图 旨在提取系统指令的请求
PII 过滤器 防止个人身份信息不必要地暴露 在记录日志或返回用户前清除模型输出中的 PII
内容审核 标记有害或不当输入（仇恨言论、骚扰、暴力） OpenAI Moderation API
工具安全防护 根据可逆性、访问级别和财务影响对每个工具进行风险评级（低/中/高），在高风险调用前触发暂停或人在回路（HITL） 执行大额退款前暂停确认
基于规则的防护 简单的确定性措施 黑名单、输入长度限制、针对 SQL 注入或禁用词的正则过滤
输出验证 确保响应符合品牌价值观 提示词工程 + 交付前内容检查

实施方式

Agents SDK 将护栏作为一等概念，采用乐观执行策略：主智能体主动生成输出，同时护栏并发运行。若护栏触发（例如流失检测绊线检测到取消风险），异常将中断流程并触发相应的响应路径。

按以下顺序构建护栏： 1. 优先关注数据隐私与内容安全 2. 根据实际暴露的边缘情况和故障，逐步添加护栏 3. 随着智能体逐渐成熟，兼顾安全性与用户体验进行优化

人在回路（HITL）模式

在部署初期，人工介入对于发现故障、挖掘边缘情况、建立评测循环至关重要。

触发条件

触发条件 说明
超出失败阈值 智能体超过重试次数仍未完成任务（如多次尝试后仍无法理解意图）→ 升级至人工
高风险操作 敏感、不可逆或高风险操作（取消订单、授权大额退款、发起付款）→ 在置信度提升前需人工确认

升级设计

  • 客服场景：升级至人工客服
  • 编码智能体：将控制权转还给用户
  • 交接过程中始终保留会话历史与状态

实施最佳实践

领域 建议
从简单开始 优先使用带工具的单智能体；仅在性能不达标时才增加复杂度
评测先行 在优化前先建立评测体系——需要基线才能判断调整是否有效
增量部署 小规模起步，用真实用户验证，随时间逐步扩展能力
工具设计 文档完善、经过充分测试、可复用的工具定义，能提升可发现性并避免重复定义
提示词模板 使用带变量的单一灵活基础提示词，而非为不同场景维护大量独立提示词

参见

参考资料