我构建 AI Agent 的经历与学到的教训

首先，我应该定义一下我的讨论对象。借用这位Twitter用户的话说：

“‘Agent’究竟是什么？”

我尝试用尽可能简洁的方式来定义它：

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

注意：

“工具调用”是模型表达想要执行特定操作并获得响应的方法，比如查询天气预报信息(西雅图)或维基百科搜索(迪利广场)。

要构建一个Agent，你所需要的就是几行代码，可以处理开始一次对话的目标和一个代理系统提示，调用一个模型进行完成，处理模型想要进行的任何工具调用，不断重复这个过程，并在完成工作后停止。

下面是一个图示，有助于解释流程：

Agent系统提示示例

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 Agent不是什么：

• 脚本化：按照我的定义，Agent不会遵循预先确定的步骤序列或工具调用，因为Agent负责选择下一个正确的工具调用

• 通用人工智能（AGI）：Agent不是AGI，AGI不需要针对特定工作类型使用Agent，因为它将成为一个具备所有可能输入、输出和工具的单一实体（我个人认为，当前技术不接近这一点）

• 黑盒子：Agent可以且应该展示其工作方式，就像当你委托任务给人类时人类会展示的那样

在开发AI Agent的第一年学到的经验来自于与我们的工程师和UX设计师亲身合作，我们一起不断完善我们的整体产品体验。我们的目标是为客户提供一个平台，让他们使用我们的标准数据分析代理和为特定任务和数据结构构建自定义代理，与他们业务相关。我们提供到数据库的连接器（例如Snowflake，BigQuery等），其中内置了安全性，工具需要在描述数据库内容的元数据层上调用RAG，并需要通过SQL、Python和数据可视化来分析数据。

对于哪些工作和哪些没有起作用的反馈既来自我们自己的评估，也来自客户的反馈。我们的用户来自财富500强公司，他们每天使用我们的代理来分析他们的内部数据。

1. 推理比知识更重要

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

我怀疑太多的处理能力【GPT的】被用于将模型作为数据库而非推理引擎。

— Sam Altman 在 Lex Fridman 的播客节目中

对此，Agent是适当的响应！我会在构建Agent时应用这种逻辑：

专注于您的智能体“知道”的内容，更要注重它的“思考”能力。

举例来说，让我们考虑编写 SQL 查询。SQL 查询经常失败。在我作为数据科学家的时间里，我敢肯定我的查询失败的次数比成功的次数多得多。如果在真实数据上运行一个你以前从未使用过的复杂 SQL 查询，第一次运行就成功了，你的反应应该是“哦，糟糕，可能出了什么问题”，而不是“哇，我搞定了”。甚至在评估模型将简单问题翻译成查询的文本到 SQL 基准测试中，准确率最高也只达到 80%。

因此，如果你知道你的模型编写准确 SQL 查询的能力最好只相当于 B-，那么如何优化推理呢？专注于给予Agent上下文，并让其“思考”，而不是希望它在一次尝试中就得到正确答案。当代理的查询失败时，我们确保返回任何 SQL 错误，以及能够捕获的所有上下文，这使得代理能够大多数时间解决问题并让代码正常工作。此外，我们为我们的代理提供了一些工具调用，以检索数据库中关于数据的上下文，类似于人类可能在编写新查询之前研究信息模式并分析分布和缺失值的数据。

2. 提高性能的最佳方式是通过迭代智能体-计算机界面（ACI）

ACI一词是新的（在普林斯顿大学的研究中引入），但完善它的专注已经是我们日常生活的一部分，已有一年。ACI指的是代理工具调用的确切语法和结构，包括代理生成的输入以及我们的API作出响应返回的输出。这些是代理与其需要进行与其方向一致的进展所需的数据进行接口的唯一途径。因为底层模型（gpt-4o，Claude Opus等……）都表现出不同的行为，对于一个模型效果最好的ACI未必适用于另一个模型。这意味着一个出色的ACI需要艺术和科学的结合……这更像是设计出色的用户体验，而不是编写源代码，因为它不断演进，小的调整会像车祸般发生被卷入一起。我无法过分强调ACI是多么重要……我们已经对我们的进行了数百次迭代，并且通过对我们工具的名称、数量、抽象级别、输入格式以及输出响应进行看似微小的调整，看到了代理性能的显著波动。

