04 · Agent Platform - 领域概述与研究总纲
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：领域总览（覆盖 01 Fundamentals、02 Technical Architecture、03 Product Architecture、04 Engineering & Practice）
文档类型：领域概述 / 研究总纲 / 学习导航
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：什么是 Agent Platform？它如何把 Agent 与 Agent System 的能力转化为可供开发者、团队、管理员和终端用户创建、配置、运行、协作、发布、复用及治理的统一平台？如何系统研究其技术架构、产品架构和工程实践？
专题导读
本篇属 Agent 全栈技术地图。《Agent 全栈技术地图》的前面三个领域分别研究 AI 的基础能力、单个 Agent 的内部构成，以及 Agent System 的运行与治理。第四领域进一步研究：如何将这些能力封装为可复用的平台服务、可操作的产品界面与可持续运营的工程体系。研究对象不局限于某个可视化 Agent Builder，也不等同于一个多 Agent 聊天页面，而是覆盖开发、部署、执行、交付、管理与治理的完整 Agent Platform。
本领域采用 v1.3 的正式候选目录，保留四章、共 36 个专题：01 Fundamentals（6 篇）、02 Technical Architecture（12 篇）、03 Product Architecture（12 篇）、04 Engineering & Practice（6 篇）。本概述承担知识地图、术语约定、架构关系、研究边界和研究路线的作用；它不代替后续 36 篇专题的机制分析和工程验证。
本领域的贯穿案例为研究报告 Studio 平台：用户创建研究项目，配置研究团队与 Agent，启动选题 - 调研 - 审核 - 撰写 - 交付的工作流，观察执行进度，参与关键审批，并管理产物和版本。该案例用于验证平台能力的完整性，不意味着所有 Agent Platform 都必须具备相同的业务流程。
一、领域定位：为什么 Agent System 之上还需要 Agent Platform？
1.1 四个领域的递进关系
| 领域 | 研究对象 | 核心问题 |
|---|---|---|
| 01 AI | 模型与智能能力 | 模型能做什么、如何使用？ |
| 02 Agent | 单个智能体 | Agent 如何感知、决策、行动？ |
| 03 Agent System | 执行与协作系统 | 如何可靠地完成任务？ |
| 04 Agent Platform | 平台与产品体系 | 如何让能力可创建、可复用、可运营？ |
Agent Platform 的工作定义：面向开发者、团队、管理员或终端用户，统一提供 Agent 及其相关资源的创建、定义、配置、测试、发布、部署、执行、协作、监控、资产管理和治理能力的软件平台。平台通常通过控制面、执行面、平台服务、开放接口与产品界面协调工作，并可能承载多个 Agent System 或业务应用。
这个定义是本知识库的研究性工作定义，用于界定研究范围，而非行业唯一标准。现实产品可能只实现其中一部分能力。例如，偏开发的工具未必具有完整的多租户商业化管理能力；偏运行的平台也未必提供可视化 Builder。
1.2 Agent、Agent System 与 Agent Platform 的边界
- Agent：可被定义和调用的智能体能力单元；关注身份、指令、模型、工具、记忆与行为。
- Agent System：将 Agent、执行引擎、编排、状态、模型和基础服务组织成能完成任务的运行系统；关注任务正确性、可靠性与治理。
- Agent Platform：将这些能力抽象为多用户可操作的产品和共享服务；关注对象管理、控制面、开发者体验、租户隔离、发布与平台级运营。
平台不必自行重写 Agent Engine、模型推理服务或工作流执行引擎。它可以集成现有组件，通过统一的定义、部署、权限、计量、审计与产品契约向用户提供服务。相反，一个只有 Agent 聊天窗口、没有平台级对象管理与复用机制的应用，不宜直接视为完整的通用 Agent Platform。
1.3 三类常见平台侧重
| 平台侧重 | 主要使用者 | 优先能力 |
|---|---|---|
| Development Platform | Agent 开发者 | Builder、调试、测试、发布、SDK |
| Runtime Platform | 平台工程团队 | 部署、执行、调度、隔离、监控 |
| Application Platform | 业务用户与团队 | Workspace、Studio、协作、交付 |
三者是分析视角，并非互斥的产品分类。统一平台可以同时具备三类能力；早期 MVP 可以只覆盖其中一种或两种。
二、研究对象：平台管理的是什么？
2.1 平台核心对象模型
平台对象应区分定义、版本、部署、运行、业务与产物，避免把“Agent”当作所有实体的统称。推荐采用以下概念基线：
| 对象 | 作用 | 典型关系 |
|---|---|---|
| Organization / Tenant | 组织与隔离边界 | 拥有 Workspace 与资源配额 |
| Workspace | 团队协作与资源范围 | 包含 Project、Agent 资产 |
| Project / Studio | 业务工作单元 | 包含任务、流程、产物 |
| Agent Definition | 可编辑的 Agent 定义 | 产生 Agent Version |
| Agent Version | 不可变的发布快照 | 被 Deployment 引用 |
| Deployment | 可被调用的部署配置 | 管理 Runtime Instance |
| Runtime Instance | 实际运行承载单元 | 执行一个或多个 Run |
| Workflow Definition | 工作流定义 | 产生 Workflow Version |
| Task / Run | 任务与执行记录 | 包含步骤、事件与结果 |
| Artifact | 可交付的输出资产 | 绑定来源、版本与权限 |
| Integration / Credential | 外部资源连接 | 受租户与策略约束 |
这里的对象名是参考领域模型，并非强制每个平台使用相同数据库表或产品术语。例如，轻量平台可以暂不区分 Project 与 Studio；也可以将 Deployment 设计为逻辑发布目标而非专属容器。
2.2 三条贯穿平台的关键链路
开发与发布链路：创建 Agent Definition → 配置模型、工具、指令与权限 → 调试和评估 → 固化版本 → 发布或部署 → 对外提供调用入口。
业务执行链路：用户创建 Project/Task → 选择 Agent 与 Workflow → 平台校验身份、权限、预算和版本 → 提交执行 → 展示事件和状态 → 人工干预 → 交付 Artifact。
治理与运营链路：组织与租户配置 → 资源准入与配额 → 执行审计与成本计量 → 质量与安全评估 → 版本调整、停用、归档和数据处置。
这些链路横跨技术与产品章节，后续应以统一对象 ID、版本和事件关联，而不是分别建立互不相通的数据模型。
三、平台总体架构：从控制面到产品界面
3.1 参考逻辑架构
终端用户 / Agent 创建者 / 开发者 / 组织管理员
│
Web UI / Studio / CLI / SDK / Open API
│
┌────────────────── 平台控制面 ──────────────────┐
│ 组织与租户 / 身份权限 / Agent Registry │
│ Builder / Workflow 定义 / 版本与发布 │
│ 资源目录 / 集成管理 / 配额 / 策略 / 审计 │
└────────────────────┬──────────────────────────┘
│ 受控的部署与执行契约
┌────────────────── 平台执行面 ──────────────────┐
│ 接入网关 / Run 调度 / Runtime 管理 / Worker │
│ Agent Engine / Orchestration / 工具执行 │
│ 状态恢复 / 事件投递 / 运行隔离 │
└────────────────────┬──────────────────────────┘
│
模型 / 工具 / 知识 / 数据 / 外部系统
│
可观测性、策略、安全、计量、数据治理（跨层）此图是逻辑职责图，不是规定必须使用微服务或独立集群。单机 MVP 可以在一个进程中实现多个逻辑模块；随着租户数量、任务时长和可靠性要求增加，再拆分部署。
3.2 控制面与执行面的职责
控制面回答“允许什么、定义什么、部署什么、谁来使用”：负责对象定义、版本、配置、组织权限、配额、策略与生命周期。执行面回答“现在执行什么、由谁承载、执行到哪里、如何恢复”：负责 Run、Worker、执行引擎、任务事件、运行时资源与故障恢复。
二者通过明确的部署契约与运行契约连接。控制面发布新版本时，不应默默改变已运行任务的定义；执行面发生故障时，也不应绕过控制面策略自行扩大权限。安全策略的执行点可能分布于两侧，不能误解为“所有安全检查都只发生在控制面”。
3.3 技术架构与产品架构不是两套系统
Technical Architecture 研究后台如何实现；Product Architecture 研究用户如何完成目标。一个后台服务可能支撑多个产品功能，一个产品功能也可能依赖多个后台服务。例如 Agent 发布功能需要 Registry、版本管理、部署管理、权限、API 与审计；Studio 运行界面需要任务 API、事件流、Runtime Management、Artifact 服务和 HITL 控制机制。
四、第一章：Agent Platform 是什么？它如何工作？ - Fundamentals
章节目标：建立平台定义、对象、工作原理、类型、生命周期和架构原则的共同语言。完成后应能画出平台的概念架构、解释它与 Agent System 的区别，并判断某产品的能力边界。
| 编号 | 正式专题 | 研究重点 |
|---|---|---|
| 01 | 什么是 Agent Platform？ - Definition & Boundaries | 定义、边界、价值、成熟度 |
| 02 | Agent Platform 由什么构成？ - Core Components | 核心对象、角色、服务组成 |
| 03 | Agent Platform 如何运行？ - Platform Architecture | 控制面、执行面、端到端链路 |
| 04 | Agent Platform 有哪些类型？ - Platform Types | 开发、运行、应用等形态 |
| 05 | 平台如何管理各类对象及其生命周期？ - Lifecycle Management | 定义、版本、部署、Run、产物 |
| 06 | 如何设计 Agent Platform 的架构？ - Design Principles | 模块化、隔离、可扩展与演进 |
章节产出：平台定义与边界说明、概念对象图、参考架构图、平台类型比较、对象生命周期图、设计原则与权衡清单。
五、第二章：Agent Platform 是如何构建和运行的？ - Technical Architecture
章节目标：将平台拆解为可实现、可集成、可测试的平台服务与架构责任，明确控制面、执行面及其依赖，避免重复研究 03 Agent System 的内部执行算法。
| 编号 | 正式专题 | 研究重点 |
|---|---|---|
| P1 | 平台如何统一管理和控制 Agent？ - Control Plane | 管理 API、期望状态、协调 |
| P2 | 平台如何执行和承载 Agent 任务？ - Execution Plane | 执行资源、任务承载、隔离 |
| P3 | 如何注册、存储和管理 Agent 定义与版本？ - Agent Registry | 定义存储、版本、依赖 |
| P4 | 平台如何提供 Agent 构建与开发服务？ - Agent Development Services | 构建、校验、调试服务 |
| P5 | 如何管理 Agent 的部署、实例与运行生命周期？ - Deployment & Runtime Management | 部署、实例、升级、恢复 |
| P6 | 如何管理和调度 Agent 工作流？ - Workflow Management | 定义管理、提交、调度对接 |
| P7 | 如何统一管理模型、工具和外部资源？ - Resource & Integration | 资源目录、连接、凭据 |
| P8 | 平台如何提供统一的 API 与 SDK？ - Platform API & SDK | 接口契约、SDK、兼容性 |
| P9 | 如何支持插件、扩展与第三方集成？ - Extensibility & Ecosystem | 扩展点、插件、生态机制 |
| P10 | 如何管理平台的数据、产物与共享资产？ - Platform Data & Assets | 资产目录、归属、血缘、存储 |
| P11 | 如何管理多租户、组织与工作空间隔离？ - Multi-tenancy & Isolation | 租户模型、隔离、组织边界 |
| P12 | 如何管理平台权限、资源配额与治理策略？ - Platform Governance | 权限、配额、策略执行、审计 |
5.1 四组需要保持清晰的技术边界
P1 与 P2：控制面管理定义、策略与期望状态；执行面管理实际运行、任务进度与计算资源。两者不要求物理分离，但职责和数据契约应分离。
P3、P4 与 P5：Registry 保存可复用定义和版本；Development Services 支持构建、调试、验证；Deployment & Runtime Management 将版本转化为可调用的部署与实例。三者对应“定义 - 开发 - 运行”，避免 Builder 直接修改生产实例。
P6 与 03 Agent System 的 L5：P6 研究平台如何保存、配置、发布、授权和调度工作流；L5 研究工作流及多 Agent 协作在执行时如何编排。平台可以调用 L5 的现有引擎，而不重复实现调度算法。
P7、P9、P10、P11 与 P12：资源接入、扩展机制、资产管理、租户隔离与治理策略是不同职责。插件安装不自动赋予资源权限；资产共享不自动取消租户边界；配额限制不替代身份授权。
5.2 研究深度要求
每个技术专题至少回答：职责与非职责、核心对象和 API、控制流与数据流、关键状态转移、失败与恢复、权限与隔离、可观测性、替代架构与选型依据、最小可行实现及验证方法。对于未实际运行的代码，应标明“参考设计”或“伪代码”，不得写成已验证结果。
章节产出：逻辑组件图、核心 API 契约、对象 Schema、部署拓扑、权限矩阵、关键序列图、平台服务依赖图和工程验收标准。
六、第三章：Agent Platform 应该提供哪些产品功能？ - Product Architecture
章节目标：从用户目标而非后台服务出发，设计 Agent 创建、开发、发布、使用、协作、交付与管理的完整产品体验。
| 编号 | 正式专题 | 研究重点 |
|---|---|---|
| F1 | 用户如何创建一个 Agent？ - Agent Creation | 创建入口、模板、初始化 |
| F2 | 用户如何配置和修改 Agent 的能力？ - Agent Configuration | 模型、指令、工具、权限 |
| F3 | 用户如何开发、调试和测试 Agent？ - Agent Development & Testing | 调试器、测试、反馈 |
| F4 | 用户如何发布、共享和复用 Agent？ - Agent Publishing & Sharing | 发布、可见性、模板、复用 |
| F5 | 用户如何组织和管理工作空间与项目？ - Workspace & Project Management | Workspace、Project、Studio |
| F6 | 用户如何启动、操作和控制 Agent？ - Agent Execution | 启动、暂停、取消、审批 |
| F7 | 用户如何组织多个 Agent 协同工作？ - Agent Collaboration | 团队、流程、任务分配 |
| F8 | 用户如何查看 Agent 的运行状态与结果？ - Agent Monitoring | 状态、轨迹、错误、成本 |
| F9 | 用户如何管理 Agent 的版本与生命周期？ - Agent Management | 版本、回滚、停用、归档 |
| F10 | 用户如何管理任务产物与交付成果？ - Artifact & Delivery Management | 文件、版本、审核、导出 |
| F11 | 开发者如何通过 API 与 SDK 集成平台能力？ - Developer Experience | 文档、密钥、示例、调试 |
| F12 | 管理员如何管理整个平台？ - Platform Administration | 组织、成员、配额、审计 |
6.1 四类核心用户
Agent 创建者：需要低摩擦地创建、配置、测试、发布和维护 Agent。业务使用者：需要将 Agent 用于具体任务，理解当前进度，控制风险并取得成果。开发者：需要稳定 API、SDK、测试环境和可解释的错误信息。组织管理员：需要管理人员、权限、预算、数据范围和审计责任。
产品功能不必在每个界面向所有角色同时暴露。平台可以通过角色和任务情境提供不同入口，但底层身份、对象和权限模型应保持一致。
6.2 典型用户旅程
Agent 创建旅程：选择创建方式 → 设定角色与目标 → 配置模型、工具、知识和权限 → 调试与测试 → 固化版本 → 发布到工作空间或 API。
Studio 业务旅程：创建研究项目 → 选择 Agent 团队与 Workflow → 配置研究要求 → 启动任务 → 观察任务图和执行事件 → 审核选题与关键产物 → 处理返工 → 导出最终报告。
管理员旅程：创建组织 → 邀请成员 → 设置工作空间权限 → 配置资源连接和预算 → 审核发布与共享策略 → 查看使用、成本与审计记录。
6.3 技术与产品的关键映射
| 产品功能 | 主要技术依赖 |
|---|---|
| F1 - F2 - F3 创建与开发 | P3、P4、P7、P12 |
| F4、F9 发布与版本 | P3、P5、P12 |
| F5 工作空间与项目 | P10、P11、P12 |
| F6 - F7 - F8 执行与协作 | P1、P2、P5、P6 |
| F10 产物交付 | P8、P10、P12 |
| F11 开发者体验 | P8、P9 |
| F12 平台管理 | P1、P11、P12 |
映射表示主要依赖，不是完整调用链。例如 F8 的观测界面还需要依赖 03 Agent System 中 H1 的可观测性能力；F6 的审批操作还需要 H6 的人工介入机制。
章节产出：用户角色与权限、信息架构、功能地图、用户旅程、关键页面规格、交互状态、错误处理、产品验收场景及 MVP 优先级。
七、第四章：如何开发、部署和维护 Agent Platform？ - Engineering & Practice
章节目标：将前面形成的技术架构和产品架构转化为可执行的工程计划，并建立持续交付与改进机制。
| 编号 | 正式专题 | 研究重点 |
|---|---|---|
| 01 | 有哪些值得研究的 Agent Platform？ - Platform Case Studies | 平台案例、能力矩阵、差异 |
| 02 | 如何选择 Agent Platform 的技术框架？ - Technology Selection | 自建与集成、框架选型 |
| 03 | 如何设计 Agent Platform 的系统架构？ - System Design | 领域模型、接口、拓扑、权衡 |
| 04 | 如何分阶段开发 Agent Platform？ - Development Roadmap | MVP、里程碑、演进路径 |
| 05 | 如何部署和运维 Agent Platform？ - Deployment & Operations | CI/CD、扩容、运维、恢复 |
| 06 | 如何验证和持续改进 Agent Platform？ - Testing & Optimization | 测试、质量、成本、体验 |
7.1 建议的渐进式开发路线
阶段 0：需求与边界验证。 选定一个明确的用户群与高频任务，定义最小产品价值；确认需要开发平台、运行平台还是应用平台的哪部分能力。产出用户旅程、对象模型、非目标清单和验收标准。
阶段 1：单租户可用 MVP。 实现 Agent 创建与配置、一个可用的 Runtime 接口、任务启动与状态展示、基本产物管理。允许先使用现成执行引擎与单体后端，避免过早建设复杂微服务。
阶段 2：可复用的平台能力。 增加 Agent 版本、Workflow 定义、工作空间、API、权限、审计、测试与发布流程。让不同项目可以复用同一 Agent 资产。
阶段 3：团队化与可靠运行。 增加组织权限、运行恢复、审批、成本计量、资源配额、任务队列、告警与回滚。验证长任务、并发任务和故障情况下的行为。
阶段 4：多租户与生态扩展。 按实际需求引入更严格的租户隔离、插件与 SDK、共享资产机制、规模化部署及运营分析。是否实现公开市场、计费与商业化，取决于产品目标而非“完整平台”的硬性要求。
每个阶段都必须有可演示的业务闭环和明确的通过标准，而不是仅以代码模块数量衡量进度。
7.2 关键技术决策
优先决定：自建还是集成 Agent Runtime；单体还是拆分控制面与执行面；Agent 与 Workflow 的版本绑定方式；Run 的持久化和恢复策略；工具执行权限边界；Workspace 与 Tenant 的隔离模型；产物的存储、共享与删除机制；API 与 UI 的统一领域契约。这些决策会影响后续迁移成本，应记录为 Architecture Decision Record（ADR）。
八、贯穿案例：研究报告 Studio 如何体现完整平台能力？
8.1 业务需求
研究团队希望通过一个 Studio 创建研究项目，使用选题、调研、分析、审核和写作等 Agent 组成协作流程。用户能够设定研究范围，观察阶段进展，批准关键决策，要求返工，最终取得可追溯的研究报告。
8.2 从平台对象到实际执行
- 管理员创建 Workspace，配置成员、预算与工具访问权限。
- Agent 创建者在 Builder 中定义选题 Agent、调研 Agent、审核 Agent，并发布不可变版本。
- Workflow 创建者定义“选题 → 审核 → 调研 → 写作 → 发布”的流程及其审批节点。
- 用户创建 Project，选择 Workflow 版本，提交任务要求。
- 控制面检查身份、权限、版本、配额和资源连接，创建 Task 与 Run。
- 执行面调度 Agent System，持续产生运行事件和 Artifact 版本。
- Studio 界面通过状态 API 与事件流展示进度；用户可以审核、返工或取消。
- 发布动作验证报告版本、审批和权限，生成可交付产物及审计记录。
- 管理员查看成本、质量与运行情况，决定是否调整 Agent 或 Workflow 的后续发布版本。
8.3 最小可验收业务闭环
一个可用的最小版本不需要实现所有 36 个专题，但至少应能证明：用户能创建任务；系统能调用一个或多个 Agent；执行状态可见；关键操作有权限检查；结果可保存与获取；失败有明确状态；用户可以复现或追踪某次执行使用的 Agent 与 Workflow 版本。
当进入多租户生产环境后，还必须进一步验证租户隔离、资源配额、凭据保护、任务恢复、审计和数据生命周期等能力。MVP 可用与生产平台可信是不同的验收层级。
九、跨领域引用与避免重复研究的原则
| 第四领域主题 | 优先引用的既有领域 |
|---|---|
| 模型与推理 | 01 AI：Model Engineering |
| Agent 内部定义与能力 | 02 Agent：Internal Architecture |
| Agent 执行循环 | 03 Agent System：L4 Agent Engine |
| 多 Agent 编排算法 | 03 Agent System：L5 Orchestration |
| 应用任务 API | 03 Agent System：L6 Application |
| 可观测与评估 | 03 Agent System：H1、H3 |
| 安全、状态与配置 | 03 Agent System：H2、H4、H5 |
| 审批、可靠性与预算 | 03 Agent System：H6、H7、H8 |
| 数据、测试、运维、治理 | 03 Agent System：H9 - H10 - H11 - H12 |
第四领域的研究重点是如何把这些能力抽象成平台服务、平台对象、产品流程与管理机制。例如，H4 研究 Checkpoint 如何工作；P5 研究平台如何管理运行实例并为用户暴露恢复操作；F6 研究用户如何理解并触发恢复。三者研究对象不同，但需要共享同一运行状态语义。
十、研究方法、写作标准与验收方式
10.1 每篇专题的研究框架
后续 36 篇专题均使用七项元数据、专题导读、研究结论、参考资料附录及证据/验证边界附录；正文结构根据主题灵活设计。研究应优先回答实际问题，再展开原理、架构、实现、权衡与案例，避免为了统一格式而堆叠相同小标题。
技术专题需要明确接口、数据结构、状态机、控制流、权限与故障语义；产品专题需要明确用户、场景、任务、界面状态、交互与验收标准；工程专题需要明确前提、依赖、步骤、风险、验收和回滚。
10.2 证据分级
- 规范或官方事实：以公开规范、官方文档、源代码或可复核的产品文档为依据，注明版本与适用条件。
- 工程推论与设计建议：明确标记为建议或参考架构，不冒充行业强制标准。
- 案例假设：标注为示例，不将虚构性能指标、成本和用户结果表述为真实测量。
- 实验结果：仅在实际执行后报告测试环境、方法、输入、输出和局限；未运行的示例代码不宣称“已验证”。
10.3 领域完成的验收标准
完成 04 Agent Platform 研究，不仅意味着写完 36 篇文章，还应能交付：一份统一术语表与领域对象模型、一张技术与产品能力映射图、一套可落地的参考架构、一组关键 API 与状态契约、一份可执行 MVP 路线图，以及一个能够演示 Agent 创建 - 执行 - 交付 - 管理的最小端到端案例。
十一、研究结论
- Agent Platform 的核心价值是能力的平台化：把 Agent 与 Agent System 转化为多角色可创建、可复用、可治理的软件能力，而不是简单增加一个可视化界面。
- 控制面与执行面是理解平台架构的重要视角，但不等同于强制的物理部署方式。早期可以单体实现，后期根据隔离、可靠性与规模要求演进。
- 平台对象模型是技术与产品之间的共同语言。Agent Definition、Version、Deployment、Run、Workspace、Project 和 Artifact 等对象必须明确其身份、归属、版本和生命周期。
- 技术架构与产品架构必须互相映射。后台服务提供可控能力，产品界面帮助用户完成任务；二者不能各自独立设计。
- Agent Platform 可以有不同产品形态。开发、运行和应用三种侧重可以组合，MVP 不必一次实现全部能力。
- 平台级治理需要跨层落地。权限、租户隔离、成本、审计、数据治理和人工审批必须落实到可信服务端与执行边界，而非仅依赖前端限制。
- 本领域的最终目标是具备实际建设能力：能够根据明确的业务需求，设计、开发、部署和持续改进一个 Agent Platform，并通过可验证的工程证据判断其质量。
附录 A：参考文献与原始资料
以下资料用于后续专题的技术核验与案例比较。官方产品文档描述的是各自产品的实现，不代表所有 Agent Platform 的统一规范。本篇主要依据用户确定的 v1.3 知识地图进行体系组织；下列链接作为后续深入研究的参考入口，未逐页核验截至本文日期的全部版本细节。
- [R1] Kubernetes Documentation - Concepts / Architecture：kubernetes.io/docs/concepts/architecture
- [R2] OpenTelemetry Documentation：opentelemetry.io/docs
- [R3] OpenAI Agents SDK Documentation：openai.github.io/openai-agents-python
- [R4] LangGraph Documentation：docs.langchain.com/oss/python/langgraph/overview
- [R5] Temporal Documentation：docs.temporal.io
- [R6] Model Context Protocol - Introduction：modelcontextprotocol.io/introduction
- [R7] Dify Documentation：docs.dify.ai
- [R8] Microsoft AutoGen Documentation：microsoft.github.io/autogen/stable
- [R9] NIST AI Risk Management Framework：www.nist.gov/itl/ai-risk-management-framework
- [R10] OWASP Top 10 for LLM Applications：genai.owasp.org/llm-top-10
附录 B：研究证据、验证声明与适用边界
资料来源：本篇目录、专题名称及数量直接依据当前对话中确认的《Agent 全栈技术地图》v1.3 候选结构；平台定义、对象模型、架构示意、开发阶段和验收清单属于基于该目录组织的研究性归纳与工程建议。
验证声明：本篇为领域总览与研究规划，未部署真实平台，未执行端到端性能、可靠性、安全或多租户隔离测试。参考架构与案例流程不构成生产可用性证明。附录 A 为官方参考入口，未对每个产品的当前版本特性进行逐项实测。
适用范围：适用于希望理解、设计、构建或评估 Agent 开发平台、运行平台和应用平台的学习者与工程团队。不同产品在规模、合规、部署和商业模式上可能采用不同实现；本篇给出统一研究框架，不强制所有平台实现全部能力。
后续研究顺序：先完成 04 Agent Platform → 01 Fundamentals 的章节概述，再依次研究该章六个专题；之后进入 02 Technical Architecture 的章节概述与 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12、03 Product Architecture 的章节概述与 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12，最后研究 04 Engineering & Practice 的章节概述与六个工程专题。