03 · Agent Platform 如何运行？ - Platform Architecture
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：01 · Agent Platform 是什么？它如何工作？ - Fundamentals
文档类型：专题研究
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：Agent Platform 的整体运行架构是什么？控制面、执行面、平台服务和用户入口如何协同？平台如何把定义、版本、部署、运行、事件、状态和产物连接成完整且可治理的执行闭环？
专题导读
本篇属 Fundamentals。前两篇分别界定了 Agent Platform 的成立条件与逻辑组件。本篇进一步研究组件如何协作使平台持续运行。研究对象是平台级运行架构，不重复 03 · Agent System 中 Agent Engine 的内部推理循环、工作流算法或具体模型调用机制。本文采用控制面（Control Plane）与执行面（Execution Plane）的双视角，辅以接入层、共享平台服务、持久化与外部依赖，说明请求流、状态流、事件流和治理流如何贯穿系统。
研究结论先行： 平台运行不是“用户点击运行 → 调用模型 → 返回文字”的单条调用链，而是定义与发布、准入与调度、执行与观测、交付与治理共同构成的长期状态机。控制面负责意图、策略和期望状态；执行面负责执行事实与结果；两者通过有身份、有版本、有状态的契约协作。这里的“面”是职责视角，不必映射成两个物理集群。
一、研究边界与分析方法
1.1 与前三个领域的边界
| 研究对象 | 主要问题 | 本篇如何使用 |
|---|---|---|
| 01 · AI | 模型如何生成、调用工具和处理知识 | 视为模型服务依赖，不重述模型算法 |
| 02 · Agent | 单个 Agent 的定义、能力和行动 | 视为平台管理的 Agent 定义与运行主体 |
| 03 · Agent System | Agent Engine、编排、状态和治理如何工作 | 视为可由平台承载的执行系统 |
| 04 · Agent Platform | 多对象、多用户、多环境的定义、部署、运行和治理如何统一 | 本篇主体 |
1.2 四个不可混淆的视角
- 逻辑架构：谁承担注册、控制、执行、调度、存储、观测等职责。
- 运行架构：请求、事件、状态、结果在职责之间如何流动。
- 部署架构：哪些进程、容器、节点和云服务承载上述职责。
- 产品架构：用户通过哪些页面、API、SDK、Studio 操作平台。
同一逻辑架构可以实现为单体、模块化单体或微服务。本文的示意图是参考模型，不是厂商通用标准。
二、平台总体运行架构
用户 / 开发者 / 管理员 / 外部系统
│ Web / API / SDK / CLI / Webhook
▼
┌──────────────────────────────────────────────────────────────┐
│ 接入与体验：认证入口、BFF/API Gateway、Workspace、Studio UI │
└──────────────────────────┬───────────────────────────────────┘
│ 身份 + 租户/项目上下文 + 请求
▼
┌────────────────────────── 控制面 ─────────────────────────────┐
│ Agent Registry / 版本与发布 / Deployment 管理 │
│ Run 控制 / Workflow 定义 / 资源目录 / 配额与策略决策 │
│ 期望状态、授权决策、配置快照、运行请求 │
└──────────────────────────┬───────────────────────────────────┘
│ 已校验的执行契约 / 队列 / 事件
▼
┌────────────────────────── 执行面 ─────────────────────────────┐
│ 准入与调度 → Worker / Agent Runtime → Workflow Runtime │
│ 模型 / 工具 / 知识访问 → 检查点与状态写入 → 结果 / 产物 │
└──────────────────────────┬───────────────────────────────────┘
│ 状态事件 / 运行指标 / 产物引用
▼
┌────────────────────────── 平台服务 ───────────────────────────┐
│ 身份授权 │ 租户隔离 │ 数据与对象存储 │ 事件总线 │ 可观测性 │
│ 审计 │ 密钥管理 │ 成本计量 │ 通知 │ API/SDK │ 集成与扩展 │
└──────────────────────────────────────────────────────────────┘
横切约束：安全策略、资源限额、可靠性、数据治理、生命周期管理。上图的上下位置表示主要交互关系，不代表所有调用都必须经过控制面。执行面可能直接访问获准的模型端点、工具、缓存和存储；涉及敏感操作时，还需要再次执行策略检查或请求人工审批。
2.1 控制面：从用户意图到可执行契约
控制面（Control Plane）主要管理期望状态与授权边界。它通常承担：Agent 定义及版本解析、配置校验、环境与部署映射、执行请求接纳、身份权限检查、资源额度核验、运行生命周期命令，以及审计记录。控制面并不必然执行每一步 Agent 推理；它要确保执行面拿到的任务有明确身份、版本、资源和策略约束。
控制面输出的最小执行契约应包含：run_id、tenant_id、project_id、agent_version_id 或 workflow_version_id、deployment_id、执行输入引用、权限/资源策略引用、截止时间与幂等键。敏感密钥不应直接嵌入普通任务消息。
2.2 执行面：从执行契约到可追踪结果
执行面（Execution Plane）负责接收获准任务、分配运行资源、驱动 Agent System、更新运行状态、处理取消与超时、写入检查点，并生成输出。它可能包含任务队列、调度器、Worker、Agent Runtime、Workflow Runtime、模型/工具适配器、状态存储和产物写入组件。
执行面负责报告观察到的事实状态，例如“已启动”“等待人工批准”“某工具调用失败”“已完成”。控制面据此向用户展示状态并执行管理策略。平台不应把“已发送任务消息”直接视为“任务成功”。
2.3 平台服务：连接两个面并提供横切保障
平台服务包括 Registry、配置、身份、授权、租户、资产、事件、存储、密钥、观测、计量、通知与集成服务。某项服务可以服务于控制面和执行面；例如授权既发生在创建 Run 时，也可能发生在运行中调用高风险工具时。平台服务是能力归类，不意味着必须独立部署。
三、平台运行所管理的核心对象
| 对象 | 作用 | 典型关系 | 重要边界 |
|---|---|---|---|
| Tenant / Organization | 资源、权限与计费边界 | 拥有多个 Workspace | 不等于部署集群 |
| Workspace / Project | 业务与协作容器 | 包含 Agent、Workflow、Run | 权限需明确继承规则 |
| Agent Definition | 可编辑的 Agent 规范 | 产生多个 Version | 草稿不应直接冒充发布版本 |
| Agent Version | 不可变的定义快照 | 被 Release / Deployment 引用 | 版本标识与内容摘要分开 |
| Workflow Version | 工作流结构快照 | 被 Run 绑定 | 运行中不隐式升级 |
| Release / Deployment | 将版本映射到环境与运行配置 | 关联一个或多个运行实例 | 发布与实际就绪不同 |
| Runtime Instance / Worker | 执行资源与进程 | 承载一个或多个 Run | 不是 Agent Definition |
| Run | 一次执行的业务标识 | 产生 Event、Checkpoint、Artifact | 与重试 Attempt 区分 |
| Attempt | Run 的一次尝试 | 可失败、超时或重试 | 不应覆盖历史尝试 |
| Event | 可追踪状态变化 | 属于 Run 或平台对象 | 事件到达顺序未必等于发生顺序 |
| Checkpoint | 可恢复状态快照 | 属于 Run / Attempt | 需匹配版本与状态 schema |
| Artifact | 任务结果或中间产物 | 由 Run 产生，受项目权限约束 | 需记录来源与生命周期 |
关键约束： 一个 Run 必须绑定确定的 Agent/Workflow 版本与配置快照，才能解释“为什么同样的请求在不同时刻产生不同结果”。配置快照可包含非敏感配置和密钥引用，不能无条件复制凭据明文。
四、完整运行链路：从创建到交付
4.1 定义与发布阶段（Design Time）
- 用户在 Workspace 创建 Agent 草稿，设置模型、工具、知识与行为约束。
- Builder 调用定义校验服务；Registry 保存草稿与引用关系。
- 用户执行调试与评估，检查工具权限、模型可用性及预算约束。
- 发布动作生成不可变版本；部署服务将版本映射到指定环境。
- 平台记录发布人、审核状态、配置引用与部署就绪状态。
设计时修改草稿，不应自动修改已经运行的 Run。需要热更新的配置应被显式标注，并说明其生效范围。
4.2 执行阶段（Run Time）
sequenceDiagram
participant U as 用户 / Studio
participant API as API / BFF
participant C as 控制面
participant Q as 队列 / 调度
participant R as Agent System Runtime
participant S as 状态与事件存储
participant A as 产物存储
U->>API: 启动 Run（版本、输入、幂等键）
API->>C: 认证身份与租户上下文
C->>C: 授权、配额、版本/部署解析
C->>S: 持久化 Run=QUEUED 与执行契约
C->>Q: 投递执行请求
Q->>R: 分配任务 / 租约
R->>S: RUNNING 事件与检查点
R->>R: Agent / Workflow 执行
alt 需要人工审批
R->>S: WAITING_APPROVAL
C-->>U: 展示待审批事项
U->>C: 批准或拒绝
C->>R: 传递授权后的恢复命令
end
R->>A: 写入产物并取得引用
R->>S: SUCCEEDED / FAILED / CANCELLED
C-->>API: 聚合运行状态与结果引用
API-->>U: 状态更新与产物访问可靠性补充： 上述“写 Run → 投递队列”跨存储边界时可能发生双写失败。可采用事务 Outbox、持久化任务表加轮询或同等机制，避免“Run 已入库但永远不执行”。消费者应按 run_id / attempt_id 做幂等处理。这里给出的是设计方案，不代表任何具体平台已经实现。
4.3 交付与回收阶段（Post Run）
执行结束后，平台需要完成状态封存、计量结算、产物访问授权、通知、日志保留与清理。Run 成功不等于交付成功：产物可能写入失败、权限不足、文件损坏，或未通过人工审核。因此，平台应将执行结果与业务验收状态分开建模。
五、状态机与控制命令
5.1 参考 Run 状态机
CREATED → QUEUED → RUNNING ───────────────→ SUCCEEDED
│ │ └──────────────→ FAILED
│ ├→ WAITING_APPROVAL ─→ RUNNING
│ ├→ WAITING_RESOURCE ─→ RUNNING
│ └→ CANCELLING ───────→ CANCELLED
└────────────────────────→ EXPIRED / REJECTED状态集合由具体产品定义；例如 REJECTED 可表示准入拒绝而非执行失败。必须明确合法状态迁移、超时、取消优先级、终态不可逆规则。取消通常是协作式请求，无法保证已发出的外部副作用被撤销。
5.2 Run 与 Attempt 的区分
同一个 Run 可以包含多次 Attempt。调度重试、Worker 崩溃重启和业务层重试并非同一概念。推荐保留 run_id 作为业务执行标识，attempt_id 标记一次具体尝试；工具调用另有 operation_id 或幂等键。这样才能计算真实重试成本、定位失败并避免将重复执行误认为新的用户任务。
5.3 控制操作的语义
| 操作 | 平台含义 | 主要风险 |
|---|---|---|
| Start | 通过准入后创建 Run | 重复请求、超配额 |
| Pause | 请求在安全点暂停 | 不一定即时、外部操作未停止 |
| Resume | 校验版本与状态后恢复 | 检查点不兼容、审批过期 |
| Cancel | 请求停止后续工作 | 已完成的副作用无法自动撤销 |
| Retry | 对失败执行进行新的 Attempt | 重复扣费、重复发信/写库 |
| Rollback | 回退部署指向的版本 | 不等于撤销既有 Run 的行为 |
六、平台中的四类流
6.1 请求流（Command / Request Flow）
来自用户或外部系统的创建、发布、启动、取消等命令，应携带认证主体、作用域、目标对象、版本和幂等键。写操作的成功响应应区分“已接收”“已持久化”“已开始”“已完成”，避免模糊的 success=true。
6.2 状态流（State Flow）
平台应区分期望状态（例如 Deployment 期望 3 个副本）与观察状态（实际仅 2 个就绪）。Run 的状态由执行事实驱动；控制面可以通过轮询或事件更新物化视图。若采用最终一致性，应向用户说明可能存在短暂延迟。
6.3 事件流（Event Flow）
事件用于通知运行进度、工具调用、审批、完成和失败。事件系统通常需要处理至少一次投递、重复、乱序、延迟和消费者离线。可通过事件 ID、对象序列号、发生时间与接收时间、去重策略和重放能力保证可追踪性；不能仅依赖全局时间戳判断因果顺序。
6.4 数据与产物流（Data / Artifact Flow）
用户输入、模型上下文、检查点、工具结果和产物的敏感性不同，应采用差异化存储、访问控制和保留策略。大文件宜通过对象存储引用而非直接塞入队列；事件日志不应默认记录全部 Prompt、密钥或个人数据。
七、同步、异步与长任务运行模式
| 模式 | 适合场景 | 平台要求 | 主要限制 |
|---|---|---|---|
| 同步请求-响应 | 简短任务、低延迟交互 | 请求超时、限流、错误契约 | 长任务易超时 |
| 异步 Run + 轮询 | 报告生成、批处理 | Run ID、状态查询、结果引用 | 轮询延迟与负载 |
| 异步 Run + SSE/WebSocket | 实时进度与交互 | 事件订阅、断线恢复、权限检查 | 连接不等于任务生命周期 |
| 事件触发 / Webhook | 自动化与系统集成 | 签名验证、重放防护、重试与去重 | 外部系统不稳定 |
| 定时 / 批量任务 | 周期研究、数据处理 | 调度、错过任务补偿、配额 | 高峰期资源竞争 |
Studio 场景宜采用异步 Run + 持久状态 + 可恢复事件订阅，避免浏览器关闭导致后台任务丢失。前端连接状态与执行状态应解耦。
八、跨组件关键契约与一致性
8.1 参考执行请求（示意，非标准 API）
{
"run_id": "run_123",
"tenant_id": "tenant_demo",
"project_id": "project_research",
"agent_version_id": "agent_research@v7",
"deployment_id": "deploy_prod_2",
"input_ref": "object://inputs/123.json",
"policy_ref": "policy:research-standard@v3",
"resource_budget": {"max_cost_usd": 5, "max_duration_s": 1800},
"idempotency_key": "start:project_research:task_42",
"trace_id": "trace_abc"
}设计注意： 这只是说明字段职责的教学示例；object:// 是抽象引用格式，不代表实际可访问地址。生产系统还需要签名/认证、Schema 版本、请求来源、超时与权限验证。预算字段只是准入和执行限制的一部分，不代表成本一定能够被精确预先估算。
8.2 关键一致性问题
| 场景 | 故障窗口 | 可采用的机制 |
|---|---|---|
| 创建 Run 与投递消息 | DB 成功、消息失败 | Transactional Outbox / 持久任务表 |
| Worker 执行与状态回写 | 外部动作成功、回写失败 | 操作幂等键、外部回执、人工对账 |
| 部署更新与运行创建 | 版本切换瞬间 | 创建 Run 时固定版本快照 |
| 取消与完成竞争 | 取消已发出但执行刚结束 | 明确状态迁移优先级与审计 |
| 事件投递 | 重复或乱序 | 事件 ID、对象序列号、幂等消费者 |
| 检查点恢复 | 代码/Schema 变化 | 兼容策略、迁移或拒绝恢复 |
不要将 exactly-once execution 作为未经限定的承诺。 平台通常更现实地采用至少一次任务投递与幂等业务操作；对于发邮件、支付、修改外部系统等副作用，还需要专门的去重与补偿机制。
九、安全、租户与治理如何贯穿运行
9.1 身份与授权链
用户身份 → 租户/项目角色 → Agent/Workflow 访问权 → Run 操作权 → 工具调用权。控制面准入并不能替代执行面内的细粒度授权，尤其当 Agent 运行中选择工具或跨项目访问知识资源时。应使用最小权限、短期凭证和可审计的授权决策。
9.2 租户隔离
至少区分：元数据隔离、运行资源隔离、存储隔离、密钥隔离、网络边界与成本计量隔离。共享 Worker 并不必然不安全，但必须明确进程/容器边界、凭据注入和跨租户数据泄露防护。高风险执行可采用更强的沙箱或专用资源池。
9.3 预算与配额
配额通常约束并发 Run、请求频率、模型 Token、工具调用、存储和总成本。预算可以在准入前校验、运行中扣减与超限中断三个阶段执行；多 Worker 并发时必须考虑计量延迟和竞态。成本观测与成本强制限制是不同能力。
9.4 人工监督
审批是平台对象而非仅一个 UI 弹窗：它应包含请求者、审批者、待执行操作摘要、风险、到期时间、决策、签名/审计记录及恢复条件。审批恢复前还需确认版本、参数、权限与策略是否发生变化。
十、可观测性、故障处理与恢复
10.1 关联标识
推荐以 trace_id 串联 API、控制面、队列、Worker、模型与工具调用，以 run_id 标识一次业务执行，以 attempt_id 区分重试，以 tenant_id / project_id 支持隔离与计费。日志、指标和追踪中的敏感字段需脱敏或限制访问。
10.2 故障域与降级
| 故障 | 用户可见症状 | 典型处理 |
|---|---|---|
| API 网关故障 | 无法创建或查询 Run | 多实例、健康检查、限流 |
| Registry 不可用 | 无法解析新版本 | 已固定版本的运行可视情况继续 |
| 队列积压 | Run 长时间 QUEUED | 监测排队时延、扩容、优先级 |
| Worker 崩溃 | RUNNING 卡住 | 租约到期、重新调度、检查点恢复 |
| 模型服务限流 | 执行变慢或失败 | 退避、熔断、备用路由、预算保护 |
| 工具调用部分成功 | 外部副作用不确定 | 回执核对、幂等、补偿或人工处理 |
| 事件订阅中断 | 前端无进度更新 | 按游标补拉、状态查询兜底 |
| 对象存储故障 | 产物不可用 | 写入校验、重试、明确交付失败 |
恢复设计必须回答三个问题：什么状态被持久化、谁拥有恢复权、如何防止恢复造成重复副作用。这与 03 · Agent System 的 H4/H7 形成上下游关系：系统层研究恢复机制，平台层研究多任务、多版本、多租户条件下的统一管理。
十一、贯穿案例：研究报告 Studio 的运行架构
11.1 业务目标与对象
一个 Studio 由用户创建，包含研究项目、Agent 团队、选题 - 调研 - 分析 - 审核 - 发布的工作流、审批节点和报告产物。平台负责 Studio/Project 的身份与权限、Agent 定义版本、Workflow 发布、Run 生命周期、状态通知、产物访问及审计；Agent System 负责实际的推理、工具调用和 Agent 协作。
11.2 一次真实业务链路的设计演练
- 创建 Studio：平台创建 Workspace/Project 关联、成员权限与资源预算。
- 选择 Agent 团队：Registry 解析选题 Agent、调研 Agent、审核 Agent 的版本及可用工具。
- 发布 Workflow：固化阶段顺序、审核返工规则与人工确认点。
- 启动研究：控制面校验租户、版本、预算与策略，创建 Run。
- 执行选题：执行面运行选题 Agent，产生候选题目与中间产物。
- 审核返工：审核 Agent 给出结构化反馈；Workflow Runtime 决定进入下一阶段或返工。
- 人工确认：Run 进入
WAITING_APPROVAL，平台通知用户，保存审批证据。 - 恢复执行：审批通过后，控制面下发恢复命令；执行面继续深度调研与写作。
- 报告交付：产物服务保存 Markdown/PDF 引用，平台记录版本、来源、验收状态。
- 审计与复盘：用户可查看各阶段耗时、模型费用、失败次数和审核意见。
11.3 最小可行平台的部署示例
浏览器（Next.js Studio UI）
│
▼
API 后端（身份、Workspace、Registry、Run Control）
│ └── PostgreSQL（定义、版本、Run、事件）
├── 持久任务表 / Redis 队列
▼
Worker（Agent System / Workflow Runtime）
├── 模型与工具 API
└── 对象存储（报告、附件、检查点）这是一种参考部署选项，不是唯一技术栈。单租户 MVP 可先采用模块化单体和单个 Worker；即使如此，也应从一开始保留版本固定、Run ID、幂等、授权与持久状态。真正需要多租户、隔离 Worker、专用调度集群时再拆分服务，避免将“微服务数量”误当作平台成熟度。
十二、架构方案比较与取舍
| 方案 | 优势 | 局限 | 适用阶段 |
|---|---|---|---|
| 单体同步执行 | 开发快、部署简单 | 长任务超时、恢复弱 | 概念验证，不宜直接承载复杂长任务 |
| 模块化单体 + 异步 Worker | 边界清晰、成本可控、易演进 | 仍需队列/状态一致性设计 | 单租户 MVP、早期产品 |
| 控制面/执行面逻辑分离 | 职责明确、便于扩展和治理 | 跨边界契约复杂 | 多团队、多工作流平台 |
| 多租户分布式执行集群 | 隔离与弹性扩展能力强 | 调度、成本、观测与运维复杂 | 规模化平台或高风险执行 |
技术选择取决于任务时长、并发、数据敏感度、可用性目标、团队能力和预算，而非仅看是否支持多个 Agent。
十三、可操作的验证方案
13.1 核心验收问题
| 验证目标 | 测试方法 | 通过判据（示例） |
|---|---|---|
| 版本固定 | 发布 v1、启动 Run、再发布 v2 | 旧 Run 始终引用 v1 |
| 幂等创建 | 同一幂等键重复提交 | 不生成重复业务 Run |
| 可靠投递 | 在 Run 持久化后模拟消息发送失败 | 系统最终重新投递或明确失败 |
| 崩溃恢复 | 执行中杀死 Worker | Run 不永久卡死，恢复/失败可解释 |
| 审批门控 | 在敏感工具前暂停 | 未获批准不执行敏感操作 |
| 取消语义 | 执行中发送 Cancel | 不再启动新步骤，已有副作用被记录 |
| 事件恢复 | 断开前端连接后重连 | 能查询权威状态并补齐关键事件 |
| 租户隔离 | 用租户 B 身份读取租户 A 资源 | 拒绝且留下可审计记录 |
| 产物交付 | 模拟对象存储写入失败 | 不错误标记为已交付 |
| 成本约束 | 模拟高频工具/模型调用 | 预算告警和硬限制符合配置语义 |
这些是待实施的测试设计，不是已经执行的测试结果。阈值（例如恢复时延、排队时延、最大成本偏差）应在实际项目中依据 SLO、业务风险和预算制定。
13.2 推荐的最小实验
搭建一个含 Registry → Run API → 持久队列 → Worker → 状态表 → 事件订阅 → 产物存储 的端到端样例，执行三类任务：短任务、长任务、需要人工审批的任务。分别注入队列失败、Worker 终止和外部工具超时，检查版本绑定、重试次数、幂等、状态一致性与产物可访问性。该实验可作为进入 P1、P2、P5、P6 专题的工程基线。
十四、常见误区与研究限制
- 将 Control Plane 理解为单独服务器。 它首先是职责边界；小平台可与 API 后端共进程。
- 将 Execution Plane 等同于 L4 Agent Engine。 前者还包括任务接纳、资源分配、Worker 生命周期、隔离与结果回传。
- 把 Agent Version 与 Runtime Instance 混为一谈。 前者是定义快照，后者是执行资源。
- 把“执行成功”当作“业务交付完成”。 报告还可能需要格式校验、人工审核与访问授权。
- 默认消息不会重复。 队列、网络重试和故障恢复都可能造成重复投递。
- 只在请求入口做授权。 运行中访问工具和知识资源仍需执行策略。
- 把实时前端连接当作任务容器。 后台 Run 应独立于浏览器生命周期。
- 认为微服务必然更成熟。 分布式复杂度必须由实际隔离和规模需求支撑。
十五、与 v1.3 后续专题的映射
| 后续专题 | 本篇提供的基础 | 后续需要深入的内容 |
|---|---|---|
| 01-04 Platform Types | 运行模式与部署取舍 | 平台类型、定位与适用条件 |
| 01-05 Lifecycle Management | 对象、状态与版本关系 | 各对象完整生命周期和迁移规则 |
| 01-06 Design Principles | 分层、隔离、契约与一致性 | 可扩展性、安全性与架构决策原则 |
| P1 Control Plane | 准入、期望状态与控制命令 | 控制面服务架构与策略执行 |
| P2 Execution Plane | 调度、Worker、执行事实 | 执行资源、隔离、弹性与运行时管理 |
| P3 Agent Registry | 定义与版本绑定 | 注册、版本、引用、发布契约 |
| P5 Deployment & Runtime Management | Deployment / Instance / Run | 发布、扩缩容、生命周期控制 |
| P6 Workflow Management | Workflow Version 与执行 | 编排定义、调度、协作与事件 |
| P8 Platform API & SDK | 请求、事件与幂等 | API 契约、SDK、兼容性 |
| P10 Platform Data & Assets | 状态、产物与审计数据 | 数据模型、存储与资产治理 |
| P11 Multi-tenancy & Isolation | 租户上下文与隔离 | 组织、权限继承、资源隔离 |
| P12 Platform Governance | 横切策略与成本 | 统一治理执行和证据 |
| F6 Agent Execution / F8 Monitoring | Run 与事件模型 | 用户操作、进度反馈与结果呈现 |
研究结论
Agent Platform 的运行架构可以概括为四个连续闭环：定义与发布闭环确保执行对象可识别、可版本化；准入与执行闭环将授权请求转化为受控运行；状态与交付闭环将执行事实、事件和产物反馈给用户；治理与改进闭环持续约束安全、成本、隔离和可靠性。控制面与执行面是理解这些闭环的关键架构视角，但平台的实际形态可以从模块化单体逐步演进到分布式系统。
对研究报告 Studio 而言，优先级不是先拆出大量微服务，而是先保证Agent/Workflow 版本固定、Run 持久化、长任务异步执行、审批可恢复、操作可审计、产物可交付。这些基础契约一旦建立，后续的平台扩展才有稳定依据。
第六轮跨章节契约核对（v1.3-r1；2026-11-01）
[平台设计决策 / 待测试] 本节是领域级一致性修订说明，优先于本篇不一致的历史局部示例；不表示已执行数据库迁移、API 合约或运行测试。统一参考：
04-Agent-Platform-Canonical-Contracts-v1.3-r1.md。
本篇图中的 WAITING_APPROVAL 是旧版展示态；统一工程契约建议持久化为 execution_status=waiting、status_reason=approval。审批通过恢复应先按检查点和调度规则转为 queued，不可把图中的 WAITING_APPROVAL → RUNNING 当成无需持久化调度的通用保证。
上述映射不应机械替换其他对象（如 ManagementOperation、Deployment）的同名状态；正式实施应更新 OpenAPI/JSON Schema、SQL 约束、事件消费者、UI 映射及测试。
附录 A：参考文献与原始资料
以下资料用于进一步核验概念与实现机制。所列为官方原始文档入口或标准文本入口；本篇未进行逐页实时网页核验，不将其中任一实现视为所有 Agent Platform 的通用规范。
- Kubernetes Documentation. Kubernetes Components / Controllers / Workloads. kubernetes.io/docs/concepts/overview/components ；kubernetes.io/docs/concepts/architecture/controller
- OpenTelemetry Documentation. Concepts: Traces, Metrics, Logs. opentelemetry.io/docs/concepts
- CloudEvents Specification. CloudEvents v1.0. github.com/cloudevents/spec
- CNCF. OpenTelemetry Semantic Conventions. opentelemetry.io/docs/specs/semconv
- Temporal Documentation. Workflow Execution / Durable Execution. docs.temporal.io
- LangGraph Documentation. Persistence / Durable Execution / Human-in-the-loop. docs.langchain.com/oss/python/langgraph/overview
- OWASP. Top 10 for Large Language Model Applications. genai.owasp.org/llm-top-10
- NIST. AI Risk Management Framework (AI RMF 1.0). www.nist.gov/itl/ai-risk-management-framework
- Google Cloud. Architecture Framework: Reliability. cloud.google.com/architecture/framework/reliability
- Microsoft. Azure Architecture Center: Compensating Transaction Pattern. learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction
附录 B：研究证据、验证声明与适用边界
证据分类： （A）控制器、持久执行、追踪、事件等概念可在附录 A 的官方资料中查阅；（B）本篇提出的 Agent Platform 对象表、双面参考架构、状态机、执行契约、Studio 演练和验收矩阵属于基于通用工程原理的综合性设计推论；（C）涉及实际延迟、吞吐、恢复成功率、成本上限和安全隔离效果的陈述均需通过具体实现测试，不作已验证结论。
验证声明： 本文没有执行真实平台部署、故障注入、性能基准或安全渗透测试。JSON、Mermaid、架构图和状态迁移为教学示例；其可运行性、兼容性和安全性需要在目标技术栈中单独验证。本文也不声称“控制面/执行面”是所有厂商统一采用的唯一分类。
适用边界： 适合研究平台整体运行架构及设计早期到规模化阶段的演进；具体产品应根据任务风险、法规要求、部署环境、用户规模和技术预算调整组件边界。涉及支付、医疗、金融或高权限自动化时，必须额外进行领域风险评估和专门治理设计。