huaAgentStudyAgent

外观

zmh.life

02 · Agent Platform 是如何构建和运行的？ - Technical Architecture - 章节概述与研究导读 ​

所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：02 · Agent Platform 是如何构建和运行的？ - Technical Architecture
文档类型：章节概述 / 技术架构研究总纲 / 专题导航
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：如何将 Agent Platform 的概念、对象模型和设计原则转化为可实现、可运行、可扩展、可治理的技术架构？P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 分别承担哪些职责，如何协作，以及如何验证平台的关键技术性质？

专题导读 ​

本篇属 Agent Platform。本章是《Agent 全栈技术地图》04 · Agent Platform 的技术实现核心章节。上一章 Fundamentals 已回答平台的定义、组成、运行架构、类型、对象生命周期和设计原则。本章进一步研究：平台怎样接收开发者与用户的操作，怎样管理 Agent 定义和版本，怎样授权并启动任务，怎样接入模型与工具，怎样提供开放接口，怎样管理数据、租户、权限与资源，最终形成能够被持续运营的平台。

本章严格遵循 v1.3 的 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 正式目录。十二个专题构成的是技术职责地图，而非十二个必须独立部署的微服务，也不应被误读为单一线性的调用链。P1、P2 提供控制与执行的总体视角；P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 细化贯穿控制面、执行面及共享平台服务的具体能力。一个平台组件可能服务多个专题，一个专题也可能横跨多个进程和基础设施。

本章研究主线：以稳定对象模型为基础，以控制面与执行面的职责分离为骨架，以接口、事件和状态机为协作契约，以安全隔离、版本追溯和资源约束为底线，以端到端任务完成与可恢复性为最终检验。

一、章节定位：从“知道平台是什么”到“能够设计平台” ​

1.1 与前三个领域及相邻章节的边界 ​

知识范围主要研究对象本章继承或新增的重点
01 · AI模型调用、上下文、知识检索继承模型 API、路由与检索原理；研究平台如何统一接入、分配和治理这些资源
02 · Agent单个 Agent 的身份、指令、工具与行为继承 Agent 的能力结构；研究如何注册、版本化、部署与复用 Agent 定义
03 · Agent SystemAgent Engine、编排、状态、可靠性与治理继承运行机制；研究平台如何承载、调度、接入和管理一个或多个 Agent System
04-01 · Fundamentals平台定义、组件、对象、生命周期与原则将概念模型转为可实现的服务职责、接口、数据模型和运行约束
04-03 · Product Architecture用户功能、工作空间、开发与交付体验本章定义技术支撑，不替代 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 的产品交互研究
04-04 · Engineering & Practice选型、系统设计、开发、部署与优化本章研究通用技术机制；工程章结合实际项目确定实现、验收与演进方案

特别注意：03 Agent System 的 L4 Agent Engine 与 L5 Orchestration 解释单次或多 Agent 任务在系统内部如何运行；本章 P2、P5、P6 研究平台怎样为这些系统提供执行承载、运行实例管理、任务准入、工作流注册与平台级调度。二者存在接口关系，但不应重复写同一套推理循环或编排算法。

1.2 完成本章应具备的能力 ​

  1. 画出 Agent Platform 的逻辑组件图、控制流/数据流图及最小部署图，解释三者区别。
  2. 明确 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 的职责、管理对象、输入输出、依赖关系和故障边界。
  3. 区分 Agent Definition、Agent Version、Deployment、Runtime Instance、Run、Attempt、Workflow Version、Artifact 等对象，给出稳定标识和引用规则。
  4. 设计创建、发布、启动、暂停、审批、恢复、取消、归档等操作的接口契约及状态转换约束。
  5. 说明平台如何实现租户隔离、最小权限、配额、审计与资源访问控制。
  6. 说明平台如何通过 API/SDK、插件机制和资源适配层实现扩展，而不将内部实现暴露为不稳定的公共契约。
  7. 制定幂等、事件交付、故障恢复、版本回滚和可观测性的验证方案，并区分已测证据与待测假设。
  8. 针对研究报告 Studio 设计一个可落地的单租户 MVP 技术架构，并解释向团队化、多租户平台演进的条件。

