OpenAI《A Practical Guide to Building Agents》详细总结#

原文：https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

PDF：https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

一句话概括#

OpenAI 这篇文章是一份面向产品和工程团队的 Agent 落地指南。它重点不是讨论 Agent 的概念有多新，而是回答三个实践问题：

什么样的任务值得做成 Agent？
一个 Agent 系统应该由哪些基础组件组成？
如何通过编排、多 Agent 和护栏，把 Agent 安全地部署到真实业务里？

如果说 Anthropic 的《Building effective agents》更强调“不要过度设计，先从简单 workflow 开始”，那 OpenAI 这篇更像一份企业落地手册：从选场景、搭结构、选模型、设计工具、写指令、做编排，到最后加 guardrails。

文章讲了什么#

OpenAI 对 Agent 的定义很直接：

Agent 是能够代表用户独立完成任务的系统。

它和普通 LLM 应用的区别在于，Agent 不只是回答问题，而是可以控制一个 workflow 的执行过程。比如：

判断下一步要做什么；
选择要调用哪个工具；
查询外部系统或数据库；
执行动作，比如更新记录、发送消息、发起退款；
根据结果继续下一步；
判断任务是否完成；
失败时停止并交还给人类。

所以，简单聊天机器人、单轮文本生成、情感分类器，都不算严格意义上的 Agent。Agent 的关键是：模型参与了流程执行和决策。

什么时候应该构建 Agent#

文章没有鼓励所有业务都做 Agent，而是给了三个适合 Agent 的场景。

1. 复杂决策#

当任务需要上下文判断、例外处理、灰度决策时，Agent 会比传统规则系统更适合。

例子：

判断用户退款请求是否应该批准；
分析一笔交易是否可能存在欺诈；
处理需要结合用户历史、政策条款、当前上下文的客服问题。

传统规则系统像 checklist，只能按照预设条件判断；Agent 更像一个有经验的工作人员，可以结合上下文处理模糊情况。

2. 规则系统已经难以维护#

有些业务一开始可以用规则自动化，但规则越来越多之后，会变得难改、难测、容易互相冲突。

例子：

供应商安全审查；
企业内部合规流程；
多条件审批流程；
大量 if-then-else 堆出来的客服或运营规则。

如果团队每次改规则都很痛苦，Agent 可能有价值。

3. 高度依赖非结构化数据#

Agent 适合处理自然语言、文档、邮件、对话、PDF、网页等非结构化输入。

例子：

处理保险理赔材料；
从文档里抽取关键信息；
读用户邮件并决定下一步；
和用户持续对话，补齐缺失信息。

这类任务很难完全用传统代码写死，因为输入格式和表达方式变化太大。

不适合 Agent 的情况#

如果一个任务满足以下特征，可能不需要 Agent：

流程固定；
输入输出结构稳定；
规则清楚；
不需要多轮决策；
不需要调用多个工具；
出错成本很高但没有可靠护栏；
用传统程序或简单 LLM 调用就能稳定解决。

文章的隐含态度是：Agent 应该解决传统自动化不擅长的问题，而不是替代所有自动化。

Agent 的三个基础组件#

OpenAI 把 Agent 的基础拆成三件事：

1
Agent = Model + Tools + Instructions

1. Model：模型#

模型负责推理、判断和决策。

文章建议：

原型阶段先用最强模型建立质量基线；
不要一开始就为了省钱选小模型；
等系统跑通、有 eval 之后，再逐步替换成更小、更快、更便宜的模型；
不同步骤可以使用不同模型。

它的模型选择逻辑是：

1
先保证准确率 -> 再优化成本和延迟

也就是说，先证明 Agent 能把事做好，再考虑怎么把它做便宜。

2. Tools：工具#

工具让 Agent 不只是“说”，还可以“做”。

文章把工具分成三类：

工具类型	作用	例子
Data tools	获取上下文和信息	查 CRM、查数据库、读 PDF、搜索网页
Action tools	对外部系统执行动作	发邮件、更新记录、发起退款、转人工
Orchestration tools	把其他 Agent 当工具使用	研究 Agent、写作 Agent、退款 Agent

工具设计非常关键。好的工具应该：

定义标准化；
描述清楚；
参数明确；
可复用；
可测试；
便于版本管理；
避免多个工具功能重叠导致模型选错。

文章还提到，对于没有 API 的旧系统，可以让 Agent 通过 computer use 模型像人一样操作网页或应用界面。但这种方式更需要安全边界和审计。

3. Instructions：指令#

指令决定 Agent 的行为边界和执行方式。

文章强调，高质量 instructions 对 Agent 尤其重要，因为 Agent 会多轮行动、调用工具、处理分支，一旦指令模糊，错误会被放大。

好的指令应该：

使用现有业务文档、SOP、客服脚本、政策文档作为来源；
把复杂文档改写成模型容易执行的步骤；
每一步都对应明确动作或输出；
明确什么时候问用户、什么时候查系统、什么时候调用 API；
覆盖常见边界情况；
对缺失信息、异常输入、用户跑题等情况有处理方式。

