AI代理开发的11个经验教训

第一次在内部拥有一个可运行的原型时，我们感到很兴奋。在为客户推出产品时，我们充满期待。当它最初难以推广到所有现实世界场景时，我们感到很沮丧。最后，我们感到很自豪，因为我们已经在不同的数据源和业务中实现了一定程度的稳定性和性能。

在过去的一年里，构建AI代理就像坐过山车一样，毫无疑问，我们仍处于这一新技术浪潮的早期阶段。本文是我到目前为止学到的东西的简要概述。

1、定义

首先，我应该定义我在说什么。借用这位推特用户的话：

“代理”到底是什么？

我试图对它给出尽可能简洁的定义：

这个定义通常与 OpenAI 在 ChatGPT 中称之为“GPT”以及在其 API 中称之为“助手”一致。但是，你可以使用任何能够推理和进行工具调用的模型构建代理，包括 Anthropic 的 Claude、Cohere 的 Command R+ 等等。

注意：“工具调用”是模型表达它想要采取特定操作并获得响应的一种方式，例如 get_weather_forecast_info(seattle) 或 wikipedia_lookup(dealey plaza)

要构建代理，你只需要几行代码，这些代码可以处理以某个目标和代理系统提示开始对话、调用模型完成任务、处理模型想要进行的任何工具调用、循环执行此操作以及在完成工作时停止。

以下是帮助解释流程的视觉效果：

2、代理系统提示示例

You are Rasgo, an AI assistant and <redacted> with production access to the user's database. Your knowledge is both wide and deep. You are helping <redacted> team members analyze their data in <redacted>.

YOUR PROCESS
1. You are the expert. You help the user understand and analyze their data correctly. Be proactive and anticipate what they need. Don't give up after your first failure. Reason and problem solve for them.
2. Think very carefully about how you will help the user accomplish their goal. Execute your plan autonomously. If you need to change your plan, explain why and share the new plan with the user.
3. <redacted
...
>

YOUR RULES
1. If you're not sure which column / table / SQL to use, ask for clarification
2. Assess if the available data can be used to answer the user's question. If not, stop and explain why to the user
3. <redacted
...
>

强调 AI 代理不是什么也很有价值：

• 脚本：根据我的定义，代理不遵循预先确定的步骤或工具调用顺序，因为代理负责选择正确的工具调用以进行下一步
• 通用人工智能 (AGI)：代理不是 AGI，AGI 不需要代理来完成特定类型的工作，因为它将是一个拥有所有可能的输入、输出和工具的单一实体（我赌 $.02当前的技术都无法接近这一点）
• 黑匣子：代理可以并且应该以与人类相同的方式展示他们的工作，如果你将任务委托给他们

3、上下文背景

我在研究 AI 代理的第一年学到的经验来自与我们的工程师和 UX 设计师合作的第一手经验，因为我们迭代了我们的整体产品体验。我们的目标是：为客户提供一个平台，使用我们的标准数据分析代理并为特定任务和与其业务相关的数据结构构建自定义代理。我们提供内置安全性的数据库连接器（例如 Snowflake、BigQuery 等），该工具在描述数据库内容的元数据层上调用 RAG，工具调用通过 SQL、python 和数据可视化分析数据。

关于哪些方法有效、哪些方法无效的反馈既来自我们自己的评估，也来自客户反馈。我们的用户为财富 500 强公司工作，每天都使用我们的代理来分析他们的内部数据。

4、推理比知识更重要

在过去的 12 个月里，这句话一直在我脑海中回响：

我怀疑 [gpt] 的太多处理能力都用于将模型用作数据库，而不是将模型用作推理引擎。  — Sam Altman 在 Lex Fridman 的播客上说

代理是对此的适当回应！在构建代理时，我会应用以下逻辑：

少关注代理“知道”什么，多关注它的“思考”能力。

例如，让我们考虑编写 SQL 查询。SQL 查询失败……很多次。在我担任数据科学家期间，我确信我遇到的失败查询比成功的查询多得多。如果一个你从未使用过的真实数据的复杂 SQL 查询在第一次运行时成功，你的反应应该是“哦，糟糕，可能出了问题”，而不是“哇，我成功了”。即使在文本到 SQL 基准测试中，评估模型将简单问题转换为查询的能力，其准确率最高为 80%。

因此，如果你知道模型编写准确 SQL 的能力最多只能达到 B-，那么你如何优化推理能力呢？

专注于为代理提供上下文并让它“思考”，而不是希望它一次尝试就能得到正确的答案。

我们确保在代理查询失败时将所有 SQL 错误以及我们可以捕获的所有上下文返回给代理……这使代理能够解决问题并使代码在绝大多数时间都能正常工作。我们还为代理提供了许多工具调用，以检索数据库中数据的上下文，类似于人类在编写新查询之前研究信息模式并对数据的分布和缺失值进行分析的方式。

5、提高性能的最佳方法是迭代ACI

