AI 从业者则逐渐转向一种极其相似的三层代理分类法。两者之间的相似之处如此相似，以至于引发了一个关于我们如何组织智能系统的普遍原则的问题。
第一层：系统 API 和工具代理
系统 API位于基础层，提供对核心系统（例如数据库、ERP 平台或旧版应用程序）的直接访问。它们处理基本的 CRUD 操作，并抽象出底层数据源的复杂性。
工具代理在人工智能系统中占据着相同的架构位置：它们是简单的、反射性的代理，可以直接访问特定功能。与计算器代理或网络搜索代理类似，它们能够响应即时输入，并输出有限的结果，无需记忆或规划。
工具代理也倾向于与用户紧密合作。它们通常由用户直接触发，并在用户的身份上下文中运行。这使得它们非常适合简单、交互式且自然内置监督的用例。
两者都充当着各自生态系统的“管道”。系统 API 成为可重用的构建块，防止每个新应用程序重新创建数据库连接。工具代理成为可靠、可测试的组件，防止每个 AI 工作流重新实现基本功能。
第二层：流程 API 和规划代理
流程 API结合多个系统 API 来实现业务逻辑。它们可能会聚合来自不同来源的客户、订单和支付数据，以创建统一的订单处理工作流。这一层是业务规则的所在，简单的组件也在此转化为有意义的业务功能。
规划代理在人工智能系统中扮演着同样的协调角色。它们维护世界的内部模型、记忆、规划行动序列，并将复杂的目标分解为可管理的子任务。一个规划代理可能会协调多个工具代理，依次调用搜索代理、摘要代理和格式化代理来完成研究任务。
真正的商业价值诞生于这个中间层。它足够复杂，足以编码有意义的工作流，但又足够简单，易于维护。流程 API 和规划代理都解决了同一个根本挑战：如何将简单的功能组合成复杂的行为，而不会造成难以维护的混乱？
虽然规划代理比工具代理的运行更具自主性，但它们通常受到人工监督（人机在环 - HItL）。在实践中，这意味着规划代理可能会提出一个行动方案，但仍需等待用户批准才能执行，尤其是在高风险或受监管的环境中。
第三层：体验 API 和工作流代理
体验 API位于顶层，为特定消费者（例如移动应用、Web 门户和合作伙伴仪表板）定制数据和流程。它们处理不同渠道需要不同数据格式、不同性能特征和不同安全模型的复杂现实。体验 API 还能协调业务工作流程和编排。
工作流代理在代理系统中扮演着协调器的角色。它们管理复杂、多步骤流程的排序、协调和监督，这些流程可能涉及多个工具、API 调用甚至子代理。当单个工具代理无法可靠地完成一项任务时，这些代理尤其有用。
工作流代理会根据运行时反馈主动规划和调整工作流，将子任务委托给专门的代理，管理中间状态，并确定何时暂停以进行人工输入。从这个意义上讲，它们就像交响乐中的指挥：并非直接执行每个任务，而是确保所有组件协调一致。这使得它们非常适合长期运行、有状态的工作流，例如索赔处理、自动事件响应或复杂的客户入职——尤其是在这些流程既需要推理，又需要频繁的人工检查点时。
由于工作流代理通常代表间接用户执行复杂任务，甚至基于系统事件而非直接用户输入触发，因此它们需要拥有自己的身份和访问边界。虽然它们可以独立运作，但大多数组织都会首先安排人工参与：用户审核输出、批准关键步骤，或在信心不足时进行干预。
为什么三层结构不断出现
我们倾向于分层架构并非偶然，而是因为它们与我们在认知、组织和技术层面管理复杂性的方式相呼应。分层架构通过将功能分解为易于理解的抽象概念，从而减轻了精神负担。它们强制关注点分离，使系统更易于演进、推理和调试。它们促进了重用：较低层级提供稳定的构建块，较高层级可以将其组合成更丰富的行为。它们也与团队的扩展方式相一致：一个团队可以负责基础设施，另一个团队负责编排逻辑，另一个团队负责用户体验。正如分层架构帮助我们构建网络、操作系统和组织一样，它现在也塑造了我们构建 API 和 AI 代理的方式。这是一种使复杂系统易于理解、具有弹性和可扩展性的通用策略。
站在巨人的肩膀上
随着AI代理越来越深入地融入企业系统，我们见证了历史的重演。同样的分层方法不仅为API带来了清晰度和可扩展性，如今也帮助我们管理智能代理系统的复杂性。有趣的是，我们并非在替换API基础设施本身，而是在其之上构建AI代理。
工具代理调用系统 API。规划代理协调现有的流程 API。工作流代理基于与面向客户的应用程序相同的体验 API 运行。这些层不仅相互镜像，而且相互依存。这种一致性意味着我们可以扩展（而非彻底改造）我们的架构来支持智能行为。