本文深入解析智能体（Agent）开发，从概念到实践，探讨了智能体的定义、适用场景、设计三要素以及安全性和编排模式等内容。作者结合实战经验，为首次尝试构建智能体的产品与工程团队提供了详尽的指导和建议。
今年一直在从事Agent相关工作，所以形成了一套自己的AI项目心得，但AI这个东西最怕孤陋寡闻，所以每天都在读各种报告，最近OpenAI除了一份报告《构建智能体的实用指南》，看了下来很不错，于是推荐给大家。
报告一共32页，其目录结构为：
大型语言模型（LLM）的能力正迅速提升，如今已能胜任复杂的多步骤任务。推理、多模态处理与工具调用等方面的突破，催生了全新的 LLM 驱动系统——智能体（agent）。
本指南专为首次尝试构建智能体的产品与工程团队撰写，汇集诸多客户部署的经验要点，凝练成切实可行的最佳实践。内容涵盖：
传统软件 帮助用户简化并自动化工作流程。
智能体（Agent） 则能够 自主 为用户执行同样的流程。
智能体是在高度自主的前提下，代表用户完成任务的系统。
工作流程（workflow） 指为实现用户目标必须依次执行的一系列步骤，例如解决客服问题、预订餐厅、提交代码变更，或生成数据报告。
非智能体场景：将 LLM 集成到应用中却不让它控制流程执行（如简单聊天机器人、单轮问答 LLM、情绪分类器等）——这些都不属于智能体。
所以，要做智能体开发首先需要对Agent进行清晰定义：
第一，LLM 驱动的流程控制与决策
第二，多工具调用并受控于安全策略
这里总结一下，就当前Agent的核心其实在于两点：
之所以模型会自信到自己编排Workflow，还是基于模型基础能力的大幅提升。
构建智能体意味着重新思考系统的决策与复杂性的处理方式。
与传统自动化不同，智能体尤其适用于那些确定性、规则驱动方法捉襟见肘的工作流程。
以 支付欺诈分析 为例：
传统规则引擎 像一张检查清单，根据预设条件对交易打标。
LLM 智能体 更像经验老到的调查员，会综合上下文、捕捉微妙模式，即使没有触发明确规则，也能识别可疑行为。
这种细腻的推理能力正是智能体在复杂、模糊场景中大显身手的关键。
PS：这里要提一嘴，就真实实践来说，规则引擎效率与准确度都更高，Agent这里所谓的微妙模式其实属于规则引擎漏掉的规则，逻辑上是需要对规则引擎进行补足的；
真实的应用会遵循快慢系统，也就是规则引擎做第一轮，模型做兜底
所以什么时候应该考虑Agent呢？
当你评估智能体的价值时，优先挑选那些 传统自动化始终难以【完全】覆盖 的流程，尤其是规则方法存在痛点的场景：
在正式投入构建智能体之前，请确认你的使用场景确实符合以上标准。 若流程本质上可以用简单、可靠的确定性方案解决，就无需强行上智能体。
PS：其实这种最大的问题是100%，模型得保证自己不会出错，至少正确率在一个数值之上，否则Agent很难得到信任
在最基本的形式中，一个智能体由 三大核心组件 组成：
weather_agent = Agent(
name=”Weather agent”,
instructions=”You are a helpful agent who can talk to users about the weather.”,
tools=[get_weather],
model=”gpt-4″ # 指定使用的LLM模型
)
不同模型在任务复杂度、延迟和成本方面存在差异：
正如下一节 “编排（Orchestration）” 将讨论的，你往往需要在同一工作流程中按任务类型混用多种模型。
并非所有步骤都需要最强模型
简单的检索或意图分类，可用体积小、速度快的模型完成。
难度更高的决策（例如是否批准退款）则可能需要更强大的模型。
一个行之有效的方法是：先用性能最强的模型完成所有步骤，获得基准表现；随后尝试用更小的模型替换某些环节，观察是否仍能达到可接受效果。
这样既不会过早限制智能体能力，又能清晰定位小模型的成功与失败边界。
PS：其实以现在大模型的资费之低，完全可以全部用最强模型
只不过比较麻烦的是，还是有很多私有化部署场景，不得不依赖小模型，所以这个策略是适用的
选型原则考虑三点：
通过调用底层应用或系统的 API，工具可以扩展智能体的能力。
对于缺乏 API 的传统系统，智能体可借助「电脑操作模型」直接操控网页或桌面界面，与人类操作无异。
每个工具都应采用标准化的定义，以便在多个智能体之间灵活复用、形成多对多关系。
良好文档、充分测试、可重复使用的工具能提高可发现性，简化版本管理，并避免重复造轮子。
PS：这里所谓的computer-use远没有大家以为那么成熟，还有很大优化空间，暂时来说重复的RPA是比较可控的
智能体常用的三类工具
下面示范如何在 OpenAI Agents SDK 中，为前文的 weather_agent 智能体添加一组工具（网络搜索 + 结果存储）：
from agents import Agent, WebSearchTool, function_tool
import datetime, db # 假设已有数据库操作模块
@function_tool
def save_results(output: str) -> str:
# 将搜索结果写入数据库
db.insert({“output”: output, “timestamp”: datetime.datetime.now()})
return “File saved”
search_agent = Agent(
name=”Search agent”,
instructions=”Help the user search the internet and save results if asked.”,
tools=[WebSearchTool(), save_results],
)
当所需工具的数量不断增多时，建议将任务拆分给多个智能体协同完成（详见 Orchestration 章节）。
高质量指令对任何 LLM 应用都至关重要，对 智能体 更是如此。
指令越清晰，歧义就越少，智能体的决策就越可靠——从而让整条工作流运行得更顺畅、错误更少。
智能体指令最佳实践
使用高阶模型自动生成指令
你可以让 o1、o3‑mini 等 高性能模型 直接根据现有文档生成规范指令。
以下英文提示词示例展示了这一思路：
你是一位撰写 LLM 智能体指令的专家。
请将以下帮助中心文档转换为一份清晰的指令清单，使用编号列表格式。
该文档是一项供 LLM 遵循的政策。
请确保没有任何歧义，并以智能体可直接执行的指令方式撰写。
待转换的帮助中心文档如下：{{help_center_doc}}
在基础组件就绪之后，你可以通过选择合适的 编排模式 来让智能体高效执行工作流程。
虽然直接上手开发一个架构复杂、完全自主的智能体很有吸引力，但实践表明，循序渐进的迭代式方法往往更容易取得成功。
编排模式的两大类别：
接下来，我们将对这两种模式逐一展开。
单个智能体最初只需要最基本的模型和一两个工具即可运行；随着需求增加，再逐步为它“装配”新的工具。
这样做既能让功能随项目迭代而自然增长，又不会因为过早拆分成多智能体而引入额外的编排成本。
其核心组件为：
任何编排方案都依赖一个 “run” 概念——通常实现为循环，使智能体持续工作直至满足退出条件。常见退出条件包括：
例如，在 Agents SDK 中，agent 是通过该方法启动的，它会循环调用 LLM，直到发生以下任一情况：Runner.run()
示例用法：
Agents.run(agent, [UserMessage()]) # “What’s the capital of the USA?”
这种 while loop 的概念是 agent 运行机制的核心。
在多智能体系统中（稍后会看到），可以出现一系列工具调用和 agent 之间的交接，但仍允许模型在满足退出条件之前连续执行多步。
在不切换到多智能体框架的情况下管理复杂性的有效策略是使用 提示模板（prompt templates）。
与其为不同用例维护大量独立提示，不如使用一个灵活的基础提示，并注入策略变量。
此模板方法能够轻松适应各种场景，从而显著简化维护与评估。当出现新用例时，只需更新变量，而无需重写整个工作流：
你是一名呼叫中心客服。
你正在与 {{user_first_name}} 交流，对方已成为会员 {{user_tenure}}。
该用户最常见的投诉类别是 {{user_complaint_categories}}。
请向用户致以问候，感谢其一直以来的忠诚支持，并回答他们可能提出的任何问题！
所以，这里问题来了：什么时候要考虑创建多个Agent呢？
我们的总体建议是：优先充分挖掘单个 agent 的能力。
多个 agent 可以在概念上带来直观的分工，但同时会引入额外的复杂性和开销；很多场景中，一个配备合适工具的 agent 已足够。
对于复杂工作流，将提示词（prompts）与工具拆分给多个 agent 往往能提升性能与可扩展性。
若你的 agent 难以执行复杂指令，或经常选择错误工具，就可能需要进一步细分系统，引入更多独立 agent。
将 agent 拆分的实践指南
接下来，我们来介绍多Agent系统。
虽然多智能体系统可以根据具体工作流和需求设计出多种形态，但我们的客户实践表明，有两类 普适的模式：
第一，经理模式（Manager, agents as tools）
一个中心化的“经理” agent 通过工具调用协调多个专门 agent，每个 agent 负责特定任务或领域。
第二，去中心化模式（Decentralized, agents handing off to agents）
多个 agent 以平级身份运行，根据各自专长将任务相互交接。
多智能体系统可抽象为图结构：节点表示 agent：
在 经理模式 中，一个中心化的 “经理” agent 通过 工具调用（tool calls）来协调多个专精 agent；每个 agent 只负责自己擅长的任务或领域。
在 去中心化模式 中，多个 agent 以 同级 身份协同，根据各自专长将任务 交接（handoff）给最合适的 agent 继续处理。
无论采用哪种编排模式，核心原则一致：保持组件灵活、可组合，并依赖清晰、结构化的提示来驱动。
所谓经理模式非常类似于DeepSeek的MoE架构。Manager 模式赋予一个 中心化的大语言模型（LLM）——“经理” 能力，使其能够通过工具调用（tool calls）无缝编排一张由 专门 agent 组成的网络。
经理不会丢失上下文，也不会失去对流程的掌控，而是能够 在正确的时间把任务智能地分派给正确的 agent，并且 毫不费力地将各 agent 的输出整合 成一次 连贯一致的交互。
这样一来，用户可以获得 流畅且统一 的使用体验，同时各种 专业化能力 也能 随时按需调用。
他适用场景是：当你只希望由 单个 agent 来掌控整个工作流的执行，并且该 agent 需要直接与用户交互时，Manager 模式是最理想的选择。
例如，在 Agents SDK 中实现 Manager 模式：
from agents import Agent, Runner # 示例导入
# ——– 定义三个专用翻译 agent ——–
spanish_agent = Agent(
name=”translate_to_spanish”,
instructions=”Translate the user’s message to Spanish”
)
french_agent = Agent(
name=”translate_to_french”,
instructions=”Translate the user’s message to French”
)
italian_agent = Agent(
name=”translate_to_italian”,
instructions=”Translate the user’s message to Italian”
)
# ——– 定义经理 agent ——–
manager_agent = Agent(
name=”manager_agent”,
instructions=(
“You are a translation agent. You use the tools given to you to translate. ”
“If asked for multiple translations, you call the relevant tools.”
),
tools=[
spanish_agent.as_tool(
tool_name=”translate_to_spanish”,
tool_description=”Translate the user’s message to Spanish”,
),
french_agent.as_tool(
tool_name=”translate_to_french”,
tool_description=”Translate the user’s message to French”,
),
italian_agent.as_tool(
tool_name=”translate_to_italian”,
tool_description=”Translate the user’s message to Italian”,
),
],
)
# ——– 运行示例 ——–
asyncdef main():
msg = input(“请输入要翻译的文本： “)
orchestrator_output = await Runner.run(
manager_agent, msg
)
print(“Translation step:”)
for message in orchestrator_output.new_messages:
print(f” – {message.content}”)
# 调用示例：
# 输入：Translate ‘hello’ to Spanish, French and Italian for me!
声明式图 vs. 非声明式
声明式框架，某些框架要求开发者预先用图形方式（节点 = agents；边 = 确定性或动态交接）显式定义工作流中的每个分支、循环与条件。
优势：可视化清晰。
劣势：当工作流更动态、更复杂时，这种方式会迅速变得繁琐，甚至需要学习专门的领域语言（DSL）。
非声明式、代码优先方法，允许开发者直接使用熟悉的编程结构表达工作流逻辑，无需提前绘制完整的图。
优势：更灵活、适应性更强，可根据运行时需求动态编排 agent。
这里很多同学可能不太看得懂，我做下简单说明，所谓声明式结构，他就像画流程图一样，需要提前定义好所有的步骤和路线，比如银行开户自动化流程：
其优势很清晰：流程稳定，但缺点也很明显，在负责逻辑里要调整流程是很烦的，比如：修改整个流程图或者重新定义所有连接关系。
而非声明式，也就是代码优先，面对这种情况改几行代码即可…
再用大白话来说是：声明式是用扣子、dify去拖拽；代码优先是自己有个工程团队写代码。
在去中心化模式中，智能体（agent）之间可以相互”移交”（handoff）工作流执行权。
移交是一种单向传递机制，允许一个智能体将任务委托给另一个智能体。
在 Agents SDK 中，移交被设计为一种工具或函数类型。当某个智能体调用移交函数时，系统会立即启动目标智能体的执行流程，并同步转移最新的会话状态。
其核心特点是：
总结下来就是：当工作流不需要中央控制器进行全局协调，而更适合由不同智能体分阶段自主处理时，此模式能实现最优效能。
下面展示了如何用 Agents 实现一个同时处理「销售 + 售后支持」的去中心化工作流。
核心思路是由 Triage Agent 先行分流，再把会话交接（handoff）给最合适的专职智能体：
from agents import Agent, Runner
# ────────────────────── 专职智能体 ──────────────────────
technical_support_agent = Agent(
name=”Technical Support Agent”,
instructions=(
“You provide expert assistance with resolving technical issues, ”
“system outages, or product troubleshooting.”
),
tools=[search_knowledge_base] # ※ 查阅知识库
)
sales_assistant_agent = Agent(
name=”Sales Assistant Agent”,
instructions=(
“You help enterprise clients browse the product catalog, ”
“recommend suitable solutions, and facilitate purchase transactions.”
),
tools=[initiate_purchase_order] # ※ 生成采购订单
)
order_management_agent = Agent(
name=”Order Management Agent”,
instructions=(
“You assist clients with inquiries regarding order tracking, ”
“delivery schedules, and processing refunds.”
),
tools=[track_order_status, # ※ 追踪订单状态
initiate_refund_process] # ※ 发起退款流程
)
# ────────────────────── 分流智能体 ──────────────────────
triage_agent = Agent(
name=”Triage Agent”,
instructions=(
“You act as the first point of contact, assessing customer ”
“queries and directing them promptly to the correct specialized agent.”
),
handoffs=[technical_support_agent,
sales_assistant_agent,
order_management_agent] # 可交接对象
)
# ────────────────────── 运行示例 ──────────────────────
Runner.run(
triage_agent,
[
“Could you please provide an update on the delivery timeline ”
“for our recent purchase?”
]
)
流程说明：
去中心化分工让每个智能体专注于自身领域，减少主控压力并提升专业度，特别适合 会话分流 场景。
解惑
很多同学这里可能有点搞不懂，我这里做下简单说明：
去中心化模式就像一群同级别的同事在一个开放工位上办公——谁最擅长就谁先伸手，把事情办完后可以直接把桌上的文件递给下一位更合适的同事继续。
没有“组长”一直盯着，也没有固定流程图，大家边做边把活儿往最合适的人手里“传”。
跟「经理模式」有什么本质区别？
经理模式属于全能助手，用户始终面对同一个虚拟客服形象，运作逻辑如下：
用户 → 经理Agent → 调用工具 → 专业Agent → 返回结果 → 经理Agent整合 → 回复用户
用户提问：”帮我查订单1234的物流，再推荐同类商品”
经理Agent接收请求
后台同时调用两个工具：
经理Agent将两个结果整合成自然语言回复：您的订单预计明天送达。根据购买记录，为您推荐这些热销配件：①…②…
这里优点很清晰：
去中心化模式类似于科室接力，用户会感知到服务主体的切换：
用户 → 分诊Agent → 转接 → 售后Agent → 转接 → 销售Agent → … → 最终闭环
用户提问：”手机屏幕碎了怎么保修？顺便看看新款机型”
分诊Agent识别双重需求 → 触发转接规则
第一棒：维修客服Agent 接管对话：”请提供设备IMEI码，我将为您生成维修工单…”
解决维修问题后，自动触发：”检测到您关注新品，正在为您转接产品顾问…”
第二棒：销售Agent 展示新品并引导购买
这里的产品体验就会有所不同了：
这里的逻辑跟我之前的培训PPT很类似的：
在一个领域里面，采用经理模式是比较好的，但如果从法律领域跳到了医疗领域去中心化比较合适。
Agent的安全性
精心设计的保护措施可以帮助你管控数据隐私风险（例如，防止系统提示词泄露）和声誉风险（例如，确保模型行为符合品牌调性）：
下图（此处省略）演示了如何将 LLM 级保护措施、基于规则的保护措施（如 regex），以及 OpenAI Moderation API 结合起来，对用户输入进行多重审查：
构建保护措施的三步启发式：
具体，Guardrails 可实现为 函数 或 代理，用于强制执行如下策略：
人类兜底
人类介入是一道关键安全网，可在 不牺牲用户体验 的前提下提升代理在真实环境中的表现。
在部署早期尤为重要，能够帮助识别失败、发现边缘案例，并建立稳健的评估循环。
实施人类介入机制，可在代理无法完成任务时 优雅地交出控制权：
典型触发条件：
Exceeding failure thresholds — 超过失败阈值
为代理的重试或操作次数设限；若超出（如多次无法理解客户意图），则升级至人工处理。
High‑risk actions — 高风险操作
对敏感、不可逆或高价值操作，应在充分信任代理可靠性之前引入人工监督。
示例：取消用户订单、批准大额退款、执行付款。
Agents 正在开启工作流自动化的新纪元——系统能够在不确定场景中推理、跨工具执行操作，并以高度自主性处理多步任务。
与更为简单的 LLM 应用不同，智能代理可端到端地执行完整流程，因而特别适用于 复杂决策、非结构化数据 或 脆弱的基于规则的系统 等场景。
本文由人人都是产品经理作者【叶小钗】，微信公众号：【叶小钗】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。