掌握 Ai 代理：2025 年设计、构建和优化综合指南

如果你关注科技新闻，你可能会听到“2025年将是人工智能代理的年”或“人工智能代理将改变我们的工作和生活”等预测。你可能会想知道人工智能代理是什么，以及它们为何突然变得如此重要。

虽然确实存在一定程度的炒作，但理解人工智能代理是如何工作的，对于任何想要构建或使用它们的人来说都是重要的。它们是我们使用大型语言模型（LLMs）或多模态视觉语言模型（VLMs）方式的根本转变，并为自动化和人机交互开辟了新的可能性。

在本综合指南中，我们将探讨和讨论人工智能代理是什么，何时使用它们，它们的核心组件，如何评估和改进人工智能代理，框架，最佳实践，构建人工智能代理的提示，以及与人工智能代理设计产品用户体验。无论你是探索人工智能代理用例的产品经理，评估人工智能代理产品机会的企业家，还是构建人工智能代理系统的开发者，本综合指南将提供你理解和导航人工智能代理世界所需的概念背景和技术见解。

目录

• 人工智能代理是什么？
• 我们何时应该使用人工智能代理？
• 人工智能代理的组件是什么？
• 人工智能代理是如何工作的？
• 人工智能代理如何制定更好的计划？
• 为人工智能代理配备工具和知识
• 在多代理系统中，代理如何协同工作？
• 我应该使用哪个框架来构建人工智能代理？（编程与无代码）
• 构建强大高效的人工智能代理的提示与最佳实践
• 如何在产品中设计人工智能代理体验？
• 总结
• 参考文献和资源

（如果你没有人工智能或编码经验，不用担心，我会尝试用非技术性术语来解释，你可以随意跳过关于实现的更技术性部分。）

什么是人工智能代理？

鉴于这个术语当前的热度，你可能会听到人们在不同的对话中提到“人工智能代理”，他们对人工智能代理的定义可能各不相同。这个概念在计算机科学中已经存在很长时间 [1]，但最近的流行是基于大型语言模型（如GPT、Claude、Llama等）的自主系统。

尽管有许多定义，但你仍然可以找到一些重复的模式——在给定一个目标的情况下，人工智能代理可以通过访问外部信息或自主使用工具来规划并尝试实现该目标 [2][3][4][5]。为了帮助你理解人工智能代理，可以简单地认为人工智能代理用一个能够访问信息和工具的大型语言模型替代了传统的编程控制流程。

人工智能代理可以使用工具和外部资源自主实现目标。由作者制作，图标来自 flaticon.com

当然，这种表述的确切措辞可能有所不同，但基本上围绕以下几个方面：

1. 代理性或自主性：顾名思义，代理具有代理性，这意味着它们可以独立行动以实现目标。代理性可以有许多不同的级别，从简单地根据用户的意图路由控制流程到执行函数，再到多步骤流程，最终到复杂的多代理合作 [2]。在设计人工智能代理产品时，我们可以根据产品的复杂性定义具有不同代理级别的人工智能代理。

2. 访问外部信息/工具：与孤立的LLM或VLM不同，代理可以与外部环境互动，以访问信息或使用工具来帮助它们实现目标 [5]。这使得它们能够基于超出其预训练数据的更更新的相关数据做出明智的决策。它们可以使用API或函数访问互联网、修改数据库，甚至在物理世界中执行操作。

3. 推理、规划和执行以实现目标：另一个核心方面，或许是决定性方面，是在给定一个目标时，人工智能代理可以推理出采取哪些行动，规划步骤列表，然后自主执行这些步骤（甚至在过程中学习和适应） [5]。这使得人工智能代理与之前的预定义工作流程不同，以适应广泛的案例，甚至是代理产品设计师可能没有考虑到的案例。

这些关键方面或能力构成了我们现在所称的“人工智能代理”，我们可以围绕这些关键能力设计我们的产品或体验。

何时我们应该使用人工智能代理？

人工智能代理听起来非常强大，对吗？它们可以独立完成复杂任务。但我们应该让它在我们的产品中做所有事情，以取代现有的编程功能和工作流程吗？答案可能是否定的。您需要考虑任务的复杂性和可用的替代方案。最好是选择最简单的解决方案，仅在必要时增加复杂性。 这可能意味着根本不使用人工智能代理系统。

对于简单、定义明确的任务和流程，传统的程序化流程可能比人工智能代理更高效、更可靠，因为它们是可解释的，并且您不需要等待令牌生成。对于需要大型语言模型能力的任务，如转换非结构化数据（例如摘要、数据提取等）并且需要一定灵活性但不需要复杂推理的任务，简单的基于大型语言模型的工作流程，如提示链、意图路由、并行运行独立任务或投票，可能就足够了[4]。当任务变得复杂、开放并且需要动态决策时，人工智能代理成为更好的选择[2][4]。

