02 · AI、Agent、Agent System、Agent Platform 之间是什么关系？ - Architecture Relationships

所属知识库：Agent 全栈技术地图
所属领域：00 · Agent 技术体系是什么？ - Overview
文档类型：技术架构与关系研究
版本：v1.0
更新日期：2026 年 10 月 26 日
核心问题：AI、Agent、Agent System 和 Agent Platform 如何相互依赖、组合与协作？它们在完整软件架构中分别承担什么职责？

一、研究概述

AI、Agent、Agent System 和 Agent Platform 是 Agent 技术体系中的四个核心研究领域。

它们之间存在紧密的技术联系，但并不是四个严格嵌套的软件组件，也不是所有 Agent 应用都必须经历的四个开发阶段。

从技术研究的角度，可以将它们组织为一条由基础能力向软件应用扩展的路径：

AI → Agent → Agent System → Agent Platform

其中，AI 提供智能能力基础；Agent 将智能能力与任务目标、决策和行动机制结合；Agent System 将 Agent 与其他软件组件组织为能够完成任务的完整系统；Agent Platform 则提供通用的 Agent 创建、配置、执行和管理能力。

不过，这条路径主要表达的是研究范围和工程抽象的递进关系，并不能完整描述它们在实际软件中的组织方式。

例如：

• 一个 Agent 可以直接调用远程 AI 模型，而不需要自行部署模型。
• 一个 Agent System 可以只包含一个 Agent，也可以包含多个 Agent。
• 一个 Agent System 可以直接面向用户提供服务，而不依赖独立的 Agent Platform。
• 一个 Agent Platform 可以管理多个 Agent System，也可以直接承载 Agent 的运行。
• 一个 Agent Platform 本身也可能包含用于管理、开发或运营的 Agent。

因此，要理解四者之间的关系，需要分别从能力依赖、架构组成、运行交互和平台服务四个角度进行分析。

二、能力依赖关系：智能能力如何转化为任务执行能力？

能力依赖关系描述的是：一个技术对象需要利用哪些能力，才能实现自身的功能。

对于现代基于大语言模型的 Agent 应用，可以从以下路径理解：

AI 模型
   │
   │ 提供语言理解、生成、推理等能力
   ▼
Agent
   │
   │ 将模型能力用于目标判断与行动
   ▼
Agent System
   │
   │ 提供任务执行所需的软件环境与工程能力
   ▼
Agent 应用
   │
   │ 根据需要复用通用平台能力
   ▼
Agent Platform

需要注意，这张图描述的是能力扩展的研究顺序，并不是实际运行时的数据流，也不表示 Agent Platform 一定是 Agent 应用的下游组件。

2.1 AI 与 Agent 的关系

AI 模型是现代 LLM Agent 的重要能力来源。

模型能够根据输入生成输出，例如分析问题、整理信息、生成文本或提出下一步行动建议。

Agent 则将这些模型能力组织到具体任务之中。

例如，当用户要求研究某个行业时，模型可以分析用户的研究需求，而 Agent 可以根据分析结果决定调用搜索工具、获取资料、继续分析或输出报告。

在这个过程中，模型负责提供智能计算能力，Agent 的执行机制负责组织任务流程和实际行动。

二者的主要关系是：

模型提供能力，Agent 使用能力。

但这种关系存在两个需要明确的边界。

首先，Agent 不一定使用大语言模型。传统 Agent 可以通过规则、搜索算法或其他决策机制实现。

其次，模型调用不一定构成 Agent。一个直接调用模型生成摘要的程序，可以是 AI 应用，但不一定具有 Agent 的目标驱动与行动决策机制。

2.2 Agent 与 Agent System 的关系

Agent 描述智能执行单元，Agent System 描述支持任务完成的完整软件系统。

一个 Agent 可以定义自己的目标、指令、工具和行为逻辑，但要实际运行，仍然需要相应的软件执行机制。

例如，Agent 需要通过模型客户端访问模型服务，通过工具接口访问外部资源，通过运行机制执行工具调用，并通过状态管理保存必要的信息。

