AI 智能体从入门到进阶再到落地完整教程

如果你关注了 2025 年的 AI 动态，可能已经注意到每个人都在谈论"智能体（Agents）"。这是有充分理由的。AI 智能体可以处理从简单的日常任务到企业级规模的复杂多智能体工作流等各种事务。

而这仅仅是个开始。我们将在这个领域看到更多的创新。

如果你是第一次来这里，我是 Marina。我是亚马逊的一名高级应用科学家，致力于生成式 AI（Gen AI）的研究。今天，我将为你拆解关于构建和使用 AI 智能体你需要知道的一切。

我对这个话题进行了深入研究。我参加了许多不同的课程，阅读了大量书籍，并构建了自己的智能体。我的研究笔记最终长达约 150 页，而通过这篇文章，我将所有这些精华提炼出来分享给你。

我们将按以下方式进行拆解：

• 首先是基础篇。 什么是 AI 智能体，它的核心概念是什么，以及你实际上可以在哪里使用它们？如果你想在不写代码的情况下开始尝试的话，我们还将涵盖一些无代码（no-code）选项。
• 然后是进阶篇。 我们将深入探讨如何构建和评估能够解决实际问题的多智能体系统。我将演示一个我自己制作的智能体系统，它目前每周能为我节省几个小时的工作时间。
• 接着是高级篇。 在生产环境中构建可靠的智能体系统到底需要什么？
• 最后是彩蛋部分，专为那些想要深入挖掘并理解像 Claude Code 这样的工具在底层到底是如何运作的开发者准备。

无论你是试图自动化自己工作流程的非技术人员，还是正在为公司构建生产级 AI 系统的开发者，这篇文章都能帮到你。

下面就开始。

入门篇 (BEGINNER)

什么是智能体？

我们从基础开始：到底什么是 AI 智能体？

最简单的理解方式是这样的。想象一下你需要写一篇文章。如果你使用传统的 LLM（大语言模型）提示词，你基本上会说："嘿 ChatGPT，给我写一篇关于如何开始健身的文章"，然后它会一口气从头到尾写完整篇内容。

但这并不是我们实际写文章的方式，对吧？我们不会一次性就写出完美的初稿。我们会计划、列提纲、做一些研究、写一个粗糙的草稿、通读并修改。这是一个过程。

这就是代理式 AI（agentic AI）所做的。与其要求 AI 在一次线性操作中完成所有事情，不如让它像人类一样迭代地工作。

那么这实际上看起来是什么样的呢？

让我们继续用写文章的例子。智能体是这样处理的：

1. 首先，它从提纲开始。在动笔之前，它先理清结构。主要观点是什么？什么顺序是合理的？
2. 然后，它弄清楚需要从提纲中获取什么信息，并实际获取这些信息。
3. 它可能会搜索网络、从 API 拉取数据或下载相关来源，然后利用这些信息写出文章的初稿。

但最棒的部分是它并不止步于此。智能体会反思 自己的工作并进行修改，比如加强薄弱的论点、补充缺失的信息或改善流畅度。

这就是人们所说的 ReAct 循环 。模型推理（Reason） 下一步该做什么，行动（Act） （通常通过调用工具，我们稍后会讨论），观察（Observe） 结果，然后要么给你答案，要么循环回去再次推理。

这种方法之所以有效，是因为每一轮循环都增加了深度。我们获得了更强的推理能力、更少的幻觉（hallucinations）和更好的组织结构，而这些都是试图一次性完成所有事情时容易丢失的东西。

这种方法非常适用于需要严谨、准确且有适当来源引用的工作。可以想想法律研究（需要引用具体案例）、医疗文档或需要在回复前查询账户详情的客户支持系统等领域。

当然，额外的专业化和准确性也带来了复杂性的成本。这就引出了一个显而易见的问题：哪些任务实际上值得构建智能体来完成？

智能体适合什么样的任务？

有些任务适合智能体，有些则不适合。让我们看一些例子，从最简单到最复杂。

• 一个非常简单的智能体系统示例是从发票中提取关键字段，然后将其保存到数据库。像这样清晰、可重复的流程非常适合智能体。
• 中等复杂度的任务可能是回复客户邮件。智能体查找订单，检查客户记录，并起草回复供人工审核。
• 再高一级是全能客户服务智能体，处理诸如"你们有蓝色牛仔裤现货吗？"或"我该如何退货？"这类问题。对于退货，智能体需要验证购买记录、检查政策、确认是否允许退货，然后走完包含许多步骤的整个退货流程。智能体必须弄清楚步骤是什么，而不仅仅是照本宣科。

思考哪些用例适合智能体的一个好方法是使用一个包含两个维度的矩阵：复杂性 和精确度。

• 有些问题既具有高复杂性又需要高精确度，比如填写税务表格。
• 有些问题很复杂但不需要完美的准确性。在这种情况下，你可以考虑像编写和检查讲座笔记摘要这样的任务。