二、十二个专题的正式目录与研究任务 ​

编号v1.3 正式专题名称核心研究问题预期技术产物
P1平台如何统一管理和控制 Agent？ - Control Plane如何执行定义管理、策略决策、任务准入和生命周期控制？控制面职责图、命令 API、状态机、控制循环
P2平台如何执行和承载 Agent 任务？ - Execution Plane如何接收任务、分配执行资源、隔离工作负载和反馈状态？执行面拓扑、Worker 契约、任务执行时序、故障边界
P3如何注册、存储和管理 Agent 定义与版本？ - Agent Registry如何组织 Agent 定义、不可变版本、引用与发布元数据？注册表模型、版本契约、依赖快照、迁移规则
P4平台如何提供 Agent 构建与开发服务？ - Agent Development Services如何支持配置、验证、调试、测试及构建产物生成？构建服务架构、校验管线、开发 API、预览环境
P5如何管理 Agent 的部署、实例与运行生命周期？ - Deployment & Runtime Management如何管理部署、运行实例、Run/Attempt、升级和回滚？生命周期状态机、部署控制器、恢复与回滚方案
P6如何管理和调度 Agent 工作流？ - Workflow Management如何注册工作流、调度执行、处理依赖与审批？工作流定义模型、调度契约、事件与状态关系
P7如何统一管理模型、工具和外部资源？ - Resource & Integration如何接入、授权、配置、限流和治理资源？资源目录、凭据绑定、适配器接口、调用策略
P8平台如何提供统一的 API 与 SDK？ - Platform API & SDK如何向客户端和外部系统提供稳定、可版本化的能力？OpenAPI、SDK 契约、认证、错误与事件协议
P9如何支持插件、扩展与第三方集成？ - Extensibility & Ecosystem如何设计扩展点、插件安装、权限、兼容与隔离？扩展点模型、插件清单、生命周期和沙箱策略
P10如何管理平台的数据、产物与共享资产？ - Platform Data & Assets如何管理对象元数据、文件、产物、血缘、保留和共享？数据分类、存储边界、资产关系与保留策略
P11如何管理多租户、组织与工作空间隔离？ - Multi-tenancy & Isolation如何定义租户边界、身份映射、隔离与跨租户防护？租户模型、授权边界、隔离矩阵、负向测试
P12如何管理平台权限、资源配额与治理策略？ - Platform Governance如何统一实施授权、配额、预算、审计和治理决策？策略执行链、配额模型、审计证据、例外流程

顺序解释：P1/P2 先建立运行骨架；P3 - P4 - P5 - P6 研究 Agent 与工作流的开发、发布和执行管理；P7 - P8 - P9 - P10 研究资源、开放接口、扩展和资产；P11/P12 研究跨模块的隔离与治理。P11/P12 虽排在后面，但其约束应从 P1 开始贯穿设计，不能等最后才补。

三、平台总体技术架构：四个互补视图 ​

3.1 能力视图（Capability View） ​

text
开发与管理：Agent 定义 / 版本 / 构建 / 发布 / 部署
运行与协作：准入 / 调度 / 执行 / 工作流 / 运行控制
开放与集成：API / SDK / 资源目录 / 连接器 / 插件
数据与资产：对象元数据 / 文件 / 产物 / 事件 / 血缘
治理与运营：身份 / 授权 / 租户 / 配额 / 预算 / 审计

这是能力清单，不是网络拓扑；同一能力可以由多个技术组件协作实现。

3.2 逻辑组件视图（Logical Component View） ​

