DLAI-CrewAI-多智能体系统-II-笔记-全-

DLAI CrewAI 多智能体系统 II 笔记（全）

001：欢迎与课程概述 🚀

在本课程中，我们将学习如何使用 CrewAI 来设计、开发和部署强大的多智能体系统。本课程是与 CrewAI 的 Joemoura 合作构建的。当今 AI 领域最重要的技能之一，就是如何构建智能体工作流和多智能体系统，即：将一个复杂任务分解为子任务，由不同的专业化智能体执行。这让你能非常高效地构建相当复杂的工作流。

在本课程中，你将学习支撑你处理复杂任务的核心基础思维框架，以及如何将它们分解为多智能体系统。我们将探讨一些激动人心的示例，包括构建核心研究员和会议准备助手等。很高兴再次邀请到 Joe 与我们一同教学。

课程核心内容

上一节我们介绍了课程的整体目标，本节中我们来看看课程将涵盖的具体内容。

以下是本课程将深入探讨的关键主题：

• 构建生产就绪的系统：学习如何使用 CrewAI 框架，构建最终可投入生产环境的系统。
• 智能体与工作流：探讨如何使用智能体和流程来构建系统，如何跟踪性能，如何实现记忆功能。
• 系统控制与迭代：学习如何控制版本、监控追踪，并持续改进智能体。课程将引入许多新功能，例如低代码控制，让你能专注于构建智能体中有趣的部分。
• 从识别到实现：本课程不仅关乎识别用例，更关乎快速构建这些智能体并实现价值。这是本课程令人兴奋的原因之一。
• 实践经验分享：Joe 是多智能体系统领域的早期远见者，在它流行之前就开始构建 CrewAI。这意味着他拥有比地球上绝大多数人都要多的、大规模的、实用的、有价值的商业实施经验，并期待与你分享所有这些经验。

构建与部署流程

了解了课程内容后，我们来看看构建和部署一个多智能体系统的基本过程。

以下是思考和实现多智能体系统的基本步骤：

1. 识别机会：审视你的生活和工作，尝试识别哪些事情适合用多智能体系统进行快速原型设计和实验。
2. 快速原型：学习如何使用 CrewAI 快速构建原型，利用其工具、MCP 服务、网络搜索等功能。
3. 规模化部署：掌握将可能在你的笔记本电脑上运行良好的原型，扩展到数千甚至数万用户的关键经验，并尽量避免过程中的陷阱。

这个过程的挑战在于，多智能体系统的有趣之处在于其非确定性，智能体可以接入多种不同来源，不仅使用认知能力，还能自我修复、在运行时应对各种情况。但这不能以牺牲可靠、可重复的输出为代价，这是你需要关注的重点。

你将学到的具体技能

在概述了宏观流程后，本节我们聚焦于你将掌握的具体构建模块和技能。

以下是本课程中你将学习到的多智能体系统核心构建模块：

• 基础组件：不仅包括智能体、任务和团队，还包括如何通过记忆、工具（包括 MCP）、执行钩子和防护栏来自定义和优化你的智能体。
• 控制与优化：学习如何通过 CrewAI 的流程和状态添加一层低代码控制，这不仅允许你使用指标来评估应用，还能指导你如何利用人类反馈来训练智能体，并随时间改进你的应用。
• 生产实践：在最后一个模块，你将听到多家已在生产环境中使用多智能体系统和 CrewAI 的公司的经验分享。

即使这是你第一次接触智能体或 CrewAI，你也能从本课程中收获良多。如果你上过我们与 DeepLearning.AI 合作的早期课程，可以将本课程视为第三阶段，你构建的系统不仅追求规模，更追求质量和可靠性。

应对可靠性与规模化挑战

构建原型是一回事，确保其可靠并规模化是另一回事。本节我们来探讨这个核心挑战。

一个常见挑战是可靠性。我们常常可以为一个工作流快速构建一个原型，它在演示时对某个输入有效，在笔记本电脑上对10个输入也可能运行良好。但从10个例子到生产环境中的1000个，如果只有80%的可靠性，那实际上并不可用。关键在于突破“仅能在演示中工作”的阶段。

为了提升智能体的可靠性，有一系列措施可以采取，例如使用训练数据、防护栏、测试以及寻找合适的模型等。所有这些都将融入智能体的记忆功能中，我们将在课程中详细讨论。

智能体普及的关键

展望未来，智能体的使用只会日益增多。但要实现这一点，至少需要满足三个主要条件。

以下是推动智能体广泛普及的三个关键要素：

1. 极易启动：我们将探讨如何轻松构建这些智能体。
2. 值得信赖：这又回到了可靠和可重复结果的概念。
3. 易于管理：确保最终能够扩展到规模。规模化不仅关乎在流程中运行大量智能体，更关乎确保你构建的组件（如自定义工具甚至智能体本身）能够跨多个用例复用。

本课程的令人兴奋之处在于，它提供了一套严谨的流程：构建多智能体系统，思考可观测性机制以判断其运行状态，并驱动一个严谨的流程来快速识别错误，然后通过提示工程微调或其他工具进行修复。这套方法比大多数人意识到的更为可靠。掌握了这套知识，构建相当可靠的多智能体系统实际上并不像广泛认为的那么困难。

课程愿景与总结

当前，关于智能体 AI 和多智能体系统存在很多热议和炒作。面对这些纷杂的声音，我们合作创建了这门关于如何使用 CrewAI 构建多智能体系统的权威课程。

完成本课程后，你将理解其核心构建模块、思维框架、如何将它们组合起来，以及如何从原型设计一路走到将你的多智能体系统规模化部署。这将是一项非常强大的技能，我相信它将让你能够构建出比以往可能实现的更多东西。

认识 Joe 有一段时间了，我可以保证这门课程也会充满乐趣。我期待看到你用这些知识构建出什么。

本节课中，我们一起学习了本课程的目标、核心内容、构建流程、你将获得的具体技能，以及如何应对可靠性与规模化的挑战。本课程旨在为你提供从零到一构建并部署可靠多智能体系统的完整路线图。

内容很多，让我们进入下一个视频，正式开始学习。

002：课程概述 🚀

在本节课中，我们将一起了解这门课程的整体框架和学习目标。我们将探讨课程涵盖的核心主题，并预览一个实际的多智能体系统应用案例，为后续的深入学习奠定基础。

欢迎来到本课程的第一个模块。

我们将探讨关于AI智能体的一切知识。

我们将学习如何构建AI智能体，从原型设计一直到生产部署。

课程内容将非常精彩，你将学到所需的一切知识。

让我们直接开始，以便立即投入学习。

以下是你可以从本课程中期待的内容。我们将涵盖很多方面。

你将学习如何构建你的第一个多智能体系统并对其进行改进。但不仅仅是构建。

你将学习如何管理不同规模的AI智能体，从从小规模开始，到扩展并进入生产阶段。

我们还将讨论评估，以及如何衡量智能体系统的性能。

但我们不会止步于此。我们希望探讨围绕智能体正在形成的新技术栈这一理念。

同时，我希望聚焦于一些更大、更具影响力的实际用例。

以及现实世界中正在运行的内容。公司实际在做的事情以及它们是如何运作的。

最后，我们将进行总结。

将本课程中学到的所有原则应用到你的职业生涯中，如何将你将在本课程中学到的一切回归到你可以自己构建的用例中。

因此，我对此感到非常兴奋。本课程的许多重点将围绕你如何从概念上思考这些智能体。

以及如何以允许你进入生产阶段的方式对它们进行原型设计。

当你构思一个用例时，其概念本身可能极其简单。

但从概念到原型的距离却非常巨大。

而当你进入生产阶段时，这个距离甚至更宽。

现在，为了让你从最初的概念出发，不仅要实现用例本身，还要实现所有的平衡、检查、监控和可观测性。

如果你没有从一开始就考虑这些，后续可能会遇到问题。

在继续之前，让我们先看看一个功能齐全的生产级智能体团队是什么样子。更重要的是，一个你能够在课程结束时自己构建，并能帮助你日常工作的团队。

让我们以准备会议这个用例来思考。

你将与某人会面，可能是销售会议或合作伙伴会议，但你需要做好准备。何不使用智能体来完成呢？

假设你将与我见面，你想了解更多关于我的信息，并确保在我们见面时一切准备就绪。

那么，你基本上可以在这里输入我的邮箱，启动你的智能体群组，它们将为你完成所有的研究工作。

在研究方面，你可以看到它找到了关于我的所有信息，包括我拥有多年的工程经验、曾任职的公司以及我贡献过的一些文章。

在邮件方面，它查看了我（在此案例中）与自己交换的任何电子邮件以及其中可能包含的信息。

然后，它整合出这份最终的会议报告，让我有信心为会议做好充分准备，以应对任何情况。

现在，这只是一个相对简单的用例。在本课程中，我们将一起讨论和构建更为复杂的用例。

在这第一个模块中，我只想简要说明一下你可以期待的内容。

首先要讨论的是，AI智能体究竟是什么。

以下是AI智能体的关键组成部分：

• 大语言模型：智能体的“大脑”，负责理解和生成信息。
• 任务：智能体需要执行的具体工作单元。
• 智能体：执行任务的独立实体。
• 团队：协同工作的智能体集合。
• 工作流：定义任务和智能体之间执行顺序的流程。

我们将讨论如何思考智能体的“代理性”和控制，以及如何弥合概念、原型和生产之间的差距。

同时，我们将聚焦于AI智能体在现实世界中的用例和实际应用，以及大规模AI智能体生产的核心支柱。

最后，我们希望确保通过这个正在形成的、面向智能体系统的新技术栈的视角和背景来审视这一切。

我非常期待与你一起学习第一个模块。让我们抓紧时间，立即开始。

我们稍后见。

---

本节课总结

在本节课中，我们一起学习了本课程的总体概述。我们明确了课程将指导你从零开始构建、改进并最终部署多智能体系统。课程内容不仅涵盖技术实现，还包括系统评估、规模化管理和新兴技术栈。通过一个会议准备的实例，我们初步看到了多智能体系统的实际应用潜力。接下来，我们将深入第一个模块，具体探讨AI智能体的核心概念与组成部分。

003：什么是AI智能体 🤖

在本节课中，我们将要学习AI智能体的核心概念、工作原理以及它们与传统自动化系统的区别。我们将深入探讨智能体如何做出决策，并理解为何它们能实现更复杂、更灵活的任务自动化。

---

什么是AI智能体？

你可能对AI智能体有自己的定义。为了确保我们讨论的是同一概念，我们需要明确AI智能体的不同选项、其本质以及工作原理。在本节课程中，我们将详细探讨智能体的方方面面及其运作机制。

现在，让我们开始深入了解。

---

智能体的核心定义 🎯

关于AI智能体的讨论非常多。但在深入之前，我们先就其定义达成一致。

我的定义是：AI智能体是一个能够决定下一步行动以完成特定目标的系统。

让我们深入剖析这个定义。

---

智能体的基础：大语言模型（LLM）🧠

所有智能体的核心都始于一个大语言模型。在本课程中，你将看到如何为LLM添加各种工具、防护栏和控制机制，使其能够像智能体一样行动。

LLM非常擅长生成内容。如果你要求它写一封电子邮件，它会为你完成。如果你要求它写得更有趣，它至少会尝试。但更有趣的是，如果你为它提供选项。

例如，一个选项可能更严肃一些，另一个选项则略有不同。此时，LLM将进行选择，并告诉你版本A更好，因为原因A、B或C；或者版本B更好，因为原因1、2或3。

归根结底，正是这种做出合理选择的能力——我们称之为认知能力——使得这些模型能够判断哪封邮件更好。

---

从聊天到控制应用流程 🔄

现在，如果我们暂时忘记邮件，转而讨论一个商业目标或任务目标，并且由LLM实际决定为实现该目标需要采取哪些步骤，那么情况就完全不同了。

这时，我们就不再是简单的聊天了。现在，AI正在控制应用程序的流程，由这些LLM做出选择，以完成你为它们设定的最终目标。

---

为何需要关注AI智能体？💡

你可能会想，我为什么要关心这个？你应该关注AI智能体的原因在于，我们最终讨论的是自动化，而且是以前无法实现的自动化。

具体来说，它允许你构建非常复杂且灵活的自动化系统。

---

用例对比：传统自动化 vs. AI智能体 🤖

让我们通过一个客户支持聊天机器人的用例示例，来比较旧式自动化与当今AI智能体风格自动化的区别。

当你思考传统的自动化时，通常需要映射所有不同的分支路径。例如，有一个起点A（客户输入），它会带你到点B（显示帮助文章）。但这并非唯一的路径。当你深入思考这个用例时，你会发现其中涉及更多环节。

点C出现了，你需要检查用户登录状态。然后点D出现了，你需要查看用户是否能访问购买记录。你可能还会添加其他升级点。你可以看到，随着添加所有这些不同的点，情况会变得多么复杂。

在更传统的自动化中，你必须映射所有不同的边和连接，以确保系统能够工作。如果你遗漏了一个，系统就会崩溃，无法运行。

---

AI智能体的不同之处 🚀

现在，如果你考虑AI智能体，你可以采取完全不同的方法。智能体可以根据客户输入，自行决定要做什么以及按什么顺序做。

它可能决定立即显示文章，稍后检查登录状态，最终再决定是否升级。你可以看到智能体如何拥有不同的选项，并像之前选择哪封邮件更好一样，自主选择如何在这些选项中导航。

---

AI智能体带来的优势 ✨

这种方法带来了几个关键优势：

1. 认知能力：智能体能够自主选择。
2. 实时反应：智能体能对你输入的任何内容做出实时反应。根据客户输入的不同，智能体会决定最合适的下一步。
3. 自我修复能力：这意味着如果“检查登录状态”这一步失败了，智能体可能会找到解决方法，例如使用另一个API，或执行另一个步骤。
4. 自我改进能力：这个概念指智能体确保能从自己的行为中学习。随着处理更多示例、用例和运行次数，它们会了解什么有效、什么无效，从而强化有效的行为。

这些是传统自动化所不具备的特性。

---

驱动智能体自动化的两大核心 🏗️

归根结底，如果我们放大视角，驱动智能体自动化和智能体系统的两大核心是：

1. 创造能力：撰写电子邮件、生成图像等。
2. 决策能力：决定使用什么工具、使用什么数据、如何从失败中恢复。

---

构建可靠、可扩展的智能体系统 ⚙️

最终，为了使这些智能体具有可扩展性，它们必须是可靠的。这意味着系统需要易于构建、值得信赖且易于管理。

如果一个客户支持智能体在大多数时候都无法响应用户请求，或者向不符合条件的客户提供退款，那么它对你的公司来说就没有多大用处。

因此，本课程的一个重点是如何设计系统，使其能够提供高质量的产出。

---

数据的重要性与适用场景 📊

我们很快就会深入讨论数据。随着你越来越多地使用AI智能体，你会注意到并非所有用例都生而平等。有些用例比其他用例更适合使用智能体。

---

总结 📝

本节课中，我们一起学习了AI智能体的核心定义，理解了其基于大语言模型的工作原理，以及它如何通过认知和决策能力实现复杂的自动化。我们对比了传统自动化与AI智能体自动化的区别，并探讨了智能体带来的实时反应、自我修复和自我改进等独特优势。最后，我们明确了构建可靠、可扩展的智能体系统的关键，并预告了下一节关于如何为AI智能体寻找最佳用例的内容。

004：AI智能体的应用场景

在本节课中，我们将学习如何思考、衡量和选择AI智能体的应用场景。我们将通过一个“用例矩阵”来分析不同场景对复杂度和精度的要求，并探讨如何根据需求选择从单一LLM调用到多智能体协作的不同实现方案。

用例矩阵：复杂度与精度

上一节我们介绍了AI智能体的基本概念，本节中我们来看看如何评估一个具体问题是否适合用智能体来解决。一个有效的方法是使用“用例矩阵”，它可以帮助你根据任务的复杂度和精度要求来定位你的用例。

• 复杂度：指任务涉及的步骤、信息量和逻辑关系的多少。
• 精度：指任务输出结果必须达到的准确性和可靠性标准。

根据这两个维度，我们可以将用例分为四个象限：

1. 高复杂度 & 高精度：例如填写长达70页、附带700多页说明的税务表格。这类任务极其复杂，且不容出错。
2. 高复杂度 & 低精度：例如内容创作。虽然需要处理复杂的信息和创意，但对输出格式和具体措辞有更大的宽容度。
3. 低复杂度 & 高精度：例如简单的数据验证或格式化。
4. 低复杂度 & 低精度：例如生成一些简单的提示或想法。

AI智能体可以处理所有这些维度的问题，但最具价值的通常是高复杂度的问题，而能最快取得成效的则是低精度的问题。一个理想的起点是高复杂度、低精度的象限，因为智能体擅长解决复杂任务，同时输出上的灵活性允许你快速获得可用的成果。

智能体层级谱系：从LLM到智能体群组

无论你考虑哪种用例，都需要在“智能体层级谱系”中做出选择。这个谱系的一端是简单的大型语言模型调用，另一端则是复杂的智能体群组协作。

以下是这个谱系的构成：

• 单一LLM调用：某些用例可能只需要向大语言模型发起一次调用就能获得所需信息。这属于低自主性的方案。
• 单一智能体：有些任务需要一个具备特定角色、记忆和工具的独立智能体来完成。
• 智能体群组：最复杂的场景需要一整个Crew，即一组各司其职的智能体协同工作。例如之前提到的会议准备用例。这属于高自主性的方案，智能体们会自主决定每个步骤的执行。

CrewAI的两种核心抽象

为了支持这种谱系，CrewAI提供了两种核心抽象来满足不同层级的控制需求。

• Crews：为高自主性优化。智能体群组拥有记忆、工具和任务，能够自主协作。公式可以表示为：Crew = 多个智能体 + 共享目标 + 协调机制。
• Crew AI Flows：这是一个低层级框架，赋予你完全的控制权，可以精确决定执行流程的顺序。你可以混合使用普通Python函数、单一LLM调用和整个Crew。代码结构示意如下：

  # 伪代码示例
  def my_flow():
      result_a = regular_python_function()  # 第一步：执行普通函数
      result_b = llm_call(result_a)         # 第二步：进行LLM调用
      final_result = crew.execute(result_b) # 第三步：启动智能体群组
      return final_result
  

示例：对话式员工福利系统

让我们通过一个具体例子来理解如何应用这些概念。假设要构建一个对话式系统，让员工咨询福利问题。

这个用例通常始于用户通过聊天界面发起对话。处理初始消息可能不需要很高的自主性，一次简单的LLM调用就足以理解用户意图并判断是否需要进一步处理。

如果LLM判断需要深入分析（例如查询数据库获取具体的福利数据，或在客服用例中查询内部系统），这时就需要更高的自主性和复杂性。这便适合交由一个Crew来完成，其中可以包含负责研究、查询、分析的多个智能体协同工作，最终将答案返回给用户。

整个流程通过Crew AI Flow来编排：先进行LLM调用，再在必要时触发智能体群组。这样，我们只在真正需要的地方“引入”智能体的自主性，从而在保持对流程控制的同时，解决了复杂问题。

本节课中我们一起学习了如何利用用例矩阵评估AI智能体项目的可行性，认识了从LLM到多智能体的谱系选择，并了解了CrewAI如何通过Crews和Flows两种抽象来满足不同复杂度和控制需求的应用场景。下一节，我们将深入探讨AI智能体的智能基础，了解它们为何能够表现出“智能”行为。

005：什么让AI智能体变得智能？🤖

在本节课中，我们将探讨什么因素使得一个AI智能体变得“智能”。我们将从理解大型语言模型与传统AI系统的区别开始，并深入探讨“上下文工程”如何成为构建可靠、可重复智能体的关键。通过一个具体的多智能体团队示例，我们将了解如何通过优化输入来引导模型，从而获得高质量的输出。

---

理解AI智能体的智能本质

上一节我们介绍了智能体的基本概念，本节中我们来看看智能的核心驱动因素。

一个能够投入生产的AI智能体，意味着它能提供可靠且可重复的结果。这要求我们必须仔细思考背后的“上下文工程”，即你在每次API调用中提供给模型的信息。让我们深入探讨这一点，以便你更好地理解如何优化你的智能体，以获得最佳的输出质量。

---

传统AI系统 vs. 大型语言模型

我非常期待这一课，因为我们将退一步，简要地理解大型语言模型的工作原理，以及它们与更传统的AI系统有何不同。

传统AI系统的核心，是尝试理解输入以预测输出。让我们看一个简单的例子：一个试图预测是否会下雨的传统AI系统。

为了做到这一点，它会使用几个不同的数据点，例如：

• 地理位置
• 季节
• 温度

使用这些特征，我们试图预测是否会下雨。一个好的例子是：孟买在夏季，华氏90度，我们预测不会下雨；但在坦佩的冬季，华氏65度，则会下雨。

这种模型的工作方式是：你向它展示足够多的关于地点、季节和温度的例子，它就会开始理解所有这些特征与预测结果之间的相关性。你向模型展示的例子越多（我们称之为“训练”），它就越能理解不同特征与实际输出之间的关联。这样在未来，如果你展示一个它未见过的例子，例如东京在夏季，华氏85度，它也能够预测是否会下雨。

这里的核心思想是，模型利用这些特征来理解它们如何与最终预测相关联。这一点在很大程度上也适用于大型语言模型。我知道这是一个简化的比较，但LLMs中确实存在大量类似的机制。它也是一个常规的AI模型，但在这种情况下，“特征”是你迄今为止输入的所有词语。

例如，当你进入ChatGPT并输入“给我一份特斯拉的股票报告”，然后它输出一个答案。理解方式是：你的提示词实际上是告知模型进行预测（即生成答案）的“特征”。这意味着你对最终得到的预测（答案）拥有比你想象的更多的控制权。你可以通过改变提示词来获得不同的回应。这本质上就是人们常说的“提示工程”——理解如何组织句子，以引导模型给出最佳答案。

一个你可以自己尝试的提示工程例子是：不要直接运行“给我一份特斯拉的股票报告”，而是将提示词改为“作为一名出色的金融顾问，给我一份特斯拉的股票报告”。你可以看到这里多了几个词，就像我们改变了季节、地点或温度一样。现在我们提供了不同的信息，这将显著影响预测，从而得到不同的答案。

系统的智能性来源于它们能够接受海量的特征作为输入，并能在这些输入之间建立复杂的关联，以预测接下来会发生什么。这一点之所以重要，是因为输入LLM的内容会极大地影响它的回应方式。而有效地做到这一点，正是构建优秀智能体的关键。

---

从确定性软件到非确定性AI

让我们再退一步思考。如果你考虑更传统的软件，所有的软件都是强类型的。我的意思是，你非常清楚输入的数据是什么、发生了哪些转换、以及输出的数据是什么。这就是为什么你可以进行测试，因为你知道 2 + 2 总是等于 4。

然而，当你考虑AI系统时，它们是非确定性的。这意味着你不知道输入的数据具体是什么，模型本身是一个黑箱，你也不知道输出的数据会是什么。想想ChatGPT，你可以在里面输入蛋糕的食谱或博士论文，有时你无法确切知道会得到什么样的数据。这既是它的魅力所在，但也影响了你能对系统施加多少控制，以确保获得可靠的输出。

---

上下文工程：构建智能体的核心

假设你正在构建一个能够创建职位列表的智能体团队。这个团队将帮助你研究、撰写职位描述并进行编辑，确保其质量一流。

这个团队将包含三个智能体：

1. 研究分析师
2. 撰写者
3. 编辑者

其工作流程是：研究员将职位角色作为输入，去研究其他职位列表，查看相关技能以及竞争对手的需求。然后，撰写者将获取所有研究结果和职位规范，并实际撰写职位描述。最后，编辑者将审查所有内容，确保其符合你公司的风格和文化。

首先，让我们谈谈上下文工程如何让你引导这个团队协同工作，决定每次请求的最佳可能输入。上下文工程的核心就是优化这一系列输入，使其作为“特征”，为你带来可能的最佳输出。

以下是构成上下文工程的关键要素：

• 系统提示：发送给模型的提示是什么？它们提供了关于LLM应如何行为的指导。
• 清晰的指令：特别是要解释对该智能体的期望是什么，以及“完成”的良好定义是什么。
• 角色扮演：确保让这些智能体进行角色扮演。请记住，你提供给这些模型的“特征”会影响你得到的输出。因此，如果你让这些智能体扮演特定角色（就像我们之前让它们扮演“出色的金融顾问”一样），当它们化身为研究员、撰写者和编辑者时，你会从这些智能体那里得到更好的回应。
• 记忆：记忆也将发挥作用，它赋予这些智能体记住过去做得好与不好的能力。
• 工具：这些是智能体为了能够进行研究（例如搜索网络）、撰写内容和审阅内容所需的东西。

我知道信息量很大，但别担心，因为我们将在后续课程中深入探讨每一个方面。

---

总结与预告

本节课中，我们一起学习了AI智能体智能的本质。我们了解到，智能并非凭空产生，而是源于对模型输入（即“上下文”）的精心设计与工程化。通过与传统AI系统对比，我们明白了LLMs将我们的提示词视为预测答案的“特征”。我们还探讨了如何通过系统提示、清晰指令、角色扮演、记忆和工具等上下文工程要素，来引导多智能体团队协同工作，从而获得可靠、高质量的输出。

在接下来的视频中，我们将一起启动我们的第一个智能体，实时观察上下文工程的实际应用。我们稍后见。

006：构建你的第一个AI智能体 🚀

在本节课中，我们将动手实践，构建你的第一个AI智能体。你将学习如何运用之前讨论的“上下文工程”原理，来构建尽可能优秀的智能体。这些核心原则适用于所有用例，无论你是否使用CrewAI或其他框架。

概述：智能体与任务的设计哲学

上一节我们介绍了上下文工程的重要性，本节中我们来看看如何将其应用于具体的智能体构建。一个关键的建议是遵循80/20法则：应将更多精力放在任务设计上，而非仅仅关注智能体本身。虽然智能体很重要，但我们的经验表明，清晰定义的任务对最终输出质量的影响最大。

你应该像一位管理者一样思考。优秀的经理往往也是出色的智能体创建者，因为他们不仅考虑“雇佣谁来完成任务”，更清楚设定成功标准的重要性。

深入理解任务

任务是单一目的和单一输出的。其有效性主要依赖于两个属性：描述和期望输出。

以下是任务的两个核心组成部分：

• 描述：阐述需要完成什么以及为何要完成。
• 期望输出：不仅定义输出格式，更明确“成功”的具体样貌。例如，输出应包含什么内容、采用何种格式、语气如何。

描述和期望输出在上下文工程中扮演关键角色，它们会被用于系统提示、角色扮演、写入记忆或智能体自我评估等不同环节。

剖析智能体

现在，让我们谈谈智能体。一个智能体主要包含三个组件：

以下是智能体的三个核心组成部分：

• 角色：应尽可能使用真实的职位头衔，或能明确传达你希望LLM扮演什么角色的描述。
• 目标：定义该智能体在所有任务中追求的最终目的，即它的“成功”标准。
• 背景故事：在这里你可以自由发挥，添加专业知识、工作风格或价值观等信息，以强化角色扮演效果，确保获得期望的输出。

实战演练：从欠佳示例到优秀示例

接下来，我们跳转到代码笔记本，看看任务和智能体如何结合，形成我们的第一个“团队”。

首先，你需要导入CrewAI的三个主要构建块。

from crewai import Agent, Task, Crew

一个欠佳的示例

假设我们想创建一个内容创作助手，用于生成30-45秒的YouTube短视频创意。

一个欠佳的设计可能如下：

# 智能体定义过于简单
agent = Agent(
    role='内容创作助手',
    goal='提出视频创意',
    backstory='一个拥有丰富视频内容创作经验的人。'
)

# 任务定义模糊
task = Task(
    description='提出5个新的视频创意。',
    expected_output='至少5个创意列表。',
    agent=agent
)

然后，我们将智能体和任务组合成团队并运行。但这样的设计存在明显问题：智能体甚至不知道它在为YouTube创作，也不了解“短视频”的特定要求。运行结果很可能不尽人意，例如生成一些适合长纪录片的主题，而非高 retention 的短视频创意。

一个优秀的示例

现在，让我们看一个经过深思熟虑的优秀设计：

# 智能体定义具体、目标明确
agent = Agent(
    role='YouTube短视频内容策略师',
    goal='创作能保持一周高留存率的YouTube短视频内容',
    backstory='你是一位专攻病毒式传播和平台算法的专家，擅长创作能在前3秒抓住观众注意力、并鼓励完播和互动的短视频内容。'
)

# 任务描述详尽，期望输出格式清晰
task = Task(
    description='基于当前趋势，构思5个YouTube短视频创意。每个创意必须适合30-45秒的格式，并优化以适应YouTube Shorts的算法推荐机制。',
    expected_output="""
    一个JSON数组，包含5个对象。每个对象必须包含以下字段：
    - "title": 视频标题
    - "hook": 开场3秒的钩子文案
    - "visuals": 建议的主要视觉元素描述
    - "tags": 5个相关标签的列表
    - "call_to_action": 视频结尾的行动号召
    """,
    agent=agent
)

将这个智能体和任务组合成团队并运行后，你会得到结构清晰、符合平台特性的高质量输出（例如格式规范的JSON数据），与欠佳示例的结果有天壤之别。

总结

本节课中，我们一起学习了构建第一个AI智能体的核心步骤。关键在于：

1. 遵循80/20法则，优先精心设计任务的描述与期望输出。
2. 像管理者一样定义智能体，明确其角色、目标和背景故事。
3. 通过具体、详细的上下文信息（如平台、格式、成功标准）来引导智能体，这能极大提升输出质量。

这只是一个单一智能体的例子。此用例可以扩展为包含多个智能体的团队，例如负责脚本起草、深度研究、社交媒体营销等，从而构建完整的内容生产流水线。在接下来的课程中，我们将继续探索多智能体协作的奥秘。

007：多智能体系统规划 🧠

概述

在本节课中，我们将要学习如何规划和设计多智能体系统。我们将探讨单个智能体的局限性，并理解如何通过组合多个专业化的智能体来应对更复杂的任务，从而获得更强大的能力。

从单智能体到多智能体

上一节我们介绍了如何构建你的第一个智能体、任务和团队。你已经准备好开始理解其中的一些基本概念。这种智能体执行工作并被分配任务的思想，在整个行业中，无论你使用的是 CrewAI 还是其他任何智能体构建工具，都是通用的。

现在，我们不仅要关注可以使用一个智能体，更要关注你也可以使用多个智能体。这里存在一个平衡：何时引入更多智能体以及引入多少。其核心理念在于，多个智能体能让你拥有更专业化的能力，正是通过它们的协同努力，你才能处理更复杂的使用场景。

使用场景与智能体数量

如果我们回顾一下之前提到的使用场景矩阵，你会发现，对于高复杂度、低精度，甚至是高复杂度、高精度的任务，通常需要多个智能体来完成，而不是单个智能体。这是因为你需要确保“分而治之”，甚至可以根据需要为你的智能体设置不同的语言模型，一切都是为了获得最佳的输出结果。

案例：深度研究团队

接下来，让我们谈谈在后续视频中将要一起构建的用例：一个深度研究团队。这基本上是一个能够对某个主题进行深入研究并生成报告的智能体小组。

输入是一个初始主题，输出是一份报告。我们将通过让四个智能体以顺序方式协作，来完成从主题到报告的转化。

以下是这个流程中各个智能体的角色和任务：

