构建有效的 AI 智能体实战指南

在这里插入图片描述

📖 系列: AI 与 Agent 系统设计 | 难度: ⭐⭐ 中级 | 阅读时间: ~20 分钟

TL;DR

经过与数十个团队合作构建 LLM 智能体后发现：最成功的实现从不依赖复杂框架，而是用简单、可组合的模式构建。 本文系统介绍了 5 种工作流模式（提示链、路由、并行化、协调者-工作者、评估器-优化器）和自主智能体，给出了每种模式的适用场景、实战案例和决策建议。核心原则：从简单开始，只在复杂性明显改善结果时才增加复杂性。

📋 目录

  1. 什么是智能体？
  2. 何时使用（以及何时不使用）智能体
  3. 如何选择框架
  4. 基础构建块：增强的 LLM
  5. 工作流：提示链
  6. 工作流：路由
  7. 工作流：并行化
  8. 工作流：协调者-工作者
  9. 工作流：评估器-优化器
  10. 自主智能体
  11. 组合与定制
  12. 总结与核心原则
  13. 附录 1：智能体实践案例
  14. 附录 2：工具的提示工程
  15. 术语对照表
  16. 实战检查清单
  17. 常见问题

什么是智能体

💡 本节导读：厘清"智能体"的定义。将所有 LLM 驱动的系统统称为智能体系统，但在工作流（预定义路径）和智能体（动态自主决策）之间划出重要架构界限。

"智能体"（Agent）可以用多种方式定义。一些客户将智能体定义为完全自主的系统——可以长时间独立运行，使用各种工具完成复杂任务。另一些人用它描述遵循预定义工作流的更规范性实现。

我们将所有这些变体统称为智能体系统（agentic systems），但在工作流（workflows）和智能体（agents）之间划出重要的架构区别：

简单来说：

  • 工作流 = 你写好了脚本，LLM 按脚本执行（像按菜谱做菜）
  • 智能体 = LLM 自己决定做什么、怎么做（像厨师自由发挥）

下面我们将详细探讨这两种类型的智能体系统。在附录 1（"智能体实践"）中，我们描述了客户发现此类系统特别有价值的两个领域。

何时使用

💡 本节导读：并非所有场景都需要智能体。很多任务用单次 LLM 调用加检索就能解决。智能体系统用延迟和成本换取更好的任务性能——要判断这种权衡何时值得。

核心建议：寻找尽可能简单的解决方案，只在需要时才增加复杂性。

🎯 核心概念: 简单性优先 — 这可能意味着根本不构建智能体系统。对于许多应用，通过检索和上下文示例来优化单次 LLM 调用通常就够了。

当确实需要更高复杂性时：

  • 工作流：为明确定义的任务提供可预测性和一致性
  • 智能体：在大规模需要灵活性和模型驱动决策时是更好的选择

如何选择框架

💡 本节导读：框架能加速入门，但也可能掩盖底层逻辑导致调试困难。建议先直接用 LLM API，确实需要框架时也要理解底层代码。

常见的智能体框架包括：

这些框架通过简化标准低级任务（调用 LLM、定义和解析工具、链接调用）使入门变得容易。然而，它们经常创建额外的抽象层，可能掩盖底层的提示和响应，使调试更困难。

⚠️ 常见陷阱: 对底层代码的错误假设是客户错误的常见来源。使用框架时，确保你理解底层实现。

建议：先直接使用 LLM API — 许多模式只需几行代码即可实现。参见 cookbook 了解示例实现。

基础构建块

💡 本节导读：所有智能体系统的基本单元是"增强的 LLM"——具备检索、工具和记忆能力的 LLM。

增强的 LLM

智能体系统的基本构建块是通过检索、工具和记忆等增强功能增强的 LLM。当前模型可以主动使用这些能力——生成自己的搜索查询、选择适当的工具、确定要保留哪些信息。

🎯 核心概念: 增强的 LLM — 就像给一个聪明的大脑配备了：📚 图书馆（检索）、🔧 工具箱（工具）、🧠 笔记本（记忆）

我们建议重点关注实施的两个关键方面：

  1. 根据特定用例定制这些功能
  2. 确保为 LLM 提供简单且文档良好的接口