以下是一个简单的流程图，帮助您确定是否真的需要在产品中实施人工智能代理：

决定是否需要人工智能代理的简单流程图。作者制作。

使用人工智能代理的优点包括：

• 处理复杂任务：它们可以处理开放性问题（可能有多种解决方案），并在过程中做出动态决策[2][4]。
• 灵活性（与程序化相比）：它们可以适应覆盖您在设计时可能未考虑的边缘情况。如果某些信息缺失，它们可以尝试自行收集信息[4][5][7][8]。
• 资源减少（与人类相比）：它们可以自动化一些以前仅由人类劳动完成的任务，从而减少您的产品/服务的资源和成本[3][9]。
• 与现实世界的交互：它们可以通过工具使用与现实世界互动，从而执行超出文本生成的任务，如原始大型语言模型[5][8]。

您也不应忽视一些潜在风险：

• 复杂性：在实施人工智能代理时，您可能会增加很多额外开销，如向量数据库、异步API调用、缓存、错误处理等。这些可能会使一个可以不使用代理解决的简单问题变得过于复杂。
• 延迟：由于基于大型语言模型的人工智能代理需要生成文本令牌进行推理，并且可能涉及许多迭代步骤，您的用户可能需要等待很长时间才能获得最终结果。
• 成本：与前一点相关，额外生成的用于推理的令牌可能会迅速累加，并提高您的大型语言模型API成本，特别是如果您使用的是昂贵的推理大型语言模型作为基础大脑。（如果您想查看示例，请搜索Cline，一个AI编码代理，如何消耗令牌）
• 潜在错误：这是灵活性的双刃剑。虽然人工智能代理可以处理更多情况，但它们在某些步骤中可能容易出错，甚至在复杂的多步骤任务中出现复合错误[4][6][7]。
• 缺乏可解释性 & 难以调试：当出现错误时，由于其灵活和动态的特性以及抽象，调试可能非常困难[4]。（有时罪魁祸首可能只是提示中的一个看似不重要的令牌。）

在构建您的产品时，请记得问自己——“使用人工智能代理系统是必要的吗？”如果有更简单的替代方案，通常选择那些更好；如果确实需要人工智能代理，那么继续阅读以了解它们的工作原理及如何实施。

人工智能代理的组成部分是什么？

你可以将代理视为一个拥有大脑、工具和记忆的智能数字工作者 [10]。这些组件协同工作，使代理能够规划、执行动作、根据观察进行适应并完成任务。

这一波代理的“大脑”是大型语言模型或多模态视觉语言模型。这些大型语言模型能够理解自然语言指令、处理信息、在给定目标的情况下起草潜在计划、评估计划，并生成基于文本的响应或结构化的函数调用以使用工具。核心是经过精心设计的提示的LLM API调用，其中包含有关目标、工具、记忆和行动指南的所有信息。重要的是要注意，这并不一定是一个单一的LLM模型，你可以为不同的步骤选择不同的LLM。例如，你可能会使用像GPT-o1这样更强大的模型来利用其推理能力将目标分解为行动计划，然后切换到更小或经过微调的模型，这些模型在代码生成或摘要等任务上更高效或专业 [4]。 （从概念上讲，这也可以被视为多个代理，其中有一个规划代理和一些工作代理。）

代理的“手”是我们提供给他们的外部工具。这些工具可以是从简单的函数（如计算器）到复杂的API，允许他们访问数据库、发送电子邮件，甚至完成代码沙盒，在那里他们可以编写和运行自己的程序或启动其他子代理。你甚至可以提供实际的物理机器人手，以便他们可以移动物体 [11]。我们在LLM提示中提供工具定义，LLM可以选择他们希望使用的工具及其选择的参数。例如，如果你提供一个搜索工具 get_weather(city)，当用户询问匹兹堡是否会下雨时，LLM可以决定用 get_weather("Pittsburgh") 来调用它。

人工智能代理还需要记忆来保持学习和适应的上下文。记忆使这些代理能够回忆与用户的过去交互，存储有关目标/工具使用的信息，并利用这些知识调整他们在计划中的未来步骤 [10]。记忆可以是短期记忆，跟踪当前会话中的消息和交互（可能只是一个消息文本字符串的列表）。它们也可以是跨不同会话或不同代理之间保留的长期记忆，这些通常存储在向量数据库或其他数据库中，具体取决于信息的类型。

最后一个组件是将大脑、工具和记忆连接在一起的胶水代码。你需要定义工具，解析LLM操作，并将信息服务到LLM的提示中，使用代理框架，或者你可以编写自己的代码来完成这些。我们稍后将深入探讨框架以及如何将这些组件链接在一起以构建你的代理。

