[译苑雅集Vol. 50]AI智能代理三层架构：借鉴API设计的可扩展系统模式
随着AI智能代理系统逐步嵌入企业架构，一个熟悉的设计模式重新浮现——三层架构。本文类比API体系中的系统、流程与体验API，深入解析工具型代理、规划型代理和工作流代理如何协同构建一个可理解、可维护、可扩展的智能系统架构。
作者：Christian Posta
时间：
原文：https://blog.christianposta.com/apis-and-ai-agents-follow-the-same-layered-pattern/
随着企业组织对 API 的采纳日趋成熟，一种自然的架构模式逐渐浮现：通过“分层”来管理复杂性。而我们也在 AI 智能体（agent）架构中看到了类似趋势。应对团队边界、业务流程、通信模式等问题时，复杂性会迅速上升。以基础组件为起点，再逐步引入可复用性、封装性以及职责分离等理念，有助于降低认知负担。
MuleSoft 推广的三层 API 分类体系，如今已成为业界标准；与此同时，AI 从业者也正在趋同于一种非常相似的三层智能体架构。这种高度的相似性引发了一个耐人寻味的问题：是否存在某种普适原则，支配着我们如何组织智能系统？
第一层：系统 API 与工具型智能体（Tool Agents）
系统 API 构成基础层，提供对核心系统（如数据库、ERP 平台或传统应用）的直接访问。它们处理基本的增删改查（CRUD）操作，屏蔽底层数据源的复杂性。
工具型智能体在 AI 系统中扮演着相同的架构角色：它们是简单的、反应式的智能体，能够提供对特定能力的直接访问。比如计算器智能体或网页搜索智能体，它们在没有记忆或规划的前提下，依据输入立即给出受限的输出。
工具型智能体通常也更贴近用户，往往是由用户直接触发，并在用户的身份上下文中执行操作。因此，它们非常适用于那些简单、交互性强且天然具备监督机制的使用场景。
这两者本质上都承担着“基础设施”的角色。系统 API 成为可复用的构建模块，避免每个新应用都重复开发数据库连接功能；工具型智能体则成为可靠、可测试的组件，避免每个 AI 流程都要从头实现基础功能。
第二层：流程 API 与规划型智能体（Planner Agents）
流程 API 将多个系统 API 组合起来，以实现具体的业务逻辑。比如，它可能会整合客户信息、订单数据和支付记录，形成一个统一的订单处理流程。在这一层，业务规则得以体现，简单组件被整合为具有业务意义的能力。
规划型智能体在 AI 系统中承担着同样的编排角色。它们维护着对世界的内部模型，拥有记忆，能够规划行动序列，并将复杂目标拆解为可管理的子任务。一个规划型智能体可能会协调多个工具型智能体，先调用搜索工具，再调用摘要工具，最后使用格式化工具，来完成一个调研任务。
这一中间层正是业务价值真正诞生的地方。它足够复杂，可以支持有意义的工作流；但又足够简洁，便于维护。流程 API 与规划型智能体都在解决同一个根本性问题：如何在不造成维护混乱的前提下，将简单功能组合成复杂行为？
虽然规划型智能体比工具型智能体更具自主性，但它们通常仍处于人类监督之下（即“人类在环”Human in the Loop，简称 HItL）。在实际应用中，这意味着规划智能体可以提出一组行动计划，但在执行前，尤其是在高风险或受监管的场景中，往往仍需获得用户的批准。
第三层：体验 API 与工作流智能体（Workflow Agents）
体验 API 处于架构的顶层，负责为具体用户提供定制化的数据与流程支持，如移动应用、网页门户或合作方的后台系统。它们要应对的是多渠道现实：不同渠道对数据格式、性能和安全模型的需求各不相同。此外，体验 API 也承担着业务流程的协调和编排职责。
在智能体系统中，工作流智能体就是体验 API 的对应角色。它们负责协调、管理和监督那些多步骤、复杂的任务流程，这些流程可能涉及多个工具、API 调用，甚至是其他子智能体。当一个任务无法被单一工具型智能体独立完成时，工作流智能体就派上用场了。
这类智能体会根据实时反馈动态规划并调整流程，将子任务委派给专门的智能体，维护中间状态，并在必要时暂停以等待人类干预。从这个角度来看，它们更像是一位交响乐指挥：自己并不直接“演奏”，但确保所有组件协同一致。这使得它们尤其适用于那些需要持续运行、有状态的工作流程，如保险理赔、自动化事件响应或复杂的客户入职流程——这些流程既需要推理判断，也需在人类监督下进行阶段性决策。
由于它们往往代表“间接用户”执行复杂任务，甚至可以由系统事件触发，而非直接由用户输入，因此工作流智能体需要独立的身份与访问权限边界。尽管它们可以自主运作，但在多数组织的实际操作中，人类仍是其中一环：用户审阅结果、批准关键步骤，或在系统置信度较低时及时介入。
为什么“三层架构”屡屡出现
我们之所以不断回归分层架构，并非偶然，而是因为这种架构模式与我们管理复杂性的方式在认知、组织与技术层面上高度契合。分层能够通过将功能模块划分为可理解的抽象单元，从而降低认知负担。它强化了关注点的分离，使系统更易于演进、理解和调试。它促进了复用：下层提供稳定的构建模块，上层可以将其组合为更丰富的行为。分层也契合团队的扩展方式：一个团队可以专注于基础设施，另一个负责编排逻辑，第三个则专注于用户体验。正如分层架构帮助我们构建网络、操作系统和组织结构一样，它如今也正在塑造我们构建 API 和 AI 智能体的方式。这是一种普适性的策略，旨在让复杂系统更易理解、更具韧性并具备可扩展性。
站在巨人的肩膀上
随着 AI 智能体日益深入企业系统的核心，我们正在重演历史。正是这种曾经为 API 带来清晰与可扩展性的分层方法，如今也帮助我们管理智能系统所带来的复杂性。值得注意的是，我们并没有用 AI 智能体来取代原有的 API 基础设施，而是在其之上进行构建。
工具型智能体调用系统 API，规划型智能体编排现有的流程 API，工作流智能体则运行在支持客户前端体验的体验 API 之上。这些层级之间不仅仅是结构上的映射，它们更是在彼此基础上的延展。正是这种结构上的一致性，使我们能够扩展已有架构以支持智能行为，而无需重新发明整个系统。