吴恩达：提升AI Agent能力的四种设计模式吴恩达在3月份发博文，敦促关注AI Agent工作流，其中提到后续将介绍

吴恩达在3月份发博文，敦促关注AI Agent工作流，其中提到后续将介绍四种设计模式提升LLM应用能力：

反思 Reflection：大型语言模型（LLM）检查自己的工作，以提出改进的方法。
工具使用 Tool Use：LLM被赋予了工具，如网络搜索、代码执行或任何其他功能，以帮助它收集信息、采取行动或处理数据。
规划 Planning：LLM提出并执行一个多步骤计划来实现目标（例如，为文章撰写大纲，然后进行在线研究，接着撰写草稿，等等）。
多代理协作 Multi-agent collaboration：多个AI代理共同工作，分配任务并讨论辩论想法，以提出比单个代理更好的解决方案。

四月份，他已一一发文（原文链接见文末），介绍他对这种四种设计模式的观点，对每种模式都给出了多篇相关的参考论文，并且认为在当下的大模型能力下 Reflection 和 Tool Use相对可靠，而Planning和Multi-agent collaboration 的输出质量相对难以控制，对这些模式想快速上手实践，可参考：吴恩达力推的AI Agent平台，国内哪家强。

一、反思 Reflection

大型语言模型可以通过反思自己的行为成为更有效的智能体。

你可能有过这样的经历：提示 ChatGPT/Claude/Gemini，收到不满意的输出，提供关键反馈以帮助 LLM 改进其响应，然后获得更好的响应。如果您自动执行提供关键反馈的步骤，以便模型自动批评自己的输出并改进其响应，会怎么样？这是反思的关键所在。

以要求 LLM 编写代码的任务为例。我们可以提示它直接生成所需的代码来执行一些任务 X。之后，我们可以提示它反思自己的输出，可能如下：

以下是用于任务 X 的代码：[以前生成的代码]
仔细检查代码的正确性、风格和效率，并就如何改进它提出建设性的批评。

有时这会导致 LLM 发现问题并提出建设性的建议。接下来，我们可以用上下文提示 LLM，包括（i）以前生成的代码和建设性反馈，以及（ii）要求它使用反馈重写代码。这可以带来更好的响应。重复批评/重写过程可能会产生进一步的改进。这种自我反思过程使 LLM 能够发现差距并改进其在各种任务上的输出，包括生成代码、编写文本和回答问题。

我们可以通过提供 LLM 工具来帮助评估其输出来超越自我反思;例如，通过一些单元测试运行其代码，以检查它是否在测试用例上生成正确的结果，或者搜索 Web 以仔细检查文本输出。然后，它可以反思发现的任何错误并提出改进的想法。

此外，我们可以使用多智能体框架实现 Reflection。我发现创建两个不同的智能体很方便，一个提示生成良好的输出，另一个提示对第一个智能体的输出提出建设性的批评。由此产生的两个代理之间的讨论导致了改进的响应。

二、工具使用Tool Use

大型语言模型如何通过利用外部工具进行搜索、代码执行、生产力、无穷无尽地充当代理。

工具使用，其中 LLM 被赋予它可以请求调用的功能来收集信息、采取行动或操作数据，是 AI 代理工作流的一个关键设计模式。您可能熟悉可以执行 Web 搜索或执行代码的基于 LLM 的系统。事实上，一些面向消费者的大型 LLM 已经包含了这些功能。但工具使用远远超出了这些例子。

如果你提示一个基于LLM的在线聊天系统，“根据审稿人的说法，什么是最好的咖啡机？”，它可能会决定进行网络搜索并下载一个或多个网页以获取上下文。在早期，LLM 开发人员意识到仅依靠预先训练的转换器来生成输出令牌是有局限性的，并且为 LLM 提供 Web 搜索工具可以让它做更多的事情。使用这样的工具，LLM 要么被微调，要么被提示（也许有少量提示）生成一个特殊的字符串，如 {tool：web-search， query：“coffee maker reviews”} 以请求调用搜索引擎。（字符串的确切格式取决于实现。然后，后处理步骤会查找这样的字符串，在找到相关参数时调用具有相关参数的 Web 搜索函数，并将结果作为额外的输入上下文传递回 LLM 以进行进一步处理。

