OpenAI：怎样把 AI Agent 真正做出来

前言

原文A practical guide to building agents。

怎样把 AI Agent 真正做出来

AI Agent 值得投入的地方，不是把聊天能力再包装一层，而是让系统真正代表人去完成一整段工作流。它能理解目标，决定下一步该做什么，调用外部工具获取信息或执行操作，在必要时修正自己的行为，并在超出能力边界时把控制权交还给人。

这也是它和普通 LLM 应用的根本区别。一个只能回答问题、做单轮生成、做情感分类的系统，还不算 Agent。只有当模型开始负责推进任务、判断流程是否完成，并在工具和规则约束下持续执行时，Agent 才真正成立。

要把 Agent 做对，核心不是先追求复杂架构，而是先把三件事打牢：选对模型、定义好工具、写清楚指令。在这个基础上，再决定是用单 Agent 还是多 Agent，最后用分层护栏把系统安全性和稳定性补起来。真正有效的路径通常也不是一步到位，而是从一个可评估、可收敛的小系统开始，再逐步扩展。

Agent 不是“会聊天”，而是“会推进任务”

理解 Agent，最重要的是先理解“工作流”这个概念。工作流不是一句回答，而是一串为了达成用户目标必须完成的步骤。它可能是处理一张退款申请，跟进一笔订单，生成一份报告，提交一段代码修改，或者完成一次餐厅预订。

Agent 的关键价值，在于它能独立推进这类多步骤流程，而不是每一步都等人来指挥。一个合格的 Agent 至少要具备两类能力。

第一类能力是用模型来管理流程。它要知道当前处于哪一步，什么时候该继续，什么时候任务已经完成，什么时候自己做错了需要纠正，什么时候应该停下来并把控制权交还给用户。

第二类能力是使用工具。Agent 不能只靠上下文“想”，它必须能连接外部系统，去拿数据、查资料、更新记录、发送消息，甚至直接操作没有 API 的旧系统界面。只有这样，它才能从“会分析”变成“能办事”。

换句话说，Agent 的本质不是更聪明的对话框，而是一个由模型驱动的执行系统。

不是所有自动化问题都适合上 Agent

Agent 很强，但并不意味着所有场景都该用它。判断要不要做 Agent，最直接的方法不是看技术新不新，而是看原来的自动化方法为什么卡住了。

最适合 Agent 的，通常是三类工作流。

第一类是复杂决策很多的场景。这里的问题不在于步骤多，而在于判断本身带有语境、例外和细微差异。比如客服退款审批，表面上像一个规则判断问题，实际上往往要综合用户历史、问题类型、上下文和特殊情况来决定。

第二类是规则系统已经变得难以维护。很多业务最初能靠规则引擎跑起来，但随着例外越来越多，规则会变得又长又脆，改一次就可能影响别处。像供应商安全审查这类流程，经常会进入这种状态。Agent 的价值就在于，它能把部分硬编码判断，替换成更灵活的语义理解和推理。

第三类是高度依赖非结构化数据。只要流程中有大量自然语言、文档、邮件、表单、聊天记录，或者需要和用户持续对话，传统自动化通常就会很吃力。比如保险理赔、文档审核、订单沟通，这些都天然适合用 Agent 去处理。

用一个很直观的对比来看，支付欺诈分析就是典型例子。传统规则引擎像一张检查清单，命中条件就报警；而 Agent 更像经验丰富的调查员，它会结合上下文、模式和细节，识别那些没有明显触发规则、但整体上可疑的情况。Agent 的优势，本质上就是处理这种模糊但重要的判断。

所以，一个简单判断标准是：如果确定性的规则系统已经足够解决问题，就不要为了“更智能”而引入 Agent。只有当复杂性、语义性和例外情况已经让传统方法明显失效时，Agent 才真正值得上场。

先把三块地基打牢，Agent 才能稳定工作

一个最基本的 Agent，由三部分组成：模型、工具和指令。

模型负责推理和决策。工具负责连接外部世界。指令负责告诉 Agent 应该怎么做，以及哪些边界不能越过。看起来简单，但大多数 Agent 项目的成败，几乎都卡在这三件事上。

模型的选择，先保效果，再谈成本

选模型时，最容易犯的错误是过早做成本优化。一个更稳妥的方法是，先用能力最强的模型把原型跑通，建立性能基线，再逐步替换成更小、更快、更便宜的模型，看哪些环节仍然能保持可接受效果。

这是因为并不是所有任务都需要最强模型。简单的检索、路由、意图分类，往往小模型就够了；但像退款审批、复杂判断、多步推理这类任务，通常更依赖高能力模型。只有先把基线建立起来，你才能知道哪些地方能降配，哪些地方一降就会出问题。

模型选择可以遵循一个很实际的顺序：先做评估，确认当前准确率；再优先满足效果目标；最后才是围绕成本和延迟做替换和优化。这个顺序看起来保守，但能避免把系统一开始就限制死。

