在今年的美国网球公开赛中，有一个融入人工智能的系统使用摄像头观察每一次发球并给出评分。为了实现这一点，我们需要一种被称为“智能体包裹”的人工智能模型。这个AI模型还会连接到一个我们称之为API（应用程序接口）的系统中，这是接下来要讨论的最重要元素之一。但我希望思考一下：为什么我们需要这个？为什么要使用API呢？AI模型仅凭自身能在发球评判工作中走多远？

假设我向AI模型提问：“杰西卡·佩古拉的发球好吗？”现在，这个模型可以很好地尝试回答这类问题。大型语言模型已经阅读了我们所称的训练数据中几乎所有关于网球的文字。当我们把这些训练数据一起输入时，就能构建这个基础模型。它可以连接到API，并告诉我诸如佩古拉如何围绕球的旋转和球在球场上的落点重建发球等技术细节。

然而，所有这些数据都来自模型训练结束之前的内容，这意味着它无法准确回答某位球员在当前正在进行的比赛中的发球表现如何。因此，如果要评估这一点，一种方法是构建并检索球员当前的比赛统计数据。这些统计信息可以粘贴到上下文窗口中，然后发送给AI模型本身。例如，佩古拉的上一次发球时速为97英里，并且是一个Ace球（直接得分）。

现在，我们给模型提供了一个立足点以及当前比赛中发生的事件作为背景。但是像发球速度、Ace球这样的统计数据，实际上是基于结果的统计。它们描述了发球的结果，但并没有太多关于球员如何移动以产生这些结果的信息。因此，即使动作不美观的发球也可能成为Ace球——相信我，我对此有切身体会。

为了获得更好的回答，为什么不向AI模型展示一段视频片段呢？这段视频可以与其他所有数据一起输入。现在，模型会报告说抛球看起来有点高，膝盖弯曲度可能过大。但这仍然受限于非专业模型能从视频帧中识别出的内容。如果没有这些API，模型的通用知识就会变得非常过时。

上下文窗口中的粘贴统计数据仅描述结果。观看部分视频只能给出一个粗略的印象，而不是我们可以使用的精确测量值。因此，AI模型缺少的是与同时测量所有这些信息上下文的系统的连接。我们可以称之为API。让我们谈谈这个API暴露了什么内容。

我们在2026年美国网球公开赛的所有254场单打比赛中引入了发球质量评分。在比赛期间，球场边的摄像头追踪球、球拍以及球员身体上的21个关节在发球时的动作。在整个锦标赛期间，这产生了一十亿——是的，各位，整整一十亿个数据点。这是一大堆信息。

没有人会阅读所有这些内容，语言模型也不行。相反，专门的服务将这些流处理成两种不同的分数。第一个是效率得分。这个评分基于生物力学，涉及膝盖弯曲程度、髋部和肩部的分离情况以及其他机械性的网球动作。

第二个分数是有效性得分，即结果评分。这是我们之前粘贴的统计数据，如速度、落点以及球是否进入了难以回击的区域。如果我们将这两个不同的元素结合起来，就会得到这里的综合质量评分。

这是使用我们所谓的IBM Bob开发的，用于识别和加权对发球影响最大的指标，并基于我们在生物力学和动力链研究中发现的哪些动作最能贡献于发球效果的结论。这一切都很巧妙，但为什么所有这些评分都需要在这个API或专门服务中进行？

我们不能直接把数据发送给AI模型，让它自己计算分数吗？如果我们仔细想想，我们有21个不同的追踪点，每个点有三个坐标值，并且每秒采样50次。如果我在这里做数学计算，这意味着每一秒钟有超过3,000个不同的数字，而在整场比赛期间则有数百万个位置值。

这是一个巨大的上下文窗口，包含大约一百万甚至更多的Token（词元）。虽然单场比赛的原始数据可能勉强能装下，但即使可以，大型语言模型本质上是一个下一个Token预测器。批量数字运算——比如从坐标流中驱动关节角度计算——并不是它的强项。

因此，所有这些背后的后端服务和API本质上是在获取我们所谓的“摄像头点位”，然后深入到关节数据，进而转化为数据的生物力学方面，最终得到我们所称的评分。当数据到达我们的语言模型时，它实际上只是几千字节的结构化数据，足够小到可以放入上下文窗口，并且有意义到可以进行推理。

这就是LLM（大型语言模型）介入我们数据的地方。我可以提出的一个问题是：“佩古拉的发球质量在本局上升，是因为她提供了更稳定的抛球。”模型最终会做它真正擅长的那部分工作：将所有这些不同的测量值转化为一段可读的句子，以回应用户的提示。

这是一个非常具体的流程。在这个美国公开赛的例子中，当球迷向赛事应用提问时就会发生API调用。问题可能是“佩古拉今天的发球状态如何？”为此，这里使用了一个智能体（Agent）来回答这类问题。下一步是将模型交给一组工具列表。

这些工具有其上下文中的定义。每个工具都有一个名称、描述以及它接受的参数，而ServeQuality API将作为这些工具之一出现。当模型决定需要数据时，它会输出一个结构化请求，该请求来自我们所谓的“控制框架（Harness）”。

这个工具集随后会调用 API，例如查询“高质量发球”这一要素。一旦发出请求，API 会将数据返回至模型的上下文中，使模型能够基于所有已有信息进行推理。这一过程可以形成持续循环：模型会判断自身缺失的信息，可能请求另一个工具，读取结果后决定是否已有足够信息来回答问题。若不足够，它将在代理循环中再次运行；但这次可能会调用不同的 API 或选择不同的工具。当信息充足时，模型便会在该循环中生成答案。因此，“拥有工具和目标的模型”基本构成了此处代理的工作定义。

我谈了很多关于网球的内容，但将 AI 代理与 API 访问相结合的相同工作流程随处可见。例如，调查生产环境故障的代理可能会从监控 API 和日志 API 中获取数据。专用系统承担所有的繁重工作和处理任务，而 API 则是向模型移交控制权的关键环节。

那么为何要费心使用 API？这主要涉及劳动分工。专用服务负责测量和计算大型语言模型难以独立处理的信息，而模型则对这些结果进行推理，将其转化为人类可以采取行动的形式。无论是网球爱好者还是待命工程师，都能据此采取行动。