文章还建议可以用更强的模型，把现有帮助中心文档或政策文档转换成 Agent 指令。

编排方式：单 Agent 还是多 Agent#

OpenAI 把 Agent 编排分成两类：

单 Agent 系统；
多 Agent 系统。

它的总体建议很清楚：

先尽量把单 Agent 做好，只有当单 Agent 扛不住复杂度时，再拆成多 Agent。

单 Agent 系统#

单 Agent 是最推荐的起点。

一个 Agent 配上合适的工具和清晰指令，就可以处理很多任务。随着能力需求增加，可以逐步给它加工具，而不是一开始就设计复杂的多 Agent 架构。

单 Agent 的核心运行方式是一个循环：

1
接收输入 -> 模型判断 -> 调用工具或直接回答 -> 观察结果 -> 继续下一步 -> 直到满足退出条件

常见退出条件包括：

模型给出最终答案；
调用了最终输出工具；
发生错误；
达到最大轮数；
命中人工介入条件。

文章特别强调：Agent 的核心不是一次模型调用，而是一个可以持续执行直到任务结束的 run loop。

用 prompt template 管理复杂度#

在还没有必要拆多 Agent 之前，可以先用 prompt template 管理复杂度。

比如客服 Agent 不需要为每个用户写一份 prompt，而是用一个基础模板，再填入变量：

用户姓名；
用户年限；
常见投诉类型；
当前政策；
业务场景。

这样可以降低维护成本，也方便评估。

什么时候拆成多 Agent#

文章给了两个判断标准。

1. 逻辑太复杂#

如果一个 Agent 的 prompt 里充满大量条件分支，比如很多 if-then-else，说明它可能已经太复杂了。

这时可以把不同逻辑段拆给不同 Agent。

2. 工具过载#

不是工具数量多就一定要拆，而是工具之间相似、重叠、容易混淆时，模型更容易选错。

文章提到，有些系统可以管理超过 15 个定义清晰、差异明显的工具；但有些系统即使不到 10 个工具，只要工具功能重叠，也会出问题。

所以判断重点不是“有几个工具”，而是：

工具是否清楚；
功能是否重叠；
参数是否容易混；
模型是否经常选错工具；
改善工具命名和描述后是否仍然失败。

如果工具设计已经优化过，Agent 还是经常选错，就可以考虑拆多 Agent。

多 Agent 的两种模式#

OpenAI 总结了两种常见多 Agent 架构。

1. Manager Pattern：管理者模式#

一个中心 Agent 作为 manager，负责协调多个专业 Agent。

结构大概是：

1
用户 -> Manager Agent -> 专业 Agent A / B / C -> Manager 汇总 -> 用户

适合：

希望只有一个 Agent 面向用户；
希望中心 Agent 保持流程控制权；
需要把多个专业能力整合成统一体验。

例子：

用户要求把一句话翻译成西班牙语、法语、意大利语。Manager Agent 可以分别调用三个翻译 Agent，再把结果汇总给用户。

这个模式的好处是用户体验统一，控制权集中；缺点是 manager 的设计质量很重要。

2. Decentralized Pattern：去中心化交接模式#

多个 Agent 是平级的，一个 Agent 可以把任务 handoff 给另一个 Agent。被交接的 Agent 接管后，可以继续和用户交互。

结构大概是：

1
用户 -> Triage Agent -> 订单 Agent / 销售 Agent / 技术支持 Agent

适合：

对话分流；
客服场景；
某个专业 Agent 接手后不需要原 Agent 继续参与；
不需要一个中心 Agent 始终掌控全局。

例子：

用户问“我的订单什么时候送达？”Triage Agent 判断这是订单问题，于是把对话交给 Order Management Agent。

这个模式的好处是职责清晰、专业 Agent 可以完整接管；缺点是要设计好交接规则，避免来回踢皮球。

关于图式编排和代码式编排#

文章还提到，有些框架要求开发者提前定义完整图结构：节点、边、分支、循环、条件。

这种方式可视化清楚，但当流程越来越动态时，维护会变复杂。

OpenAI 倾向强调代码优先的灵活编排：开发者可以用熟悉的程序结构表达逻辑，不一定要提前把所有图结构写死。

这个观点和整篇文章一致：Agent 系统需要灵活，但不能失控。

Guardrails：护栏#

OpenAI 这篇文章很重视护栏，因为 Agent 不只是输出文本，还可能调用工具、写入系统、执行真实动作。

护栏的作用是降低：

数据隐私风险；
提示词泄露风险；
越权操作风险；
品牌声誉风险；
安全与合规风险；
高风险工具误用风险。

文章强调：护栏不是单一机制，而是多层防御。

常见护栏类型#

