P5 · 如何管理 Agent 的部署、实例与运行生命周期？ - Deployment & Runtime Management
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：02 · Agent Platform 是如何构建和运行的？ - Technical Architecture
文档类型：专题研究 / 技术架构 / 参考设计
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：平台如何把不可变 Agent Version 转化为可用的部署服务，管理 Deployment、Runtime Instance、Run 和 Attempt 的不同生命周期，并在升级、扩缩容、故障与回滚时保持可追溯、可控和安全？
专题导读
本篇属 Technical Architecture。P5 研究 Deployment & Runtime Management：连接 P3 Agent Registry 的发布资产、P1 Control Plane 的控制决策和 P2 Execution Plane 的执行资源。它既不是单纯的容器部署教程，也不是 Agent 内部推理循环的实现。研究重点是部署意图、实际运行实例、任务执行之间的关系，以及平台如何协调它们。
本篇采用“定义版本 - 部署配置 - 运行实例 - 任务执行”的对象链，并进一步区分 Deployment Revision、Replica、Run 与 Attempt。下文给出的状态机、数据库表、API 和参数均为参考设计，不是所有平台必须遵守的行业标准。平台可采用常驻服务、按需 Worker、作业容器或混合运行模式。
研究结论
- 发布不等于部署，部署不等于执行。 Registry 中的不可变版本只有在被部署到某个环境并通过准入、资源和健康检查后，才构成可调用的服务或任务模板。
- Deployment 是期望状态的声明；Runtime Instance 是实际承载能力的实体；Run 是一次业务执行；Attempt 是其执行尝试。 四者不应共用一个状态字段。
- 控制面维护期望状态，执行面报告观测状态。 调谐器（reconciler）通过幂等操作逐步缩小两者差距；网络分区期间不能假设即时一致。
- 部署升级必须明确新旧版本的路由规则和回滚边界。 对于长任务，切换新流量不意味着迁移或中止已经开始的 Run。
- 扩缩容需要同时考虑平台负载与外部依赖约束。 Worker 数量、模型速率限制、工具配额、租户预算、队列等待时间必须联合管理。
- 故障恢复不能仅靠重试。 需要持久化状态、租约、幂等键、检查点与外部副作用对账；对于非幂等操作，优先确认结果再决定重试。
- MVP 宜采用模块化控制服务、关系数据库、可靠任务队列和独立 Worker。 当需求明确后，再增加多环境发布、渐进流量切换、自动扩缩容和跨区域灾备。
一、定义与研究边界
1.1 Deployment Management
部署管理负责将已验证、已授权的 Agent Version 或 Workflow Version 与运行环境、资源规格、工具权限、密钥引用、模型路由和流量策略关联起来，并形成可审计的部署记录。其输出不是模型响应，而是可供执行控制面解析的部署配置与运行端点。
典型职责包括：部署创建与审批、环境差异配置、版本固定、部署修订、激活与停用、健康检查、滚动升级、回滚和退役。部署系统可能使用 Kubernetes、容器平台、Serverless 或自定义 Worker 池，但这些是实现选择，而非定义要件。
1.2 Runtime Management
运行管理负责维护运行承载能力及其可用性，包括 Worker/Replica 注册、心跳、容量、调度目标、资源约束、隔离级别、健康状态、租约和故障处置。对于按需执行的平台，运行实例可能只在任务期间存在；对于常驻服务，运行实例可能长期在线。
边界约定： P2 解释执行面如何真正运行任务；P5 解释平台如何部署、配置、追踪、调整和回收这些执行能力。P6 专注工作流定义与调度，不在 P5 重复研究 DAG、步骤编排和多 Agent 协作算法。
1.3 相邻专题的责任矩阵
| 专题 | 核心责任 | 与 P5 的交界 |
|---|---|---|
| P1 Control Plane | 授权、准入、全局控制命令 | P5 执行部署及运行管理决策 |
| P2 Execution Plane | Worker、Sandbox、Attempt 实际执行 | P5 管理执行承载能力和生命周期 |
| P3 Agent Registry | 不可变定义与版本、依赖锁定 | P5 引用和部署已发布版本 |
| P4 Development Services | 草稿、校验、测试、构建 | P5 不负责修改开发草稿 |
| P6 Workflow Management | 工作流编排、触发、步骤调度 | P5 为其提供可用运行目标 |
| P11 Multi-tenancy | 租户身份、隔离模型 | P5 落实资源隔离和容量约束 |
| P12 Platform Governance | 策略、权限、配额、审计 | P5 在部署和运行阶段执行策略 |
二、核心对象与关系模型
2.1 对象清单
| 对象 | 稳定标识 | 主要职责 | 生命周期特征 |
|---|---|---|---|
| Agent Definition | agent_id | 逻辑身份 | 可长期存在 |
| Agent Version | version_id | 不可变能力快照 | 发布后不可原地修改 |
| Deployment | deployment_id | 环境中的部署逻辑身份 | 可持续升级 |
| Deployment Revision | revision_id | 一次不可变部署配置快照 | 每次变更生成新修订 |
| Runtime Instance | instance_id | 实际执行进程/容器/Worker | 可短暂、可替换 |
| Run | run_id | 一次业务执行请求 | 独立于实例生命周期 |
| Attempt | attempt_id | 一次实际执行尝试 | 可因失败重新创建 |
| Artifact | artifact_id | 运行结果及中间产物 | 可按策略保留 |
2.2 对象关系
flowchart TD
A[Agent Definition] --> V[Agent Version]
V --> D[Deployment]
D --> R[Deployment Revision]
R --> I[Runtime Instance / Worker]
D --> U[Run]
U --> T[Attempt]
T --> I
U --> O[Artifacts / Events]图中边表示逻辑关联而非必然的数据库外键或一对一关系。一个 Deployment 可以有多个 Revision；同一 Revision 可有多个实例；一个 Run 可有多个 Attempt；按需 Worker 模式中，Run 也可能先于实例创建。
2.3 为什么需要 Deployment Revision
如果直接修改 Deployment 的 version_id、资源规格和密钥引用，历史 Run 将难以证明当时使用了什么配置。建议将 Deployment 保留为稳定逻辑入口，所有实质配置变更产生不可变 Revision，并记录 created_by、approved_by、config_digest 和 effective_at。历史 Run 应固定 Revision 与 Agent Version；对于运行时可变外部依赖，还需记录模型版本/别名解析结果、工具版本和策略版本，不能仅凭 Revision 断言完全可复现。
三、部署生命周期
3.1 推荐状态机
stateDiagram-v2
[*] --> Draft
Draft --> Validating: submit
Validating --> Rejected: checks fail
Rejected --> Draft: revise
Validating --> Ready: checks pass
Ready --> Deploying: activate
Deploying --> Healthy: readiness passes
Deploying --> Degraded: partial readiness
Healthy --> Updating: new revision
Updating --> Healthy: rollout success
Updating --> Degraded: rollout issues
Degraded --> Healthy: recover
Healthy --> Draining: deactivate
Degraded --> Draining: deactivate
Draining --> Retired: no new traffic and policy satisfied该状态机为教学模型。实际实现应区分用户期望状态（例如 active、suspended、retired）与系统观测状态（例如 ready、degraded、unavailable），否则在部署过程中容易出现并发更新和状态覆盖。
3.2 部署准入检查
部署前应验证：版本存在且可发布；租户有权使用；依赖已解析；目标环境支持运行时能力；资源配额足够；密钥引用可解析且最小授权；模型与工具策略允许；镜像或构建工件符合完整性要求；发布审批和变更窗口符合治理策略。验证通过仅说明允许尝试部署，不等于部署成功或运行质量达标。
3.3 多环境管理
建议至少区分 development、staging、production 三类逻辑环境，但单人 MVP 可先使用 local 和 production。环境差异通过配置引用表达，而不是复制 Agent Definition。严禁将生产密钥直接写入 Manifest 或 Deployment Revision 的明文字段。环境隔离可由命名空间、独立数据库/队列、独立集群或云账号实现，隔离强度应由风险模型决定。
四、运行实例生命周期
4.1 实例与健康
Runtime Instance 代表具体的执行承载体，可能是容器、进程、沙箱、远程 Worker 或托管计算实例。建议记录 instance_id、tenant_scope、runtime_kind、revision_id、capacity、last_heartbeat_at、lease_epoch 和 observed_state。
健康信号应分层：**存活（liveness）**表示进程仍运行；**就绪（readiness）**表示可接新任务；**执行健康（execution health）**表示任务完成率、超时率和依赖失败率在可接受范围。三者不能互相替代。Worker 可以存活但无法访问模型服务；也可能正常执行长任务而短期没有空闲容量。
4.2 实例状态与回收
参考状态：provisioning → starting → ready → busy → draining → terminated，另设 unhealthy。进入 draining 后停止领取新任务，已运行任务依据策略继续、迁移、检查点暂停或超时终止。对于不支持安全迁移的 Agent Run，不应声称可以无损热迁移。
4.3 心跳、租约与 fencing
Worker 通过心跳报告健康和容量；任务领取采用带期限的 Lease。租约过期只能说明所有权需要重新确认，不能证明旧 Worker 已停止执行。为避免旧 Worker 在网络恢复后提交结果，可使用递增的 fencing_token 或 attempt_epoch，由状态存储与外部提交网关拒绝过期写入。对于无法受控的第三方 API 副作用，仍需要幂等键、对账或人工处理。
五、Run 与 Attempt 的运行生命周期
5.1 Run 状态
建议区分：created、queued、running、waiting_approval、paused、succeeded、failed、cancelled。其中 cancel_requested 可作为单独控制字段，避免将“请求取消”误认为“已停止”。具体状态集合需与 P1、P2 的接口保持一致。
5.2 Attempt 状态
Attempt 表示执行尝试，可采用 leased、starting、running、succeeded、failed、lost、timed_out。Run 的最终结果由 Attempt 结果与重试策略共同决定。一个 Attempt 失败不一定使 Run 失败；一个 Run 成功也不代表所有历史 Attempt 均成功。
5.3 状态持久化与恢复
最小可恢复记录应包含：Run 与 Attempt ID、固定版本/修订、输入引用、执行状态、最后检查点、外部操作幂等键、审批状态、时间戳、失败原因及产物引用。检查点可降低重做成本，但不保证模型推理和外部环境逐字重放。恢复前必须核对已完成的外部操作，避免重复发送邮件、重复提交付款或重复发布产物。
六、部署升级、流量切换与回滚
6.1 升级策略
| 策略 | 实施方式 | 适用场景 | 主要风险 |
|---|---|---|---|
| Recreate | 停旧启新 | 非关键、可中断任务 | 服务中断 |
| Rolling | 逐批替换实例 | 常驻服务、兼容升级 | 新旧并存时行为差异 |
| Blue-Green | 两套环境切换入口 | 快速回滚 | 资源成本较高 |
| Canary | 少量新流量逐步放量 | 高风险行为变更 | 样本量和评价偏差 |
| Shadow | 新版本只观察不产生副作用 | 行为比较 | 额外成本、数据安全 |
对于 Agent，灰度判断不能只看 HTTP 5xx；还应比较任务完成率、人工介入率、工具错误、成本、延迟、策略违规和业务质量。对模型生成行为的统计评估要考虑样本代表性与不确定性。
6.2 新旧 Run 的版本固定
路由规则只影响新 Run。已经开始的 Run 应继续绑定原 Revision，除非平台明确支持受控迁移并证明状态兼容。用户请求“回滚”时，通常意味着把新流量切回旧 Revision，而不是自动撤销所有已发生的外部操作。
6.3 数据兼容性
升级涉及数据库模式、事件契约、检查点格式、工具协议与工作流定义。应采用向后兼容的扩展 - 迁移 - 收缩策略；对无法兼容的变更建立明确迁移方案和回退条件。发布 Agent Version 的回滚与数据库回滚不是同一问题。
七、容量、调度与自动扩缩容
7.1 四类约束
平台至少同时关注：计算资源（CPU、内存、并发）、模型服务（RPM、TPM、并发、区域）、工具服务（速率限制、连接数、权限）以及租户策略（预算、配额、公平性）。扩容 Worker 不一定提高吞吐量，瓶颈可能是模型或第三方工具。
7.2 扩缩容信号
建议组合队列等待时间、待处理任务数、Worker 利用率、任务运行时间分布、模型限流率和预算消耗速度。对长任务，仅使用 CPU 百分比容易误判。扩容应有最大实例数、冷却时间和成本上限；缩容应优先排空 Worker，避免杀死有状态任务。
7.3 租户公平性
共享 Worker 池需要防止单一租户占满资源。可采用租户级并发上限、加权公平队列、预留容量和优先级，但优先级不能绕过授权与预算策略。不同隔离级别的任务不应无条件共享同一执行环境。
八、可靠性、失败模式与恢复
| 故障 | 可观测现象 | 推荐处理 | 必须避免 |
|---|---|---|---|
| Worker 崩溃 | 心跳停止、Lease 过期 | 标记 Attempt lost，检查点恢复 | 盲目重复外部副作用 |
| 队列重复投递 | 同一任务被多次领取 | 幂等领取、fencing | 认为队列天然 exactly-once |
| 控制面短时不可用 | 无法创建/取消 Run | 持久化命令、重试、降级 | 丢失操作意图 |
| 模型服务限流 | 429、延迟升高 | 退避、并发限制、路由策略 | 无界重试 |
| 新版本异常 | 质量或错误率恶化 | 停止放量、切回旧 Revision | 假设回滚能撤销副作用 |
| 实例缩容过快 | 运行中任务中断 | draining、检查点、超时策略 | 直接杀死长任务 |
| 审批等待过久 | Run 长期 waiting | 到期策略、提醒、人工处理 | 默认自动批准高风险动作 |
| 存储或事件异常 | 状态落后、事件缺失 | Outbox、对账、重放 | 仅依赖内存状态 |
交付语义： 任务队列常见的是至少一次投递；通过幂等和事务设计追求“业务结果只生效一次”，而不是宣称整个分布式系统天然 exactly-once。对于第三方非幂等操作，应显式记录不确定状态并执行对账。
九、安全、权限与租户隔离
部署授权应至少校验主体、租户、目标环境、Agent Version、资源配额和允许的工具权限。部署凭据、运行凭据与用户交互凭据应分离，运行时尽可能使用短期凭据。Worker 不应凭客户端提供的 tenant_id 自行信任租户归属，而应使用控制面签发的可信执行上下文。
对于执行不可信代码、浏览器自动化或文件处理的任务，应依据风险使用容器、进程沙箱或更强隔离机制，并限制文件系统、网络出口、系统调用和秘密访问。容器本身并非对所有攻击模型都足够的安全边界。跨租户缓存、对象存储前缀和日志也需纳入隔离审查。
十、数据结构与接口契约参考
10.1 Deployment Revision 示例
{
"deployment_id": "dep_research_prod",
"revision_id": "rev_0007",
"agent_version_id": "av_research_1_4_2",
"environment": "production",
"runtime_profile": "worker-python-standard",
"resource_limits": {"max_concurrent_runs": 4, "memory_mb": 2048},
"secret_refs": ["secret://research/search-api"],
"routing_weight": 100,
"config_digest": "sha256:example-not-a-real-digest",
"created_by": "user_admin",
"status": "ready"
}示例中 routing_weight 是一种简化字段。真实平台若采用多个 Revision 并行路由，通常应由 Deployment 的路由策略统一保存各 Revision 权重，避免分别修改导致权重不一致。secret_refs 只保存引用，不保存密钥明文。
10.2 Run 创建契约
POST /v1/deployments/{deployment_id}/runs
Idempotency-Key: run-create-20261031-001
Authorization: Bearer <token>
Content-Type: application/json{
"input": {"topic": "2026 AI Agent 平台生态"},
"execution_mode": "async",
"requested_revision": null,
"project_id": "project_research_01"
}{
"run_id": "run_1042",
"deployment_id": "dep_research_prod",
"resolved_revision_id": "rev_0007",
"resolved_agent_version_id": "av_research_1_4_2",
"status": "queued"
}这些路径和字段为教学性 API 设计，不代表既有行业协议。生产系统需补充输入 Schema 校验、权限、限流、错误码、审计和幂等键作用域。
10.3 参考关系表
CREATE TABLE deployment (
id TEXT PRIMARY KEY,
tenant_id TEXT NOT NULL,
environment TEXT NOT NULL,
desired_state TEXT NOT NULL,
active_revision_id TEXT,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE TABLE deployment_revision (
id TEXT PRIMARY KEY,
deployment_id TEXT NOT NULL REFERENCES deployment(id),
agent_version_id TEXT NOT NULL,
config_digest TEXT NOT NULL,
config_json JSONB NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE TABLE agent_run (
id TEXT PRIMARY KEY,
deployment_id TEXT NOT NULL REFERENCES deployment(id),
revision_id TEXT NOT NULL REFERENCES deployment_revision(id),
status TEXT NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE TABLE run_attempt (
id TEXT PRIMARY KEY,
run_id TEXT NOT NULL REFERENCES agent_run(id),
attempt_no INTEGER NOT NULL,
worker_id TEXT,
fencing_epoch BIGINT NOT NULL DEFAULT 0,
status TEXT NOT NULL,
UNIQUE (run_id, attempt_no)
);实现注意： 此 SQL 仅表达最小对象关系，尚未包含完整租户复合外键、Revision 不可变触发器、幂等表、事件 Outbox、索引、审计字段和状态迁移约束；不能直接视为生产级数据库设计。
十一、参考架构与实现选择
11.1 MVP 参考架构
flowchart LR
UI[Studio UI] --> API[Platform API / Control Modules]
API --> DB[(PostgreSQL)]
API --> Q[(Durable Queue)]
API --> REG[Agent Registry]
API --> DEP[Deployment Manager]
DEP --> DB
Q --> W[Worker Pool]
W --> RT[Agent System Runtime]
W --> DB
W --> OBJ[(Object Storage)]
W --> OBS[Logs / Traces / Metrics]在此结构中，Deployment Manager 可以先作为模块化单体的一部分，不必独立成微服务。Worker 独立进程承载长任务；队列保证异步派发；数据库持久化状态；对象存储保存资料与产物。
11.2 三种执行承载方式
| 模式 | 特征 | 优点 | 代价 |
|---|---|---|---|
| 常驻 Worker 池 | Worker 持续领取任务 | 启动快、易共享容量 | 需管理实例和隔离 |
| 每 Run 独立 Job | 每任务创建隔离执行单元 | 资源边界清晰 | 冷启动和调度成本 |
| 托管 Serverless | 事件驱动按需执行 | 运维负担低 | 时长、状态与网络约束 |
对需要长时间运行、人工暂停和多工具交互的 Studio，常驻 Worker 或持久化作业系统通常更容易实现可恢复执行；是否采用 Kubernetes Job、Temporal 等技术，应在明确业务负载和团队运维能力后决定。
11.3 架构演进路线
阶段 A：单租户 MVP。 实现固定版本、Deployment 配置、异步 Run、独立 Worker、基本状态与人工取消。
阶段 B：可靠运行。 增加租约、心跳、检查点、Outbox、幂等和失败对账。
阶段 C：团队化。 增加多环境、权限分级、发布审批、版本回滚、队列公平性。
阶段 D：规模化。 增加自动扩缩容、灰度发布、跨租户隔离强化、区域部署与灾难恢复。
阶段划分是建议路径，不是成熟度标准。应以验收证据而不是功能数量决定是否升级架构。
十二、贯穿案例：研究报告 Studio
假设 Studio 已有三个已发布 Agent Version：选题、深度调研和审核。平台在生产环境创建 deployment_research，引用固定的 Workflow Version，并通过版本锁定关联三个 Agent Version。
用户启动报告任务时，Control Plane 验证项目权限和预算，解析当前生效的 Deployment Revision，创建 Run 并持久化输入与版本引用。Worker 领取 Attempt，加载 Agent System Runtime，执行选题、调研和审核步骤。审核不通过时由 P6 的工作流逻辑决定返工；需要用户确认时，Run 进入 waiting_approval，释放不必要的计算资源，等待审批事件后恢复。
若此时平台将选题 Agent 从 v1 升级到 v2，新启动的 Run 可以路由到新 Revision；正在进行的报告继续引用原 Revision，避免同一次研究中途改变 Agent 行为。若新版本表现异常，平台停止向新 Revision 分配流量并回滚路由，同时保留新旧 Run 的审计与质量指标。
12.1 Studio 最小验收场景
- 发布 v1 后创建 Deployment，能够成功运行并固定 Revision。
- 发布 v2 并切换新流量，既有 Run 仍可追溯 v1。
- Worker 在调研中崩溃，Run 能够被识别、恢复或明确失败。
- 用户暂停等待审批时，不占用不必要的活跃 Worker。
- 用户取消后，系统停止新步骤并报告可能已发生的外部副作用。
- 回滚后新 Run 使用旧 Revision，历史运行记录保持不变。
- 租户或项目权限不足时，部署和运行请求被拒绝并留痕。
十三、工程验证计划
以下测试是待执行验证计划，不是已完成的测试结果。
| 编号 | 验证主题 | 操作 | 预期结果 |
|---|---|---|---|
| T01 | 不可变版本 | 尝试修改已发布版本 | 拒绝原地修改 |
| T02 | 修订固定 | Run 启动后切换路由 | Run 保持原 Revision |
| T03 | 幂等创建 | 相同键重复提交 Run | 返回同一业务请求结果 |
| T04 | 并发更新 | 两管理员同时修改部署 | 乐观锁或冲突处理 |
| T05 | 发布准入 | 使用未授权工具 | 部署拒绝并审计 |
| T06 | 启动失败 | Worker 无法加载依赖 | 部署降级或 Attempt 失败 |
| T07 | 心跳失联 | 强制断开 Worker | Lease 过期后安全接管 |
| T08 | 旧 Worker 回归 | 模拟延迟写入 | fencing 拒绝过期提交 |
| T09 | 重复投递 | 队列投递同一消息两次 | 不重复产生业务副作用 |
| T10 | 取消竞态 | 完成瞬间发送取消 | 状态一致且记录竞态 |
| T11 | 人工审批 | 审批等待后恢复 | 无重复执行已完成步骤 |
| T12 | 滚动升级 | 逐批替换 Worker | 新旧 Run 路由符合策略 |
| T13 | 灰度回滚 | 注入新版本错误 | 停止新流量并回切 |
| T14 | 资源限额 | 超过租户并发限制 | 排队或明确拒绝 |
| T15 | 外部限流 | 模型持续返回 429 | 有界退避与降级 |
| T16 | 数据隔离 | 跨租户读取 Run | 拒绝访问 |
| T17 | 产物保留 | Run 完成并归档 | 产物按策略可访问 |
| T18 | 审计链 | 发布、执行、回滚全过程 | 可追溯主体、时间与版本 |
| T19 | 缩容排空 | Worker 运行中缩容 | 先 draining 再终止 |
| T20 | 配置兼容 | 升级事件与检查点格式 | 兼容或明确拒绝迁移 |
建议记录每项测试的环境、输入、执行步骤、观测证据、失败原因和复测结果。尤其应对 T08、T09、T10、T11 进行故障注入与并发测试，而不是仅检查正常路径。
十四、常见误区与架构检查
误区一：部署就是启动一个容器。 容器只是承载形式，部署还包含版本、配置、权限、路由、健康、回滚与审计。
误区二：Run 与 Worker 一一对应。 一个 Worker 可以执行多个 Run；一个 Run 可能跨多个 Worker 和 Attempt；有些工作流还会并行产生多个子执行。
误区三：发布新版本会自动更新运行中的任务。 默认应固定 Run 的版本，迁移必须显式设计和验证。
误区四：增加 Worker 就能解决吞吐瓶颈。 模型速率限制、工具 API 和租户预算常常是更紧的约束。
误区五：失败后重试即可保证可靠性。 重试可能重复外部副作用，需要幂等、对账和补偿策略。
误区六：部署健康等于业务质量合格。 Agent 可能技术上运行正常，但产生低质量研究结果；质量评估需与平台发布策略关联。
架构自检时，应能清楚回答：当前生产部署指向哪个 Revision？新旧 Run 如何路由？Worker 失联后谁有权接管？审批等待如何恢复？如何证明一次外部操作是否已发生？如何在不丢失历史记录的情况下回滚？如果无法回答，说明部署与运行管理尚未形成闭环。
十五、与后续研究的衔接
P5 提供部署与运行管理框架；P6 进一步研究工作流如何被定义、触发、调度和协调；P7 研究模型、工具与外部资源的统一管理；P8 研究平台 API 与 SDK；P11、P12 研究租户隔离和治理。产品章节 F6、F8、F9 将从用户角度研究执行操作、运行监控和 Agent 生命周期管理。工程章节将进一步落实技术选型、部署运维与测试。
第六轮跨章节契约核对（v1.3-r1；2026-11-01）
[平台设计决策 / 待测试] 本节是领域级一致性修订说明，优先于本篇不一致的历史局部示例；不表示已执行数据库迁移、API 合约或运行测试。统一参考：
04-Agent-Platform-Canonical-Contracts-v1.3-r1.md。
本篇示例枚举 waiting_approval 需映射为 execution_status=waiting、status_reason=approval；cancel_requested 只作 desired_action=cancel，不作为 Run 终态。运行时部署版本与 Agent/Workflow 已解析版本须在 Run 创建时固定，生产切换不应默默更改既有 Run 的版本引用。
上述映射不应机械替换其他对象（如 ManagementOperation、Deployment）的同名状态；正式实施应更新 OpenAPI/JSON Schema、SQL 约束、事件消费者、UI 映射及测试。
附录 A：参考文献与原始资料
以下以官方文档和标准规范作为进一步核验入口。它们支持相应工程概念，但不意味着本文参考对象模型、API 路径和状态机来自某一个标准。外部产品的具体功能、版本与支持范围应在实施前重新核对。
- Kubernetes Documentation - Deployments: kubernetes.io/docs/concepts/workloads/controllers/deployment （声明式部署、滚动更新和回滚的工程参照）。
- Kubernetes Documentation - Jobs: kubernetes.io/docs/concepts/workloads/controllers/job （批处理任务及重试行为）。
- Kubernetes Documentation - Pod Lifecycle: kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle （实例状态、就绪与生命周期）。
- Kubernetes Documentation - Horizontal Pod Autoscaling: kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale （自动扩缩容的基本机制）。
- Temporal Documentation: docs.temporal.io （持久化工作流与故障恢复思路；具体语义依 SDK/部署而异）。
- OpenTelemetry Documentation: opentelemetry.io/docs （分布式追踪、指标和日志的可观测性基础）。
- CNCF Cloud Native Glossary: glossary.cncf.io （云原生部署、声明式管理等术语）。
- NIST AI Risk Management Framework: www.nist.gov/itl/ai-risk-management-framework （AI 系统风险治理框架）。
- PostgreSQL Documentation - Transaction Isolation: www.postgresql.org/docs/current/transaction-iso.html （事务隔离与并发一致性）。
- AWS Builders' Library - Making retries safe with idempotent APIs: aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs （幂等请求与重试设计）。
附录 B：研究证据、验证声明与适用边界
B.1 证据分级
- 通用工程机制：Deployment、Job、健康检查、自动扩缩容、事务隔离等概念可在相应官方技术文档中核验。
- 综合架构推导：Agent Version、Deployment Revision、Run、Attempt 的分层模型及控制面协作，是对平台需求与分布式系统工程原则的综合设计。
- 教学性示例：本文 Mermaid、JSON、SQL、状态机、Studio 场景和 20 项测试为参考设计，不代表已在生产环境验证。
B.2 已完成与未完成
已完成：基于 v1.3 目录的职责边界梳理、对象模型设计、部署与运行机制分析、典型故障分析、接口和数据结构示例、验证计划编制。
未完成：真实平台部署、性能压测、并发与故障注入测试、生产安全审计、外部产品功能逐项核验。本文不宣称已经完成这些验证。
B.3 适用边界
本文适用于需要管理多个 Agent Version、运行环境与长任务的 Agent Platform。对于单一、短时、无状态的 Agent 应用，可以大幅简化 Deployment Revision、实例管理和灰度机制。对于强监管、多区域、高隔离环境，应增加合规、数据驻留、供应链签名和灾备要求。具体技术实现应依据负载、风险、成本与团队能力作出架构决策。