最大的价值通常来自于高复杂性 的工作，而最早期的快速成功往往出现在较低精确度的一侧。这就是为什么"高复杂性、低精确度"的象限通常是明智的起点。我们可以利用自动化处理棘手的事情，而不会因为每次都需要完美的输出而受阻。

总结一下，当任务需要迭代 、研究 或多步骤流程时，智能体真的能大放异彩。从那些能容忍稍低准确性的复杂任务开始通常是有意义的。

自主性谱系 (Spectrum of Autonomy)

好了，既然你知道了智能体擅长什么，让我们谈谈如何进行构建。你需要做的第一个重大决定是：你想给你的智能体多少自主权？

把这看作一个谱系。

• 在一端，我们有脚本化智能体（Scripted Agents） ，硬编码每一个步骤。比如对于我们的文章写作示例，可能是：先生成搜索词 -> 调用网络搜索 -> 获取页面 -> 然后写文章。结束。这是确定性的、可预测的且易于控制的。模型唯一的工作是生成实际文本，因为我们已经决定了其他一切。
• 在另一端，我们有高度自主的智能体（Highly Autonomous Agents） 。现在 LLM 决定是搜索 Google、新闻网站还是研究论文。它弄清楚要获取多少页面，是否转换 PDF，以及是否进行反思和修改。它甚至可能编写新函数并运行它们。这更强大，但也更不可预测且更难控制。

在实践中，大多数现实世界的智能体处于中间位置，即半自主。智能体从我们定义的工具中进行选择，并在你设置的安全护栏内做决定。

上下文工程 (Context Engineering)

但是，智能体怎么知道有哪些工具可用或如何做决定呢？

这被称为"上下文工程"，即我们决定智能体拥有什么信息。这包括任务背景、智能体的角色、过去行动的记忆以及可用的工具等内容。

如果把所有这些上下文放在一起，这个上下文会将非确定性的模型引导向一致的、高质量的输出。

这就是智能体"智能"的实践基础。不仅仅是模型本身，而是你如何围绕它构建上下文。我们在整个课程中会更多地讨论这些组件。

任务分解 (Task Decomposition)

一旦智能体有了它的上下文，就该定义它应该做的任务了。弄清楚这些任务可能是你关于构建智能体所学到的最重要的事情。

从如何做这项任务开始。然后对于每一步，问自己："LLM 能做这个吗？一小段代码能做吗？一个 API 能做吗？"如果答案是否定的，就把它拆解得更小，直到可以为止。

我们继续用构建一个写文章的智能体为例。 想想你实际上会怎么写，然后弄清楚 AI 可能如何完成该任务。它可能会像这样：

1. 列提纲（使用 LLM）
2. 生成搜索词 （使用 LLM），然后调用搜索 API
3. 获取页面（使用工具）
4. 写初稿（使用 LLM，基于上述来源）
5. 自我批判草稿（使用 LLM 反思并列出差距）
6. 修改（使用 LLM）

每一步都是微小的、可检查的和清晰的。当输出不够好时，我们明确地知道哪一步需要改进。

进阶篇 (INTERMEDIATE)

评估 (Evaluation)

好了，现在我们掌握了基础知识，正进入进阶领域。

我们将从一些非常枯燥的事情开始。但是，这是区分业余爱好者和专业人士的关键：你如何衡量其性能。

有时，评估可以简单到测量输出正确的次数。如果我问我的客服聊天机器人是否有某种商品库存，它回答对了吗？

但并不是所有事情都那么界限分明。让我们想想我们的文章写作智能体。如何衡量文章实际上是否好？

一种方法是使用第二个 LLM 来判断输出。让它使用一致的评分标准对每篇文章的质量进行 1 到 5 分的评分。

可以在组件级别 评估系统，以确保每个单独的步骤都有效；也可以进行端到端评估，以判断整个系统的最终质量。

如果发现系统运作不如预期，第一步是检查中间步骤，这被称为追踪（trace） 。这包括智能体编写的搜索查询、草稿和思考步骤等内容。如果通读这些内容，你可能会注意到一些模式，比如过于笼统的查询，或者修改步骤没有正确采纳批评意见。

这些观察结果将成为我们接下来的评估点或修复点。

重要的是要立即开始评估，但也不要担心一开始就要拥有完美的评估系统。可以先让它跑起来，然后随着时间的推移进行迭代。

记忆 (Memory)

现在我们建立了一个简单的系统，也有了一些衡量性能的方法，是时候实际着手提高性能了。记忆是一个非常常用的方法。

记忆让智能体记住什么有效、什么失败了以及下次该做什么改变，从而在每次运行时都能通过短期记忆 （智能体边做边记录）和长期记忆来实际改进。在多智能体系统中，其他智能体可以读取这些笔记。智能体完成任务后，可以反思它做了什么，将结果与预期进行比较，弄清楚什么做得好、什么做得不好，并将这些教训存储在长期记忆中。