人工智能代理是如何工作的？

现在让我们揭开人工智能代理工作原理的神秘面纱。从高层次来看，人工智能代理的工作方式与我们在接到任务时的做法类似，我们思考、行动，并从发生的事情中学习——然后我们重复这一过程，直到任务完成。

您可能会看到一些概念框架，将其分解为规划者、评估者和执行者的角色 [12]。规划者负责弄清楚如何利用可用的工具和信息实现给定目标。它会制定一个逐步的计划。评估者通过推理来验证计划，判断计划是否合理以及执行者是否正确执行了行动。执行者按照计划进行函数/工具调用，与环境互动并执行行动。

人工智能代理在一个持续的推理-行动循环中工作。作者使用来自 flaticon.com 的图标制作。

但为了进一步简化，这个过程的核心是一个持续的ReAct，推理-行动循环 [13]。大型语言模型根据上下文和消息历史推理当前情况，进行函数调用，粘合代码解析函数调用，执行函数，并将结果放入上下文中，然后大型语言模型可以观察结果并基于新信息再次推理以更新计划。这个循环会持续进行，直到实现目标或满足停止条件（例如，步骤过多/时间过长）。

当然，这只是对人工智能代理工作原理的简化版本，在接下来的部分中，我们将深入探讨更技术化的方面——代理和多代理系统的架构、改善代理推理的技术、如何为代理提供外部信息和工具等。

人工智能代理如何制定更好的计划？

当你在工作中接到一个复杂项目时，第一步是什么？第一步是制定计划，对吧？就像当你推出一个新功能时，产品需求就像计划——你不会直接开始编写代码。如果没有适当的规划，代理就会像初级产品经理一样，试图在没有用户研究或定义成功指标的情况下推出产品。规划将帮助代理：

1. 保持专注于他们的目标
2. 在执行步骤中更高效
3. 在步骤出现错误时恢复
4. 在多代理环境中协作与合作 [12][14]。

就像产品经理或产品设计师有我们的思维框架一样，代理也有不同的方法和途径来分解任务。在设计人工智能代理时，你可以选择最适合任务的方法。你可以通过在提示中明确指示大型语言模型来实施这些规划方法，或者通过动态路由的提示为特定步骤进行实施。

第一种方法是任务分解，就像创建详细的待办事项列表。代理将主要任务分解为更小、更易管理的子任务。他们可以进行分解优先的规划，在开始任何子任务之前创建完整的子任务列表。或者他们可以进行交错分解，在分解任务和规划下一个子任务之间交替进行 [14]。

另一种常见的方法是多计划选择，代理生成多个计划并选择最佳方案。就像在产品探索阶段，我们通常会集思广益潜在解决方案，然后决定最佳想法进行汇聚。你可以将大型语言模型的温度调整为更高的值（控制随机性），以便生成更多样化的计划。然后你可以使用一些策略，如多数投票（自我一致性）、树搜索算法（思维树）、蒙特卡洛树搜索等 [15][16]。

你还可以通过一些外部规划者帮助你的代理制定更好的计划，就像你的公司为年度规划雇佣外部顾问一样。有符号规划者使用正式规则来制定计划。它们精确且可解释，但计算上可能比较密集。还有神经规划者，它们在过去的规划任务上进行训练以生成计划。

除了外部规划者，你还可以为代理提供外部信息以进行记忆增强规划。如果你的问题空间更可预测，主题专家可能会为你的代理编写一些通用计划，你可以将这些计划插入代理提示中。你甚至可以让代理写下他们过去成功任务的计划，以便他们在未来从中学习。这可以通过RAG（检索增强生成）系统来实现，我们将在下一部分讨论。

代理还可以反思他们的计划并进行改进。他们可以反思自己的行动，识别潜在的错误/改进，并迭代地完善他们的计划 [17][18]。你还可以定义不同的提示，让大型语言模型从不同的角度思考，或者让专业代理共同合作以改进计划 [7]。就像科技公司的产品团队或小组一样，你可以让产品代理、设计代理、编码代理和财务代理讨论、辩论并最终确定计划。

这些方法并不是相互排斥的，你可以将不同的方法结合在一起，为你的代理制定更好的计划。确保在计划质量和延迟/令牌数量之间取得平衡。

为人工智能代理配备工具和知识

在制定计划后，代理需要在外部知识和工具的帮助下开始执行计划。人工智能代理获取外部知识的主要方式是通过一个叫做RAG（检索增强生成）的过程，并且它们可以通过函数调用使用外部工具。在这一部分，我们将深入探讨如何为人工智能代理配备外部工具和知识。