mermaid
flowchart TB
    U[用户 / 开发者 / 管理员 / 外部系统]
    UI[Web UI / CLI / SDK]
    GW[API Gateway / Platform API]
    CP[Control Plane\n定义/发布/准入/策略/运行控制]
    REG[Agent Registry / Development Services]
    WF[Workflow & Deployment Management]
    RES[Resource Catalog / Integrations / Plugins]
    EX[Execution Plane\nQueue / Scheduler / Workers / Runtime Adapters]
    GOV[Identity / Tenant / Policy / Quota / Audit]
    DATA[Metadata DB / Event Log / Object Storage]
    OBS[Observability]
    U --> UI --> GW --> CP
    CP --> REG
    CP --> WF
    CP --> GOV
    CP --> EX
    EX --> RES
    REG --> DATA
    WF --> DATA
    EX --> DATA
    GOV --> DATA
    CP --> OBS
    EX --> OBS

此图是研究性逻辑模型。例如 API Gateway 并非每个 MVP 必需的独立组件；Registry 与 Control Plane 可能位于同一进程；运行器可以是外部服务。图中箭头表示主要依赖方向，不表示所有同步/异步调用。

3.3 运行视图（Runtime View） ​

应同时追踪四条流：①命令流：创建、发布、启动、取消等操作；②执行流：任务被分配到 Worker 或外部 Runtime；③事件与状态流：运行状态、进度、工具调用与审批信号；④数据与产物流：输入文件、知识资源、检查点、输出报告和审计证据。不要把“请求成功返回 Run ID”误写为“任务已执行成功”。

3.4 部署视图（Deployment View） ​

最小实现可以是：一个 Web 前端、一个模块化后端、一个持久化数据库、一个异步 Worker，以及按需配置的队列/对象存储。逻辑控制面和执行面分责，不意味着必须采用 Kubernetes、微服务、服务网格或多集群。只有在吞吐、隔离、可用性和团队组织约束得到验证时，才逐步拆分部署单元。

四、平台核心对象模型与不可变约束 ​

4.1 对象及其责任归属 ​

对象最小语义主要专题关键约束
Tenant / Organization组织与安全边界P11/P12每个受保护对象有可验证的归属
Workspace / Project业务与协作容器P10/P11资源继承与共享必须显式授权
Agent Definition可编辑的 Agent 逻辑定义P3/P4与已发布版本分离
Agent Version可复现的定义快照P3已发布版本原则上不可原地修改
Workflow Definition / Version流程结构与固定版本P6Run 引用具体版本
Deployment版本与环境、资源、策略的绑定P5升级与回滚可追踪
Runtime Instance实际执行承载实体P2/P5实例身份不等于 Run 身份
Run / Attempt任务执行与重试尝试P1/P2/P5/P6独立 ID、状态与幂等语义
Resource Binding资源访问配置与授权关系P7/P12凭据与定义分离、运行时校验
Artifact可持久化的执行产物P10所属、版本、保留与访问可追踪
Plugin Installation插件版本与权限授权P9/P12安装与执行权限独立控制
Audit Record不可随意篡改的操作证据P12记录主体、动作、对象、决策与时间

4.2 核心关系示意 ​

text
Tenant ── Workspace ── Project / Studio
                │
                ├── Agent Definition ── Agent Version ── Deployment
                │                                         │
                ├── Workflow Definition ── Workflow Version│
                │                                         ▼
                └── Run ── Attempt ── Runtime Instance ── Artifact
                      │
                      └── Resource Binding / Policy Decision / Audit Event

上述图是关系示意，并非严格的数据库外键图。一个 Run 可以引用 Agent Version 和 Workflow Version，运行实例可复用或按任务创建；具体基数、外键及所有权应在 P3/P5/P6/P10/P11 中分别确定。