这些运行机制与其他系统组件共同构成 Agent System。

因此：

Agent 是 Agent System 中的重要执行实体，但 Agent System 的范围通常大于单个 Agent 的定义与行为逻辑。

这里的“范围更大”指研究对象和系统职责更广，并不意味着 Agent 必须作为独立进程或服务存在。

在实际开发中，一个简单的 Agent System 可能只是一个包含 Agent 执行逻辑、模型调用和工具接口的程序。

而一个复杂的生产级 Agent System，可能包含独立的后端服务、任务队列、数据库、执行环境、监控系统和多个 Agent。

2.3 Agent System 与 Agent Platform 的关系

Agent System 通常围绕具体业务目标组织技术能力。

Agent Platform 则将不同 Agent 应用可能重复需要的功能抽象为通用服务。

例如，一个自动生成研究报告的 Agent System，需要模型调用、任务执行、资料存储和报告输出等能力。

如果需要同时运行多个不同类型的研究系统，并允许用户创建 Agent、修改配置、管理任务、查看执行记录，就可以考虑构建 Agent Platform。

因此：

Agent System 关注如何完成具体任务，Agent Platform 关注如何通用化地构建、运行和管理 Agent 及其系统。

二者并不是简单的上下级包含关系。

一个 Agent Platform 可以为多个 Agent System 提供服务，也可以直接承载它们的执行过程。

同样，一个 Agent System 可以完全独立运行，不需要专门的平台。

三、架构组成关系：四者如何组织成完整的软件架构？

能力依赖关系说明技术能力如何被利用，而架构组成关系需要进一步回答：这些能力在软件中如何组织？

首先，需要区分三个概念：

逻辑组件：系统设计中承担某种职责的部分，例如 Agent Runtime、模型服务或工具执行器。

软件实现：实现这些职责的具体代码、模块、进程或服务。

部署结构：这些软件运行在什么设备、容器、服务器或云服务中。

三者不一定一一对应。

例如，一个 Agent Runtime 在逻辑上负责执行循环和工具调用，但实际实现中可能只是某个 Python 应用内部的一个模块。

同样，模型服务可以是本地部署的模型，也可以是远程 API。

3.1 一个典型的 Agent 软件架构

以下是一个简化的参考架构：

                  用户 / 外部系统
                         │
                         ▼
                 应用接口与交互层
                         │
                         ▼
                  Agent System
┌─────────────────────────────────────────────┐
│                                             │
│              任务管理与编排                 │
│                     │                       │
│                     ▼                       │
│              Agent Runtime                  │
│                     │                       │
│                     ▼                       │
│                   Agent                     │
│                                             │
│     ┌────────────┬────────────┐             │
│     │            │            │             │
│     ▼            ▼            ▼             │
│  模型访问      工具调用     上下文与状态      │
│     │            │            │             │
└─────┼────────────┼────────────┼─────────────┘
      │            │            │
      ▼            ▼            ▼
   AI 模型      外部服务      数据与存储

这张图表达的是一种逻辑关系：

Agent System 负责承载完整任务执行；Agent Runtime 负责驱动 Agent；Agent 在执行过程中使用模型、工具和上下文；底层模型、外部服务和数据存储可以位于系统内部，也可以由外部服务提供。

需要特别注意，图中的 Agent 与 Agent Runtime 是概念上的职责区分。在实际框架中，两者可能被封装在同一个对象中。

此外，并不是每个 Agent System 都必须包含独立的任务编排服务。对于简单系统，Agent Runtime 本身就可以承担主要的任务控制工作。

3.2 Agent Platform 在架构中的位置

当系统进一步平台化时，Agent Platform 通常提供跨应用复用的管理与运行能力。

可以通过以下参考架构理解：

                     用户 / 开发者
                           │
                           ▼
                    Agent Platform