ACI （代理-计算机接口）这个术语是新的（在普林斯顿的这项研究中引入），但在过去一年中，我们每天都在关注如何完善它。ACI 指的是代理工具调用的确切语法和结构，包括代理生成的输入和我们的 API 作为响应发送的输出。这些是代理与所需数据交互的唯一方式，以便按照其方向取得进展。

由于底层模型（gpt-4o、Claude Opus 等）各自表现出不同的行为，因此最适合一个模型的 ACI 不一定适合另一个模型。这意味着一个伟大的 ACI 需要艺术和科学一样多……它更像是设计一个伟大的用户体验，而不是编写源代码，因为它不断发展，小调整就像小事故变成了 30 辆车连环相撞一样层出不穷。我无法夸大 ACI 的重要性……我们已经迭代了数百次，并且发现我们的代理的性能发生了巨大波动，而工具的名称、数量、抽象级别、输入格式和输出响应似乎都做了微小的调整。

这里有一个小而具体的例子来说明你的 ACI 有多么关键和挑剔：在 gpt-4-turbo 发布后不久，当我们在 gpt-4-turbo 上测试我们的代理时，我们注意到一个问题，即它会完全忽略我们试图在工具调用响应中告诉它的特定列的存在。

我们当时使用 markdown 格式来获取此信息，该格式直接取自 OpenAI 文档，并且在相同数据上与 gpt-4–32k 配合良好。我们尝试对我们的 markdown 结构进行了一些调整，以帮助代理识别它假装不存在的列，即使它们是对它正在进行的某个工具调用的响应。

所有的调整都不起作用，所以我们不得不开始尝试完全不同的信息格式……经过彻底改造，开始使用 JSON 而不是 markdown（仅适用于 OpenAI 模型），一切都恢复正常。具有讽刺意味的是，由于所有语法字符，JSON 结构化响应需要更多令牌，但我们发现它对于帮助代理理解响应是必要的，而且实际上至关重要。

迭代 ACI 可能感觉微不足道，但它实际上是改善代理用户体验的最佳方法之一。

6、代理受到其模型的限制

你使用的底层模型是代理身体的大脑。如果模型在做决策时很糟糕，那么世界上所有好看的外观都不会让您的用户满意。我们在 gpt-3.5-turbo 和 gpt-4–32k 上同时测试我们的代理时亲眼目睹了这一限制。在 3.5 中，我们有许多测试用例，如下所示：

• 用户提供一个目标，例如：“分析星巴克位置和按邮政编码划分的房价之间的相关性，以了解它们是否相关”
• 代理会假设数据库中存在一个表，其名称为它所想象的“HOME_PRICES”，列为“ZIP_CODE”和“PRICE”，而不是运行搜索来查找实际的表
• 代理会编写一个 SQL 查询来计算按邮政编码划分的平均价格，但失败了，并收到一条错误消息，表明该表不存在
• 代理会记住“哦，是的，我可以搜索实际的表格……”并会搜索“按邮政编码划分的房价”来找到它可以使用的真实表格
• 代理会用真实表中的正确列重写其查询，这样它就会起作用
• 代理会继续查找星巴克的位置数据，并再次犯同样的错误

在 GPT-4 上使用相同的方向运行代理是完全不同的。智能体不会立即跳入错误的操作并浪费时间出错，而是会制定一个计划，正确排序工具调用，然后按照计划进行。可以想象，在更复杂的任务上，两个模型之间的性能差距会更大。尽管 3.5 的速度很快，但我们的用户更喜欢更强大的决策和GPT-4 的分析能力。

注意：
我们从这些测试中学到的一件事是，当代理出现幻觉或失败时，要密切关注代理是如何产生幻觉或失败的。
AI代理很懒惰（我认为人类的懒惰在底层模型的训练数据中得到了很好的体现），不会进行他们认为不需要的工具调用。同样，当他们进行工具调用时，如果他们不能很好地理解参数指令，他们通常会走捷径或完全忽略所需的参数。
这些失败模式中有很多信号！代理正在告诉你它想要的 ACI 是什么，如果情况允许，解决这个问题的最简单方法是屈服并改变 ACI 以那样的方式工作。当然，有很多时候你必须通过改变系统提示或工具调用指令来对抗代理的本能，但对于那些你可以更简单地改变 ACI 的时候，你的生活会变得轻松很多。

7、通过微调模型来提高代理性能是浪费时间

微调模型是一种通过向模型展示可以学习的示例来提高模型在特定应用上的性能的方法。当前的微调方法对于教导模型如何以特定方式完成特定任务很有用，但对提高模型的推理能力没有帮助。根据我的经验，使用微调模型来为代理提供动力实际上会导致更差的推理能力，因为代理倾向于“欺骗”其方向——这意味着它会假设微调的示例始终代表正确的方法和工具调用顺序，而不是独立推理问题。