检索增强生成，顾名思义，是指系统为代理检索相关信息 以生成决策。RAG可以帮助代理：

• 获取最新信息：大型语言模型只知道它们训练数据中的信息，因此它们不知道训练后发生的任何事情。因此，为了让代理根据新信息（如新API/新产品/新研究）采取行动，我们需要为其提供这些信息。
• 提高准确性和相关性：人工智能代理可以通过RAG获得更准确的结果。在前一部分中，我们讨论了如何为代理提供过去成功的计划，以便制定更好的计划。
• 减少幻觉：就像人类一样，我们可以通过用证据来支撑代理的响应，减少代理产生幻觉（虚假信息）的机会（可以将其视为写论文时的引用）。提供证据可以最小化它们编造内容的可能性[19]。
• 改善上下文理解：通过为代理提供相关上下文，它可以更好地理解任务。特别是在多代理协作中，共享的上下文可以帮助它们更好地协作以实现目标。

RAG检索相关文档块并将其插入大型语言模型的提示中。由作者制作，图标来自 flaticon.com

RAG的基本概念很简单：当代理需要一些信息时，您找到最相关的信息并将其放入大型语言模型调用的提示中。这可以通过向量数据库、搜索API或其他数据库来实现。向量数据库在RAG实现中被广泛使用，因为它们可以搜索非结构化数据，如文本或图像，同时保持其语义意义。它的工作原理是将参考数据分块，将其转换为向量嵌入，然后比较查询的嵌入以找到最相似的嵌入和块。您还可以依赖现有搜索引擎（如Google）的搜索API和网页解析器，将在线信息提供给代理。还可以通过其他数据库（如图数据库或传统SQL数据库）获取相关上下文。您还可以给代理提供像SQL执行这样的工具，让代理编写自己的SQL查询以获取所需的数据（不过要非常注意权限和安全）。

RAG本身是一个积极研究的子领域，进行RAG的“最佳”方法也在不断演变。以下是一些常用的方法来改善RAG结果，以帮助您入门[19][20]，但请随意查看参考文献和新研究的详细信息：

• 分块：不同的参考文档分解方式会影响结果的相关性。例如，您可以按上下文大小（令牌计数）、语义意义、段落等方式分解文档。您需要考虑哪种分块技术提供最相关的信息，而不至于用不相关的信息过载上下文。
• 查询扩展：您可以基于原始查询生成额外的查询，而不是直接比较原始查询，以捕获更广泛的相关文档，使用同义词或相关术语来提高召回率。
• 查询转换：您还可以让代理重新表述原始查询以提高清晰度，更好地与参考文档对齐，从而提高准确性。例如，HyDE（假设文档嵌入）生成一个假设答案，然后用于嵌入搜索，而不是原始查询[21]。
• 混合检索：您可以结合不同的检索方法，如全文搜索、图搜索和向量搜索，以适应不同类型的查询并捕获相关文档。
• 重新排序：在初始检索后，您可以重新排序文档，以优先考虑最相关/有用的数据，以插入代理的提示上下文。

虽然RAG允许代理访问信息，函数调用和API使它们能够根据这些信息与外部世界进行交互[2][4][5]。 对于大型语言模型代理的函数调用，核心是让大型语言模型生成一个结构化输出，包括函数名称和参数，通常为JSON格式，可以被我们的代码解析以调用该特定函数。

例如，您可以在提示中向大型语言模型提供工具定义，如下所示：

{
      "type": "function",
      "function": {
          "name": "get_flights",
          "parameters": {
              "type": "object",
              "properties": {
                  "from_location": {"type": "string"},
                  "to_location": {"type": "string"},
                  "date": {"type": "string", "format": "date"}
              },
              "required": ["from_location", "to_location", "date"]
          }
      }
}

当您要求大型语言模型查找从北京到旧金山的航班时，大型语言模型可以生成一个函数调用，如下所示：

{
  "function": {
    "name": "get_flights",
    "arguments": "{'from_location': 'Beijing', 'to_location': 'San Francisco', 'date': '2025-01-13'}"
  }
}

像这样的结构化输出可以很容易地用代码解析，然后您可以用您的代码调用该函数，并在下一个提示中向大型语言模型提供执行的结果。（当然，您需要用您的代码进行验证和确认，以确保代理不会调用随机函数或进行潜在有害的操作，如rm -rf .到您的系统。）这些函数可以简单到像计算器函数，也可以是抽象的复杂API调用，在远程编程环境中执行脚本[5]。代理将根据用户查询和提供给它的工具列表决定是否以及何时使用外部工具[12]。这种外部工具使用能力将大型语言模型从被动的信息提供者转变为积极的助手。