┌───────────────────────────────────────────────┐
│                                               │
│                平台管理能力                   │
│                                               │
│   Agent 创建 / 配置 / 注册 / 权限 / 版本       │
│                                               │
├───────────────────────────────────────────────┤
│                                               │
│                平台运行能力                   │
│                                               │
│   任务调度 / Runtime / 工具 / 模型 / 状态      │
│                                               │
├───────────────────────────────────────────────┤
│                                               │
│               Agent 应用与系统                │
│                                               │
│    研究系统      编程系统      数据分析系统    │
│                                               │
└───────────────────────────────────────────────┘
                           │
                           ▼
                基础设施与外部资源

在这种模式中，Agent Platform 可以同时提供管理能力与运行能力。

但这只是一种参考架构。

另一种常见模式是，Agent Platform 只负责 Agent 的注册、配置、权限和监控，而实际 Agent System 运行在独立的执行环境中。

因此，平台与系统之间可能存在多种组织方式，不能简单理解为所有 Agent System 都必须部署在平台内部。

四、运行交互关系：一个任务如何经过整个技术体系？

为了理解实际运行过程，可以使用一个行业研究任务作为案例。

假设用户希望生成一份新能源汽车行业研究报告。

4.1 用户提交任务

用户通过网页、应用程序或 API 提交研究需求。

任务可能包含研究主题、时间范围、输出格式和其他约束。

如果系统使用 Agent Platform，平台可能负责用户身份认证、工作空间选择、Agent 配置读取和任务创建。

如果没有独立平台，这些功能也可以直接由 Agent System 实现。

4.2 Agent System 接收并组织任务

Agent System 接收用户请求，创建任务记录，并准备执行环境。

系统可能需要加载 Agent 配置、选择模型、初始化上下文、获取工具权限，以及确定任务执行方式。

对于复杂任务，系统还可能将任务拆分为多个步骤，或分配给不同 Agent。

4.3 Agent 进行判断与行动

Agent 根据研究目标和当前信息决定下一步操作。

例如，Agent 可能先判断需要收集哪些行业数据，然后调用搜索工具。

工具返回资料后，Agent 可以进一步分析信息，并决定是否需要继续检索。

在这一过程中，Agent 的判断可能依赖 AI 模型。

4.4 AI 模型提供智能计算能力

当 Agent 需要理解信息、分析资料或生成文本时，系统向 AI 模型发送请求。

模型接收指令、上下文和相关数据，返回分析结果、文本内容或工具调用建议。

模型通常不直接负责整个任务的生命周期管理，也不必知道 Agent System 的全部内部架构。

4.5 系统管理执行过程

Agent System 负责处理模型调用和工具执行的实际结果。

例如，系统需要记录任务状态、保存必要的中间结果、处理工具异常、限制执行次数，并判断任务是否完成。

如果执行过程需要人工审核，系统还需要支持暂停、确认和恢复。

4.6 返回任务结果

当研究任务完成后，系统将结果返回给用户。

如果使用 Agent Platform，平台还可能提供任务历史、执行记录、报告管理、资源统计和后续重新运行等功能。

由此可以看出：

用户任务通常由 Agent System 承接，Agent 负责其中的智能决策与行动，AI 模型提供智能能力，Agent Platform 则可以提供通用的管理与运行支持。

五、平台服务关系：Agent Platform 如何支持 Agent System？

Agent Platform 与 Agent System 之间的关系，可以进一步从服务方式进行区分。

5.1 平台提供构建能力

平台提供 Agent 创建、配置、注册和版本管理等功能。

开发者或用户可以通过平台定义 Agent 的角色、模型、工具、指令和其他配置。

平台保存这些定义，并支持后续修改和复用。

5.2 平台提供运行能力

平台可以提供统一的 Agent Runtime、任务调度、模型访问、工具执行和状态管理能力。

不同 Agent 可以共享这些运行服务，而不必各自实现完整的基础设施。

5.3 平台提供管理能力

平台可以统一管理用户、工作空间、权限、资源配额、日志、监控和执行记录。

这些能力有助于支持多个 Agent 应用的长期运行和维护。

5.4 平台提供集成能力

