如何构建高效的AI智能体

智能体”（Agent）的定义有多种。有些客户将其定义为可以长时间独立运行、使用各种工具来完成复杂任务的完全自主系统；另一些则将其描述为遵循预先定义工作流、较具指导性的实现方式。Anthropic将这些不同形式都归类为智能体系统(agenticsystems)，但在架构上，我们强调区分工作流(workflows)与智能体(agents)工作流指的是通过预定义的代码路径对大语言模型和工具进行编排的系统

小天才学习机打游戏

1169人浏览 · 2025-01-17 19:59:16

小天才学习机打游戏 · 2025-01-17 19:59:16 发布

如何构建高效的智能体

Anthropic 刚刚发布了一份关于“如何构建高效智能体”的精彩指南。

在过去的一年里，我们与来自各行各业、致力于构建大语言模型 (LLM) AI 智能体的数十个团队合作。我们发现，最成功的应用往往并未使用复杂的框架或专业库，而是采用了一些简单且可组合的模式来构建系统。

在本文中，我们将分享与客户合作并亲自构建 AI 智能体时所获得的经验，并为开发者提供构建高效 AI 智能体的实用建议。

什么是智能体？

“智能体”（Agent）的定义有多种。有些客户将其定义为可以长时间独立运行、使用各种工具来完成复杂任务的完全自主系统；另一些则将其描述为遵循预先定义工作流、较具指导性的实现方式。Anthropic 将这些不同形式都归类为智能体系统 (agentic systems)，但在架构上，我们强调区分工作流 (workflows)与智能体 (agents)：

工作流指的是通过预定义的代码路径对大语言模型和工具进行编排的系统。
智能体则是通过大语言模型来自主决定工作流程和使用工具的方式，并掌控完成任务的路径。

接下来，我们会详细介绍这两种智能体系统。在附录 1（“智能体的实际案例”）中，我们还会展示客户在特定领域中如何利用这些系统获得显著价值。

使用智能体的场景

当构建基于大语言模型的应用时，我们建议先从最简单的解决方案开始，只有在确有需要时，才增加复杂性。这可能意味着完全不使用智能体系统。因为智能体系统通常需要在延迟和成本之间进行权衡，以换取更好的任务性能，必须评估这是否是可以接受的取舍。

如果有必要增加复杂性，那么工作流在可预见、可定义的任务中提供了更强的可预测性和一致性，而当需要在大规模环境中进行更灵活的模型驱动决策时，智能体则更为适用。但对许多应用而言，仅使用带检索和上下文示例的单次大语言模型调用，通常已经足够。

何时以及如何使用框架

目前市面上有许多框架可以简化智能体系统的实现，例如：

LangChain 的 LangGraph；
Amazon Bedrock 的 AI Agent 框架；
Rivet，一款可视化拖拽式的大语言模型工作流搭建工具；
以及 Vellum，另一款搭建并测试复杂工作流的可视化工具。

这些框架让构建变得更简单，能够快速完成对大语言模型的调用、定义和解析工具以及链式调用等标准化底层任务。但是，它们常常额外引入抽象层，可能会遮蔽底层的提示词和响应，从而使调试难度加大。它们也可能诱使开发者增加不必要的复杂性，而实际上更简单的方案就足以应对需求。

因此，我们建议开发者从直接调用大语言模型 API 入手：许多常见模式都能通过几行代码实现。如果确实要使用某个框架，一定要理解其底层原理。对底层机制的误解是用户在使用中经常遇到的问题。

若要获取更多示例，请参阅我们的示例代码库 (cookbook)。

基础构件、工作流与智能体

在本节中，我们将探讨在实际生产环境中常见的智能体系统模式。从最基础的构件——增强型大语言模型 (LLM)——开始，逐步增加复杂度，从简单的组合式工作流一路拓展到自主智能体。

基础构件：增强型大语言模型

智能体系统的基础构件是经过增强的大语言模型 (LLM)，为其配备检索、工具和记忆等功能。我们当前的模型可以主动使用这些能力——自行生成搜索查询、选择合适的工具并确定要保留的信息。

the augmented LLM

在实际应用中，建议把握两个关键点：首先，要将这些功能与特定用例相结合；其次，要提供一个易用且文档完善的接口给大语言模型使用。实现这些增强功能的方法不止一种，我们近期发布的 Model Context Protocol 就是其中一种方案，通过一个简单的客户端实现，开发者即可对接不断壮大的第三方工具生态系统。

在本文剩余部分，我们默认每次调用大语言模型时，都能使用这些增强功能。

工作流：链式提示词

链式提示词将一个任务分解为一系列步骤，每次大语言模型调用会处理上一步的输出。可以在任何中间步骤加入编程层面的检查（在下图中称为“gate”），以确保流程依然走在正确轨道上。

the prompt chaining workflow

适用场景： 这种工作流非常适合能够被轻松拆解为固定子任务的情形。其主要目标是用多次调用大语言模型来换取更高的准确度，每次调用只需处理相对简单的任务，从而在延迟和准确度之间寻求平衡。

示例：

先生成营销文案，再将其翻译成另一种语言；
先写出一篇文档的大纲，检查该大纲是否满足特定标准，然后再根据该大纲撰写正文。

工作流：路由式

通过对输入进行分类，将其引导至对应的后续任务。此工作流能够实现关注点分离，并为不同类别分别构建更具针对性的提示词。若不进行路由，为某类输入做的优化可能会影响对其他输入的处理效果。

the routing workflow

适用场景： 路由适用于复杂任务，这些任务可分为不同类别，并且每个类别都能更准确地分别处理。对于分类本身，可以使用大语言模型或传统的分类模型/算法。

示例：

