Agents 畛域 通常出真知 的阅历分享 一年打怪更新

作者 |Patrick Dougherty

编译|岳扬

01 何为“Agent”？（Definitions）

在探讨本文的关键内容之前，须要明白定义一下本文所指的“Agent”究竟是啥。借用一下这位 Twitter 用户的话[1]：

我尽力给出了一个长篇大论的定义：

该定义大抵与OpenAI在 ChatGPT 中提及的 “生成式预训练模型（GPTs）” 和其 API 中的 “助手（Assistants[2]）” 概念相符。不过，Agent 并不会局限于这些才干，任何能启动逻辑推理（reasoning）并调用工具（making tool calls）的模型都能胜任这项义务，比如 Anthropic 公司的Claude**[3]、Cohere 的 Command R+[4]等泛滥模型皆可。

tool calls 是一种让模型表白它想要执行的某种特定操作并失掉操作结果的模式，例如调用 get_weather_forecast_info(seattle) 或 wikipedia_lookup(dealey plaza) 这样的函数。

构建一个 Agent 仅需几行代码就可以了，这些代码能够处置一个有明白指标且由系统揭示词（system prompt）疏导的对话环节，能够处置模型想要执行的任何 tool calls ，循环执行这些操作，并在到达指标后中止。

上方这幅图示（visual）可以协助解释这一流程：

构建 “Agent” 的基本步骤简明概览

02 Agent System Prompt Example

须要在此廓清对 AI Agent 的几个经常出现失误观念：

03 高低文 Context

在开发 AI Agents 名目的第一年里，我从与工程师（engineers）和用户体验设计师（UX designer）的协作中取得了第一手阅历，对产品的全体用户体验效果启动了屡次优化，受害匪浅。咱们的指标是为客户打造一个平台，协助客户经常使用咱们规范化的数据剖析 Agents，并针对其业务中特有的义务和数据结构，自行开发合乎集体需求（custom）的 AI Agents。咱们确保该平台与诸如 Snowflake、BigQuery 等数据库安保对接，同时内置安保机制，在形容数据库内容的元数据层上调用 RAG（检索增强生成）工具，并经过 SQL、Python 和支持数据可视化的数据剖析工具剖析数据。

关于哪些做法可行，哪些观念则不尽善尽美，此平台不只依据自身评价（our own evaluations），也参考了客户的实在反应。 咱们的用户大多到任于 500 强企业，他们每天都经常使用咱们的 AI Agent 对外部数据启动深度剖析。

04 阅历经验（What I’ve Learned about Agents）

4.1 推理才干比常识量更关键

这句话在过去的一年里不时在我脑海中回响：

AI Agents 正是对此观念的正当回应！在构建 AI Agents 时，我会驳回这一逻辑：

别太在意 AI Agents “了解、知道（knows）” 什么，而应更看重它的 “思索（think）” 才干。

以编写 SQL 查问语句（SQL Queries）为例。SQL 查问语句（SQL Queries）往往频繁执行出错……，且不足为奇。在我负责数据迷信家（data scientist）时期，我的查问语句（SQL Queries）执行失败次数远远超越成功的次数。

假设一个复杂的 SQL 查问语句初次就能在咱们不相熟的实在数据上执行成功，咱们应该感到惊讶并发生疑心，“蹩脚，或者有疑问！”，而不会自信满满地以为“哇！完美！我搞定了”。即使是在评价模型能否将一个便捷疑问转换为查问语句的 text-to-SQL 基准测试[6]中，其最高准确率也只要 80 %。

因此，即使看法到该模型在编写 SQL 语句的才干顶多只能失掉 B- 的效果，那么咱们该如何优化其推理才干呢？关键在于为 Agents 提供足够的高低文，让它能启动 “思索” ，而非宿愿它一次性性答对。当 AI Agents 编写的查问语句执行失误时，须要反应一切 SQL errors 消息以及能够取得的尽或者多的高低文消息，这样 AI Agents 便能在大少数状况下自行修正疑问，使 SQL 语句反常执行。咱们雷同也为 Agents 提供了少量 tool calls ，使其能像人类那样，在编写新的查问语句前，先对数据库的消息架构（information schema）和数据个性（data for distributions and missing values）启动调研剖析。

4.2 优化性能的最佳模式就是不时优化“人”机交互界面（agent-computer interface, ACI）

“ACI” 这个新词（源自普林斯顿大学（Princeton）的一项钻研[7]）虽然出现不久，但咱们对它的打磨却是过去一年中的日常上班重心。ACI 指的是 AI Agents 所经常使用的 tool calls 的详细语法和架构，包括了 AI Agents 生成的 inputs 内容与 API 在照应内容中发回的 outputs 。这些是 Agents 失掉必要数据、推进上班停顿与上班指标分歧的惟一模式。

由于底层模型（比如 gpt-4o、Claude Opus 等）各有特点，所以对某一个模型来说最完美的 ACI 未必适宜另一个模型。 这就象征着，构建一个低劣的 ACI 须要“迷信（science）与艺术（art）齐飞”……更像是发明一种极致的用户体验，而非纯正地编写代码（writing source code），由于 ACI 会继续演化，小小的改动就能像多米诺骨牌一样引发一连串的反响。ACI 有如许关键，我再怎样强调都不为过…… 咱们对咱们构建的 AI Agent 启动了数百次迭代，仅仅是对命名（names）、数量（quantity）、形象水平（level of abstraction）、输入格局（input formats）及输入的照应（output responses）做出微调，就能造成 AI Agents 的性能发生渺小动摇。

此处有一个详细的小案例，能够活泼地说明 ACI 有如许关键和辣手：咱们在 gpt-4-turbo 刚推出不久后，对咱们的 AI Agents 启动了屡次测试，却发现了一个辣手的疑问 —— AI Agents 在处置照应消息时，会齐全疏忽掉某些数据（正是咱们试图经过 tool call 的照应内容来告知或传递给 Agents 的数据局部）。咱们所经常使用的是间接从 OpenAI 官网文档中提取的 markdown 格局消息，并且在雷同的数据集上与 gpt-4-32k 配合得很好。为了使 AI Agents 能够识别出那些被它“熟视无睹”的数据列（columns），咱们尝试对 markdown 结构启动一些调整，但无论怎样修正，Agents 都金石为开...... 于是，咱们选择彻底扭转战略，将消息格局从 markdown 转换为 JSON（仅针对 OpenAI 模型）格局后，奇观出现了，一切都复原如初。 颇具讥刺象征的是，照应内容驳回 JSON 格局虽然由于包括了少量语法字符而消耗了更多 tokens ，但咱们发现这一步骤不只十分必要，更是确保 Agents 能够正确解读模型照应的关键。

虽然或者对 ACI 的优化环节觉得微无余道，但这确实是改善 Agents 用户体验的有效路径之一。

4.3 AI Agents 的配置受限于其所经常使用的模型

底层模型就好比是 Agents 的大脑。假设模型的决策不尽人意，那么无论看起来如许吸引人，都无法则用户满意。这一点在咱们经常使用 gpt-3.5-turbo 和 gpt-4–32k 作为底座模型启动测试时亲自感触。在经常使用 GPT 的 3.5 版本时，某些测试案例的状况大抵为：

在 gpt-4 上，以相反的指点准则运转 Agents ，状况则一模一样。它不会再立刻执行失误的操作而糜费时期，而是会精心谋划，制订一个有序的 tool calls 执行方案，并严厉依照方案执行。不难想象，在执行更为复杂的义务时，两个模型之间的性能差距会更为清楚。虽然 GPT 3.5 版本的速度很快，但产品用户显然更青睐