4.3 不变量（Invariants） ​

  • 已发布的 Agent Version 不应被静默覆盖；若要变更，创建新版本并记录引用关系。
  • 每个 Run 应记录实际执行的 Agent/Workflow 版本及必要的配置快照或可验证引用。
  • 每次状态转换必须经过服务端授权与合法性检查；前端显示状态不是可信事实来源。
  • 同一幂等键在定义的作用域内重复提交，不应产生意外的重复业务执行；具体保证范围需明确。
  • 跨租户访问默认拒绝；共享必须经明确授权，并可审计。
  • 密钥、令牌等敏感资源不应被直接固化到 Agent 版本、日志或产物中。
  • 删除或撤销对象时，应检查下游引用、保留要求与正在执行的 Run。

这些是本知识库建议的设计约束；具体实现应结合安全要求、业务语义与验证结果确定。

五、端到端主链路：从 Agent 创建到报告交付 ​

以“研究报告 Studio”为贯穿案例：用户创建一个研究项目，配置选题 Agent、调研 Agent、审核 Agent，选择工作流版本，启动研究任务，必要时人工批准，最终获得报告产物。

mermaid
sequenceDiagram
    actor User as 用户
    participant API as Platform API
    participant CP as Control Plane
    participant REG as Registry/Workflow
    participant GOV as Policy & Quota
    participant EX as Execution Plane
    participant RT as Agent System Runtime
    participant STORE as Metadata & Artifact Store
    User->>API: 创建/配置 Agent 与 Workflow
    API->>REG: 保存草稿、验证、生成版本
    REG-->>API: 版本引用
    User->>API: 启动研究 Run (idempotency key)
    API->>CP: 提交 Run 请求
    CP->>GOV: 身份/租户/配额/策略校验
    GOV-->>CP: 允许或拒绝 + 决策证据
    CP->>REG: 解析不可变版本与资源绑定
    CP->>STORE: 创建 Run 记录（已受理）
    CP->>EX: 分派执行请求
    EX->>RT: 启动 Agent System
    RT-->>EX: 事件/进度/检查点/产物引用
    EX->>STORE: 持久化状态、事件、产物
    EX-->>CP: 完成/失败/等待审批
    CP-->>API: 查询与订阅的状态更新
    API-->>User: 状态、审批入口、报告链接

关键点：受理、排队、运行、等待审批、完成是不同状态；在审批等待期间可能释放执行资源，但必须保存恢复所需状态。状态和事件可能延迟或重复；应设计单调序列、去重键或其他一致性机制，不能依赖消息总是严格按序且恰好一次到达。

六、P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 的职责边界与交叉关系 ​

6.1 P1 Control Plane 与 P2 Execution Plane ​

P1 负责“允许什么运行、按哪个版本运行、如何改变生命周期”；P2 负责“在哪里执行、如何执行、如何隔离工作负载、如何报告结果”。平台可以将二者部署在同一应用中，但需要不同的职责契约。P1 不应直接承担长时间模型推理；P2 不应绕过 P1/P12 自行扩大权限。

6.2 P3 Registry、P4 Development Services、P5 Runtime Management ​

P3 管理可引用的定义与版本；P4 提供构建、校验、调试与开发流程服务；P5 管理部署与运行对象。例如“在 Builder 中修改提示词”属于 P4 的编辑与验证流程；“生成版本 v7”归 P3；“将 v7 部署到 staging”归 P5。产品界面 F1 - F2 - F3 - F4 可将这些操作串成连续体验，但技术职责仍须区分。

6.3 P5 Runtime Management 与 P6 Workflow Management ​

P5 关注部署、实例、Run/Attempt 生命周期；P6 关注工作流定义、节点依赖、任务调度和协作语义。工作流引擎可以由 Agent System 提供，平台只负责注册、触发和观测；也可以由平台承载。必须在接口中说明谁是 Run 状态的权威来源、谁负责恢复以及失败重试的所有权。

6.4 P7 Resource & Integration 与 P9 Extensibility & Ecosystem ​