下次运行时，它会加载这些教训并加以应用。

这可以用来"训练"智能体，类似于监督学习。我们可以对智能体的工作给予反馈，这样随着时间的推移，每次运行的质量都会提高。我将在本节末尾的演示中展示这一点的例子。

所以，记忆是动态的，并且在每次运行时更新。知识（Knowledge） 则不同，它是你预先加载的静态参考资料。PDF、CSV、文档或对数据库的访问权限。你给智能体一次，它就可以在需要引用准确信息时从该库中提取。

安全护栏 (Guardrails)

一旦我们将智能体与其任务、知识和记忆设置好，它就可以彻底放飞自我了吗？

不完全是。还有一个我们没谈到的非常重要的步骤。

因为 LLM 是非确定性的，它们可能会犯错。也许它们写了一些事实上错误的东西，或者格式不对。

为了防止问题发生，我们需要向系统添加安全护栏。 护栏基本上是位于"智能体说完成了"和"任务实际最终化"之间的质量关卡。

护栏主要有三种方法，大多数生产系统至少使用两种。

1. 对于像输出格式和长度这样的确定性内容，我们可以直接使用标准代码片段 。这些既快又便宜，应尽可能优先使用。
   
2. 有时我们在检查更微妙的东西，比如"这个回复与来源在事实上一致吗？"或"语气积极且专业吗？"
   
   在这种情况下，我们可以使用另一个 LLM 来判断输出。如果 LLM 裁判说"不，这不合格"，它会解释原因。该反馈会被发送回你的智能体，智能体进行修改并重试。
3. 最后，有时你只需要人工检查工作。 与其让智能体自动完成并发布结果，你可以让它停下来先请求批准。你可以给出反馈并要求智能体重试。

设计模式 (Design Patterns)

好了，我们已经涵盖了很多关于如何让系统运作的内容。现在让我们谈谈如何让系统质量更好。

有四种核心模式可以可靠地提升质量和能力：反思、工具使用、规划和多智能体协作。

让我们从最简单也是最有效的开始：反思。

1. 反思 (Reflection)

简而言之，反思基本上意味着我们不止步于初稿。 当你使用反思时，模型生成一些东西，批判它，然后根据需要重写。这第二轮------由要求它发现并修复问题的提示词引导------几乎总是让结果更好。

让我给你展示一个关于邮件的快速示例。

• 版本 1（初稿）： "嘿，我们下个月见面讨论项目吧。谢了"

  • 这有什么问题？日期模糊（"下个月"），没有签名，"谢了"感觉很突兀。

• 反思步骤： 模型阅读 v1 并发现这些问题------时间线不清楚，缺少落款，语气感觉仓促。

• 版本 2（修改后）： "你好 Alex，我们能不能在 1 月 5 日至 7 日之间见面讨论项目时间表？请告诉我你的时间。祝好，Marina"

  • 内容相同，但更干净、更具体、更专业。

反思在代码方面变得非常强大，因为我们可以添加外部反馈。可以编写代码，让批评智能体审查它，然后实际运行它。这样我们可以捕获错误、测试结果和输出，并将这些反馈回模型。模型可以使用这些具体信息来生成更好的 v2。

在有结构化输出（如 JSON）、程序化指令（如泡茶的步骤，反思可以捕捉遗漏的步骤）、创造性工作和长篇写作时，反思特别有用。 特别是在你整合外部反馈时，反思效果很好。比如在 JSON 上运行模式验证器，或在研究任务中检查缺失的引用。

缺点是它增加了延迟和成本，因为你在进行多轮操作。所以，务必测试带反思和不带反思的情况，以确保它确实有帮助。

2. 工具使用 (Tool Use)

好了，让我们谈谈第二个设计模式：工具使用。

核心思想是：你给 LLM 一个它可以调用的函数清单。可以是网络搜索、数据库查询、代码执行、日历访问或应用程序需要的任何东西。然后模型决定何时以及使用哪些工具。

这很重要，因为 LLM 本身只是一个文本生成器。它不知道现在几点了，也不知道你公司的销售数据。它不能执行代码来计算精确答案。 但是如果你给它工具，它就可以做诸如搜索网络、查询数据库、写入 CRM 或运行代码之类的事情。

所以如果我问智能体"现在几点了？"，LLM 调用 getCurrentTime() 函数，得到"3:20 PM"，然后用这个回复。

或者我们可能会要求它搜索当地餐馆、查询数据库或做数学计算。在每种情况下，模型识别出它需要外部信息或计算，选择正确的工具，并使用结果来回答。

在给模型多个工具时，它可以将它们串联 起来。例如，假设我们正在构建一个日历助手。我们暴露了三个工具：checkCalendar（查日历）、makeAppointment（预约）和 deleteAppointment（删除预约）。