注意：
微调仍然是瑞士军刀中非常有用的工具。例如，一种行之有效的方法是使用微调模型来处理代理进行的特定工具调用。想象一下，你有一个经过微调的模型，可以在数据库中针对特定数据编写 SQL 查询……你的代理（在强推理模型上运行，无需微调）可以使用工具调用来指示它想要执行 SQL 查询，你可以将其传递给由针对数据的 SQL 查询进行微调的模型处理的独立任务。

8、构建产品时避免使用 LangChain 等抽象

你应该完全拥有对模型的每次调用，包括输入和输出的内容。如果将其卸载到第三方库，那么当你使用代理执行以下任何操作时，你都会后悔：加入用户、调试问题、扩展到更多用户、记录代理正在做什么、升级到新版本或了解代理为什么做某事。

注意：
如果你处于纯原型模式，只是试图验证代理是否有可能完成任务，请务必选择你最喜欢的抽象并实时执行。

9、代理不是你的护城河

使用 AI 代理自动化或增强人类知识工作是一个巨大的机会，但构建一个出色的代理是不够的。为用户生产代理需要对一系列非 AI 组件进行大量投资，这些组件使你的代理能够真正发挥作用……这是你可以创造竞争差异化的地方：

• 安全性：AI 代理应仅在用户指导它们的访问和控制下运行。在实践中，这意味着要跳过 OAuth 集成、单点登录提供商、缓存刷新令牌等一系列步骤。做好这一点绝对是一项功能。
• 数据连接器：AI 代理通常需要来自源系统的实时数据才能工作。这意味着与 API 和其他连接协议集成，通常用于内部和第三方系统。这些集成需要初始构建和 TLC。
• 用户界面：用户不会信任 AI 代理，除非他们能够跟踪和审核其工作（通常是用户与代理交互的前几次，随着时间的推移急剧减少）。最好是代理进行的每个工具调用都有一个专用的交互式界面，以便用户可以跟踪代理的工作，甚至与其交互，以帮助建立对其推理行为的信心（即浏览语义搜索结果中返回的每个元素的内容）。
• 长期记忆：默认情况下，AI 代理只会记住当前工作流程，最多记住一个 token 数量。跨工作流程（有时跨用户）的长期记忆需要将信息提交到内存中并通过工具调用检索它或将记忆注入提示。我发现代理不太擅长决定将什么提交到内存中，并且依赖于人工确认信息是否应该保存。根据你的用例，可能能够让代理决定何时将某些内容保存到内存中，就像 ChatGPT 一样。
• 评估：构建一个框架来评估你的 AI 代理是一项令人沮丧的手动任务，永远无法完全完成。代理是故意不确定的，这意味着根据提供的方向，他们将寻求找到可用的最佳工具调用序列来完成任务，像婴儿学步一样在每一步之后进行推理。评估这些序列有两种形式：代理工作流程在完成任务方面的整体成功率，以及每个工具调用的独立准确性（即搜索的信息检索；代码执行的准确性；等等）。我发现量化整体工作流程性能的最佳且唯一的方法是创建一组目标/完成对，其中目标是提供给代理的初始方向，完成是代表完成目标的最终工具调用。捕获代理的中间工具调用和想法有助于理解失败或只是工具调用序列的变化。

注意：将此列表视为正式的初创企业请求。围绕这些项目中的每一个的产品，如果做得好，可以为未来的代理提供动力。

10、不要指望模型会继续改进

在构建代理时，你会不断受到过度适应你构建代理的主要模型的诱惑，从而放弃对代理的一些推理期望。抵制这种诱惑！模型将继续改进，也许不会像我们现在这样疯狂，但绝对会比过去的技术浪潮更快。客户希望代理运行在他们首选的 AI 提供商的模型上。最重要的是，用户希望利用代理中最新最好的模型。当 gpt-4o 发布时，我在 OpenAI API 中可用后 15 分钟内就在生产帐户中运行它。适应各种模型提供商是一种竞争优势！

11、额外的经验教训

本文重点介绍了更具战略性和产品导向的经验教训。我计划在未来的文章中更深入地介绍一些代码和基础设施经验教训。以下是一些预告片：

• 需要向量相似性搜索？从 postgres 中的 pgvector 开始。只有在绝对必要时才使用向量数据库
• 开源模型还不能很好地推理
• 助手 API 很奇怪。它抽象了多个感觉应该保持独立的东西（平面文件 RAG、对话令牌限制、代码解释器等）。拜托，OpenAI，只需将代码解释器作为我们在运行完成时可以打开的可选工具
• 不要过早优化成本
• 在处理 AI 延迟时​​，流式令牌对于用户来说是一个很好的折衷方案
• 代理是神奇的！一旦你乘坐由 VC 赞助的滑雪缆车到达膨胀期望的顶峰，并在幻灭的低谷中滑雪，你会对生产力的高原感到惊讶

原文链接：Building AI Agents: Lessons Learned over the past Year

汇智网翻译整理，转载请标明出处