实现这些增强的一种方法是通过 模型上下文协议（MCP），它允许开发者通过简单的客户端实现与不断增长的第三方工具生态系统集成。

在本文的其余部分中，我们假设每个 LLM 调用都可以访问这些增强功能。

提示链

💡 本节导读：将任务分解为一系列步骤，每步 LLM 处理上一步的输出。像工厂流水线。

工作原理

提示链（Prompt Chaining）将任务分解为一系列步骤，其中每个 LLM 调用都会处理前一个步骤的输出。你可以在任何中间步骤上添加编程检查（即下图中的"门"），确保流程仍按计划进行。
在这里插入图片描述

🔧 类比: 像工厂流水线——上一道工序的输出是下一道的输入。中间的"门"是质检站，不合格就拦截。

何时使用

任务可以轻松、干净地分解为固定子任务的情况。主要目标是通过让每次 LLM 调用变得更简单，来用延迟换取更高的准确性。

实战案例

  • 生成营销文案，然后将其翻译成其他语言
  • 编写文档大纲，检查大纲是否符合特定标准，然后根据大纲编写文档

路由

💡 本节导读：对输入分类并引导至专门的后续任务。像医院分诊台。

工作原理

路由（Routing）对输入进行分类并将其引导至专门的后续任务。此工作流允许分离关注点并构建更专业的提示。如果没有此工作流，针对一种输入的优化可能会损害其他输入的性能。
在这里插入图片描述

🔧 类比: 像医院分诊台——根据你的症状把你送到不同科室：发烧→内科，骨折→骨科，心悸→心内科。

何时使用

复杂任务中存在更好单独处理的不同类别，且分类可以被准确处理（通过 LLM 或传统分类算法）。

实战案例

  • 将不同类型的客户服务查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具
  • 将简单/常见问题路由到更小、经济高效的模型（如 Claude Haiku 4.5），将困难/不寻常的问题路由到更强大的模型（如 Claude Sonnet 4.5）以优化性能

并行化

💡 本节导读：多个 LLM 同时工作，聚合输出。有分段和投票两种变体。

工作原理

LLM 有时可以同时处理一项任务，并以编程方式聚合它们的输出。并行化体现在两个关键变体中：

  • 分段（Sectioning）：将任务分解为并行运行的独立子任务
  • 投票（Voting）：多次运行同一任务以获得不同的输出
    在这里插入图片描述

🔧 类比: 像多人同时翻译一本书的不同章节（分段），或像多个评委同时打分然后取平均（投票）。

何时使用

  • 划分的子任务可以并行化以提高速度
  • 需要多个视角或尝试以获得更高置信度

实战案例

  • 分段：实施护栏——一个模型实例处理用户查询，另一个筛选不当内容。这比同一个 LLM 调用同时处理护栏和核心响应效果更好
  • 分段：自动评估 LLM 性能——每个 LLM 调用评估模型性能的不同方面
  • 投票：审查代码漏洞——多个不同提示审查并标记代码
  • 投票：评估内容是否不当——多个提示评估不同方面或要求不同投票阈值

协调者工作者

💡 本节导读：中央 LLM 动态分解任务、委派给工作者 LLM、综合结果。像项目经理分配任务。

工作原理

在协调者-工作者（Orchestrator-Workers）工作流中，一个中央 LLM 动态分解任务，将它们委托给工作者 LLM，并综合其结果。
在这里插入图片描述

🔧 类比: 像项目经理——拿到需求后动态分配给不同工程师（前端、后端、测试），最后汇总结果。与并行化的区别：子任务不是预先定义的，而是由协调者根据具体输入动态确定的。

何时使用

无法预测所需子任务的复杂任务。例如在编码中，需要更改的文件数量以及每个文件中更改的性质可能取决于具体任务。

实战案例

  • 每次对多个文件进行复杂更改的编码产品
  • 涉及从多个来源收集和分析信息的搜索任务

评估器优化器

💡 本节导读：一个 LLM 生成响应，另一个 LLM 评估并提供反馈，循环迭代。像作家改稿。

工作原理

在评估器-优化器（Evaluator-Optimizer）工作流中，一个 LLM 调用生成响应，而另一个在循环中提供评估和反馈。
在这里插入图片描述