用户问："帮我安排本周与 Alice 的会议。" 模型思考步骤：

1. 检查我的日历看是否有空------看起来周四下午 3 点可以。
2. 调用 makeAppointment，参数为 Alice 和那个时间。
3. 向用户确认。

这里的关键是 LLM 根据从上一个工具的输出中学到的内容，选择下一个要调用的工具。这不是一个固定的管道------它是动态的。

好的，但也有一件事：LLM 只生成文本。它们不执行代码。那它们怎么"调用"函数呢？ 实际上它们不调用。它们请求一个函数调用。

这是底层循环：

1. 用户发送一个提示词。
2. LLM 查看其可用工具并决定是否需要一个。
3. 如果需要，它输出一个特殊请求，如"我想调用 getCurrentTime，时区为东八区"。
4. 代码看到该请求，实际运行该函数，并获得结果。
5. 将该结果作为新的上下文反馈给 LLM。
6. LLM 使用它来完成回答------或者如果需要，请求另一个工具。

就这么简单。LLM 请求但不实际执行代码。

设计好的工具 为了让 LLM 能够找到并请求工具，我们需要一种一致的方式来定义它们。每个工具都有两部分：

1. 智能体的接口。 这包括工具名称、何时使用它的简单英语描述，以及类型化的输入模式（schema）。 例如："ReadWebsiteContent"，描述为"获取并返回网页文本"，有一个输入：url (string)。
2. 实现代码。 任何需要的东西，如 SQL 查询、身份验证、重试、限流和解析。

智能体只看到接口。所有混乱的实现细节都被隐藏了。

好的工具还会考虑错误处理、自我恢复和速率限制等问题。它们可能会使用缓存来记住相同输入的结果，以减少延迟、成本和外部 API 负载。并且它们应该有异步支持，以便当前智能体（或其他智能体）可以在长工具请求完成时继续工作。

工具应该像产品一样构建，具有版本控制、适当的文档和充分的测试。维护一个内部注册表，其中包含经过审查的工具及其文档、版本和所有权，是很有用的。

把所有这些放在一起，你就给了你的智能体与世界互动的方式。这太酷了！但我们需要确保智能体知道它在现实世界中需要做什么，这就引出了第三个设计模式：规划。

3. 规划 (Planning)

规划的想法是：与其硬编码固定的步骤序列，不如让 LLM 决定做什么以及按什么顺序做。

假设你正在为一家零售店构建客户服务智能体。可以为每种情况硬编码流程："如果是价格问题，做 X。如果是退货，做 Y。如果是库存，做 Z。" 但是当有人问了一些你没预料到的问题时会发生什么？或者同一个问题根据上下文需要不同的步骤时？

有了规划，你给智能体一个函数工具箱，如 get_item_descriptions、check_inventory、get_item_price、process_return，并让它弄清楚何时使用哪些工具。

基本循环如下：

1. 给智能体访问工具的权限。
2. 提示它创建一个计划："列出回答这个问题的分步行动"。
3. 一步一步执行计划------LLM 选择正确的工具，你运行它，反馈结果。
4. 重复直到完成。

这基本上是"计划 → 行动 → 观察 → 继续"，但是用的是我们自己的工具。

具体例子：零售太阳镜 用户问："有 100 美元以下的圆形太阳镜现货吗？" 智能体可能规划：

• 步骤 1：使用 get_item_descriptions 查找圆形镜框。
• 步骤 2：对该列表运行 check_inventory。
• 步骤 3：对现有库存商品调用 get_item_price 并筛选出 100 美元以下的。
• 步骤 4：撰写答案。

我们没有预定义这个具体方案。LLM 从可用工具中选择了它。

现在来了个不同的问题："我想退掉我买的金框太阳镜，不是金属的那副。" 在这种情况下，计划完全改变：

• 步骤 1：识别用户之前的购买记录。
• 步骤 2：匹配金框产品。
• 步骤 3：调用 process_item_return。
• 步骤 4：确认结果。

要求模型输出 JSON 格式的结构化计划会很有帮助。

或者，你可以让它编写实际代码，通常是编码了整个计划的 Python 代码。

规划需要注意的事项

规划增加了自主性，这意味着它也增加了不可预测性。我们需要在权限、工具调用验证以及管理一步输出传递到下一步等方面设置安全护栏。

今天，规划最强的用例是高度代理式的编码系统。模型将编程任务分解为步骤并逐一解决。 对于其他领域，规划绝对有效，但更难控制，因为你不知道模型会创建什么计划。不过，工具和安全护栏正在快速改进，采用率也在增长。

但是如果有一个系统需要做很多不同的事情，甚至可能同时进行呢？这就是多智能体协作发挥作用的地方。

4. 多智能体 (Multi-Agent)

想想在现实生活中如何处理一个复杂的项目。我们不会雇佣一个超级通才来做所有事情。而是会建立一个团队。有在特定领域非常擅长的专家，他们互相移交工作。