类型	作用
Relevance classifier	判断用户请求是否在 Agent 范围内
Safety classifier	检测 jailbreak、prompt injection 等攻击
PII filter	防止输出不必要的个人敏感信息
Moderation	过滤仇恨、骚扰、暴力等不安全内容
Tool safeguards	按工具风险等级控制调用权限
Rules-based protections	用黑名单、长度限制、正则等处理已知风险
Output validation	检查输出是否符合品牌、安全和格式要求

工具风险分级#

文章特别值得注意的一点是：工具应该按风险分级。

可以考虑这些因素：

只读还是写入；
是否可逆；
是否需要账户权限；
是否涉及财务影响；
是否会影响真实用户；
是否可能造成不可恢复后果。

比如：

查询订单：低风险；
更新 CRM 字段：中风险；
发起大额退款：高风险；
付款、取消订单、删除数据：高风险。

高风险工具不应该随便让 Agent 自动执行，应该触发额外检查或人工审批。

人工介入#

文章明确说，人类介入是关键安全机制，尤其是在早期部署阶段。

两类情况特别需要人工介入：

超过失败阈值
比如 Agent 多次无法理解用户意图、连续调用工具失败、反复给出不确定答案。
高风险动作
比如取消订单、批准大额退款、执行付款、修改敏感数据。

这点非常现实：Agent 不是必须全自动。生产环境里，很多时候最好的形态是“自动处理大部分低风险任务，把不确定和高风险任务交给人”。

文章的落地路线#

可以把 OpenAI 的实践路径整理成这样：

1
选择合适场景
2
-> 用强模型做原型
3
-> 定义工具
4
-> 编写清晰 instructions
5
-> 先做单 Agent
6
-> 建立 eval
7
-> 优化模型成本和延迟
8
-> 必要时拆多 Agent
9
-> 增加多层 guardrails
10
-> 小范围上线并持续迭代

这条路线的关键是：不要从架构开始，而是从业务问题和评估开始。

这篇文章的重点#

重点一：Agent 是 workflow 的执行者#

Agent 不只是聊天界面，而是可以推动业务流程向前走的系统。

它的核心能力是：

判断；
调用工具；
执行动作；
根据反馈继续；
完成整个流程。

重点二：Agent 的价值在模糊和复杂场景#

如果任务很规则、很稳定、很确定，用传统自动化就可以。Agent 的价值主要在：

模糊判断；
复杂上下文；
非结构化数据；
规则系统难维护；
需要多轮工具调用。

重点三：先单 Agent，再多 Agent#

多 Agent 听起来高级，但会增加复杂度。

OpenAI 的建议是先最大化单 Agent 能力，只有当指令太复杂、工具太混乱、模型经常选错工具时，再拆分。

重点四：工具和指令是 Agent 的产品设计#

工具不是技术细节，而是 Agent 能力边界。

指令也不是随便写一段 prompt，而是把业务 SOP 转换成模型可执行流程。

重点五：护栏是生产 Agent 的必需品#

Agent 越能“行动”，越需要控制。

尤其是涉及写入、付款、退款、删除、修改用户数据时，必须有风险分级、审批机制和人工介入。

需要注意什么#

不要把所有 LLM 应用都叫 Agent。
不要为了追热点而把简单任务复杂化。
不要跳过 eval，直接谈成本优化。
不要一开始就用小模型做原型，容易误判系统上限。
不要让工具命名、参数和描述含糊不清。
不要给单个 Agent 塞太多相似工具。
不要让 prompt 变成无法维护的超长规则堆。
不要一开始就设计复杂多 Agent 架构。
不要让高风险工具自动执行。
不要把 guardrails 当成一次性配置，要随着真实失败案例持续补充。
不要认为人工介入是失败，它其实是生产系统可靠性的一部分。

知识博主角度#

这篇文章可以这样讲：

OpenAI 给 Agent 下了一个很务实的定义：Agent 不是会聊天的模型，而是能代表用户跑完整业务流程的系统。

然后展开三个问题：

什么任务值得做 Agent？
复杂决策、规则难维护、非结构化数据多。
Agent 怎么搭？
三件套：模型、工具、指令。
怎么从 demo 走向生产？
先单 Agent，必要时多 Agent，再加多层 guardrails 和人工介入。

最后可以用一句话收尾：

Agent 的真正难点不是让模型调用工具，而是让它在真实业务里可控、可评估、可交接、可追责。

和 Anthropic 那篇的区别#

两篇文章都反对盲目复杂化，但侧重点不同。

文章	重点
Anthropic《Building effective agents》	强调先简单后复杂，介绍多种 agentic workflow 模式
OpenAI《A Practical Guide to Building Agents》	强调企业落地，从选场景、三件套、编排到护栏

Anthropic 那篇作为“Agent 架构思想”，把 OpenAI 这篇作为“Agent 落地手册”。

音乐

音乐

OpenAI《A Practical Guide to Building Agents》解读：从场景选择到安全落地