平台可以通过 API、SDK、插件或其他集成机制，为外部应用提供 Agent 能力。

例如，外部业务系统可以调用平台中的某个 Agent，提交任务并获取结果。

5.5 平台与系统的三种典型关系

关系模式	说明	适用情况
独立运行	Agent System 不依赖专门的 Agent Platform	单一应用、原型验证、专用系统
平台承载	Agent Platform 提供 Agent System 的运行环境和管理能力	多 Agent 应用、统一运行与管理
平台管理	Agent System 独立运行，Agent Platform 通过接口进行注册、配置、监控或治理	分布式系统、已有应用集成

实际产品可能同时采用多种模式。

六、Agent Runtime、Agent Harness 和 Agent Framework 处于什么位置？

在理解 Agent 与 Agent System 的关系时，还需要明确几个常见的技术概念。

这些概念并不是与 AI、Agent、Agent System、Agent Platform 完全平级的研究领域，而是主要涉及 Agent 的开发与运行机制。

6.1 Agent Runtime：执行环境与运行机制

Agent Runtime 负责支持 Agent 的实际执行。

在不同技术框架中，它可能承担以下职责：

• 初始化 Agent 运行实例；
• 调用模型并处理响应；
• 执行工具调用；
• 管理执行循环；
• 维护运行状态；
• 处理终止条件与异常。

Runtime 主要回答：

Agent 的行为逻辑如何被真正执行？

因此，Runtime 通常属于 Agent System 的核心运行机制。

6.2 Agent Harness：围绕 Agent 的执行与控制机制

Agent Harness 通常用于描述围绕模型或 Agent 构建的执行控制框架。

它可能涉及模型调用、上下文管理、工具执行、反馈处理、任务循环、权限限制和执行终止等机制。

Harness 与 Runtime 的概念存在明显交叉。

在某些技术项目中，Harness 更强调围绕模型构建的控制与工具使用机制；Runtime 更强调 Agent 的执行环境和生命周期。

但这不是所有技术框架都遵循的统一划分。

因此，在具体研究中，应当结合项目实现分析二者的职责，而不是强行将它们划分为两个完全独立的架构层。

6.3 Agent Framework：开发框架

Agent Framework 为开发者提供构建 Agent 的程序接口、组件和抽象。

例如，开发框架可能提供 Agent 定义、模型适配、工具注册、执行循环、状态管理和工作流编排等功能。

Framework 主要回答：

开发者如何通过代码构建 Agent 和 Agent System？

一个 Agent Framework 可以包含 Runtime 或 Harness 的实现，也可以依赖其他执行服务。

6.4 三者在技术体系中的位置

概念	核心职责	主要关联领域
Agent Runtime	承载和执行 Agent	Agent System
Agent Harness	组织和控制 Agent 的执行过程	Agent / Agent System
Agent Framework	提供 Agent 开发抽象和编程组件	Agent / Agent System
Agent Platform	提供通用构建、运行和管理能力	Agent Platform

在本知识库的技术分类中：

Agent Runtime 与 Agent Harness 主要进入 Agent System → L4 · Agent Engine 研究。

Agent Framework 则可以在 Agent → Development & Practice 和 Agent System → Technical Architecture 中分别研究其开发使用方式与架构实现。

如果涉及统一管理多个 Agent 的运行环境，还需要在 Agent Platform → P2 · Execution Plane 和 P5 · Runtime Management 中研究相应的平台能力。

七、四者之间是否存在严格的包含关系？

这是理解整个技术体系时最容易出现误解的问题。

7.1 AI 不等于 Agent 的下层软件组件

AI 是一个广泛的技术领域，而不是一个固定的软件架构层。

Agent 可以调用 AI 模型，但不能因此认为整个 AI 领域都包含在 Agent 内部。

在实际软件中，AI 模型可能作为远程服务运行，与 Agent System 通过 API 通信。

7.2 Agent 不一定是独立的软件服务

Agent 是一种智能执行实体，但在具体实现中，它可能只是某个程序中的对象、配置与执行逻辑。