这里有一个小的具体例子来说明你的ACI有多关键和挑剔：在我们在gpt-4-turbo上测试代理的时候，发现一个问题，它完全忽视了我们试图告诉它的工具调用响应中存在的特定列。在当时我们使用的是从OpenAI文档直接获取的markdown格式，而且与在相同数据上的gpt-4-32k运行良好。

我们尝试了几次调整我们的markdown结构，以帮助代理识别它假装不存在的列，即使它们在它进行工具调用时的响应中。但是没有一次调整有效，所以我们不得不开始尝试使用完全不同的信息格式进行实验……而且经过一番大修转而开始使用JSON而不是markdown（仅适用于OpenAI模型），一切又恢复正常了。

具有讽刺意味的是，JSON结构化响应需要更多的标记，因为涉及所有的语法字符，但我们发现这是必要的，实际上对于帮助代理理解响应是至关重要的。对您的ACI进行迭代可能看起来微不足道，但实际上是改善Agent用户体验的最佳途径之一。

3.Agent受其模型的限制

你使用的基础模型是Agent身体的大脑。如果模型在做决策时表现糟糕，那么即使外表再好看，也不会让用户感到满意。我们首次发现这个局限性是在同时测试我们的代理在 gpt-3.5-turbo 和 gpt-4-32k 上时。在3.5上，我们有许多测试案例，大致如下：

1. 用户提供一个客观目标，例如：“分析星巴克店铺与房价之间的相关性，以邮政编码了解它们是否相关”

2. 代理会假设数据库中存在一个它臆想出来的名称为“HOME_PRICES”的表，以及类似“ZIP_CODE”和“PRICE”的列，而不是运行搜索以找到实际表

3. 代理会编写一个计算按邮政编码平均价格的 SQL 查询却失败，并收到一个指示表不存在的错误消息

4. 代理会记起“哦，是的，我可以搜索实际的表…”，并搜索“按邮政编码的房价”以找到一个可用的实际表代理会用来自一个真实表的正确列重新编写它的查询，然后它会起作用

5. 代理会继续处理星巴克店铺位置数据，并再次犯同样的错误

在gpt-4上运行代理并采用相同的方向完全不同。代替立即采取错误的行动并浪费时间的情况，代理将制定出具有正确工具调用顺序的计划，然后按计划执行。可以想象，在更复杂的任务上，两种模型之间的表现差距变得更大。尽管3.5的速度很快，我们的用户大量更喜欢gpt-4更强大的决策和分析能力。

解读：

从这些测试中我们学到的一点是要非常注意代理幻觉或失败的方式，以及何时发生。人工智能代理很懒（我假设人类的懒惰在底层模型的训练数据中得到了很好的体现），并且不会扰乱他们认为不需要的工具调用。同样地，当他们执行工具调用时，如果他们不理解参数指令，他们通常会采取捷径或完全忽略所需的参数。在这些失败模式中有很多信息！代理正在告诉你它希望ACI是什么，如果情况允许，解决这个问题的最简单方法就是让步并更改ACI的工作方式。

当然，在许多时候，你需要通过更改系统提示或工具调用指令来对抗代理的直觉，但是对于那些更简单地改变ACI的情况，你会更轻松地解决问题。

4. 微调模型提升Agent性能是浪费时间

微调模型是通过向其展示可以学习的示例来提高模型在特定应用程序上的性能的一种方法。目前的微调方法适用于教授模型以特定方式执行特定任务，但对于提高模型的推理能力并不有用。

根据我的经验，利用微调模型来驱动代理实际上会导致推理能力更差，因为代理倾向于“作弊”其方向 - 这意味着它将假定它进行微调的示例始终代表正确的方法和工具调用顺序，而不是独立地推理问题。

解读：

微调仍然可以是您的瑞士军刀中非常有用的工具。例如，一个表现良好的方法是使用一个微调的模型来处理代理进行的具体工具调用。想象一下您有一个经过微调的模型，用于在您的特定数据、在您的数据库上编写 SQL 查询... 您的代理（在没有进行微调的强大推理模型上运行）可以使用一个工具调用来指示它希望执行 SQL 查询，然后您可以将其传递到一个由您的模型处理的独立任务，该模型是针对您数据中的 SQL 查询进行微调的。

5. 如果您正在开发产品，请避免使用像LangChain和LlamaIndex这样的抽象概念