多智能体系统借用了同样的思维方式。 每个智能体都有明确的角色。每个都专注于它擅长的事情。输出更好，因为你在每一步都有专业化分工。

除了专业化，多智能体系统还有其他优势：

• 它避免了任何单一智能体拥有巨大的上下文窗口。
• 可以使用多个 LLM。可以混合使用更快、更便宜的模型来处理高容量的简单任务，而保留更大、能力更强的模型用于策略、微妙的客户回复或长篇写作等精确任务。这在成本和性能上都给了你灵活性。
• 可以并行化工作。
• 如果有非常长时间运行的操作，可以拆分工作，并查看哪些智能体正在处理什么，以帮助用户了解正在发生的事情。

如果有一个简单的任务，跳过多智能体系统。它们会减慢速度并使调试更加困难。

这是因为多智能体系统引入了一层全新的复杂性。如果两个智能体试图修改同一个文件，你可能会遇到资源冲突；智能体之间有通信开销；还有复杂的任务依赖关系。还有像 API 速率限制这样的问题，以及如果一个智能体失败了该怎么办------其他的继续吗？还是回滚？如何将多个智能体产生的内容合并成一个连贯的输出？

这并非不可管理，但我们需要为此进行设计。需要强大的编排、良好的错误处理以及智能体如何通信的清晰协议。

多智能体系统设计

那么让我们多谈谈如何设计这些多智能体系统。让我们用制作营销手册的例子来说明我们的选项。

角色模型 (The Roles Model)

第一步是按角色定义你的智能体。每个智能体都有明确的工作描述，并且只拥有它做那份工作所需的工具。

对于我们的营销手册，可能有：

1. 研究员智能体，负责查找市场趋势和竞争对手动向。该智能体可能拥有网络搜索、检索和笔记工具。
2. 平面设计师智能体，负责创建图表和视觉资产，拥有图像生成、图像处理或绘制图表的代码执行工具。
3. 撰稿人智能体，负责将发现和资产转化为最终文案。该智能体可能只是 LLM 本身，无需外部工具。

通过提示词来实现每个智能体，赋予其角色，比如"你是一名专门从事市场分析的研究员智能体"，并只给它该角色应有的工具。

一旦定义了智能体，需要决定它们如何通信。有四种主要模式，我们将从最简单到最复杂进行讨论。

模式 1：顺序 (Sequential)

这是最简单和最可预测的。每个智能体完成其工作，然后将输出传递给队列中的下一个智能体。

对于我们的手册，它可能看起来像这样：研究员完成 → 交给设计师 → 设计师完成 → 交给撰稿人 → 完成。 它就像一条装配线。它易于调试，并且具有可预测的时间和成本。 这是适合上手的方式。根据具体用例，这可能就足够了。

模式 2：并行 (Parallel)

但顺序并不是唯一的选择。当步骤互不依赖时，你也可以并行运行智能体，这对于减少延迟非常棒。

例如，研究员和设计师可以同时处理手册的独立部分，然后撰稿人合并他们的输出。 这加快了速度，但增加了协调的复杂性。

模式 3：单一管理者层级 (Single Manager Hierarchy)

如果开始进入更复杂的工作流，添加一个管理者智能体来进行规划和协调会很有帮助。专家智能体做他们的工作并向管理者汇报，而不是互相汇报。

这在保持控制紧密的同时给了我们灵活性。管理者可以重新排序步骤，跳过不需要的事情，或要求智能体返工。它比线性流程更具适应性，又不会混乱。 这可能是今天生产环境多智能体系统中最常见的模式。

对于更复杂的工作流，可以有更深的层级结构，其中一些智能体管理它们自己的子智能体。

例如，你的研究员智能体可能编排一个"网络研究员"子智能体和一个"事实核查员"子智能体。你的撰稿人智能体可能有"风格撰稿人"和"引用检查员"在它下面工作。这对非常复杂的任务很有帮助，但当然会增加更多的混乱。

模式 4：网状模型 (All-to-All / Free-for-All Chat)

最后，我们要谈网状模型，这可能会超级混乱。在这个模型中，任何智能体都可以随时向任何其他智能体发送消息。这在生产环境中很少见，因为它很难预测和控制。输出可能会在每次运行时差异巨大。

但它对于更头脑风暴、创造性或低风险的任务可能有效。比如生成多个广告文案变体，如果一次运行产生垃圾，你可以直接重试。

协调陷阱

我们已经谈过几次协调的挑战。这里有两个最常见的陷阱。

1. 重复工作。 多个智能体可能会重复相同的搜索或调用相同的工具。这可以通过收紧任务范围和在智能体之间进行明确的分工来解决。
2. 不必要的串行化。 链接那些可以并发运行的步骤会减慢一切。为了解决这个问题，识别真正独立的任务并异步运行它们，然后只路由下一步所需的上下文片段。