针对不同类型的客服请求（如一般性问题、退款请求、技术支持）分别使用不同的处理流程、提示词和工具；
将简单/常见的问题路由到较小的模型（例如 Claude 3.5 Haiku），而将困难/非常规的问题路由到更强大的模型（如 Claude 3.5 Sonnet），以兼顾成本与速度。

工作流：并行式

在某些场景下，大语言模型可以同时处理一个任务，并通过程序方式整合它们的输出。并行式工作流主要分为两种形式：

分块（Sectioning）：将一个任务拆分为若干互不影响的子任务，并行完成；
投票（Voting）：多次运行同一个任务，从而获取多样化的输出。

the parallelization workflow

适用场景： 当子任务可以并行执行以加快速度，或需要多种观点或多次尝试来获得高置信度的结果时，并行化会非常有效。对于带有多重考量的复杂任务，大语言模型通常在分别处理每个考量点时表现更好，因为这让每次调用专注于特定方面。

示例：

分块（Sectioning）：
实现防护机制，一台模型实例负责处理用户查询，另一台则负责审查是否存在不当内容或请求。这通常比让同一个调用同时处理防护及核心响应更有效；
自动进行评测 (eval) 用来评估大语言模型性能，每一次模型调用分别负责评估在给定提示词上模型表现的不同方面。
投票（Voting）：
在审查代码是否存在漏洞时，使用多个不同的提示词多次检查代码，一旦发现问题就会标记；
判断某段内容是否不当时，让多个提示词分别评估不同方面或使用不同的投票阈值，平衡误判和漏判的风险。

工作流：协调者-执行者 (Orchestrator-workers)

在协调者-工作者工作流中，由一个中心的大语言模型动态地拆解任务，将子任务分配给各个执行者模型，并整合它们的结果。

the orchestrator-workers workflow

适用场景： 此工作流非常适合那些无法预先预测需要哪些子任务的复杂场景。例如，在写代码时需要修改多少文件、每个文件需要做哪些改动，都取决于具体的任务。虽然此模式在结构上看似与并行化相似，但其关键区别在于灵活性——子任务不是预先定义的，而是由协调者根据实际输入动态生成。

示例：

面向编程产品的功能，每次都可能对多个文件进行复杂修改；
涉及搜索与分析多个来源信息并筛选可用信息的搜索类任务。

工作流：评估者-优化者 (Evaluator-optimizer)

在评估者-优化者工作流中，一个大语言模型先生成初步输出，另一个大语言模型对该输出进行循环式评估和反馈。

the evaluator-optimizer workflow

适用场景： 如果我们有明确的评估标准，并且多次迭代确能带来可量化的提升，这种工作流特别有效。适合此方式的两个标志是：其一，在有人提供明确反馈时，大语言模型的输出可显著提升；其二，大语言模型本身也能生成有价值的反馈。这与人类作者多次修改文稿，逐渐完善的过程类似。

示例：

文学翻译：首次翻译可能忽略了一些细微之处，而评估者模型可给出有益的批评与建议；
复杂的搜索任务，需要多轮搜索和分析来收集完整信息，此时评估者可决定是否继续执行更多搜索。

智能体 (Agents)

随着大语言模型在理解复杂输入、推理和规划、可靠使用工具以及从错误中恢复等能力上的成熟，智能体在生产环境中开始崭露头角。智能体通常从用户的指令或互动对话开始工作，一旦任务明确，就会自主规划与执行任务，必要时向用户寻求更多信息或判断。在任务执行过程中，智能体需要获取每一步的“真实信息”（例如工具调用的结果或代码执行的结果）来判断进度。智能体也可以在遇到阻碍或需要人工确认时暂停，等待用户反馈。任务完成时通常结束整个流程，但也可以设置停止条件（如限制迭代次数）来控制风险。

智能体能够应对复杂任务，但其实现往往并不复杂——通常只是在循环中根据环境反馈不断调用大语言模型并使用工具。因此，如何精心设计和记录各类工具显得至关重要。在附录 2（“为工具进行提示词工程”）中，我们会进一步探讨工具开发的最佳实践。

Autonomous agent

何时使用智能体： 当问题本身是开放式的，或无法提前确定需要多少步骤、何种具体路径时，就可以考虑使用智能体。大语言模型在此过程中可能会进行多次迭代，所以你需要对其决策能力有一定信任度。在受信任的环境中，智能体非常适合扩展任务规模。

同时，智能体的自主性意味着更高的成本，也存在错误逐步放大的可能。我们建议在沙盒环境中进行大量测试，并配合适当的防护措施。

示例：
以下是我们在内部实现中的示例：

用于解决 SWE-bench 任务的代码智能体：基于任务描述对多个文件进行编辑；
“计算机使用”演示：Claude 通过使用计算机来完成指定任务。

High-level flow of coding agent

组合与自定义这些模式

这些构建块并非绝对标准，只是为开发者提供常见的参考模式，以适配不同的用例。与所有大语言模型功能一样，衡量性能并不断迭代非常关键。再次强调：只有当增加复杂度能够“确实”带来效果提升时才这么做。

总结

在大语言模型领域，成功并不意味着构建出最复杂的系统，而是要搭建出最“恰当”的系统。先从简单的提示词入手，用充分的评测优化提示词，仅当简单方案无法满足需求时，再考虑多步骤的智能体系统。

在构建智能体时，我们倾向于遵循以下三大核心原则：

1. 保持设计上的简洁性；

2. 强调透明度，在显式的规划步骤中展现智能体的思考过程；

3. 谨慎打造智能体-计算机接口 (ACI)，在工具的文档与测试上下足功夫。

框架确实能帮助开发者快速开始，但在部署到生产环境时，也不要忽视将抽象层降到最低、直接使用基础组件的方法。遵循这些原则，可以构建既高效又可靠、维护成本更低、并且广受用户信赖的智能体。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述