最近，Anthropic提出了一种新的统一协议，供大型语言模型代理管理其上下文并与外部世界交互，称为Claude MCP（模型上下文协议）[22]。这是一个旨在简化和统一人工智能代理助手如何连接到外部数据源的尝试，通过解决数据集成的碎片化问题。与其为每个数据源构建定制集成（这可能耗时且难以扩展），不如MCP提供一种通用的开放标准来实现这种连接。开发人员可以构建一个跨多个数据源和工具工作的单一集成。这在构建您的人工智能代理时可以是一个很好的资源，但请注意，许多其他公司也在推动类似的标准，这可能导致一个不统一的标准世界。

代理在多代理系统中如何协作？

当任务变得过于复杂时，可能需要多个代理协同工作来解决它。为特定工具/步骤定义特定代理也是一个好主意，这样可以逐个迭代和改进它们。创建多代理系统的方式有很多种，且没有共识认为哪种方式最好。在本节中，我们将讨论多个代理可能如何协作以及它们如何沟通以共享信息。

目前，我们可以看到多代理系统中出现以下模式：

• 管理者（或监督者）- 工作者：一个单一的管理者或监督者代理控制整体流程，并决定下一个调用哪个子代理工作者来解决问题，就像团队负责人召唤个人贡献者一样。这也可以称为垂直架构 [41]。
• 层级：该模型扩展了管理者-工作者模型，形成管理者的管理者，形成层级或树状架构。这就像大型企业的运作方式——有部门、团队负责人和个人贡献者。
• 网络/群体：在该模型中，所有代理都是相互连接的，每个代理可以在需要帮助时调用其他代理。这就像一种自组织架构，当问题没有明确的层级或顺序时可能会很好，但也有可能变得混乱。

代理在沟通（共享信息）方面也有不同的方式：

• 图状态：如果代理被定义为图节点，它们可以通过图状态进行通信，将图状态传递给下一个代理节点。这是LangGraph [24]中的主要思想。
• 完整历史：如果任务不是太复杂或上下文不太长，代理可以共享任务的完整历史以及代理的内部思维/工具执行历史。
• 选择性共享：通常，由于上下文限制，无法共享完整历史。代理可以选择性地共享它们认为对其他代理有用的信息。就像人类工作者一样，我们向同事提供一些关于我们工作的上下文，以帮助他们做出决策。
• 最终结果：如果其他代理不需要代理的上下文或内部过程，可以将代理的最终结果传递给下一个代理。这样，每个代理就像一个工具，只需将工具结果传递给下一步。

由于大型语言模型代理是一个新领域，而多代理系统则更为前沿，因此尚未达成共识，认为哪种方式是架构多代理系统或代理通信的最佳方式。一些框架支持不同的方法，您可以自己尝试。

我应该使用哪个框架来构建人工智能代理？（编程与无代码）

就像我刚才描述的MCP协议一样，人工智能代理框架的数量也处于一种每天都有新框架的状态，并且没有“最佳”人工智能代理框架的答案。

虽然没有明确的“最佳”框架，我将介绍一些有一定影响力的人工智能代理框架，并提供它们的概述，但框架的选择取决于您的目标和任务：

• LangChain & LangGraph [23][24]：LangGraph是LangChain用于复杂代理系统的编排框架，采用基于图的编排和持久状态管理。LangGraph支持不同的多代理架构和代理间通信风格 [36]。由于LangChain是大型语言模型框架中的早期参与者，LangGraph也受到了很多关注，网上有许多教程可供学习，但很多人批评LangChain和LangGraph过于抽象，定制化困难。

• SmolAgents [2][25]：SmolAgents是Hugging Face的极简人工智能代理框架，其核心功能仅需1000行代码。我推荐它作为学习资源。您可以访问他们的仓库，阅读他们的GitHub实现，这样您将更好地理解人工智能代理的工作原理。SmolAgent专注于通过代码块执行“动作”，然后通过执行代码“观察”结果。对于多代理协作，代理被视为其他代理在需要时可以调用的工具 [37]。

• Swarm [26]：Swarm是OpenAI的教育代理框架。与SmolAgents类似，尽管该框架由于缺乏持久状态和功能有限而不太适合生产，但它是学习多代理系统的良好资源，来自LLM领域的OG——OpenAI。对于多代理协作，代理可以访问转移功能，将对话“交接”给另一个代理。就像您拨打接待员电话时，他们会根据您的问题转接到工程/财务等特殊角色。

• PydanticAI [27]：PydanticAI是一个基于Pydantic构建的框架，用于生产级人工智能应用，最近于2024年12月发布。它是模型无关的、类型安全的，并旨在像FastAPI一样对开发者友好。PydanticAI支持不同级别的多代理协作，包括委托（使用工具通过另一个代理）、像Swarm一样的交接，或使用基于图的状态机的图形控制流 [39]。