• 规划者智能体：第一个任务是将初始查询分解。无论我们得到什么主题，我们都希望将其分解成更易于管理的小块。
• 研究者智能体：我们需要对该主题进行一些调查。这个智能体可能需要一些工具（例如网络搜索）来查找构建报告所需的信息。
• 事实核查者智能体：我们希望确保报告事实准确。因此，会有一个单独的智能体专门进行事实核查，交叉验证各种说法，确保一切有效，并尽量减少可能出现的幻觉。
• 报告撰写者智能体：最后的智能体负责将所有来自规划、研究和事实核查的知识整合成一份连贯的报告，从而在最终获得高质量的输出。

为了直观展示，我们可以用一个简单的流程图来表示这个顺序过程：

graph LR A[初始主题] --> B(规划者) B --> C(研究者) C --> D(事实核查者) D --> E(报告撰写者) E --> F[最终报告]

智能体的协作模式

正如你所见，在这个例子中，智能体以特定的顺序工作以生成最终报告。但是，当你构建这些用例时，顺序协作可能并不总是最优的。你可能需要探索智能体之间不同的通信和协作风格。

以下是几种常见的协作模式：

• 分层式：智能体之间存在明确的层级关系，上级智能体协调下级智能体。
• 混合式：结合了多种协作模式。
• 并行式：多个智能体可以同时并行工作。
• 异步式：智能体可以并行工作，最终再汇聚到一个智能体进行整合。

总结

本节课中，我们一起学习了多智能体系统的规划。我们理解了单个智能体的能力边界，以及如何通过引入多个专业化智能体来应对复杂任务。我们介绍了一个具体的用例——深度研究团队，并分析了其中四个智能体（规划者、研究者、事实核查者、报告撰写者）在顺序工作流中的角色。最后，我们还简要提及了智能体之间可能存在的其他协作模式，如分层、并行等，为后续更灵活的系统设计奠定了基础。

008：构建你的第一个多智能体系统 🚀

在本节课中，我们将动手构建你的第一个多智能体系统。你已经学习了许多核心概念，并花时间规划了用例，现在是时候将这些知识付诸实践了。

我们将深入代码，构建一个“深度研究团队”。这个团队将伴随我们走过后续多节课程，我们会不断用新学到的知识来改进和增强它。

概述

这个初始团队将由四个智能体组成：一个研究规划师、一个互联网研究员、一个事实核查员和一个报告撰写员。这些智能体将按顺序执行一系列任务，最终为我们生成一份关于任何我们想要研究主题的完整报告。

我们需要为互联网研究员智能体提供一些工具。关于工具的详细讨论将在未来的课程中进行。目前，我们仅使用一个预构建的工具。最终，我们甚至会学习如何构建自定义工具。

现在，让我们进入代码环节，开始实际操作。

第一步：导入必要的库和配置

首先，我们需要导入 CrewAI 的核心类：Agent、Task 和 Crew。这些类与我们在上一个笔记本中使用的是相同的。

from crewai import Agent, Task, Crew

为了更方便地管理 OpenAI 的 API 密钥，我们还需要导入一些辅助代码。这是一段样板代码，你可以直接复制粘贴，它会正常工作。

# 导入用于加载环境变量和API密钥的模块
import os
from dotenv import load_dotenv
load_dotenv()

# 配置OpenAI API密钥
os.environ["OPENAI_API_KEY"] = os.getenv("OPENAI_API_KEY")

在本笔记本的最后，我邀请你尝试更换模型，观察不同模型的效果。

第二步：配置研究工具

因为我们需要为智能体提供研究工具来收集数据，所以我们将使用一个应用程序来进行网络搜索。再次强调，现在不必过于纠结工具的细节，我们将在后续课程中详细讨论。

我们只需导入相关模块，并通过加载密钥、创建搜索工具实例和网站抓取工具实例来正确配置它们。

from langchain.tools import DuckDuckGoSearchRun
from langchain.agents import Tool

# 创建搜索工具实例
search_tool = DuckDuckGoSearchRun()
# 创建网站抓取工具实例（此处为示例，实际可能需要其他库如BeautifulSoup）
# scrape_tool = Tool(name="ScrapeWebsite", func=scrape_website_function)

第三步：创建智能体

现在，让我们开始创建智能体。第一个智能体是研究规划师。它的核心思想是能够分析查询，并将其分解为更小、更具体的研究主题。

紧接着的下一个智能体是互联网研究员，它将基于研究规划师的计划来执行具体的研究工作。

你可以看到，我们为每个智能体都设定了非常具体的角色、目标和背景故事。事实核查员和报告撰写员智能体也将遵循相同的模式创建。

# 创建研究规划师智能体
research_planner = Agent(
    role='研究规划师',
    goal='分析用户查询并将其分解为具体的研究主题和问题',
    backstory='你是一位经验丰富的研究策略专家，擅长将宽泛的主题拆解为可执行的研究步骤。',
    verbose=True
)

# 创建互联网研究员智能体
internet_researcher = Agent(
    role='互联网研究员',
    goal='根据研究计划，在互联网上搜索并收集关于指定主题的详细信息',
    backstory='你是一位高效的网络信息搜集专家，擅长使用各种工具找到准确、相关的数据。',
    tools=[search_tool], # 为该智能体分配搜索工具
    verbose=True
)

# 创建事实核查员智能体
fact_checker = Agent(
    role='事实核查员',
    goal='验证研究员收集信息的准确性和时效性',
    backstory='你是一位严谨的事实核查员，对信息的真实性有极高的要求。',
    tools=[search_tool], # 事实核查员也可以使用搜索工具进行验证
    verbose=True
)

# 创建报告撰写员智能体
report_writer = Agent(
    role='报告撰写员',
    goal='根据已验证的研究信息，撰写一份结构清晰、内容全面的研究报告',
    backstory='你是一位专业的科技报告作者，擅长将复杂信息整合成易于理解的格式。',
    verbose=True
)

需要指出的是，研究员和事实核查员都使用了同一组工具子集。

第四步：创建任务

有了智能体后，我们接下来创建任务。我们从“研究计划任务”开始。

这个任务非常具体地定义了它希望智能体做什么：基于用户查询，研究相关主题，理解核心问题，并创建研究计划。

在这里，你第一次看到我们向任务中插入了一些变量。这很重要，因为当你运行这些智能体时，总会有用户输入的成分。无论是查询还是其他输入，你都需要将其注入到工作流中。在这个案例中，我们从第一个任务就注入了用户查询，它将从此处开始指导整个计划。

# 创建研究计划任务
plan_task = Task(
    description="""基于以下用户查询，制定一份详细的研究计划。
    识别主要研究问题，并将宽泛的主题分解为具体的、可搜索的子主题。
    用户查询：{user_query}""",
    agent=research_planner,
    expected_output="一份包含具体研究问题和子主题的详细计划大纲。"
)

# 创建互联网研究任务
research_task = Task(
    description="""执行研究计划。使用提供的工具搜索互联网，收集关于每个研究子主题的全面、最新信息。
    确保信息来源可靠，并记录关键发现和数据点。""",
    agent=internet_researcher,
    expected_output="一份包含所有研究子主题详细发现的汇总，附信息来源。"
)

# 创建事实核查任务
check_task = Task(
    description="""验证研究员收集的所有信息。检查关键数据、声明和统计数据的准确性。
    确认信息的发布时间，并标记任何存疑或过时的内容。""",
    agent=fact_checker,
    expected_output="一份经过验证的信息列表，标注已验证和待核实的内容。"
)

# 创建报告撰写任务
write_task = Task(
    description="""基于已验证的研究信息，撰写一份最终的研究报告。
    报告应采用Markdown格式，结构清晰，包含引言、主要发现、详细分析、数据表格（如适用）和结论。
    确保报告全面、易读且专业。""",
    agent=report_writer,
    expected_output="一份完整的、格式良好的Markdown研究报告。"
)

观察其余任务，你可以看到我们应用了与之前相同的标准，使用了大量形容词（如“全面的”）来精确描述期望包含的内容和搜索范围。

第五步：组建团队并运行

现在，让我们将智能体和任务整合到这个“团队”中，以便实际运行它。这与我们之前所做的完全相同，只是现在有了更多的智能体和任务。

请记住，这里的整个规划是让这些智能体和任务以顺序方式工作，即一个智能体的输出将成为下一个智能体的输入。这意味着我们将首先进行规划，然后根据规划收集研究，接着验证信息，最后撰写最终报告。

我们仍然需要将用户查询注入到这个流程中。

# 定义用户查询
user_query = "评估2025年用于自动化竞争市场分析的五大新兴AI工具"

# 创建团队，指定任务顺序
research_crew = Crew(
    agents=[research_planner, internet_researcher, fact_checker, report_writer],
    tasks=[plan_task, research_task, check_task, write_task],
    verbose=2
)

# 运行团队，传入用户查询
result = research_crew.kickoff(inputs={'user_query': user_query})

在这里，我们通过 kickoff 方法传递了输入。这就是变量插值魔法发生的地方：我们将上面单元格中编写的用户查询传递给团队，它会自动将该查询插入到任何提及它的任务和智能体中。

现在，让我们启动它，看看结果。

print(result)

执行过程解析

如果我们跟随执行过程，可以看到研究规划师智能体首先启动，开始创建整个计划，确定我们需要寻找哪些信息来生成报告。

随着进程继续，事情变得更加有趣。当轮到互联网研究员时，这个智能体实际上可以使用工具。你可以看到它使用了搜索工具，正在执行关于“2025年市场分析新兴AI工具”的搜索，并能在输出中看到工具的返回结果：URL、标题、摘要以及网站发布时间。

接着，互联网研究员可能会决定抓取特定网站以获取关于某个工具的更多信息，并可能对找到的多个网站都执行此操作。在抓取信息后，它会生成最终答案，给出所有找到的工具及其相关信息的完整回复。

我再次邀请你尝试更换模型，观察这对输出结果的影响，你会从中获得很多乐趣。

继续向下滚动到事实核查员智能体，我们可以看到它也在进行搜索，但搜索目标更侧重于查找功能、定价等信息，以确保验证之前发现的信息。它会为我们找到的所有软件（如 Quantal lope 等）执行此操作。

所有这些经过验证的信息最终都会输入给报告撰写员。

最终输出

报告撰写员最终生成了一份 Markdown 文件，内容是关于“2025年用于自动化竞争分析市场的五大新兴AI工具”的全面研究报告。

报告涵盖了从“12 AI”到“Quentaloupe”等所有发现的工具，提供了引用来源、详细说明，甚至提到了发现这些信息的具体网站。它还为我们绘制了一个表格，概述了每个工具的功能，并指出了它们的潜在局限性，包括潜在的成本分析等内容。

总结

本节课中，我们一起动手构建了你的第一个多智能体系统。我们创建了一个由四个智能体（研究规划师、互联网研究员、事实核查员、报告撰写员）组成的“深度研究团队”，并让它们按顺序协作，最终根据用户查询生成了一份完整的研究报告。我们学习了如何导入库、配置工具、创建智能体和任务，以及如何通过变量插值将用户输入注入到工作流中。

如果你继续学习下一课，将会看到，随着我们学到更多知识，我们会不断将新功能带回这个用例中，使其不仅更加复杂，同时也更加可靠。

关于后续课程，让我们跳入下一节。期待稍后与你再见。

009：生产环境中的多智能体系统 🚀

在本节课中，我们将探讨如何将多智能体系统从原型阶段推进到生产环境。我们将了解原型与生产系统之间的巨大差异，识别在生产化过程中面临的挑战与常见陷阱，并概述确保系统稳定、可观测和高质量运行的关键考量。

从原型到生产的跨越

上一节我们介绍了多智能体系统的基本构建方法。本节中，我们来看看将系统投入生产环境意味着什么。

构建原型与投入生产之间存在巨大差距。在原型阶段，您可能以一次性自动化的方式运行智能体。例如，我们早期构建的用于帮助组织和准备会议的智能体团队（Crew），或者另一个用于总结会议记录、提取行动项并起草邮件的用例。

在原型阶段，这个Crew可能由您手动触发，运行后获得结果；或者您可以将其小规模部署给您的工程团队使用。关键在于，一旦您将其全面推广至整个公司，您就从“人力时间”转向了“机器时间”。

• 人力时间：用户少，执行次数少，易于监控和修复问题。
• 机器时间：用户成千上万，执行次数数十万计，如果早期没有投入精力构建监控体系，大规模下的监控和修复将变得极其困难。

当每天只有几次Crew执行时，理解执行轨迹、定位问题并修复相对容易。但当规模扩展到数百、数千甚至数十万次执行时，您无法再进行临时监控，必须确保漏洞不会开始堆积。这就是“机器时间”的含义：智能体进入高速运行环境，执行大量任务，而您仍需能以某种方式追踪其性能。

生产环境的核心指标

为了有效监控生产系统，您需要关注两类核心指标。

以下是您需要关注的两类指标：

1. 深入指标：这类指标关乎调试和复现错误、检查执行轨迹、计算提示词（Prompt）令牌数的能力。其核心在于能够深入任何一次具体执行，追踪并理解其中发生的一切。
2. 宏观指标：这类指标更多围绕使用大语言模型作为评判员、检查输出质量、识别幻觉、评估相关性或成功率。其理念是，您或许可以依赖深入指标进行临时调试，但一旦系统大规模运行，您需要确保有相应的体系来检查整个系统的整体质量。

常见的生产化陷阱

认识到生产系统的挑战后，理解如何应对至关重要。但在此之前，了解常见的失败原因同样重要。

我们发现，当前大多数在将系统投入生产时遇到困难的团队和公司，其问题往往出在流程上，而非技术上。技术已经就位，强大的模型和丰富的功能触手可及。

以下是几个常见的流程陷阱：

• 规划不足：没有花费足够的时间来规划这些用例。
• 成功定义模糊：没有清晰的成功标准定义。
• 流程未模块化：没有将流程分解为更小的、可供多个智能体使用的模块。
• 缺乏评估：即使有清晰的成功定义，也没有进行度量和评估。

无法评估系统是否真正为您创造价值，这将阻碍您做出进一步投资的决策。同时，在改进系统时，您也需要能够判断改进方向是否正确。

课程总结与展望

本节课中，我们一起学习了多智能体系统从原型迈向生产环境所面临的本质变化、需要监控的核心指标（深入指标与宏观指标），以及在此过程中常见的流程性陷阱。

现在您已经了解了生产系统的一些挑战，理解如何实际解决这些问题就变得非常重要。在接下来的视频中，您将看到许多可以用于调试、观测和优化多智能体系统的不同策略和技巧。请确保不要错过下一课，因为它将成为后续一些新示例的基石。

010：调试、观察与优化策略 🐛

在本节课中，我们将学习如何调试、观察和优化你的多智能体系统。理解系统内部运行机制并制定优化策略，对于确保系统长期稳定运行和持续改进至关重要。

运行时间：人类时间与机器时间

上一节我们介绍了多智能体系统的趣味性。本节中，我们来看看系统执行过程中的时间概念。

系统执行会不断累积。执行次数越多，你对系统的信任度要求就越高。最终，这不仅关乎实现价值的速度，更关乎你对输出结果的信任程度，以便你能将系统性能发挥到极致。

引导智能体的方法

为了引导智能体朝特定方向行动，你可以实施多种方法。以下是几种核心的上下文工程技术：

• 系统提示词：设计清晰的指令。
• 角色扮演：为智能体定义明确的角色。
• 记忆：利用记忆功能。
• 工具：为智能体配备合适的工具。

好消息是，CrewAI 已经内置了许多此类功能。然而，在部署和调试过程中，你仍会遇到许多问题，例如：智能体为何采取某个行动？数据从何而来？智能体使用了哪些工具？在早期调试、测试和部署阶段，追踪这些信息可能很困难。你需要答案来精确理解系统的行为逻辑及其决策原因。

核心调试与优化策略

接下来，我们将探讨几种能极大简化你工作的策略。

1. 利用追踪功能 🔍

当你本地运行智能体时，可以查看追踪信息。这些追踪信息会在 CAMP 的浏览器界面中打开，让你能看到智能体的每一个动作：从初始任务，到所有大语言模型调用，再到使用的工具，以及其间的一切过程。你不仅能查看耗时，还能展开细节，了解具体使用了什么工具、提供了什么输入。你甚至可以查看所有独立的消息。

当你在本地计算机上运行 Crew 时，终端会直接显示一些追踪信息，帮助你理解当前状况。执行结束后，你总会获得一个链接，确保你可以在实际用户界面中查看智能体的运行情况并进行监控。

2. 任务与测试

我们讨论了很多关于上下文工程和提示词设计的想法。我们知道每个智能体都有角色和背景故事，每个任务都有描述和期望输出。通过更新这些内容，你可以很大程度上控制发送给模型的信息。

但提示词设计只是冰山一角。通过任务和测试，是理解智能体行为并找到最适合你的模型的有效方法。你可以让单一智能体定义和单一任务定义，针对多个不同的大语言模型进行测试。系统会使用一个大语言模型作为“裁判”来评判每个请求的输出结果。通过这种方式，你可以基于事实数据（而不仅仅是感觉）来比较哪个大语言模型在该任务上表现最佳，哪个更可靠、更符合你的期望。

3. 训练智能体 🏋️

测试仅帮助你选择模型。选定模型后，如何让智能体强制执行特定格式或行为呢？这时就需要引入“训练”这一新功能。这是一种非常强大的技术。

这里的“训练”并非指训练或微调一个大语言模型（当然你也可以这么做），而是一种技术：让你的智能体多次执行任务，获取你的反馈，然后再次尝试。它会更新自己的内部记忆以学习如何改进，从而随着时间的推移不断进步。

在这个过程中，智能体反复执行任务。每次完成后，它会向你（人类）征求反馈。你提供的任何反馈都会被转化为学习经验，存入该智能体的记忆中。因此，当这个智能体执行未来的任务时，这些反馈会被注入到其提示词中。这为你提供了另一种影响上下文的方式，而不必仅仅修改任务描述或智能体定义。

4. 设置防护栏 🚧

许多生产系统都能从防护栏中受益。防护栏的理念是强制执行特定行为。回顾我们讨论过的从任务到训练再到防护栏的所有内容，你会发现一个共同点：确保你的智能体以某种特定方式行事。

你可以将防护栏视为位于智能体和任务完成之间的一个“关卡”。在智能体最终完成工作并传递结果之前，它会经过这个防护栏。防护栏可以是一个作为裁判的大语言模型，也可以是一个代码防护栏，即你编写代码来检查输出。

防护栏随后会判断最终输出是否成功。如果成功，则让响应通过并给出最终答案；如果发现不足，则会向智能体反馈信息，让智能体再次尝试改进。

以下是几个例子：

• 代码防护栏示例：假设你只想确保最终输出少于200个字符。你可以直接为此编写一个代码防护栏，使用常规 Python 代码计算字符数。如果不少于200，则发回给智能体重写。

  if len(final_output) >= 200:
      # 触发重写逻辑
      return “output_too_long”
  

• LLM 裁判示例：除了少于200字符，你还想确保内容是积极的。你可以使用一个大语言模型作为裁判，来检查输出是否积极。这能实现仅靠编码无法完成的复杂检查。

总结

本节课中，我们一起学习了调试、观察和优化多智能体系统的核心策略。我们探讨了利用追踪功能深入理解系统行为，通过任务测试科学选择模型，运用训练技术让智能体从反馈中学习改进，以及设置防护栏来强制执行特定规则以保证输出质量。

除了测试、训练、防护栏和上下文工程，还有许多其他选项可以提升系统性能，其中一些我们将在后续模块中看到。接下来，请观看下一个视频，了解最成功和最常见的生产用例有哪些。我们稍后见。

011：规模化多智能体系统的实际应用案例 🚀

在本节课中，我们将探讨多智能体系统在真实商业环境中的规模化应用。你将了解哪些实际用例正在为企业带来显著效益，以及如何衡量这些系统的效率提升。

规模化应用的实际用例

上一节我们深入探讨了多智能体系统的设计，本节中我们来看看它们在现实世界中的表现。目前，许多应用案例已展现出惊人的效率提升，范围在80%到97%之间。这里的“效率”可以通过多种方式衡量，最常见的是比较企业在实施智能体系统前后，完成特定任务所花费的时间。

一个真实的财富500强公司案例

为了具体说明，让我们分析一个真实的财富500强消费品公司的案例。这家公司销售薯片、维生素、方便面或啤酒等超市常见商品。

他们实施了一个非常有趣的用例，称为“收入运营”。其核心目标是解决一个历史难题：如何比以往更快地批准价格变动。这个过程传统上需要大量人工审批，例如检查竞争对手价格、核查市场行情等。

以下是该智能体系统的工作流程：

1. 流程起点：一切从一个更新请求开始，该请求会被录入一个SharePoint数据库。
2. 信息检索：智能体能够从数据库中检索该请求信息。
3. 系列检查：为了决定是否批准此变更，智能体会执行一系列检查：
   • 检查竞争对手价格。
   • 检查市场价格。
   • 验证数值并遵循若干基本规则，例如成本中心是谁、谁为折扣买单。
4. 决策与执行：如果所有检查都通过，智能体将批准并广播新的价格值，这将直接影响产品的最终售价。
5. 人工介入机制：如果在任何环节出现问题（例如，拟更新的价格不符合竞争对手定价），智能体会主动向相关人员请求额外验证。它们会向负责人发送提示并提出具体问题，以获取批准请求前所需的验证和信息。

这是一个极其强大的用例。可以想象，对于一家全球运营的公司，如果此类流程被妥善自动化，每周可以节省数百小时。对该企业而言，这是一个出色的初始用例。经过几周的优化实施，仅此用例就为他们带来了94%的效率提升和97%的决策准确率。准确率是通过比较智能体在同期做出的决策与之前人工所做的决策来衡量的，以确保一对一的可比性。

分享这个案例的目的，是为你提供一个蓝图，供你在自己的公司或团队中参考实施。

广泛的应用领域与功能

超越这家公司，你会发现许多顶级行业都在应用多智能体系统。我们看到高科技、消费电信、金融、客户服务、保险等领域的公司都在广泛受益。

在这些行业中，具体的功能应用主要集中在以下几个领域：

• 销售与营销自动化
• 开发人员自动化
• 网络安全
• 供应链管理
• 定价策略
• 人员管理

成功实施的关键考量

在讨论了所有内容之后，我们可以总结出，在实施前进行周密思考是成功的关键。你需要围绕以下几点进行设计：

• 输出质量：明确你希望获得什么样的输出质量。
• 智能体协作：思考智能体之间最佳的协作方式。
• 性能衡量：确定如何衡量系统性能。
• 模型测试：确保针对不同模型进行测试验证。
• 规模化与护栏：规划如何扩展系统，并设置适当的防护措施。
• 可观测性与追踪：添加可观测性和追踪机制，以确保获得尽可能好的输出。

我想强调的是，在设计阶段投入时间进行深入思考，将最终帮助你取得更好的成果，这一点至关重要。

总结与展望

本节课中，我们一起学习了多智能体系统规模化应用的实际案例、其带来的巨大效率收益，以及一个消费品公司的详细实施流程。我们还看到了该系统在不同行业和功能领域的广泛应用前景，并总结了成功部署的关键设计考量。

现在，你已经了解了将多智能体系统投入生产环境的主要考虑因素。我邀请你跟随我进入下一个视频，我们将讨论AI智能体革命为何正在此时发生，以及你如何参与构建它。请不要错过。我们稍后见。😊

012：为何发生在当下

在本节课中，我们将回顾迄今为止所学的关于 AI 智能体的知识，并探讨其未来发展趋势，以及这些趋势可能对您、您的团队和公司技术决策产生的影响。

智能体采用模式的演变

上一节我们介绍了智能体的构建与应用。本节中，我们来看看企业采用 AI 技术的模式正在发生怎样的根本性转变。

一年前，大型语言模型的采用模式始于“边缘”。这意味着某个部门的个人开始使用 LLM 处理任务，效果很好，但并未广泛告知他人。这种模式带来了诸多问题。

以下是这种模式导致的主要问题：

• 信息泄露风险高：不应发送给 LLM 的数据可能被误传。
• 用例临时性强：难以复制推广，其他人无法效仿。
• 知识孤岛化：相关知识被局限在少数人手中。

这导致 LLM 的采用比预期更为分散。许多公司后来意识到了问题，并试图建立专门的团队和卓越中心。

如今，AI 智能体的采用模式则截然不同。我们看到的是“中心化”采用模式：由一个赋能团队集中部署智能体，然后允许其他团队自行使用。这确保了以下几点：

• 对 LLM 和集成的集中控制。
• 在中心位置处理个人身份信息等敏感数据的移除。
• 对用例及其实现方式的统一管理。

随后，赋能团队可以进入其他部门（无论是技术还是非技术部门），根据他们是否需要编码，通过 Crew Studio 或无代码方案，或直接使用 CrewAI 开源库，来启用这些用例。这是企业采用智能体方式的一个非常有趣的变化。

构建可靠智能体的核心概念

围绕构建可靠智能体的理念，主要基于以下三点：

1. 易于构建：无论是通过编码还是无代码方式，都需要非常容易使用和构建，实现从零到一的快速启动。
2. 结果可重复：我们深知这是非确定性系统，无法保证两次答案完全相同，但必须确保所有输出结果都是高质量的。
3. 方案可扩展：这不仅指能运行百万个智能体，还包括如何确保公司或团队不会重复构建相同的智能体或工具，并能在全公司范围内复用这些构建模块。

正在形成的智能体技术栈

基于构建智能体的理念，一个完整的技术栈正在形成。我们可以从数据管理层开始，逐级向上看：

• 数据管理：智能体需要接触数据，无论是 Databricks、Snowflake、Redshift 还是 BigQuery。
• 大型语言模型：存在多种 LLM，每个模型都有其特色和能力。您可能希望在某些用例中使用 GPT-4，在另一些用例中使用 Claude 或 Gemini。
• 智能体编排：这是 CrewAI 的核心领域，需要确保任务能可靠运行，并能以适当的方式进行观察和监控。
• 认证与作用域、企业连接器以及智能体应用。

此外，还有可观测性、支付等新兴类别不断涌现。这里的核心思想是，公司认识到智能体需要与数据交互，并且需要灵活运用不同的 LLM。

企业关注的五大核心要素

无论公司为技术栈的每个部分选择何种具体方案，有五件事是所有公司都会考虑的：

1. 互操作性：使用不同供应商服务且不被厂商锁定的能力。
2. 可观测性：清晰理解您的智能体做了什么，并能追溯其执行过程。
3. 治理：跟踪数据访问权限，确保现有的认证和授权系统能使您始终符合内部所有合规要求。
4. 评估：如何确保智能体的表现符合速度和质量的预期，从而保证智能体持续有效工作。
5. 防护栏：帮助您获得更可靠、可重复的结果。

这五大要素是每家公司都在询问的，与他们的具体技术栈构成无关。因此，最终，即使在 CrewAI 平台上，我们也确保您构建的任何东西都可以作为开源项目下载并在任何地方运行。

课程总结与下一步

本节课中，我们一起回顾了 AI 智能体的核心概念，探讨了其企业采用模式的演变、构建可靠智能体的要点、正在形成的技术栈以及企业关注的五大核心要素。

希望学完本课，您能收获满满，对构建自己的首个多智能体系统、理解如何将这些系统扩展到生产环境，以及哪些用例对企业最具价值充满信心。

既然您已掌握了所有这些知识，就可以准备进入我们的分级实验和分级测验了。在分级实验中，您将实现一个多智能体自动代码审查系统，这将会非常棒。

完成后，我们将在下一个模块中立即见面，在那里我们将动手实践，学习如何为您的 Crew 实现工具、防护栏、执行钩子和 MCP 服务器。这将非常令人兴奋。

期待在那里与您相见。

013：理解AI智能体工作流 🧠

在本模块中，我们将深入探讨之前学习的所有内容。我们将从理解智能体如何实际工作开始，探究其背后的运行机制、规划与执行任务的方式，以及它们如何对输出结果进行反思。这将非常令人兴奋，因为您将开始以一种前所未有的方式理解智能体的内部运作原理。

智能体协作与ReAct循环 🔄

我们已经了解了智能体群组（Crews）以及多个智能体如何协作完成任务。这些智能体可以通过多种方式协作，完成研究、内容创作、分析、撰写报告等各种活动。

现在，让我们聚焦于单个智能体，并讨论其核心驱动机制：ReAct循环。这个循环是智能体运行的基础，它代表了智能体推理（Reason）、行动（Act）并反复进行直到得出结论或最终输出的能力。

具体过程如下：

1. 推理：大型语言模型（LLM）会思考下一步该做什么。
2. 行动：根据推理，智能体可能会采取一个行动（例如使用一个工具）。
3. 观察：智能体观察该行动产生的输出结果。
4. 循环或输出：基于观察，智能体要么给出最终答案，要么返回第一步，重新进行推理以决定下一步行动。

例如，在创建或研究某事物的过程中，智能体会决定：“为了继续，我需要使用工具A。”获得工具A的信息后，它可能意识到还需要更多信息，于是再次进入循环，选择使用工具B。这就是标准的ReAct循环流程。

循环的扩展：规划、记忆与护栏 🛡️

ReAct循环还可以加入更多步骤，使其功能更强大。

• 规划阶段：许多现代智能体系统会在开始执行前加入一个规划阶段。智能体在此阶段进行预先推理，制定计划，该计划将影响其后续行动。这有助于智能体处理更复杂的工作。在CrewAI中，您可以通过设置一个标志（如 reasoning=True）来启用此功能。

• 记忆的作用：记忆在智能体工作流中扮演着关键角色。它会在每个步骤中动态地存入和取出信息。每当智能体进行推理或采取行动时，都会创建记忆并存入其记忆库。同样，当智能体决定下一步做什么时，也会从其记忆库中提取相关信息。

• 护栏的作用：护栏在后期阶段介入，用于防止输出在未完成或未达到用例标准之前被释放。它可以提供确定性或概率性的控制和检查。

多智能体工作流与任务委派 👥

ReAct循环不仅限于单个智能体。在我们的智能体群组中，每个执行不同任务的智能体背后都在运行着各自的ReAct循环。

您可以设计一个智能体的ReAct循环触发其他多个智能体的工作。这就像一个管理者智能体，它将工作委派给其他智能体，不仅决定委派什么和如何委派，还会审查返回的结果。这些被委派的智能体可以并行执行任务。

例如，初始智能体将一系列任务委派给其他智能体，最后由一个报告智能体进行汇总。报告智能体将所有智能体完成的任务和信息整合到最终报告中。

您可能还注意到了“前置与后置钩子”的概念。我们将在后续课程中详细讨论。有时，您需要这些钩子在智能体群组工作之前或之后执行代码，这在从外部拉取数据或将数据推送到外部时非常有用。

核心控制机制总结 📋

归根结底，我们花了大量时间讨论如何控制智能体，以及如何在这些概率性AI系统中提供确定性控制。目前，我们主要关注三种核心机制：

1. 记忆：动态更新的上下文，帮助智能体随时间推移更好地学习。
2. 护栏：为输出添加确定性或概率性控制和检查（例如使用LLM作为评判员或代码护栏）。
3. 钩子：允许在智能体工作之前或之后执行确定性代码。

我们将在下一个模块讨论一个更高级的控制手段：工作流。但现在，让我们先关注这些离散的确定性控制工具。使用它们可以显著提高您用例的可靠性。

下节预告 🚀

在接下来的课程中，我们将专门深入探讨记忆这个非常令人兴奋的主题。我们将详细研究所有不同类型的记忆及其工作原理。

本节课中，我们一起学习了AI智能体的核心工作流——ReAct循环，了解了其基本步骤以及如何通过规划、记忆和护栏进行扩展。我们还探讨了多智能体场景下的任务委派模式，并总结了当前可用于控制智能体行为的几种关键机制。理解这些基础概念是设计和构建高效多智能体系统的第一步。

014：2. 融入记忆与知识

