本文探讨了AI代理的五个要素：狭窄的上下文、简单的工具、详细的提示、适合用例的模型和集中管理。强调了Spring AI框架在简化AI集成方面的作用，以及AI原生平台在管理和扩展AI应用的重要性。
译自：5 Factors for Predictable Autonomy With Agentic AI
作者：Brian Friedman, Jonathan Eyler-Werve
这是“交付 Agentic AI”系列的第二部分。 阅读第 1 部分。
之前，我们探讨了 AI 计划失败的原因，并描述了一个虚构的、在全国范围内拥有连锁店的汽车修理店，它即将开展其首个 agentic AI 项目。我们虚构的连锁店希望加入已经从其 AI 工作中看到投资回报率 (ROI) 的 5% 企业的行列，因此它已决定创建一个代理，该代理将自动化一项商店经理每周要花费四个小时的任务。接下来，我们将深入研究以可预测的自主性运行的 AI 代理的五个要素。
通过汽车修理店连锁店的例子，我们将探索一种解决方案，该解决方案每年每个商店可以节省超过 200 小时的管理时间，并且可以在 12 周或更短的时间内推出。我们将通过按时、按预算、按质量发布具有以下特点的解决方案来坚定地插上我们的投资回报率旗帜：
- 狭窄的上下文
- 简单的工具
- 详细的提示
- 适合用例的正确模型
- 集中管理 AI 资产、连接和策略
狭窄的上下文
对于 agentic AI 来说，上下文就是一切。它定义了模型必须知道的所有为我们量身定制的内容，才能回答问题。例如，一些国际公司可能会选择按照其服务的所有国家/地区的最高法律标准运营，以避免全面出现问题。询问公司在特定国家/地区的代理应该做什么，不应仅依赖于普遍接受的地理知识；而应依赖于给定司法管辖区的公共和内部政策的组合。
在我们的汽车修理店连锁店的场景中，上下文再狭窄不过了。我们对服务单感兴趣。它们记录了每一次送车、每一次取车、每一次执行的服务以及收集到的调查回复。还有大量的其他信息，例如零件编号和服务代码，但鉴于我们当前的任务是将服务单中捕获的调查数据转换为可报告的数据源，因此其中很多信息都是无用的。
因此，我们希望描述尽可能少的字段供我们的 AI 代理筛选，因为我们希望精确地描述每个字段；在这种情况下，我们聘请 AI 代理不是为了他们的创造力。
简单的工具
我们将在服务单系统中定义一个查询，以获取送车日期、取车日期、执行的特定服务和调查回复。我们将允许我们的 AI 代理通过视图或存储过程访问该查询，并且我们将通过称为工具的 AI 编程结构公开它。
我们不会简单地将模型释放到我们的数据库中，让它“弄清楚我们需要什么”。我们将为它提供解决问题所需的确切数据形状，并且我们将为它提供一种非常简单的执行方式：要么获取在两个特定日期之间更改为“已关闭”的所有内容，要么获取本周更改为“已关闭”的所有内容。
我们将使用 Spring AI 和模型上下文协议 (MCP) 将我们的代理快速连接到我们的上下文中。Spring AI 将确保我们的代码允许模型交互的灵活性，而 MCP 将确保在需要时调用我们的工具，并且当模型考虑我们用户的提示时，我们的上下文会流入模型。Spring AI 的卓越之处在于，我上面描述的大部分内容都是使用人类语言而不是代码实现的。
工具是开发人员提供的代码块，AI 可以使用它们。开发人员使用简单的英语描述行为，然后 LLM 使用这些描述来了解如何使用该工具。这确实是一种卓越的范式转变，开发人员 90% 的编码工作都被帮助 LLM 正确使用代码的文档所取代，只剩下 10% 的剩余代码需要实际编写。
Spring AI 混合了自然语言和编程接口。（来源：Broadcom 旗下的 VMware）
我再怎么强调上面代码片段所展示的概念对软件开发来说有多么具有革命性都不为过。工具描述向其使用者（AI）描述了如何使用它以及如何理解其响应。早在 2023 年，我们就不得不编写数十行（如果不是数百行）代码来协调两个不相关系统之间的交互。
仅仅不到两年后的今天，我们就可以使用自然语言来指示 AI 如何为我们协调这些交互。我们所要做的就是提供在调用工具时在后台调用的函数。但是，必须将所有这些函数调用拼接在一起才能产生有意义的结果，这就是代理及其系统提示成为粘合剂的地方。
详细的提示
当实例化代理时（当托管代理的服务启动时），模型首先想知道的是此代理的系统提示是什么。换句话说，该代理的任务和目的是什么？
在系统提示中，我们确切地告诉代理它的工作是什么。我们可以确切地告诉我们的代理它可以执行哪些任务，甚至在什么情况下可以执行。也许在营业时间内启动的任务应该安排在非营业时间窗口进行处理。
这些事情可以非常快速地由普通人烘焙到提示中。无需编码。系统提示是简单的英语，就像我们审查过的工具描述一样。以下代码段来自用于配置我们的 Spring 应用程序的属性文件：
驱动受约束的客户满意度数据分析师代理行为的系统提示。（来源：Broadcom 旗下的 VMware）
想想这里消除了多少行代码，这些代码用于根据一天中的时间和一周中的哪一天来确定是安排进程还是立即运行它。这不仅仅是该逻辑的实现，而是它的封装和集成，以便它可以与其他服务交互。只要存在用于确定当前日期的工具和用于安排任务的另一个工具，就可以通过在代理提示中描述来完全发明这种能力。
通过非常明确地告诉我们的代理应该做什么以及何时使用它拥有的工具，我们可以开始获得我们期望从 AI 获得的 可预测的自主性的回报。在这种情况下，回报的形式是每个商店每年超过 200 小时的经理工作时间。对于我们的第一枪来说，还不错。
适合用例的正确模型
简化的模型选择决策树（仅用于说明目的）。（来源：Broadcom 旗下的 VMware）
诚然，汽车修理店的例子并没有为围绕模型选择的故事情节提供太多内容。每个企业首先也是最重要的问题应该是：我们是否愿意使用公共模型？考虑到我们必须将我们的狭窄上下文发送到这些模型；每次我们询问有关服务单分组的问题时，我们都必须通过线路将数据发送到模型进行评估。也许我们的汽车连锁店不太关心当前数据集的内容，但随着时间的推移，私有 AI 的重要性可能会增加。
这就是为什么我们将我们的模型交互包装在像 Spring AI 这样的框架中——更改模型提供商的业务决策不应需要对解决方案进行大规模更改。但是，如果没有像 Spring AI 这样的层介于开发人员和模型之间，就会发生这种情况。
如果我们要处理调度而不是调查数据，模型选择将会有更多有趣的故事情节。调度需要推理，因此推理模型将比通用 LLM 有效得多。但是，当要求 LLM 使用在为该任务创建的视图中清晰且容易获得的字段以给定格式准备批处理文件时，不需要太多精明才能做出正确的决定。只要 MCP 在他们的技巧包中，任何主要的公共或私有参与者都可以轻松处理该用例。
第二天是最长的一天
早些时候，我提到了 Spring AI 以隔离开发人员，使其免受与一个或多个模型交互的复杂性影响。与模型交互只是我们在运营化这项首次 agentic 工作时必须满足的需求的冰山一角。正如 Tanzu 的 AI Native 报告详细揭示的那样（此处提供），成功运营 AI 需要完成的工作不胜枚举。我们需要能够在许多方面应用策略：允许哪些模型以及允许哪些团队？如何颁发令牌？如何处理配额和退款？如何轮换工具和 MCP 服务器的凭据？如何限制对 MCP 服务的访问，使其仅限于部分使用者？我们如何管理部署并证明哪些版本的哪些模型可以安全使用？
我们需要完成所有这些以及更多的事情，并且我们需要以可重复的方式，为多个环境完成这些事情，然后才能看到生产的光芒。
能够管理上述内容非常重要，因为随着事物的演变，我们的系统将会是什么样子。AI 代理在底层技术和部署架构方面与微服务具有很大的对称性，但粒度更高。这些服务将更小，并且它们的任务将更加离散；微服务将被纳米服务所取代。我们的客户满意度分析代理就是一个纳米服务的例子。我们将保持该服务的规模较小，并专注于一件事，以便它以可预测的方式运行。
在我们的虚构汽车修理店的未来，将会有数百个（如果不是数千个）像这样的纳米服务，每个纳米服务都具有一组狭窄的职责和工具。我们服务的粒度的权衡将是其数量的增加。AI 原生解决方案从想法到生产的速度将既令人震惊又让人不知所措。如果我们想以可持续的方式大规模地做到这一点，我们将需要防护措施，而这正是 AInative 平台所提供的。
如果没有平台来管理所有这些，第二天就会变成第二个月，然后变成第二年，然后你才有机会站稳脚跟。麻省理工学院的论文，批评企业 AI 部署， 对此进行了量化。对于实际投入生产的 AI 工作，其中 67% 的工作使用供应商提供的 AI 资产管理解决方案。只有 22% 的成功系统是他们为管理 AI 集成问题而创建的。同样，独立研究 发现，大多数受访者 (82%) 认为 AI 平台对于扩展 AI 来说很重要或必不可少。
成功地设置自己以大规模交付 AI 应用程序
Agentic AI 是一件强大的事情，但陷阱很多。为了快速、安全地行动，同时交付价值，至关重要的是我们要减少要求 AI 为我们解决的问题空间。通过提供找到解决方案所需的 足够多 的信息，并通过简单的工具为我们的代理提供 足够多 的能力，我们可以最大限度地减少幻觉毒害我们的响应的机会。
同样，通过通过提示为每个代理制作职位描述，我们可以约束我们的代理的行为，限制他们可以访问的工具，并提供对其工作绩效的特定期望。
我们还了解到，并非所有模型都是平等创建的，并且用例应决定我们选择的模型。但也许最关键的是，我们已经了解到，当我们使用 AI 原生平台来管理这些问题而不是尝试推出我们自己的 AI 集成平台时，我们可以将成功部署的几率提高一倍。
