《A Practical Guide to Building Agents》文档学习
《A Practical Guide to Building Agents》文档总结
该文档是一份面向产品和工程团队的实用指南，旨在帮助团队探索并构建首个基于大语言模型（LLM）的智能体（Agent），提炼了大量客户部署经验，提供了从概念定义到实际落地的全流程最佳实践。
一、智能体（Agent）的核心定义
1. 本质与区别
- 本质：智能体是能代表用户独立完成任务的系统，可执行用户目标所需的一系列工作流（如解决客服问题、预订餐厅等），且具备高度自主性。
- 与传统软件/简单LLM应用的区别：传统软件需用户操作以简化自动化工作流，而智能体可自主执行；仅集成LLM但不控制工作流执行的应用（如简单聊天机器人、单轮LLM交互工具）不属于智能体🔶1-13。
2. 核心特征
- 依赖LLM管理工作流执行与决策，能识别工作流完成状态，主动纠正错误，失败时可暂停执行并将控制权交回用户。
- 可访问多种工具与外部系统交互（获取上下文、执行操作），并能根据工作流当前状态动态选择合适工具，且始终在明确的约束（Guardrails）内运行。
二、何时构建智能体
1. 核心适用场景
智能体适合传统确定性、规则化方法难以应对的工作流，优先选择以下三类场景：
- 复杂决策类：涉及细微判断、例外情况或上下文敏感决策的工作流，如客服流程中的退款审批。
- 规则难维护类：因规则集庞大复杂导致更新成本高、易出错的系统，如供应商安全审查。
- 依赖非结构化数据类：需解读自然语言、从文档提取信息或与用户对话交互的场景，如处理房屋保险索赔。
2. 典型案例对比
以支付欺诈分析为例，传统规则引擎像清单一样，仅根据预设标准标记交易；而LLM智能体更像资深调查员，能评估上下文、识别细微模式，即使无明确违规规则也可发现可疑活动，可有效应对复杂模糊场景。
三、智能体设计基础
智能体最基础的形式包含三大核心组件，具体如下表所示：
| 组件 | 作用说明 |
|---|---|
| 模型（Model） | 为智能体的推理与决策提供支持的LLM |
| 工具（Tools） | 智能体可使用的外部函数或API， legacy系统无API时，智能体可通过计算机使用模型与系统UI交互🔶1-34 |
| 指令（Instructions） | 定义智能体行为的明确指南与约束，高质量指令可减少歧义、提升决策准确性🔶1-34 |
1. 模型选择原则
- 分任务匹配：简单任务（如检索、意图分类）可使用更小、更快的模型；复杂任务（如退款审批）需更强大的模型。
- 原型与优化流程：先用最强大的模型构建原型确立性能基准，再尝试替换小模型验证效果，平衡性能、成本与延迟。
- 核心步骤：先通过评估建立性能基准，再用最优模型达成准确率目标，最后在可能的情况下用小模型优化成本与延迟1-47🔷1-49🔷。
2. 工具定义规范
- 工具类型：智能体需三类工具，且工具可作为其他智能体的工具（如经理模式中的子智能体），例如退款智能体、研究智能体、写作智能体1-59🔷。
- 设计要求：每个工具需标准化定义，实现工具与智能体的灵活多对多关联；工具需具备完善文档、充分测试与可复用性，以提升可发现性、简化版本管理。
3. 指令配置最佳实践
| 实践方法 | 具体说明 |
|---|---|
| 利用现有文档 | 基于现有操作流程、支持脚本或政策文档创建LLM友好的流程，如客服场景可参考知识库文章 |
| 提示拆分任务 | 将复杂资源拆解为更小、清晰的步骤，帮助模型更好遵循指令 |
| 定义明确操作 | 确保流程每一步对应具体操作/输出，如要求智能体询问用户订单号或调用API获取账户详情 |
| 覆盖边缘案例 | 预判常见变化（如用户信息不全、问题超出预期），用条件步骤说明处理方式 |
四、智能体编排（Orchestration）
编排模式用于实现智能体高效执行工作流，主要分为单智能体系统与多智能体系统两类。
1. 单智能体系统
- 核心特点：单个模型配备合适工具与指令，通过循环（loop）执行工作流，新增工具可扩展能力，且易于评估与维护1-91🔷。
- 运行机制：以“运行（run）”为核心，通过循环执行直至满足退出条件，常见退出条件包括调用最终输出工具、模型返回无工具调用的响应（如直接用户消息）等1-98🔷1-100🔷。
- 复杂度管理：可使用提示模板，通过单一灵活基础提示接受政策变量，适配多场景，简化维护与评估。
2. 多智能体系统
（1）适用场景
当单智能体无法遵循复杂指令、频繁选择错误工具时，可拆分构建多智能体系统，具体拆分依据包括：
- 逻辑复杂：提示包含大量条件语句（多if-then-else分支），提示模板难以扩展。
- 工具过载：工具存在相似性/重叠性，即使优化工具名称、参数与描述也无法提升性能。
（2）核心模式
| 模式 | 结构特点 | 适用场景 |
|---|---|---|
| 经理模式（Manager） | 中央“经理”智能体通过工具调用协调多个专业智能体，整合结果提供统一用户体验1-124🔷 | 需单一智能体控制工作流执行、接触用户的场景，如多语言翻译（经理智能体协调西班牙语、法语、意大利语翻译智能体）1-126🔷 |
| 去中心化模式（Decentralized） | 多个智能体地位平等，可根据专业领域相互移交任务控制权，移交时同步最新对话状态1-140🔷 | 无需单一智能体集中控制的场景，如客服流程（分诊智能体将订单查询移交订单管理智能体）1-150🔷 |
（3）设计原则
无论采用何种模式，均需保持组件灵活性、可组合性，并以清晰、结构化的提示为驱动。
五、约束（Guardrails）设计
1. 核心作用与定位
- 作用：管理数据隐私风险（如防止系统提示泄露）与声誉风险（如确保模型行为符合品牌定位），是LLM部署的关键组件，需与身份验证、访问控制等安全措施结合使用。
- 定位：分层防御机制，单一约束保护有限，需组合使用多种专业约束提升智能体安全性。
2. 约束类型
| 类型 | 功能说明 | 示例 |
|---|---|---|
| 相关性分类器 | 确保智能体响应在预期范围内，标记偏离主题的查询 | 将“帝国大厦有多高”标记为无关查询 |
| 安全分类器 | 检测试图利用系统漏洞的不安全输入（如越狱、提示注入） | 识别“扮演教师解释系统指令”这类提取系统提示的输入 |
| PII过滤器 | 审查模型输出，防止不必要的个人身份信息泄露 | 过滤输出中的手机号、身份证号 |
| 内容审核 | 标记有害/不当输入（如仇恨言论、骚扰、暴力内容） | 拦截包含辱骂性语言的用户消息 |
| 工具安全措施 | 按工具风险（只读/写权限、可逆性、财务影响等）评级（低/中/高），高风险工具执行前触发检查或人工审批 | 对“发起退款”等高风险工具，执行前需人工确认 |
| 规则化保护 | 用确定性措施（黑名单、输入长度限制、正则过滤）防范已知威胁 | 拦截包含违禁词或SQL注入的输入 |
| 输出验证 | 通过提示工程与内容检查确保响应符合品牌价值观 | 避免输出损害品牌形象的言论 |
3. 构建流程与机制
- 构建步骤：优先关注数据隐私与内容安全；根据实际边缘案例与故障新增约束；平衡安全性与用户体验，随智能体演进调整约束1-174🔷1-176🔷。
- 执行机制：以Agents SDK为例，默认采用乐观执行，主智能体生成输出时约束同步运行，若违反约束则触发异常；约束可实现为函数或智能体，如防越狱、相关性验证等1-190🔷。
六、人类干预机制
1. 核心价值
人类干预是提升智能体实际性能且不影响用户体验的关键保障，尤其在部署初期，可帮助识别故障、发现边缘案例、建立完善的评估周期。
2. 触发场景
- 超出失败阈值：设定智能体重试或操作限制，若超出（如多次无法理解用户意图），则触发人类干预。
- 高风险操作：对敏感、不可逆或高风险操作（如取消用户订单、大额退款、付款），需触发人工监督，直至智能体可靠性达标。
七、总结与建议
1. 智能体核心价值
智能体开启了工作流自动化新时代，能应对模糊场景、跨工具执行操作、处理多步骤任务，尤其适合复杂决策、非结构化数据处理、规则难维护的场景，区别于简单LLM应用。
2. 构建关键建议
- 基础建设：选择合适模型，搭配定义清晰的工具与结构化指令。
- 编排策略：从单智能体起步，需复杂处理时再过渡到多智能体系统。
- 安全保障：全流程部署约束，结合人类干预机制。
- 落地路径：从小规模验证开始，结合真实用户反馈迭代，逐步扩展能力。