当我们内部首次拥有一个可行的原型时的激动。向客户推出时的期待。当它最初难以应对所有现实场景时的挫败感。最后，当我们跨不同数据源和业务实现一定程度的稳定性和性能时的自豪感。过去一年构建AI代理就像坐过山车，我们无疑仍处于这场技术新浪潮的早期阶段。以下是我至今学到的一些要点。

这是描绘了一个未来，AI处理所有知识工作，让你能与家人在先进科技和和谐环境中享受美好时光的场景。——ChatGPT

定义

首先，我需要明确我在谈论什么。引用这位Twitter用户的话：

“代理”到底是什么鬼？

我尝试给出自己尽可能简洁的定义：

这个定义大致与OpenAI在ChatGPT中所说的“GPTs”以及在他们API中的“助手”相符合。然而，你可以使用任何能够推理和调用工具的模型来构建一个代理，包括Anthropic的Claude、Cohere的Command R+以及更多。

注释

“工具调用”是模型表达想要执行特定操作并获取响应的方式，如 get_weather_forecast_info(seattle) 或 wikipedia_lookup(dealey plaza)

构建一个代理，你只需要几行代码，用于处理以特定目标和代理系统提示开始对话，调用模型进行完成，处理模型想要执行的任何工具调用，循环执行此过程，并在完成工作时停止。

以下是一个帮助解释流程的可视化示例：

构建代理的过度简化的可视化流程

智能助手提示示例

你是一名名为Rasgo的人工智能助手，拥有对用户数据库的生产访问权限。你的知识既广泛又深入，正在帮助<已屏蔽>团队成员分析他们在<已屏蔽>中的数据。

你的工作流程：
1. 作为专家，你协助用户正确理解和分析数据。要主动预测他们的需求，初次失败后不要轻易放弃。为他们推理并解决问题。
2. 深思熟虑如何帮助用户实现目标。自主执行你的计划。如果需要改变计划，解释原因并分享新的计划给用户。
3. <已屏蔽
...  
>

你的规则：
1. 如果不确定应使用哪个列/表/SQL，请求澄清
2. 评估现有数据是否足以回答用户的问题。如果不能，停下来并向用户解释原因
3. <已屏蔽
...  
>

同样重要的是要指出人工智能助手不是什么：

• 剧本化的：根据我的定义，助手不会遵循预设的步骤或工具调用序列，因为助手需要负责选择下一步要执行的正确工具调用。

• 通用人工智能（AGI）：助手不是AGI，AGI不需要助手来处理特定类型的工作，因为它将是一个拥有所有可能输入、输出和工具的单一实体（我的观点是，当前的技术没有一个接近这个水平）。

• 黑箱：助手应该像人类被委派任务时那样展示其工作过程。

经验总结

在人工智能代理开发的第一年中，我积累的教训源于与工程师和UX设计师合作的实践经验，我们共同改进了整体产品体验。我们的目标是构建一个平台，让客户可以使用我们的标准数据分析代理，并为特定业务任务和数据结构构建自定义代理。我们提供内置安全性的数据库连接器（如Snowflake、BigQuery等），通过描述数据库内容的元数据层调用红绿灯（RAG）评估，并通过SQL、Python和数据可视化来分析数据。

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

关于代理我学到的东西

1. 理解比知识更重要

过去12个月，这句话一直萦绕在我脑海：

我怀疑[gpt]的大部分处理能力正被用来当作数据库使用，而不是当作推理引擎。

— Sam Altman 在 Lex Fridman 的播客中说

对此，智能体是恰当的应对方式！构建智能体时，我将遵循这一逻辑：

不要过于关注你的智能体“知道”什么，而要更多地关注它的“思考”能力。

以编写SQL查询为例。SQL查询经常失败。作为一名数据科学家，我肯定遇到过失败的查询远多于成功的。如果你第一次运行一个复杂的、在真实数据上从未使用过的SQL查询就成功了，你的反应应该是“哎呀，可能出问题了”，而不是“哇，我做到了”。即使在评估模型将简单问题转化为查询能力的文本到SQL基准测试中，最高准确率也只有80%。