🔧 类比: 像作家改稿——写一版初稿→编辑批注→改一版→再批注→直到满意。也像学生做题——做题→对答案→发现错了→改正→再对答案。

何时使用

有明确的评估标准，且迭代细化提供可衡量的价值时。两个好迹象：

  1. 当人类清楚地表达反馈时，LLM 响应可以明显改善
  2. LLM 能提供此类反馈

实战案例

  • 文学翻译：译者 LLM 最初可能无法捕捉细微差别，但评估器 LLM 可以提供有用的批评
  • 复杂搜索任务：需要多轮搜索和分析来收集全面信息，评估器决定是否需要进一步搜索

自主智能体

💡 本节导读：LLM 动态决定自己的流程，在循环中与环境交互。这是最灵活但也最不可控的模式。

工作原理

随着 LLM 在关键能力上成熟——理解复杂输入、参与推理和规划、可靠地使用工具、从错误中恢复——自主智能体（Autonomous Agents）在生产中不断涌现。

智能体的工作流程：

  1. 从人类用户的命令或交互式讨论开始
  2. 任务明确后，独立规划和执行
  3. 每一步从环境获取"基本事实"（如工具调用结果或代码执行）来评估进度
  4. 在检查点或遇到阻碍时暂停以获取人工反馈
  5. 任务完成后终止，或达到停止条件（如最大迭代次数）
    在这里插入图片描述

🔧 类比: 像厨师做菜——看食材（感知）→想做法（推理）→动手做（行动）→尝味道（反馈）→不对就调整。循环往复直到菜做好。

何时使用

  • 开放式问题：难以预测所需步骤数，无法硬编码固定路径
  • LLM 可能运行很多轮，你需要对其决策有一定程度的信任
  • 智能体的自主性使它们成为在可信环境中扩展任务的理想选择

⚠️ 常见陷阱: 自主性意味着更高的成本和复合错误的风险。建议在沙盒环境中进行广泛测试，并配备适当的护栏。

实战案例

  • 用于解决 SWE-bench 任务的编码智能体——根据任务描述对许多文件进行编辑
  • "计算机使用"参考实现——Claude 使用计算机完成任务

组合与定制

💡 本节导读：这些模式不是规定性的，而是可以塑造和组合的常见模式。

这些构建块不是规定性的。它们是开发人员可以塑造和组合以适应不同用例的常见模式。与任何 LLM 功能一样，成功的关键是衡量性能并迭代实现。

🎯 核心原则: 只有当复杂性明显改善结果时，才考虑增加复杂性。

总结

💡 本节导读：LLM 领域的成功不在于构建最复杂的系统，而在于为你的需求构建正确的系统。

三大核心原则

  1. 保持简单 — 智能体设计的简单性
  2. 优先透明 — 显式展示智能体的规划步骤
  3. 精心设计 ACI — 通过充分的工具文档和测试打造智能体-计算机接口（ACI）

🎯 专家注解: 框架可以帮你快速入门，但在转向生产时，不要犹豫减少抽象层并使用基本组件构建。实践中很多客户错误来自对框架底层行为的不理解。理解底层代码是使用框架的前提。

附录1

智能体实践案例

💡 本节导读：两个特别有前途的智能体应用场景——客户支持和编码智能体。

我们的客户合作揭示了人工智能智能体的两个特别有前途的应用，它们证明了上述模式的实际价值。这两个应用都说明了智能体如何为需要对话和行动的任务增加最大价值，具有明确的成功标准，启用反馈循环，并集成有意义的人工监督。

A. 客户支持

客户支持通过工具集成将熟悉的聊天机器人界面与增强功能结合起来。这非常适合开放式智能体，因为：

  • 支持交互自然遵循对话流程，同时需要访问外部信息和操作
  • 可以集成工具来提取客户数据、订单历史记录和知识库文章
  • 可以通过编程方式处理退款或更新工单等操作
  • 成功可以通过用户定义的解决方案来明确衡量

🎯 专家注解: 一些公司已通过基于使用的定价模型（仅对成功解决收费）证明了此方法的可行性，显示出对智能体有效性的信心。

B. 编码智能体