P7 管理平台已有或已接入的模型、工具、知识、凭据及外部资源的目录、配置和访问；P9 研究如何让第三方通过插件协议、扩展点、安装机制与兼容策略增加平台能力。一个插件可能注册一个资源适配器，但“资源调用管理”和“插件生命周期管理”并非同一职责。

6.5 P8 Platform API & SDK 与 P4/P9 ​

P8 研究对外稳定契约、认证、分页、错误语义、流式事件、SDK 版本和兼容；P4 是 Agent 开发服务，P9 是扩展机制。API 是访问能力的方式，不是所有能力的所有者。避免让 API Gateway 直接承载业务状态机或权限策略。

6.6 P10 Data & Assets、P11 Multi-tenancy、P12 Governance ​

P10 定义数据分类、持久化、共享、血缘、保留与删除；P11 定义组织和租户隔离边界；P12 统一权限、配额、预算、策略与审计。三者是横切职责：数据访问必须结合租户与授权，执行准入必须结合配额，删除资产必须结合保留策略和审计要求。

七、横切设计问题：每篇专题都必须回答 ​

横切问题最低研究要求典型反例
身份与授权谁发起操作，谁有权访问什么对象只在前端隐藏按钮
租户隔离对象、数据、计算与凭据的隔离边界查询遗漏 tenant_id 过滤
版本与追溯Run 引用的定义/资源/策略版本运行中静默更新提示词
状态与一致性状态来源、事件去重、失败补偿假设消息恰好一次送达
可靠性超时、重试、取消、恢复与幂等失败后无条件重跑外部副作用
资源成本配额、并发、预算、限流与计量Agent 无限循环调用模型
可观测与审计Trace、Run ID、操作证据和敏感信息脱敏仅保留无关联的文本日志
安全边界工具权限、密钥、网络和插件隔离将平台管理员凭据交给 Worker
开放兼容API/SDK/插件的版本契约修改内部表结构导致外部 SDK 失效
数据生命周期产物归属、共享、保留、归档与删除删除 Agent 后产物引用全部失效

这些要求应体现在专题正文、接口示例和测试方案中，而不是仅在 P11/P12 两篇末尾补充。

八、技术架构的典型设计决策与权衡 ​

8.1 模块化单体还是微服务 ​

默认先明确模块边界、对象所有权和接口契约；若规模较小、团队人数有限，模块化单体加独立 Worker 往往更容易调试和部署。微服务适用于需要独立扩缩容、故障隔离、不同团队独立交付或特定合规边界的情况，但会增加网络失败、分布式一致性与运维成本。微服务数量不是平台成熟度指标。

8.2 同步调用还是异步任务 ​

创建草稿、读取配置、校验简单字段适合同步请求；长时间研究、外部工具调用和多 Agent 工作流更适合异步 Run。API 返回 Run ID 后，客户端通过轮询、SSE、WebSocket 或事件订阅获取进度。应定义重连、事件序列、状态快照和最终结果读取机制。

8.3 平台自建 Runtime 还是集成已有执行引擎 ​

平台可自行开发运行器，也可通过适配器调用现有 Agent System/Runtime。选择依据包括可控性、恢复能力、运行成本、模型工具生态、部署约束与供应商锁定。若采用外部 Runtime，必须明确任务 ID 映射、事件标准化、取消语义、重试所有权和状态一致性。

8.4 单租户、多租户与资源隔离 ​

初期可以单租户，但数据模型应预留清晰的所有权和授权边界。多租户并非单一开关：身份、数据库行级访问、对象存储路径、缓存、消息队列、执行容器、凭据与计费均可能形成不同隔离层。应依据风险模型选择逻辑隔离、独立数据库、独立执行资源或混合模式，并用负向测试证明。

8.5 数据库、事件与对象存储的职责 ​

关系型数据库适合平台对象和状态记录；对象存储适合较大文件与报告产物；队列或事件总线适合异步任务与事件传递。不要将队列消息当作唯一的长期业务事实，也不要将大文件直接混入高频状态表。采用事务性 Outbox 等模式时，应明确交付语义与消费者幂等要求。