你应该完全拥有对模型的每次调用，包括输入和输出。如果你将这个工作交给第三方库，当你需要让你的Agent进行以下任何操作时，你会后悔的：接纳用户，调试问题，扩展到更多用户，记录Agent正在做什么，升级到新版本，或者理解Agent为什么这样做。注意：如果你处于纯原型模式，并且只是试图验证代理是否能够完成任务，尽管选择你喜欢的抽象层并实时操作。

6. 你的智能体不是你的护城河

用AI Agent自动化或增强人类知识工作是一个巨大的机遇，但仅仅构建一个出色的Agent是不够的。为用户生产一个Agent需要在许多非AI组件上进行重大投资，这些组件使您的Agent真正起作用...这是您可以创建竞争差异化的地方：

• 安全性：AI代理应仅在用户控制和操控下运行。实际上，这意味着通过OAuth集成、单点登录提供商、缓存刷新令牌等一系列步骤来实现。做好这件事绝对是一个功能。

• 数据连接器：AI代理通常需要源系统的实时数据来工作。这意味着需要集成API和其他连接协议，通常涉及内部和第三方系统。这些集成需要初始构建和随着时间的推移进行维护。

• 用户界面：用户不会信任一个AI代理，除非他们可以跟踪和审计其工作（通常是用户与代理交互的前几次，随着时间的流逝急剧减少）。最好是代理进行的每个工具调用都有一个专用的交互界面，以便用户能够跟踪代理的工作，并甚至与代理交互，以帮助建立对其推理行为的信心（即，浏览语义搜索结果中返回的每个元素的内容）。

• 长期记忆：AI代理默认情况下只会记住当前的工作流程，最多记住一定数量的令牌。跨工作流程的长期记忆（有时跨用户）需要将信息记录在内存中，并通过工具调用或将记忆注入提示来检索。我发现代理在决定保存哪些信息到记忆中方面并不擅长，需要依靠人类确认信息是否应该保存。根据您的用例，您可能允许代理决定何时将某些内容保存到记忆中并逃脱责任，类似于 ChatGPT。

• 评估：建立一个评估您的AI代理的框架是一个令人沮丧的手动任务，永远不会完全完成。代理是有意的非确定性，这意味着根据提供的方向，它们会着手寻找完成任务所需的最佳工具调用顺序，并在每一步之后进行推理，就像一个学步的婴儿。评估这些序列有两种形式：代理完成任务的工作流程的整体成功和每个工具调用的独立准确性（即搜索的信息检索; 代码执行的准确性等...）。我发现量化整体工作流程的表现的最佳且唯一方法是创建一组客观/完成对，其中客观是提供给代理的初始方向，完成是代表完成客观的最终工具调用。捕捉代理的中间工具调用和想法有助于理解失败或只是工具调用顺序的变化。

解读：

请将此列表视为正式的创业请求。如果每个项目都做得好，产品可以推动未来代理的发展。

7. 不要押注模型继续改进

在建立您的代理过程中，您将不断地受到诱惑，过度调整在其基础上构建的主要模型，并消除您对代理的某些推理期望。抵制这种诱惑！模型将持续改进，也许不会像我们目前的疯狂速度那样，但绝对会比过去的技术浪潮更快。客户将希望代理运行在他们首选AI提供商的模型上。

最重要的是，用户将期望在您的代理中利用最新和最优秀的模型。当gpt-4o发布时，我在OpenAI API中提供它后的15分钟内就已经将其投入到生产账户中了。在不同模型提供商之间具有适应性是一种竞争优势！

8. 学到的教训

这篇文章着重于更战略和产品导向的教训。我计划在未来的一篇文章中深入探讨一些代码和基础架构方面的教训。以下是一些提示：

• 需要矢量相似度搜索？从 postgres 中的 pgvector 开始。只有在绝对必要时才使用矢量数据库

• 开源模型目前还不太合理

• Assistants API 很奇怪。它抽象出了多个感觉应该保持独立的东西（平面文件 RAG、对话令牌限制、代码解释器等）。请，OpenAI，仅仅将代码解释器作为一个可选工具，我们可以在运行时打开它

• 不要过早地为成本进行优化

• 流式令牌在用户处理 AI 延迟时是一个很好的折中方案

• 智能体太神奇了！一旦你坐上由风险投资公司赞助的滑雪梯升到充满夸张期望的顶峰，然后在幻灭谷中滑雪，最后留意到效率高原，你将感到惊讶