01 · 什么是 Agent Platform？ - Definition & Boundaries
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：01 · Agent Platform 是什么？它如何工作？ - Fundamentals
文档类型：专题研究
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：什么是 Agent Platform？它的必要特征与判定边界是什么？它与 Agent、Agent System、Agent Harness、Agent Framework、Workflow Engine、AI Platform 及普通 Agent 应用有何关系？如何通过可检验的技术标准判断一个系统是否构成 Agent Platform？
专题导读
本篇属 Fundamentals。> 研究定位：本篇研究 Agent Platform 的定义、边界与判定方法。核心组件的逐项分析属于下一篇 Core Components；控制平面、执行平面、Registry 和 Builder 的实现属于 Technical Architecture；具体用户界面属于 Product Architecture。本篇提出的定义与分类是本知识库的工作定义与分析框架，不是声称行业已经形成唯一标准。
一、问题起点：为什么需要区分 Agent 应用、系统与平台？
一个开发者编写了能够搜索网页并回答问题的 Agent 程序，是否就拥有一个 Agent Platform？不一定。程序可能完整实现任务决策和工具调用，却仅服务于单一、固定的应用需求。另一个团队搭建了 Agent Runtime、任务队列、数据库、日志与审批系统，是否一定构成平台？也不一定：它可能是针对单个业务流程定制的 Agent System，尚未把创建、配置、运行与管理能力提供为可复用的服务。
平台化改变的不是 Agent 是否“更聪明”，而是 Agent 能力的提供方式和管理方式。平台把原本嵌入应用代码的 Agent 定义、模型与工具配置、版本、任务运行、权限和观测能力，抽象为多个使用者或多个业务场景可以通过稳定接口操作的对象。这使得“构建一次 Agent 应用”与“持续提供构建和管理 Agent 的能力”成为不同的工程问题。
Agent Platform 的研究应回答三个层次的问题：平台化的对象是什么；哪些能力必须可复用且可管理；使用者通过什么接口消费这些能力。 对它的判断不能仅凭产品名称、是否具有聊天窗口、是否支持多个 Agent、是否使用低代码界面或是否部署在云端。
二、Agent Platform 的工作定义
本知识库采用以下工作定义：
Agent Platform（智能体平台）是将 Agent 的定义、配置、运行与管理能力抽象为可复用服务，通过稳定的使用接口、明确的资源与权限边界以及可持续的生命周期管理，使开发者、团队或其他使用者能够创建、运行、观察和维护 Agent 的软件平台。
定义中的几个关键词具有不同的技术含义。
Agent 的定义与配置：平台需要把 Agent 视为可识别、可操作的对象，至少能够描述其任务职责、指令、模型或决策策略、可用工具及相关运行约束。具体实现可以是代码、声明式配置、数据库记录或可视化编辑结果，不要求必须具有拖拽式 Builder。
可复用服务：同一套平台能力可以服务不同 Agent 定义、任务或使用场景，而不是仅执行一段固定的业务脚本。可复用性不等于一定面向公众开放，也不等于必须支持多个租户。
稳定使用接口：使用者能够通过 API、SDK、命令行、配置接口或图形界面，按约定创建、调用或管理平台对象。界面不是必要条件，但可被使用的服务边界是平台成立的重要依据。
管理与生命周期：平台应能够区分 Agent 的定义、配置或版本与实际运行记录，并提供与目标场景相称的更新、权限、状态查询和运行管理能力。成熟平台通常进一步支持发布、回滚、审计、配额和成本归属，但这些不是所有最小平台都必须独立实现的模块。
资源与权限边界：平台应能明确“谁可以对哪个 Agent 做什么”“某次运行可使用哪些资源”。它可以复用外部身份系统或现有基础设施，但不能把所有安全与管理责任完全交给 Agent 自行遵守自然语言指令。
该定义强调平台的服务属性和管理属性，而不是具体技术栈。一个基于 Python 和数据库构建的内部 API 平台，可能满足定义；一个具有复杂聊天界面但只运行单一固定 Agent 的产品，可能不满足。
三、平台成立的必要特征与非必要特征
3.1 四项判定维度
为了把定义转化为可检查的标准，本篇采用四项判定维度。这四项是本知识库的分析准则，而非行业认证标准。
| 维度 | 核心问题 | 可检查的证据 | 常见误判 |
|---|---|---|---|
| P-A · Agent 对象化 | Agent 是否可被独立定义、识别和管理？ | Agent 定义对象、配置记录、标识符或声明式描述 | 把单一硬编码 Prompt 当成完整管理对象 |
| P-B · 能力服务化 | 创建、运行或管理能力是否通过约定接口供使用者复用？ | API、SDK、CLI、配置接口、可视化操作 | 把一次性脚本包装成网页就称为平台 |
| P-C · 运行可管理 | 能否区分定义与运行，并查询、控制或追踪执行？ | Run ID、执行状态、运行记录、取消或管理接口 | 只有“发送消息 - 返回回答”，没有可管理运行对象 |
| P-D · 资源与责任边界 | 是否有可执行的权限、资源或管理边界？ | 身份与权限规则、资源限制、审计记录或外部治理集成 | 仅靠 Prompt 告诉 Agent 不要越权 |
判断方法：如果四项维度都能找到与目标场景相称的实现证据，可以将其作为 Agent Platform 研究；如果只满足部分维度，更准确的称呼可能是 Agent 应用、Agent Framework、Agent Runtime 或 Agent System。不能将这个判定表理解为必须采购四个独立产品或建立四组微服务。
3.2 常见但非必要的能力
可视化 Agent Builder、多租户、Agent Marketplace、自动扩缩容、多 Agent 编排、独立控制平面、独立执行集群、模型训练和私有化部署，都不是 Agent Platform 的定义性必要条件。它们可以成为平台的能力、架构选择或产品差异，但不能单独作为平台身份的充分证据。
例如，只有 API 而没有图形界面的开发者平台，可以成立；支持多个 Agent 的定制研究应用，可能仍只是应用；单租户的企业内部平台也可能成立。是否具有“平台性”，取决于 Agent 能力是否被稳定地对象化、服务化和管理，而非用户规模。
四、与相邻概念的严格边界
4.1 AI、Agent、Agent System 与 Agent Platform
| 对象 | 主要研究对象 | 典型核心问题 | 与 Agent Platform 的关系 |
|---|---|---|---|
| AI | 模型、推断、检索和模型工程 | 智能能力如何获得与调用？ | 平台使用或托管这些能力 |
| Agent | 面向目标的决策与行动实体 | 下一步行动如何选择、结果如何反馈？ | 平台定义、配置、运行或管理 Agent |
| Agent System | 承载 Agent 执行的软件系统 | 任务如何执行、编排、持久化与恢复？ | 平台通常封装或复用系统运行能力 |
| Agent Platform | 面向使用者的可复用管理与运行服务 | 如何让 Agent 能被创建、配置、运行、观察和持续维护？ | 本篇研究对象 |
这四个层次是知识研究的分工，不意味着实际产品必须拆成四个进程或服务。一个代码仓库可以同时实现 Agent Runtime、工作流、平台 API 和管理界面；研究时仍应按职责区分。
4.2 Agent Framework / SDK
Agent Framework 提供编程抽象，例如 Agent、Tool、Run、Graph、Message 或 State 等类型与执行辅助能力。它帮助开发者编写 Agent 或 Agent System，但不天然提供可被多个使用者持续消费的 Agent 管理服务。
例如，某框架允许开发者通过 Python 定义多个 Agent 并执行任务，但所有配置修改仍需编辑源代码、重新部署，且没有可管理的 Agent 对象与运行服务接口。此时称其为 Framework 更准确。反过来，一个 Agent Platform 完全可能以此框架为底层实现。
边界并不绝对：如果一个项目既提供 SDK，又提供托管运行、定义注册、版本管理和管理接口，应分别分析其框架层与平台层，而不是强行二选一。
4.3 Agent Harness 与 Agent Runtime
Agent Runtime 主要承担某个 Agent 执行实例的驱动、工具调用、状态更新和终止等职责。Agent Harness 在不同技术社区中的用法并不统一，通常强调围绕 Agent 执行建立的上下文、工具、约束、反馈和验证机制。两者都可能成为平台执行平面的组成部分。
它们与 Agent Platform 的差别主要在于管理对象和服务范围：Runtime / Harness 可以使一次任务可靠执行，但平台还需要把 Agent 定义、配置、运行、访问和维护组织成可复用服务。一个功能丰富的 Harness 并不因具备工具调用和审批就自动成为平台。
4.4 Workflow Engine 与 Multi-Agent System
Workflow Engine 管理步骤、依赖、触发、调度和执行状态。它可以作为 Agent Platform 的编排底座，但未必具备 Agent 定义、模型与工具配置、Agent 运行对象及其生命周期管理。
Multi-Agent System 则强调多个 Agent 的协作与交互，是系统组织方式，而不是平台属性。多个 Agent 组成的研究团队，可以运行在专门的业务系统里；一个只服务单 Agent 的开发者平台，也可以是平台。
因此，“支持多 Agent”“有流程编排”“有画布”都不足以证明平台成立。
4.5 AI Platform / Model Platform
AI Platform 往往覆盖模型开发、训练、部署、评测、推断服务与数据管理等更广泛的 AI 工程能力；Model Platform 则可能更聚焦模型托管、路由和推断。Agent Platform 可以依赖这些服务，也可能在同一产品中整合模型管理能力。
判断某个平台是否属于 Agent Platform，应看它是否直接提供 Agent 对象和运行生命周期的管理能力，而不是仅看它是否提供大语言模型 API、Prompt 模板或 Function Calling。
4.6 普通 Agent 应用与 Agent Platform
普通 Agent 应用面向特定业务目标，例如自动生成研究报告、客服答疑或浏览器操作。它可能有复杂的运行系统和精美的界面，但其主要产品对象仍是业务任务结果。
Agent Platform 的主要产品对象则包括可被创建和管理的 Agent 能力本身。它允许使用者在一定范围内定义不同 Agent、配置资源、触发运行并管理其生命周期。平台可以承载应用，应用也可以内置平台能力，但两者的核心抽象不同。
一个实用判据是：如果要增加第二类 Agent，是否必须复制代码、改动核心业务逻辑并重新开发一套管理流程？如果必须，平台化程度通常较低；如果能够通过已有的定义、配置和运行接口完成，则具有更明显的平台特征。这是启发式问题，不是唯一的技术测试。
五、三个容易混淆的“平台对象”
理解平台边界，还必须区分 Agent Definition、Agent Version 与 Agent Run。它们分别代表“是什么”“哪一个确定版本”“这一次执行发生了什么”。
| 对象 | 含义 | 典型字段 | 是否应该随每次执行改变？ |
|---|---|---|---|
| Agent Definition | 可复用的 Agent 设计与配置实体 | agent_id、name、model_policy、tools、instructions | 不应因一次运行结果直接改写其身份 |
| Agent Version | 可追踪的定义快照或发布单元 | version_id、agent_id、revision、created_at | 原则上应保持不可变或可审计 |
| Agent Run | 某版本在特定任务与上下文下的执行记录 | run_id、version_id、input、status、events、result | 会随执行状态变化 |
某些平台还区分 Deployment（发布到运行环境的版本）、Session（跨多次交互的会话）、Instance（实例）和 Workflow Run（工作流执行）。这些概念并无跨产品统一的字段定义。分析具体产品时，必须先检查它们的官方语义，不能把 Run、Session、Instance 和 Deployment 混用。
一个典型的关联模型是：
Agent Definition (agent_id)
│
├── Version v1 ── Deployment A ── Run #101
│ └──── Run #102
└── Version v2 ── Deployment B ── Run #103这个模型的意义不在于要求每个平台都有独立 Deployment 表，而在于区分设计变更、版本发布与实际执行。如果平台在运行过程中无记录地覆盖 Agent 指令或工具配置，就很难回答某次结果究竟由哪套配置产生，也难以回归测试或审计。
六、平台的控制边界：Control Plane 与 Execution Plane
平台常以控制平面和执行平面描述职责划分，但两者是逻辑职责，不要求物理上分成两个集群。
Control Plane 处理 Agent 定义、版本、授权、发布、配额、资源策略与管理操作，回答“谁可以配置什么、哪一个版本可运行、应受到什么限制”。
Execution Plane 处理任务启动、运行时执行、模型与工具调用、执行状态、结果和运行事件，回答“这次任务实际做了什么、是否完成、消耗哪些资源”。
使用者 / 管理员
│ 创建、配置、发布、授权
▼
Control Plane ── 可运行版本 + 授权策略 ──► Execution Plane
▲ │
└──── 运行状态、事件、用量与审计信息 ────────┘
│
模型 / 工具 / 数据关键工程问题不是是否画出了两层，而是控制平面的策略能否在执行平面真正生效。例如，用户在管理界面移除某 Agent 的文件删除权限，如果执行器仍可调用删除工具，那么平台的权限边界只是界面配置，而非有效的系统控制。
同样，平台不应把模型输出当作可信授权依据。模型可以提出“需要调用删除工具”的行动意图，但工具调用是否执行，应由可信的软件组件依据身份、策略和上下文进行判断。
七、边界案例：哪些系统应被称为平台？
以下案例为概念性假设，不是对任何特定厂商产品现行能力的事实断言。
| 案例 | 具备的能力 | 更合适的归类 | 判断理由 |
|---|---|---|---|
| A：单个研究聊天应用 | 固定研究 Agent、聊天界面、搜索与报告 | Agent Application | 核心对象是研究结果，Agent 不可复用管理 |
| B：Python Agent 工具库 | 定义 Agent、工具与执行循环 | Agent Framework | 提供开发抽象，但缺少持续管理服务 |
| C：研究任务后端 | 任务队列、Runtime、状态存储、监控 | Agent System | 执行能力完整，但可能仅服务固定业务 |
| D：内部 Agent API 服务 | 注册不同 Agent、配置版本、启动 Run、查询状态、授权 | Agent Platform | Agent 对象化、服务化且具管理边界 |
| E：拖拽式流程画布 | 设计步骤并运行固定工作流 | Workflow Platform / Application | 画布本身不足以证明 Agent 管理能力 |
| F：多 Agent 协作程序 | 研究员、写作者、审核者协同工作 | Multi-Agent System | 多 Agent 协作不自动产生平台属性 |
| G：模型 API 网关 | 模型接入、路由、用量与密钥管理 | Model Platform / Gateway | 未直接管理 Agent 定义与运行生命周期 |
对于介于 C 与 D 之间的系统，不必急于作二元判定。可以分别描述其“Agent System 能力已经具备、平台管理能力部分具备”，并明确缺少哪些可验证证据。平台性可以是逐步形成的工程特征，而不是单纯的产品标签。
八、如何进行一次可复现的平台边界审查？
为了避免定义停留在文字层面，可以对待研究系统进行一次小规模、可复现的审查。建议使用以下审查流程。
第一步：确定服务对象与系统范围。 明确系统服务的是一个业务应用、一个开发团队、多个业务团队还是外部客户；列出实际存在的 API、管理界面和运行服务。不要以产品宣传中的“平台”字样替代架构证据。
第二步：识别 Agent 对象。 查找是否存在可识别的 Agent 定义及其标识符，能否通过配置或接口创建第二个不同 Agent，是否需要修改核心代码才能实现。
第三步：追踪定义到运行。 选择一个 Agent，记录它的配置、版本、运行入口、运行标识符、执行状态和最终结果。检查能否回答“这次运行使用了哪个 Agent 的哪个版本”。
第四步：验证权限与资源边界。 使用无权限身份尝试读取或执行不属于自己的 Agent；检查系统是否由服务端拒绝，而不是仅在界面隐藏按钮。检查模型和工具凭据是否与 Agent 配置及运行身份正确隔离。
第五步：检查变更和审计。 修改 Agent 的工具配置或指令，观察已有运行记录是否仍可关联旧配置，是否能解释新旧版本差异，以及是否能够撤销或恢复发布。
第六步：形成带证据的判断。 将观察结果分别标记为“实际验证”“源码可证”“文档宣称”或“尚未确认”，避免把文档能力清单写成已运行验证。
8.1 建议使用的审查记录表
| 审查项 | 证据要求 | 记录示例 |
|---|---|---|
| Agent 对象 | Agent ID、定义结构或创建接口 | POST /agents 返回 agent_id（示例接口） |
| 复用能力 | 两个不同 Agent 共用平台运行能力 | 相同 Run API 启动两个 Agent |
| 版本追踪 | 运行记录指向确定配置 | run.version_id 可回溯 |
| 执行管理 | 可查询运行状态与结果 | RUNNING → COMPLETED / FAILED |
| 权限边界 | 越权操作由服务端拒绝 | 无权限调用返回拒绝 |
| 运行可观察 | 可查询必要事件与错误 | run_id 关联日志或事件 |
| 变更管理 | 配置更新不破坏历史归因 | 旧 Run 保留旧版本关联 |
表中的 API 路径、状态名称只是示例，并非跨平台统一规范。具体审查时应采用目标产品的真实接口与术语。
8.2 一个最小平台的参考契约
以下 JSON 是用于说明平台对象边界的示意数据结构，不是可直接用于某个厂商 API 的请求格式：
{
"agent": {
"agent_id": "research-agent",
"version_id": "v2",
"definition": {
"role": "technical-researcher",
"model_policy": "research-default",
"tools": ["search", "read_document"]
}
},
"run": {
"run_id": "run-1042",
"agent_id": "research-agent",
"version_id": "v2",
"status": "RUNNING",
"requested_by": "user-17"
}
}该结构只展示定义、版本和运行之间的关系。真实平台还需要处理认证、授权、配置验证、密钥管理、并发、存储一致性、失败恢复和审计等问题。存在这份 JSON 并不意味着平台已经实现。
九、平台化的收益、代价与适用条件
平台化的潜在收益包括：减少不同团队重复开发 Agent 接入和运行管理代码；统一模型、工具和权限的管理方式；提高版本可追踪性；使任务运行、成本与错误能够集中观察；通过稳定接口支持新的 Agent 类型和业务场景。
但平台化也带来新的成本：抽象层需要长期维护，平台 API 与对象模型会形成兼容性约束；通用能力可能限制特定业务的灵活性；多团队共享基础设施引入隔离、配额、故障影响范围和治理复杂度；控制平面与执行平面之间的配置一致性、发布和回滚也成为独立的工程问题。
因此，并非所有 Agent 项目都应该立即平台化。若只有一个业务场景、需求变化少、运行规模有限，直接构建可维护的 Agent 应用或 Agent System 可能更经济。若多个项目反复需要 Agent 创建、配置、版本、运行、权限和监控能力，平台化的价值才更容易显现。
一个实用的工程判断是：被复用的是 Agent 的基础能力，还是仅仅复制了业务代码？ 如果跨项目复用已经成为稳定需求，可以考虑将重复出现的对象与操作抽象为平台服务；如果尚无明确复用需求，过早构建通用 Builder、Registry 和多租户架构，可能只会增加复杂度。
十、与本知识库后续专题的衔接
本篇只解决 Agent Platform 的定义与边界。其余研究将在以下专题展开：
| 后续专题 | 在本篇基础上继续解决的问题 |
|---|---|
| Fundamentals 02 · Core Components | 平台需要哪些功能职责与组件？ |
| Fundamentals 03 · Platform Architecture | 平台整体如何运行，控制与执行职责如何协同？ |
| Fundamentals 04 · Platform Types | 如何从服务对象、托管方式和产品形态分类？ |
| Fundamentals 05 · Lifecycle Management | Agent 定义、版本、部署、实例和运行如何管理？ |
| Fundamentals 06 · Design Principles | 如何选择平台边界、抽象层和架构原则？ |
| Technical Architecture P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 | 控制平面、执行平面、Registry、Builder、运行管理、工作流与治理如何实现？ |
| Product Architecture F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 | 使用者如何创建、配置、操作、观察和管理 Agent？ |
| Engineering & Practice 01 - 06 | 如何研究真实平台、选型、设计、开发、部署和验证？ |
特别需要避免三类重复：本篇不详细设计 Registry 数据库；不替代 P1/P2 的控制平面与执行平面实现；也不提前展开 F1/F2 的界面交互。它为这些专题提供共同的概念和判定标准。
十一、研究结论
Agent Platform 的本质，不是“拥有多个 Agent 的软件”，也不是“能够拖拽构建 Agent 的界面”，而是将 Agent 定义、配置、运行与管理转化为可复用、可访问、可治理的软件服务。
判定一个系统是否构成 Agent Platform，应重点检查 Agent 是否成为可管理对象、能力是否通过稳定接口复用、运行是否具有可追踪的生命周期，以及权限与资源边界是否由可信的软件机制执行。可视化 Builder、多租户、多 Agent、独立微服务和云托管都可能是平台特征，但不是定义的必要条件。
Agent System 主要解决任务如何执行与保障，Agent Platform 进一步解决这些能力如何作为持续服务被创建、配置、管理和消费。两者可以由同一软件实现，但研究问题不同。准确区分这条边界，是后续分析 Agent Registry、Control Plane、Execution Plane、Agent Builder 和平台治理的基础。
附录 A：参考文献与原始资料
建议在后续研究中使用以下官方技术资料作为核查入口；列出这些入口不代表本篇已完成对其最新版本的逐项验证：
- LangGraph 官方文档（运行与持久化机制）：docs.langchain.com/oss/python/langgraph/overview
- OpenAI Agents SDK 官方文档（Agent 执行抽象）：openai.github.io/openai-agents-python
- Microsoft Agent Framework 官方资料：learn.microsoft.com/en-us/agent-framework
- Kubernetes 官方文档（控制器与声明式资源管理，用于平台控制平面的工程类比）：kubernetes.io/docs/concepts/architecture/controller
- CNCF Cloud Native Glossary（云原生平台与运行基础设施相关术语）：glossary.cncf.io
附录 B：研究证据、验证声明与适用边界
证据类型： 本篇采用概念辨析、架构推演与可操作判据，形成知识库的工作定义。它不代表业界已有统一、强制性的 Agent Platform 定义。上列参考资料主要用于相关技术概念的核查入口，不应被理解为对本篇全部定义的直接背书。
验证状态： 本文未对具体厂商平台的当前版本进行源码审计、实际 API 调用或功能验收。文中的案例 A - G、JSON 和接口示例均为教学用假设，不是已部署或已测试系统。涉及具体产品的现行功能、实现方式和性能，应在后续 Platform Case Studies 中以明确版本、官方资料和可复现实验独立核验。
适用边界： 文中的判定标准用于区分平台化程度与研究对象，不是行业认证标准。开发平台、运行平台与应用平台可各自具备平台属性，不要求单一产品覆盖 v1.3 目录列出的全部功能。
后续衔接： 下一篇为「02 · Agent Platform 由什么构成？ - Core Components」，重点讨论组成部分与职责；本篇不提前替代 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 的技术实现或 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 的产品交互研究。