九、Studio 贯穿案例：从 MVP 到平台化 ​

9.1 最小可运行范围 ​

目标：让一个用户创建研究 Studio、配置 Agent/Workflow、启动异步研究、查看进度、人工审核、恢复任务并下载产物。此时不强制建设插件市场、复杂多租户计费或跨区域调度。

建议逻辑模块：Identity、Workspace、Agent Registry、Workflow Registry、Run Control、Resource Catalog、Artifact、Audit；部署上采用 Web 前端 + 模块化后端 + 数据库 + Worker，按需求加入对象存储和队列。模型/工具调用通过独立适配层管理密钥与超时。

9.2 参考 API 契约（教学示例，非现有产品 API） ​

http
POST /v1/agents
POST /v1/agents/{agent_id}/versions
POST /v1/deployments
POST /v1/runs
GET  /v1/runs/{run_id}
POST /v1/runs/{run_id}:cancel
POST /v1/runs/{run_id}:approve
GET  /v1/runs/{run_id}/events
GET  /v1/runs/{run_id}/artifacts

POST /v1/runs 应校验调用者权限、资源绑定、预算/配额与版本引用，并定义幂等键的作用域和过期策略。approve 需验证审批者身份、审批状态和审批动作的幂等性；取消并不保证已经发生的外部副作用能够撤销。上述端点名称仅用于展示资源边界。

9.3 阶段演进与升级触发条件 ​

阶段主要能力进入下一阶段的证据
S0 概念验证单任务、固定 Agent、基本产物证明真实业务价值与核心流程
S1 单租户 MVP定义/版本、异步 Run、审批、审计可重复完成端到端任务，失败可诊断
S2 团队化平台Workspace、角色权限、共享资产多成员协作与权限测试通过
S3 多租户平台租户隔离、配额、组织管理跨租户负向测试、负载与成本验证
S4 生态扩展API/SDK、插件、模板、开放集成稳定契约、兼容测试、第三方采用证据

此表是建议的演进路径，不是所有平台都必须经历的固定成熟度等级；开放 API 也可能在 MVP 阶段出现，取决于业务需要。

十、研究方法与证据标准 ​

10.1 每篇 P 专题的建议研究结构 ​

  1. 专题导读：核心问题、范围、非目标、与相邻专题的边界。
  2. 概念与技术原理：关键术语、对象与算法/机制；必要时说明替代实现。
  3. 技术架构：逻辑组件、数据流、状态机、接口/事件契约。
  4. 工程实现：数据模型、API 示例、部署选择、失败处理、兼容性。
  5. 实验验证：可执行的测试设计、预期结果、实测记录（如有）。
  6. 局限与权衡：安全、成本、性能、复杂度和适用条件。
  7. 研究结论、权威参考文献与证据声明。

10.2 证据分级 ​

证据类型使用方式禁止的表述
官方标准/文档说明标准术语、公开协议和具体产品行为将文档描述冒充本地实测
可复现源码/测试说明特定版本下的实现与行为不注明版本与环境就推广到全部版本
本地工程实验记录命令、环境、输入、输出、失败情况未运行却声称“测试通过”
架构推论标明前提、推理链与适用边界将研究建议写成行业统一标准
教学示例用于说明契约、流程和设计权衡伪装成可直接调用的真实平台 API

10.3 章节验收标准 ​

  • 十二篇专题的中文标题、英文名称、编号与 v1.3 完全一致。
  • P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 每篇都明确对象、职责、接口、数据与故障边界；跨专题无互相矛盾的状态定义。
  • 至少具备统一对象关系图、控制/执行时序图、Run 状态机、租户权限矩阵和数据流/资产关系图。
  • 能将一个完整 Studio 任务映射到各专题的服务责任，并指出谁是状态和权限决策的权威来源。
  • 重要设计决策包含可替代方案、适用条件、风险与验证方式。
  • 所有产品特性与标准事实有可追溯来源；示例和未实测假设均有明确标注。
  • 与 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 产品专题建立双向映射，避免把后端服务直接当作前端页面结构。