• CrewAI [28]：CrewAI是一个用于编排角色扮演、自治人工智能代理的框架。CrewAI因其简单性和用户友好的集成而获得了社区的积极反馈。Crew（一个协作的代理组）可以遵循顺序或层次流程进行多代理协作 [40]。

• Google Vertex AI Agent Builder [29]：Google提供了一个无代码接口，用于构建可以与其基础模型和Google搜索功能集成的对话人工智能代理。它还提供RAG、评估和监控。

• Amazon Bedrock Agents [30]：与Google类似，Amazon也提供用于构建具有多代理协作的人工智能代理的服务。他们还提供无代码代理构建，可以轻松与他们的AWS服务集成。

• Dify [31]：Dify是一个开源平台，为人工智能代理开发提供类似的无代码功能，具有RAG管道和为非技术用户提供的预构建模板。

• Coze [32]：与Dify类似，Coze也为非技术用户提供无代码人工智能代理构建体验。但它是由字节跳动（TikTok的母公司）提供的托管服务。从无代码开发者的角度来看，它用户友好且易于使用。

（编辑日期：2025年2月17日：改进了代理框架的描述。）

当然，除了这些框架外，您始终可以选择自己构建。实际上，如果您在Reddit上搜索推荐的人工智能代理框架，人们通常会建议您构建自己的人工智能代理，以避免框架的开销。毕竟，人工智能代理是一个带有目标、工具定义和上下文的提示，包含一些代码以链接大型语言模型调用、执行函数并插入相关上下文。如果您对自己的任务非常了解，并且理解人工智能代理的工作原理（从SmolAgents或Swarm中学习！），那么构建自己的人工智能代理是很容易的。

Please translate the following text to Chinese. Requirements: 1. Keep code blocks (```) unchanged 2. Keep inline code (`) unchanged 3. Keep Markdown formatting 4. Use these technical term translations: AI agents -> 人工智能代理 large language models -> 大型语言模型 multimodal vision language models -> 多模态视觉语言模型 automation -> 自动化 human-AI interaction -> 人机交互 programmatic flows -> 程序化流程 LLM capabilities -> 大型语言模型能力 prompt chaining -> 提示链 intent routing -> 意图路由 multi-agent systems -> 多代理系统 RAG (retrieval-augmented generation) -> RAG（检索增强生成） vector databases -> 向量数据库 search APIs -> 搜索API graph databases -> 图数据库 SQL databases -> SQL数据库 function calling -> 函数调用 JSON format -> JSON格式 Claude MCP (Model Context Protocol) -> Claude MCP（模型上下文协议）

     Text: ## Tips & best practices for building robust and efficient AI agents

When building production-grade AI agents, there are some general principles and tips that can make your agent more robust and make your agent-building experience smoother.

Let’s start with some general principles to follow when designing your agentic solution/product:

• Start simple, and scale gradually. As I’ve mentioned in the first few sections, start by thinking about whether an AI agent is the easiest solution to your problem at hand — you may not even need an AI agent [4]. If so, you should start with simple, straightforward agent designs with limited tools & knowledge and add complexity only when necessary [33]. This reduces the chances of compounding errors in the agent workflow.

• Ensure transparency and explainability with comprehensive logging [4]. It will be a developer’s nightmare if you find a bug but don’t know where it comes from. You should log the planning, decisions, tool usage, and messages in the agent’s workflow [5][33]. This is especially important for debugging and monitoring production apps.

• Set up proper evaluation and testing. Just like writing code, you should set up evaluation and testing for your agent workflow. Proper automated evaluation can prevent failures and accelerate your development process [12][33]. For each step that the agent takes, you can have unit tests; and for the entire workflow, you should also evaluate cost, efficiency/latency, accuracy, success rate, etc.

For the steps/nodes in the agent workflow, there are also some tips that may help you design and implement more robust and efficient agents:

For general steps:

• Choose the most appropriate model. The most capable reasoning model may not be the best choice for every step. You should balance cost, latency, and accuracy for each step based on your own specific needs [33].

• Implement confirmation mechanisms & security. While agents are capable, you shouldn’t put all your trust in them. You should consider adding user confirmation steps for critical actions like modifying data or sensitive operations [33] and follow the principle of least privilege. For example, coding agents like Cursor or Cline will ask you to confirm if you want to apply the proposed code changes.

• Manage the context for each step. When providing the agent with context, it’s not a good idea to always provide the full message history, all tool definitions, and all retrieved RAG chunks. Pick only the necessary context that the model requires to perform its actions. This can not only reduce token usage but also improve decision-making outcomes.

For planning:

