作者 |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 版本的速度很快，但产品用户显然更喜欢