一般来说，要从能用到的最简单的协调方式开始，只有在需要时才增加复杂性。

最佳实践

无论选择哪种模式，在设计系统时都要记住以下四个关键最佳实践：

1. 定义接口，而不是凭感觉（Define interfaces, not vibes）

   每个智能体都需要清晰的输入和输出模式（schema）。它需要知道诸如：什么字段？什么类型？传递什么 ID 或引用？ 撒手不管比模型本身更容易崩溃。如果你的研究员返回一个非结构化的数据块，而你的设计师不知道如何解析它，整个系统就会失败。

2. 按智能体限定工具范围

   只给每个智能体它实际需要的工具。最小权限访问。 这有助于安全性，并使系统更容易推理、更容易审计和更容易调试。

3. **记录追踪（Log the trace）

   **保留每一步的执行。每个智能体计划了什么？它使用了什么提示词？它做了什么工具调用？返回了什么结果？ 当出现问题时，这种追踪使错误分析变得快速。我们可以确切地看到哪里出了问题。

4. **评估组件以及端到端

   **需要两种类型的评估：

   • 组件级： 研究相关吗？图像质量高吗？文案语气合适吗？
   • 端到端： 最终手册好吗？它符合要求吗？ 如果你的端到端评估显示有问题，但组件评估看起来都很好，就能知道这是一个放手或集成问题。如果特定的组件评估失败，就知道该改进哪个智能体。

高级篇 (ADVANCED)

好了，欢迎来到高级部分。如果你已经到了这里，说明你是认真想要构建可以在现实世界中工作的真实智能体系统。

从零到原型的技术无法实现从原型走向生产。我们需要不同的工具、不同的思维方式和更多的规则。 下面进入这部分内容。

多智能体系统的高级任务分解

我们已经讨论过任务分解。但是在使用多智能体系统时，这会变得越来越复杂。

有四种主要模式可以指导你做好这件事。（顺便说一句，内容改编自这篇很棒的博客------可以阅读获取更多详情！）

模式 1：功能性分解 (Functional Decomposition)

在这种模式下，我们将任务按技术领域或专业知识拆分。这就是我们在之前的例子中一直在使用的------按需要完成的工作类型来拆分任务。

例如，可以考虑全栈功能开发。有前端工作、后端逻辑、数据库修改改，可能还有 API 更新。每一个都需要不同的知识和不同的工具。所以可以创建专门针对每个领域的智能体。

模式 2：空间性分解 (Spatial Decomposition)

也可以按文件或目录结构拆分。在处理具有许多可以独立处理的文件的大型代码库时，这尤其强大。

假设我们正在进行大规模重构------也许是将所有 API 端点更新到新的身份验证系统，并且有几十个跨越不同服务的文件。 可以进行空间分解：