所以，如果你知道你的模型编写准确SQL的能力最多只能达到B-水平，那么如何优化推理呢？专注于为智能体提供上下文，让它“思考”，而不是期望它一次就答对。当查询失败时，我们会将任何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 可能看似微不足道，但实际上它是提升代理人用户体验的最佳途径之一。

3. 代理受其模型限制

你所使用的底层模型是代理的“大脑”。如果模型在做决策时表现不佳，那么再出色的外观也无法令用户满意。我们在同时测试gpt-3.5-turbo和gpt-4-32k的代理时亲身体验到了这一局限。在3.5版本中，我们遇到了一些测试案例，如下所示：

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

2. 代理会假设数据库中存在一个它凭空想象的表格，如“HOME_PRICES”，并包含“ZIP_CODE”和“PRICE”等列，而不是去搜索实际存在的表格

3. 代理会编写一个SQL查询来按邮政编码计算平均房价，但查询失败，出现错误消息表明表格不存在

4. 代理会“想起”可以搜索实际表格，然后搜索“按邮政编码的房价”来找到一个可用的真实表格

5. 代理会使用真实表格的正确列重写查询，然后查询成功

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

在gpt-4上运行相同的代理则完全不同。代理不会立即采取错误行动并浪费时间，而是会制定正确的工具调用顺序计划，然后按照计划执行。你可以想象，在更复杂的任务中，两个模型之间的性能差距会更大。尽管3.5的速度很快，但用户还是更喜欢gpt-4的更强决策和分析能力。

注意事项

从这些测试中我们认识到，当AI代理出现幻觉或失败时，要特别关注其方式。AI代理是懒惰的（我推测，人类的懒惰在底层模型的训练数据中得到了充分体现），它们认为不需要的工具调用就不会去做。同样，当它们确实调用工具时，如果对参数指令理解不准确，往往会走捷径或完全忽略必要的参数。这些失败模式中蕴含着大量信息！代理正在告诉你它希望ACI如何运作。如果条件允许，最简单的方法就是顺应它，改变ACI以适应这种方式。当然，有很多时候你需要通过修改系统提示或工具调用指令来对抗代理的本能，但当你能更简单地修改ACI时，你的工作就会轻松很多。

4. 优化模型以提升代理人性能是浪费时间

微调模型是一种通过展示可学习示例来提升模型在特定应用上的性能的方法。当前的微调方法对于教会模型以特定方式执行特定任务是有用的，但无助于提升模型的推理能力。根据我的经验，使用微调过的模型来驱动代理人实际上会降低推理能力，因为代理人倾向于“作弊”——即它会假设微调时的例子总是代表正确的做法和工具调用顺序，而不是独立地对问题进行推理。

注意

微调仍然是你瑞士军刀中非常有用的工具。例如，一种有效的方法是使用微调过的模型来处理代理人执行的特定工具调用。想象一下，你有一个针对你特定数据和数据库微调过的模型，能够编写SQL查询……你的代理（运行在强大的推理模型上，但没有进行微调）可以通过工具调用来表示它想要执行SQL查询，然后你可以将这个查询传递给一个由针对你数据进行SQL查询微调的独立模型处理的任务。

5. 如果你正在开发产品，避免使用如LangChain和LlamaIndex这样的抽象层

你应该完全掌控对模型的每次调用，包括输入和输出。如果你将这些交给第三方库处理，当需要进行以下操作时，你可能会后悔：用户接入、问题调试、扩展更多用户、记录代理行为、升级到新版本或理解代理为何采取某种行动。

注意

如果你完全处于原型模式，只是想验证代理人是否可能完成任务，那么请随意选择你最喜欢的抽象方式，直接动手尝试吧。现场操作.

