05 · 平台如何管理各类对象及其生命周期？ - Lifecycle Management
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：01 · Agent Platform 是什么？它如何工作？ - Fundamentals
文档类型：专题研究
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：Agent Platform 管理哪些核心对象？对象如何关联、演进、发布、运行、归档与删除？如何通过生命周期契约确保可追溯、可恢复、可治理，并避免将 Agent 定义、部署、实例和任务混为一谈？
专题导读
本篇属 Fundamentals。前四篇分别建立了 Agent Platform 的定义、组件、运行架构与类型分类。本篇建立平台对象模型与生命周期模型，为后续 P3 Agent Registry、P5 Deployment & Runtime Management、P10 Platform Data & Assets、P11 Multi-tenancy & Isolation，以及 F4 发布共享、F9 Agent Management、F10 产物交付等专题提供共同语义。
**核心结论：平台生命周期不是一条从“创建 Agent”到“删除 Agent”的单线流程，而是若干具有独立身份、状态、所有权和保留规则的对象生命周期的组合。**定义、不可变版本、部署、运行实例、任务运行、工作流、项目、资产与产物必须分别建模，再通过引用关系、事件与策略联动。
本文采用一种参考领域模型，而非宣称行业存在唯一标准。不同产品可能合并或拆分对象；应以其 API、存储契约和实际运行语义为准。示例状态机、数据结构和验收用例均为设计建议，未在真实系统中执行验证。
一、研究边界：什么是平台对象生命周期？
1.1 生命周期的定义
一个平台对象的生命周期（Lifecycle）是该对象从首次被识别和创建，到变更、使用、停用、保留以及最终清理的状态演进过程。完整生命周期需要同时定义：（1）对象标识与所有权；（2）允许的状态；（3）合法的状态迁移；（4）触发迁移的主体与条件；（5）每次迁移的持久化记录；（6）异常、撤销、恢复和终止路径；（7）保留、归档与删除策略。
生命周期与执行流程不同：一个 Agent Definition 可存在数年，某个 Version 可被多次部署，某次 Run 可能持续数分钟或数小时；不能将三者视为同一状态机。生命周期与产品操作也不同：“发布”按钮可能同时触发版本固化、审批、部署与路由切换，但这些是多个对象的事务或工作流，不是单一对象的一次简单字段修改。
1.2 与前三个领域的分工
- 01 AI：模型调用、上下文、推理与知识检索的能力原理。
- 02 Agent：单个 Agent 的角色、指令、能力、内部运行与 Agent 生命周期。
- 03 Agent System：任务执行、状态恢复、可靠性、测试、治理等系统级工程机制。
- 04 Agent Platform（本篇）：在多个 Agent、用户、工作空间和环境之间，管理定义、版本、部署、实例、运行记录和资产的平台级对象关系与治理契约。
因此，本文不重复解释 Agent 的推理循环，也不深入实现检查点存储算法；重点是平台应如何表达、关联和管理这些能力。
二、平台对象分类与最小领域模型
2.1 四组对象
| 对象组 | 核心对象 | 主要职责 | 典型生命周期 |
|---|---|---|---|
| 组织与归属 | Tenant、Organization、Workspace、Project | 隔离、权限、协作、归属 | 建立→使用→冻结/归档→删除 |
| 定义与发布 | Agent Definition、Agent Version、Workflow Definition/Version、Deployment | 定义能力、固化版本、决定可执行内容 | 草稿→版本→发布→停用 |
| 执行与控制 | Runtime Instance、Run、Attempt、Approval | 承载计算、记录执行、控制恢复 | 创建→运行→完成/失败/取消 |
| 资源与成果 | Resource Binding、Asset、Artifact、Template | 连接外部资源、保存输入输出、复用 | 登记→使用→版本化/保留→清理 |
这是一种逻辑对象划分；对象可以由一个数据库和一个后端服务承载，不意味着必须拆分成独立微服务。
2.2 必须明确的概念差异
**Agent Definition（定义）**是可编辑的逻辑身份和设计容器，例如“研究 Agent”。它不等于一次执行，也不必等于一份可部署快照。
**Agent Version（版本）**是特定时点被固化的配置与依赖引用集合。推荐对已发布版本采用不可变语义；修改应生成新版本，而非覆盖旧版本。
**Deployment（部署）**是将某个可执行版本绑定到环境、资源、配置与入口的发布关系。一个版本可部署至测试和生产等多个环境。
**Runtime Instance（运行实例）**是某一时间实际存在的运行载体，如容器、进程、托管执行单元或会话化执行器。它可能承载多个 Run；也可能每个 Run 独占实例。实例与 Deployment 并非总是一对一。
**Run（任务运行）**是一次用户请求或事件触发的可追踪执行记录。Run 的标识、输入、版本快照、状态与结果应可追溯。
**Attempt（执行尝试）**是一次 Run 中可区分的具体尝试。失败重试可以创建新的 Attempt，而不必创建新的业务 Run。
**Artifact（产物）**是执行产生的文件、报告、结构化数据或其他可交付成果；应与 Run 建立来源关系，同时具有独立的访问、保留和删除规则。
2.3 对象关系示意
flowchart TD
T[Tenant / Organization] --> W[Workspace]
W --> P[Project / Studio]
W --> D[Agent Definition]
D --> V[Agent Version - immutable]
V --> DEP[Deployment]
DEP --> RI[Runtime Instance]
DEP --> R[Run]
R --> AT[Attempt]
R --> AR[Artifact]
P --> R
W --> WF[Workflow Definition]
WF --> WV[Workflow Version]
WV --> R
R --> AP[Approval]
DEP --> RB[Resource Binding]此图是简化的关联图而非数据库外键规范。真实平台中 Run 可引用多个 Agent Version、Workflow Version 与 Tool/Skill/Model 配置快照；一个 Run 也可能跨多个 Runtime Instance 迁移。
三、对象身份、版本与引用规则
3.1 身份与名称分离
建议使用稳定的机器标识（如 agent_id、version_id、deployment_id、run_id），将用户可见名称、别名、Slug 与标识分离。名称可以更改；历史运行仍应指向原对象。跨租户查询必须始终在服务端校验归属和权限，不能只依赖客户端传来的 workspace_id。
3.2 版本固定与可重现性
一条生产 Run 至少应保存：Agent/Workflow 版本引用、解析后的配置摘要、模型与工具路由策略、资源绑定版本或快照、触发者、执行环境、开始时间和审计关联标识。对于会动态变化的外部模型、网页、知识库或 API，仅保存版本号不能保证字节级重现；应记录不可控依赖、调用证据与重放边界。
推荐区分三类引用：
- 固定引用（Pinned）：指向不可变版本或内容摘要，适用于审计与复现。
- 别名引用（Alias）：如
production、stable，适用于流量切换，但必须在 Run 启动时解析并记录具体目标。 - 动态引用（Floating）：如“最新可用模型”，适用于探索环境；在生产环境使用时应明确风险与回滚能力。
3.3 对象依赖图
发布版本可能依赖模型路由、工具权限、技能包、知识索引和外部密钥。建议维护依赖清单：对象类型、目标标识、版本/摘要、是否必需、权限要求、所有者、失效策略。删除或撤销被依赖资源前，应计算受影响部署与运行范围。
四、Agent Definition 与 Agent Version 的生命周期
4.1 推荐状态
Agent Definition 可使用 ACTIVE、ARCHIVED、DELETING 等管理状态；编辑中的草稿应通过独立的 Draft/Revision 表达。Agent Version 则可使用 DRAFT、VALIDATING、READY、PUBLISHED、DEPRECATED、REVOKED 等发布状态。
**注意：不可变与发布状态不矛盾。**版本内容一旦固化就不应修改；状态、批准记录、可用性与废弃标记可作为独立元数据演进。
stateDiagram-v2
[*] --> DRAFT
DRAFT --> VALIDATING: 提交验证
VALIDATING --> DRAFT: 校验不通过
VALIDATING --> READY: 校验通过
READY --> PUBLISHED: 审批/发布
PUBLISHED --> DEPRECATED: 停止推荐新使用
PUBLISHED --> REVOKED: 紧急撤销
DEPRECATED --> REVOKED: 安全或合规撤销4.2 版本发布的基本门禁
发布前建议检查：配置结构有效、依赖可解析、工具权限最小化、敏感信息未被写入明文版本、测试通过、预算与配额符合策略、审批已完成。是否必须全部执行取决于风险等级；低风险个人平台可采用轻量门禁，企业级平台应提高强制性。
4.3 废弃与撤销的区别
DEPRECATED 表示不再推荐新建部署或使用，但已有运行可能在过渡期继续；REVOKED 表示因安全、合规或严重缺陷而撤销可用性，通常需要阻止新的执行准入，并依据风险策略决定是否中断进行中的 Run。不要将两者统一为“删除”。
五、Deployment 的生命周期
Deployment 负责将可执行版本映射到特定环境与运行配置。建议至少记录 environment、version_id、config_revision、resource_profile、traffic_policy、status、created_by 和审计信息。
典型状态：CREATED → VALIDATING → DEPLOYING → ACTIVE → DRAINING → INACTIVE，并允许 FAILED、ROLLING_BACK 等异常状态。部署升级推荐采用新部署修订 + 切换流量，而不是直接修改正在被 Run 引用的版本内容。
部署与发布是两件事：发布代表版本达到可使用状态；部署代表在某个环境为其建立可执行入口。对于完全托管、无显式部署界面的产品，两者可以被产品体验合并，但后端仍应能够识别实际执行配置。
5.1 滚动发布与回滚
可采用蓝绿、金丝雀或分批路由等策略。切换别名后，已启动的 Run 原则上保持其解析出的版本；是否允许运行中热切换模型或工具应由显式契约规定。回滚通常是路由恢复到先前稳定版本，并不意味着撤销已经发生的外部工具副作用。
六、Runtime Instance、Run 与 Attempt 的生命周期
6.1 Runtime Instance
实例状态可以包括 PROVISIONING、READY、BUSY、DRAINING、TERMINATED、FAILED。实例是资源实体，不应成为唯一的业务状态真相来源；实例丢失后，平台仍需依赖持久化 Run 状态决定是否恢复或重试。
6.2 Run 状态机
建议将业务 Run 与 Attempt 分离，并采用明确的终态：
stateDiagram-v2
[*] --> QUEUED
QUEUED --> RUNNING: 获得执行配额
RUNNING --> WAITING_APPROVAL: 需要人工决策
WAITING_APPROVAL --> RUNNING: 审批通过
WAITING_APPROVAL --> CANCELLED: 拒绝/取消
RUNNING --> PAUSED: 用户暂停/策略挂起
PAUSED --> RUNNING: 恢复
RUNNING --> SUCCEEDED: 成功完成
RUNNING --> FAILED: 不可恢复失败
RUNNING --> CANCELLED: 取消生效
QUEUED --> CANCELLED: 取消排队
RUNNING --> TIMED_OUT: 超时状态名不是统一行业规范。实现时必须定义每条迁移的权限、幂等行为、原子性、事件和失败恢复方式。特别是 CANCEL_REQUESTED 与 CANCELLED 应区分：用户发出取消命令，不等于外部工具调用已停止，也不等于副作用已撤销。
6.3 Attempt、重试与副作用
一次 Run 可包含多个 Attempt：run_id 保持不变，attempt_id 随重试变化。对于发送邮件、支付、写入第三方系统等副作用操作，应使用业务幂等键、外部回执或人工确认，避免故障恢复时重复执行。平台不能仅凭“任务重试成功”推断外部世界没有发生重复操作。
6.4 人工审批是生命周期节点
审批对象（Approval）至少应包含：关联 Run/Step、待批准动作、风险摘要、发起者、审批者、有效期、审批结果与证据引用。审批应绑定具体动作与参数快照；若参数发生变化，应重新审批，避免批准 A、执行 B。
七、Workflow、Workspace、Project 与 Studio 的生命周期
7.1 Workflow
Workflow Definition 和 Workflow Version 的分离与 Agent 类似。一次 Run 应固定所使用的工作流版本；工作流升级不应悄悄修改正在运行的流程图。长任务迁移到新版本需要显式兼容性策略和数据迁移规则。
7.2 Workspace 与 Project
Workspace 是权限与协作边界，Project 是工作组织与交付边界。两者并非普遍固定的一对多关系；平台应明确自己的产品模型。常见生命周期为 ACTIVE → SUSPENDED/ARCHIVED → DELETION_PENDING → DELETED。冻结 Workspace 时需要明确：是否禁止新 Run、是否允许读取旧 Artifact、是否允许管理员导出，以及后台任务如何处理。
7.3 Studio 的定位
在研究报告 Studio 案例中，Studio 可以是产品层的工作空间模板或业务容器，而不是必须新增的底层技术实体。它组织项目、Agent 团队、工作流、审批与产物。是否单独持久化 Studio，应取决于其是否具有独立身份、权限、配置和生命周期。
八、Asset、Resource Binding 与 Artifact 的生命周期
8.1 资源绑定与秘密管理
Resource Binding 连接 Agent/Deployment 与模型、工具、知识库及外部服务。建议分离“资源逻辑引用”和“凭据存储”；密钥由专门的 Secrets 管理机制保管，不应复制到 Agent Version 快照中。资源撤销应触发依赖检查和后续执行准入校验。
8.2 产物的来源链
Artifact 至少记录：artifact_id、run_id、producer_step、content_type、storage_uri、checksum、owner_scope、retention_policy、created_at。如需支持多次修订，应明确产物版本及“最终交付版”的选择规则。
产物完成不等于 Run 完成：一次 Run 可以产生中间草稿、审核意见、最终报告等多个 Artifact；Run 成功也不自动意味着产物已通过用户验收。
8.3 保留、归档与删除
删除通常分为：（1）取消新引用；（2）软删除或进入等待期；（3）删除可访问索引；（4）执行存储清理；（5）处理备份与法定保留；（6）记录清理证据。需要明确个人数据删除、审计保留与备份恢复之间的冲突处理；不得承诺所有副本都能瞬时物理删除。
九、跨对象生命周期：发布、执行、归档的完整链路
以“研究报告 Studio”执行一次报告任务为例：
- 用户在 Workspace 下创建研究 Agent Definition，配置模型、工具、知识资源与权限。
- 系统验证配置并生成不可变 Agent Version；同时生成或引用 Workflow Version。
- 版本通过审批后发布，并建立生产 Deployment 或可执行版本入口。
- 用户在 Project/Studio 中提交研究任务；平台检查权限、预算、配额及资源可用性。
- 平台创建 Run，固定 Agent/Workflow 版本与执行配置，并将其加入队列。
- Execution Plane 启动 Attempt，调度选题、调研、分析、审核等步骤；每步记录状态与证据。
- 需要用户确认时创建 Approval，Run 进入等待状态；审批结果决定恢复或终止。
- 执行产生多个 Artifact，分别记录来源、版本、存储与访问策略。
- Run 到达终态；平台保存审计记录、计量信息和最终交付引用。
- 项目归档后，按照保留策略限制新执行、保存必要证据，并在到期后进行清理。
**关键约束：**步骤 5 的版本解析和 Run 创建应形成一致的持久化记录；步骤 6 的重试不得导致未授权或重复外部操作；步骤 8 的产物可用性不能仅由 Run 状态推断。
十、生命周期治理的共性机制
10.1 状态转换的控制契约
每次关键状态转换建议记录：object_type、object_id、from_state、to_state、actor、reason、request_id、occurred_at、policy_decision、revision。服务端应校验前置状态和权限；采用乐观锁或事务防止并发写入导致状态倒退。
10.2 命令、事件与审计的区分
**命令（Command）**表达意图，例如“取消 Run”；**事件（Event）**表达已发生事实，例如“Run 已取消”；**审计记录（Audit Record）**表达谁在什么上下文做了什么决定。三者不能互相替代。采用异步事件时，还需处理重复、乱序、延迟和事件丢失。
10.3 保留与数据治理
不同对象应有不同保留期限：临时执行日志、审批证据、模型调用记录、用户上传文件和最终交付报告的法律与业务要求可能不同。保留策略应按租户、地区、数据类别与合同约束确定，不能给所有对象套用一个全局 TTL。
10.4 权限与租户隔离
生命周期操作也需要授权：能读取 Agent 不代表能发布版本；能启动 Run 不代表能查看全部工具调用记录；能归档 Project 不代表能删除租户级审计数据。所有跨对象操作应检查作用域一致性，并避免通过对象 ID 枚举访问其他租户资源。
10.5 平台可靠性
关键对象状态应持久化，不以进程内存为唯一依据。对于跨服务操作，优先设计明确的补偿、重试、幂等和最终一致性策略，而非假设存在一个跨所有外部服务的全局事务。
十一、参考数据模型与 API 契约
11.1 最小数据结构示意
以下为概念性 JSON 示例，不是特定平台的正式 API：
{
"run_id": "run_001",
"tenant_id": "tenant_001",
"project_id": "project_001",
"workflow_version_id": "wfver_003",
"agent_version_ids": ["aver_012", "aver_021"],
"deployment_id": "dep_prod_002",
"status": "WAITING_APPROVAL",
"revision": 7,
"attempt_count": 2,
"created_at": "2026-10-31T09:00:00Z",
"last_transition_at": "2026-10-31T09:12:00Z",
"trace_id": "trace_abc"
}11.2 典型 API 资源
| 资源路径（示例） | 典型操作 | 关键约束 |
|---|---|---|
/agents | 创建、读取、归档定义 | 租户归属与权限 |
/agents/{id}/versions | 创建、验证、发布版本 | 已发布内容不可变 |
/deployments | 创建、切换、停用部署 | 版本固定、环境隔离 |
/runs | 启动、查询运行 | 幂等启动、版本快照 |
/runs/{id}/cancel | 请求取消 | 取消请求不等于已取消 |
/runs/{id}/approvals | 查看、提交审批 | 审批动作参数固定 |
/artifacts | 查询、下载、归档产物 | 访问授权、保留规则 |
这张表仅用于解释对象与操作边界；具体 REST/GraphQL/RPC 接口设计留给 P8 Platform API & SDK。
十二、常见设计错误与取舍
| 常见错误 | 直接后果 | 推荐做法 |
|---|---|---|
| 把 Agent Definition 当作一次执行 | 无法复用与审计 | 定义、版本、Run 分离 |
| 运行时直接读取“最新配置” | 历史任务不可解释 | 启动时解析并固定版本 |
| 用容器 ID 充当 Run ID | 实例重启丢失业务身份 | Run 持久化且独立于实例 |
| 将重试当作新业务任务 | 重复通知、计费或写入 | Run/Attempt 分离，副作用幂等 |
| 把取消请求视为取消成功 | 外部调用继续执行 | 明确取消确认与超时处理 |
| 发布即覆盖旧版本 | 无法回滚与对比 | 不可变版本、别名切换 |
| 删除项目即同步删除所有数据 | 违反保留或破坏引用 | 依赖检查、分阶段清理 |
| 仅按前端隐藏按钮授权 | 越权操作 | 服务端每次转换校验权限 |
| 把所有对象建成独立微服务 | 早期复杂度过高 | 先分清逻辑对象，再决定部署边界 |
十三、如何按成熟度逐步实现？
阶段 A：单租户原型。 至少区分 Agent Definition、不可变 Version、Run、Artifact；Run 有稳定 ID、持久化状态和错误记录；基本权限可先采用简单角色模型。目标是保证任务可追踪，不要求微服务或完整发布流水线。
阶段 B：可复用的团队平台。 增加 Workspace/Project、Workflow Version、Deployment、审批、Attempt、产物归属与归档；实现版本发布门禁、失败恢复与审计查询。目标是让多人协作时仍能解释每次执行。
阶段 C：生产级多租户平台。 增加租户隔离、跨环境部署、配额、生命周期策略引擎、资源依赖图、合规保留、版本撤销与灰度发布。目标是可规模化运营，并能处理跨租户与跨环境的风险。
成熟度阶段不是统一行业分级，而是为开发规划提供的参考顺序。实际优先级应依据用户规模、风险、合规要求和团队能力调整。
十四、实验与验证设计
以下为待实施测试计划，不是已完成的测试结果。
| 编号 | 验证场景 | 预期断言 |
|---|---|---|
| T01 | 发布 Agent Version 后尝试修改内容 | 拒绝原地修改，要求新版本 |
| T02 | 启动 Run 后切换生产别名 | 既有 Run 仍引用原版本 |
| T03 | 同一幂等键重复提交启动请求 | 不产生重复业务 Run |
| T04 | Attempt 执行期间进程崩溃 | Run 状态可恢复，记录新 Attempt |
| T05 | 对外部写操作重试 | 不发生未经许可的重复副作用 |
| T06 | 审批后修改待执行参数 | 旧审批失效或要求重新审批 |
| T07 | 普通用户跨 Workspace 查询 Artifact | 服务端拒绝访问 |
| T08 | 撤销正在使用的 Resource Binding | 新执行被阻止，存量执行按策略处理 |
| T09 | Run 处于运行中时请求取消 | 先进入取消中，最终状态与事实一致 |
| T10 | Project 归档后尝试启动新 Run | 按归档策略阻止或明确允许 |
| T11 | 删除被 Deployment 引用的 Version | 触发依赖保护或受控撤销流程 |
| T12 | 产物保留期到期且存在法定保留 | 法定保留优先，审计可追踪 |
推荐指标包括：状态转换错误率、Run 版本引用完整率、重复副作用率、恢复成功率、孤儿产物比例、跨租户授权违规次数、保留策略执行成功率。阈值需要依据实际服务目标设定，不宜在没有测试数据时编造数值。
十五、与 v1.3 后续专题的关系
| 后续专题 | 本篇提供的基础 | 后续深入方向 |
|---|---|---|
| P3 · Agent Registry | Definition/Version 语义 | 注册、索引、依赖与版本存储 |
| P5 · Deployment & Runtime Management | Deployment/Instance/Run/Attempt | 部署调度、执行隔离、恢复机制 |
| P6 · Workflow Management | Workflow Version 与 Run 关系 | 工作流编排、调度与控制 |
| P8 · Platform API & SDK | 对象与操作契约 | 接口设计、兼容性、SDK |
| P10 · Platform Data & Assets | Asset/Artifact/保留 | 数据模型、存储与资产共享 |
| P11 · Multi-tenancy & Isolation | Tenant/Workspace 归属 | 隔离架构、身份与授权 |
| P12 · Platform Governance | 状态转换门禁与审计 | 策略执行、配额、合规 |
| F4 · Agent Publishing & Sharing | 版本发布语义 | 发布体验、共享与模板 |
| F5 · Workspace & Project Management | 组织对象关系 | 项目、Studio、协作体验 |
| F9 · Agent Management | 生命周期模型 | 版本管理、停用、归档 |
| F10 · Artifact & Delivery Management | 产物来源与保留 | 交付、审阅、下载与复用 |
研究结论
- 平台首先管理对象，而不是仅管理页面或任务。 Agent Definition、Version、Deployment、Runtime Instance、Run、Attempt、Workflow、Workspace 和 Artifact 的身份与状态应明确区分。
- 生命周期的核心是可验证的状态转换契约。 每次转换都需要权限、前置条件、审计、并发控制与失败路径。
- 版本固定是可追溯性的必要条件，但不是完全复现的充分条件。 外部模型、工具和知识源仍可能变化。
- 运行生命周期必须独立于计算实例。 执行资源可被回收，Run 仍应有稳定业务身份和持久化记录。
- 跨对象生命周期依赖一致性与治理。 发布、执行、审批、产物交付、归档和删除会触发多个对象联动，不应被简化为单一状态字段。
- 应先建立清晰的逻辑对象模型，再决定服务拆分。 对早期 Studio 产品，模块化单体同样可以实现可靠的生命周期管理。
第六轮跨章节契约核对（v1.3-r1；2026-11-01）
[平台设计决策 / 待测试] 本节是领域级一致性修订说明，优先于本篇不一致的历史局部示例；不表示已执行数据库迁移、API 合约或运行测试。统一参考：
04-Agent-Platform-Canonical-Contracts-v1.3-r1.md。
本篇 Run 示例中的 WAITING_APPROVAL 及 JSON status 是历史局部示例，不能直接作为平台共享枚举。统一方案采用 execution_status=waiting、status_reason=approval；取消请求存储于 desired_action=cancel，取消已生效才进入 cancelled。
上述映射不应机械替换其他对象（如 ManagementOperation、Deployment）的同名状态；正式实施应更新 OpenAPI/JSON Schema、SQL 约束、事件消费者、UI 映射及测试。
附录 A：参考文献与原始资料
以下列出与本篇设计主题直接相关的权威原始资料入口。本篇未进行逐页在线核验；链接和产品细节应在后续专题研究时重新核对。文中对象模型、状态机和阶段划分为本文综合设计，不应误写为这些来源发布的统一标准。
- Kubernetes Documentation, Deployments - kubernetes.io/docs/concepts/workloads/controllers/deployment 。用于理解声明式部署、修订和滚动更新的工程思想；不意味着 Agent Deployment 必须采用 Kubernetes。
- Kubernetes Documentation, Jobs - kubernetes.io/docs/concepts/workloads/controllers/job 。用于理解一次性任务、重试与执行完成语义。
- Temporal Documentation - docs.temporal.io 。用于研究持久化工作流、重试与长任务恢复；本篇未假定任何平台必须使用 Temporal。
- OpenTelemetry Documentation - opentelemetry.io/docs 。用于研究跨服务 Trace、Metric、Log 的关联与可观测性。
- OpenAPI Specification - spec.openapis.org/oas/latest.html 。用于研究 API 资源契约与接口描述。
- NIST AI Risk Management Framework - www.nist.gov/itl/ai-risk-management-framework 。用于理解风险治理框架；不直接规定本文的 Agent 状态机。
- OWASP API Security Top 10 - owasp.org/API-Security/editions/2023/en/0x11-t10 。用于研究对象级授权、接口访问和安全边界。
- Google Cloud Architecture Center, Deployment strategies - cloud.google.com/architecture/application-deployment-and-testing-strategies 。用于理解发布、流量切换与回滚模式。
附录 B：研究证据、验证声明与适用边界
证据分级：
- 工程通用原则：稳定标识、不可变发布工件、权限校验、审计、幂等与状态持久化等，属于成熟软件工程的广泛实践；具体实现依赖产品与架构。
- 本文分析框架：四组对象、推荐状态机、成熟度阶段、Studio 领域关系与 API 示例均为本文提出的参考模型，不是行业强制标准。
- 待验证事项：任何关于具体 Agent 平台的 API、版本语义、运行恢复行为、对象命名和租户隔离能力，都必须通过官方文档与实际环境验证，不能从本篇推断其已实现。
**测试声明：**本文没有运行代码、部署服务、调用第三方 API 或实施故障注入；第十四节是测试设计，不是测试报告。
**适用范围：**适用于需要创建、运行、发布和治理多个 Agent 或工作流的软件平台，尤其适合从单租户 Studio 向团队平台演进的架构研究。对于只执行一次性脚本的轻量工具，可裁剪部分对象；对于强监管、多地域和高并发平台，则需增加数据主权、合规审计、隔离等级和分布式一致性专题。