• 智能体 1 处理 /services/users/*
• 智能体 2 处理 /services/orders/*
• 智能体 3 处理 /services/payments/*
• 智能体 4 处理 /services/notifications/* 在这种情况下，通过确保智能体在代码库的独立部分工作来最大限度地减少冲突。它们可以并行工作。但是如果文件彼此有复杂的依赖关系，空间分解就会失效。

模式 3：时间性分解 (Temporal Decomposition)

模式 3 是关于将任务分解为顺序阶段，后续阶段依赖于早期阶段的完成。

让我们以产品发布为例。你不能某天醒来就开始发送促销邮件。有一个逻辑顺序：

• 阶段 1：市场研究 --- 分析竞争对手，调查目标客户，确定定位机会
• 阶段 2：发布计划 --- 定义信息，设定定价，创建时间表，确定渠道
• 阶段 3：资产创建 --- 撰写文案，设计图形，构建着陆页，准备邮件序列
• 阶段 4：发布与监控 --- 执行活动，跟踪指标，回应反馈，实时调整

每个阶段都有自己的智能体或智能体团队。阶段 2 直到阶段 1 完成并审核通过后才开始。

模式 4：数据驱动分解 (Data-Driven Decomposition)

最后，我们可以按数据分区拆分。这种不太常见，但对于某些用例非常强大，特别是涉及可以分区并独立处理数据块的大型数据集的任务。

假设我们正在分析应用程序日志以识别性能问题。有上个月的千兆字节日志。 可以按时间或按服务分区：

• 智能体 1 处理第 1 周日志
• 智能体 2 处理第 2 周日志
• 智能体 3 处理第 3 周日志
• 智能体 4 处理第 4 周日志

每个智能体独立运行分析，然后在最后汇总结果。

也可以混合使用这些模式。例如，一个全栈功能可能使用功能性分解 作为主要结构（前端、后端、数据库），但后端智能体在内部使用时间性分解（设计 API → 实现逻辑 → 添加测试）。

提升质量 (Improving Quality)

好了，到目前为止，假设我们有了一个工作系统，我们做了全面的评估以查找错误，但我们仍然对性能不满意。应该这么做：

首先要理解的是，在处理两种根本不同类型的组件，它们需要不同的改进策略。

1. **非 LLM 组件

   **这些是诸如网络搜索、RAG 检索、代码执行、语音识别、视觉模型、PDF 解析器之类的东西。 改进这些主要有两种方法：

   • 调整参数 (Tune the knobs)。 调整网络搜索日期范围、top-k 结果、RAG 分块大小、相似度阈值等。
   • 或者，更换提供商。 尝试替代的网络搜索 API。不同的 OCR 或视觉模型等等。

2. **LLM 组件

   ** 这些用于生成、提取、推理------任何你使用语言模型本身的地方。 我们可以做很多事情来改进这部分：

   • 更好地提示。 添加明确的指令、约束、模式（schemas）。使用少样本（few-shot）输入-输出对来向模型展示你想要什么。
   • 尝试另一个模型。 一些模型更擅长遵循指令，另一些擅长代码或事实回忆。不要假设一个模型最适合所有事情。
   • 将困难任务分解为更小的部分。
   • 作为最后手段进行微调 (Fine-tuning)。 微调很强大但成本高昂。把它留给成熟的系统，当你需要最后那几个百分点的质量提升并且已经用尽了其他所有方法时再用。

降低延迟 (Reducing Latency)

搞定输出质量应该是你的第一步。在那之后，让我们谈谈降低延迟。

1. **建立基线
   **第一步是为工作流中的每一步计时。你可能会发现，LLM 生成搜索词需要 7 秒。网络搜索需要 5 秒。起草文章需要 11 秒，依此类推。 这给了你一个基线，让你知道应该优化什么。
2. **并行化
   **接下来，并行运行任何可以同时运行的部分。比如网络获取、多次搜索或解析多个文档。这通常是最容易的胜利。
3. **调整模型大小
   **在任务简单的地方（如关键词生成）使用更小、更快的 LLM，并将重量级模型保留用于综合和推理。
4. **尝试更快的提供商
   **吞吐量和 token 流式传输速度差异很大。在不更改任何提示词的情况下，使用具有优化服务的提供商可以减少数秒时间。
5. **最后，削减上下文
   **更短的提示词和上下文意味着更快的解码，所以尽量只保留该步骤真正需要的内容。

降低成本 (Reducing Cost)

随着质量提高和延迟得到控制，要开始关注成本了。首先，要像测量延迟一样测量每一步的成本。

智能体系统有几个成本来源：

• LLM 调用： 由输入 token 和输出 token 决定。这些通常分开定价（输入 token 较便宜，输出 token 较贵）。
• API 调用： 诸如网络搜索、PDF 转换、图像生成、语音转文本。这些通常有按次调用或按单位计费的定价。
• 基础设施： 如果你运行自己的检索系统、向量数据库或代码执行计算资源。

假设我们正在构建一个写文章的研究智能体。这是一次运行可能的成本：

如果每天运行 1,000 次，那就是 80 美元/天或 2,400 美元/月。

一旦知道每一步的成本，可以如下优化：

1. 首先从大头下手。 如果网络搜索每次调用花费 2 美分，而每次运行调用 10 次，那就是 20 美分。尽最大努力减少调用、缓存结果或批量查询。
2. 模型分层。 对简单的任务使用便宜的模型，仅在真正重要的地方使用前沿模型。
3. 主动缓存。 确定性的结果，如搜索响应、嵌入（embeddings）、分块检索或中间摘要，不应每次都重新计算。
4. 约束输出。 要求结构化、简洁的结果，使用诸如"返回包含这些必填字段的 JSON"、"最多给我 5 个要点"的指令。更少的 token，更低的账单。
5. 批量处理。 如果在处理许多相似的项目，尽可能打包操作。例如，在 AWS 上，批量处理的成本是按需处理的 50%。

可观测性和监控 (Observability and Monitoring)

有了一个质量、延迟和成本都基本满意的系统。现在我们需要确保它在规模化后继续按预期运行。

这就是监控和可观测性发挥作用的地方。可观测性涵盖调试能力、质量监控和幻觉追踪。基本上，任何帮助你观察智能体行为和性能的东西。

棘手的是，AI 系统的可观测性与传统软件根本不同。 对于传统软件，你可以追踪清晰的执行路径。函数 A 调用函数 B，函数 B 查询数据库，返回数据，渲染页面。诸如此类。

AI 系统不这样工作，原因有很多：

• 它们是非确定性的。相同的输入可能基于模型响应产生不同的输出。不能只是重放请求并期望相同的结果。
• 它们具有分布式执行，工具并行运行，智能体生成子智能体等等。
• 有许多具有潜在故障点的外部依赖关系，这些都在你的控制之外。
• 还有更多！

为了管理这一切，我们需要两种可见性：

1. "放大（Zoom-in）"指标
   帮助我们调试单次运行。这是完整的追踪（trace） ：提示词、工具调用、token 使用量、重试尝试和每个决策点。基本上是重现错误并确切查看哪里出错所需的一切。
2. **"缩小（Zoom-out）"指标
   **告诉我们整个系统在多次运行中的表现。这包括自动质量检查（通常使用 LLM 作为裁判）、幻觉率、成功/ROI 衡量标准，以及显示更改是有帮助还是有害的趋势线。

不仅要记录智能体做了什么，还要记录为什么做。例如，可能会记录："智能体选择使用网络搜索而不是 RAG，因为查询包含'最近'"或"反思通过程发现了 3 个问题：缺失引用、日期模糊、语气错误"。

在同时运行成千上万个智能体时，我们无法手动观察每个追踪。这就是质量抽样发挥作用的地方。与其深入检查每一次执行，不如定义一个抽样率------比如总运行次数的一定百分比------进行质量和幻觉评估。然后系统使用该执行子集来计算智能体的总体质量得分和幻觉得分。 这让我们能够优先考虑修复和改进的领域。

除了技术指标，还需要了解用户行为。

• 人们实际上在问什么？ 他们是在按预期使用你的智能体，还是找到了创造性的变通方法？
• 他们在哪里卡住了？ 他们是否重述并重试？这是第一次尝试没起作用的信号。
• 他们用输出做了什么？ 如果他们立即要求修改，说明初始质量不够好。
• 会话有多长？ 非常短的会话可能意味着快速成功或立即失败。非常长的会话可能意味着智能体有能力但效率低下。

这些定性数据与技术指标一起指导我们的产品路线图。

安全性 (Security)

最后，我们需要谈谈构建强大系统中如果不那么令人兴奋但最重要的部分之一：安全性。

就像可观测性一样，AI 智能体的安全性也不像传统的应用程序安全性。你不仅仅是防御外部攻击者------实际上你必须防止你自己的系统做出危险的决定或被操纵采取有害行动。

这些是需要注意的事情：

• 提示词注入 (Prompt injection)： 用户输入或外部数据中的恶意内容劫持了你的智能体指令。
• 不安全的代码生成： 智能体编写访问敏感数据或执行危险操作的代码。
• 数据泄露： 个人身份信息 (PII) 或专有信息通过智能体输出或工具调用泄露。
• 资源耗尽： 智能体启动昂贵的操作或无限循环。

我们来特别深入探讨一下代码执行。代码执行是智能体的终极工具。它极其强大，因为智能体可以编写代码来生成图表、创建 Markdown 文件、处理数据，通常可以在你给定的范围内做"任何它们想做的事"。 这是一把双刃剑。

许多任务可以通过定义良好的自定义工具来覆盖，所以系统并不总是需要回退到自由形式的编码。但在确实启用它们时，我信需要安全护栏。

安全地进行代码执行有如下步骤：

1. 沙盒执行。 使用 Docker 或受限的运行环境。将代码执行与主应用程序完全隔离。代码应该在每次执行后被销毁的容器中运行。
2. 资源限制。 设置超时、内存上限、CPU 限制。阻止危险的导入、网络访问（除非明确需要）以及指定临时目录之外的文件系统写入。
3. 仅允许白名单库。 只允许特定、安全的库，如 pandas、numpy 或 datetime。不允许任意安装。如果智能体需要一个库，你要显式地将其添加到白名单中。
4. 验证加反思循环。 如果代码执行出错，捕获回溯信息并让模型修复代码。给它一两次尝试机会，并确保你有熔断机制。
5. 确定性 I/O。 让代码返回一个小的、结构化的结果------一个数字、一个列表、一个 JSON 对象。然后你为用户格式化它。不要让代码直接向用户输出或写入他们可以访问的文件。
6. 还有输入和输出清洗，以便所有输入在到达智能体之前都经过验证，并且扫描所有输出以查找像 API 密钥或 PII 这样的敏感数据。

高级部分到此结束！有了所有这些，就可以构建扩展并在生产中服务用户的真实系统了。

彩蛋篇 (BONUS)

如前所述，我们还有一个为超级进阶者准备的彩蛋。

我们今天讨论的大部分内容都假设你使用的是像 LangGraph 或 CrewAI 这样的框架。但如果你是一个有兴趣了解像 Claude Code 这样代理式工具内部运作原理的开发者，我强烈推荐这篇关于代理式系统设计的博客：gerred.github.io/building-an...

它涵盖了诸如三个核心层（终端 UI、LLM"智能"层和工具层）、如何用异步生成器构建反应式命令循环、流式传输 + 工具调用的模式，甚至还有一个看起来很像 Claude Code 和 Cursor 底层驱动技术的并行执行引擎和智能工具调度（读 vs 写）。

翻译整理自：AI Agents: Complete Course From beginner to intermediate to production