软件开发领域在 LLM 功能方面表现出巨大潜力，从代码完成到自主解决问题。智能体特别有效，因为：

  • 代码解决方案可通过自动化测试验证
  • 智能体可以使用测试结果作为反馈来迭代解决方案
  • 问题空间定义明确且结构合理
  • 输出质量可以客观衡量

在实际实现中，智能体现在可以仅根据 PR 描述解决 SWE-bench Verified 基准测试中的实际 GitHub Issue。

⚠️ 注意: 虽然自动化测试有助于验证功能，但人工审查对于确保解决方案符合更广泛的系统要求仍然至关重要。

附录2

工具的提示工程

💡 本节导读：工具是智能体的关键组成部分。设计工具接口（ACI）和设计人机界面（HCI）一样重要。

无论构建哪种智能体系统，工具都可能是重要组成部分。工具使 Claude 能够通过在 API 中指定外部服务和 API 的确切结构和定义来与它们交互。

格式选择建议

  1. 给模型足够的标记来"思考" — 在它陷入困境之前
  2. 保持格式接近互联网上自然出现的文本 — 模型见过最多的格式
  3. 确保没有格式化"开销" — 如必须精确计数数千行代码或字符串转义

ACI 设计原则

🎯 核心概念: 在人机界面（HCI）上投入多少精力，就应计划在智能体-计算机界面（ACI）上投入同样多的精力。

  • 站在模型的角度思考：根据描述和参数，使用这个工具是否显而易见？好的工具定义应包括示例用法、边缘情况、输入格式要求以及与其他工具的明确界限
  • 优化参数命名：像为初级开发者写优秀的文档字符串一样
  • 测试模型如何使用工具：运行多个示例输入，查看错误并迭代
  • 防错（Poka-yoke）：修改参数使犯错更难

🎯 专家注解: 在为 SWE-bench 构建智能体时，花在优化工具上的时间比整体提示还多。例如发现模型在移出根目录后会使用相对文件路径出错——改为始终要求绝对路径后，模型完美地使用了该方法。

📖 术语对照表

英文 中文 说明
Agent 智能体 自主执行任务的 AI 系统，动态决定流程
Workflow 工作流 预定义代码路径编排的 LLM 系统
Agentic System 智能体系统 工作流和智能体的统称
Prompt Chaining 提示链 顺序执行的多步 LLM 调用
Routing 路由 按输入分类分发到不同处理流程
Parallelization 并行化 多个 LLM 同时工作并聚合输出
Orchestrator-Workers 协调者-工作者 中央 LLM 动态分配任务给工作者
Evaluator-Optimizer 评估器-优化器 生成-评估循环迭代
Augmented LLM 增强的 LLM 具备检索、工具、记忆能力的 LLM
MCP 模型上下文协议 连接 AI 与数据源的开放标准
ACI 智能体-计算机接口 Agent 与工具交互的接口设计
HCI 人机界面 Human-Computer Interface
Guardrails 护栏 防止 AI 产生不当输出的安全机制
SWE-bench 软件工程基准 评估 AI 解决真实 GitHub Issue 能力的基准
Poka-yoke 防错 日语术语，通过设计使错误更难发生

✅ 实战检查清单

❓ 常见问题

Q: 智能体和聊天机器人有什么区别？
A: 聊天机器人只能对话，智能体能调用工具、执行操作、自主决策并从环境反馈中学习。

Q: 需要什么前置知识？
A: 了解 LLM API 调用和基本的 Python 编程即可。如果用过 Claude 或 OpenAI 的 API，就足够了。

Q: 应该先用框架还是直接用 API？
A: 建议先直接用 LLM API。很多模式只需几行代码。使用框架时，确保理解底层代码。

Q: 5 种工作流模式必须按顺序使用吗？
A: 不需要。它们是独立的构建块，可以单独使用或组合使用。根据任务选择最合适的。

Q: 自主智能体太贵了，有没有省钱的方法？
A: 有。先用简单提示试试，不行再考虑工作流，最后才用自主智能体。还可以通过路由把简单问题分给小模型。

Q: 如何评估智能体的效果？
A: 定义明确的成功标准，在沙盒环境中测试，监控延迟和成本，用人工审查补充自动化评估。

posted @ 2026-08-12 01:29  johnsong2008  阅读(5)  评论(0)    收藏  举报