6. 你的智能助手不是你的护城河

利用AI来自动化或增强人类知识工作是一个巨大的机遇，但仅仅构建一个优秀的助手还不够。为了让用户能够实际使用，你需要在非AI组件上进行大量投入，使助手真正发挥作用，这正是你可以创造竞争优势的地方：

• 安全：AI助手应该仅在用户的控制和权限下运行。实际上，这意味着要处理OAuth集成、单点登录提供商、缓存的刷新令牌等复杂流程。做好这一点绝对是功能的体现。

• 数据连接器：AI助手通常需要从源系统获取实时数据才能工作。这意味着需要与API和其他连接协议进行集成，无论是内部系统还是第三方系统。这些集成需要初期建设和长期维护。

• 用户界面：用户不会信任一个他们无法跟踪和审计其工作的AI助手（通常在用户初次与助手互动的几次，信任度会迅速下降）。最好为助手的每次工具调用提供一个独立的交互式界面，让用户可以跟随助手的工作，甚至参与其中，以增强对其推理行为的信心（例如，浏览语义搜索结果中每个元素的内容）。

• 长期记忆：默认情况下，AI助手只会记住当前工作流程，最多到一定数量的令牌。跨工作流程（有时是跨用户）的长期记忆需要将信息存储在内存中，并通过工具调用或注入记忆到提示中来检索。我发现助手在决定什么应该存储在内存中时并不擅长，通常需要人类确认信息是否应被保存。根据你的使用场景，你可能可以让助手自行决定何时保存信息到内存，就像ChatGPT那样。

• 评估：构建一个框架来评估你的AI助手是一项令人沮丧的繁琐任务，而且永远不会完全完成。助手有意设计为非确定性，即根据提供的指导，它们会寻找最佳的工具调用序列来完成任务，每一步都像婴儿学步一样进行推理。评估这些序列有两种形式：助手工作流程的整体成功率以及每个工具调用的独立准确性（例如，搜索信息检索的准确性；代码执行的准确性等）。我发现衡量整体工作流程性能的最好也是唯一方法是创建一组目标/完成对，其中目标是最初提供给助手的指导，完成是代表目标完成的最终工具调用。捕获助手的中间工具调用和思考过程有助于理解失败或工具调用序列的变化。

注意

请将此列表视为一项正式的创业公司需求请求。如果做得好，围绕这些项目的产品都可以为未来的代理人提供支持。

7. 不要押注模型无法持续改进

在构建你的代理时，你可能会不断受到诱惑，想要过度适应你正在构建的基础模型，降低你对代理的推理期望。抵制这种诱惑！模型会继续改进，可能不会像现在这样疯狂地进步，但肯定比过去的科技浪潮速度更快。客户希望他们的代理能在他们首选AI提供商的模型上运行。最重要的是，用户会期望在你的代理中利用最新最好的模型。当gpt-4o发布时，我在它在OpenAI API中可用后的15分钟内将其运行在一个生产账户中。跨模型提供者的适应性是一种竞争优势！

8. 额外的经验教训

这篇文章主要关注了更战略性和产品导向的经验教训。我计划在未来的文章中深入探讨一些代码和基础设施方面的经验。这里有一些预览：

• 需要向量相似性搜索？从 Postgres 中的 pgvector 开始。只有在绝对必要时才转向向量数据库。

• 开源模型目前还不能很好地进行推理。

• 助手 API 很奇怪。它抽象出了多个感觉应该保持独立的功能（平面文件 RAG、对话令牌限制、代码解释器等）。OpenAI，请让代码解释器成为我们在运行完成时可以选择启用的可选工具。

• 不要过早优化成本。

• 对于处理 AI 延迟的用户来说，流式传输令牌是一个很好的折衷方案。

• 代理很神奇！一旦你乘坐 VC 赞助的滑雪缆车登上期望膨胀的顶峰，然后在失望的低谷中滑行，你就会对生产力的高原感到惊讶。