P2 · 平台如何执行和承载 Agent 任务？ - Execution Plane
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：02 · Agent Platform 是如何构建和运行的？ - Technical Architecture
文档类型：专题研究 / 技术架构 / 参考设计
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：Agent Platform 如何将经过控制面准入的任务可靠地分派到执行资源，运行 Agent System、工具与工作流，控制资源和安全边界，并将状态、结果和产物可信地反馈给平台？
专题导读
本篇属 Technical Architecture。Execution Plane（执行面）是 Agent Platform 中真正承载任务计算与外部操作的职责集合。它负责接收已授权的执行请求，获取不可变的运行快照，分配 Worker 或隔离环境，驱动 Agent System 执行模型调用、工具调用和工作流步骤，处理取消、超时、失败与恢复，并向控制面报告可核验的执行事实。
本篇承接 P1《Control Plane》，从执行面的视角回答：任务在哪里运行、如何被领取、资源如何隔离、长任务如何存活、失败如何恢复、运行状态如何回传、执行面如何在平台治理下保持自治。以多 Agent 研究报告 Studio 为贯穿案例，提供架构图、时序图、状态与租约模型、契约示例、故障矩阵和可验证的验收方案。
研究边界：P2 研究平台级执行基础设施及其与控制面的契约，不重复 03 · Agent System 中 L4 Agent Engine 的推理循环内部机制、L5 Orchestration 的协作算法，也不取代 P5 Deployment & Runtime Management、P6 Workflow Management、P11 Multi-tenancy & Isolation 和 P12 Platform Governance 的专门研究。涉及这些主题时只解释执行面必须实现的接口与约束。
研究结论
- 执行面负责执行事实，控制面负责管理意图与准入。 执行面不应凭一条队列消息自行决定访问哪些租户数据或使用无限资源；必须校验任务身份、版本、租约、权限和预算边界。
- Run、Attempt、Worker、Sandbox 是不同对象。 Run 是业务执行记录；Attempt 是某次尝试；Worker 是执行载体；Sandbox 是可选的隔离边界。一个 Run 可以经历多个 Attempt，Worker 也可承载多个 Run（取决于隔离策略）。
- 可靠性建立在持久化状态、租约、心跳、幂等和重试边界之上。 队列“至少一次交付”通常比假设“恰好一次执行”更现实；外部副作用必须单独设计幂等或补偿。
- 隔离级别应随工具风险和租户边界调整。 纯模型推理与只读检索可以采用较轻隔离；执行用户代码、浏览器自动化、文件系统或不可信工具时，应考虑进程、容器、微虚拟机及网络/文件/凭据限制。
- 长任务是平台常态。 执行面必须支持异步执行、进度事件、可控取消、超时、检查点和在明确恢复语义下重试；不能将一个 HTTP 连接当作任务生命周期。
- 观测数据与审计证据要区分。 日志、指标、Trace 便于排障；关键状态迁移、工具操作、审批与产物来源还需要可靠记录，且不得泄露密钥和敏感上下文。
- Studio 的初期适宜采用模块化控制服务 + 队列 + 独立 Worker + 数据库/对象存储。 在明确并发、隔离、成本与可靠性要求后，再引入独立沙箱池、调度服务或容器编排。
一、执行面的定义、边界与目标
1.1 什么是 Execution Plane
执行面是平台用于承载、运行和监督具体 Agent 任务的一组服务、进程和资源。它不是一个固定产品或单一服务器，而是逻辑职责的集合：任务消费、运行环境准备、Agent System 启动、模型与工具访问、执行过程控制、状态上报和结果持久化。
| 维度 | Control Plane（P1） | Execution Plane（P2） |
|---|---|---|
| 核心问题 | 是否允许、运行哪个版本、如何治理 | 在哪里运行、如何执行、如何安全完成 |
| 主要对象 | Agent Version、Deployment、Run、Policy Decision | Attempt、Worker、Lease、Sandbox、Execution Event |
| 典型操作 | 准入、授权、发布、创建 Run、取消意图 | 领取任务、准备环境、执行步骤、心跳、提交结果 |
| 状态性质 | 管理期望状态与业务状态 | 报告执行事实、资源占用与故障 |
| 安全责任 | 决策与授权、预算和租户策略 | 实际执行路径上的强制隔离与权限落实 |
关键原则：控制面与执行面的职责分离，不等于网络上必须隔离成两个集群。小规模平台可在同一部署环境运行，但应保留独立模块、数据契约和故障边界。
1.2 与 Agent System 内部执行的关系
Agent Platform 的执行面提供“运行 Agent System 的外壳与基础设施”，Agent System 内部的 Agent Engine、编排器、记忆、上下文和工具调用机制仍然负责“任务如何推理与推进”。例如，Studio 的深度调研 Agent 在 Worker 中运行，但它如何规划检索、引用资料和协作审核，属于 Agent System 设计。执行面关心的是该运行是否被授权、是否超时、消耗多少资源、失败后如何处理及如何回传结果。
1.3 执行面的质量目标
- 正确性：执行的定义、版本、输入和权限与准入快照一致。
- 隔离性：不同租户、任务及不可信工具之间的访问边界可被强制执行。
- 可靠性：Worker 崩溃、队列重复、网络分区时可识别并处理不确定状态。
- 可恢复性：在可恢复检查点继续执行，或以新 Attempt 明确重启。
- 可控性：取消、超时、暂停和审批可通过协议实现，而非依赖提示词。
- 可观测性：执行进度、资源消耗、错误和关键副作用有可关联的记录。
- 效率：通过并发限制、资源配额、批处理与扩缩容控制成本和延迟。
二、执行面的逻辑组件
2.1 组件与职责矩阵
| 逻辑组件 | 主要职责 | 典型输入/输出 | 关键边界 |
|---|---|---|---|
| Task Consumer | 从可靠队列领取任务 | RunRequested → AttemptClaimed | 不能把消息接收等同于完成 |
| Scheduler / Placement | 匹配能力、资源、优先级 | 任务需求 → Worker/Pool | 可位于控制面或独立服务 |
| Worker Supervisor | 启停任务、监控进程、取消 | 执行快照 → 生命周期事件 | 不负责业务授权决策 |
| Agent Runtime Adapter | 启动具体 Agent System | 版本/输入 → Agent 输出 | 不应绑定唯一框架 |
| Sandbox Manager | 准备隔离文件、网络、权限 | 安全策略 → 隔离执行环境 | 隔离必须在 OS/基础设施落实 |
| Tool / Model Gateway | 受控访问模型与外部工具 | 限权调用 → 结果/计量 | 不应将长期凭据暴露给 Agent |
| Checkpoint / State Client | 保存可恢复状态与游标 | 步骤状态 → 检查点 | 检查点兼容性须有版本约束 |
| Event Reporter | 发送心跳、进度、结果 | 执行事实 → 事件 | 必须考虑乱序、重复、丢失 |
| Artifact Writer | 上传产物、校验元数据 | 文件/报告 → 对象存储引用 | 产物归属与访问需授权 |
| Resource Meter | 记录用量和限制资源 | token/CPU/时长 → 计量 | 估算与最终结算应区分 |
这些组件可以在一个 Worker 进程中组合实现，也可以在规模扩大后拆分。逻辑组件数量不等于微服务数量。
2.2 参考架构图
flowchart TB
U[Studio UI / API Client] --> CP[Control Plane / Platform API]
CP --> DB[(Platform DB: Run / Attempt / Lease)]
CP --> Q[(Durable Task Queue)]
Q --> TC[Task Consumer / Scheduler]
TC --> WS[Worker Supervisor]
WS --> SB[Sandbox / Runtime Environment]
SB --> AS[Agent System Runtime]
AS --> MG[Model Gateway]
AS --> TG[Tool Gateway]
AS --> CK[(Checkpoint Store)]
AS --> AR[(Artifact Storage)]
WS --> EV[Execution Event Reporter]
EV --> DB
EV --> CP
CP --> U图中数据库和队列是逻辑基础设施；事件既可经由消息总线归并，也可由 Worker 通过受控 API 上报。生产设计必须避免 Worker 绕过权限边界任意修改业务状态。
三、核心对象、身份与执行契约
3.1 Run 与 Attempt 的区别
Run 代表一次用户可见的任务执行请求，具有稳定 run_id。Attempt 代表执行该 Run 的一次尝试，具有独立 attempt_id；网络失败、Worker 崩溃或超时后可产生新的 Attempt。一次 Run 的最终状态应由控制面按照合法转换与终结规则归并，而不是任由任意 Worker 写入。
Worker 是执行任务的计算载体；Sandbox 是任务实际获得的受限运行环境；Lease（租约） 是执行面暂时拥有某项任务执行权的证明；Execution Snapshot 是固定版本、配置、输入、权限与预算的可验证快照。
| 对象 | 推荐标识 | 生命周期 | 关键不变量 |
|---|---|---|---|
| Run | run_id | 受理至终态/归档 | 绑定不可变执行快照 |
| Attempt | attempt_id | 领取至成功/失败/失联 | 属于唯一 Run，尝试编号单调 |
| Worker | worker_id | 注册、健康、下线 | 能力与健康状态可发现 |
| Lease | lease_id + fencing token | 获取、续租、过期 | 过期持有者不得提交有效终态 |
| Sandbox | sandbox_id | 创建、运行、清理 | 资源、网络、文件和凭据受限 |
| Checkpoint | checkpoint_id | 创建、读取、保留/删除 | 与运行版本及恢复点兼容 |
| Artifact | artifact_id | 生成、校验、发布/归档 | 有归属、哈希与访问策略 |
3.2 参考执行请求契约
以下为教学设计示例，不是既有平台的官方 API：
{
"schema_version": "1.0",
"run_id": "run_123",
"attempt_id": "att_001",
"tenant_id": "tenant_a",
"deployment_id": "dep_research_prod",
"agent_version_id": "agent_research@7",
"workflow_version_id": "wf_report@3",
"input_ref": "object://inputs/run_123.json",
"execution_snapshot_ref": "object://snapshots/run_123.json",
"policy_ref": "policy://tenant_a/v5",
"resource_limits": {
"wall_time_seconds": 3600,
"max_model_tokens": 150000,
"max_concurrent_tools": 3
},
"idempotency_key": "tenant_a:report:request_456",
"trace_id": "trace_abc"
}设计要求：消息正文不包含模型 API Key、OAuth Refresh Token 或数据库密码；执行面通过短期身份凭证或受控密钥代理获取必要权限。引用对象需校验所属租户、版本与完整性，防止篡改引用造成越权。
3.3 执行事件契约
事件至少包含 event_id、schema_version、run_id、attempt_id、worker_id、lease_token、sequence、occurred_at、event_type 和必要的载荷。事件类型可以包括 AttemptStarted、Heartbeat、StepProgress、CheckpointSaved、ArtifactProduced、AttemptSucceeded、AttemptFailed、AttemptCancelled。
重要区分：事件产生时间不代表平台接收顺序；业务终态应校验 Attempt 是否仍拥有有效租约、事件序号是否可接受、Run 是否已终结。对于跨组件事件，不能依赖单一全局时间戳判定先后。
四、任务派发、领取与执行流程
4.1 标准执行链路
- 控制面完成鉴权、策略准入、预算检查、版本固定和 Run 持久化。
- 控制面以可靠机制发布任务，例如数据库事务内记录 Outbox，再异步投递到队列。
- Consumer 收到任务后检查其有效性、租户和版本，并尝试原子领取执行权。
- 调度器依据资源需求、Worker 能力、租户配额及优先级选择执行池。
- Worker 创建 Attempt，获取租约，准备隔离环境并加载执行快照。
- Runtime Adapter 启动 Agent System，执行模型调用、工具调用和工作流步骤。
- Worker 周期性上报心跳、进度、用量和检查点；产物经受控写入路径保存。
- 完成时 Worker 提交带租约证明的终态事件；控制面校验并归并 Run 状态。
- 资源、临时凭据与沙箱清理；最终结果和产物引用对授权用户可见。
4.2 参考时序图
sequenceDiagram
participant CP as Control Plane
participant Q as Task Queue
participant W as Worker
participant S as Sandbox / Agent Runtime
participant ST as State & Artifact Store
CP->>ST: Persist Run + immutable snapshot + outbox
CP->>Q: Publish RunRequested
Q-->>W: Deliver task (at least once)
W->>CP: Claim Attempt + acquire lease
CP-->>W: Lease + scoped execution identity
W->>S: Start sandbox with limits
loop During execution
S-->>W: Progress / usage / checkpoint
W->>ST: Persist checkpoint or artifact
W->>CP: Heartbeat / execution events
end
S-->>W: Result or error
W->>CP: Complete Attempt (lease token)
CP->>ST: Validate and finalize Run
W->>S: Cleanup environment4.3 至少一次投递与重复领取
消息队列可能重复投递、消费者可能在处理后但确认前崩溃、网络重试可能重复请求。因此，消息去重不等于副作用幂等。建议采用：Run/Attempt 唯一约束、原子 Claim、租约和 fencing token、工具调用幂等键、事件去重，以及对无法幂等的外部操作采用人工确认或补偿策略。
对“发送邮件”“支付”“写入第三方系统”等副作用，重试必须明确区分：请求未送达、请求已送达但响应丢失、请求成功但状态回传失败。不能把所有失败简单处理为“重新执行整段 Agent”。
五、Worker、调度与资源管理
5.1 Worker 运行模型
| 模式 | 特点 | 适用场景 | 主要风险 |
|---|---|---|---|
| 进程内异步任务 | 部署简单、开销低 | 本地实验、极低并发 | API 重启影响任务，隔离弱 |
| 独立 Worker 进程 | 生命周期独立、可水平扩展 | 单租户 MVP、团队平台 | 需队列、心跳与状态协议 |
| 容器化 Worker 池 | 资源限制与环境可复制 | 多工作负载、弹性扩缩容 | 冷启动、镜像与运维成本 |
| 按任务创建沙箱 | 强化任务隔离 | 不可信代码、高风险工具 | 启动开销、网络和存储治理 |
| 专用隔离执行池 | 分级隔离与策略控制 | 多租户、高合规要求 | 调度复杂、成本更高 |
5.2 调度决策的输入
调度器至少考虑：任务优先级、队列等待时间、租户公平性、Worker 能力标签、CPU/内存需求、模型与工具可达性、沙箱隔离级别、并发限制、截止时间与成本预算。若存在 GPU 或特定浏览器环境需求，还需资源亲和与容量预留。
反例：仅按队列 FIFO 派发所有任务，可能使一个租户的大批量长任务阻塞其他租户的短任务。可通过租户级并发上限、分级队列、加权公平或任务类别分池缓解，但应通过真实负载数据决定复杂度。
5.3 资源预算与实际计量
执行前的 resource_limits 是上限或策略约束，执行中的 token、工具调用、CPU 时间和存储用量是观测值，结算时还可能有供应商账单与估算误差。平台应区分预算预留、实时计量、硬限制、软告警和最终结算。具体定价和账单归属由 P12 及工程实践进一步研究。
六、执行环境与安全隔离
6.1 任务风险分级
| 风险级别（参考） | 任务示例 | 典型执行边界 |
|---|---|---|
| 低 | 只读文本生成、受控检索 | 独立任务上下文、凭据最小化 |
| 中 | 访问内部文件、调用有限业务 API | 受限 Worker、细粒度工具授权、审计 |
| 高 | 执行代码、浏览器自动化、写入外部系统 | 沙箱隔离、网络限制、审批与副作用防护 |
| 极高 | 不可信代码与敏感数据混合处理 | 更强隔离、专用执行池、严格审查或禁止 |
以上是风险建模示例，不是普遍适用的合规分级。实际边界应根据数据敏感度、工具权限、租户互信程度与威胁模型确定。
6.2 隔离措施
- 计算隔离：进程/容器/虚拟机边界、CPU/内存/进程数限制；不能把容器等同于绝对安全沙箱。
- 文件隔离：临时目录独立、只读挂载、输出目录白名单、运行结束清理。
- 网络隔离：默认拒绝不必要的出站连接，按域名/服务和协议开放；防范 SSRF 与内部网络探测。
- 身份与密钥：短期、限权凭据；工具网关代调用；禁止在 Prompt、日志或产物中传播密钥。
- 租户隔离：任务身份贯穿数据库查询、对象存储路径、队列、缓存与工具访问，不能仅依赖前端过滤。
- 工具安全：工具定义、参数、审批和结果均视为需要验证的边界；对高风险动作实施独立授权。
6.3 Prompt Injection 的执行面防线
模型读到的网页、文件、检索片段和工具返回内容可能包含恶意指令。执行面应将这些内容视为不可信数据，确保其不能改变平台授予的权限。模型可以提出工具调用，但最终的工具访问必须由外部策略、参数校验和沙箱强制执行；不能仅靠系统提示词承诺“不会越权”。
七、长任务、取消、暂停与恢复
7.1 任务状态与尝试状态
建议分别维护 Run 和 Attempt 状态。参考 Run 状态：QUEUED → RUNNING → SUCCEEDED / FAILED / CANCELLED，并允许按业务需要进入 WAITING_APPROVAL、PAUSED、TIMED_OUT。Attempt 状态可为 CLAIMED → STARTING → RUNNING → SUCCEEDED / FAILED / LOST / CANCELLED。
这只是参考状态机；实际平台必须定义每个状态的进入条件、可执行操作、幂等规则和终态不可逆约束。暂停不等于挂起任意进程：如果 Runtime 不支持安全检查点，平台应在安全边界暂停后重新调度。
7.2 取消的正确语义
取消通常是协作式、最终生效的请求：控制面标记取消意图，执行面通过心跳或控制通道获知后停止新步骤、尝试终止子进程并清理资源。对于已经发出的外部副作用，取消不代表撤销。需要区分 CANCEL_REQUESTED 与 CANCELLED，并记录取消后仍可能完成的竞态情况。
7.3 心跳、租约与失联
Worker 应周期性续租并上报心跳。租约过期表示“该执行权不再可信”，不证明旧 Worker 已物理停止；因此新 Attempt 启动前后必须通过 fencing token 或下游强制机制阻止旧 Attempt 提交状态及危险副作用。网络分区可能造成双活，单靠心跳超时不足以保证无重复外部操作。
7.4 检查点与恢复语义
检查点至少记录恢复位置、Agent/Workflow 版本、必要状态引用和外部副作用完成记录。恢复策略可以是：从步骤边界继续、从最近检查点重放、整次任务重新执行，或交由人工处置。对于非确定性模型输出，恢复不等于位级重现；平台应追踪输入、模型版本、参数和关键外部依赖，并接受无法完全重现的边界。
八、状态上报、事件与可观测性
8.1 三类记录应分别设计
| 记录类型 | 目的 | 典型内容 | 可靠性要求 |
|---|---|---|---|
| 运行事件 | 推进业务状态 | AttemptStarted、CheckpointSaved、AttemptFailed | 去重、排序规则、可恢复 |
| 可观测性遥测 | 性能与故障诊断 | Trace、日志、指标、token 用量 | 采样、保留期、隐私控制 |
| 审计记录 | 责任与合规追踪 | 授权、审批、工具副作用、发布与取消 | 防篡改、访问控制、保留策略 |
不能把“有 Trace”视为“已经具备完整审计”。对于隐私和敏感数据，日志应默认脱敏，并对 Prompt/工具输入输出的存储实施独立策略。
8.2 推荐指标
- 队列等待时间、任务启动延迟、端到端完成时间及分位数。
- Run/Attempt 成功率、失败率、超时率、重试次数与失联次数。
- Worker 利用率、沙箱启动时间、并发数、队列积压量。
- 模型调用时延、token 消耗、工具调用失败率、预算触顶次数。
- 检查点成功率、恢复成功率、取消生效延迟、产物提交失败率。
指标需要按租户、任务类型、版本和执行池分组，但应控制标签基数，避免直接将 run_id 作为高基数指标标签。
九、故障模型与恢复策略
| 故障场景 | 可观测症状 | 建议处理 | 不应假设 |
|---|---|---|---|
| 队列重复投递 | 同一 Run 多次被消费 | 原子 Claim、幂等与租约校验 | 队列天然只交付一次 |
| Worker 崩溃 | 心跳停止、租约过期 | 标记 Attempt LOST，按策略新建 Attempt | 旧任务一定没有副作用 |
| 控制面暂时不可用 | 事件上报失败 | 本地缓冲/重试、租约策略、恢复后对账 | Worker 可无限离线运行 |
| 模型服务限流 | 429、延迟增大 | 有界退避、并发限制、降级 | 所有错误都可立即重试 |
| 工具调用超时 | 结果不确定 | 查询副作用状态、幂等键、人工介入 | 超时意味着调用未成功 |
| 沙箱资源耗尽 | OOM、CPU/磁盘限制 | 终止、归因、调整资源或拒绝重试 | 增加重试就能解决 |
| 检查点损坏 | 恢复失败 | 完整性校验、版本兼容、回退策略 | 检查点总可跨版本使用 |
| 取消与成功竞态 | 同时收到成功和取消 | 终态仲裁、审计事件、用户可见语义 | 取消请求必然优先 |
| 产物上传中断 | 临时文件或部分对象 | 临时区上传、校验、原子发布引用 | 文件存在即表示交付成功 |
| 租户访问越权 | 数据或工具跨租户访问 | 执行期再授权、隔离测试、拒绝并告警 | 控制面鉴权已足够 |
9.1 重试与死信
建议定义按错误类别分类的重试策略：瞬时网络错误可有限次数退避；参数错误、权限拒绝、预算耗尽通常不应自动重试；外部副作用不确定时先核对结果。超过阈值的任务进入人工处置或死信流程，并保留完整关联标识和失败原因。
十、Studio 贯穿案例：研究报告任务如何执行
10.1 业务场景
用户在 Studio 创建“城市文化创意产业研究”项目，选择工作流版本，启动研究任务。工作流包含选题 Agent、深度调研 Agent、分析 Agent、审核 Agent，并在关键节点等待用户确认，最终生成 Markdown/PDF 报告。
10.2 推荐的初期架构
flowchart LR
UI[Studio Frontend] --> API[Platform API + Control Modules]
API --> PG[(PostgreSQL)]
API --> MQ[(Durable Queue)]
MQ --> WK[Research Worker]
WK --> RT[Agent System / Workflow Runtime]
RT --> MG[Model API Gateway]
RT --> TO[Restricted Tools]
WK --> PG
WK --> OS[(Object Storage)]
API --> UI建议最小能力：版本固定、Run/Attempt 分离、队列可靠派发、Worker 心跳与租约、基础超时/取消、审批检查点、产物上传与审计。初期可使用一个 Worker 池，但应在代码中保留未来按工具风险和租户拆分执行池的接口。
10.3 一次执行的具体过程
- 用户发起 Run，控制面记录工作流版本、Agent 版本和项目权限。
- Worker 领取选题任务并启动 Agent System；检索工具通过受控网关调用。
- 选题完成后写入检查点与候选题产物，Run 进入等待用户审批的状态。
- 用户确认后，控制面创建新的可执行阶段；Worker 不必长期占用计算资源等待人工回复。
- 深度调研与分析阶段按工作流策略执行，可并发的步骤受到预算与并发限制。
- 审核失败时触发受控返工，记录每次 Attempt/迭代，不覆盖先前产物。
- 报告产物经校验后发布到项目资产区，Run 终结，临时执行环境被清理。
边界提醒：这是一种参考实现，不代表 Studio 当前代码已经具备上述能力。实际采用前应对现有代码、框架、队列和数据库结构做差距评估。
10.4 MVP 与成熟平台的演进
| 阶段 | 执行面重点 | 暂缓的复杂能力 |
|---|---|---|
| PoC | 单 Worker、可追踪执行 | 多租户、公平调度、弹性扩容 |
| 单租户 MVP | 可靠队列、Run/Attempt、取消、检查点 | 多集群、复杂沙箱池 |
| 团队平台 | 权限边界、资源配额、Worker 池、故障恢复 | 跨地域调度、完整市场生态 |
| 多租户平台 | 强隔离、租户公平、审计与计费 | 无明确收益的超前拆分 |
| 规模化运营 | 弹性扩缩容、分级执行池、容量治理 | 依据真实指标持续决策 |
十一、工程设计决策与技术选型
11.1 先做决策，再选工具
选择队列、Worker 框架、容器编排与沙箱技术前，先回答：单次任务最长多久？是否允许不可信代码？需要多少并发？是否跨租户？外部副作用是否可重试？是否需要人工审批后恢复？可接受的恢复时间和数据损失是什么？预算上限是多少？
11.2 常见技术路径（示例，不构成产品推荐）
| 能力 | 可选技术方向 | 选择依据 |
|---|---|---|
| 任务队列 | PostgreSQL 作业表、Redis 队列、消息代理 | 可靠性、吞吐、运维成本 |
| Worker 执行 | 独立 Python/Node 进程、容器化任务 | 语言生态、任务时长、隔离 |
| 工作流持久化 | 数据库状态机、持久化工作流引擎 | 恢复语义、复杂度、团队能力 |
| 沙箱 | OS 进程限制、容器、微虚拟机 | 威胁模型、冷启动与成本 |
| 状态存储 | 关系数据库 + 对象存储 | 一致性、查询、产物规模 |
| 可观测性 | OpenTelemetry 生态及日志/指标后端 | 跨服务关联、隐私与成本 |
11.3 架构决策记录（ADR）示例
ADR-P2-001：Studio MVP 使用独立 Worker，而非在 HTTP 请求中执行长任务。 背景：研究任务可能持续数分钟到数小时，且包含审批等待。决策：平台 API 只负责准入与 Run 创建，Worker 通过队列异步执行；Run 状态持久化。收益：部署解耦、任务可追踪、故障恢复边界清晰。代价：增加队列、事件、幂等和租约实现。触发复审条件：真实并发、任务时长、故障率或隔离要求显著变化。
十二、测试与验证方案
以下为待实施的测试计划，不是已执行结果。每项测试应记录环境、版本、输入、步骤、预期、实际结果和证据链接。
| ID | 测试主题 | 注入/操作 | 验收重点 |
|---|---|---|---|
| P2-T01 | 任务领取幂等 | 重复投递相同消息 | 同时只有合法 Attempt 拥有租约 |
| P2-T02 | Worker 崩溃 | 执行中强制终止进程 | 识别失联并按策略恢复 |
| P2-T03 | 旧租约隔离 | 租约过期后提交旧结果 | 旧 Attempt 不能覆盖新终态 |
| P2-T04 | 控制面断连 | 中断 Worker 与 API 网络 | 缓冲/重试与最终对账符合契约 |
| P2-T05 | 任务取消 | 长工具调用中请求取消 | 状态可追踪，副作用语义明确 |
| P2-T06 | 超时限制 | 超过 wall-time | 任务被终止/标记且资源释放 |
| P2-T07 | 资源耗尽 | 限制内存/磁盘/CPU | 不影响其他任务，错误可归因 |
| P2-T08 | 检查点恢复 | 保存后重启 Worker | 在声明的恢复点继续或安全失败 |
| P2-T09 | 非幂等工具 | 模拟响应丢失 | 不发生未受控重复副作用 |
| P2-T10 | 跨租户访问 | 修改对象引用和工具参数 | 拒绝越权并生成审计记录 |
| P2-T11 | 密钥泄露 | 检查日志、Prompt、产物 | 不出现明文长期凭据 |
| P2-T12 | 队列积压 | 制造突发高并发 | 延迟、拒绝与配额行为符合策略 |
| P2-T13 | 产物完整性 | 中断上传、篡改哈希 | 不发布损坏或未授权产物 |
| P2-T14 | 事件乱序 | 重排完成/心跳事件 | Run 状态不倒退、不非法终结 |
| P2-T15 | 审批等待 | 人工审批延迟数小时 | Worker 不需持续占用执行资源 |
| P2-T16 | 模型限流 | 模拟 429 与超时 | 有界退避，不超出预算 |
| P2-T17 | Sandbox 网络策略 | 访问未授权地址 | 网络请求被阻断并记录 |
| P2-T18 | 版本一致性 | 执行中发布新版本 | 既有 Run 保持原版本快照 |
12.1 验收证据要求
每项验证至少提供：测试环境与依赖版本、可复现步骤、日志/Trace/事件关联标识、数据库状态变化、关键安全策略、实际结果及已知限制。若测试未执行，应标记“待验证”，不能写成“已通过”。
十三、与其他专题的职责衔接
| 关联专题 | P2 负责 | 对方专题深入研究 |
|---|---|---|
| P1 · Control Plane | 消费执行意图、报告执行事实 | 准入、控制命令、状态仲裁 |
| P3 · Agent Registry | 加载已固定的定义/版本引用 | 定义注册、存储、版本治理 |
| P4 · Agent Development Services | 承载测试运行环境 | 开发、调试、构建服务 |
| P5 · Deployment & Runtime Management | Worker、Attempt 与运行实例的执行机制 | 部署目标、实例编排和生命周期管理 |
| P6 · Workflow Management | 执行工作流节点与检查点 | 工作流定义、调度与编排治理 |
| P7 · Resource & Integration | 受控访问模型、工具与知识资源 | 资源目录、接入与统一配置 |
| P8 · Platform API & SDK | 提供执行事件与结果接口 | 对外 API、SDK 和契约治理 |
| P9 · Extensibility & Ecosystem | 在沙箱中执行插件与扩展 | 扩展点、插件生命周期与生态 |
| P10 · Platform Data & Assets | 写入检查点与产物 | 数据模型、资产归属与共享 |
| P11 · Multi-tenancy & Isolation | 强制落实运行时隔离 | 租户模型、隔离策略与验证 |
| P12 · Platform Governance | 执行预算、策略与审计要求 | 权限、配额、策略和治理机制 |
与 03 · Agent System 的边界：L4 解释 Agent Engine 如何驱动单个 Agent 的推理和工具调用；L5 解释任务编排与多 Agent 协作；H4/H7/H11 解释系统级状态、可靠性与部署。P2 则解释平台如何在多个 Run、Worker、租户和执行环境之间承载这些系统能力。
十四、常见误区与研究自检
- 把执行面等同于 Agent Framework。 Framework 只是执行面可承载的一种 Runtime。
- 把 Worker 心跳当作精确的任务完成证明。 心跳只能反映某个时刻的可达性。
- 把消息去重当作副作用幂等。 外部系统可能已经成功处理请求。
- 把容器当作天然安全边界。 仍需限制网络、文件、凭据、权限和内核攻击面。
- 把取消当作回滚。 已执行的外部操作需要补偿或人工处理。
- 把检查点当作确定性重放。 模型与外部环境变化会影响结果。
- 把 Worker 横向扩容当作吞吐提升保证。 模型 API 限流、工具瓶颈与数据库争用可能成为新瓶颈。
- 把平台级执行和 Agent 内部规划混在一起。 二者应通过明确 Runtime Adapter 与事件契约连接。
- 在尚无真实需求时过度微服务化。 优先建立正确的对象模型、租约、幂等与隔离。
自检问题：能否解释一个 Run 的多个 Attempt？能否处理 Worker 失联后的双活？能否指出每个副作用的幂等边界？能否说明任务取消和审批等待时的资源占用？能否将日志、业务事件与审计分开？能否用可执行测试验证跨租户隔离？
十五、总结与后续研究
Execution Plane 的核心价值，是把“允许执行某个 Agent System”转化为“在明确资源与权限边界内可靠执行，并产生可追踪的事实和结果”。实现这一目标，必须同时具备执行载体、租约与尝试模型、异步任务契约、运行隔离、状态上报、恢复策略和产物管理。复杂调度与大规模基础设施可以渐进引入，但这些基础语义不能省略。
下一篇 P3 · 如何注册、存储和管理 Agent 定义与版本？ - Agent Registry 将研究 Agent 定义与版本如何被登记、校验、解析、引用、发布及审计，并与 P1/P2 的执行快照衔接。
第六轮跨章节契约核对（v1.3-r1；2026-11-01）
[平台设计决策 / 待测试] 本节是领域级一致性修订说明，优先于本篇不一致的历史局部示例；不表示已执行数据库迁移、API 合约或运行测试。统一参考：
04-Agent-Platform-Canonical-Contracts-v1.3-r1.md。
本篇的 WAITING_APPROVAL 与 CANCEL_REQUESTED 是历史说明用状态；统一 Run 枚举分别采用 waiting + status_reason=approval 与 desired_action=cancel，受理取消后可进入 cancelling，最终确认停止后才是 cancelled。Attempt 状态机独立定义，不应与 Run 枚举合并。
上述映射不应机械替换其他对象（如 ManagementOperation、Deployment）的同名状态；正式实施应更新 OpenAPI/JSON Schema、SQL 约束、事件消费者、UI 映射及测试。
附录 A：参考文献与原始资料
以下资料用于进一步核对执行模型、分布式任务、隔离与可观测性的通用工程原理。不同产品的行为与 API 可能随版本变化；本文没有将任何一种框架的实现方式视为唯一标准。
- Kubernetes Documentation, Jobs - kubernetes.io/docs/concepts/workloads/controllers/job （批处理任务与重试语义）。
- Kubernetes Documentation, Resource Management for Pods and Containers - kubernetes.io/docs/concepts/configuration/manage-resources-containers （资源请求与限制）。
- Kubernetes Documentation, Pod Security Standards - kubernetes.io/docs/concepts/security/pod-security-standards （工作负载安全约束）。
- Temporal Documentation - docs.temporal.io （持久化工作流、重试与执行恢复的产品实现参考）。
- Celery Documentation, Tasks - docs.celeryq.dev/en/stable/userguide/tasks.html （任务确认、重试与幂等）。
- RabbitMQ Documentation, Consumer Acknowledgements and Publisher Confirms - www.rabbitmq.com/docs/confirms （消息确认与可靠投递）。
- PostgreSQL Documentation, Explicit Locking - www.postgresql.org/docs/current/explicit-locking.html （并发领取与锁机制参考）。
- OpenTelemetry Documentation - opentelemetry.io/docs （Trace、Metrics、Logs）。
- OWASP, Top 10 for LLM Applications - owasp.org/www-project-top-10-for-large-language-model-applications （提示注入与工具使用风险）。
- NIST, AI Risk Management Framework - www.nist.gov/itl/ai-risk-management-framework （AI 系统风险管理原则）。
- AWS Builders' Library, Making retries safe with idempotent APIs - aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs （分布式重试与幂等设计）。
- Martin Kleppmann, Designing Data-Intensive Applications, O'Reilly, 2017（分布式系统一致性、复制与故障语义背景）。
附录 B：研究证据、验证声明与适用边界
B.1 证据类型
- 行业通用工程原则：队列重复投递、重试、幂等、资源隔离、日志与指标等，参考上列官方技术文档与分布式系统文献。
- 研究性抽象：Control Plane / Execution Plane 的职责划分、Run/Attempt/Lease/Sandbox 对象模型、六类质量目标及阶段性演进路径，是为本知识库构建的统一分析框架；不是行业强制标准。
- 参考设计：JSON 契约、Mermaid 图、Studio 架构、状态枚举、风险分级和测试表是教学与工程设计建议，不能直接作为已验证的生产实现。
B.2 验证声明
本文完成了概念建模、架构对照、故障推演和可测试性设计；未在真实 Studio 环境部署 Worker、队列、沙箱或执行故障注入测试。未对第三方平台进行当前版本的实测；具体产品行为应以实际版本文档与实验为准。文中的 P2-T01 至 P2-T18 均为待实施验证项。
B.3 适用边界与待研究问题
本篇适用于需要执行长任务、工具调用或多 Agent 工作流的平台，尤其适用于从单租户 MVP 向团队或多租户服务演进的场景。对于严格实时控制、硬实时工业系统、强监管金融交易或不可信代码托管等场景，还需专项威胁建模、形式化约束和行业合规评估。
后续研究重点：P5 进一步确定 Deployment、Runtime Instance 与 Worker 的管理关系；P6 进一步确定工作流持久化与节点调度；P11 进一步确定多租户隔离级别；P12 进一步确定资源配额、策略执行点和审计责任。