工具定义得越清楚，Agent 越不容易“乱用能力”

工具是 Agent 和真实系统交互的手脚。一个设计得好的工具，不只是“能调用”，还要定义统一、文档完整、可复用、可测试。否则工具一多，系统很快就会失控。

从用途上看，工具大致分三类。

第一类是数据工具，用来取上下文和信息，比如查询交易数据库、读取 CRM、查看 PDF、搜索网页。没有这类工具，Agent 就只能靠对话上下文和模型记忆做判断，几乎不可能稳定完成真实任务。

第二类是动作工具，用来执行外部操作，比如发邮件、发短信、更新 CRM、创建工单、触发退款。这类工具直接影响业务状态，因此设计时必须特别清楚参数、权限和副作用。

第三类其实是“Agent 作为工具”。也就是说，一个专门的研究 Agent、退款 Agent、写作 Agent，本身也可以被另一个上层 Agent 调用。多 Agent 系统往往就是从这里长出来的。

当工具越来越多时，问题往往不只是数量，而是相似度。如果多个工具名字接近、参数重叠、边界模糊，模型就会频繁选错。很多时候，与其马上把系统拆成多个 Agent，不如先把工具命名、描述和入参定义整理清楚。只有在这些工作都做过以后，仍然持续出现工具选择错误，才说明系统可能真的需要拆分。

指令不是补充说明，而是 Agent 的运行规则

很多人低估了指令的重要性，觉得只要模型足够强，写一点自然语言说明就够了。但在 Agent 场景里，指令其实就是流程定义的一部分。指令模糊，Agent 的行为就会发散；指令清楚，系统才会稳定。

高质量指令通常有几个特点。

第一，尽量从已有业务文档里提炼，而不是从零想象。标准操作流程、客服脚本、政策文件，本来就是业务规则的沉淀，只是需要改写成模型容易遵循的步骤。

第二，把大任务拆成小步骤。越是密集、压缩、隐含前提多的说明，模型越容易理解偏。把它们拆成明确的执行顺序，成功率通常会明显提升。

第三，每一步都要对应清晰动作。比如是“询问用户订单号”，还是“调用接口获取账户信息”，还是“返回一段固定措辞的解释”，这些都应该写明。动作越具体，歧义越少。

第四，提前覆盖常见分支和边界条件。真实世界里，用户会给不完整信息，会问预料之外的问题，会在中途改变意图。稳健的指令不是只覆盖主流程，而是明确说明缺少关键信息时怎么办、走不通时怎么办、遇到异常输入时怎么办。

编排方式先求简单，复杂度上来再拆系统

Agent 设计里最容易被过度设计的部分，就是编排。很多团队一开始就想做全自动、多角色、图结构、复杂路由，最后系统既难评估也难维护。更稳妥的做法，是先把一个单 Agent 跑顺，再决定要不要拆成多 Agent。

单 Agent 往往是最好的起点

单 Agent 的优点非常实际：能力集中，结构简单，评估方便，维护成本低。你可以不断给它增加工具，让它通过循环执行直到达到退出条件，比如完成某个输出、调用了某个结束工具、返回了不需要再调用工具的回复，或者触发了错误和最大轮次限制。

这类“循环直到退出”的运行方式，是 Agent 的基本执行模型。它不是一次生成结束，而是不断观察当前状态、决定下一步、调用工具、吸收结果、继续推进，直到任务完成或被中断。

单 Agent 还能通过提示模板来降低维护成本。与其为不同用户场景维护大量独立提示，不如定义一套可注入变量的基础模板，再把用户信息、策略参数、业务条件作为变量填进去。这样新增场景时，你调整的是模板参数，而不是整套流程逻辑。

只有当单 Agent 真的撑不住时，才应该拆成多个 Agent

多 Agent 不是更高级，而是更复杂。它确实能带来更强的模块化，但也会引入更多状态传递、边界定义、调试和评估问题。因此，判断是否该拆分，关键不在于“功能多不多”，而在于“复杂性是否已经超过单 Agent 能稳定处理的范围”。

通常有两个很实际的信号。

一个信号是逻辑分支太多。当提示词里堆满 if-then-else 式条件，模板变得越来越难读、难改、难测，说明这个系统已经不适合继续压在一个 Agent 里了。

另一个信号是工具负担失控。不是单纯工具数量多，而是工具之间过于相似、重叠，导致模型总是选错。即使你已经改善了名称、参数和描述，问题仍然频繁出现，这时就应该考虑把不同任务域拆给不同 Agent。

多 Agent 主要有两种常见模式

第一种是经理模式，也可以理解成“Agent 作为工具”。这里会有一个中心 Agent 负责和用户交互、掌握全局上下文，再通过工具调用其他专门 Agent 去完成具体任务，最后把结果整合成统一回复。