在本节课中，我们将要学习如何为AI智能体赋予记忆与知识。这些能力使智能体能够自我修复、随时间改进，并更有效地完成任务。我们将探讨记忆的类型、知识如何融入，以及它们如何共同提升智能体的性能。

---

🧠 记忆的类型

上一节我们介绍了智能体的基本概念，本节中我们来看看智能体如何通过记忆来学习和改进。在CrewAI和大多数智能体框架中，存在几种不同类型的记忆。CrewAI特别定义了三种至关重要的记忆类型：短期记忆、长期记忆和实体记忆。

短期记忆旨在帮助智能体在既定上下文之外交换信息。这意味着智能体在执行任务和行动时，会将信息写入该记忆，并允许其他智能体从中读取。

长期记忆则旨在帮助智能体进行自我反思，以理解随时间改进的方法。当智能体完成任务后，它们会将实际输出与预期输出进行比较，汲取经验教训，并存储起来供后续使用。这样，当它们再次执行相同任务时，就能了解哪些做法是好的、应该多做，哪些做法应该避免。

实体记忆帮助智能体记住可识别的实体，例如公司、产品、流程等及其描述。一个实体记忆可能包含的概念包括人物、组织和地点。智能体开始学习这些不同的事物并存储它们，这样在后续过程中就不需要再次推断或学习它们是什么。

---

⚙️ 启用记忆

如果你希望为你的智能体启用记忆功能，操作非常简单。你只需要在Crew实例中将一个标志位设置为 True。

memory = True

启用此标志后，你所有的智能体都将开始使用这些记忆功能。

---

🔄 记忆如何工作

现在我们已经了解了记忆的类型和启用方法，接下来看看记忆在智能体运行过程中是如何工作的。如果我们回顾智能体的反应循环，现在可以看到，长期、短期和实体记忆这三个不同的数据库都会将信息输入到思考过程中。

这使得智能体不仅能更了解如何做得更好，还能了解正在讨论的内容以及其他智能体可能在做的事情。当智能体完成回答后，在循环末尾会新增一些步骤，这些步骤基本上会添加反思，从而将记忆注入回那些数据库中，供未来使用。

---

👨‍🏫 通过反馈生成记忆

除了数据，你还可以通过提供反馈来为智能体生成记忆。实现这一目标的方法是使用CrewAI训练功能。

CrewAI训练是你在终端运行的一项功能，它在执行结束时提示你为智能体提供反馈。这些反馈将被用来生成记忆，然后注入回数据库中。未来当这些智能体再次运行时，这些记忆将被重新注入到思考过程中。

总而言之，关于记忆，有两种生成方式：

1. 通过常规的执行过程，记忆被自动注入到记忆数据库中。
2. 通过带有明确指导的人类反馈进行训练，你指出智能体做对和做错的事情，从而生成记忆。

---

🗑️ 重置记忆

在某些时候，尤其是当你尝试使用记忆功能时，可能会需要了解如何重置这些记忆。好消息是，你只需要运行一个简单的命令。

crewai reset memories

这个命令会自动为你清除所有记忆，然后你可以从头开始重新创建它们，无论是通过执行智能体任务还是通过提供反馈。

---

📊 记忆的影响

无论你是通过生成记忆还是通过反馈训练，额外的上下文都能对智能体性能产生可衡量的影响，因为它有助于控制行为、格式或风格等方面。

例如，在一次反馈会话中，如果你告诉智能体你希望答案始终以Markdown格式呈现，它实际上会创建一个关于此的记忆。现在，该指令将自动添加到每次智能体执行中，从而强制使用特定的格式。或者，如果你希望它非常幽默，那将创建一个记忆，然后被注入以强制特定的风格。

由此可见，记忆实际上是一种非常强大且重要的方式，让你能更多地控制智能体的工作方式以及它们如何完成任务。

---

📚 知识：预加载的数据源

记忆并不是控制智能体的唯一方式。记忆中的数据是在执行过程中被选择性添加到上下文中的，并通过人类反馈或内部LLM作为评判来更新。

而知识则是数据，它同样被选择性添加，但它是预先添加到你的智能体中的。这意味着它不是动态生成的。如果你有特定的数据源，希望智能体在执行任务时能够意识到，你可以将这些知识预加载到智能体中，在智能体执行过程中，这些知识将被选择性使用。

这些知识源可以是：

• 文本文件（原始文本或PDF文档）
• 结构化数据（如CSV文件、Excel电子表格甚至JSON文档）

将这类数据输入到你的智能体中极其简单。你需要做的就是加载文档，然后根据知识的具体类型，使用不同的类将其嵌入到你的智能体中。

# 示例：加载知识文档（伪代码）
knowledge_base = load_documents(["file1.pdf", "data.csv"])
agent.knowledge = knowledge_base

从那时起，你就可以确保你的智能体内部拥有这些知识源。这意味着在反应循环期间，智能体现在将能够从该知识中提取相关信息片段，以提供正确的答案。这是一种非常有用的方式，可以将额外的信息包含到你的智能体中，并确保这些信息在未来的任何执行中都能持续存在。

---

🎯 总结与展望

本节课中，我们一起学习了智能体的记忆与知识。记忆（短期、长期、实体）使智能体能够从经验中学习、自我反思并与同伴共享信息。知识则允许你为智能体预加载特定的、静态的数据源。两者结合，为你提供了控制智能体、强化特定模式的方法，无论是让它们随时间自我改进，还是通过反馈或预先提供知识来实现。

记忆非常有趣，但我对接下来的课程内容更感兴趣。那就是防护栏。防护栏为你提供了比记忆和知识更具确定性的控制可能性。我非常期待这个主题。下一节我们将深入探讨防护栏的工作原理以及它们如何帮助你。我们稍后见。

015：3. 使用护栏控制智能体

在本节课中，我们将要学习如何为智能体系统添加“护栏”，以确保其输出更可靠、更可预测。我们将探讨两种主要的护栏类型：LLM护栏和代码护栏，并了解它们如何在智能体的反应循环中发挥作用，以强制执行特定的输出准则。

概述

到目前为止，你已经对智能体有了很多了解。你理解了智能体循环、如何构建智能体以及如何构建有用的东西。

但让构建变得容易只是其中一部分。另一部分是构建你信任的东西，即能提供可靠且可重复输出的东西。所以在本视频中，我们将讨论护栏。护栏是一个基石，它能让你的智能体以更可预测的方式运行。

请记住，构建智能体系统与编写传统软件工程截然不同。因为传统软件是强确定性的，而智能体系统是非确定性的。因此，护栏在如何强制智能体以不同方式行为方面扮演着重要角色。这将会非常令人兴奋。让我们开始吧。

护栏的作用

护栏允许你在智能体中添加更多确定性控制，主要通过两种方式实现：使用另一个LLM作为“法官”，或者使用确定性代码。我们将讨论这两种方式，以及它们在反应循环中扮演的角色。在下一个模块中，我们还将讨论“工作流”，如果你想深入控制，这是终极方法。但当你试图强制执行特定的输出准则时，护栏可能就能解决大部分问题。

我们已经讨论过这个反应循环，它从任务开始，最终产生一系列导致答案的行动和观察。这个过程没有任何确定性。对于大多数用例来说，这就是问题所在，它们需要非常具体的答案。你不一定每次都想要相同的答案，而是想要可靠、可重复的结果。所以答案可以不同，但每次都需要令人满意。

护栏如何融入循环

现在，我们继续讨论对话的概念，以及你的特征和提示如何影响助手。如果你仔细想想，这些模型的核心就是你发送给它们的消息和提示。在这种智能体内部思考过程的混合中，可能会出现幻觉，模型可能会给出不一定正确的答案，或者开始偏离你实际想要的内容，不仅在内容上，在格式和风格上也是如此。

这就是护栏可以发挥作用的地方，它可以作为安全检查，作为最后的防线，确保答案是令人满意的。在模块3的后面，我们还将讨论工作流，这让我非常兴奋，因为工作流是为你的自动化构建控制层的终极方式。但护栏非常棒，因为它们允许你与大量智能体一起工作。

护栏的工作机制

你强制执行特定的输出。这里的想法是，你可以使用一个护栏来验证实际的答案，然后可能发生两种情况之一。首先，答案没有通过护栏检查。这意味着答案不符合你定义的任何标准，然后它会回到循环中。但护栏实际上可以提供关于答案为何错误的额外反馈，并将其注入回反应循环，以便智能体可以做得更好。然后，如果智能体再次尝试，并且这次通过了，护栏就允许它进入下一步并给出实际答案。

护栏的酷炫之处在于，它们允许你在流程中途验证信息，因为它们是在任务级别运行的。不仅如此，它们还允许你将反馈注入回循环。你可以把这看作是一个更确定性的“人在回路”机制，你不仅可以让你的智能体与真实的人对话，现在还可以通过编程方式检查输出。

你可以使用两种类型的护栏。

护栏的两种类型

第一种是LLM护栏。这基本上是使用另一个LLM作为法官，让这个LLM进行事实核查或对消息进行某些处理，以判断其好坏。

另一种是代码护栏。你可以编写实际的代码来验证答案是否正确。

你可以在CrewAI中开箱即用地使用这两种护栏。LLM护栏稍微宽松一些，因为它依赖于另一个LLM，但构建起来极其简单。而传统的代码护栏需要你进行一些额外的编码，但允许你做到你想要的任何具体程度。

如果你考虑LLM护栏，这里发生的情况是：当智能体获得最终答案时，它会进入这个LLM护栏，然后护栏调用一个单独的LLM，根据某些特定标准检查这个答案是否合理。如果答案不合理，则返回思考过程。如果答案良好，则可以继续前进。

代码护栏的一个例子会是更确定性的东西，比如检查答案长度。你可以检查答案是什么并计算字符数。如果字符数少于200，因为你有一个硬性要求，答案必须简短，那么代码检查通过，任务完成。但如果不符合，则将其发送回反应循环。因此，在这里你可以看到，使用代码护栏，你可以非常具体，并使用常规的Python来实现这些检查。而对于LLM护栏，你可以直接告诉另一个LLM去进行事实核查或任何LLM可能能够进行的其他检查。

关于这一点很酷的是，无论你使用的是代码护栏还是LLM护栏，总会有一些关于未通过护栏的原因的反馈，你可以将其发送回去。

反馈机制

在LLM护栏的情况下，反馈将自动生成并发送回去。但在代码护栏的情况下，你可以动态设置原因，例如告诉智能体这个答案太长了，需要只有200个字符长。这些信息将被发送回反应循环，允许你的智能体接收这些信息，并尝试重写最终答案，或者采取更多行动，以实现符合护栏要求的结果。

让我给你看一些快速的代码，展示这是如何工作的。

代码护栏示例

对于代码护栏，你需要做的就是在Python中定义一个简单的函数。

这个函数将接收一个字符串作为输出参数，这基本上就是智能体发送给这个函数进行验证的内容。

在这个函数内部，你可以做任何你想做的事情。在这个例子中，我们保持简单，只检查字数是否少于200。

如果为真，它将允许你的智能体继续前进，给出最终答案，并进行下一个任务。

但如果为假，你也可以在这里包含一个原因，说明为什么它不好。这些信息将被注入回智能体，让它再试一次。

为了将护栏实际添加到智能体本身，你只需要在你的任务中添加一个新属性，即 guardrails。你也可以添加多个，因为它接受一个数组作为值，这意味着你可以添加许多不同的护栏。不仅可以是代码护栏，也可以是LLM护栏，或者任何你想要的护栏。

强制执行结构化输出

另一种获得更好结果的方法是强制执行结构化输出。这可以确保无论你从智能体和Crew中得到什么，都遵循你期望的特定格式。这可能非常有帮助，特别是如果你计划对这些数据做些什么。

所以，如果你要将这些数据发送到某个地方，比如外部应用程序，或者如果你想基于这个输出采取行动，那么最好能确切知道你得到的格式是什么。你可以在这里使用Pydantic来实际强制执行这种格式，并确保Crew的输出始终映射到你的需求。

强制执行特定格式的一个选项是使用专用的格式化智能体。这种策略更容易分配给任务，因为它使格式化成为一个专门的角色。

然而，最终的格式化强制执行是使用Pydantic模型，你可以实际使用一个单独的LLM（如果你想的话）来生成结构化的函数调用输出。

所以，你可以创建你的类，例如这个 UserQuery 类，它使用Pydantic的 BaseModel 来定义该系列属性。现在，你可以实际将这个类作为你希望从此智能体获得的输出示例传递，智能体将实际强制执行并对照该示例进行检查。

这里很酷的一点是，你可以选择在最后获得一个Pydantic对象实例，或者这个对象的JSON结构。你可以通过设置 output_pydantic 或 output_json 来指定。通过这种方式，你可以确保始终获得你关心的相同格式的输出。然后，你可以对这个结构化输出做任何你想做的事情。

例如，在这个 UserQuery 示例中，你可能希望将文本推送到数据库中，但前提是置信度分数高于0.5或0.7，或任何其他值。所以你可以看到，通过不仅定义对象，还定义你获得的属性类型，你现在可以使用这些属性来进行条件逻辑判断或许多其他事情。

总结

本节课中，我们一起学习了如何使用护栏来控制智能体的输出，使其更加可靠和可预测。我们介绍了两种主要的护栏类型：LLM护栏和代码护栏，并了解了它们如何在智能体的反应循环中验证输出、提供反馈并强制执行特定格式。通过使用护栏，你可以在非确定性的智能体系统中引入确定性的检查点，从而构建出更值得信赖的应用程序。

016：4. 使用执行钩子控制智能体

概述

在本节课中，我们将要学习如何使用执行钩子来控制智能体。执行钩子允许我们在智能体开始工作之前或完成工作之后运行自定义代码，从而实现对输入数据的预处理或输出数据的后处理，这对于构建可靠的生产系统至关重要。

正文

到目前为止，你已经了解到智能体非常强大。它们擅长动态决策并响应你提出的任何要求。

但有时你需要更多的控制权。有时你需要确保在智能体执行之前或之后运行实际的代码。

这正是执行钩子的用武之地。它允许你编写代码，这些代码将在智能体开始工作之前或刚刚结束之后运行，并利用这些代码向智能体输入数据，或从智能体中提取数据并发送到其他地方。

这是一种非常有趣的技术，根据你的使用场景，它可以发挥巨大的作用。

下面让我展示如何实现它。现在，你对 Crew 已经非常熟练了。你可能已经意识到，当你拥有一个 Crew 时，你可能希望在它开始工作之前或完成工作之后触发某些操作。

这些操作可以是多种多样的。很多时候，它涉及从某个地方加载数据，或者将数据卸载到某个地方。你可能希望利用这些数据来修改某些信息。

因此，在大多数情况下，你可能希望执行某些操作来修改进入智能体的输入，或修改从你的 Crew 输出的结果。

你可能希望在开始工作流之前以某种方式更改这些信息，或将其与其他内容结合。在工作流结束时，你可能希望将最终结果推送到 Salesforce 等系统，甚至是你的电子邮件中。

这就是钩子的作用，因为前置钩子或后置钩子允许你在相应位置编写你想要执行的代码。这就像在工作流中加入一个额外的步骤，让你可以将实际的编码逻辑引入到智能体流程中。

例如，前置钩子可能用于获取输入数据、清理输入数据、检查个人身份信息并确保将其剔除。而后置钩子则用于验证输出、审核内容、移除个人身份信息，或者仅仅是将输出记录到某处以供后续检查。

以下是一个良好的前置钩子函数示例。假设输入的一部分是一个电话号码，你需要确保其格式正确。

你在这里所做的是提取这些信息，并使用常规的 Python 代码将其分解为特定格式，然后重新将其引入到输入中。这样做可以确保进入 Crew 和智能体的数据格式正确。

以下是一个良好的后置钩子函数示例。现在你获取到了输出。假设输出中也包含电话号码，但你想将其隐藏起来。那么，你可以实现一个功能，隐藏部分数字，只显示最后四位数字，即对输出的部分进行模糊处理，然后返回处理后的输出。

现在，如果你想将这些前置钩子和后置钩子添加到你的任务中，在代码中你只需要添加这两个新属性：prehook 和 posthook。你可以看到它们都以列表作为值，这意味着你可以添加许多不同的钩子，无论是在执行前还是执行后运行，从而让你拥有很大的控制权。

归根结底，你可以看到钩子，无论是前置还是后置，在帮助你构建可靠系统方面都能发挥巨大作用。如果有一件事你会反复听到我提及，那就是：为了让系统能够投入生产，它们必须是可靠的。

你绝对可以非常轻松地使用 Crew 构建它们，无论是无代码还是专业代码方式。但当你部署它们时，你需要确保它们能提供一致的输出，并且能够控制任何进出系统的信息。

因此，归根结底，钩子的很多重点都围绕着构建可靠系统这一理念。现在，你能获得的最高级别的控制是在你使用 C eye flows 时，我们将在模块三中详细讨论这一点。

这里的理念是，Flows 允许你将实际代码与单个 LLM 调用、单个智能体或整个 Crew 融合在一起。这是能将一切整合在一起的终极支柱。

在接下来的几节课中，我们将深入探讨 Flows。我已经开始为你整合一些这方面的背景和概念。Flows 可以极其强大，因为它们允许你创建完全不涉及 LLM 的简单自动化，也能构建像我们在这里看到的更复杂的东西。

希望到目前为止你享受这个过程。下一课，我们将讨论 AI 智能体如何使用外部工具。工具是你的智能体完成工作的核心部分，因为它们使你的智能体能够做很多事情。

它们将能够接入外部资源，能够推送外部数据并在不同系统中执行操作。我相信你会对此非常感兴趣。你一定不想错过。让我们直接进入下一课。

总结

本节课中，我们一起学习了执行钩子的概念与应用。我们了解到，前置钩子可用于在智能体执行前预处理输入数据，后置钩子则用于在智能体执行后处理输出结果。通过向任务添加 prehook 和 posthook 属性，我们可以插入自定义代码逻辑，从而增强对智能体工作流的控制，这对于确保系统在生产环境中的可靠性和一致性至关重要。

017：5. 改进深度研究智能体组

在本节课中，我们将把之前学到的知识付诸实践。我们将对之前构建的深度研究智能体组进行改进，为其加入记忆功能和执行钩子，使其能力得到进一步提升。让我们开始吧。

概述

上一节我们介绍了智能体组的基本构建。本节中，我们将把深度研究智能体组提升到一个新的水平。我们不仅会优化已有的组件，还会应用一些新学到的概念，例如防护策略和回调钩子，以确保生成更高质量的报告。

从代码到配置文件

首先，我们像往常一样加载必要的模块和类，包括智能体、任务、智能体组以及搜索工具。同时，我们也会加载API密钥。

# 加载模块和工具
from crewai import Agent, Task, Crew
from tools import A_search_tool, scrape_website_tool
import os

# 加载API密钥
os.environ["OPENAI_API_KEY"] = "your_openai_key"

接下来，我们创建工具的实例，这与之前的工作方式相同。

# 创建工具实例
search_tool = A_search_tool()
scrape_tool = scrape_website_tool()

现在，我们将采用一种新的方式来定义智能体和任务：使用YAML配置文件。这样做可以将智能体的定义（如角色、目标和背景故事）与核心代码分离，使代码更清晰，也便于非技术人员参与修改。

以下是配置文件的示例结构：

agents.yaml

research_planner:
  role: 研究规划师
  goal: 制定高效的研究计划
  backstory: 你是一名资深研究策略专家...

internet_researcher:
  role: 网络研究员
  goal: 根据计划搜集详细信息
  backstory: 你是一名善于从网络获取信息的专家...

tasks.yaml

plan_research:
  description: 为给定的研究主题制定详细计划。
  expected_output: 一份包含步骤和资源的研究计划文档。

gather_info:
  description: 执行研究计划，搜集具体信息。
  expected_output: 一份包含原始数据和初步发现的信息汇总。

在代码中，我们可以轻松加载这些配置来创建智能体：

# 从YAML文件加载配置并创建智能体
import yaml

with open(‘config/agents.yaml‘) as file:
    agent_configs = yaml.safe_load(file)

agents = []
for key, config in agent_configs.items():
    agent = Agent(
        role=config[‘role‘],
        goal=config[‘goal‘],
        backstory=config[‘backstory‘],
        tools=[search_tool, scrape_tool], # 工具可以单独配置
        verbose=True # 启用详细输出日志
    )
    agents.append(agent)

通过verbose=True参数，我们可以在执行过程中看到智能体的思考过程，这对于调试和理解工作流非常有帮助。

实施防护策略

在创建任务之前，我们先建立一个“防护栏”。这是一个代码函数，用于在任务最终输出前检查其内容是否符合我们的格式和质量要求。

def report_guardrail(task_output):
    """
    检查最终报告是否包含必要部分。
    """
    output_lower = task_output.lower()
    checks = [
        ‘summary‘ in output_lower,
        ‘insight‘ in output_lower or ‘recommendation‘ in output_lower,
        ‘citation‘ in output_lower or ‘reference‘ in output_lower
    ]

    if all(checks):
        # 所有检查都通过
        return True, task_output
    else:
        # 检查失败，返回错误信息指导智能体重做
        feedback = “报告必须包含以下部分：1) 摘要（Summary）， 2) 见解或建议（Insights/Recommendations）， 3) 引用或参考文献（Citations/References）。请补充缺失的部分。”
        return False, feedback

这个函数会检查报告是否包含摘要、见解和引用。如果任何一项缺失，它会返回False和具体的反馈信息，这些信息会被传回给智能体，让其修正工作。

创建任务与分配防护栏

现在，我们从YAML文件加载任务配置并创建任务。关键的一步是将上面定义的防护栏函数分配给最终的报告撰写任务。

# 从YAML文件加载任务配置
with open(‘config/tasks.yaml‘) as file:
    task_configs = yaml.safe_load(file)

tasks = []
for key, config in task_configs.items():
    task = Task(
        description=config[‘description‘],
        expected_output=config[‘expected_output‘],
        agent=assign_appropriate_agent(key), # 需要根据逻辑分配智能体
        async_execution=False
    )
    # 如果是最终报告任务，则添加防护栏
    if key == ‘write_final_report‘:
        task.guardrail = report_guardrail
    tasks.append(task)

添加执行钩子

接下来，我们创建一个执行后钩子。钩子是在智能体组执行特定阶段（如启动前或结束后）自动运行的函数。这里我们创建一个简单的钩子，用于在智能体组运行结束后将最终报告保存为Markdown文件。

def save_report_hook(output):
    """
    将最终输出保存为文件的钩子函数。
    """
    filename = “final_research_report.md”
    with open(filename, ‘w‘, encoding=‘utf-8‘) as f:
        f.write(output)
    print(f“报告已保存至：{filename}”)

组装并运行智能体组

最后，我们将所有组件——智能体、任务、记忆功能和钩子——组装成智能体组并运行它。

# 定义智能体组
deep_research_crew = Crew(
    agents=agents,          # 我们创建的智能体列表
    tasks=tasks,            # 我们创建的任务列表
    memory=True,            # 启用记忆功能，允许跨轮次学习
    verbose=True
)

# 添加上面定义的保存报告钩子，在智能体组执行后调用
deep_research_crew.after_kickoff_callback = save_report_hook

# 定义输入并运行智能体组
research_topic = “研究用于自动化竞争性市场分析的前五大新兴AI工具”
result = deep_research_crew.kickoff(inputs={“topic”: research_topic})
print(result)

运行后，我们可以观察智能体的执行流程。研究规划师首先制定计划，研究员根据计划搜集信息，事实核查员验证信息，最后报告撰写员生成报告。如果最终报告因缺少“摘要”部分而被防护栏拒绝，报告撰写员会收到反馈并重新生成包含摘要的报告，直到通过所有检查。

总结

本节课中，我们一起学习了如何改进一个深度研究智能体组。我们引入了YAML配置文件来管理智能体和任务定义，使项目结构更清晰。我们实现了一个代码防护栏，用于自动检查输出质量并引导智能体自我修正。我们还创建了一个执行后钩子，用于自动保存工作成果。最后，我们为智能体组启用了记忆功能。通过这些改进，我们的智能体组变得更强健、更易维护，并且能产出更符合要求的成果。请尝试修改任务定义、防护栏规则或模型，亲身体验这些概念如何在实际中发挥作用。

018：6. 在智能体中使用工具 🛠️

在本节课中，我们将要学习智能体（Agent）的核心组成部分之一：工具（Tool）。工具是智能体与外部世界交互的桥梁，它们极大地扩展了智能体的能力，使其能够执行更复杂、更实用的任务。

概述：什么是工具？

智能体的一个重要特性是工具，我们之前对此讨论不多。工具允许你的智能体与外部世界进行交互，无论是发送数据、拉取数据，还是执行某些操作。当智能体拥有可支配的工具时，它们能完成许多不同的事情。这是使用智能体最酷的部分之一，也非常重要，因为它们实现了与外部世界的交互，并极大地扩展了你能构建的用例范围。

现在，让我们深入探讨工具的世界，理解如何使用它们。这非常令人兴奋，因为工具能让你的智能体完成更复杂的工作，并与外界系统进行交互。

工具的作用与形态

上一节我们介绍了工具的基本概念，本节中我们来看看工具具体能做什么。

我们已经知道，你可以在一个“团队”（Crew）中组织你的智能体，并且这个团队可以包含多个智能体。现在，这些智能体将能够利用外部资源。利用这些资源可能有几种不同的形式。

以下是几种常见的工具形态：

• 发送数据：例如，将数据写入数据库、CRM系统或ERP系统。
• 拉取数据：例如，从互联网上搜集信息、进行网络爬取、执行谷歌搜索等。
• 执行操作：例如，运行代码或在外部系统上执行某些动作。

在许多用例中，总是涉及与数据交互的元素，无论是拉取数据、更新数据还是介于两者之间的操作。而实现这一切的方式就是通过工具。工具正是允许智能体利用这些资源的关键。

为智能体配置工具

一个智能体可以拥有多个工具。如果你仔细观察，会发现你可以为智能体提供任意数量的工具。

但是，为智能体提供过多工具可能会适得其反，特别是当工具数量太多，导致智能体不知道应该使用哪个工具时。因此，根据模型大小、任务的复杂性甚至工具本身的复杂性，过多的工具可能导致智能体迷失方向，无法理解何时使用正确的工具。这又回到了将工作分解为多个智能体、多个任务和多个工具的思路。你需要确保为智能体提供足够的工具，但也要确保是合适的工具，不仅要允许智能体进行这些调用，还要记住，过多的工具可能会影响性能。

以下是一些最常见的工具类型示例：

• 涉及文件和文件夹的工具
• 查看当前文件系统的工具
• 网络爬取和浏览工具
• 数据库连接工具
• 代码执行工具

这些只是我们看到的一些例子，但还有更多可能。你甚至可以创建自己的自定义工具，以集成到内部系统中，连接公司内部运行的其他服务。

工具调用的优势与特性

关于工具调用，有几个方面需要理解。首先是它的效用：它通过将智能体与外部系统集成来扩展其能力，同时也提供了灵活性，因为你可以创建自定义工具来连接自有的系统。

其次，工具调用有一些特定的优势，特别是以下几点：

1. 错误处理：CrewAI 已经内置了强大的异常处理机制，确保失败更优雅，智能体可以自我修复。
2. 缓存机制：在整个团队执行过程中，当智能体使用工具时，系统会缓存针对特定参数的工具调用结果。这意味着如果智能体反复使用同一个工具，它不会再次调用相同的API。这不仅节省了时间、金钱和令牌，还有助于应对外部系统的可用性问题。
3. 同步/异步支持：系统同时支持同步和异步工具。这意味着你的工具可以立即返回结果，也可以有一个异步端点，允许非阻塞操作，这样智能体在等待某个工具返回时，其他智能体可以继续工作。

工具在智能体与任务中的分配

在给智能体分配工具时，有一点需要特别注意：在 CrewAI 中，工具既可以分配给智能体，也可以分配给任务。

这意味着，智能体将拥有属于其“武器库”的工具。当它们去执行任务时，将能够使用这些工具。但是，如果你为某个任务单独设置了一套工具，那么智能体在执行该任务时，其可用的工具选择将被限制在这套任务工具内，而不是它自身拥有的所有工具。

换句话说，即使一个智能体有能力写入你的CRM系统，但对于某个特定任务，如果你希望确保这不是一个可选项，你可以给这个任务分配另一套工具，而这套工具将优先于智能体自身的工具。因此，你可以通过多种不同的层级来控制智能体的实际能力，无论是直接给智能体分配工具，还是给任务分配一个用于完成该任务的工具池。

我知道这听起来可能有点复杂，但当你重用一个智能体来执行一系列不同任务，并且可能希望为它执行的每个任务都配备一个工具子集时，这实际上非常有帮助。

工具的构成：接口与代码

现在，让我们快速了解一下工具的构成，看看它有哪些组件。工具基本上由两个主要部分组成。

第一部分是一个非常简单的接口。这个接口向智能体描述如何使用它。因此，它需要有一个名称、一个描述，以及一系列关于如何使用它的输入参数。

第二部分是自定义代码。这是你可以为工具做任何事情的地方。你可能希望它与外部服务进行身份验证，可能希望它进行API调用，或者可能希望它通过其他某种协议进行服务连接。这里的核心思想是，通过这两部分的结合，你得到了一个非常简洁的包，可以传递给智能体，不仅教会它们如何使用，还告诉它们在调用后要做什么。

让我们看一个例子，例如一个“爬取网站”的工具。它的名称可能是 read_website_content。你可以看到名称可以非常具有描述性。描述本身说明了何时应该使用这个工具。在这个例子中，它“使智能体能够读取网站内容”。输入参数是网站URL。每当你的智能体尝试爬取网站时，它都会传递这个网站URL参数。然后是一些自定义代码，这是一个简单的爬取逻辑，基本上使用了HTTP请求。

在这里，你不仅可以看到这个例子，还可以构建自己的自定义工具。请记住，自定义代码可以是任何东西。事实上，我们已经为你构建了许多预制的工具，不仅用于爬取，还用于许多其他事情。如果你考虑更复杂的外部工具，例如需要适当身份验证的电子邮件、日历或文档访问工具，我们在CrewAI平台上提供了许多这样的预制工具，你可以在线查看。

如何创建自定义工具

让我展示一下自定义工具的样子。这是一个构建自定义工具的示例代码：

from crewai_tools import tool