• Evaluate the plan for efficiency. Sometimes, an agent may choose an inefficient plan for achieving a goal while there might be better plans. You should evaluate and monitor metrics like the number of steps and thinking tokens to iteratively improve the plan efficiency by providing it with feedback or better prompting.

• Validate the plan for goal achievement. Agents may also come up with plans that won’t lead to achieving the goal or mistakenly believe that they have achieved a goal [12]. In this case, you can validate the plan with another agent or with non-LLM-based tools or scripts. (A common example would be an agent going in circles and trying to do the same actions over and over, which can be easily detected with code.)

For tool use:

• Use concise tool description and documentation. You should optimize the agent-computer interface by providing the agent with clear and concise tool descriptions, so they understand when they should use a tool [4][34]. Think in the agents’ shoes — just like when you’re writing API documentation for your peer developer. This can reduce token usage and improve the performance of tool use. Some quick tips are:

  1. Use descriptive & unambiguous function names
  2. Clearly describe function & params with purpose and use cases
  3. Include examples and edge cases for non-reasoning models
  4. Don’t give too many tools for the agent to choose from.

• Validate tools and tool params. The agent might hallucinate by trying to call a tool not provided to it or by calling a tool with non-existent param fields [12]. This can be reduced by using enums in param description or not having LLM fill params that you can fill with code [35]. Your code should validate these or you may even be able to restrict the tokens in the structured output.

如何在产品中设计人工智能代理体验？

在考虑与人工智能代理的用户体验或产品体验时，我希望从以下几个层面来思考：用户触发、事件触发和预测。这些不同层次的人工智能代理自主性可以为用户提供不同的体验，并在用户旅程中带来愉悦的时刻。

第一种体验是用户触发的代理。对于这些类型的代理，用户需要明确发起交互。例如，用户需要点击代理按钮/图标，输入他们的查询，然后代理将开始工作以回答用户的查询。这种体验非常反应性，代理仅对用户的命令作出反应。这可能是当前环境中最常见的代理类型。一个例子是亚马逊的Rufus购物助手代理，用户需要点击图标并输入他们的问题。

亚马逊Rufus的截图。

更顺畅的体验可能是事件触发的人工智能代理，这些代理不一定需要用户的明确指示来开始工作，而是可以通过用户自然工作流程中的特定触发事件来启动。这减少了用户记住调出代理并给出指令的认知负担。用户可以继续他们原来的工作流程，代理将完成他们的任务并将结果呈现给用户。这种体验的一个例子可能是Loom最近的人工智能更新。用户只需像往常一样录制他们的屏幕，Loom的人工智能将开始生成标题、摘要和待办事项，去除视频中的沉默/填充词，甚至为未来的参考生成文档/Jira票据/或电子邮件。

Loom AI的截图

更进一步可能是预测性人工智能代理，这些代理可以在用户甚至意识到他们想要什么之前，自主帮助用户完成任务。这些代理可以分析用户模式、上下文和历史行为，以预测用户的需求并采取主动行动。这种自主性级别为用户提供无缝的协助，并可能帮助用户实现他们可能未意识到的目标，但这需要产品经理或设计师对用户的偏好和待完成工作（JTBD）有深入的理解。你需要平衡何时直接行动与何时等待用户的确认。我看到的一个早期例子是Semrush的副驾驶，它可以主动分析有机流量和竞争对手数据，以识别您网站SEO的潜在改进领域。

Semrush的截图。

摘要

虽然现在对人工智能代理有一些炒作，但我相信通过这篇文章，你对它们以及它们如何为我们的用户与产品之间的互动开辟新方式有了更好的理解。

如果你是产品经理/设计师或企业家，确保超越炒作，找到可以为用户带来价值的人工智能代理的真实、有价值的用例。不要仅仅为了引入代理而将其放入你的产品中——如果处理不当，可能会因延迟和错误而在用户旅程中造成更多摩擦。

如果你是一个尝试实现人工智能代理系统的开发者，你也应该仔细评估任务，并确定它是否真的需要人工智能代理的推理能力来处理复杂和开放式的决策。

但如果你确实找到一个需要人工智能代理作为最佳解决方案的用例，那就去做吧！首先从一个简单的代理系统开始，逐步扩展，你将会打造出一个强大而高效的人工智能代理，为你的用户和业务带来实际价值。

参考文献和资源

[1] “自主代理：特征和要求，卡内基梅隆技术报告 CMU-CS-91–204” Brustoloni, Jose C. 卡内基梅隆大学, https://iiif.library.cmu.edu/file/Newell_box00089_fld06093_doc0001/Newell_box00089_fld06093_doc0001.pdf

[2] “介绍 smolagents，一个构建代理的简单库” HuggingFace, https://huggingface.co/blog/smolagents

