OpenAI 实操指南：怎么构建 Agent

OpenAI 把大量客户落地经验提炼成了这份「构建 agent 的实操指南」，面向第一次做 agent 的产品和工程团队。它从「什么算 agent、什么时候才该做 agent」讲起，一路到设计基础、编排模式和护栏。

下面按原文结构做完整精译导读，关键论点配原句直引，建议结合上方链接读英文全文。

传统软件帮用户把工作流变顺、变自动；而 agent 能高度自主地「替用户」去跑这些工作流。OpenAI 给的定义很简洁：agent 是能独立替你完成任务的系统。

只是集成了 LLM、但没用它来控制工作流执行的应用（简单聊天机器人、单轮 LLM、情感分类器）不算 agent。一个真正的 agent 有两个核心特征：它用 LLM 来管理工作流的执行和决策，能识别任务何时完成、能在出错时自我纠正、失败时还能停下来把控制权交还给用户；它能调用各种工具与外部系统交互（既取上下文也采取行动），并根据当前状态动态选工具，始终在清晰定义的护栏内运作。

agent 特别适合那些传统「确定性、规则驱动」方法力不从心的工作流。文章用支付欺诈分析打比方：传统规则引擎像一张清单，按预设条件命中就标记；而 LLM agent 更像一个老练的调查员，会评估上下文、捕捉微妙模式，即便没有踩中明确规则也能识别出可疑活动。

评估价值时，优先挑那些以往一直抵触自动化、传统方法总是卡壳的工作流：一是需要细腻判断、有例外、依赖上下文的复杂决策（比如客服里的退款审批）；二是规则集庞杂、难以维护、改一处就容易出错的系统（比如供应商安全审查）；三是高度依赖非结构化数据、需要理解自然语言或从文档里抽取含义的场景（比如处理家财险理赔）。在动手前先确认你的用例确实满足这些标准，否则一个确定性的方案可能就够了。

最基本的 agent 由三件套构成：模型（驱动推理和决策的 LLM）、工具（它能用来采取行动的外部函数或 API）、指令（定义它如何行为的明确准则和护栏）。

选模型的原则很朴素：先用最强的模型给每个任务搭原型、立一个性能基线，再尝试换成更小更快的模型看是否还能达标，这样既不会过早限制能力，又能看清小模型在哪行、在哪不行。归纳起来三步：建 eval 立基线；用最好的模型先达到准确率目标；再在可行处用小模型替换大模型，优化成本和延迟。

工具上，每个工具都应有标准化定义，从而支持工具与 agent 之间灵活的多对多关系；文档完善、充分测试、可复用的工具能提升可发现性、简化版本管理。agent 大体需要三类工具：数据类（取上下文，如查数据库、读 PDF、搜网页）、行动类（采取动作，如发邮件、更新 CRM、把工单转人工）、编排类（agent 本身也能作为别的 agent 的工具）。指令则是重中之重：复用已有的操作规程 / 政策文档来生成对 LLM 友好的「routine」、提示 agent 把任务拆成更小更清晰的步骤、让每一步都对应一个具体动作或输出、并显式覆盖边界情况（信息不全或被问到意料之外的问题时怎么走）。

别一上来就奔着「全自主、复杂架构」去；客户的经验是渐进式更容易成功。编排大体分两类：单 agent 系统（一个模型配上合适的工具和指令，在循环里执行工作流）和多 agent 系统（把执行分散到多个协同的 agent）。

单 agent 能靠「逐步加工具」处理很多任务，把复杂度控制住、也方便评估和维护。每种编排都需要「run」的概念，通常实现成一个循环，让 agent 一直跑到触发退出条件（工具调用、某种结构化输出、出错、或达到最大轮数）。一个不用切多 agent 就能管住复杂度的好办法是用提示模板：与其为每个用例维护一堆独立 prompt，不如用一个能接受策略变量的灵活基础模板，新用例来了改变量就行。

什么时候才该拆多 agent？总的建议是先把单 agent 的能力用到头。当 agent 老是跟不上复杂指令、或总选错工具时，再进一步切分。两条实操判据：逻辑过于复杂（prompt 里塞满 if-then-else 分支、模板难以扩展，就按逻辑段切给不同 agent）；工具过载（问题不在工具数量而在相似 / 重叠程度，有的实现能管 15 个以上界限清晰的工具，有的不到 10 个重叠工具就乱套，先靠清晰命名和描述提升工具辨识度，没用再拆）。

多 agent 系统可建模成图（agent 是节点）。经验上有两大通用类别。管理者模式（agents as tools）：一个中心「管理者」agent 通过工具调用来编排一群专才 agent，自己不丢失上下文和控制权，把各专才的结果合成统一的交互。它适合「只想让一个 agent 掌控执行、且独占与用户的接触」的工作流，比如让一个翻译管理者按需调用西、法、意各语种的子 agent。在这种模式里，图的边代表工具调用。

去中心化模式（agents handing off）：多个 agent 平等协作，一个可以直接把工作流的执行「移交」(handoff) 给另一个，移交是单向转移、并把最新会话状态一并带过去。它适合不需要中心控制或汇总、各 agent 各自接管并按需与用户交互的场景，比如一个分诊 agent 把「订单相关」的请求直接交给订单管理 agent。在这种模式里，图的边代表 handoff。两种模式遵循同样的原则：保持组件灵活、可组合，由清晰、结构良好的提示驱动。

护栏帮你管住数据隐私风险（如防系统提示泄露）和声誉风险（如确保品牌一致的行为），但它要和稳健的认证授权、严格的访问控制、常规软件安全措施配合。把护栏当成分层防御：单独一道往往不够，多道专门护栏叠在一起才更有韧性，比如把 LLM 护栏、基于规则的护栏（正则等）和审核 API 组合起来一起审用户输入。

常见的护栏类型：相关性分类器（拦下跑题输入）、安全分类器（识别越狱 / 提示注入）、PII 过滤器（防个人身份信息泄露）、内容审核（拦有害不当内容）、工具安全分级（按只读/写、可逆性、权限、财务影响给每个工具评低 / 中 / 高风险，高风险动作触发额外检查或升级人工）、基于规则的防护（黑名单、长度限制、正则防 SQL 注入）、输出校验。构建上有个好用的启发式：先抓数据隐私和内容安全，再根据真实世界遇到的边界和失败逐步加，并在安全和体验之间不断权衡。

最后别忘了规划人工介入：它是改进 agent 真实表现、又不牺牲体验的关键安全阀，在部署早期尤其重要，能帮你发现失败、暴露边界、建立稳健的评估循环。两类典型触发：超过失败阈值（设好重试 / 动作上限，多次仍搞不懂用户意图就升级人工）和高风险动作（敏感、不可逆、高风险的操作，如取消订单、批大额退款、发起支付，在对可靠性建立信心前都该触发人工监督）。

agent 标志着工作流自动化的新阶段：系统能在模糊中推理、跨工具采取行动、以高度自主完成多步任务，因此特别适合那些涉及复杂决策、非结构化数据、或脆弱规则系统的用例。

要造出可靠的 agent，从扎实的基础开始：把有能力的模型，配上定义良好的工具和清晰、结构化的指令；用与复杂度匹配的编排模式，从单 agent 起步，必要时再演进到多 agent；护栏在每个阶段都关键。成功部署不是「全有或全无」：从小处起步，用真实用户验证，再随时间扩展能力。

作者 · OpenAI

原文 · openai.com

本页为 GoodVibe 对原文的中文整理，著作权归原作者所有；建议点击上方链接阅读原文全文。