这种模式适合那些希望始终由一个 Agent 控制整体流程的系统。比如一个翻译助手接到“把 hello 翻成西班牙语、法语和意大利语”的请求时，中心 Agent 可以分别调用三个语言 Agent，再把结果统一返回给用户。

第二种是去中心化的交接模式。这里没有一个 Agent 永远控制全局，而是由多个平级 Agent 根据各自擅长的任务相互交接控制权。一个分诊 Agent 接到客户问题后，可以把“查订单”交给订单 Agent，把“技术故障”交给技术支持 Agent，把“购买咨询”交给销售 Agent。交接之后，新的 Agent 直接继续和用户互动。

这种模式特别适合会话分诊和职责边界清楚的服务流程。只要不需要一个中心角色持续做综合判断，它往往比经理模式更直接。

无论采用哪种编排方式，一个原则都应该保持不变：尽量让组件保持可组合、可替换、边界清晰，而不是过早把流程固化成难改的复杂结构。

Guardrails 不是附加项，而是 Agent 上线的前提

Agent 一旦能读数据、调工具、写系统、做高风险动作，安全问题就不再只是“回答得礼不礼貌”，而是会直接变成数据泄露、越权操作、品牌风险和业务损失。所以，Guardrails 不是最后补一层的可选配置，而是系统设计的一部分。

最有用的理解方式，是把 Guardrails 看成分层防御。单一护栏几乎不可能挡住所有问题，但把多个针对不同风险的护栏叠加起来，系统会稳很多。

常见的护栏大致分为几类。

相关性分类器用来判断输入是否在任务范围内。比如一个退款 Agent 被问“帝国大厦有多高”，这类明显偏题的问题就应该被拦住，而不是硬答。

安全分类器用来识别越狱、提示注入和试图套出系统指令的输入。凡是明显在诱导系统暴露内部规则、绕过限制、修改目标的内容，都应该优先处理。

PII 过滤器用来检查输出里是否暴露了不必要的个人敏感信息。很多系统不是输入危险，而是输出时无意泄露了不该返回的数据。

内容审核用于拦截仇恨、骚扰、暴力等不合规内容，保证系统在更广泛的开放环境中仍能保持安全交互。

工具级护栏则更贴近业务风险。每个工具都应该有风险评级，比如只读查询通常是低风险，而写入数据库、发起支付、取消订单、大额退款则可能是中高风险。风险越高，执行前就越应该增加额外检查，甚至要求人工确认。

最后还有规则型保护措施，比如黑名单、正则过滤、输入长度限制。这些看起来“笨”，但对已知威胁往往非常有效，特别适合拦截明显模式化攻击。

真正有用的 Guardrails 设计，不是一次性把所有可能规则都堆上去，而是先覆盖最关键的隐私和内容安全风险，再根据线上遇到的失败案例不断补充。也就是说，护栏体系本身也应该迭代。

人工介入机制决定了 Agent 能不能安全落地

再好的 Agent，也不该被默认成永远正确。尤其在上线初期，人工介入不是“系统不够自动化”的表现，反而是建立可靠系统最快的办法。

人工介入最重要的作用，是在不牺牲用户体验的前提下，把失败和边界暴露出来。Agent 做不下去时，应该能优雅地转交给人；而不是继续瞎猜，直到把问题做坏。

最常见的两类触发条件很明确。

一类是失败阈值超限。比如多次没理解用户意图、反复调用工具仍无法完成任务、在循环中不断碰壁，这时就不该继续让 Agent 自行尝试，而应该及时升级给人工处理。

另一类是高风险动作。凡是敏感、不可逆、影响资金或账户状态的操作，都应该在系统还没有建立足够可靠性之前加入人工监督。取消订单、批准大额退款、执行支付，这些都属于典型高风险动作。

这背后的逻辑很简单：Agent 最适合自动化的是高频但边界相对可控的工作；而一旦进入高损失区间，可靠的交接机制往往比继续追求自动化率更重要。

真正能落地的 Agent，都是从小系统迭代出来的

把 Agent 做成生产级系统，并不需要一开始就做成“全知全能”的复杂智能体。更现实的路径是，先找到一个确实适合 Agent 的工作流，再用一个单 Agent 加少量清晰工具把它跑通，建立评估基线，补上关键护栏，观察真实用户交互中的失败点，最后再决定是否扩展模型组合、工具集合和多 Agent 编排。

Agent 真正带来的变化，不只是回答问题更自然，而是让系统第一次能够在模糊、不完整、充满例外的环境里，持续推进一段任务直到完成。这让它特别适合那些规则系统已经脆化、非结构化信息太多、人工判断成本太高的工作流。

但它能否真正交付价值，取决于设计是否克制。模型要先保效果，工具要清晰可控，指令要可执行，编排要从简单开始，护栏要分层建设，人工介入要提前准备。把这些基础做对，Agent 才不是一个看上去很聪明的演示，而是一个能在真实业务里稳定工作的系统。