[3] “什么是人工智能代理？” IBM, https://www.ibm.com/think/topics/ai-agents

[4] “构建有效的代理” Anthropic, https://www.anthropic.com/research/building-effective-agents

[5] “代理” Google, https://www.kaggle.com/whitepaper-agents

[6] “TPTU：基于大型语言模型的人工智能代理的任务规划和工具使用。” Ruan, Jingqing, 等. NeurIPS 2023 决策制定基础模型研讨会. 2023, https://arxiv.org/abs/2308.03427

[7] “基于大型语言模型的多代理：进展与挑战的调查” Guo, Taicheng , 等. arXiv 预印本 arXiv:2402.01680, https://arxiv.org/abs/2402.01680

[8] “基于大型语言模型的代理的崛起与潜力：一项调查” Xi, Zhiheng, 等. arXiv 预印本 arXiv:2309.07864, https://arxiv.org/abs/2309.07864

[9] “什么是人工智能代理？” 亚马逊网络服务, https://aws.amazon.com/what-is/ai-agents/

[10] “人工智能代理组件” MindsDB, https://mindsdb.com/blog/ai-agents-components

[11] “机器人中的人工智能代理” SmythOS, https://smythos.com/ai-agents/impact/ai-agents-in-robotics/

[12] “代理” Huyen, Chip, https://huyenchip.com/2025/01/07/agents.html

[13] “ReAct：在语言模型中协同推理和行动” Yao, Shunyu, 等. arXiv 预印本 arXiv:2210.03629, https://arxiv.org/abs/2210.03629

[14] “理解大型语言模型代理的规划：一项调查” Huang, Xu, 等. arXiv 预印本 arXiv:2402.02716. https://arxiv.org/abs/2402.02716

[15] “思维树：与大型语言模型的深思熟虑的问题解决” Yao, Shunyu, 等. 神经信息处理系统进展 36 (2024). https://arxiv.org/abs/2305.10601

[16] “更多代理就是你所需要的” Li, Junyou, 等. arXiv 预印本 arXiv:2402.05120. https://arxiv.org/abs/2402.05120

[17] “自我精炼：自我反馈的迭代精炼” Madaan, Aman, 等. 神经信息处理系统进展 36. https://arxiv.org/abs/2303.17651

[18] “通过自我对弈和从人工智能反馈中学习，改善语言模型的谈判” Fu, Yao, 等. arXiv 预印本 arXiv:2305.10142. https://arxiv.org/abs/2305.10142

[19] “大型语言模型的检索增强生成：一项调查” Gao, Yunfan, 等. arXiv 预印本 arXiv:2312.10997. https://arxiv.org/abs/2312.10997

[20] “如何在你的大型语言模型应用中改善RAG结果：从基础到高级” Zhao, Guodong. https://readmedium.com/how-to-improve-rag-results-in-your-llm-apps-from-basics-to-advanced-822818014144

[21] “无相关标签的精确零样本密集检索” Gao, Luyu, 等. arXiv 预印本 arXiv:2212.10496. https://arxiv.org/abs/2212.10496

[22] “介绍模型上下文协议” Anthropic. https://www.anthropic.com/news/model-context-protocol

[23] “LangChain” https://www.langchain.com/

[24] “LangGraph” https://www.langchain.com/langgraph

[25] “SmolAgents” HuggingFace. https://github.com/huggingface/smolagents

[26] “swarm” OpenAI. https://github.com/openai/swarm

[27] “PydanticAI” Pydantic. https://ai.pydantic.dev/

[28] “CrewAI” Crew AI Inc. https://github.com/crewAIInc/crewAI

[29] “Vertex AI Agent Builder” Google. https://cloud.google.com/products/agent-builder

[30] “Amazon Bedrock Agents” 亚马逊. https://aws.amazon.com/bedrock/agents/

[31] “Dify” langgenius. https://github.com/langgenius/dify

[32] “Coze” Bytedance. https://www.coze.com/

[33] “使用亚马逊Bedrock Agents构建强大生成式人工智能应用的最佳实践 — 第2部分” AWS 机器学习博客. https://aws.amazon.com/blogs/machine-learning/best-practices-for-building-robust-generative-ai-applications-with-amazon-bedrock-agents-part-2/

[34] “EASYTOOL：通过简洁的工具指令增强基于大型语言模型的代理” Yuan, Siyu, 等. arXiv 预印本 arXiv:2401.06201. https://arxiv.org/abs/2401.06201

[35] “函数调用 — OpenAI API” OpenAI. https://platform.openai.com/docs/guides/function-calling

[36] “多代理系统” LangGraph. [https://langchain-ai.github.io/langgraph