![](https://github.com/OpenDocCN/dsai-notes-pt1-zh/raw/master/docs/dlai-crewai-mtagt-sys-2/img/e3a216053a88a19a15e3a94aa10fb071_13.png)

@tool("获取天气")
def get_weather(city: str) -> str:
    """
    获取指定城市的当前天气信息。
    参数:
        city (str): 城市名称。
    返回:
        str: 该城市的天气描述。
    """
    # 这里是自定义代码，例如调用天气API
    # 示例：模拟返回
    return f"{city}的天气是晴朗的，25摄氏度。"

你可以看到，它完全基于注解。你需要做的就是创建这样一个单一的函数，并用 @tool 注解来装饰它，这个注解会为你提供工具的名称。然后，你在函数定义中放入的描述将用于向智能体描述这个工具，而其中的代码可以是任何你想要的内容。我们保持这个例子非常简单。

现在，你可以通过设置一个名为 tools 的属性来将这些工具分配给你的智能体，这个属性实际上接受一个数组作为值，因为你可以为智能体提供多个工具。

如果你需要更多企业级连接器，比如日历、电子邮件、Salesforce、Stripe、Jira等，你实际上可以在CrewAI平台上找到它们。

对于执行操作的工具，例如写入数据库、更新CRM、生成报告，自定义代码可能涉及许多不同的事情，比如API调用、直接连接数据库、接入RAG系统或外部API等。在这里，可能性是无限的，从使用我们在开源中提供的预制工具，到编写连接现有系统的自定义工具，再到使用我们通过CrewAI平台提供的现成连接器，你有多种选择。

工具仓库与可重用性

我们还为你提供了所谓的工具仓库。以可扩展的方式构建智能体的一个重要部分是能够使用构建块来实现。可以把它想象成乐高积木，你可以在许多不同的用例中重复使用。例如，你可能希望重用同一个智能体来执行许多不同的任务，跨越许多不同的用例。对于工具也是如此，你可能构建了一个对你来说极其重要，并且可以在许多不同用例中发挥作用的工具。

因此，我们不仅允许你使用我们的CLI工具 crewai create-tool 来构建这些工具，你还可以发布这些工具，以便组织内的其他人通过执行 crewai publish 来使用。你的同事和其他人可以通过执行 crewai install 来下载这些工具。这非常重要，因为当你构建这些自定义工具时，特别是当它们触及内部系统时，你肯定希望有一种简单的方式来分发它们，以便许多人可以使用并构建其他用例。

工具的可靠性与最佳实践

你可以看到工具非常强大。我还想在工具的背景下谈谈可靠性，我认为有三个方面值得强调：

1. 强制返回：这意味着你允许智能体自动将工具的输出作为任务的最终输出。当你不想让智能体对工具返回的内容进行额外处理，只想确保智能体执行一系列步骤，并在执行到该工具时，其输出就是任务的最终结果时，这可能很有用。
2. 速率限制：其中一些工具对你可以发出的请求数量，或在特定时间段内可以发出的请求数量有严格的要求。因此，你实际上可以设置重试逻辑和最大使用限制，以确保你的智能体不会过度使用同一个工具，从而防止可能出现的故障。
3. 工具仓库：这个概念促进了跨多个智能体和任务重用和共享这些工具的想法，这对于公司来说非常有帮助，尤其是在扩展到多个用例并试图找到标准化采用这些工具的方法时。

总结与下节预告

到目前为止，你可能已经掌握了工具的重要性和强大功能。你可以用它做很多事情。但在下一节课中，我们将讨论一些能将此提升到新水平的东西，那就是 MCP。MCP正在改变集成的世界，因为它允许智能体接入许多其他公司提供的集成。你将直接进入那个主题，在实践中理解MCP，以及如何将其与你的团队和智能体一起使用，以构建更复杂的集成。我非常期待这个内容，你肯定不想错过。我们下节课见。

019：7. 为深度研究团队添加工具

在本节课中，我们将学习如何为我们的深度研究智能体团队添加自定义工具。我们将创建一个能让报告撰写智能体生成并嵌入图表的工具，从而丰富最终报告的内容。

概述

上一节我们深入了解了工具的概念。本节中，我们将把这些知识应用到我们的深度研究团队中，为其添加自定义工具。你将看到这会让团队的能力变得多么强大，我们能做的事情也更多了。这非常令人兴奋，让我们直接开始吧。

创建自定义工具

首先，我们将首次使用一个自定义工具。这非常令人兴奋，因为我们将开始理解如何通过自定义工具为你的智能体添加任何能力。你可以使用自定义工具连接到外部系统、内部系统（如数据库）或任何你可能拥有的系统。因此，在这方面你可以做很多事情。

对于本节课，我们将创建一个自定义工具，允许你的最终智能体绘制图表。这意味着它将利用为报告收集的信息来绘制某种可视化图表，并将其嵌入到最终报告的 Markdown 文件中。这个自定义工具的目的是让你的报告内容更丰富。

以下是创建自定义工具的基本结构。自定义工具通过使用 BaseTool 类来创建。我们需要确保导入这个类。然后，你的自定义工具可以像下面这样简单：你定义类名、工具名称和一些模式描述。

from crewai.tools import BaseTool

class MyCustomTool(BaseTool):
    name = "工具名称"
    description = "工具描述"
    def _run(self, argument):
        # 你的逻辑代码
        return "工具执行结果"

你可以将所有逻辑放在这个 _run 函数中，在这里你可以做任何你想做的事情，比如连接 API、连接外部系统，只需确保最后返回一个字符串作为工具的最终结果。

实现图表绘制工具

现在我们已经理解了自定义工具的结构，让我们来创建我们自己的工具。这个自定义工具将用于绘制 Seaborn 图表。

import seaborn as sns
import matplotlib.pyplot as plt
from crewai.tools import BaseTool

class PlotSeabornChartTool(BaseTool):
    name = "绘制 Seaborn 图表"
    description = "根据提供的数据和信息，使用 Seaborn 和 Matplotlib 库绘制自定义图表。"
    def _run(self, data_info):
        # 使用 data_info 中的数据绘制图表
        # 例如：sns.barplot(data=data_info)
        plt.savefig('chart.png')
        return "图表已生成并保存为 chart.png"

如果你熟悉 Python，你可能已经知道这些库了。Seaborn 和 Matplotlib 都是 Python 中用于创建自定义图表的知名库。这基本上是一个自定义绘图工具，允许智能体创建自定义图表。它在描述中提供了一些使用说明。在 _run 函数的定义中，你可以看到它从参数中获取一个名为 data_info 的参数，然后使用数据绘制一个完整的 Seaborn 图表，并将该图像提供给我们的智能体，以便它可以将其合并到最终结果中。

我们希望确保为我们的智能体提供这个工具，以便我们的报告也能获得更丰富的视觉效果。让我们创建这个工具，然后继续设置智能体。

设置工具与智能体

现在，我们将创建 SerperDevTool 和 ScrapeWebsiteTool 的实例，确保这两个工具准备就绪，并可以分配给我们的智能体。

到目前为止，你应该更熟悉工具本身的概念了，即工具是允许你的智能体与外部或内部系统交互的一种方式。请记住，这些工具可以有很多不同的形式和形态。我们在这里使用了几个由 CrewAI 预置的工具，你可以基本上将它们部署到智能体中，它们就可以工作了。

但你也正在创建我们自己的自定义工具。我们最终也会讨论如何将 LLM 用作工具，这在未来的课程中会非常令人兴奋。但这里的核心思想是，通过工具，你允许你的智能体真正接入外部世界，无论是从中提取信息、向其中推送信息，还是在其他系统中执行操作。

我们在这里所做的是接入 Serper API 在互联网上进行搜索，并使用 ScrapeWebsiteTool 来实际访问一些网站并从中获取信息。我们设置特定 Serper URL 的原因仅仅是由于我们在大多数用例中使用的学习环境。如果你在自己的电脑上使用，例如在你自己的终端中，除了设置 Serper API 密钥的环境变量外，你通常不需要这样做。

加载智能体与任务

接下来，我们加载 agents.yml 文件，并确保创建我们所有的智能体。这与上次的做法相同，这里没有什么特别之处。其基本思想是从 YAML 文件加载所有提示词，并使用它们再次实例化我们所有的智能体，非常简单直接。这里的整体思路仍然是关注点分离，你将提示词或智能体定义、任务定义放在单独的文件中，然后是智能体和任务本身。

请记住，我们仍然保留了到目前为止使用的所有功能，包括我们在上一个笔记本中实现的 Guardrails。我们要确保在这里引入那个 Guardrails，以检查最终输出和最终报告是否包含摘要部分、建议部分和引用部分。

我还想指出的一点是，在我们的报告撰写智能体上，我们正在分配我们的自定义工具。在这里你可以看到我们是如何实际操作的：基本上创建了我们刚刚在上面几个单元格中创建的那个工具的实例。就这么简单。一旦你创建了自定义工具，你需要做的就是将其分配给一个智能体，你的智能体就可以使用了。我们将在未来的课程中讨论如何确保你可以在许多不同的团队和智能体之间分发你的工具，以便于维护，并让你团队中的其他人也能使用它。但现在，你只需要担心创建一个实例并将其交给你的智能体就可以了。

接下来我们要做的是创建我们的任务，这与我们设置智能体的方式非常相似，我们现在从 YAML 文件加载这些任务，并使用数据再次实例化所有不同版本的任务。请记住，我们仍然保持上一个笔记本中的相同结构，我们仍然有那个 write_report_guardrail 来确保在实际完成之前检查最终报告。

组装并运行团队

我们从上一个笔记本带来的另一个功能是能够将最终报告保存为文件，它也将是一个 after_hook。我们保持这一点不变。让我们确保创建那个函数，以便我们可以使用它。

现在，只需将整个智能体组和任务组集合到一个单一的团队中。你可以看到我们仍然在使用记忆功能，并且我们仍然设置了那个 after_kickoff 回调函数。

现在创建完成后，剩下要做的就是实际启动团队并查看结果。现在我们有了输入，我们需要做的就是启动团队，看看我们实际从中得到了多好的结果。

查看运行结果与报告

现在，如果我们跟踪执行过程，我们可以看到相同的流程仍然有效。我们试图在这里保持简单，以确保我们能向你展示如何在我们学习这些概念的同时，将它们中的一些实现到我们的团队中。但在本节结束时，我们将看到，通过所有课程，我们将能够构建一个非常强大的系统。

现在，让我们专注于添加这个自定义工具，看看它是如何工作的。你可以看到研究规划器仍然在做它的主要工作。它试图找到一个角度，来了解这些工具以及从那时起要研究什么。然后，互联网研究员开始工作。它再次使用 SerperDevTool 来查找信息，并根据它找到的网站中的数据，然后开始抓取这些网站，以确保获得所需的所有信息。

最后，它整理出一份报告的早期草稿，其中包含所有这些公司的信息，然后传递给我们的 FactCheckerAgent。现在我们可以暂时跳过它，直接进入我们的最终报告，看看它是什么样子。

如果你在这里查看报告，会发现很有趣，因为它从事实检查器获取了所有信息，但现在它使用了我们的自定义工具来创建自定义图表。你可以看到它分享了一些信息，然后绘制了一个特定的 PNG 文件，该文件将被注入到最终报告中。然后，同一个报告撰写智能体构建了整个报告，并实际将图像嵌入其中，你可以在“视觉数据表示”部分看到。

但随后 Guardrails 启动，并注意到缺少一个“见解”部分。然后智能体需要返回进行编辑。从那时起，智能体决定绘制一个不同的图表并再次编辑其报告。Guardrails 发现缺少“引用”部分。所以智能体又回去添加。在这里，你可以看到我们讨论的所有不同部分汇集在一起，从自定义工具到实际的 Guardrails，以及介于两者之间的一切，共同构建了这份最终报告。

现在，如果我们继续向下滚动，我们实际上得到了这份最终报告，并且我们可以实际将其输出，因为请记住，我们使用一个 after_hook 将其保存为 Markdown 文件。我可以进入一个新单元格，直接输出那份研究报告。我们可以看到整个报告。你可以浏览所有报告内容。你可以看到它发现的那些新兴工具。你可以看到功能和局限性，甚至它能够绘制的图表，基本上显示了这些工具的每月 AI 成本。

总结

本节课中，我们一起学习了如何为深度研究智能体团队添加自定义工具。我们创建了一个图表绘制工具，并将其集成到报告撰写智能体中，从而让最终报告包含了可视化数据。这个过程展示了如何通过工具扩展智能体的能力，使其不仅能处理文本信息，还能生成和嵌入图表，极大地丰富了输出内容。

我们看到了从研究规划、信息搜索、事实核查到报告撰写和 Guardrails 检查的完整流程。随着我们不断添加新功能，这个团队的能力正在逐步增强。在接下来的课程中，我们将添加更多功能，以确保报告内容真实可靠，并遵循特定格式。

020：采用模型上下文协议（MCP）🚀

概述

在本节课中，我们将学习一个当前非常热门的话题：模型上下文协议（MCP）。我们将了解MCP是什么、它如何工作，以及在采用它之前需要考虑的一些事项。MCP可以非常强大，是智能体技术栈中的重要组成部分，但理解其幕后工作原理至关重要。

---

什么是MCP？🤔

上一节我们介绍了MCP的重要性，本节中我们来看看MCP的具体定义。

MCP是一个开放协议，由社区开发并由Anthropic发起。其核心思想是建立一个通用层和通用约定，规定智能体如何访问工具、资源和提示。MCP正变得相当知名，特别是因为它建立在一些已经非常成功的技术之上。

核心概念：MCP = 一个基于JSON-RPC 2.0的开放协议，用于标准化智能体对工具和资源的访问。

---

MCP解决的问题：集成碎片化🧩

在深入MCP的细节之前，了解它要解决什么问题很有帮助。现有的系统和工具暴露其功能的方式各不相同。

以下是现有集成方式面临的一些挑战：

• 方式多样：有些应用通过OAuth集成暴露，有些使用常规API，有些则使用套接字。
• 阻碍开发：这些不同的模式和方式可能会阻碍系统启动和运行，因为开发者可能陷入“集成地狱”，忙于构建集成而无法完成有意义的任务。
• 适配器复杂：这些集成通常需要大量定制的适配器，以确保以正确的方式使用正确的工具。
• 工具共享困难：在不同智能体之间共享工具变得非常困难，从一个智能体或工具切换到另一个时，使用方式可能截然不同。

历史上，甚至有整个公司（如Zapier、IFTTT和Make）的业务核心就是为用户管理和构建这些集成之间的“粘合层”。这种碎片化使得构建集成的人更加困难，也使得依赖这些集成的客户更加困难。这就是MCP和协议整体成为AI领域热门话题的主要原因。

---

MCP的工作原理：客户端-服务器架构⚙️

理解了问题所在，现在我们来看看MCP是如何通过其架构来解决这些问题的。

使用MCP时，你的智能体可以调用一个MCP客户端，该客户端随后将其路由到一个MCP服务器，从而让你能够访问另一端的工具。在CrewAI中，你无需担心设置客户端或服务器，这非常简单。

核心流程：

你的智能体 -> MCP客户端 -> MCP服务器 -> 外部工具/资源

你需要做的就是启动你的智能体，并将其指向一个特定的MCP服务器。基于此，智能体就可以访问该服务器提供的所有不同资源。你只需要知道特定的服务器配置和要使用的协议，并在你的Crew或智能体上进行设置，智能体就能够利用所有这些工具。

这一切都发生在一个众人皆知的、用于工具的开放协议之后，底层使用JSON-RPC 2.0。这种客户端-服务器架构的思想允许你构建一个单一的层来将所有这些东西连接在一起。

---

有MCP与无MCP的世界🌍

为了更直观地理解MCP带来的改变，我们可以对比一下有MCP和没有MCP的集成世界。

• 没有MCP的世界：可以看作是一种 M x N 的复杂性。为了将你的解决方案与已有的工具集成，你需要为每个工具组合构建自定义连接器（如果它们尚不存在）。
• 有MCP的世界：你可以连接到任何遵循该协议的工具。这是一种 M + N 的抽象，允许你更快地移动，尤其是当你将更多工具纳入囊中时。

---

MCP的核心组件🔧

现在，让我们具体看看MCP由哪些基本构件组成。

MCP包含三个基本原语（Primitives）：

1. 工具（Tools）：智能体可以执行的操作或函数。
2. 提示（Prompts）：可重用的提示模板。
3. 资源（Resources）：智能体可以读取或访问的数据源。

此外，还有暴露或传输这些数据的方式，主要有三种：

• 标准I/O
• SSE（服务器发送事件）
• 流式HTTP

本质上，这些只是访问那些服务器和调用那些工具的不同方式。真正重要的是你在这样做时使用的格式。

---

CrewAI 中的 MCP 支持🤖

了解了MCP的构成，我们来看看如何在CrewAI中实际应用它。

CrewAI原生支持MCP。Crew内部和外部的智能体都可以使用MCP。这允许它们在运行时动态发现和聚合这些工具。

此外，Crew本身也可以成为MCP服务器。当你在CrewAI平台上部署一个Crew时，可以自动将其导出为服务器，允许其他智能体像使用工具一样使用它们。

---

实战示例：连接Box MCP服务器📦

理论需要联系实际，下面我们通过一个具体例子来演示如何使用MCP服务器。

Box公司开发了一个MCP服务器，将其部分功能提供给智能体使用。如果你使用CrewAI运行一个智能体，可以通过声明你希望智能体如何连接以及想要使用什么协议，轻松连接到Box。你可以在智能体级别或在包含智能体的Crew内部进行设置。

使用起来极其简单，只需要为AI工具安装一个具有特定依赖项的特定扩展来设置你的服务器。设置完成后，只需用MCP服务器适配器包装你的智能体定义，或者赋予你的智能体访问MCP工具的权限。

这意味着你的智能体现在可以自动接入这些集成，并在执行过程中自动利用Box所暴露的那些操作和功能。例如，从文件中提取特定功能是Box暴露的功能之一，智能体可以利用它来提取信息以构建最终报告。

代码示例：

# 导入MCP服务器适配器
from crewai_tools import mcp

![](https://github.com/OpenDocCN/dsai-notes-pt1-zh/raw/master/docs/dlai-crewai-mtagt-sys-2/img/45447aeefd621bfd4408cdb2fe9572b2_8.png)

# 设置服务器属性（URL，传输层）
server_config = {
    “url”: “your_mcp_server_url”,
    “transport”: “sse” # 或 “http”, “stdio”
}

# 用适配器包装你的智能体或Crew
@mcp.server(**server_config)
def define_my_agent():
    # 这里是你的智能体定义
    agent = Agent(
        role=“数据分析师”,
        goal=“从Box文件中提取数据并生成报告”,
        tools=[], # 工具会自动从MCP服务器注入
        verbose=True
    )
    return agent

# 然后像使用常规工具一样使用这些工具

通过这样做，你就自动将你的智能体暴露给该服务器中所有可用的内容。在这个代码块中，你还可以过滤掉一些MCP工具，以便更精确地控制你想要发生的事情。

---

MCP 采用前的安全考量⚠️

在兴奋地使用这些MCP功能之前，必须讨论一些安全防护措施。

在使用任何MCP服务器之前，你需要确保你信任它。这是一个重要的免责声明，因为这是一个全新的协议，尚未经过多年实战考验。这意味着现在有很多人正试图破解它，对于不熟悉协议的人来说，已经证明存在一些需要关注的问题。

所有这些问题都在被快速解决，但在使用服务器前，请务必确保你信任它。请记住，MCP服务器返回的信息会传递给你的智能体和LLM，这创造了它们进行提示注入的可能性——即返回信息试图对你的智能体进行提示注入。传输层本身也可能存在漏洞。

安全建议：

• 确保SSE传输得到妥善保护。
• 始终验证任何传入SSE连接上的来源头（Origin headers）。
• 避免将服务器绑定到所有本地接口，必要时仅绑定到localhost。
• 为所有SSE连接实施适当的身份验证。

没有这些保护措施，攻击者可能使用DNS重绑定来与本地MCP服务器进行远程网站交互。因此，在采用这些尖端技术时，请务必注意这一点。

---

MCP 的前景与总结✨

尽管存在上述担忧，MCP在特定条件下确实大放异彩，特别适合重用工具。

MCP的前景非常广阔。它允许你在不同的框架、工作流和智能体之间使用工具。它为大型组织的集成提供了标准，甚至允许你将你自己的Crew作为服务暴露出来。当然，目前对于小型和简单的脚本来说存在一些开销，但MCP正在帮助解决这个问题。因此，MCP有很多优势。

在本模块中，我们讨论了许多内容：工具仓库、MCP。现在是时候讨论如何以以前无法做到的方式来构建这些智能体了。我将在下一课中通过使用无代码UI构建智能体来展示这一点。这不仅使不会编码的人受益，也使工程师受益，因为他们可以更快地行动，极其迅速地构建出Crew的初版，然后在此基础上快速迭代。

我对下一课要展示的内容感到非常兴奋。完全不写代码就能构建一些智能体，而且它们可以如此复杂，这简直令人难以置信。它们甚至可以自己编写自定义工具，或与极其复杂的应用程序集成。请务必关注下一个视频，因为它将深入探讨无代码构建智能体，我对此非常期待。

---

总结

本节课中，我们一起深入学习了模型上下文协议（MCP）。我们从MCP的定义和它要解决的集成碎片化问题开始，了解了其客户端-服务器架构的工作原理，并对比了有MCP和没有MCP的集成世界。我们剖析了MCP的核心组件（工具、提示、资源），并学习了如何在CrewAI中实际使用MCP，包括通过Box示例进行实战演示。最后，我们强调了在采用MCP时必须考虑的安全问题，并展望了其未来前景。MCP作为一个标准化协议，为智能体生态的互联互通和快速发展奠定了重要基础。

021：9.构建无代码智能体 🚀

在本节课中，我们将学习如何从编写代码转向使用无代码方式构建智能体。我们将通过简单的提示来创建自动化流程，并最终将其导出为代码，以便进行更深入的定制和开发。

---

概述

上一节我们介绍了通过代码构建智能体系统的基础。本节中，我们将探索一个强大的无代码平台，它允许我们仅通过自然语言描述来设计和部署多智能体工作流。这种方法能极大地加速从概念到实现的过程。

平台入门

首先，我们需要访问平台。以下是初始步骤：

1. 访问 app.query.com。
2. 如果你是首次使用，点击“注册”创建新账户。
3. 登录后，你将看到主界面，可以直接开始通过聊天构建用例。

这个平台的核心是，你可以通过对话描述你想要的功能，系统会自动将其转化为一个可视化的智能体工作流。

构建一个销售用例

让我们尝试构建一个对销售团队非常有用的自动化流程：销售会议准备助手。

我输入了以下提示：

“给定某人的邮箱，深度研究此人及其公司，并结合HubSpot中的相关数据以及我们在Gmail中往来的邮件，为我生成一份初次销售电话的最终报告。”

尽管提示中有一些拼写错误，但系统能够理解并开始构建。

提交提示后，界面会切换到“工作室”视图。左侧是聊天记录，右侧是自动生成的自动化流程图。你可以在此拖放组件进行自定义，顶部则有运行自动化和查看日志的选项。

系统自动构建的流程

关闭教程弹窗后，我们可以看到系统已经自动为我们创建了完整的智能体工作流：

• 智能体1：负责搜索互联网和阅读网站内容。
• 智能体2：负责研究HubSpot数据。
• 智能体3：负责查看Gmail邮件。

所有智能体和工具都已配置完毕。对于一个全新账户，这无需任何自定义设置。当然，要使用HubSpot和Gmail，我需要点击相应区域进行授权认证，但整体构建过程非常简单。

运行与验证

系统会继续完善流程，验证一切是否就绪，并为流程命名。虽然我的HubSpot和Gmail尚未连接，但我们仍然可以测试运行。

点击运行按钮后，系统会询问目标邮箱地址。为了演示，我输入了自己的邮箱，模拟即将与自己进行会议的场景。

随后，我们可以看到第一个智能体开始执行任务。在“执行”页面，我们可以查看每一次调用的详细追踪记录，包括：

• 内部使用的提示词。
• 原始数据。
• 工具调用情况。
• 所有中间结果，甚至包括爬取的网站信息。
• 最终答案。

查看结果

回到可视化编辑器，点击查看最终任务输出。例如，研究我的智能体发现我是CrewAI的创始人兼CEO，找到了我的背景信息、LinkedIn资料，以及关于公司的许多信息，包括近期发展与和PwC的合作关系等。

这展示了我们能够多么轻松地搭建起这样一个系统，而这仅仅是自动化可能性的冰山一角。

从无代码到代码

重要的是，你不仅限于聊天构建。你随时可以拖放自定义的智能体、任务和工具，并以任何你喜欢的方式连接它们。

更强大的是，假设你已经设置好一切，你可以将整个工作流下载为代码。例如，在清理掉未连接的智能体和工具后，点击下载按钮，你将获得一个包含全部代码的ZIP文件。这意味着你可以继续在Python环境中修改和扩展它。

这不仅让非技术人员和工程师都能构建自动化流程，也帮助工程师更快地构建原型、更快地实现价值，因为你无需从头搭建基础框架，可以直接进入MVP（最小可行产品）阶段并进行后续优化。

总结

本节课中，我们一起学习了如何使用无代码平台快速构建多智能体系统。我们通过一个销售准备用例，演示了如何用自然语言提示生成完整工作流，如何运行和调试，以及最终如何将无代码项目导出为可进一步开发的Python代码。这种方法显著提升了开发效率，是快速验证想法和实现自动化的强大工具。

如果你想尝试这个工作室，请访问 app.query.com。我们下节课再见。

022：协作模式设计 🧩

概述

在本节课中，我们将学习如何设计多智能体系统中的协作模式。我们将探讨为何将复杂任务分解给多个专业智能体，比使用单一通用智能体能产生更高质量的输出，并了解如何通过配置角色、目标和模型来优化每个智能体的表现。

---

智能体协作的核心挑战

上一节我们介绍了如何将任务分解给不同的智能体和任务。本节中我们来看看控制它们协作与工作方式的不同方法。

每个智能体本质上都在与其背后的大语言模型进行交互。所有不同的组成部分，例如系统提示词、角色定义、聊天历史记录，以及所有数据，每一次对大语言模型的请求都经过优化，以适配智能体及其模块的上下文。

这一切会整合成一个完整的请求包。然而，随着智能体持续工作，其上下文范围开始扩大。你可能开始为其添加更多工具并赋予更复杂的任务。

# 示例：智能体上下文随工具和任务增加而扩展
agent.add_tool(tool1)
agent.add_tool(tool2)
agent.assign_task(complex_task)

这会增加大语言模型可访问的选项、想法和过往对话的数量。所有这些信息在某个时刻将突破大语言模型的上下文长度限制。

问题不仅在于上下文长度本身，还会导致性能下降。一些更精细的信息可能无法放入模型上下文，同时越来越多不相关的信息被包含进来。智能体开始偏离其核心职责，出现目标模糊的情况，导致智能体难以决定何时使用何种工具。

这里的核心观点是：扩展智能体的职责范围，可能会因上下文控制不够精确而降低输出质量。

---

解决方案：专业化优于通用化

因此，正确的组合方式不是让一个智能体做太多不同的事情，而是让每个智能体专注于自己的任务，拥有自己的上下文、系统提示词和角色设定。

通过使用多个专业化的智能体，而非一个通用型智能体，你可以分解上下文，使每个智能体只获取与其目标和目的相关的信息。这些结果的总和，将远优于让单一智能体处理所有事情。

将所有智能体的输出整合起来，你将获得前所未有的高质量输出。

需要明确的是，生成式系统的后端由多个智能体分解处理，但这并不意味着用户体验也必须如此。用户体验可能仍然是与单一智能体对话的界面，但在幕后，是多个智能体在协同完成工作。

---

构建高效智能体的要素

以下是构建高效智能体的三个核心要素：

1. 角色：明确智能体的专业身份。
2. 目标：定义智能体需要完成的具体任务。
3. 背景故事：提供上下文，帮助智能体理解其职责范围。

其核心理念是：通过提供高质量输入，帮助智能体塑造其专业角色。

回顾经典的客户支持用例，那些智能体可以专门化于分析工单、检索知识库，并在可能时尝试自行解决工单。

例如，其中一个智能体可以是工程师智能体，如果问题是一个程序错误，它可以尝试编写代码来修复。通过明确定义每个智能体的单一职责，你可以取得惊人的效果。

如果要用一句话总结：优先选择专家型智能体，而非通才型智能体。专注的智能体能提供更精确的输出。

一个好的命名示例是：将智能体命名为“技术博客写手智能体”，而不是笼统的“写手智能体”，如果其目标是创建技术博客内容。这样，你在角色上实现了专业化，同时在整个智能体团队中保持了功能的多样性。

---

模型选择：平衡速度与质量

除了角色、目标和背景故事，另一个可以定制智能体的关键因素是其所使用的大语言模型。

在这里，你不仅可以选择角色、目标和背景故事，还能选择每个智能体使用的模型。例如，如果你发现Claude在撰写技术博客方面比GPT-4表现更好，你可以专门指定该智能体使用那个模型。

因此，根据每个智能体的角色和目标，你可能还需要为其选择最合适的大语言模型。你需要在速度和质量之间取得平衡。较小的模型通常更便宜、更快，因此在需要速度的场景下表现出色；而较大的模型通常具备更强的推理能力，能更好地遵循指令，并且通常拥有更大的上下文窗口。

当质量对你至关重要时，你可能会选择更大的模型。在你的智能体团队中，可以混合使用不同模型的智能体，这正是使用CrewAI的优势之一。

最终，你始终要确保获得一致、可靠、可重复的结果。为了实现这一点，你需要进行规划，理解在质量、速度和你期望的正确结果之间取得何种平衡。

例如：

• 处理客户评论并在将问题转交正确部门后撰写回复时，你可能会选择更大的模型以获得高质量的回复。
• 进行股票分析时，可能选择较小的模型来研究和抓取网页数据、提取关键数字，而使用更大的模型来制定交易策略。

---

总结

本节课中，我们一起学习了将工作分解给多个智能体和任务如何能带来比单一智能体更优的结果。我们探讨了如何不仅通过角色、目标和背景故事进行优化，甚至可以通过为不同智能体选择不同的大语言模型来提升整体表现。利用多个模型提供商，你可以获得更好的综合结果。

在下一个视频中，你将看到可以为智能体设置的多种不同通信模式。这将是一个非常有趣的话题，可能会为你解锁更多的应用场景。

023：多智能体通信模式

在本节课中，我们将学习多智能体系统中的通信模式。我们将探讨智能体如何协作、交换信息，以及如何通过不同的流程设计来优化系统性能。

上一节我们介绍了智能体之间的协作，本节中我们来看看它们如何进行通信。

多智能体系统没有一种通用的解决方案，就像任何技术生态系统一样。设计系统架构需要深入思考。这非常令人兴奋，让我们直接开始。

你已经了解了单智能体甚至多智能体的强大功能，也知道了在设置智能体的各个方面，甚至它们将使用的工具时，你拥有多大的控制权。但多智能体系统的一个挑战在于，你必须定义它们之间如何协作，而这会变得非常有趣。

顺序流程

CrewAI 的默认行为是智能体以顺序方式工作。这意味着你定义智能体，任务将定义处理事务的顺序。

一个很好的例子是股票交易分析：第一个智能体挑选一支股票，第二个智能体获得挑选结果后进行深入研究，提取大量信息，最后一个智能体将报告整合在一起。

在这种情况下，一个任务的输出会作为下一个任务的输入。

除了顺序流，你还可以让智能体相互委托工作和提问。例如，在某个时刻，最后的报告智能体如果对为何选择某支股票有疑问，它可以回头询问最初的智能体选择的原因。

这里的核心思想是，在整个执行过程中，每个智能体的任务为下一个智能体提供上下文。这意味着它的输出将被注入到下一个智能体的提示中。

聚合上下文

有时，你需要更多的控制，确保将一个智能体的任务输出提供给多个不同的任务。编码团队就是一个很好的例子。

这些智能体旨在创建软件。你可能有一个初始的规划智能体、一个任务分解智能体，然后是一个编码智能体。

规划者会思考规范以及如何实现最终目标。任务分解者会接收该计划，并用来编写一系列单元任务。但编码者是实际完成大部分工作的智能体，它需要同时访问计划本身和分解后的任务。

在 CrewAI 中，这非常容易实现。你可以看到，对于任务分解任务，我们通过 context 参数明确指出其上下文是规划任务的输出。然后，最终的创建应用程序任务可以汇集之前两个任务（规划和测试）的结果，你可以在其 context 参数中精确指定这一点。

并行流程

顺序流程只是冰山一角，还有许多其他流程模式。并行处理是另一种选择。当然，对于其他用例，你不必局限于顺序流程。

在并行流程中，可能有许多智能体同时工作，执行各自的任务。它们可能会在进展过程中传递任务结果，但核心思想是它们有能力并行完成工作，从而显著减少延迟，加快最终输出的获取速度。

分层流程

你还可以使用分层流程，其中一个单独的智能体将工作委托给其他智能体。这种管理型智能体不仅会分配工作，还会在工作完成后进行审查。

这个第一个智能体基本上是其他智能体的“老板”，决定谁做什么，并检查输出以确保其符合标准，如果不符合则要求改进。这种策略可能会因为额外的 LLM 调用而略微增加处理时间，但尽管存在来回通信，它在设计上对于完成更复杂的任务非常有用。

内存与通信

无论你选择哪种流程（顺序、并行或分层），每个 Crew 中都始终存在一个内存层。这个内存层由我们在上一个模块中讨论过的三种内存类型组成：短期记忆、长期记忆和实体记忆。我想花些时间谈谈它们如何影响智能体之间的通信。

短期记忆是非常短暂的，意味着它在每次 Crew 执行后都会被清除。其核心思想是，Crew 中的所有智能体都贡献并共享同一个短期记忆存储。智能体会自动将此短期记忆作为 CrewAI 上下文管理的一部分，因此它们知道其他智能体一直在做什么，以及是否有任何相关信息可供使用。需要注意的是，在并行执行期间，任何给定的智能体可能在任何给定时间都未完成其任务，因此其输出可能尚未进入共享的短期记忆。

长期记忆也是共享的，但更具持久性。智能体可以在多次不同的执行中使用此记忆。因此，智能体在完成任务的过程中会进行自我批判，并从彼此的错误中学习。如果一个智能体犯了错误，其他智能体也可以通过访问这个长期记忆来使用和学习。

实体记忆的工作方式类似，Crew 不必反复了解相同的对象、人物或地点，因为它们会将这些信息写入实体记忆，所有智能体都可以访问。例如，当一个智能体研究了一个特定人物后，其他智能体可以看到这一点，如果它们可以直接从实体记忆中检索，就不会再要求研究同一个人。

常见协调问题与解决方案

在通信模式中，有一些常见的协调问题，你在构建自己的用例时应该注意。我们经常看到的主要有几个问题。

冗余工作：智能体重叠并执行相同的任务或非常相似的任务，使用相同的工具并进行相同的搜索，导致效率低下。如果智能体相互干扰，你应该界定每个任务的范围，使它们不重叠。你也可以尝试从并行流程开始，然后在需要时转向更复杂的分层流程。但我确实看到顺序流程完成了大部分工作。

决策链延迟：当你有一系列高延迟的逐步决策链时，会出现另一个问题。这通常发生在你添加更多智能体和任务，但没有区分哪些可以并发运行与哪些必须顺序运行时，从而拖慢整个自动化过程。这是因为你让智能体依赖于早期发生的任务，而它们可能甚至不需要那些任务的结果来完成自己的工作。

为了避免这种情况，请确保识别可以异步运行的任务，并用 async_execution=True 标记它们。这将确保所有这些执行并行完成。如果你想引用这些任务的输出，可以像我们之前看到的那样使用 context 参数，将上下文引入不同的任务。

总结与展望

现在，让我们稍微退一步。你确实有很多选择。我们讨论了顺序流程、分层流程、混合模式（一个智能体将任务发送给多个智能体，然后将上下文汇集回一个智能体），以及通过并行实现同步执行。这里面有很多内容。

因此，确实有很多不同的方式可以将系统组合在一起，这不仅允许你定义智能体如何协同工作，还允许你定义它们之间交换多少信息，从而让你对每个智能体完成任务所拥有的上下文有更精细的控制。

在下一节中，我们将分享一些非常令人兴奋的内容，因为我们将使用 CrewAI 来实现其中一些新的协调模式。顺便说一下，CrewAI 是我最喜欢的工具之一，所以我对此感到非常兴奋，我现在就迫不及待想开始了。

本节课中我们一起学习了多智能体系统中的多种通信与协调模式，包括顺序、并行、分层流程，以及内存系统如何支持智能体协作。我们还探讨了常见的协调问题及其解决方案，为设计高效的多智能体系统奠定了基础。

024：构建协调模式 🧩

在本节课中，我们将学习如何将之前介绍的智能体协作与通信方式整合到一个实际用例中。我们将从顺序流程转向混合流程，并探索如何让单个智能体异步执行多个任务。

---

概述

上一节我们介绍了智能体间的各种协作方式。本节中，我们将通过一个实际代码案例来应用这些知识。我们将构建一个“深度研究”智能体团队，其中单个智能体会同时处理多个研究任务，并最终生成一份综合报告。

---

从顺序流程到混合流程

首先，我们将从顺序执行流程转向更灵活的混合流程。这意味着我们将改变智能体、任务和团队的工作方式。

以下是核心变化：

• 从单一顺序执行，变为部分任务可并行执行。
• 单个智能体将能够同时处理多个任务。

---

构建项目结构

我们将采用一种新的CrewAI方法来创建项目结构，它会自动为我们搭建好整个框架。

你无需立即在Jupyter Notebook中运行此命令，因为相关文件夹已预先设置好。但为了演示，我们将从头开始创建。

运行以下命令来创建名为“deep_research_crew”的团队：

crewai create crew deep_research_crew

运行后，CrewAI会引导你进行一系列选择来设置整个项目脚手架。例如，它会询问你想使用的模型。为了简单起见，我们选择OpenAI和GPT-4o模型。

完成后，你会看到项目生成了完整的文件夹结构，包括：

• knowledge 文件夹：存放智能体的背景知识。
• src 文件夹：存放源代码。
• tasks 文件夹：存放任务定义。
• pyproject.toml 文件：管理项目依赖。

在src/deep_research_crew目录下，你会找到核心的crew.py文件，以及config和tools文件夹。config文件夹用于存放智能体和任务的YAML配置文件，tools文件夹用于存放自定义工具。

---

配置智能体与任务

现在，我们需要配置具体的智能体和任务。

首先，进入config文件夹，打开agents.yaml文件。系统已预生成了一些示例智能体，我们需要将其替换为我们实际需要的智能体配置。

以下是我们的智能体配置示例：

research_planner:
  role: 研究规划师
  goal: 为研究任务制定清晰、可执行的计划
  backstory: 你是一位经验丰富的研究项目经理，擅长分解复杂主题并规划高效的研究路径。

top_researcher:
  role: 顶级研究员
  goal: 进行深入、准确且全面的主题研究
  backstory: 你是一位孜孜不倦的研究专家，擅长从海量信息中提取关键洞察。

fact_checker:
  role: 事实核查员
  goal: 确保所有研究信息的准确性和可靠性
  backstory: 你是一位严谨的编辑，对细节有着敏锐的洞察力，致力于消除错误信息。

report_writer:
  role: 报告撰写员
  goal: 将研究发现整合成结构清晰、内容翔实的最终报告
  backstory: 你是一位技术作家，擅长将复杂信息转化为易于理解的格式。

接下来，配置任务。打开tasks.yaml文件，同样替换为我们的任务配置。

我们的任务发生了一些变化。请注意，creative_research_plan任务现在需要处理一个主主题和一个次主题。随后，这两个主题的研究将由同一个智能体top_researcher并行执行。

creative_research_plan:
  description: 为“{main_topic}”和“{secondary_topic}”制定详细的研究计划。
  agent: research_planner

research_main_topic:
  description: 根据研究计划，深入研究主主题“{main_topic}”。
  agent: top_researcher
  context: [creative_research_plan] # 依赖前一个任务的输出

research_secondary_topic:
  description: 根据研究计划，深入研究次主题“{secondary_topic}”。
  agent: top_researcher
  context: [creative_research_plan] # 依赖同一个研究计划

关键点在于，research_main_topic和research_secondary_topic这两个任务将同步执行（即并行），因为它们都依赖于同一个creative_research_plan任务的输出。

---

添加背景知识与工具

为了让智能体在任务开始时就了解一些背景信息，我们可以使用knowledge文件夹。在user_preferences.md文件中，可以添加任何内部政策或用户偏好。

例如：

用户姓名：Joe Doe
职业：AI工程师
兴趣：对智能体技术感兴趣
所在地：美国加利福尼亚州旧金山

接下来，我们需要将之前用过的图表生成自定义工具集成进来。将工具代码复制到tools文件夹下的chart_generator_tool.py文件中。

此外，我们还需要设置防护规则（Guardrails）。在项目根目录创建一个guardrails文件夹，并在其中创建report_guardrail.py文件，用于存放检查最终报告内容的防护规则代码。

---

整合团队代码

现在，让我们查看并理解主文件src/deep_research_crew/crew.py中的代码。

该文件使用了装饰器来简化配置。@crew装饰器标注了整个团队类，@agent和@task装饰器用于标注智能体和任务。这样，我们可以直接引用YAML配置文件中的设置，而无需手动加载。

在智能体定义部分，我们可以指定每个智能体使用的模型。例如，可以让research_planner使用更快的gpt-4o-mini，而其他智能体使用gpt-4o。

我们还需要导入之前创建的图表生成工具，并将其分配给report_writer智能体使用。

在任务定义部分，我们通过context属性设定了依赖关系。最重要的是，我们通过配置实现了research_main_topic和research_secondary_topic这两个任务的同步执行。

团队配置部分将智能体、任务、内存（Memory）和流程类型（此处为混合流程）整合在一起。我们还使用了output_file属性来替代之前的回调函数，用于直接保存任务输出。

最后，我们通过knowledge_sources参数加载了用户偏好知识。

---

运行团队并查看结果

一切就绪后，我们可以在终端运行以下命令来启动整个团队：

crewai run

执行过程中，你会观察到：

1. creative_research_plan任务首先执行，并利用了knowledge中的背景信息。
2. 随后，research_main_topic和research_secondary_topic两个任务同时启动、并行执行。
3. 两个研究任务完成后，事实核查任务开始。
4. 最后，报告撰写任务整合所有信息，并应用防护规则，生成最终报告。

报告生成后，我们可以在Jupyter Notebook中渲染其Markdown格式，查看详细的研究发现、信息来源链接以及生成的图表。

---

总结

本节课中，我们一起学习了如何构建一个协调模式复杂的多智能体系统。我们从顺序流程演进到混合流程，实现了单个智能体并行处理多个任务。我们利用CrewAI的项目结构、装饰器配置、背景知识注入和自定义工具，构建了一个高效、可扩展的深度研究团队。你可以基于此结构，进一步尝试批判性测试或训练，以优化结果。

我们已涵盖了多种流程类型和智能体连接模式。接下来，我们将探讨智能体与外部智能体通信的一种新兴且备受关注的协议：A2A（智能体对智能体）协议。

025：4. 使用 A2A 协议 🚀

概述

在本节课中，我们将要学习 A2A 协议。这是一个新兴的协议，旨在让不同的人工智能智能体能够在网络上相互通信与协作。我们将探讨它的核心概念、工作原理，以及它如何与 CrewAI 框架集成。

---

A2A 协议简介

目前，全球范围内有大量的智能体正在运行，其中许多已经在线。有时，你的智能体需要与网络上的其他智能体进行协作。A2A 协议正是一个为此目的而设计的协议，它获得了广泛的关注，并且越来越多的人开始使用它。

上一节我们讨论了 MCP 协议，现在让我们来看看 A2A。当我们讨论 MCP 时，我们提到了一种允许智能体调用外部工具的方法。而 A2A 则更进一步，它允许智能体调用外部的其他智能体。

这是一个相对较新的协议，但已经开始获得关注，并且已经被 CrewAI 以及许多其他框架和供应商所支持。与 MCP 一样，它也是一个开放标准，并围绕几个关键原则构建。

A2A 的核心原则与组件

A2A 协议的核心思想是让智能体间的通信变得极其简单。它采用了与 MCP 类似的 gRPC 和 SSE 技术，并确保遵循严格的安全和监控准则。

该协议的核心是让智能体之间能够交换消息、分配任务并共享成果。以下是 A2A 协议的主要组成部分：

以下是 A2A 协议的核心组件：

• 智能体卡片：用于标识一个智能体，描述其能力、可以执行的任务以及可能需要的任何要求。
• 任务：这是一个有状态的工作单元，你将某项工作委托给智能体去完成。这与 CrewAI 中任务的概念非常相似。
• 消息：这是智能体之间进行交互的载体，它们通过消息进行对话。
• 成果物：这是任务执行后产生的具体、有形的输出。

你可以看到，这些概念与我们目前在 CrewAI 中讨论的许多内容都能对应起来。这也解释了为什么 A2A 协议能获得如此多的关注。它创建了一个通用层，使得来自不同技术栈的智能体能够相互通信。

A2A 与 MCP 的区别

现在，我们需要明确区分 A2A 和 MCP 协议。

• 使用 MCP，你允许你的大语言模型或智能体连接到外部的工具和无状态数据集（例如，提示词等）。
• 使用 A2A，你实际上是在让一个智能体触发另一个智能体。它们不仅可以相互对话，还能协作完成任务并最终汇报结果。

关键区别在于，将智能体包装成工具会从根本上改变其能力。如果你试图在 MCP 中包装一个智能体，可能无法充分发挥该智能体的全部潜力。而 A2A 则是从底层设计上就原生支持智能体，而不是将它们视为工具。两种方式都可行，但目前 A2A 正获得更多关注。

A2A 与 CrewAI 的集成

A2A 协议与 MCP 是互补关系，并非二选一。根据你的外部集成需求，你可能会在多种用例中同时使用两者。

将 A2A 与 CrewAI 集成有两种主要方法：

以下是两种集成方法：

1. 将 CrewAI 智能体暴露为 A2A 服务器：这种方法让你的 CrewAI 智能体可以被外部智能体发现和调用。
2. 将外部 A2A 智能体作为工具使用：这种方法允许你的 CrewAI 智能体将任务委托给其他符合 A2A 协议的智能体。

第一种模式非常简单。你基本上是将你的 CrewAI 智能体包装在一个支持 A2A 协议的 HTTP 接口后面。其架构组件非常直观，使用了我们在讨论 MCP 时提到的相同 HTTP 和 JSON-RPC 结构。

第二种模式则是允许你的 CrewAI 工作流中的智能体调用远程的 A2A 智能体。这使你能够创建一个自定义工具，直接调用远程的 A2A 服务器，这个过程也非常直接。

行业标准与展望

通过 A2A 协议，我们可以看到整个行业正在共同努力，试图确定我们应遵循的标准。目前有多种选择，这是一个全新的领域，许多公司、开发者和团队都在探索最负责任、最高效的方式，让智能体能够相互通信并跨网络使用工具。

A2A 是一个非常实用的协议，它正在不断扩展并获得采用，以实现智能体在互联网上的互操作性。目前尚不确定未来是否会出现一个统一所有智能体的单一协议，但 A2A 无疑是当前获得大量关注并与 CrewAI 良好集成的协议之一，这一点值得强调。

总结

本节课中，我们一起学习了 A2A 协议。我们了解了它如何作为智能体间通信的新兴标准，探讨了其核心组件（智能体卡片、任务、消息、成果物），并明确了它与 MCP 协议的区别与互补关系。最后，我们介绍了将 A2A 与 CrewAI 集成的两种方法。你可能已经开始思考可以将哪些智能体连接起来了，这非常令人兴奋。

在下一节课中，我们将更深入地探讨这些概念，敬请期待。

026：5. 使用 Flows 编排智能体 🧩

在本节课中，我们将要学习 CrewAI 中的 Flows。这是一个用于编排智能体和任务流程的低层级、模块化框架。通过 Flows，你可以精确控制执行顺序，并灵活决定在何处引入多少“智能体”能力。

---

概述：理解智能体系统的不同心智模型

上一节我们深入探讨了智能体本身。但在智能体系统领域，存在几种不同的心智模型。

AI 智能体通常通过三种主要心智模型来理解：智能体、图 和 事件。到目前为止，我们主要关注的是智能体模型，并看到了它们的强大能力。

另一种逐渐兴起的心智模型是图，它使用更传统的图架构（如节点和边）。但由于图的概念较为复杂，日常接触较少，其采用速度较慢，门槛也较高。

而目前非常流行的一种高级心智模型是事件模型。它更类似于常见的 Web 开发模式（如事件驱动），对于大多数已经熟悉 Web 应用开发的工程师来说，这个概念更容易理解和上手，并能快速投入生产。

无论采用哪种心智模型，它们都共享一些模式，例如围绕使用大语言模型、决定何时使用它们，以及如何谨慎地向它们添加上下文。

鉴于当前趋势，CrewAI 社区的许多成员在构建智能体系统时，特别关注事件和智能体模型。我们已经详细讨论了智能体和 Crews，现在让我们更多地关注基于事件的结构，看看这个心智模型如何应用，以及如何将其与智能体和 Crews 结合使用，发挥强大威力。

---

什么是 Flows？🚀

Flows 是一个模块化的编排层，你可以将其视为定义智能体或 Crews 行为的主干。

这意味着它允许你在非常低的层级上，定义所有你想要发生的事情及其顺序。你可以在 Flow 中引入多种不同的组件：

• 你可以引入 LLM 调用。
• 你可以引入常规的 Python 代码。
• 你可以引入单个智能体（可使用记忆和护栏）。
• 你甚至可以引入整个 Crew。

本质上，你可以将到目前为止学到的所有组件都放入 Flow 中。Flow 将为你提供主干和结构，以定义执行内容和顺序。当流程变得复杂时，这种控制能力显得尤为重要。

以下是一个 Flow 的示例：

1. 首先执行一段初始代码（常规 Python），可能用于从某处拉取数据或检查特定行为。
2. 然后，该代码触发两件并行执行的事情：
   • 信息流入一个单一的 LLM 调用，该 LLM 可能用于过滤信息、提取上下文或判断是否已拥有所需信息。
   • 同时，一个单独的智能体也在工作，它可能拥有记忆和护栏，并基于信息产生某种输出。
3. 并行执行结束后，流程汇合到一个单一的函数中，执行更多代码来处理信息。
4. 最后，该代码可能触发两个不同的操作：将日志记录到特定数据库，并启动一个完整的 Crew 作为下一步。

通过这个例子，你可以看到如何结合代码、LLM、智能体和 Crews，获得极大的控制力。Flows 成为了定义整个执行过程的自动化控制层和主干。

Flows 是一个低层级的编排框架，让你完全控制将要发生的事情，并允许你决定在整个执行过程中引入多少智能体能力。你不仅控制顺序，还拥有一个在整个 Flow 中共享的状态。这意味着在不同的代码块、函数和 LLM 调用中，你可以将数据存入该状态，并在后续步骤中复用。

---

两种构建方式：Agency 与 Control 🔄

退一步看，构建智能体系统主要有两种方式：

1. 优化于 Agency（自主性）：使用智能体、工具、任务、记忆等我们目前所学的组件。你优化的是让智能体在运行中自行解决问题。
2. 提供结构化主干：使用 Flows，它为你提供结构化的主干，你仍然可以在其中引入智能体、LLM 和整个 Crews，但你对如何设置拥有更多控制权。

它们各有其适用的场景：

• Crews：拥有更多协作性智能体，因此更自主、动态。它们更适合探索性、非确定性的任务，例如撰写剧本、制定营销策略或构思落地页创意。
• Flows：是更低层级、事件驱动的控制层。它们非常适合于结构化的、可重复的步骤，并要求严格的控制。例如，用于响应电子邮件、作为会议助手（在保存会议记录文档时触发，生成任务并通过 Slack 发送）等。

将两者结合可以创建非常复杂的用例。我们观察到企业和个人工程师中一个日益增长的模式是 “按需引入 Agency”模型，或者我喜欢称之为 “最小可行方案”方法。它遵循“保持简单”的工程原则。

这个思路是：从一个结构化的主干（如 CrewAI Flows）开始，然后只在每个步骤需要时才添加 Agency。如果一段代码能解决问题，就无需引入 LLM 或智能体带来的成本、延迟和潜在复杂性。你应该将智能体和 Crews 保留给它们真正能增加价值的复杂任务。如果确实需要 LLM，可以从单一 LLM 调用开始，再逐步引入智能体或整个 Crew。

这允许你选择在 Flow 中引入多少 Agency，确保你构建的系统既高效又有效。

---

Flows 的核心构建模块 🧱

让我们看一个真实 Flow 的结构示例：

在这个 Flow 中：

1. 一个 start_conversation 函数启动对话。
2. 它触发一个 router 函数。该函数基本上执行一次 LLM 请求，以决定是否需要进行深度研究。
3. 如果不需要深度研究（例如，对话已有大量上下文），则直接进入 answer 函数（另一个 LLM 调用）来回复答案。
4. 如果需要深度研究，则进入 research 函数，该函数内部包含一个完整的 Crew。这个 Crew 会像我们之前看到的那样，外出进行研究、抓取网页并最终生成报告，该报告随后被用来给出答案。

仔细观察 Flows，它有一套构建模块，允许你构建这些复杂用例，但这些模块本身非常简单，因为 Flow 只是一个很薄的层。以下是三个主要的构建模块（都是装饰器）：

1. @start 装饰器：标记哪个函数将作为第一个执行的函数。
2. @listen 装饰器：标记一个函数，它将在另一个函数完成后执行。
3. @router 装饰器：定义一个条件函数，它将根据函数内部发生的情况，将请求路由到不同的路径。

仅凭这三个简单的构建模块，你就能做很多事情。随着组合更多模块，能力会更强。

以下是一个利用这些构建模块的简单 Flow 代码示例：

# 导入装饰器
from crewai.flow import listen, start

# 使用 @start 标记流程的起点
@start
def start_conversation():
    # ... 你的代码 ...
    pass

# 使用 @listen 标记此函数在 start_conversation 完成后执行
@listen(start_conversation)
def trigger_research():
    # ... 你的代码 ...
    pass

你可以看到，这只是常规的 Python，非常 Pythonic。你只需编写函数，并使用装饰器来注解它们。@start 标记起点，@listen 用于建立事件链。

---

高级模式与可视化 🗺️

通过组合这些模式，可以构建真正有趣的流程。例如：

• 一个使用 @start 的函数可以触发两个同时监听它的函数，从而实现并行执行。
• 你可以设置第四个函数，仅在第二和第三个函数都完成后才执行（使用 @listen 并配合 and 条件）。
• 你也可以设置第四个函数在第二或第三个函数完成时执行（使用 or 条件）。
• 结合 @router 装饰器，可以让一个函数根据条件触发两个不同分支中的一个。

这些抽象组合可能难以想象，但当应用于真实用例时，它们能带来极大的清晰度和能力。

让我们回到之前提到的“对话与深度研究”的 Flow 示例，并快速回顾一下：

• start_conversation 函数使用 @start 装饰器。
• trigger_deep_research 函数使用 @router 装饰器，内部通过 LLM 调用（例如函数调用）决定路由方向。
• 如果路由到 answer，则执行相应的监听函数；如果路由到 research，则执行另一个监听函数，并可能在其中启动一个完整的 Crew。

CrewAI 的一个很酷的功能是，它可以自动绘制你的 Flow 图。你只需在终端输入 crewai flow plot，它就会自动分析你的函数和装饰器，并为你生成可视化图表。

这对于理解复杂的 Flow、文档记录以及发现流程中的问题非常有帮助。上图就是一个由 CrewAI Flow 自动绘制的“深度研究检查”流程图示例，清晰地展示了从开始到路由，再到研究 Crew 和最终报告生成的整个过程。

---

项目结构与状态管理 📁

要开始一个 Flow 项目，可以使用一个简单命令创建完整的文件夹结构：

crewai create flow <你的流程名称>

这会自动为你创建一个标准的 Python 项目（使用 pyproject.toml 管理依赖），并包含以下结构：

• 一个专门用于存放 Crews 的文件夹（例如 research_crew）。
• 一个用于存放可在整个项目中复用的 Tools 的文件夹。
• 主要的流程代码通常位于 main.py 或类似文件中。由于 Flow 是很薄的一层，且是纯 Python，你可以按喜好将代码拆分到不同文件中，以确保可维护性。

Flows 另一个非常有趣的特点是状态管理。每个 Flow 都有自己的状态，你可以将其想象成一个数据库，可以在 Flow 执行期间存储任何数据。

例如，从第一个函数开始，你通过 LLM 调用、执行代码或智能体/Crew 的输出产生了一些数据，并希望将其存储起来供以后使用。你可以将其写入 Flow 的状态中，然后在其他函数中读取它。这为你在不同函数间共享数据提供了极大的灵活性。

不仅如此，你还可以持久化这个状态，将其存储到实际的数据中。这样，当你再次运行该 Flow 时，状态会自动从保存的地方预加载，你可以从上次停止的地方继续。实现这一点非常简单，只需使用 @persist 装饰器来注解整个 Flow 或特定的函数。

在我们的深度研究对话示例中，随着发送新消息，我们希望确保将所有消息和输出持久化到一个单一状态中，以便在对话过程中复用。这样，每次从顶部运行 Flow 时，它会自动预加载之前的对话历史，让你可以持续聊天。

你可以在每个函数上使用 @persist 装饰器，来定义哪些函数执行后应该将状态持久化到数据库。在后续执行中，状态会被自动重新加载，你也可以选择覆盖其中的部分数据。

---

总结 🎯

本节课中，我们一起学习了 CrewAI 中的 Flows。

• Flows 是一个低层级、模块化的编排框架，用于定义智能体任务的执行顺序和逻辑主干。
• 它允许你灵活混合使用 Python 代码、LLM 调用、单个智能体和完整 Crews，实现高度可控的自动化流程。
• 我们探讨了构建智能体系统的两种主要思路：优化自主性的 Agency 模式和提供精确控制的 Flows 模式，并介绍了 “按需引入 Agency” 的最佳实践。
• Flows 的核心是三个简单的装饰器：@start、@listen 和 @router，通过它们可以构建复杂的事件驱动逻辑。
• CrewAI 提供了 crewai flow plot 命令，能自动将代码可视化为流程图，极大方便了理解和调试。
• Flows 拥有强大的状态管理功能，支持在流程内部共享数据，并能将状态持久化到数据库，实现跨执行会话的连续性。

Flows 感觉非常实用，许多人已将其用于日常开发，并作为将用例推向生产环境的首选方式，因为它提供了坚实的结构和所需的控制力。通过应用“按需引入 Agency”模型，你可以精确决定在自动化中引入多少智能和能力。

当然，它们需要良好的设计和可靠的构建。在接下来的视频中，我们将动手构建一个完整的 Flow，这将会非常精彩！

027：6. 构建深度研究流程 🚀

在本节课中，我们将学习如何将之前构建的深度研究智能体团队（Crew）升级为一个更强大、更可控的深度研究流程（Flow）。我们将看到如何利用流程来编排决策、管理状态，并在简单的语言模型调用和复杂的多智能体研究之间无缝切换。

---

概述

到目前为止，我们已经了解了流程（Flows）的强大功能和重要性。现在，我们将把之前构建的深度研究智能体团队（Deep Research Crew）转化为一个深度研究流程（Deep Research Flow）。通过这个升级，我们将整合所有已学的知识，使这个用例变得更加强大，并解锁更多应用场景。

从智能体团队到流程

上一节我们介绍了如何构建一个混合型的研究团队。它包含一个研究规划员，负责提出假设并分解研究问题，然后触发两个并行任务（研究主主题和次主题），但由同一个智能体执行。之后，进入事实核查阶段，同样由一个智能体完成两项核查任务。最后，所有信息汇总到最终报告撰写员那里。

现在，我们将把这个过程提升到新的水平，使用 CrewAI Flows 来重构它。我们不会改变智能体团队内部的运作逻辑，而是改变触发和管理这个团队的方式。

流程的核心概念与结构

流程为我们提供了一个轻量级的编排层，它通过一系列装饰器（decorators）让构建自动化流程变得非常简单。一个典型的流程项目结构如下：

your_flow_project/
├── src/
│   └── your_flow/
│       ├── __init__.py
│       ├── main.py      # 流程的主要代码
│       ├── crews/       # 存放智能体团队
│       └── tools/       # 存放工具
├── pyproject.toml
└── README.md

你可以使用 crewai create flow 命令快速生成这个脚手架。

流程状态（State）

流程的核心是状态（State），它是一个在流程所有函数间共享的数据结构。我们可以随时读写状态，以便在不同执行步骤间传递数据。

from crewai.flow.flow import Flow, state

class ResearchState(Flow):
    query: str = state(default="")  # 用户查询
    needs_research: bool = state(default=False)  # 是否需要深度研究
    final_answer: str = state(default="")  # 最终答案
    # ... 其他状态字段

关键装饰器

流程通过装饰器控制执行顺序和逻辑：

• @agent：标记一个函数由智能体执行。
• @task：标记一个函数为任务。
• @flow：定义一个流程。
• @on_start：标记流程的起点函数。
• @on_event：监听特定事件，触发函数执行。
• @router：根据条件将流程导向不同的分支。
• @persist：持久化状态，使其在多次流程执行间保留。

构建深度研究流程

以下是深度研究流程的主要步骤分解，每个步骤都对应流程中的一个函数。

1. 开始对话

这是流程的入口点，使用 @on_start 装饰器。它会检查是否存在之前持久化的状态，并向用户询问研究主题。

from crewai.flow.flow import Flow, on_start

class DeepResearchFlow(Flow):
    @on_start
    async def start_conversation(self):
        print("🤖 欢迎来到深度研究助手！")
        # 检查并加载持久化状态
        if self.state.previous_query:
            print(f"我记得上次您想了解: {self.state.previous_query}")
        # 获取用户输入
        self.state.user_query = input("您今天想了解什么？\n")

2. 分析查询

此函数使用 @router 装饰器，分析用户查询的复杂性。它调用一个轻量级语言模型来决定是直接回答，还是需要进行深度研究。

from crewai.flow.flow import router

    @router
    async def analyze_query(self):
        # 调用LLM判断查询复杂度
        analysis = await self.llm_call(f"分析查询复杂度: {self.state.user_query}")
        if analysis == "SIMPLE":
            self.emit("simple_event")  # 触发简单回答路径
        else:
            self.emit("research_event") # 触发深度研究路径

3. 简单回答路径

如果查询简单，流程会直接进入此函数，生成即时回复。

from crewai.flow.flow import on_event

    @on_event("simple_event")
    async def simple_answer(self):
        answer = await self.llm_call(f"请友好地回答: {self.state.user_query}")
        self.state.final_answer = answer
        self.emit("final_answer_ready")

4. 深度研究路径

如果判断需要研究，流程会先进入澄清问题环节。

4.1 澄清问题

此步骤会询问用户，以获得更具体的研究方向。

    @on_event("research_event")
    async def clarify_query(self):
        clarifying_q = await self.llm_call(f"针对‘{self.state.user_query}’，生成一个澄清问题以获得更具体方向。")
        user_context = input(f"🤔 {clarifying_q}\n")
        self.state.additional_context = user_context
        self.emit("query_clarified")

4.2 执行研究

这是流程的核心，在此加载并运行我们之前构建的深度研究智能体团队。团队会并行研究主次主题，进行事实核查，并生成详细报告。

    @on_event("query_clarified")
    async def execute_research(self):
        print("🔬 启动深度研究团队...")
        # 动态配置团队任务
        self.research_crew = DeepResearchCrew()
        self.research_crew.set_topic(
            main_topic=self.state.user_query,
            context=self.state.additional_context
        )
        # 执行团队任务
        final_report = await self.research_crew.kickoff()
        self.state.research_report = final_report
        self.emit("research_complete")

4.3 保存与总结报告

研究完成后，流程将报告保存为文件，并生成一个简洁的总结。

    @on_event("research_complete")
    async def save_and_summarize_report(self):
        # 保存详细报告到Markdown文件
        with open("research_report.md", "w") as f:
            f.write(self.state.research_report)
        # 生成总结
        summary = await self.llm_call(f"请总结以下报告的核心发现: {self.state.research_report[:1000]}...")
        self.state.final_summary = summary
        self.emit("report_saved")

5. 返回最终答案

这是流程的终点，它监听来自两条路径（简单回答或研究总结）的事件，并向用户呈现最终结果。

    @on_event({"simple_answer_done", "report_saved"})
    async def return_final_answer(self):
        print("\n" + "="*50)
        print("📝 最终答案:")
        print("="*50)
        print(self.state.final_answer or self.state.final_summary)
        print("="*50)
        # 持久化状态，供下次对话使用
        self.persist_state()

可视化与运行流程

CrewAI 提供了一个强大的工具来可视化你的流程。

# 在项目根目录运行，生成流程可视化图
crewai flow plot

这将生成一个 HTML 文件，清晰地展示流程的所有步骤、分支和事件触发关系。这对于理解复杂流程和调试非常有帮助。

运行流程只需一个命令：

crewai run

流程启动后，你可以与它交互。例如：

• 输入“你好”，它会直接调用LLM生成问候回复。
• 输入“宇宙的起源”，它会触发深度研究路径，可能先询问你具体想了解科学的还是历史的视角，然后启动整个研究团队，最终给你一份详细的报告和总结。

总结

本节课中，我们一起学习了如何将智能体团队（Crew）集成到流程（Flow）中，从而构建出更灵活、更强大的自动化系统。我们掌握了：

1. 流程的核心价值：在简单的LLM调用和复杂的多智能体协作之间提供精细化的控制层。
2. 关键组件：包括状态管理、装饰器（如 @router, @on_event, @persist）的使用。
3. 构建模式：从开始对话、分析路由、执行不同路径（简单回答/深度研究），到最终汇总输出的完整模式。
4. 可视化与持久化：使用 crewai flow plot 可视化流程，利用 @persist 实现跨对话的状态保持。

通过深度研究流程这个案例，你看到了如何把之前所学的智能体、任务、工具、记忆和护栏等概念，通过流程优雅地串联起来，形成一个端到端的、可交互的AI应用。现在，你可以尝试修改这个流程，添加更多步骤或处理更多边缘情况，利用这些基础模块去构建属于你自己的自动化用例。

028：构建可靠系统的策略 🛠️

在本节课中，我们将学习如何确保您构建的多智能体系统能够可靠、稳定地运行。我们将探讨一系列策略和技巧，从测试、训练到代码执行和推理智能体，旨在帮助您将系统自信地部署到生产环境中。

概述

通过本课程的学习，您应该已经非常熟悉如何构建智能体。无论是在 Jupyter Notebook、本地计算机还是 CrewAI 平台上，创建智能体都已不是难事。然而，核心问题在于：您能否可靠地运行它们？它们能否持续产出高质量的结果？最终，一切都关乎信任。您能否信任这些智能体，并自信地将它们部署到生产环境？如果不能，我们就需要解决这个问题。本节将介绍如何构建值得信赖的智能体系统。

构建可信智能体的核心策略

为了获得可靠、可重复的结果，从而建立对智能体的信任，我们需要为系统引入一些确定性控制。其中一些控制手段您可能已经熟悉，例如之前课程中深入讨论过的流程和护栏。流程为智能体提供了结构化的任务执行骨架，而护栏则用于检查特定的输出。

除此之外，还有一些我们尚未深入探讨但非常有价值的控制策略，包括：

• 推理智能体：强制智能体在执行任务前进行思考和规划。
• 人工介入监督：在智能体完成任务前，要求其与您核对，以便提供额外反馈。
• 测试：比较不同大语言模型，以在质量、速度等方面做出最佳选择。
• 训练：通过记忆机制，训练智能体以特定方式行为，强制其遵循特定格式。

接下来，我们将逐一详细探讨这些策略。

启用推理智能体 🤔

上一节我们介绍了为系统引入控制的重要性，本节中我们来看看如何通过推理智能体来提升输出的质量。

推理智能体的核心思想是，要求智能体在执行任何操作或完成任务之前，先思考并规划出达成目标的步骤。通过这种方式，智能体会草拟并自我检查一个计划。您可以限制其尝试制定满意计划的次数，之后它才会真正开始执行工作并遵循最初草拟的计划。

启用此功能非常简单，只需将一个名为 reasoning 的标志设置为 True。这将自动为您的智能体开启推理步骤。

agent.reasoning = True

此外，您还可以设置 max_reasoning_attempts 参数，以定义智能体在实际开始工作前可以尝试创建计划的次数。这是一种简单有效的方法，可以确保您的智能体在执行工作前进行额外思考，从而根据具体用例获得更好的输出。

实施人工介入监督 👤

我们已经在前面的模块中讨论过护栏，但我想谈谈终极护栏——人工介入监督的能力。这使您能够在智能体工作过程中验证、检查其输出是否合格，并为其提供反馈。

其工作原理是：智能体完成任务后，在最终确认工作完成前，会向您请求输入，询问您对其工作的评价。您可以根据需要提供额外反馈，智能体将根据这些反馈重新执行工作。

例如，在执行的最后，您的终端会出现类似这样的提示，要求您提供反馈。您可以输入具体指令（如“生成15项而不是10项”），也可以不输入任何内容，智能体会默认一切正常。输入反馈后，该信息将传回给智能体，它会重新工作以满足您的要求，并在完成前再次请您确认。

人工介入监督在需要对智能体进行特定监督时极为有用。当您部署此类智能体时，特别是使用 CLI 时，这套人工介入逻辑会变成一个 API。该 API 允许您将其与 Slack、Teams 或其他您可能使用的通信系统集成，从而无需人员守在终端旁即可提供反馈。

训练您的智能体团队 🧠

接下来，我们谈谈如何训练您的智能体团队。这里的训练指的是通过交互式反馈过程，让智能体记住做对和做错的事情，这些记忆将在后续的所有执行中被复用，以确保它们遵循既定标准。

回顾本课程第一个模块的内容，在训练模式下，智能体会正常启动，但在产生初始输出后会暂停并向您征求反馈。然后，它们会尝试利用该反馈改进答案，并基于此生成学习记忆存入其记忆库。

系统会为团队中的每个智能体记录：初始输出是什么、您给出的人工反馈是什么、改进后的输出是什么，以及执行过程中的关键信息。在训练结束时，这些反馈会按智能体进行整合，成为有价值的建议来源。这些建议是从您的反馈以及初始输出与改进输出之间的差异中提炼出的清晰、可操作的指令，并为生成的每条记忆附上质量评分。

在正常执行期间，每个智能体会将其整合后的建议作为上下文的一部分加载，确保将其考虑在内。您的文件系统中会有一个物理文件来存储这些建议、质量评分和最终摘要。

要启动训练，您可以在终端中运行 crewai train 命令，也可以在 Python 中使用 train() 函数，这将自动为您启动训练过程。执行后，您将看到运行过程、反馈提示出现，最终您会得到一个基于您反馈而变得更好的智能体。

测试与选择合适的大语言模型 📊

除了训练，您可能还需要测试您的流程和智能体，以获取其性能指标，判断它们表现如何，甚至可以比较几个不同的大语言模型。

在测试 AI 智能体时，系统会多次运行同一任务（执行指定次数）。您还可以指定一个特定的大语言模型作为“裁判”，该模型可以是执行任务所用的同一个，也可以是另一个专门用于评判的模型。

测试结束后，系统会为每项任务生成一系列关于输出质量的图表。您可以通过 CLI（在终端输入 crewai test）或 Python（使用 test() 函数）来触发测试。

其背后的流程是：智能体团队执行所有任务后，这些任务的输出和预期输出会被提交给“裁判”大语言模型。“裁判”模型会以 0 到 10 的分数对这些任务进行评分，告诉您输出质量如何，以及实际任务输出与您在任务定义中设定的预期输出的匹配程度。

测试报告会按不同任务进行分解，显示每次运行（例如3次）的得分，并给出包含质量和运行时间的平均分。这非常强大，因为当您更改智能体、任务或使用的大语言模型时，您需要一种方法来公平地比较（“苹果对苹果”），以了解这些更改是否带来了积极影响。

通过测试结果，您可以自行判断该分数是否满足您的用例要求，或者是否需要采用不同的策略来改进。您可以从课程中学到的众多策略中进行选择，包括训练、启用推理智能体、改进上下文，甚至选择不同的流程来观察其对团队输出的影响。

安全代码执行 💻

我们已经涵盖了许多提升输出的方法，但还有一个重要话题没有讨论：安全代码执行。代码执行对智能体来说极其强大，堪称终极工具，因为它允许智能体编写代码来完成任何他们想做的事情，例如生成图表、创建 Markdown 文件等。一旦智能体进入编码模式，它们（以及背后的大语言模型）在这方面尤其擅长。

有几种方法可以为您的智能体启用安全的代码执行，市面上也有许多工具支持智能体编码。但需要注意的是，一旦智能体开始编码，其能力边界将大大扩展。因此，您需要确保以安全的方式进行，并且只在确实需要时才允许编码。大多数智能体实际上可以使用您预先创建的自定义工具来完成大量工作，不一定需要触及代码。

但如果您确实需要，CrewAI 提供了一个自动嵌入到智能体中的代码解释器工具。它为您提供了几个设置选项，包括一种安全执行模式。您可以启用或禁用此代码执行功能，因此无需担心智能体自动编写代码，除非您明确允许。如果以安全模式运行，代码将在使用 Docker 镜像的容器中执行，从而与您的计算机隔离，更加安全。

在代码中启用代码执行非常简单：

agent.allow_code_execution = True
agent.code_execution_mode = "safe" # 确保代码在容器中运行

总结

本节课中，我们一起学习了构建可靠多智能体系统的关键策略。

可靠的智能体不仅仅是准确的，它们还需要是可预测的、可衡量的和可恢复的。我们涵盖了大量的信息，从护栏、大语言模型选择、基于代码的工具、推理机制、人工介入监督，到流程中的前后钩子，您现在拥有了许多工具来控制您的智能体，以确保获得理想的结果。

在开发智能体时，请专注于使用这些功能来持续获得良好的输出，即使在参数变化或输入意外时也是如此。当您优化了智能体，对其工作方式充满信心，并准备好投入生产时，下一步需要考虑的就是如何实际跟踪和监控您的智能体团队，如何确保其性能保持高位、延迟保持低位，以及如何跟踪幻觉等问题。通过综合运用这些方法，确保最终用户获得良好的体验。

在接下来的视频中，我们将深入探讨生成式 AI 系统的监控与可观测性，这对于将系统真正投入生产环境至关重要。

029：监控与可观测性 👁️

在本节课中，我们将要学习如何确保你的多智能体系统在生产环境中稳定运行。我们将探讨监控的重要性，并介绍 CrewAI 提供的工具，帮助你观察、理解和改进智能体的行为与性能。

---

上一节我们介绍了如何为智能体添加防护栏和钩子。本节中，我们来看看当智能体进入生产环境后，如何对其进行持续的监控与观察。

现在，你对你的用例充满信心。你构建了智能体，添加了钩子，应用了防护栏，并运用了本课程中学到的许多知识。然而，当它们真正进入生产环境时，工作并未停止。你需要确保对它们进行监控。这一点尤其重要，因为一旦智能体在规模化环境中运行，它们将以机器速度执行任务。因此，你需要确保所有监控措施到位，以观察它们的表现。我们将讨论如何暴露这些指标，以及如何真正了解系统中发生的情况，以便利用这些指标来推动改进。CrewAI 为你提供了许多工具来实现这一点。让我们开始讨论这些工具。

我们一直在讨论各种不同的功能和不同的方法，试图强制执行某些行为，并确保从智能体获得可靠的输出。但归根结底，可靠的输出意味着你正在努力构建值得信赖的智能体。上一课我们简要提到了这一点。建立对智能体的信任需要几个要素。例如，它需要可调试性，因为在原型设计阶段，你需要理解智能体在做什么、它如何得出结论以及如何做出选择。这样你就能更好地理解，并对如何改进它做出更明智的决定，使其表现更好。同时，你还需要确保监控质量，保证输出的一致性、可重复性，避免幻觉，并符合你期望的任何格式。

治理也是一件大事，因为对许多公司来说，思考和关注这一点至关重要，以防止个人身份信息或个人数据泄露，并从根本上将其过滤掉。这不仅是为了保护这些信息不被外部暴露，很多时候也是为了确保它们不会在内部暴露。如今，个人身份信息保护甚至个人信息保护已成为全球主要关注点，不仅在欧洲，在美国和许多其他国家也是如此。因此，在构建这些用例时，你需要确保考虑到这一点，尤其是在准备投入生产时，以确保不会暴露你不希望暴露的信息。

提示注入是迄今为止在智能体和大型语言模型中被利用最多的技术之一。有人可能向你的提示词中注入某些内容，从而危及你的用例或可能导致安全风险，这个问题必须作为智能体问题来解决。特别是那些生成代码的智能体，如果它们没有被适当地沙盒化或验证，可能会开辟新的攻击途径。最终，你需要确保我们的智能体在规模化运行时值得信赖，这不仅关乎它们所做的工作和它们访问的数据，也关乎整个基础设施能否承担起执行你的用例所需部分的负载。

不过，这些主题通常分为三个领域。考虑到我们到目前为止讨论的所有不同方面，它们总是可以归结为三个主要领域：可观测性、安全性和合规性。许多适用性和质量监控都属于可观测性范畴。因此，当你考虑调试、监控质量、监控幻觉时，所有这些都属于这个范畴。安全性涵盖诸如代码生成检查、提示注入检查、数据治理等领域，这个领域有很多内容，特别是现在随着 MCP 服务器的引入。合规性将更侧重于监控与个人身份信息或个人数据相关的问题。公司可能还有其他合规性指南。但在所有这些领域中，最重要的是能够看到和识别问题。这是它们之间共同的根本基础。无论你是为了保护个人身份信息，还是为了监控质量，都是如此。

正如许多工程师所知，如果你没有可见性，就像没有单元测试一样，你很快就会对你正在构建的东西失去信心，这会降低你快速前进的能力。你看不到的东西就无法修复。这就是为什么在 CrewAI，我们花费大量时间让每个人都能轻松理解智能体在做什么。到目前为止，你已经在本机终端的日志中看到过一些这样的信息。还有一种更深入的方式。你可以追踪智能体所做的每一个动作，无论是 Crews、Flows 还是工具调用，你都可以看到幕后发生的事情。这个功能我们称之为追踪。

以下是几种不同的方式，你可以利用数据来理解你的智能体在做什么。

第一种方式，我们在构建的所有示例中一直在使用，基本上就是在你的智能体上设置 verbose=True。这样做会在你的终端中打印出整个思考链以及你的智能体采取的一系列动作。

但是，如果在创建智能体后，你在你的 Crew 中设置 tracing=True，你将获得一个更高级别的视图。通过简单地启用这一个标志为 True，我们会在你的执行结束时提供一个最终 URL，你可以立即在浏览器中加载它，深入观察智能体的每一个步骤。你将能够看到按智能体及其执行的单个任务分解的内容，还可以展开大型语言模型调用，查看实际返回的响应，甚至可以深入查看正在使用的工具，了解这些工具是如何被使用的，一路追溯到你的智能体和大型语言模型之间交换的原始数据。这对于处于原型设计阶段的人来说具有巨大的价值，因为他们可以完全理解正在发生的事情。同时，它也非常适合调试，以防你遇到某些情况导致程序中断或出错，你需要追溯以理解是如何进入那个奇怪状态的。

现在，我想确保我们退一步，也讨论一下当你同时运行成千上万个智能体时，如何跟踪它们。生产中的智能体以机器速度运行。我的意思是，这不一定是以人类速度可以同时观察的东西。因此，可观测性变得更加被动，而主动告警则成为更大的优先事项。为了实现这一点，我们也为你提供了一些功能，比如 Crew 质量采样，你可以设置想要对总执行量的多少百分比进行采样，用于为你的 Crew 创建质量分数和自动幻觉分数。一旦我们设置好这个，你将看到一个完整的图表为你绘制出来。

这里有很多内容。让我们花点时间深入了解一下。在 X 轴上，你有时间。因此，跨越许多不同的执行和许多不同的日子，你可以看到你的智能体表现如何。在 Y 轴上，你有几个不同的选项。你不仅可以看到它们使用的平均提示词令牌数，还可以看到它们获得的平均分数以及它们获得的幻觉分数。归根结底，我们利用你的智能体执行过程中的集体数据，包括实际输出、预期输出以及你的智能体采取的所有不同动作，为你提供一个关于智能体系统正在发生的一切的总体概览视图。通过查看图表，你应该能够快速掌握任何质量或幻觉方面的问题，并追溯到你可能做过的任何具体更改。

这非常令人兴奋，但这只是冰山一角。还有许多其他工具可以让你在可观测性方面走得更远。例如，你可能想看看像 Arize 或 Galileo 这样的前沿工具，或者其他许多可观测性工具，它们可以深入检查你的智能体，了解它们的表现和性能，并围绕你的特定用例提供更具体的告警。我们当然推荐市面上许多不同的工具，而这两个是首先想到的。

在下一个视频中，我们将开始讨论如何在这个方向上更进一步，即当你真正开始部署这些你信任的智能体时，如何确保随着时间的推移你继续保持对它们的信任，如何确保在你不断为它们添加新功能时它们不会崩溃。这将是一个非常令人兴奋的话题。希望在那里见到你。希望你到目前为止真的很享受这门课程，结尾部分将会非常精彩。我们下节课再见。

---

本节课总结

本节课中，我们一起学习了多智能体系统投入生产后监控与可观测性的重要性。我们了解到，监控是确保系统可靠、安全运行的关键，主要涉及可观测性、安全性和合规性三大领域。CrewAI 提供了强大的工具来支持这些需求，包括通过设置 verbose=True 在终端查看日志，以及通过启用 tracing=True 获得一个详细的 URL 来深入追踪智能体的每一步执行过程。此外，我们还介绍了质量采样功能，它可以通过图表直观地展示智能体在一段时间内的性能、质量分数和幻觉分数，帮助你快速发现问题。最后，我们认识到，除了 CrewAI 内置工具，还可以集成如 Arize、Galileo 等专业可观测性平台，以获得更深入、更定制化的监控能力。通过这些工具，你可以建立对智能体系统的信任，并持续推动其改进。

030：为智能体实施CI/CD 🚀

在本节课中，我们将学习如何为投入生产的AI智能体建立持续集成和持续部署流程。我们将探讨如何确保智能体在持续改进的过程中保持稳定运行，以及如何像传统软件工程一样，为AI智能体构建可靠的CI/CD工作流。

当智能体投入生产环境后，你需要确保它们持续运行，不会崩溃，并且你的修改不会破坏它们。

如果你是一名工程师，可能对CI/CD非常熟悉。

现在我们将讨论AI智能体的CI/CD流程是怎样的。

你需要确保在改进智能体的同时，它们不会崩溃，并且在发布后能够可靠地运行。

以思考传统软件开发中CI/CD流程的方式来思考这个问题会很有帮助。

让我们深入探讨，看看CI/CD如何应用于AI智能体。

接下来我们将讨论大规模部署AI智能体。尽管部署很重要，但它并非主要挑战。真正的难点在于智能体上线后如何保持其可靠运行。

因此，以工程师处理CI/CD流程的方式来思考这个问题是有益的。

以下是你需要考虑的一些问题。

例如，如何支持新模型？这一点很重要，因为每周都有大量新模型发布，模型策略、变体和微调方面也有许多新进展。

能够真正试验这些不同模型并尝试使用它们，对你构建系统的方式会产生巨大影响。不仅如此，你还需要思考系统如何随时间演进，以确保它们变得更好而不是更差，确保它们仍在工作而不会开始崩溃。

一旦系统上线，你会不断对它们产生疑问。

你会想知道是否在使用更新、更便宜、更快的模型，会想知道它们是否按预期工作。当你开始思考这些挑战时，事情会变得更加复杂，以更深入的规划和考量来对待生产中的智能体非常重要。

因此，如果你真正思考从确定要自动化的流程，到让智能体被监控和部署的整个过程，你希望从以下步骤开始。

理解问题

我知道这听起来不是什么了不起的顿悟时刻，但让我告诉你，大多数公司失败不是因为技术。技术就在那里，而且相当令人印象深刻。它们失败是因为没有真正思考自己的用例，没有真正规划用例，没有思考如何衡量它们，也没有定义用例成功的标准。

从规划流程开始，然后你想实现第一个版本，这里的想法是极速前进。你希望再次快速获得从0到1的胜利。

建立验证集

从第一个版本到建立验证集，其理念是你不仅仅想要一个最小可行产品，你希望事情能运转起来。不要担心完美，你稍后会完善它。一旦你有了第一个版本，你就可以开始建立什么是好、什么是坏的标准，以及该自动化流程的“好”是什么样的，这将成为你的验证集。

这将为你提供一个清晰的基线，用于衡量你的更新是在提高还是降低性能。

当我在这里谈论验证集时，我试图做的是建立一个你可以对照衡量的基线。在实施过程中的某个时间点，你需要一组用例或一组已完成的运行，来确立“好”的标准。

这之所以重要，是因为当你实施护栏、更换LLM、进行训练或测试时，你需要有可以对照检查的东西，你需要知道你是否在推动改进。唯一能做到这一点的方法就是建立一个基线。

因此，尽早建立验证集很重要。随着进展不断更新它则更为重要，以确保当你改变这些内容时，它们不仅保持工作，而且持续变得更好。

实施护栏与监控

在建立验证之后，你可以开始实施护栏，以确保你的智能体在某些事件发生时行为得当。

这就是我们之前看到的许多内容发挥作用的地方，不仅是护栏，还有任务、训练以及其间的一切。

但这里的关键是尽早建立这个验证集，并在系统工作后实施护栏和触发器，然后保持持续的监控。

这个循环将帮助你更快地构建更好的版本，其基础是相对于你实际基线的可衡量进展。

在构建这个验证集时，请确保你不仅仅存储提示，还要记录实际的指标，如质量评估、运行时间、成本。随着时间的推移收集和分析这些数据，可以帮助你做出关于模型选择、权衡和性能改进的明智决策。

现在，我想确保我们正确地思考了这些事情。

你已经注意到，在构建这些智能体的过程中，我们可以通过两个改进向量来推动。

你需要确保所有内容都得到适当的版本控制，并且清楚地了解每个版本的变化。在CrewAI，我们非常注重将提示（包括角色、目标、背景故事、描述和预期输出）与实际智能体逻辑本身分离开来。

通过保持提示分离，允许你独立于代码调整它。由于提示存储为YAML文件，即使是非技术团队成员也很容易添加和维护。

你还可以为这些提示创建存储库，以便在不同的智能体或项目中重用，甚至可以使用智能体存储库来存储智能体，我们稍后会讨论这一点。

另一方面，智能体逻辑则更定制化，涉及更多传统代码，尤其是当你使用工具、钩子和护栏时。即便如此，其中大部分仍然可以重用。

这种关注点分离使得重用设计良好的智能体成为可能，特别是那些具有强大提示和工具的智能体，只需最少修改即可应用于许多任务和用例。

利用CrewAI CLI与存储库

假设你想创建你的Crew。你可能已经看到过一点，但你实际上可以使用CLI为你创建整个结构。

你只需要输入命令 crewai create crew 并给你的Crew起个名字，然后你就可以进入那个文件夹。你会发现整个Crew结构已经为你创建好了。

你会看到你的智能体和任务都映射到了YAML文件，这些文件包含了智能体的角色、目标、背景故事以及任务描述和预期输出。

假设你在一个智能体上投入了大量精力，设计了正确的工具和提示，它运行良好，以至于你可以重用它来完成许多不同用例的许多任务。

好消息是，我们实际上为你提供了能力，不仅可以在项目中使用这些智能体YAML文件，还可以在你的智能体存储库中使用它们，以便跨多个用例重用它们。

现在，你可以在线创建这些智能体到你的存储库中，并在本地重用它们，而且你可以免费这样做。你只需要按照流程创建你的智能体，我们有专门的UI界面。

一旦你想在本地计算机上使用它，你可以直接从该存储库加载。

这很重要，因为它允许你拥有这些智能体并随时间重用它们。对于工具也是如此，你可以有一个单一的存储库，在那里存放你所有的工具（公开或私有），并跨多个用例重用它们。

如果你想创建一个工具，再次使用相同的CLI，输入命令 crewai create tool 并给你的工具起个名字。从那时起，你将看到一个自定义工具的结构，你可以修改它以执行任何你想要的操作。它可以连接到特定系统、外部系统，甚至可以构建视频，任何你能想到的都可以做成这个工具，它都是常规的Python代码。

当你运行发布命令时，该工具不仅对你的团队中的其他人可用，他们可以通过CLI安装并访问该工具，并在许多不同的用例中使用它，甚至在我们课程一开始看到的那个无代码UI构建器中，你也可以使用这些工具。

因此，你可以使用这两个发布和共享工具的方法，在你的组织内提供一个集中的内部库。

这些工具可以包括自定义代码、MCP服务器或介于两者之间的任何东西。这种方法不仅提高了Crew和用例级别的可观察性和指标，还创建了可重用的乐高积木式组件，可以应用于许多不同的项目和工作中。

回顾与规划的重要性

现在，我想确保我们退一步，谈谈这些用例。对我们来说，不忽视规划阶段很重要。

我在本课开始时简要提到了这一点，但我想回过头来详细谈谈。许多人跳过这一步，直接开始编写代码，这可能令人兴奋并能快速产生结果，但仔细规划能带来更好的结果。

一个常见的陷阱是未能明确定义成功，以及没有将流程分解成更小、可管理的、可以成为独立任务的块。一些团队也忘记了衡量或评估结果，因为他们一开始就没有建立这些指标。

当你走向生产环境时，花时间进行周密的规划，可以使你的系统结构良好、可衡量，并能随时间有效演进。

你需要记住的四件事是：花时间规划、有明确的成功定义、确保将流程分解成更小的块、确保有衡量和评估的方法。

总结与展望

在本模块中，我们从协作、智能体协调、不同模式、构建流程、实施推理智能体、训练、测试、结构化输出等方面学到了很多。现在，我们掌握了所有这些工具，可以构建更多东西。

接下来，我们将完成本模块的计分测验和计分实验，在那里你将使用在本模块中学到的所有技能创建一个代码审查流程。这将非常令人兴奋，因为这是一个非常实用的用例，我相信作为一名工程师，你会欣赏它。

你即将完成本课程。完成后，你会看到在下一个模块中，事情将进入一个新的层次，因为我们不仅要讨论如何构建AI智能体，还要讨论其实际的商业价值。这是一个非常特别的模块，因为我会尝试一些不同的东西，邀请一群正在生产中构建AI智能体的公司，他们是拥有实践经验的实际从业者，正在领导他们的团队进行这项工作。

我希望你在我与他们交谈时，听听他们的声音：他们面临哪些挑战？哪些方法对他们有效？他们遇到了哪些问题？这将非常令人兴奋。所以我希望在你的计分课程之后能在那里见到你。

请继续关注，这将非常有趣。我们稍后在那里见。

031：跨行业应用案例

概述

在本节课中，我们将探讨AI智能体在不同行业和组织中的实际应用。我们将看到，从提高效率的后台自动化到创造新收入来源的创新用例，智能体技术正在深刻地改变工作方式。通过分析真实公司的案例，我们将理解智能体如何落地，以及如何评估和规划自己的智能体项目。

---

智能体应用的必然趋势

上一节我们探讨了智能体的技术基础，本节中我们来看看它们在实际业务中的表现。首先需要明确一个核心观点：智能体的广泛应用是不可逆转的趋势。

这仅仅是新型劳动力形态的开端。AI智能体只会从此刻起不断改进。不存在未来组织停止使用AI智能体的场景。自动化以及利用AI的自动化将持续演进和改进。

一旦接受这个现实，你就会发现AI智能体在许多领域都存在机会。智能体本身具有巨大潜力，能够影响我们的工作方式、运营效率以及业务开展模式。

两类核心自动化用例

回顾本课程中讨论的用例类型，它们主要分为两大类。

以下是两类主要的自动化用例：

1. 端到端流程转型：这类流程跨越不同的业务单元，范围广，涉及多个利益相关者，周期长。例如，将原本需要数周的任务缩短到几天、几小时甚至几分钟。例子可能包括后台办公或某些前台运营工作。这类自动化始于智能体，也终于智能体，通常涉及多个业务单元，中间可能有人类参与，构建更复杂，需要一定精度，但能带来巨大价值。
2. 日常任务优化：这类优化更侧重于个人效率提升。它们让你更高效，也更容易实现价值。例子不仅包括会议准备，还包括生成报告或自动化特定工作任务。虽然范围限于个人，但一旦在整个组织内采用，这些日常自动化会累积成惊人且可观的影响。这类自动化最终能极大提高效率。

市场应用全景

纵观全局，你会发现一些全新的前沿用例。

例如，人们称之为APA（Agent Process Automation），基本上是用智能体流程自动化取代机器人流程自动化。你还会看到智能体被用于新型的智能体ETL管道，即在摄取数据时，智能体基于该数据推断新数据或即时修改数据。此外，还有一些智能体原生功能，即产品中新增的功能，使你的产品能够实现以前不可能的事情。

目前，应用智能体最多的前九大垂直行业包括金融服务、健康与生命科学、保险、高科技公司、媒体与娱乐、客户服务、CPG（快速消费品）、零售和电信。在这些公司内部，许多职能部门或横向领域都在探索智能体的用例。

我们观察到销售和市场营销用例的趋势，同时也包括开发人员自动化、网络安全、供应链、定价用例和人员管理。放眼全局，你会看到一个巨大的机会版图，横跨不同公司及其内部的不同横向领域。这有助于你在思考自己的用例时，了解可以借鉴哪些资源。

重温用例评估框架

这让我们回到了课程开始时讨论的用例矩阵，即从复杂性和精度两个维度来思考你的用例。

几节课前，我们讨论过这个框架。鉴于其重要性，在思考你的用例以及当今AI智能体如何在业务中执行操作时，我决定再次提及它。你需要理解你的用例在这个框架中的位置。

记住，你的用例可能具有高复杂性和高精度，也可能具有低复杂性和低精度，或者介于两者之间。这个框架上没有对错之分，它只是帮助你理解需要投入多少努力才能获得所需的价值。

低复杂性、低精度的用例可以节省大量时间，并对组织产生巨大影响。关键是要理解你的具体用例落在哪个位置，无论高低。

真实案例深度解析

现在，我想带你了解几个与CrewAI合作公司的具体真实用例。通过这些例子，我们将看到不同级别的复杂性、不同的分布情况，以及端到端和日常自动化的例子。这将使一些用例的价值变得极其具体，这些都是我们为真实企业运行的用例，可能会为你的一些决策提供参考。

案例一：全球500强金融机构

我想从一个金融机构开始。这是一家全球500强机构，一家大型银行，他们决定专注于其KYC流程。

KYC代表“了解你的客户”。这是一个涉及收集客户和潜在客户信息的过程，需要进行深入研究和分类以了解每个具体个体。银行需要这样做，以确保为该个体提供正确的产品和服务。

这家金融机构使用CrewAI来自动化他们的流程，并得到了一些非常有趣的惊喜。

• 首先，智能体生成的初始报告实际上比人类的第一稿更准确。
• 流程中某些原本需要一周工作的部分，现在总共只需15到30分钟。
• 由于所有这些智能体现在都在进行研究，执行“了解你的客户”尽职调查的整体入职时间减少了四倍。它们提取纳税申报表，在批准或不批准之前通过API及其金融机构验证这些数据。

这对于像这样的大型组织的底线产生了巨大影响。这是一个端到端的自动化流程，侧重于减少时间和提高效率，完全是关于效率增益。它证明了高度监管的业务也能从此类自动化中受益，只要它们从底层开始构建以确保支持治理，并专注于那些可以快速行动、在开始扩展之前获得早期胜利的用例。

案例二：全球财富500强快速消费品公司

现在，我想切换一下话题，因为我们的下一个用例是一家全球财富500强CPG公司。

CPG代表快速消费品。我们过去也讨论过，这是智能体潜力巨大的行业之一。这些公司生产你可以在超市和商店购买的产品，比如零食或消费品。这些公司着手改进他们的退款流程。

每当客户发现产品缺失或有问题时，他们想要回自己的钱。可以想象，这对客户来说是一个非常令人沮丧的处境。他们希望问题能尽快得到解决。但由于法规要求，这些公司需要进行一系列检查。他们需要确保自己没有上当受骗，产品确实有问题。因此，有一个完整的流程来验证不仅是个人的凭证和历史，还包括围绕该产品的许多内部流程。

为此，他们决定使用CrewAI的AI智能体来自动化整个退款流程，从而显著缩短处理退款请求的时间，取代了涉及多个团队的高度手动流程，将整个过程从三天减少到不到10分钟。这对于这样的公司来说创造了非常有趣的投资回报。你可以看到这是另一个端到端自动化的例子，但范围更集中于特定流程。同样，这也是一个后台自动化用例，我们看到了很多这样的案例。

案例三：全球1000强电信公司（收入生成用例）

现在，我想引入第三个用例。这个用例不同，因为它不是关于效率增益，而是关于收入生成。我对此感到非常兴奋。

这是一家全球1000强公司，意味着它是世界上最大的千家公司之一，是一家电信公司。他们决定采取完全不同的方法。正如我告诉你的，我们之前关注效率增益，他们开始思考可以探索哪些业务线，而这些业务线在以前需要巨额投资才能确保将其作为一个实际想法进行探索。但现在，通过利用智能体，他们可以在更可控的环境中测试这些概念，并最终投入更多资金。

他们决定使用智能体来分析客户的行为和数据，例如客户是预付费手机还是后付费手机，以及他们拥有的关于该特定客户的所有数据。通过使用智能体分析这些行为，发现该客户具有的模式，并利用这些模式给他们一个特定的信用评分。通过拥有这个信用评分，他们可以开启一项新的业务线：提供贷款服务。

由于这一切都使用智能体，从客户提出请求起，他们可以在两天内将钱存入客户的银行账户，因为一切都是尽可能自动化的。他们实现这一点的方式是分析客户的消费模式，例如他们的手机使用情况，并使用智能体大规模处理这些数据。他们发现，他们找到的模式与他们认为的客户信用价值之间存在高度相关性。他们在这方面取得了显著的成功，花费的资金远少于在没有智能体的情况下启动整个业务线所需的资金。

在这里，你可以看到这是一个完全不同的用例。它更像是一个创收用例，而不是效率展示。这非常有趣。

智能体采用生命周期的演变

除此之外，我们还想讨论智能体的采用生命周期在过去几年中是如何变化的。

回顾过去，我们几乎经历了几个不同的阶段。市场一直在持续过渡和演变。因此，组织在接受教育方面变得更好、更成熟，理解智能体如何帮助他们的业务，并且有几个不同的阶段展开。

• 第一阶段：聊天机器人：大约两年前，你看到公司做了很多聊天机器人。这些聊天机器人很大程度上是通用机器人，背后是所谓的单一智能体，仅使用常识，具有一定交互性，但非常专注于聊天用例，无论是内部还是外部。这些并不是在ChatGPT出现后才出现的，聊天机器人已经存在了十多年。
• 第二阶段：AI副驾驶：最近，我们更多地看到了AI助手或AI副驾驶的概念。你可能有一个智能体，或者感觉像是有多个智能体，存在一些委托，具有更具体的领域知识，无论是通过集成RAG实现还是更具交互性。这里的想法是，许多公司现在采用这种模式来帮助完成从编码到撰写文档等不同的事情。
• 第三阶段：智能体协作工作流：现在我们正在进入第三阶段，你实际上开始看到智能体工作占据主导地位。这是最新、最前沿的阶段，你看到多个智能体协同工作。这包括流程特定或任务特定的智能体，但也包括更广泛的智能体，并与许多工具集成，包括我们提到的MCP和记忆系统。这可以自动或单独触发，不仅更注重效率，而且正如我们刚刚看到的，也为更多机会打开了创收用例的大门。

构建智能体工作流的核心原则

现在，无论你选择如何构建智能体工作流，有一件事你必须明白：无论你做什么，它都必须极其易于构建和运行。

你可以使用代码或无代码来实现，但要以一种能帮助你快速构建从而获得价值的方式来实现。并且它必须是可信的，这样你才能真正依赖其输出。因此，追踪记录必须存在，训练必须存在，防护措施必须存在，选择正确的模型必须存在。

不仅如此，它还需要是可扩展的。这里的可扩展不一定意味着每月运行一百万个智能体（我们有一些客户正在这样做），也意味着以可重用的方式构建它们。这种乐高积木的概念，你可以通过智能体或工具等重用的乐高部件。退一步看，这些基本上是你构建这些用例时需要牢记的三个支柱，这也是我们构建CrewAI的基础。

总结

在本节课中，我们一起学习了AI智能体在不同行业的实际应用。我们从智能体应用的必然趋势出发，区分了端到端流程转型和日常任务优化两类核心用例。通过分析金融服务、快速消费品和电信行业的三个真实案例，我们看到了智能体在提升效率、改善客户体验乃至创造新收入流方面的巨大潜力。我们还回顾了智能体采用生命周期的演变，从早期的聊天机器人到当前的智能体协作工作流。最后，我们强调了构建智能体工作流时，易用性、可信赖性和可扩展性三大核心原则的重要性。

我非常兴奋我们在这一点上涵盖了这么多内容，并希望在这个最后的模块中，当我们深入探讨这些AI智能体的细节时，我们开始更好地理解它们如何不仅能为你服务，而且你实际上应该如何思考这些用例，以及如果你确保从一开始就做对哪些主要事情，它们将在你的整个旅程中帮助你。

我对下一课感到非常兴奋，我们将研究成功实施之间的模式，探索这些公司内部的采用模式，以及它们在采用这些技术时的样子。我对此感到非常兴奋，因为你有机会看到如何将其应用到自己的公司、团队或用例中，所以你一定不想错过，我们稍后见。

032：AI智能体用例优先级排序 🎯

在本节课中，我们将学习如何为AI智能体项目选择和确定高优先级的用例。我们将探讨成功实施AI智能体的关键驱动因素、常见的成功与失败模式，以及如何从零开始规模化地推进智能体应用。

---

在上一节中，我们探讨了AI智能体的各种潜在用例。本节中，我们来看看如何从众多想法中筛选和确定应优先实施的用例。

根据我们目前所学，你可能对众多用例以及如何将AI智能体应用到日常工作感到兴奋。即使在你的公司和团队内部，你们可能也在讨论其中一些用例。但如何对这些用例进行优先级排序？其他公司是如何做的？不同领域的成功实施有哪些共同点？让我们探索这些成功驱动因素，以便理解如何将其应用到自己的用例中。

你将学习AI构建者如何从零到一地推进智能体应用。不仅如此，他们还能以可扩展的方式进行。让我们深入探讨。

本模块主要关注公司在采用AI智能体时会发生什么。让我们探索成功的多智能体系统的驱动因素。那些成功部署AI用例的公司有哪些共同点？你将学习团队如何从0进展到1。我们不仅要讨论这一点，还要讨论具体方法。

---

AI智能体的采用在这些团队内部迅速传播，并扩展到整个组织。我们已经识别出几个常见的成功模式。

以下是成功实施AI智能体用例的四个关键模式：

1. 高频用例：当智能体每周或每月运行多次时，通常能带来非常成功的实施。这能产生复合回报或规模化投资，使公司更容易决定投资这类用例。因此，你需要确保至少在一些早期胜利中寻找高频用例。
2. 清晰的成功标准：拥有可衡量的清晰成功标准至关重要。你需要理解何时成功，并且在项目早期定义这些指标非常有帮助。围绕评估标准达成共识，能真正影响你的用例。
3. 合理的后备路径：这意味着必要时可以通过人工介入、设置护栏、LM护栏或使用查询流程为自动化添加更多结构。这允许你更有意识地处理后备方案，能产生巨大影响。这也是我们注意到的一个模式。
4. 衡量结果：你需要有追踪、可观测性和监控机制来跟踪性能。当你的用例具备这些特征时，很可能就是一个适合AI智能体的强力候选者，前提是该用例首先能从智能体中受益。

这意味着你需要寻找一个高频用例，在该用例上你能就评估方式达成共识，能通过使用查询流程或我们学到的其他功能来规划合理的后备路径，并且需要确保使用我们在课程中展示的一些方法来衡量结果。

现在，如果你做到了这些，就能获得惊人的成果。有些公司已经在某些用例上实现了80%到超过90%的效率提升。这些收益是可能的，你实际上可以实现它们。但你必须真正理解你正在优化什么。

---

让我们谈谈如何理解你的优化目标，因为我们在上一课中讨论了一些用例，有些团队优化效率提升，而另一些则优化收入生成。处理这些不同目标的方法以及在每种情况下衡量的内容将大不相同。

让我展示一个例子，一个我们客户如何采用查询流程的真实案例，他们是如何做的，在整个过程中学到了什么，他们推进的速度有多快，以及这对他们来说是什么样子。

这将引用我们之前看到的一些内容。这家公司最初与我们接触是关于一个价格运营用例。他们在几周内就让第一个用例上线了。你已经知道这基本上是一个用于更改价格、查看优惠券和折扣的定价操作。他们从中获得了惊人的准确性和效率提升。

从那时起，我们实际上扩展到了三个新用例。然后我们制定了一个联合用例路线图。根据该路线图，我们在一个月内与其他业务部门一起扩展到了五个新用例。这最终导致了跨多个不同区域的扩展。

请记住，这并非一帆风顺。当我们首次部署他们的价格运营用例时，准确率大约在60%左右。因此有几周时间，我们基本上是在改进那个基线，改进我们已有的验证集，以确保我们达到了97%的准确率。这对我们来说是一个非常值得注意的时刻，因为我们和客户都看到了从零到一的过程，看到了采用智能体时的实际样子。

如果你观察这在他们的智能体运行数量上是如何体现的，你可以从他们的第一个用例中看到，他们从初始规模开始扩展，直到公司内部开始传播这个消息，他们开始扩大使用范围。然后我们在一个月内为他们部署了那五个用例，最终实施扩展到全球多个不同区域，并与他们签订了主协议服务。

此时，这个看起来一直很漂亮的柱状图变成了一条平坦的线，因为他们在大约15天内从零执行到了10万次。因此，随着时间的推移观察这家公司的采用模式非常有趣。如果你看公司的查询执行次数，它开始时非常温和。随着消息开始传播，你部署了更多用例，你可以开始看到价值，开始看到模式，开始看到人们对此投入，采用的扩展真正获得了动力，并从此开始适当扩展。

这是一个非常令人兴奋的用例，也是我们在不同公司以各种形式看到的情况。如果你现在观察这个行业，我会说采用生命周期至少有五个不同的级别。我想指出的是，这里的第5级对于大公司来说是非常理想的。一些新的初创公司可能一开始就是第5级，因为它们是从头开始为AI智能体构建的。但许多公司实际上处于第1或2级。而我们帮助他们从那里一路提升到第4级，并最终也达到第5级。

但这里的想法是，你必须开始测试，开始尝试，开始构建这些用例。当你这样做时，你对这些用例如何帮助你以及你如何实际构建它们的信念和理解会不断增长。

---

现在，我想确保再次指出，并非一切都是完美的。实际上也存在一些常见的失败模式。接下来让我们谈谈这些。

我们已经看到并了解到智能体在哪些情况下会失败。这通常发生在你定义了目标的情况下。

智能体失败不仅可能是因为你没有正确定义目标，还可能是因为缺乏可观测性，意味着你无法理解你的智能体如何工作或它们是否在工作。然后它还有我们已经讨论过的问题，那就是没有明确的成功定义，或者不清楚你将如何评估这一点。有时，由于目标不明确，无法跟踪或适当监控你在这方面的投资回报。

最重要的是，没有迭代的所有者，没有关键人物来持续改进，没有团队来负责这些未来的实施。你可以看到许多公司试图定义AI卓越中心或特定团队，或者让许多团队挑选自己的工具。我不会说这样做是对是错。但你肯定要确保有人对这个倡议负责，有人推动，有人真正在这方面取得进展。

因此，如果你所在的团队正试图弄清楚如何启动和部署自己的用例，这些都是你应该注意的事情。确保你没有陷入这些陷阱，同时要理解，在推出智能体和随时间改进它们之间存在一个过程，这个过程会带来更好的结果。

我非常高兴我们有机会讨论这个问题，特别是因为如果你投入时间完善这些用例，你可以取得惊人的成果，但这需要你付出一些努力。

---

现在，我想确保我们进入下一课，我对此也非常兴奋，因为我们花时间研究了一些公司，并且我们实际上要把这些公司带到课程中来。我想和他们交谈，和他们聊聊他们实际上在用AI做什么，以及他们如何构建AI智能体。他们帮助我们理解他们如何取得成功，他们面临了哪些困难，以及他们做对了什么。我想确保你不仅从我这里听到，而且直接从构建这些智能体并使用你技术的人那里听到。所以我想在下一课见到你，这将与我们迄今为止所做的完全不同，你不想错过这一课。那么，我们到时见。

---

本节课中，我们一起学习了如何为AI智能体项目确定高优先级用例。我们探讨了成功的四个关键驱动因素：高频使用、清晰的成功标准、合理的后备路径以及结果衡量。同时，我们也分析了常见的失败模式，如目标不明确、缺乏可观测性和迭代所有权缺失。通过一个真实客户案例，我们看到了从概念验证到规模化部署的完整路径。理解这些模式将帮助你在自己的组织中更有效地启动和扩展AI智能体应用。

033：与 Exa 的对话

概述

在本节课中，我们将与正在现实世界中构建AI智能体的从业者进行对话。我们将了解他们如何使用查询AI来构建智能体，探讨他们感到兴奋的方面以及面临的挑战。通过这次对话，我们希望学习他们如何扩展智能体应用、发现新机会，以及总结出可供我们借鉴的经验教训。

---

与行业实践者的对话

现在，我们希望与在现实世界中构建AI智能体的从业者进行交流。我们将讨论这些人如何使用查询AI来构建智能体，他们对此感到兴奋的方面，以及他们在整个过程中遇到的挑战。在本节课中，我们将与这些项目的领导者聊天，他们正在推动AI智能体在其公司中的采用，并取得了惊人的成果。

因此，让我们深入了解，以便更多地了解他们如何扩展使用、发现新机会，以及他们学到了哪些可以应用到我们自身用例中的经验。现在，让我们加入这场对话。

接下来，你将听到来自Exa的分享。Exa是CrewAI的主要合作伙伴。Exa正在进入搜索领域，构建自己的搜索引擎，专为AI和AI智能体优化，使构建用例的人们能够更容易地在正确的时间获取所需信息。

Exa通过我们构建的官方集成与CrewAI集成，你在整个课程中一直在使用它。它为数百万AI开发者处理请求，其中许多请求由CrewAI智能体驱动，并使智能体能够通过真正的语义搜索访问实时信息。

现在，让我们听听他们的联合创始人之一Jeffrey关于他们如何看待AI智能体，特别是CrewAI在该领域所扮演角色的看法。

Jeff，非常感谢你今天抽出时间。我知道谈论AI智能体非常令人兴奋，因为目前正在发生很多事情。随着智能体经济空间的不断发展，从你的角度来看，以及从你所见的广泛工具和资源生态系统中，不断扩展的重要性如何？

我认为过去一年发生的事情确实令人难以置信。在过去某个时间点，大型语言模型在使用工具方面非常糟糕，然后它们变得勉强能用，而现在它们在使用工具方面已经非常出色了。像Claude、GPT-4o、Sonnet和GPT-4o Codex这样的模型，它们简直太棒了。

如果大型语言模型没有输入任何有趣的数据，或者无法与外部世界互动，那就像一个人坐在房间里，没有电脑，没有任何可用资源。你很聪明，有大脑，但你只是坐在那里。因此，从根本上说，大型语言模型能够与外部世界互动、读取信息并写入信息是至关重要的。

根据我对AI实验室正在研究的内容以及他们希望在未来几年启用的能力的理解，重点很大程度上集中在工具使用和外部数据上。

你提到这一点很有趣。实际上，在录制这门课程时，我与Andrew讨论过这个问题，他提到，如果你回顾2024年，就像十年前在AI档案中一样，这些模型真的不那么好。你需要搭建大量的脚手架才能确保它们以某种方式运行，你必须描述每一个细节以保持所有控制。但现在，模型在使用工具方面越来越好，这确实导致人们移除了很多脚手架，并更加专注于智能体本身。

那么，具体到Exa，因为你拥有关于实时网络搜索的非常有趣的视角，这解锁了许多不同的用例——如果智能体能在正确的时间输入真实和正确的数据，它们就能做很多事情——你如何看待这些自主智能体的演变，特别是考虑到它们现在能够访问并与实时网络搜索API配对？

当GPT-3.5出现时，如果你给它几千个令牌并告诉它“嘿，根据这个网页回答这个问题”，大约30%的时间它会幻觉。它会告诉你网页上的错误答案。然后在某个时间点，也许是GPT-4，它开始减少幻觉。但即便如此，如果你给它多个选项，比如给它两个工具使用，它仍然表现不佳。

而现在，你可以构建能够访问十几个工具的复杂智能体，并以各种疯狂的方式组合使用这些工具。例如，Claude Code就是这样做的。Claude Code有大约10,000个令牌的工具，它有文件I/O工具、网络搜索工具等等，它能够将这些工具串联起来，产生非常有用的输出。

网络搜索是该工具链中一个根本重要的部分，因为大型语言模型本质上不是搜索引擎。它们知道很多东西，但那只是它们记忆的东西。有时它们会产生幻觉，因此它们依赖于包括网络搜索在内的工具。

是的，我认为你说得很好，因为这不仅仅是网络搜索的能力。你关于幻觉的观点，几乎就像是答案的锚定。事实上，你现在可以赋予这个智能体能力，让它不仅能给你答案，还能自我事实核查，或确保它们使用最新的数据，并找到所需的一切来检查所有条件。我认为这很有趣。

围绕“锚定于真实数据并从实时网络数据更新确实能产生巨大差异”这一理念，你有没有看到任何具体的用例？

我们看到的其中一个用例是：让我们思考一下大型语言模型没有记住什么。首先是近期事件。所以，如果你问大型语言模型“今天世界上发生了什么”，除非它查找信息，否则它什么都不知道。其次是长尾信息。例如，假设你正在构建一个AI市场工具，比如销售勘探工具，大型语言模型没有记住像1000家生物技术公司或1000家AI初创公司这样的列表。这只是它们不知道的信息。

这种不常见、不是每个人都知道的长尾信息——它知道Stripe，但不知道最近一家从事支付业务的YC公司。因此，在这些情况下，它需要查找信息。

最后，我认为我们Exa一直关注的一个非常有趣的事情实际上是编码。目前大型语言模型的一个巨大限制是，对于它们记住的东西，它们可以编写非常好的代码。它们可以编写完美的Next.js代码，可以编写完美的Express代码等等。但是，假设上周我发布了一个Agent SDK，还有其他一些SDK，即使是OpenAI自己的大型语言模型也不知道这些SDK的任何信息。因此，从根本上说，需要进行网络搜索来查找有关如何编码的信息。

所以我们实际上在几周前推出了名为Exa Code的产品，这是专门为编码智能体设计的搜索。

我很喜欢这一点。你提到这一点很有趣，因为这是我们与客户PwC的一个主要用例。当他们使用这些模型进行SAP和Salesforce编码时，模型可能知道一些，但不知道PwC的特定方式或他们在许多应用程序构建中设定的条件。所以，是的，这是一个很好的用例。

我的意思是，对于大多数人来说，编码可能不是首先想到的事情，但你是对的——如果你不使用像Next.js这样大多数开发者都了解的东西，你需要利用真正锚定的数据。

从技术和公司的角度来看，你认为最大的摩擦点是什么？人们真的在尝试添加这种嵌入搜索或进行爬虫以获取数据。你认为工具方面已经解决了吗？还是输出质量？你认为目前主要的障碍是什么？

我认为限制智能体使用搜索工具和爬虫工具的一个正确答案是上下文窗口管理，也就是上下文工程。今天，如果你使用很多流行的工具，会发生什么？例如，今天如果Claude Code使用其原生的fetch工具而不是使用Exa MCP进行网络搜索，它会下载数百KB的文件，完全淹没上下文窗口。

我认为人们可能已经忘记了上下文窗口是多么脆弱，因为模型感觉更小了。然后当模型停止工作时，你的客户可能会想“好吧，它没工作，也许我再试一次”，但实际上模型只是开始表现不佳。即使是最新、最强大的模型，在数万个令牌级别，如果你用1000个原始HTML令牌淹没上下文窗口，它也不会表现良好。

因此，我认为这些工具自行执行一些令牌效率步骤至关重要。例如，Exa Code有一个理念，我们总是尝试只返回几百个令牌。我们实际上尝试只返回代码示例，因为代码示例是完成编码任务所需知识在令牌方面最密集的表示形式。如果没有，我们会提取文档，但即使那样，我们也尽量将其控制在几千个令牌以内。

这对于你创建的任何工具都适用。如果你正在某个地方摄取巨大的文档，它会淹没上下文窗口，所以你可能必须使用子智能体之类的东西。例如，Crew Code现在有子智能体，这非常酷。

这是一个很好的观点。这很有趣，就像回到谷歌时代，当谷歌是人们搜索事物的默认方式时，有一个指标是“我们希望成为人们花费最少时间的网站”，而所有其他网站都在优化参与时间，谷歌只是想让你超级快地找到一切。

听起来你告诉我的是，在新时代，Exa现在成为智能体搜索的主要提供者，新版本的理念是：我会用最少的令牌返回最多的信息，所以真的是物超所值，不仅在金钱方面，而且在上下文窗口方面。因为归根结底，上下文工程是你真正必须考虑的事情。这些东西毕竟是AI模型，垃圾进，垃圾出。因此，你进行有效上下文管理的能力会产生良好的影响。

我知道时间快到了，我还有一个最后的问题。关于你看到的CrewAI和Exa的结合，有没有任何具体的用例让你印象深刻？或者你对AI智能体领域整体有什么看法，以及事情的发展方向？

考虑到大型语言模型能力的不断增强，那些具有最大灵活性的产品和框架变得越来越重要。因此，我认为我看到的涉及CrewAI和Exa的最酷用例，都体现了Crew和Exa共有的哲学：你有一个非常聪明的大型语言模型，尽可能赋予LLM智能和行动的能力，让它自由发挥，为它构建好用的工具，但不要过度干预或试图以非常具体的方式控制它。

因此，我在Exa上看到的所有最酷的东西都是这样的：你可以使用一些具有非常狭窄定义用例的产品，或者也许你想为自己构建类似的东西，但请赋予LLM力量，让它呼吸，灵活地使用工具。

“赋予LLM力量”，我很喜欢这个说法，我会更多地使用它。Jeff，非常感谢你，真的很感谢你今天抽出时间。这非常有帮助，我相信人们对在本课程中使用Exa感到超级兴奋，我敢肯定在这之后他们会更多地使用它。

是的，非常感谢邀请我，这很棒。

---

总结

在本节课中，我们一起学习了与AI智能体实践者Exa的对话。我们探讨了实时网络搜索对于AI智能体的重要性，它如何通过提供锚定于真实世界的数据来减少幻觉并增强智能体的能力。我们了解到，上下文窗口管理是当前智能体工具链中的一个关键挑战，高效的令牌使用至关重要。最后，我们认识到，赋予大型语言模型灵活性和权力，让它们能够自由地与强大工具（如精准搜索）交互，是构建下一代高效、实用AI智能体的核心哲学。

034：与Snyk的对话

在本节课中，我们将学习Snyk公司专家分享的关于多智能体系统安全性的见解。我们将探讨在设计和部署基于CrewAI等框架的智能体系统时，需要考虑的关键安全挑战、最佳实践以及未来的发展趋势。

---

引言：Snyk与安全

接下来，我们将听取Nick的分享。Snyk是一家专注于安全的软件公司。

Snyk是一个平台，服务于超过250万开发者，确保他们构建安全的代码。

他们正在使用CrewAI来驱动安全流程的多智能体自动化。

他们还将自己的平台与CrewAI智能体集成，以便使用CrewAI的开发者能够确保其代码安全并可用于生产。

他们在多智能体系统以及如何追踪这一正在推动软件行业发展的新趋势中的漏洞和安全问题方面，正在取得重大进展并进行大量投资。

我非常期待听到他们的分享。让我们直接开始。非常感谢您的加入。

我们对此感到兴奋。我们正尝试总结并与像您这样的行业专家交流，从您的视角看到了哪些趋势。

我认为您拥有独特的视角。

---

安全在多智能体生态系统中的重要性

因为您与Snyk合作，多年来一直思考安全问题，所以我希望问您几个问题。特别是随着智能体领域的不断发展，安全对整个生态系统的重要性在您看来如何？

首先，感谢邀请，很高兴来到这里。是的，Snyk的整个业务都围绕着帮助人们构建安全的应用程序。我认为，现在我们拥有了像使用CrewAI构建的这类智能体系统，这一点比以往任何时候都更加重要。我们是CrewAI的忠实粉丝，我个人也经常使用它，它非常棒。

但正如你们所有正在学习本课程的学生可能想象的那样，当你们构建智能体系统时，有很多事情需要考虑。你们可能会使用像CrewAI这样的框架，它对于组织智能体、让它们彼此通信、赋予它们访问不同工具的能力等方面非常出色。但这确实会带来需要考虑的全新类型的风险。

因此，当一个智能体执行某项任务并将信息传递给另一个智能体时，你们必须思考一些在过去的确定性世界中相对简单的事情。例如，这个智能体在与另一个智能体交互时，是否可能做出导致问题的行为？在我们的领域，我们实际上称之为“有毒流程”。

Snyk所做的工作之一，就是提供工具来分析你们的智能体、MCP服务器以及连接到应用程序中的所有工具。我们会查看工具定义，弄清楚每个工具在做什么，然后在后端使用生成式AI来应用一系列防护栏和过滤器，以帮助更好地理解当某些工具暴露给某些智能体时，可能发生什么类型的风险。

这只是需要考虑的新型安全问题之一，但显然这是一个非常广阔的领域，涉及很多方面。

---

安全部署工作流的关键挑战

这非常有趣，因为我认为这正是经验发挥作用的地方。为了能考虑到所有这些边缘情况，你们在实际中看到的一般性关键挑战有哪些？

从我们作为安全开发者、安全公司的角度来看，我们基本上会审视几个不同的方面来构建安全框架。首先，我们会查看应用程序的实际代码。多年来，我们一直拥有进行静态代码分析的工具。因此，首先我们会分析你们正在构建的自定义代码，寻找非常明显的安全问题。例如，像SQL注入攻击或跨站脚本攻击这类众所周知的问题，可以使用确定性逻辑轻松检测出来。你们不一定需要LLM来检测这些，并且可以用非常确定性的方式修复它们，因为修复SQL注入有100%明确的方法。这些问题可以说是已解决的问题。

因此，静态分析是现代应用安全的基本构建模块之一。但除此之外，当你们谈论构建更复杂的、自主工作的系统时，显然仍存在许多未知数。我们内部的工作方式是做两件事：首先，我们保持警惕，实际上我们有一个威胁情报源，当其他公司发生涉及智能体的有趣漏洞和安全事件时，它会让我们保持更新。每当有这样的事件公开，我们的安全研究团队基本上会收到通知，它可能链接到一些GitHub文章或其他公司的安全研究员。我们会让安全研究员仔细研究并分析它，思考“这是一种非常有趣的新型攻击吗？作为一家安全公司，我们能从中学习到什么，然后应用到我们的产品或研究中，以帮助客户以更安全的方式构建应用程序吗？”实际上，我们这样做已经有一段时间了。

因此，我们今天推出的许多产品，比如我们的MCP扫描工具（用于查找有毒流程等），最初都是受到我们遇到的新型漏洞的启发。我们对它们进行了大量研究，然后发现“嘿，这实际上是一些以前没有被真正讨论过的新东西，让我们围绕这个构建产品，比如构建防护措施和教育材料，让人们更容易在未来防止这种情况发生。”

---

实际案例与安全思维模式

这太有趣了。我想其中一个漏洞是那次大型的GitHub漏洞，你们实际上能够自己检测到，对吗？

是的，没错。今年早些时候，我们的一位研究员发表了一些非常有趣的研究，基本上发现GitHub正在使用大型语言模型，并对GitHub Issues进行一些自动化处理。攻击者通过GitHub Issue进行一些巧妙的提示注入操作，能够泄露仓库的敏感信息。

因此，在你们构建东西的过程中，在脑海中建立这类威胁模型是非常有用的。所以，我想告诉正在学习这些东西并构建他们第一个自主系统的学生们：当你们构建这些东西时，在脑海深处不必感到害怕，但要记住可能会出什么问题，以及我将如何解决这些问题。只要你们正确地思考这些事情，你们就处于开发专业人员的前1%。因为思考风险，并将其记在脑中，确保以良好的方式架构事物，这不仅是你们能为应用程序做的最好的事情之一，也是为你们的职业生涯做的最好的事情之一。拥有良好的安全实践和安全思维模式，是成为现代圈子里优秀工程师的关键部分。

我喜欢您的表述方式，即“安全思维模式”。如果从一开始就采取这种方法，当你们构建每一个功能时，只需问自己：我在这里可能暴露了哪些攻击面？我该如何保护它？仅这一点就已经能改变局面，因为大多数人不会这样做。因此，作为工程师，你们能够这样思考，我认为这可能是一个巨大的差异化优势。

---

将智能体集成到现有工作流中的挑战

您提到了几个要点，比如AI生成的代码，MCP是另一个大问题。你们看到人们在尝试将这些智能体集成到现有CI/CD管道中时，遇到了哪些挑战？人们是在为此挣扎，还是已经解决了这个问题？

这是一个非常好的问题。我觉得在回答这个问题时有些矛盾。一方面，我觉得将智能体工具和功能添加到应用程序中从未如此简单。以Snyk为例，我们公司已经存在相当长一段时间了，我们有很多旧项目，可能是内部项目，已经有一段时间没有维护了。有时我甚至会直接进去，用AI重写它们，或者在管道中添加一堆新功能。凭借我们今天可用的工具，你们能够以我甚至在四年前都认为不可能的速度完成这些工作，这完全令人难以置信。

但与此同时，对人们来说，这也可能非常可怕。我认为这是最大的担忧，尤其是在大公司工作的人们。我认为人们在将这类工具和实践引入现代工作场所时，最大的担忧是存在一些恐惧和不确定性。人们会想：“嘿，如果我把这个智能体放在这里，使用它安全吗？这会以某种方式暴露客户信息吗？”人们担心的组件很多，即使是一个非常简单的例子。

从生成式AI开始流行之初，你们在文章和网络帖子中最常听到的事情之一就是对提示注入的恐惧。提示注入仍然是一个大问题，而且不一定已经解决。没有100%万无一失的方法来完全解决提示注入，因为生成式模型是非确定性的，幕后发生的事情有很多神秘之处。

因此，对于每个模型，可能有不同的最佳实践方法来避免或修复它。也许这意味着让其他生成式AI审查提示，然后尝试查看其中是否有任何可疑之处；也许意味着在扫描工具或安全应用程序中设置一些确定性逻辑来检查它；或者也许意味着拥有良好的运行时工具和可观察性，以便当你们的智能体和工具实际执行操作时，你们可以让人或另一个智能体回顾这些操作的运行时历史记录，并寻找可疑模式。有很多方法可以解决这些问题，但根本上，我认为这又回到了拥有良好的安全思维模式并在工程工作中积极主动。

---

自主AI与安全的未来关系

这是一个非常好的观点，我同意您的看法。提示注入是您重新提及的一个很好的话题，因为很多人再次谈论它，但现在人们谈论得没那么多了，但问题并没有消失。是的，它仍然存在。你们可以找到一些方法来让LLM识别它们，可以尝试主动预防，但归根结底，没有100%的保证，没有“启用这个标志，一切就都解决了”的方法。

这让我想知道，我很想听听您对这个问题的看法：您如何看待自主AI与安全之间的关系？这是一个难题，因为市场变化太快了。但您如何看待这种结合在未来三年内的发展？

我认为有几件事非常有趣。首先，AI模型的改进速度总体上快得惊人。即使是一个非常基础的提示，你们得到的很多软件在结构和内容方面都可以非常好。那么安全如何融入其中呢？我认为我们正接近一个点，即安全可以成为一个完全自主的事情。我的意思是，将LLM和智能体以及非确定性应用程序与一个确定性的安全工具配对，这个工具可以100%确定地告诉你们这里是否存在问题或是否发生了不好的事情，并将其作为反馈来帮助智能体改进和引导它。我认为这正迅速成为我们领域的制胜策略。

如果你们曾经使用过Snyk的任何工具（可以免费使用，只需注册即可试用），你们会注意到一件事：假设你们正在使用Cursor之类的工具编写软件，你们可以将Snyk的工具插入到Cursor规则中。当你们提示Cursor并要求它构建一个新的CrewAI流程或类似的东西时，每次Cursor向项目添加一些代码时，它都会在后台使用Snyk自动扫描并查找许多常见类型的问题，利用Snyk提供的上下文，然后Cursor本身实际上会发布修复程序，重新测试以确保这些问题得到解决。这就创建了一个非常有趣的自主循环，我们已经从中看到了非常显著的效果。

因此，在我看来，安全领域在这个自主未来的演变方式是，它正成为使用生成式AI的一个迭代部分。我个人的希望是，在未来三年内，我们将达到这样一个点：典型的工程师甚至不需要考虑安全方面的努力。他们将能够直接说：“嘿，Cursor或Claude，或者任何工具，帮我构建这个应用程序。”安全将通过这种迭代过程在幕后处理，最终结果是我们作为用户将拥有更好的软件，我们不必过多担心这些事情。这有点像梦想。

---

CrewAI在生态系统中的角色

我喜欢这个观点。您说得完全正确。如果LLM在编写代码方面越来越好，它们也应该在预防和修复代码方面越来越好。这是一个有趣的愿景。

在我们结束之前，我知道您提到过您自己也在使用AI，并且我们一直在讨论CrewAI如何帮助人们使用它。您如何看待CrewAI在这个生态系统中的角色？它是如何集成的？我知道我们也有一些合作正在进行，但您对此有何看法？

当你们最初推出时，我想我是通过Hacker News发现你们的，当时我一直在关注你们的教程，构建一些系统，并在Python应用程序中进行一些编排，非常喜欢。我认为你们的一个优势是在工程方面有一个非常清晰的框架，使得构建智能体变得非常可重复和可靠。例如，拥有像AML文件中那样漂亮的智能体定义，拥有流程、Crew和编排组件，我认为这些都是我们可能认为理所当然但你们已经主流化的东西。因此，我是它的忠实粉丝。

实际上，在Snyk内部，我们构建并运行了大量项目，直接在生产中使用CrewAI，它们非常棒。我们用它来做任何事情，从帮助自动化员工社交媒体，到为我们正在推出的新产品构建产品框架和参考文档。这些工具内部驱动的自动化数量巨大，而且它们感觉非常稳定，我认为这主要归功于CrewAI框架。所以，谢谢你们。

谢谢您的使用。我对未来的发展感到兴奋。我认为智能体领域正在发生很多事情，我想我们正一同前行。

非常感谢，Nick。我真的很感激您抽出时间，非常高兴您能来到这里，也希望所有学习者有所收获。我不知道您是否对所有的学习者有什么临别赠言，但我的问题就这些了。

我只想说，对于所有正在学习这门课程的你们，你们很棒，继续构建，享受乐趣。这就是这一切的意义所在：使用AI让生活更愉快。它确实为我做到了这一点，希望对你们也是如此。

我喜欢这个说法。非常感谢，Nick。下次再聊，祝您一切顺利。

---

总结

本节课中，我们一起学习了Snyk专家分享的关于多智能体系统安全的核心观点。我们探讨了在构建自主系统时，安全思维模式的重要性，以及如何识别和防范如“有毒流程”、提示注入等新型风险。我们还了解了将智能体集成到现有工作流中的挑战与机遇，并展望了未来安全与自主AI协同演进的愿景。最后，我们看到了像CrewAI这样的框架在提供清晰、可靠的工程基础方面所扮演的关键角色。记住，主动思考安全并采用最佳实践，是构建健壮、可信的多智能体系统的基石。

035：5. 与 Weaviate 的对话 🗣️💾

在本节课中，我们将聆听来自开源向量数据库 Weaviate 的分享。我们将了解向量数据库在多智能体系统中的重要性，以及它如何赋能智能体访问动态、相关的信息。同时，我们也会探讨开发者在集成向量搜索时常见的挑战和最佳实践。

---

接下来，我们将听到来自 Weaviate 的分享。Weaviate 是一个开源向量数据库。它不仅允许你存储信息，还能让你的智能体自行利用这些信息。当你需要进行向量搜索时，其强大的搜索能力可以驱动许多出色的应用场景。我们希望从他们的视角了解，作为目前被广泛采用的主流数据库之一，他们的看法。

让我们开始吧。

塞巴斯蒂安，非常感谢你今天与我们在一起。我们很高兴能邀请到 Weaviate 的成员参与本课程。我有几个问题想问你。随着生成式 AI 领域的持续发展，拥有包括 Weaviate 这样的向量数据库在内的更广泛的工具和资源生态系统有多重要？

我认为这绝对至关重要。这很像你可以有一个“10倍效率”的开发者，他似乎无所不知。

但你依赖的是这样一个单一故障点。同时，这个“10倍效率”的开发者能走多远也是问题。沿用同样的类比，如果你有一个更全面、技能甚至有时有所重叠的团队，你们可以取得更多成就。我认为这很好地转化到了 AI 生态系统中。我们可以一起做更多事情。如果我们想完全靠自己完成所有事情，我们将会失败。

这是最好的事情，因为我们每个人都可以专注于自己最擅长的事情。我们也总是在思考：如何集成、如何连接、如何与所有这些其他工具协同思考，以及我们如何作为一个生态系统来工作。我们可以像一个团队一样工作和协作，因为我们属于一个整体。我们不是试图独自取胜的独立团队。

“我们属于一个整体”这个说法我很喜欢，我会更频繁地使用它，说得很好。那么具体到 RAG 领域，现在很多人都在谈论，每个人都在做 RAG。你如何看待向量知识库角色的演变，特别是围绕 AI 智能体变得越来越自主这一理念？

向量数据库和向量嵌入在其中扮演着相当关键的角色。因为如果一个智能体只依赖大语言模型，那么你基本上依赖的是其固有的知识库。而如果你使用向量数据库，你就能访问动态的、可以在一分钟甚至一秒钟内变化的数据，并且总能获得最新的信息。

信息不仅是最新的，而且非常相关。你只获得相关的信息，因此信息量会小很多。你不会向你的大语言模型发送长达 100 页的 PDF，而只是发送相关的部分。

另一个方面是，你获得的信息可能对特定用户是相关的。也许你的智能体工作流服务于成百上千的用户，每个用户都有自己的数据。你不可能为每个用户都配备一个大语言模型，那将非常疯狂，而且更新每个模型也需要很长时间。

此外，你可以使用各种分区策略，将数据分离到不同的租户中。这样，我永远不会查询你的数据部分，你也永远不会查询我的。因此，数据库基本上可以增强智能体，提供更多你期望成熟数据库具备的保护和安全措施。

有你希望智能体访问的数据，并且你希望确保这些数据是新鲜的。有几种方法可以实现这一点，但我认为没有哪个像 Weaviate 这样的向量数据库能给你所有的控制权。因为你不仅需要最新的数据，还可以控制一切。

当你想到通过将智能体编排与向量检索紧密结合而成为可能的新一类应用程序和用例时，这确实令人兴奋。你是否经常听到关于智能体与向量检索紧密结合的具体用例？有哪些有趣的例子？

我经常思考的是，我们可以从数据库中提取什么信息返回给大语言模型。一个例子是，实际上一年多以前，我们重写了一些语言客户端，完全更改了 Python、TypeScript 和其他语言中的 API。我们今天面临的困境是，很多大语言模型是用旧的 API 训练的，所以当有人试图用大语言模型生成 Weaviate 代码时，他们得到的是旧代码。我们不希望人们使用旧代码，因为旧代码不够好，新代码很棒。

通过使用数据库，我们可以说：让我们删除所有提及旧 API 的记录，只使用新的示例。这样，我们不仅可以添加更多信息，甚至可以限制信息，比如“永远不要展示这部分”，因为我们可以删除它或将其过滤掉。

对我来说，智能体几乎就像是帮助人们获取最准确信息的人，这些信息也与你的数据相关。你不希望得到类似“这是一个 Weaviate 查询示例”这样的通用回答，而是希望得到“你有这三个集合，这是你如何用这些特定属性查询这个特定集合”的具体指导。这非常强大。

现在人们开始理解提示工程和数据如何工作，以及为什么这很重要。但随着人们转向使用智能体，会有许多与大语言模型的 API 调用，复杂性工程变得至关重要。我们在整个课程中都讨论过这个观点，即你需要尽可能优化。开发者应该如何思考向量数据库和复杂性工程的角色？

老实说，可以这样想：智能体对我来说就像人。如果你每次都将那 400 页的 PDF 发送给他们，并说“嘿，我有个问题”，有时问题可能很简单，比如“如何连接到数据库”，而这个答案可能就在第一页。但我认为大语言模型会尝试阅读整个上下文。最终你得到的是非常缓慢且效率低下的结果，你是在过度使用资源。

对我来说，这始终是关于：智能体需要什么？大语言模型需要什么来完成这项任务？

这是一个很好的观点。我们来谈谈挑战。当人们试图将向量和向量搜索引入智能体时，常见的陷阱或反模式是什么？人们通常做错什么，需要注意什么？

我认为其中一点是经典的数据问题：垃圾进，垃圾出。通常，嵌入模型在处理非结构化数据方面确实很好，但这并不意味着非结构化数据本身可以是垃圾，完全一团糟。我们常常对这类事情思考得不够。

例如，我是否应该基于特定字段创建我的向量嵌入？你真的需要作者姓名或电子邮件等所有其他信息吗？可能不需要。所以这又是一个“少即是多”的问题。

我经常注意到的另一点是，向量嵌入可能非常大。如果你想扩展到数十亿个对象和数十亿个向量怎么办？我不确定你能那么容易或便宜地获得那么多内存，那会很昂贵。这是一个常见的陷阱：你没有评估运行所需查询所需的资源。

你可以做一些事情来解决这个问题。你可以减少向量的大小，要么减少维度数量，要么将每个维度更改为一个字节甚至一个比特的大小。这样，你可以将所需的内存减少到四分之一。我们在 Weaviate 中内置了这个功能，只需两行代码即可启用量化，但它实际上非常强大。

我们最近发布了一个叫做“旋转量化”的功能。我们原以为量化会减慢查询速度，但事实恰恰相反，查询速度更快了。当我们测量其与未压缩向量的召回率时，差异大约只有 0.01%。你只能在类似实验室的环境中注意到这种差异。为什么不默认这样做呢？

这太不可思议了。所以这可能是两个常见的陷阱：一是在生成向量嵌入时发送太多不精确的信息；二是在运行整个系统时没有考虑向量嵌入可能有多大。

这是一个有趣的视角。作为一家向量数据库公司，你们处于这场革命的核心，观察着各种不同的搜索方式、不同的公司、不同的框架和不同的智能体。你对 CrewAI 有什么看法？你看到 CrewAI 如何与 Weaviate 协作？请与我们分享更多。

我喜欢 CrewAI 的一点是，我们团队之间有这种协同效应。你们真的在考虑开发者体验。我对开发者体验充满热情，所以这对我来说已经表明你们关心那些试图构建东西的开发者。这也是我们得到的反馈。

当我们在一些研讨会上尝试使用 CrewAI 时，反馈总是：我可以轻松地跟着前几步走，我已经知道该做什么了。你们也有非常相似的“快速实现价值”的理念：我花了半小时完成快速入门，阅读了一些示例。

但还有一个非常清晰的部分是：如何进入生产环境？当出现问题时，你会得到一个可以采取行动的错误信息。而有些框架每三个月左右就会改变它们的语法和 API，这每次都让我抓狂，因为我想用这个框架演示，结果发现“哦，我的演示不工作了”，原因是“我不应该更新我的 NPM 包或 Python 库”。

但使用 CrewAI 我还没有遇到过这个问题。你们在这一点上相当负责。我喜欢有充分理由的重大变更，但不喜欢那种破坏一切、甚至让我无法连接的变更。我认为这非常棒，因为你们关心我们这些使用你们框架和 API 的开发者。而且，我能读懂代码。

感谢你的美言。塞巴斯蒂安，你还有什么想留给我们的观众吗？我知道我们谈了很多事情，不知道你是否有什么最后的想法想留给学习者。

对我来说，我最关心的性能类型实际上是开发者的性能，即“如果你拥有这套工具，你能多快地交付解决方案”。我认为这绝对超级重要。

在我们所处的这个 AI 生态系统中，要始终思考“实现价值的速度”：你能多快完成概念验证，多快进入生产环境，以及多快地增长和扩展。有些解决方案可能是企业级的，有些可能是开源项目，有些可能只是你为自己构建的东西。这应该是同一套技能，不应该为企业级和你的个人项目使用完全不同的解决方案。你构建的技能和解决方案应该整合在一起，成为一件事、一套技能，这将使你变得非常强大。

然后，选择合适的工具。你已经有了两个，比如 CrewAI 和 Weaviate。选择其他工具时，要选择那些不会锁定你的工具。它们应该因为你喜欢而让你留下，而不是因为你没有其他选择。这就是我的建议。

这是一个有趣的建议。塞巴斯蒂安，非常感谢你加入我们的课程。我相信所有学生都会很感激。祝你一切顺利，大家也祝你好运，构建一些非常棒的东西。

说得好，保重。再见。

---

在本节课中，我们一起学习了向量数据库 Weaviate 在多智能体系统中的核心作用。我们了解到向量数据库如何为智能体提供动态、相关且安全的数据访问，从而克服仅依赖大语言模型的知识局限性。同时，我们也探讨了在集成向量搜索时需要注意的常见陷阱，如数据质量和资源规划，并看到了 CrewAI 与 Weaviate 在提升开发者体验和实现价值速度方面的协同效应。选择合适的工具并关注开发效率，是构建强大 AI 应用的关键。

036：与百威英博的对话

在本节课中，我们将学习全球最大饮料公司之一——百威英博（AB InBev）如何在其业务中应用CrewAI构建多智能体系统。我们将了解他们面临的挑战、采用的策略以及取得的初步成果。

接下来，你将听到关于百威英博的介绍。他们在全球拥有超过500个标志性品牌。作为全球最大的饮料公司之一，他们正在整个业务中使用CrewAI构建多智能体系统，范围从商业数字平台到自动化后台办公用例。他们是一家规模庞大的公司，在使用AI智能体方面拥有巨大潜力，并且是我们利用AI智能体重塑劳动力这一旅程中的重要合作伙伴。接下来你将听到他们的分享。让我们开始吧。

探索AI智能体的动机与挑战

上一节我们介绍了百威英博的背景，本节中我们来看看他们决定探索AI智能体的主要动机和初期挑战。

Daniel分享了他们最初使用CrewAI开源版本的经历，并指出一个重要的注意事项：CrewAI实际上帮助他们制定了智能体策略。起初，他们更多地是尝试理解和学习如何以智能体为导向构建流程。

“智能体团队”和“工作流”的概念对他们帮助很大，并促使他们创建了一个内部框架。这个框架现在正帮助他们进行流程映射。

Daniel认为，流程是最大的挑战。关键在于如何将业务流程进行映射，并转化为具体的行动步骤，进而确定需要创建哪些智能体，以及这些智能体需要使用哪些工具来执行这些行动。将流程转化为“智能体团队-工作流”的视角，这一转变对他们非常有帮助。

早期部署的影响与收益

了解了挑战之后，我们来看看部署智能体系统带来的早期影响和收益。

首先是在开发智能体方面的生产力提升。初期，由于团队缺乏相关知识，他们在如何构建智能体、设计最佳架构以及将其集成到现有系统中遇到了困难。

对他们而言，一个超级重要的原则是不创建新系统，而是将智能体嵌入到现有系统中。这样才能真正改造流程并提升效率。

从技术角度看，随着时间推移，他们获得了巨大的生产力收益。当团队熟练使用CrewAI构建智能体后，速度变得非常快。在升级到企业版并使用Studio后，甚至连业务部门的同事也开始使用CrewAI。

Daniel提到，他的生活已经变成了“Crew生活”，因为不仅是技术团队，业务团队也在使用。这非常有益，因为他们相信创建智能体网络的价值。如果一个智能体可以被创建、复制，并跨职能、跨内部团队、在业务与技术团队之间使用，那么就能实现生产力提升。这一点对他们来说非常强大。

Sean总结道，将智能体嵌入现有系统有两个好处：一是便于分发，用户无需改变习惯即可获得更好体验，从而更容易采纳；二是可以建立智能体知识库，避免重复劳动，实现“一次构建，全球部署”，确保在所有不同业务单元中使用。

规模化扩展的挑战与应对策略

看到了初步收益，接下来面临的挑战就是如何将成功经验规模化。Daniel提到了团队培训是一个大挑战。

他们通过在全球范围内举办研讨会和培训课程来解决这个问题。这对他们来说规模很大，因为他们要覆盖大约40个国家。百威英博有六个大区，目前已有三到四个大区在使用CrewAI，并计划在明年年中前让所有六个大区都用上。

最大的挑战之一就是规模化。当CrewAI启动并运行后，他们需要培训团队。Daniel内部称之为“季前赛”，即先与团队进行内部演练，然后再进入“正式比赛”。这是他们与CrewAI合作创建的内部框架的一部分，包括在内部平台和工具上进行培训。

从技术挑战来看，上下文管理是最大的挑战，特别是对于他们这样业务遍布全球的碎片化公司。但另一方面，全球各地的用例却几乎相同。无论是供应链、采购还是物流，挑战都大同小异。

真正的挑战在于系统差异。例如，在构建自动化任务的薪资智能体时，他们在全球有超过15个不同的薪资系统。虽然可以复制智能体模板，但每个国家都有特定的需求。因此，他们需要构建能够全球扩展的解决方案，这是一项庞大而复杂的工程工作。然而，由于整个公司都在使用相同的CrewAI智能体框架，这使得全球扩展智能体变得容易得多。这条路并非一蹴而就，而是从初期错误中摸索出来的。

消费品行业的应用洞察与建议

上一节讨论了规模化，本节我们聚焦于消费品行业应用AI智能体的关键考量。

Daniel分享了他们最大的经验之一：深入聚焦，而非广泛铺开。他们定义了几个优先改造的流程。消费品公司通常涉及庞大的运营体系，包括繁重的运营、物流、分销中心（对他们而言是酿酒厂）以及巨大的销售运营网络，人员遍布全球，流程改造非常困难。

他们决定深入某一个流程，这带来了巨大改变。他们选择处理那些他们有一定知识储备、能够映射流程并最终评估的领域。评估因素包括技术的成熟度。例如，如果某个流程还在使用Excel（这在全球公司中很常见），那么将智能体集成到现有系统中的方式就会完全不同，需要不同的技术方案和流程映射方法。

目前，他们优先考虑那些可以在内部端到端控制的职能，例如法务、财务，而不是严重依赖现场合作伙伴的销售或分销职能。这些端到端可控的职能是他们起步的领域。

就挑战而言，现在熟练使用CrewAI后，最大的挑战更多在于流程映射和智能体工作流设计。另一方面，也要避免创造不必要的复杂性，因为工程师有时会因技术兴奋而构建非必需的东西。

Sean提到，每家公司都有相似的软件栈，如数据管理、ERP、CRM等，如何集成这些系统是每家公司都在思考的问题。Daniel认为，智能体可以扮演重要角色。他将其与大约15年前的API网关相类比。当时，API网关在数字转型中扮演了关键角色，公司需要处理遗留系统，同时构建未来。现在，他们构建的智能体以及由CrewAI驱动的整体智能体策略，加上内部工具和新流程，就类似于过去的API网关。但现在有了生成式AI和LLM的加持，使得生产力比过去提升了10到50倍。

总结与建议

在本节课中，我们一起学习了百威英博应用CrewAI构建多智能体系统的实践经验。

Daniel在最后分享了他们的关键收获，并与本课程内容相联系：做好准备工作，这对他们产生了巨大影响，因此他相信本课程对所有考虑使用CrewAI的人都会非常有帮助。

他最后的建议是：在当前AI市场日新月异的环境下，对于在公司做技术决策的人来说，专注于某些技术并加倍投入是明智的，要确保我们构建的东西能够规模化。他认为，CrewAI设计整个框架的方式非常强大。首先，做好“季前赛”准备；其次，至少加倍投入一项能够融入我们生态系统的优秀技术，这样才能实现规模化。

本节课到此结束。我们了解了从动机、挑战、早期收益到规模化策略和行业洞察的全过程，这些经验对于任何希望在企业中部署AI智能体的团队都具有宝贵的参考价值。

037：AI 智能体的未来 🚀

概述

在本节课中，我们将探讨 AI 智能体未来的发展趋势。我们将了解智能体管理平台的出现、开源与闭源模型的选择、模型微调的重要性，以及自我改进与长期运行智能体等前沿方向。理解这些趋势将帮助你更好地规划和构建未来的 AI 应用。

---

智能体管理平台的出现 🏢

到目前为止，你已经取得了巨大的进步。你几乎完成了这门课程，并学习了从设计、开发到部署 AI 智能体的全过程。现在，让我们探索 AI 智能体正在重塑未来的几种不同方式，以及你如何参与其中。

首先，我们需要花时间讨论一下 AI 智能体的未来，比如六个月或一年后会是什么样子。虽然我们无法完全控制其发展，但已经出现了一些模式，暗示了事物的发展方向。

第一个趋势是智能体管理平台的出现。根据客户或公司选择的目标，这种平台会呈现出不同的形态。但组织无疑需要一个管理层面来协调整个公司的智能体采用。

这些平台可以作为单一控制源，不仅管理可复用的用例，还提供集中的监控、功能增强和安全性。智能体管理平台将提供三个核心能力：

1. 构建与集成用例的能力：能够极其快速地启动。
2. 在这些用例中建立信任的能力：能够观察和优化运行中的用例。
3. 交付价值的能力：随着用例获得越来越多的关注，能够管理和扩展它们。

这个编排层位于运行中的智能体之上，让公司能够控制发生了什么、如何发生以及何时发生。这无疑是我们在人们讨论采用 AI 智能体时看到的一种模式。

---

平台的核心能力与软件工程模式 🔧

上一节我们介绍了智能体管理平台的概念，本节中我们来看看其具体的核心能力。

如果深入观察这些具体能力，你会发现它们细分为更小的功能。在编排方面，你会看到规划、推理、记忆、护栏和知识管理。在观察方面，则涉及我们讨论过的追踪、训练和测试，包括基于事件的自动化。

在构建和集成方面，你可能希望用代码构建，也可能希望像我们在 Studio 中那样进行无代码构建；你可能希望使用本地工具，也可能希望使用其他 AI 或外部触发器。在管理和扩展方面，你需要确保能够快速部署、邀请团队成员、控制权限，并拥有一些后台监控。

一些项目和公司处理端到端的整个工作流程，而另一些则专注于特定的能力。但关键在于，这里存在一个涵盖整个流程的编排层。

正如我们讨论过的，从观察到优化再到构建，你会发现很多共通之处。在传统软件工程和这里的智能体工程之间，你肯定能识别出一些模式。例如，观察层通常与构建和集成层是分离的，这体现了关注点分离的原则。这只是一个例子，但这里还有许多其他关注点。

---

新兴的技术栈与用户反馈 🧱

我们看到，随着世界的发展，一个新的技术栈正在形成。这个技术栈从数据管理延伸到大型语言模型，再到编排、可观测性、身份验证、连接器，最终汇聚成生成式 AI 应用（或称 Gen 应用）。

在最顶层，用户通过界面与智能体交互，这些界面可以是对话式的（如聊天界面），甚至是传统的基于按钮的设计。然而，从用户反馈中，有三个团队持续出现。我们在前面提到过，但这里想再次强调。在整个技术栈中，有许多最常见和最常被提及的担忧。

其中之一是我们在早期课程中简要提到的：客户正在避免供应商锁定。这种担忧可以追溯到云计算时代，当时迁移经验表明，公司变得依赖托管服务，随着成本增加，组织发现自己被锁定，难以将工作负载迁移到其他替代方案（例如使用 Kubernetes）。经历过这些挑战的领导者，在采用 AI 智能体时更加谨慎。

因此，公司确实需要灵活性。这不仅关乎供应商锁定（当你考虑超大规模云提供商或不同部署方法时，这确实是个问题），还关乎为工作选择合适工具的能力。因为你可以为不同的智能体使用不同的 LLM，实际上可以在其中建立一个优化层。这也为你使用开源模型甚至进行微调打开了空间。

这里的核心思想是，组织希望拥有在任何地方运行其工作负载的自由，无论是在本地服务上，还是在任何他们使用的超大规模云上。公司还希望使用许多不同的模型，不仅仅是 OpenAI 或 Claude，而是从他们已采购的任何供应商中进行挑选。

CrewAI 作为一个框架和平台，允许你下载在用户界面上生成的任何内容的代码。CrewAI 从设计之初就旨在让你利用这种互操作性，不仅在 LLM 层面，甚至在智能体群组本身。因此，即使在我们之前使用的无代码体验中，你也不会被锁定，因为你可以随时为你用户界面上生成的任何内容下载代码，并随身携带，因为那是你的知识产权。这解决了许多关于平台依赖性的担忧。

---

开源与闭源模型的选择 🤖

既然我们谈到了模型，那么理解何时使用开源模型、何时使用闭源模型以及这样做的一些好处就很重要。

公司通常会根据其需求，针对开源或闭源模型进行优化。例如，自行运行模型已经变得容易得多，特别是借助像 llama.cpp 或 TensorRT-LLM 这样的工具。这意味着你可以获取全球正在生产的这些优秀模型，自行托管，甚至微调它们以使其更好。

像 GPT-4 和 Claude Sonnet 4.5 这样的闭源模型，通常附带更好的内置功能，开箱即用，这给了它们优势。但开源模型在能力上已经迎头赶上，现在许多公司实际上开源了他们自己的模型。你不仅可以利用这些模型，还可以针对特定的应用领域对它们进行微调，使它们成为更适合你和你的用例的智能体。

你还可以在本地运行它们以确保隐私，并确保你仍然符合任何治理政策。此外，你可以大幅降低使用成本，并避免在使用这些试图服务全球用户的外部提供商模型时可能遇到的任何速率限制。

现在，如果你观察闭源模型，你会发现它们为复杂任务提供了更先进的推理模型，并为可预测的行为提供了许多安全性和鲁棒性功能，允许你通过托管服务轻松集成。

然而，你应该警惕在较小的模型上运行你的智能体。参数少于 140 亿或 200 亿的模型，当你试图将它们扩展到智能体行为时，通常效果不佳。它们只是无法像更大的模型那样遵循指令。因此，智能体通常需要更强大的模型才能有效执行。

话虽如此，随着新模型的推出，它们通常更先进。所以你现在看到了一整套新型模型，它们更小但也非常强大。例如，开源模型 Qwen2.5-20B 肯定可以用于一些智能体行为，但你会在更大的模型上发现更好的性能。

---

模型微调的重要性 ⚙️

现在，我想花点时间关注一下微调。微调在过去几年中被广泛讨论，但大多数公司仍未采用。这很不幸，因为微调在成本节约和性能改进（尤其是速度方面）提供了巨大的潜力。

然而，采用的障碍很高。没有丰富 AI 训练经验的公司发现很难自信地掌握模型微调。随着进入门槛的降低，以及微调对智能体变得更加容易，采用率可能会增加。公司确实希望获得微调带来的好处。

例如，你可以省钱，因为你可以运行更小的模型；而且它们运行得更快，因为效率更高。因此，构建这些 AI 智能体用例的公司，实际上想要微调的结果，但在执行上遇到了困难。随着摩擦减少，更多的公司将追求微调，而通过智能体微调模型是获得更好结果的一种非常有效的方法。

---

未来趋势：自我改进与长期运行智能体 🔄

展望未来，AI 智能体开发中有两个趋势正在融合。这是我们从智能体开发前沿听到的，即自我改进和长期运行智能体。

对于自我改进的智能体，我们不仅希望它们像现在这样随时间获取记忆，还希望确保它们在这方面变得更好、更有效。我们还希望这些智能体能持续评估自己的表现，并相应地调整行为，实现持续改进。在成千上万次执行中做到这一点，是人们努力追求的目标。这种自我改进能力已内置在 CrewAI 中，我们仍在大力投资以进一步增强它。

长期运行智能体是公司正在思考的另一个方向，即智能体可以在没有人类交互的情况下，持续运行很长时间（有时甚至数小时），并仍然取得出色的成果。持续时间取决于你的配置、智能体数量和系统设置。但可以肯定的是，业界正在积极优化自我改进和长期运行智能体，并探索如何有效地构建它们。

如果你想想昨天的智能体，你会发现它们会闲置等待指令，执行非常短期的水平任务（可能只有几分钟），并在执行后忘记任务。而明天的智能体则完全不同，它们能够被事件自主触发，执行更长时间（有时数小时），并且擅长存储运行时获得的所有洞察，以便随时间进行自我反思和改进。这是业界试图将 AI 智能体提升到下一个水平的主要驱动力。

---

核心原则：可靠性高于一切 🎯

最后，我想回到一个非常重要的原则。即使听完所有这些功能，如果你必须从这门课程中带走一样东西，那就是：当你构建智能体自动化时，你不应该只追求自动化。你应该将可靠性构建到你创造的每一样东西中。

这使你的 AI 智能体为生产环境做好准备。当你设计、构建和部署智能体时，时刻牢记这一点，你就能取得显著的成果。

总结

本节课中，我们一起学习了 AI 智能体的未来发展趋势。我们探讨了智能体管理平台的作用、开源与闭源模型的权衡、模型微调的价值，以及自我改进与长期运行智能体等前沿方向。最重要的是，我们认识到，在构建 AI 智能体时，可靠性是比单纯追求自动化更根本的原则。希望这些知识能帮助你在未来的 AI 项目中做出明智的决策。

038：课程总结 🎉

在本节课中，我们将对《使用 CrewAI 设计、开发与部署多智能体系统》课程的核心内容进行回顾与总结。

恭喜你完成本课程。你学到了很多关于AI智能体的知识。

我们讨论了如何构建它们、如何部署它们以及其间的所有环节。

现在，你需要将所学的一切应用到日常工作和构建这些用例中。

如果你发现有任何遗漏，或者想了解更多关于AI智能体的信息，请联系我们。你可以在LinkedIn或Twitter上找到我，无论你选择哪个平台，我都非常期待与你交流所有关于AI智能体的内容。

你为此付出的所有努力给我留下了深刻印象。希望你已经看到了这对未来技术和AI智能体发展的意义。

期待不久后与你再见。祝你一切顺利。😊

---

本节课中，我们一起回顾了整个课程的学习历程，总结了关于AI智能体构建与部署的核心知识，并鼓励你将所学付诸实践。