同样，如果你问，“如果我以 12% 的复利投资 100 美元，最后我能得到什么？”，而不是尝试直接使用 transformer 网络生成答案——这不太可能产生正确的答案——LLM 可能会使用代码执行工具运行 Python 命令来计算 100 * （1+0.07）**12 以获得正确答案。LLM 可能会生成如下字符串：{tool：python-interpreter， code：“100 * （1+0.07）**12”}。

但是，代理工作流中的工具使用现在走得更远。开发人员正在使用功能来搜索不同的来源（Web、Wikipedia、arXiv 等）、与生产力工具交互（发送电子邮件、读/写日历条目等）、生成或解释图像等等。我们可以使用上下文来提示 LLM，该上下文提供了许多函数的详细说明。这些描述可能包括函数所执行操作的文本说明，以及函数所需的参数的详细信息。我们希望 LLM 能够自动选择正确的函数来调用来完成工作。此外，正在构建LLM可以访问数百种工具的系统。在此类设置中，可能有太多函数可供使用，无法将所有函数都放入 LLM 上下文中，因此您可以使用启发式方法在当前处理步骤中选择要包含在 LLM 上下文中的最相关子集。下面引用的Gorilla论文中描述了这种技术，它让人想起，如果有太多的文本无法作为上下文包含，检索增强生成（RAG）系统如何提供启发式方法，以选择要包含的文本子集。

在 LLM 历史的早期，在 LLaVa、GPT-4V 和 Gemini 等大型多模态模型（LMM）广泛使用之前，LLM 无法直接处理图像，因此计算机视觉社区在工具使用方面进行了大量工作。当时，基于 LLM 的系统处理图像的唯一方法是调用一个函数来执行对象识别或其他函数。从那时起，工具使用的实践呈爆炸式增长。GPT-4 的函数调用功能于去年年中发布，是迈向通用实现的重要一步。从那时起，越来越多的 LLM 正在被开发为与工具使用类似的简单方法。

三、规划****Planning

大型语言模型可以驱动强大的代理执行复杂的任务，前提是您要求他们在行动之前规划步骤。

规划是一种关键的代理 AI 设计模式，在这种模式中，我们使用大型语言模型（LLM）来自主决定执行哪些步骤来完成更大的任务。例如，如果我们要求代理对给定主题进行在线研究，我们可能会使用 LLM 将目标分解为更小的子任务，例如研究特定的子主题、综合发现和编写报告。

许多人在 ChatGPT 发布后不久就经历了“ChatGPT 时刻”，当他们玩它时，惊讶地发现它大大超出了他们对 AI 能做什么的预期。如果你还没有经历过类似的“AI Agentic 时刻”，我希望你很快就会。几个月前，我有一个，当时我展示了一个我实施的研究代理的现场演示，该代理可以访问各种在线搜索工具。

我私下测试了这个代理多次，在此期间，它一直使用网络搜索工具来收集信息并撰写摘要。但是，在现场演示期间，Web 搜索 API 意外返回并显示速率限制错误。我以为我的演示即将公开失败，我害怕接下来会发生什么。令我惊讶的是，特工巧妙地转向了维基百科的搜索工具——我忘记了我给了它——并使用维基百科而不是网络搜索完成了任务。

这对我来说是一个惊喜的 AI 代理时刻。我想很多还没有经历过这种时刻的人会在接下来的几个月里这样做。当你看到一个代理人自主地决定以你没有预料到的方式做事，并因此成功时，这是一件美好的事情！

许多任务无法通过单个步骤或单个工具调用完成，但代理可以决定要执行哪些步骤。例如，为了简化 HuggingGPT 论文（如下所述）中的一个示例，如果您希望智能体考虑一张男孩的照片并画一张相同姿势的女孩的照片，则该任务可以分解为两个不同的步骤：（i）检测男孩图片中的姿势和（ii）以检测到的姿势渲染女孩的图片。LLM 可能会被微调或提示（使用少量提示）通过输出类似“{tool：pose-detection， input：image.jpg， output：temp1 } {tool：pose-to-image， input：temp1， output：final.jpg}”这样的字符串来指定计划。

此结构化输出指定要执行的两个步骤，然后触发软件调用姿势检测工具，然后调用姿势到图像工具以完成任务。（此示例仅供说明之用;HuggingGPT 使用不同的格式。

诚然，许多代理工作流不需要规划。例如，您可以让代理以固定次数反映并改进其输出。在这种情况下，代理采取的步骤顺序是固定的和确定的。但是，对于无法提前指定将任务分解为一组步骤的复杂任务，规划允许代理动态决定要执行的步骤。

