04 · Agent Platform 有哪些类型？ - Platform Types
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：01 · Agent Platform 是什么？它如何工作？ - Fundamentals
文档类型：专题研究
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：Agent Platform 应当如何分类？开发平台、运行平台、应用平台和综合型平台之间有何区别与联系？如何根据能力边界、交付形态、治理要求和使用场景选择或设计平台？
专题导读
本篇属 Fundamentals。前三篇已讨论 Agent Platform 的定义、核心组件与运行架构。本篇转向平台形态与分类方法：平台为何会呈现不同类型；如何避免把“产品名称”“架构层”“交付方式”“目标用户”混作同一分类；如何使用可核验的能力证据识别平台定位；以及如何从自身需求出发选择单一平台、组合平台或自建平台。
核心判断：Agent Platform 没有唯一、互斥且被行业统一采纳的分类标准。本文提出一套研究用的多维分类框架：以平台的主要价值交付阶段为主轴，将其区分为开发型、运行型、应用型和综合型；再以交付方式、抽象程度、运行自治性、服务对象、治理范围等维度交叉描述。各类型可以重叠，同一产品可能同时属于多类。下文的分类属于本文的分析框架，不宣称是正式行业标准。
一、为什么需要研究平台类型？
1.1 同名产品可能解决不同问题
“Agent Platform”在实际语境中可能指可视化搭建器、Agent SDK 所依托的托管服务、工作流运行服务、企业级治理平台、面向最终用户的任务工作台，甚至包含市场与计费的综合产品。它们都可能提供 Agent 能力，但交付的核心价值、系统边界、用户角色和运维责任明显不同。若不先分类，技术选型就容易比较不同层次的产品，例如把开源开发框架与托管企业应用直接按功能数量排名。
1.2 分类应服务于可执行的决策
分类至少应支持四项判断：（1）平台的主要用户是谁；（2）平台承诺解决 Agent 生命周期的哪些阶段；（3）哪些能力由平台提供、哪些由使用者自行实现；（4）平台之间是否可组合。分类的目的不是贴标签，而是发现能力缺口、责任边界与集成成本。
1.3 分类的分析单位
研究时需要明确比较对象究竟是产品整体、某项子服务、某个部署方案，还是一个具体版本。同一厂商可能同时提供 SDK、托管运行服务和可视化应用产品；不能将它们未经说明地当成一个单一平台，也不能把营销页面列出的全部能力视为当前部署必然具备。
二、平台分类的基础：六个分析维度
| 维度 | 关键问题 | 典型取值或观察点 |
|---|---|---|
| 主要价值阶段 | 平台首先帮助用户完成什么？ | 开发、运行、应用、端到端 |
| 目标用户 | 谁直接操作平台？ | Agent 开发者、平台工程师、业务创建者、终端用户、管理员 |
| 交互与抽象层 | 用户以何种方式表达需求？ | 代码/SDK、声明式配置、低代码画布、自然语言/工作台 |
| 部署与交付 | 谁负责运行基础设施？ | 本地、自托管、托管云、混合、嵌入式 |
| 运行与治理边界 | 平台承担多少生产责任？ | 仅构建、托管执行、状态/审计/配额/租户治理 |
| 扩展与生态 | 能否被其他系统组合复用？ | API、SDK、插件、连接器、市场、开放协议 |
**使用原则：**这些维度彼此独立。例如“低代码”描述交互抽象层，“SaaS”描述交付方式，“开发型”描述主要价值阶段。低代码 SaaS 平台并不自动等于应用型平台；开源也不自动意味着可自托管生产运行。
三、主分类：按主要价值交付阶段
3.1 开发型平台 - Agent Development Platform
**核心价值：**让创建者更高效地设计、构建、调试、测试和发布 Agent 或工作流。主要用户是开发者、自动化设计者和业务创建者。
典型能力包括 Agent 定义、模型与工具配置、提示词与技能管理、可视化编排或代码开发、调试运行、测试数据集、版本化、模板复用和发布入口。平台可以包含轻量运行能力，但其差异化价值通常在开发体验（Developer/Builder Experience）。
**典型交付物：**Agent Definition、Workflow Definition、版本化配置、测试报告、可部署包或发布引用。
**边界：**具有 Agent Builder 不代表具备生产级运行平台。需要另行检查长任务恢复、任务队列、实例隔离、容量调度、部署管理、租户治理和 SLO。
3.2 运行型平台 - Agent Runtime Platform
**核心价值：**可靠地承载 Agent System 的执行，并提供部署、任务生命周期、调度、状态、隔离、监控与资源控制。主要用户是平台工程师、后端开发者和运维人员。
典型能力包括执行准入、运行实例分配、队列/调度、异步任务、重试与恢复、Checkpoint、事件与日志、密钥注入、权限隔离、伸缩、版本部署及回滚。某些运行平台并不提供面向业务人员的可视化 Builder。
**典型交付物：**Deployment、Run、Attempt、执行事件、状态快照、日志、结果与运行指标。
**边界：**运行型平台与 03 · Agent System 的执行引擎不同。Agent Engine 负责具体 Agent 的推理 - 行动循环；Runtime Platform 负责跨多个定义、实例、环境和使用者的运行管理。平台可托管一个或多个不同实现的 Agent System。
3.3 应用型平台 - Agent Application Platform
**核心价值：**把 Agent 能力组织成用户可持续使用的产品和业务流程。主要用户是业务团队、终端用户、项目负责人和运营者。
典型能力包括 Workspace/Project/Studio、任务发起、会话与长任务、协作与人工审批、进度展示、产物管理、共享与权限、业务模板、通知与交付。它可能隐藏 Agent 的内部构建细节，强调用户目标与业务成果。
**典型交付物：**已完成的业务任务、报告、文件、操作记录、审批决策、共享成果及业务指标。
**边界：**单个 Agent 聊天应用不必然是平台。应检查其是否能够持续承载多个可配置的 Agent/Workflow/应用单元，是否具备可复用的对象、统一管理能力和合理的访问边界。平台属性存在程度差异，而非绝对二分。
3.4 综合型平台 - Integrated / End-to-End Agent Platform
**核心价值：**在同一产品或产品套件内贯通开发、测试、发布、执行、管理和使用，并提供统一身份、资源、治理和资产体系。
典型能力包括开发型、运行型和应用型平台的交集，以及跨生命周期的版本追踪、资产关联、权限模型、审计、成本计量和组织治理。
**典型交付物：**从 Agent 定义到业务交付的完整可追溯链路。
边界：“综合型”不等于所有能力都成熟，也不要求全部能力由一个进程实现。综合平台可以是多个服务组成的产品套件。其关键是对用户提供一致的对象、身份、流程和管理体验，而不是简单将多个工具拼在一个导航栏里。
3.5 四种类型对照
| 类型 | 首要用户 | 首要对象 | 核心价值 | 常见缺口 |
|---|---|---|---|---|
| 开发型 | 开发者/创建者 | Definition、Version、Test | 构建与迭代效率 | 生产运行与治理 |
| 运行型 | 平台工程师/运维 | Deployment、Run、Attempt | 可靠执行与可运维性 | 业务产品体验 |
| 应用型 | 业务团队/终端用户 | Workspace、Task、Artifact | 任务完成与业务交付 | 底层可扩展性 |
| 综合型 | 多角色 | 全生命周期对象 | 统一体验与治理 | 复杂度、成本、锁定 |
**重要限定：**表中的“常见缺口”是选型时需要核验的风险，不是对某一类平台的普遍断言。
四、交叉分类：不能混为主类型的其他维度
4.1 按交付与部署方式
- 托管云平台（Managed/SaaS）：服务商运营核心平台；关注数据边界、地域、SLA、可迁移性、费用和供应商锁定。
- 自托管平台（Self-hosted）：组织自行部署；关注安装复杂度、升级、安全修补、备份和内部运维能力。
- 本地/桌面平台（Local/Desktop）：面向个人或边缘设备；关注离线能力、本地权限、设备资源和数据同步。
- 混合平台（Hybrid）：控制、执行或数据分布在不同环境；关注身份联邦、网络边界、状态一致性和跨环境审计。
- 嵌入式平台（Embedded/Headless）：以 API/SDK 形式嵌入第三方产品；关注多租户委托、白标、配额和接口稳定性。
这些是交付形态，不是对平台功能类型的替代分类。一个运行型平台既可能托管云部署，也可能自托管。
4.2 按创建方式和抽象层
- 代码优先（Code-first）：通过 SDK、声明式代码和 CI/CD 管理定义；便于复杂逻辑与自动化，但要求工程能力。
- 低代码/可视化（Low-code/Visual）：通过节点、表单、画布搭建；适合标准化流程，但需要检查表达能力、版本差异与可测试性。
- 自然语言优先（Natural-language-first）：用户用自然语言描述目标，平台辅助生成 Agent/Workflow；需检查生成结果的可解释性、可复现性与审查机制。
- 混合式（Hybrid Authoring）：支持代码、可视化与配置之间的协作；需检查双向转换是否无损、哪种表示是权威来源。
4.3 按服务对象和管理范围
个人平台、团队协作平台、企业平台、行业/场景专用平台、对外提供服务的平台，其主要差异可能体现在身份模型、数据边界、审计、合规、配额、服务级别与商业交付责任。“企业级”不是一个可以仅凭品牌或宣传用语验证的技术类别，必须拆成可测试的治理要求。
4.4 按运行方式
同步交互、异步长任务、事件驱动、定时/批处理、持续运行、人工审批驱动等，是运行模式而非平台类型。同一平台可支持多种模式；运行模式决定任务状态机、取消与恢复、计费、观测和用户体验的设计。
五、容易混淆的概念与边界
| 概念 | 它主要是什么 | 与 Agent Platform 的关系 |
|---|---|---|
| Agent Framework / SDK | 编程抽象、库与开发工具 | 可作为平台开发底座；单独的库未必是平台 |
| Agent Builder | 创建和配置 Agent 的工具或服务 | 常属于开发型平台的一部分 |
| Workflow Engine | 执行工作流定义的引擎 | 可成为运行型平台的底层能力 |
| Agent Runtime / Harness | 驱动 Agent 行动的运行机制与约束环境 | 可由平台承载、配置和管理 |
| Agent System | 完成任务的 Agent 系统 | 是平台可托管和复用的运行主体 |
| Agent Application | 面向某项用户目标的具体应用 | 可以运行在平台上；未必本身构成平台 |
| Model Gateway | 统一访问模型的服务 | 是平台可集成的基础服务，不等于 Agent Platform |
| Agent Marketplace | 发现、分发、共享 Agent 的产品机制 | 是平台生态能力之一，不等于完整平台 |
判断边界时，应优先问：**是否存在可复用的平台对象与统一服务契约？是否管理多个执行单元或使用场景？是否提供跨对象的生命周期与治理能力？**避免只凭“有 UI”“能运行 Agent”“支持多 Agent”下结论。
六、平台类型如何组合？
6.1 单一平台覆盖多个类型
一个产品可能同时提供可视化 Builder、托管 Runtime 和用户 Workspace，因此兼具开发型、运行型、应用型属性。评估时应分别给出三个维度的能力证据，避免只用“综合型”掩盖薄弱环节。
6.2 多个平台组成一个产品系统
典型组合：
flowchart TB
U[业务用户 / 开发者]
A[应用型平台：Workspace / Studio / Delivery]
D[开发型能力：Builder / Test / Registry]
R[运行型平台：Deployment / Run / State]
S[Agent System：Engine / Workflow / Tools]
G[共用治理：Identity / Policy / Audit / Cost]
U --> A
U --> D
A --> R
D --> R
R --> S
G -.治理.-> A
G -.治理.-> D
G -.治理.-> R此图是逻辑组合示例，不代表必然的产品部署拓扑。开发型能力与应用型能力可由同一系统提供；运行型能力也可以由自建模块或第三方服务提供。
6.3 组合时最重要的接口
- 定义与部署契约：Definition/Version 如何被发布为 Deployment；兼容性和回滚如何处理。
- 执行契约：Run 请求、输入、幂等键、取消、超时和结果如何表达。
- 状态与事件契约：谁是状态权威来源；事件如何排序、去重与重放。
- 身份与权限契约：用户、服务账户、Agent 身份如何跨平台传递，如何最小授权。
- 产物契约：Artifact 的存储位置、权限、版本、保留期限和下载方式。
- 观测与计量契约：跨平台 trace、成本归因、审计与故障定位。
七、典型产品案例：以能力事实而非品牌标签分类
以下案例仅用于展示分析方法。不同版本、套餐、部署形态与发布时间可能改变功能边界。未在本文写作过程中逐项在线验证产品最新功能，不能据此作当前采购承诺。
| 案例 | 可研究的主要方向 | 分类时应特别核验 |
|---|---|---|
| LangGraph / LangSmith 相关产品 | 代码开发、Agent 运行与观测的组合 | 开源库、开发工具、托管服务分别承担什么职责 |
| Dify | 可视化开发、应用发布与工作流运行 | 自托管/云版本差异、生产治理与扩展边界 |
| Microsoft Copilot Studio | 业务 Agent 创建、连接与组织治理 | 授权方式、渠道、租户边界与管理能力 |
| Google Vertex AI Agent Builder / Agent Engine 相关服务 | 开发与托管执行能力组合 | 具体服务范围、运行管理和与云服务的依赖 |
| Amazon Bedrock Agents | 托管 Agent 能力与云资源集成 | 平台对象边界、执行模式、治理与外围服务需求 |
| 自建研究报告 Studio | 应用型起步，逐步加入开发与运行管理 | 可复用程度、平台对象、长期运行与治理闭环 |
**案例分析纪律：**对每个候选产品建立证据表，至少记录“产品/组件名称、版本或查询日期、官方文档、明确支持的能力、未验证的能力、依赖条件”。不能把某个生态中的框架、部署服务、观测产品无条件合并为同一产品的原生能力。
八、如何判断一个平台属于哪些类型？
8.1 能力证据矩阵
建议用“已验证支持 / 文档声明支持 / 需外部集成 / 不支持 / 未知”五态记录，不要直接以主观的 1 - 5 分替代证据。
| 能力组 | 开发型观察项 | 运行型观察项 | 应用型观察项 |
|---|---|---|---|
| 定义与配置 | Agent/Workflow 定义、版本、配置 | 部署读取与版本固定 | 模板与可配置入口 |
| 测试与发布 | 调试、测试集、发布流程 | 环境部署、回滚 | 可见范围、共享与上架 |
| 执行与恢复 | 预览运行 | 队列、长任务、重试、恢复 | 发起、暂停、取消、重试交互 |
| 数据与产物 | 开发资产 | 状态、日志、执行结果 | 文件、报告、审批与交付 |
| 治理与管理 | 开发权限 | 租户隔离、配额、审计 | 工作空间、角色、管理员控制 |
| 集成与扩展 | SDK、插件开发 | API、事件、资源适配 | 外部应用入口、连接器 |
8.2 一个可复用的判定流程
**步骤一：定义任务。**例如“业务人员配置研究团队并提交报告任务”“开发者托管一个持续运行的 Agent”。
**步骤二：划清产品边界。**确定被评估的是 SaaS 整体、自托管版本、开源库，还是某项子服务。
**步骤三：识别主要价值阶段。**记录用户首先为哪种能力选择它，而非单纯统计功能数量。
**步骤四：逐项收集证据。**官方文档与可重复操作优先；区分已验证与待验证。
**步骤五：识别组合依赖。**检查平台自身实现了哪些职责，哪些由外部引擎、云资源或集成服务承担。
**步骤六：输出多标签结论。**例如“开发型为主、具备托管运行能力、应用层有限”，而不是强行只选一个标签。
8.3 判定结果模板
评估对象：<产品/服务/版本/部署方式>
主要用户：<开发者/平台工程师/业务用户/管理员>
主要价值阶段：<开发/运行/应用/综合>
次要能力：<可多选>
已验证证据：<功能、文档、测试日期>
依赖与限制：<外部服务、套餐、地域、配额>
平台责任边界：<平台负责 / 用户负责>
尚待验证：<关键未知项>
适用场景：<明确业务需求>
结论可信度：<基于证据说明>九、如何为具体项目选择平台类型？
9.1 先看任务，而不是先看平台清单
| 需求 | 优先关注 | 不能忽视 |
|---|---|---|
| 快速试验多个 Agent 方案 | 开发型 | 定义可导出、测试可复现 |
| 长时间执行大量任务 | 运行型 | 状态恢复、隔离、配额、成本 |
| 业务人员日常使用 Agent | 应用型 | 任务体验、权限、审批、产物 |
| 面向多个团队提供统一能力 | 综合型或组合平台 | 多租户、API、治理、升级 |
| 将 Agent 嵌入既有产品 | Headless/SDK 能力 | 身份传递、接口稳定性、计费 |
| 严格数据驻留或离线要求 | 自托管/本地/混合 | 真实依赖清单与运维成本 |
9.2 选择路径：购买、组合或自建
直接采用成熟平台适合业务流程标准化、产品功能与需求匹配、团队运维能力有限的情况。需验证供应商锁定、数据导出和长期成本。
组合现有平台能力适合开发体验、运行能力和应用体验由不同方案分别满足的情况。需预算接口适配、状态一致性、权限映射和故障归因成本。
自建平台适合业务对象独特、交互要求特殊、需要深度控制执行或多租户治理的情况。应先明确不可替代的差异化能力，再决定哪些底层能力复用现有组件。
选择时应核算总拥有成本（TCO），而非仅比较订阅价格或基础设施账单。TCO 至少包括研发、运维、模型与工具调用、迁移、合规、停机风险和人员学习成本。
9.3 典型反模式
- 把一个漂亮的 Agent Builder 当成已经具备可靠运行与治理的平台。
- 因为产品支持多 Agent，就假设它具备多租户、组织权限和生产级审计。
- 把“开源”“自托管”“私有化”“本地推理”视为同义词。
- 将 Agent Framework 与完整 Agent Platform 作一对一价格或功能对比。
- 过早追求综合型平台，导致 MVP 被账户体系、市场、计费和复杂微服务拖慢。
- 忽略定义、运行、产物三类对象的身份与版本关联，后续难以复现结果。
十、贯穿案例：研究报告 Studio 应如何定位？
10.1 起步阶段：应用型平台优先
用户的直接目标是“提出研究需求 → 组织 Agent 团队 → 运行研究流程 → 人工审核 → 交付报告”。因此，从用户价值看，研究报告 Studio 首先是应用型平台或应用型平台雏形。核心对象是 Workspace、Project、Studio、Task、Run、Approval 和 Artifact。
需要强调：如果 Studio 只支持一套固定工作流、无法复用或管理其他 Agent/Workflow，它更准确地说是Agent Application / Agent System 的产品界面。只有逐步形成可复用定义、统一执行、生命周期管理和跨项目管理能力，平台属性才会增强。
10.2 第二阶段：补足开发型能力
允许创建不同研究 Agent、修改指令与工具、配置审核标准、保存版本、预览调试并发布到不同 Studio。此时平台具备明确的开发型能力，但不必立即开发通用拖拽画布。
10.3 第三阶段：补足运行型能力
支持长任务异步执行、任务队列、Checkpoint、暂停与恢复、取消、失败重试、运行事件、版本固定、资源配额和成本追踪。需要决定哪些职责由自建服务承担，哪些由既有 Agent System 或托管运行服务承担。
10.4 第四阶段：面向多团队的平台化
增加组织/租户边界、角色与权限、项目隔离、共享资产、审计、配额、API/SDK 和管理后台。此时才需要系统评估综合型平台的组织成本、扩展能力与商业交付能力。
10.5 最小对象关系
flowchart LR
W[Workspace / Project] --> ST[Studio]
ST --> T[Task]
ST --> AV[Agent Version]
ST --> WV[Workflow Version]
T --> R[Run]
R --> AT[Attempt]
R --> AP[Approval]
R --> AR[Artifact]
AV --> DP[Deployment]
DP --> R这张图是概念关系草图，不是完整 ER 模型；具体基数、外键和事件模型需在 P3/P5/P10、F5/F6/F10 及 Engineering & Practice 中设计。
十一、与 v1.3 目录其他专题的关系
| 后续专题 | 本篇提供的前置判断 | 后续深入研究内容 |
|---|---|---|
| Fundamentals 05 · Lifecycle Management | 不同平台类型管理不同对象阶段 | 定义、版本、部署、实例、Run、Artifact 生命周期 |
| Fundamentals 06 · Design Principles | 分类决定优先设计约束 | 复用、隔离、可扩展、演进、治理原则 |
| P1/P2 | 开发/运行/应用能力可以分离 | 控制面与执行面具体职责 |
| P3 - P4 - P5 - P6 - P7 | 不同平台类型依赖不同核心服务 | 注册、开发、部署、工作流与资源集成 |
| P8/P9 | 嵌入式与生态型平台尤其依赖接口 | API、SDK、插件与扩展 |
| P10 - P11 - P12 | 组织化平台需要共享资产和治理 | 资产、多租户、权限与配额 |
| F1 - F2 - F3 - F4 | 开发型平台的产品能力 | 创建、配置、调试、发布 |
| F5 - F6 - F7 - F8 - F9 - F10 | 应用型平台的产品能力 | 项目、执行、协作、监控、管理、交付 |
| F11/F12 | 对外集成与组织运营 | 开发者体验与平台管理 |
| Engineering & Practice | 分类指导案例选择与技术选型 | 平台对比、系统设计、路线、部署和测试 |
十二、研究方法与实验验证设计
12.1 研究方法
本文采用概念辨析、能力分类、平台责任边界分析和案例映射。主分类为研究性归纳，不将其表述为任何标准组织的官方分类。
12.2 建议进行的验证实验
| 实验 | 操作 | 可验证结论 |
|---|---|---|
| 开发能力验证 | 创建 Agent、变更工具、保存版本、执行测试 | 是否存在可复用定义和测试闭环 |
| 运行能力验证 | 提交长任务、强制中断 Worker、恢复执行 | 是否具备状态持久化和故障恢复 |
| 应用能力验证 | 不同角色在同一 Project 发起、审批、交付 | 是否形成完整业务闭环 |
| 租户隔离验证 | 跨组织访问定义、Run、Artifact | 是否具备有效的数据与权限隔离 |
| 接口可复用验证 | 通过 SDK/API 调用相同 Agent 定义 | 是否提供稳定的外部服务契约 |
| 组合平台验证 | 更换运行后端并保持上层任务契约 | 平台间是否具备合理解耦程度 |
**执行状态：**以上均为建议的验证设计，本文未执行真实产品测试、故障注入或性能测量。
十三、局限与适用边界
- **分类非唯一标准。**行业产品边界持续变化，开发型、运行型、应用型是本文为研究与选型提出的分析框架，不应作为排他性的市场定义。
- **产品案例具有时效性。**具体功能、定价、部署方式和支持范围可能变化，实际选型必须依据当时的官方文档与实测结果。
- **成熟度不由类型决定。**开发型平台可以具有完善的治理；综合型平台也可能在可靠性方面不足。类型描述价值重心，不能代替质量评估。
- **平台不等于微服务。**单体、模块化单体、云托管或混合架构均可能形成平台能力；部署复杂度不能替代平台化程度。
- **不替代具体安全评估。**租户隔离、访问控制、密钥、数据驻留和合规要求需在具体场景与威胁模型下独立验证。
研究结论
**结论一：**应使用多维分类而不是单标签分类。平台的主要价值阶段、用户角色、抽象层、交付方式和治理范围是不同维度。
结论二：按主要价值阶段，可将 Agent Platform 分为开发型、运行型、应用型与综合型四种研究类型；它们允许重叠，不构成官方统一标准。
结论三：类型判断必须基于可复用对象、服务契约、生命周期、运行责任和治理证据，不能只看界面、品牌、是否开源或是否支持多个 Agent。
**结论四：**平台可以由多个产品或服务组合构成。组合能力的关键不是组件数量，而是定义、执行、身份、事件、产物和审计之间是否存在稳定契约。
**结论五：**研究报告 Studio 的合理起点是应用型产品能力，随后按实际需求增加开发型和运行型服务；在未验证跨场景复用与统一管理前，不宜仅因存在多 Agent 协作就称其为成熟 Agent Platform。
**结论六：**平台选型应从业务任务与责任边界出发，分别验证功能、部署、治理、迁移与总拥有成本，避免为追求“综合型”而过度建设。
附录 A：参考文献与原始资料
以下列出适合核对平台概念、组件边界和案例能力的官方原始资料入口。链接作为后续逐项核验的线索；本文未在写作时逐条在线访问确认最新版本，因此不将其视为已完成的最新功能审计。
- LangChain, LangGraph Documentation：docs.langchain.com/oss/python/langgraph/overview - 研究代码层 Agent/工作流抽象及其与平台服务的边界。
- LangChain, LangSmith Documentation：docs.langchain.com/langsmith/home - 研究开发、测试、观测与部署服务之间的关系。
- Dify, Official Documentation：docs.dify.ai - 研究可视化构建、工作流、应用发布与部署形态。
- Microsoft, Microsoft Copilot Studio Documentation：learn.microsoft.com/en-us/microsoft-copilot-studio - 研究业务创建者体验、连接器与组织管理。
- Google Cloud, Vertex AI Documentation：cloud.google.com/vertex-ai/docs - 研究云平台的开发与托管运行能力边界；具体服务应进一步细分核验。
- AWS, Amazon Bedrock User Guide：docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html - 研究托管 Agent 能力与云资源集成。
- CNCF, Cloud Native Glossary：glossary.cncf.io - 辅助区分控制面、数据/执行面、服务与部署等架构概念；不作为 Agent Platform 分类标准。
- NIST, AI Risk Management Framework：www.nist.gov/itl/ai-risk-management-framework - 辅助分析平台治理责任，不作为平台类型标准。
- OpenTelemetry, Documentation：opentelemetry.io/docs - 辅助研究跨服务观测与追踪的接口要求。
附录 B：研究证据、验证声明与适用边界
B.1 证据类型
- **概念性归纳：**开发型、运行型、应用型、综合型四分法及六维分类矩阵，是本文构建的研究框架，不属于经正式标准组织批准的分类法。
- **可由官方资料进一步核验的事实：**各案例产品存在相应官方文档；具体功能、版本、授权和部署能力仍需在实际比较时逐项确认。
- **工程推论：**不同平台组合需要统一定义、执行、身份、事件、产物与审计契约；Studio 的阶段性演进路径是基于需求的设计建议。
- **未测试设想：**所有实验矩阵、故障注入、跨租户访问测试与平台替换实验，均未实际执行。
B.2 本篇自检
- [x] 标题、编号、所属领域与 v1.3 目录一致。
- [x] 明确分类维度与主分类之间的关系。
- [x] 说明四类平台允许重叠，不冒充行业统一标准。
- [x] 区分 Agent Framework、Agent System、Agent Application 与 Agent Platform。
- [x] 覆盖类型组合、选择方法、贯穿案例、实验设计与局限。
- [x] 说明官方资料入口与未完成的实时核验。
- [x] 包含专题导读、研究结论和两个固定附录。
B.3 后续待研究问题
- 平台对象在各类产品中的最小统一模型如何定义？转入 Fundamentals 05。
- 多类型平台应遵循哪些架构设计原则？转入 Fundamentals 06。
- 各类平台在真实产品中如何划分控制面与执行面？转入 P1/P2。
- 不同产品的功能覆盖、成本与可迁移性如何定量比较？转入 Engineering & Practice 01 - 02。