因此，不能仅凭是否存在独立的 Agent 进程判断系统是否具有 Agent。

7.3 Agent System 不一定包含多个 Agent

Agent System 的核心特征是具备支持 Agent 完成任务的软件系统边界。

单个 Agent 加上必要的执行环境、工具和应用接口，也可以构成 Agent System。

多个 Agent 之间的协作是系统架构的一种选择，而不是 Agent System 的必要条件。

7.4 Agent Platform 不一定包含所有 Agent System

Agent Platform 可以直接承载 Agent System，也可以只提供控制、管理或集成能力。

例如，一个平台可以管理运行在不同服务器上的 Agent System，而不直接执行其中的全部任务。

因此，Agent Platform 与 Agent System 之间更适合用服务关系、管理关系和运行关系描述，而不是简单的物理包含关系。

八、如何从架构角度区分四个研究领域？

可以通过四个问题快速确定研究对象。

研究问题	对应领域
智能能力如何产生、调用和优化？	AI
Agent 如何理解目标、作出判断并采取行动？	Agent
Agent 如何在完整的软件环境中运行并完成任务？	Agent System
如何统一创建、配置、运行和管理不同 Agent？	Agent Platform

当一个技术问题同时涉及多个领域时，应当进一步区分它的研究视角。

例如，工具调用可以从三个角度研究：

AI 视角：模型如何生成工具调用请求？Function Calling 的接口和输出结构是什么？

Agent 视角：Agent 如何决定何时使用工具、选择哪个工具，并利用执行结果继续任务？

Agent System 视角：系统如何注册、执行、隔离和监控工具调用？如何处理权限、超时和失败？

如果进一步涉及工具的统一配置、共享和管理，则进入 Agent Platform 的研究范围。

同一项技术可以出现在多个领域，但每个领域关注的职责不同。

九、核心结论

AI、Agent、Agent System 和 Agent Platform 之间存在四种主要关系。

第一，能力依赖关系。 现代 LLM Agent 通常依赖 AI 模型提供智能能力，并将模型能力用于任务判断与行动。

第二，架构组成关系。 Agent 通常作为 Agent System 中的智能执行实体，与 Runtime、工具、模型服务、状态管理和其他软件组件共同完成任务。

第三，运行交互关系。 用户任务通过应用或系统进入执行流程，Agent 在运行机制支持下调用模型与工具，系统负责管理执行状态并交付结果。

第四，平台服务关系。 Agent Platform 可以为多个 Agent 或 Agent System 提供通用的创建、配置、执行、管理和治理能力。

因此：

AI 提供智能能力，Agent 组织智能行动，Agent System 承载完整任务执行，Agent Platform 提供通用构建与管理能力。

这是一种有助于理解技术职责的参考架构关系，而不是四个必须独立部署、严格嵌套的软件层级。

十、关联研究

关联文档	研究内容
01 · AI、Agent、Agent System、Agent Platform 有什么区别？ - Definitions	四个核心概念的定义与边界
03 · 整个 Agent 技术体系由什么构成？ - Technology Landscape	具体技术组件、纵向架构与横向工程能力
04 · 如何系统学习和研究 Agent 技术？ - Learning Roadmap	技术学习与实践路径
02 · Agent → A2 · Model	Agent 如何使用模型能力
02 · Agent → A7 · Tools	Agent 如何选择和使用工具
03 · Agent System → L3 · Model Services	系统如何接入和管理模型服务
03 · Agent System → L4 · Agent Engine	Agent Runtime、Harness 与执行机制
03 · Agent System → L5 · Orchestration & Collaboration	工作流与多 Agent 协作
04 · Agent Platform → P1 · Control Plane	平台控制与管理能力
04 · Agent Platform → P2 · Execution Plane	平台执行能力
04 · Agent Platform → P5 · Runtime Management	Agent 运行实例与生命周期管理
Q1 - 什么是 Agent Harness，跟 Agent System 有什么区别？	Harness 与完整系统的概念边界