一方面，计划是一种非常强大的能力;另一方面，它会导致难以预测的结果。根据我的经验，虽然我可以让 Reflection 和 Tool Use 的代理设计模式可靠地工作并提高我的应用程序的性能，但 Planning 是一项不太成熟的技术，我发现很难提前预测它会做什么。但该领域继续快速发展，我相信规划能力会迅速提高。

四、多代理协同Multi-agent collaboration

促使 LLM 在复杂任务的不同部分扮演不同的角色会召唤一个可以更有效地完成工作的 AI 代理团队

多智能体协作是我在最近的信件中描述的四种关键 AI 智能体设计模式中的最后一种。对于像编写软件这样的复杂任务，多智能体方法会将任务分解为由不同角色（如软件工程师、产品经理、设计师、QA（质量保证）工程师等）执行的子任务，并让不同的智能体完成不同的子任务。

通过提示一个 LLM（或者，如果您愿意，也可以提示多个 LLM）执行不同的任务，可以构建不同的代理。例如，要构建一个软件工程师代理，我们可能会提示 LLM：“你是编写清晰、高效代码的专家。编写代码来执行任务......”

尽管我们对同一个 LLM 进行了多次调用，但我们应用了使用多个代理的编程抽象，这似乎有悖常理。我想提供几个原因：

它有效！许多团队都用这种方法取得了不错的成绩，没有什么能比得上结果了！此外，消融研究（例如，在下面引用的 AutoGen 论文中）表明，多种药物比单一药物具有更好的性能。
尽管今天的一些 LLM 可以接受非常长的输入上下文（例如，Gemini 1.5 Pro 接受 100 万个令牌），但它们真正理解长而复杂的输入的能力参差不齐。在代理工作流中，提示 LLM 一次专注于一件事可以提供更好的性能。通过告诉它什么时候应该扮演软件工程师，我们还可以指定该角色的子任务中什么是重要的。例如，上面的提示强调清晰、高效的代码，而不是可扩展和高度安全的代码。通过将整体任务分解为子任务，我们可以更好地优化子任务。
也许最重要的是，多智能体设计模式为我们提供了一个框架，作为开发人员，可以将复杂任务分解为子任务。在编写代码以在单个 CPU 上运行时，我们经常将程序分解为不同的进程或线程。这是一个有用的抽象，它允许我们将任务（如实现 Web 浏览器）分解为更易于编码的子任务。我发现通过多智能体角色进行思考也是一个有用的抽象概念。

在许多公司中，经理们通常会决定雇用哪些角色，然后如何将复杂的项目（例如编写大型软件或准备研究报告）拆分为较小的任务，以分配给具有不同专业的员工。使用多个代理是类似的。每个智能体都实现自己的工作流程，有自己的内存（本身就是智能体技术中一个快速发展的领域：智能体如何能够记住足够多的过去交互，以便在即将到来的交互中表现得更好？），并且可能会向其他智能体寻求帮助。代理还可以参与规划和工具使用。这会导致 LLM 调用和代理之间的消息传递杂乱无章，从而导致非常复杂的工作流。

虽然管理人很困难，但这是一个非常熟悉的想法，它为我们提供了一个如何“雇用”和分配任务给我们的人工智能代理的心理框架。幸运的是，人工智能代理管理不善造成的损害远低于人类管理不善造成的损失！

AutoGen、Crew AI 和 LangGraph 等新兴框架提供了丰富的方法来构建问题的多智能体解决方案。如果你有兴趣玩一个有趣的多代理系统，还可以看看ChatDev，这是一个运行虚拟软件公司的一组代理的开源实现。我鼓励您查看他们的 GitHub 存储库，也许可以克隆存储库并自己运行系统。虽然它可能并不总是产生你想要的东西，但你可能会惊讶于它的表现。

就像 Planning 的设计模式一样，我发现多智能体协作的输出质量很难预测，尤其是在允许智能体自由交互并为他们提供多种工具时。更成熟的反思和工具使用模式更可靠。我希望你喜欢玩这些代理设计模式，并希望它们能为你带来惊人的结果！

附录：原文链接

www.deeplearning.ai/the-batch/h…

www.deeplearning.ai/the-batch/a…

公众号:Fintech搬砖录

在Fintech的世界里搬砖

100篇原创内容