十一、技术架构与产品架构的映射 ​

技术专题主要支撑的产品专题映射说明
P1/P2F6 Agent Execution、F8 Agent Monitoring任务控制、执行反馈与用户可见状态
P3F1 Agent Creation、F4 Agent Publishing、F9 Agent Management定义、版本、发布与管理
P4F1/F2/F3创建、配置、调试、测试的后端能力
P5F6/F9部署、实例与运行生命周期
P6F7 Agent Collaboration工作流与多 Agent 协作的管理能力
P7F2/F3/F11模型工具配置、测试与外部集成
P8F11 Developer Experience开放接口、SDK 与开发者契约
P9F3/F4/F11扩展、插件、复用和开发生态
P10F5 Workspace、F10 Artifact & Delivery项目资产、产物、共享与保留
P11F5/F12 Platform Administration组织、工作空间与隔离边界
P12F6/F9/F12权限、配额、预算、治理与审计

映射是多对多关系：一个产品功能可能依赖多项技术服务；一项技术能力也可能支撑多个用户场景。

研究结论 ​

Agent Platform 的技术架构不应从“选什么框架、拆几个服务”开始，而应从平台管理的对象、跨对象的生命周期、服务职责和安全边界开始。P1/P2 提供控制与执行的总体骨架；P3 - P4 - P5 - P6 形成 Agent 与 Workflow 的定义、开发、部署和运行管理闭环；P7 - P8 - P9 - P10 形成资源、接口、扩展和数据资产能力；P11/P12 将租户隔离、授权、配额和治理落实为全平台的技术约束。

本章的最终目标不是画出一张复杂架构图，而是使研究者能够解释并验证：谁有权启动哪个版本的 Agent、使用哪些资源、由谁执行、状态如何持久化、失败如何恢复、结果归谁所有，以及如何追溯整个过程。只有这些问题得到可检查的技术回答，Agent Platform 才具有可持续开发和运营的工程基础。

附录 A：参考文献与原始资料 ​

以下优先列出标准组织、开源项目或厂商官方技术文档，作为 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 后续专题的研究入口。它们分别支持控制器、运行、接口、可观测、安全、资源和工作流等技术问题，不代表这些项目共同定义了一套唯一的 Agent Platform 标准架构。

附录 B：研究证据、验证声明与适用边界 ​

目录依据：本篇 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 的名称、编号和顺序采用用户确认的《Agent 全栈技术地图》v1.3 目录；与已完成的 04-01 Fundamentals 六篇专题及 04 领域总纲保持一致。

研究性模型：能力分组、逻辑组件图、对象关系图、Studio 参考架构、阶段演进模型、参考 API 与章节验收标准，均为用于研究和工程设计的综合性建议，不是行业统一标准或某个现成平台的正式实现声明。

来源与核验状态：附录 A 提供后续深入研究的官方资料入口；本章未逐项在线核验这些文档在 2026 年 10 月 31 日的最新内容，也未以它们证明任何特定平台的最新产品功能。正式 P 专题应针对关键技术结论逐条核验相关原始资料和版本。

验证声明：本篇没有执行 Agent Platform 部署、接口调用、压测、租户隔离测试或故障注入；时序图和 API 均为设计性示例。未来专题若包含代码实验，应记录环境、步骤、结果与失败情况。

适用边界：适用于开发型、运行型、应用型和综合型 Agent Platform 的技术架构研究。具体组件选择、租户模型、消息交付语义和部署规模必须根据真实负载、安全要求与组织条件决定。

下一篇：P1 · 平台如何统一管理和控制 Agent？ - Control Plane。