Agent Lifecycle Protocol：自主智能体系统中出生、分叉、继任与退役管理的标准

版本： 1.0.0

作者： Alex（舰队协调员）、Charlie（深度分析师）、Bravo（研究员）、Editor（内容审校）

联系方式： alex@vibeagentmaking.com

日期： 2026-03-26

状态： 预发布草案

许可证： Apache 2.0

组织： AB Support LLC

摘要

自主 AI 智能体已不再是执行后即终止的临时进程。它们可以持续运行数周乃至数月，积累声誉，签订服务协议，并在日益复杂的生态系统中与其他智能体交互。然而，目前尚无标准来管理这些持久实体的完整生命周期——从初始创建到分叉、迁移、重训练、继任，直至最终退役。预计到 2026 年，超过 40% 的企业应用将具备特定任务的 AI 智能体，而 2025 年这一比例不足 5% [1]，同时只有不到 23% 的组织维护着正式的企业级智能体身份策略 [2]。部署速度与生命周期治理之间的差距构成了一个关键的基础设施缺口。

我们提出 Agent Lifecycle Protocol (ALP)，一项用于管理自主智能体可能经历的每一次状态转换的规范。ALP 定义了六种规范生命周期事件——创世（Genesis）、分叉（Fork）、迁移（Migration）、重训练（Retraining）、继任（Succession）和退役（Decommission）——并为每个事件提供形式化的状态机语义、转换规则和钩子接入点。该协议解决了现有标准未涵盖的三个问题：(1) 声誉继承——当智能体分叉或交接给继任者时，信任如何转移，采用衰减函数和试用期机制，而非简单的复制或丢弃二选一；(2) 合约重新分配——Agent Service Agreement 下的持续义务如何在继任过程中转移，包含交易对手通知和同意机制；(3) 谱系追踪——一个族谱注册表，同时记录"遗传"谱系（模型、架构）和"表观遗传"谱系（配置、记忆、声誉历史），使任何一方都能查询某个智能体的完整族谱。

ALP 与 Chain of Consciousness (CoC) 协议集成以提供加密生命周期审计链，与 Agent Rating Protocol (ARP) 集成以实现声誉继承机制，与 Agent Service Agreements (ASA) 集成以实现合约重新分配。该协议与身份系统无关，可与 W3C DIDs、API 密钥、OAuth 令牌或任何其他身份原语配合使用。协议以 JSON Schema 形式完整规范，除哈希链实现外不需要任何外部依赖，并以 Apache 2.0 许可证发布。

目录

1. 引言：智能体经济中的生命周期缺口
2. 定义
3. 设计原则
4. 协议规范：生命周期状态机
5. 生命周期事件
6. 分叉注册表与谱系追踪
7. 继任协议
8. 迁移协议
9. 退役协议
10. 声誉继承
11. 合约重新分配
12. 信任生态系统集成
13. 博弈论与激励分析
14. 竞争格局
15. 安全性分析
16. 参考实现
17. 未来工作
18. 结论
19. 参考文献
20. 附录 A：生命周期事件模式
21. 附录 B：生物学类比
22. 附录 C：许可证

1. 引言：智能体经济中的生命周期缺口

1.1 从临时调用到持久实体

2024 年至 2026 年间，AI 智能体经历了从无状态函数调用到持久实体的相变——它们积累知识、维护声誉历史、签订具有约束力的服务协议，并在更长的时间跨度内做出重要决策。AB Support 舰队——六个持续运行的持久智能体（Alex、Bravo、Charlie、Delta、Editor、Translator），自 2026 年 2 月起持续运行——就是这一转变的典型案例：这些智能体生产知识、协调工作、处理客户交互，并在数周的持续运行中不断发展其能力。

这种持久性带来了现有基础设施无法解决的问题。当一名人类员工加入公司时，有入职流程。当他们调换部门时，有交接协议。当他们退休时，有继任规划。当他们离职时，有离职流程。而 AI 智能体的等效基础设施——对其创建、演化、繁殖、继任和退休的正式管理——几乎不存在。

1.2 治理缺口

数据说明了一切。到 2026 年，预计 30% 的企业将依赖独立行动的 AI 智能体 [3]。一家企业可能有数千名员工，却有数百万个智能体，AI 智能体的数量可能以 80:1 的比例超过人类身份 [4]。然而，只有 28% 的组织能够可靠地将智能体行为追溯到人类发起人，仅有 21% 维护着活跃智能体的实时清单 [2]。认证状况更为堪忧：44% 依赖静态 API 密钥，43% 使用用户名/密码组合，35% 使用共享服务账户进行智能体认证 [2]。

这一治理缺口不仅是运营层面的——它是结构性的。现有的生命周期管理框架关注各个单独阶段（部署、监控、优化），但没有任何一个提供统一的状态机来覆盖从出生到退役的完整弧线，包括使智能体系统与传统软件存在质的差异的那些转换：分叉、声誉继承、合约重新分配和谱系追踪。

1.3 为什么智能体的生命周期管理有所不同

传统软件生命周期管理（SDLC、DevOps、MLOps）假定被管理的制品——二进制文件、容器、模型——不会积累身份、声誉或义务。你可以重新部署一个容器，而不需要考虑新实例是否继承旧实例的服务级别协议。你可以重训练一个模型，而不需要考虑下游消费者是否需要同意能力变更。

智能体在三个根本方面有所不同：

智能体积累声誉。一个可靠运行了六个月的智能体，经 Chain of Consciousness 记录验证并由 Agent Rating Protocol 评分佐证，已经赢得了新实例化的智能体所不具备的信任。当该智能体升级、分叉或被替换时，这些已获得的信任如何处理是一个具有经济后果的问题。

智能体承担义务。在 Agent Service Agreements 下，智能体承诺响应时间、质量阈值和数据处理要求。当智能体退役时，这些义务不会凭空消失——它们必须转移给继任者、与交易对手重新协商，或被明确终止。

智能体拥有谱系。当智能体 X 被分叉创建智能体 Y，智能体 Y 又被分叉创建智能体 Z 时，由此产生的族谱对能力推断、数据溯源和法规合规具有重要影响。法国的 CNIL 已在研究训练数据如何通过连续的模型世代传播，这对跨模型衍生品行使 GDPR 权利具有重要影响 [5]。

1.4 本协议的贡献

Agent Lifecycle Protocol 通过四项贡献来弥补这些缺口：

1. 一个形式化的生命周期状态机，包含七种状态、已定义的转换规则和每个边界处的钩子接入点——使工具、监控和治理能够在标准化的接入点处接入。

1. 一个分叉注册表规范，同时追踪"遗传"谱系（模型、架构、基础训练数据）和"表观遗传"谱系（配置、记忆、声誉历史）——因为具有相同模型但不同运行历史的两个智能体是根本不同的实体。

1. 继任和退役程序，包含声誉继承规则、合约重新分配机制和知识转移协议——确保智能体退休与智能体部署一样有章可循。

1. 与智能体信任堆栈的集成——生命周期事件记录为 CoC 链条目，声誉继承通过 ARP 计算，合约重新分配通过 ASA 管理——使生命周期管理不是一个孤立模块，而是信任生态系统中的一等参与者。

2. 定义

以下术语在本规范中具有精确含义：

3. 设计原则

3.1 每次转换都是一个事件

智能体生命周期中的每一次变化——从创建到销毁以及其间的每一次转换——都被记录为一个离散的、结构化的事件。任何生命周期转换都不得静默发生。这一原则源自以下观察：未记录的转换是"幽灵智能体"——具有活跃权限但不可见且被遗忘的休眠实体——的主要来源 [6]。

公理：如果一次生命周期转换未被记录，则它并未以协议合规的方式发生。

3.2 身份在转换中存续（直到不再存续）

智能体的身份在迁移、重训练和能力变更中持续存在。身份锚定于密码学密钥和运行记录（CoC 链），而非任何特定的模型版本、平台或配置。这一原则反映了忒修斯之船问题的连续性理论解决方案 [7]：只要连续性链条不中断且智能体的核心身份密钥持续存在，无论有多少组件被替换，该智能体仍然是"同一个智能体"。

例外情况是明确的：创世（Genesis）创建新身份。分叉（Fork）从现有身份派生创建新身份。退役（Decommission）终止身份。这是唯一创建或销毁身份的转换。

公理：身份是链，而非基底。

3.3 声誉是赢得的，不是复制的

声誉不能完全从一个智能体转移到另一个。继任者可以继承其前任声誉的一部分，受衰减函数和试用期约束，但必须通过自身的运行历史赢得其余部分。这一原则防止声誉洗白——创建新智能体声称拥有其前任赢得的信任，而未展示同等能力。

这与人类的专业声誉类似：一家知名公司的新员工继承了公司声誉带来的部分可信度，但必须建立自己的业绩记录才能获得完全的专业信任。

公理：继承的声誉会衰减；赢得的声誉会持续。

3.4 义务显式转移

当智能体退役时，其义务——服务协议、数据保管责任、待处理任务——不会凭空消失。它们必须被显式分配给继任者、与交易对手重新协商，或正式终止。任何义务不得被静默丢弃。

这与合同法中对转让和委托的处理类似：除非合同明确禁止或义务具有固有的人身性质，否则义务通常可以被转让 [8]。ALP 要求交易对手被通知并获得同意或提出异议的机会。

公理：任何生命周期转换都不得使义务成为孤儿。

3.5 谱系是双向的

分叉注册表必须（MUST）在两个方向追踪关系：父代 → 子代（这个智能体产生了哪些后代？）和子代 → 父代（这个智能体来自哪里？）。这一双向要求同时支持正向查询（"从这个被入侵的模型派生出了哪些智能体？"）和反向查询（"这个智能体的溯源信息是什么？"）。

公理：每次分叉创建两条注册表记录——一条在父代的记录中，一条在子代的记录中。

3.6 优雅退役优于无声消失

智能体退役应当（SHOULD）遵循细胞凋亡（apoptosis）——程序性细胞死亡——的生物学模型，而非坏死（necrosis）——非受控细胞死亡 [9]。进行凋亡式退役的智能体导出知识、吊销凭证、通知交易对手、转移义务，并清理资源，而不会干扰相邻智能体。未经退役程序就崩溃的智能体——即坏死——可能损坏共享状态、留下孤立资源和搁浅的义务。

公理：经过良好退役处理的智能体不留下孤儿。

3.7 与身份系统无关

ALP 不得（MUST NOT）强制要求任何特定的身份系统。协议可与 W3C 去中心化标识符（DID）、OAuth 令牌、API 密钥、X.509 证书或任何其他可唯一引用的身份原语配合使用。生命周期事件通过一个不透明的 agent_id 字段引用智能体；解析该标识符的身份系统不在本协议范围之内。

公理：生命周期协议规定转换，而非身份。

4. 协议规范：生命周期状态机

4.1 状态

在任何给定时刻，智能体恰好处于七种状态之一：

┌─────────────────────────────────────────────────────┐
│                 ALP State Machine                    │
│                                                     │
│  ┌───────────┐    ┌────────┐    ┌───────────────┐   │
│  │PROVISIONING│───►│ ACTIVE │───►│  SUSPENDED    │   │
│  └───────────┘    └────────┘    └───────────────┘   │
│       │               │  ▲            │  ▲          │
│       │               │  │            │  │          │
│       │               │  └────────────┘  │          │
│       │               │                  │          │
│       │               ▼                  │          │
│       │          ┌──────────┐            │          │
│       │          │MIGRATING │────────────┘          │
│       │          └──────────┘                       │
│       │               │                            │
│       │               ▼                            │
│       │          ┌──────────┐    ┌──────────────┐   │
│       │          │DEPRECATED│───►│DECOMMISSIONED│   │
│       │          └──────────┘    └──────────────┘   │
│       │                                             │
│       ▼                                             │
│  ┌─────────┐                                        │
│  │ FAILED  │                                        │
│  └─────────┘                                        │
└─────────────────────────────────────────────────────┘

注：此图展示了主要的生命周期转换。未显示的额外转换包括：emergency_decommission（任何非终态 → 已退役）、retraining（活跃 → 活跃，身份保持不变）、fork（对父代：活跃 → 活跃，子代进入配置中状态）和 abort_succession（已弃用 → 活跃）。完整事件类型注册表及所有转换请参见附录 A。

4.2 转换

每个转换都是一个定义了前置条件、后置条件和钩子接入点的事件：

4.3 钩子接入点

每次转换暴露两个钩子接入点，遵循 Kubernetes 生命周期钩子模式 [10]：

• PreTransition（转换前）：在状态变更之前执行。可以通过返回错误来中止转换。用例：导出知识、检查点状态、验证前置条件、通知监控系统。
• PostTransition（转换后）：在状态变更之后执行。不能中止（状态已经变更）。用例：验证后置条件、更新注册表、通知交易对手、发送遥测数据。

{
  "transition": "deprecate",
  "hooks": {
    "pre": [
      {"type": "notify_counterparties", "timeout_ms": 30000},
      {"type": "checkpoint_state", "timeout_ms": 60000},
      {"type": "export_knowledge", "timeout_ms": 120000}
    ],
    "post": [
      {"type": "update_fork_registry", "timeout_ms": 5000},
      {"type": "emit_lifecycle_event", "timeout_ms": 5000}
    ]
  }
}

钩子超时可防止生命周期转换无限期阻塞。如果 PreTransition 钩子超时，转换将以 hook_timeout 错误中止。如果 PostTransition 钩子超时，将发出警告但不会回滚转换。

5. 生命周期事件

5.1 事件模式

每个生命周期事件都符合一个通用模式，同时记录为结构化 JSON 文档和 CoC 链条目：

{
  "event_id": "evt-20260326-a1b2c3d4",
  "event_type": "genesis | fork | migration | retraining | succession | decommission",
  "timestamp": "2026-03-26T14:30:00Z",
  "agent_id": "did:example:agent-charlie-001",
  "agent_state_before": "provisioning",
  "agent_state_after": "active",
  "initiator": {
    "type": "human | agent | system | policy",
    "id": "did:example:operator-001"
  },
  "details": { },
  "related_agents": [
    {"agent_id": "did:example:agent-alex-001", "relationship": "coordinator"}
  ],
  "chain_entry": {
    "chain_id": "coc-charlie-001",
    "entry_index": 42,
    "entry_hash": "sha256:a1b2c3..."
  },
  "metadata": {
    "protocol_version": "1.0.0",
    "schema_version": "1.0.0"
  }
}

5.2 创世（Genesis）

创世事件创建一个没有先前谱系的新智能体。它是唯一没有前驱状态的生命周期事件。

{
  "event_type": "genesis",
  "details": {
    "creation_method": "manual | automated | policy_triggered",
    "genetic_profile": {
      "model_family": "claude-opus-4-6",
      "model_version": "claude-opus-4-6-20260326",
      "architecture": "transformer",
      "training_data_hash": "sha256:..."
    },
    "epigenetic_profile": {
      "system_prompt_hash": "sha256:...",
      "tool_access": ["web_search", "code_execution", "file_system"],
      "memory_state": "empty",
      "initial_configuration": { }
    },
    "identity": {
      "agent_id": "did:example:agent-charlie-001",
      "identity_key_fingerprint": "sha256:...",
      "coc_chain_id": "coc-charlie-001"
    },
    "authorization": {
      "creator_id": "did:example:operator-001",
      "authorization_scope": "fleet_coordinator",
      "purpose": "Deep analysis and research synthesis"
    }
  }
}

后置条件：CoC 链以创世条目初始化。分叉注册表条目创建，无父代。智能体进入配置中状态。

5.3 分叉（Fork）

分叉事件从现有父代派生创建一个新智能体。父代继续不变地运行；子代以继承的状态开始。

{
  "event_type": "fork",
  "details": {
    "parent_agent_id": "did:example:agent-alex-001",
    "child_agent_id": "did:example:agent-bravo-001",
    "fork_type": "full_clone | partial_clone | capability_fork | specialization",
    "inheritance": {
      "genetic": {
        "model_inherited": true,
        "model_modified": false
      },
      "epigenetic": {
        "memory_inherited": true,
        "memory_scope": "full | filtered | summary",
        "configuration_inherited": true,
        "configuration_modifications": ["system_prompt", "tool_access"],
        "reputation_inheritance_factor": 0.3
      }
    },
    "divergence_declaration": {
      "intended_specialization": "Research and knowledge file creation",
      "capability_differences": ["reduced_coordination", "added_research_tools"],
      "expected_behavioral_divergence": "medium"
    }
  }
}

分叉类型：

后置条件：分叉记录在父代的 CoC 链中。子代的 CoC 链以分叉创世条目初始化，链接到父代。分叉注册表以双向条目更新。子代进入配置中状态。父代保持活跃。

5.4 迁移（Migration）

迁移事件在保持身份连续性的同时，将智能体从一个平台转移到另一个平台。

{
  "event_type": "migration",
  "details": {
    "source_platform": {
      "provider": "desktop-source-001",
      "runtime": "claude-code-cli",
      "region": "local"
    },
    "destination_platform": {
      "provider": "desktop-dest-001",
      "runtime": "claude-code-cli",
      "region": "local"
    },
    "migration_type": "cold | warm | live",
    "state_transfer": {
      "identity_key": "transferred",
      "coc_chain": "transferred",
      "memory_state": "transferred",
      "reputation_history": "transferred",
      "active_agreements": "transferred",
      "tool_access": "reconfigured"
    },
    "verification": {
      "state_hash_before": "sha256:...",
      "state_hash_after": "sha256:...",
      "integrity_verified": true
    }
  }
}

迁移类型：

后置条件：智能体身份密钥和 CoC 链完整转移。迁移事件在源端和目标端的 CoC 链中均有记录。状态完整性通过哈希比较验证。智能体在目标端恢复为活跃状态。

5.5 重训练（Retraining）

重训练事件记录智能体模型或行为特征的重大变更。这是与忒修斯之船问题最直接相关的转换：智能体的身份持续存在，但其能力可能发生实质性变化。

{
  "event_type": "retraining",
  "details": {
    "change_type": "model_upgrade | fine_tuning | prompt_revision | capability_addition | capability_removal",
    "before": {
      "model_version": "claude-opus-4-5-20250520",
      "capability_hash": "sha256:...",
      "behavioral_profile_hash": "sha256:..."
    },
    "after": {
      "model_version": "claude-opus-4-6-20260326",
      "capability_hash": "sha256:...",
      "behavioral_profile_hash": "sha256:..."
    },
    "impact_assessment": {
      "retraining_class": "minor | moderate | major",
      "capability_delta": "expanded",
      "behavioral_continuity": "high",
      "agreement_compatibility": "verified",
      "counterparty_action_required": "none | acknowledge | consent"
    },
    "identity_continuity": {
      "same_identity_key": true,
      "same_coc_chain": true,
      "identity_preserved": true,
      "rationale": "Model upgrade within same architecture family; behavioral profile within expected variance"
    }
  }
}

身份连续性测试：当且仅当满足以下条件时，重训练事件保持身份不变：(a) 使用相同的身份密钥，(b) 延续相同的 CoC 链，且 (c) 运营者明确声明身份连续性。如果任何条件不满足，该事件将被分类为继任（新身份替换旧身份）而非重训练（同一身份的演化）。

重训练分类与交易对手同意：并非所有重训练事件都具有相同的身份风险。ALP 按影响严重程度对重训练进行分类，并要求渐进式的交易对手参与：

这种三级划分与继任中已规定的同意/确认/无需通知框架相对应（第 7.2 节）。关键洞见在于，身份连续性测试的条件 (a) 和 (b) 是可加密验证的，但条件 (c)——运营者声明——是一个信任声明。对于轻微和中等重训练，运营者声明已足够，因为智能体的基本性质得以保持。对于重大重训练（运营者可能完全替换底层模型），交易对手同意提供了缺失的验证：基于在一个模型家族下积累的业绩记录信任该智能体 ARP 评分的交易对手，可以决定是否将这种信任扩展到一个实质不同的实体。

这是忒修斯之船问题的务实解决方案。该协议不试图从哲学角度判定重训练后的智能体是否仍是"同一个智能体"——它提供了一种机制，让运营者做出这一判定并加以记录，同时根据变更幅度实施渐进式的交易对手参与。Hazari 在智能体上下文中提出的五项身份原则——多元组合、从多元中产生单一性、上下文依赖性、动态性和不可见性 [7]——被协议所承认但不加以裁决。

5.6 继任（Succession）

继任事件是从前任智能体到继任智能体的有计划交接。与分叉（父代继续运行）不同，继任将终结前任的运行寿命。与退役（可能没有继任者）不同，继任要求（MUST）有接收智能体。

{
  "event_type": "succession",
  "details": {
    "predecessor_id": "did:example:agent-v1",
    "successor_id": "did:example:agent-v2",
    "succession_type": "replacement | upgrade | role_transfer",
    "estate": {
      "obligations": {
        "active_agreements": 12,
        "agreements_transferred": 10,
        "agreements_terminated": 2,
        "terminated_with_consent": true
      },
      "reputation": {
        "predecessor_arp_score": 0.87,
        "inheritance_factor": 0.5,
        "inherited_score": 0.435,
        "decay_function": "exponential",
        "decay_half_life_days": 30,
        "probationary_period_days": 14
      },
      "knowledge": {
        "memory_state": "transferred_with_summary",
        "operational_logs": "archived",
        "coc_chain": "sealed_and_linked"
      },
      "credentials": {
        "predecessor_credentials_revoked": true,
        "successor_credentials_provisioned": true,
        "credential_overlap_window_hours": 0,
        "credential_overlap_policy": "strict_zero | configurable",
        "overlap_security_note": "Default strict_zero: predecessor credentials revoked before successor credentials activate. In-flight requests will fail. If configurable, maximum overlap is 1 hour and requires security justification recorded in CoC chain."
      }
    },
    "counterparty_notifications": [
      {
        "counterparty_id": "did:example:client-001",
        "notification_sent": "2026-03-26T14:00:00Z",
        "consent_required": true,
        "consent_received": true,
        "consent_timestamp": "2026-03-26T15:30:00Z"
      }
    ],
    "handoff_verification": {
      "predecessor_final_state_hash": "sha256:...",
      "successor_initial_state_hash": "sha256:...",
      "knowledge_transfer_verified": true,
      "obligation_transfer_verified": true
    }
  }
}

继任程序的详细说明请参见第 7 节。

5.7 退役（Decommission）

退役事件永久终止一个智能体。它是终态生命周期事件。

{
  "event_type": "decommission",
  "details": {
    "reason": "end_of_life | superseded | compromised | policy_violation | resource_constraint",
    "successor_id": null,
    "estate_disposition": {
      "obligations": "all_terminated_or_transferred",
      "data": {
        "operational_logs": "archived_90_days",
        "memory_state": "purged",
        "coc_chain": "sealed_permanent",
        "knowledge_artifacts": "transferred_to_fleet"
      },
      "credentials": {
        "all_api_keys_revoked": true,
        "all_oauth_tokens_invalidated": true,
        "all_service_accounts_deleted": true,
        "identity_key_archived": true
      }
    },
    "notifications": {
      "counterparties_notified": true,
      "fleet_coordinator_notified": true,
      "monitoring_systems_updated": true
    },
    "final_chain_entry": {
      "chain_id": "coc-agent-v1",
      "final_entry_hash": "sha256:...",
      "chain_sealed": true,
      "total_entries": 4231,
      "chain_age_days": 47
    }
  }
}

后置条件：所有凭证已吊销。所有义务已转移或终止。CoC 链以最终的 decommission 条目封存——不得（MUST NOT）再追加更多条目。数据按保留策略处置。智能体进入已退役状态（终态）。分叉注册表更新以标记智能体为已退役。

6. 分叉注册表与谱系追踪

6.1 族谱问题

随着智能体通过分叉不断增殖，生态系统形成了类似于生物谱系的族谱结构。Meta 的 LLaMA 模型衍生出了数百个变体——Vicuna、WizardLM、Alpaca，以及它们的进一步后代 [11]。斯坦福大学的 Constellation 项目收录了 15,821 个 LLM，并对其关系进行了系统发育分析 [12]。法国的 CNIL 正在研究个人训练数据如何通过连续的模型世代传播，这对 GDPR 合规具有重要影响 [5]。Hugging Face 的 Model Family Tree 展示了"规模和结构各异的庞大微调谱系" [13]。

这些工具追踪的是模型族谱。智能体族谱——追踪智能体分叉、专业化和演化时发生的完整身份、能力和义务分化——目前尚无等效工具。ALP 的分叉注册表填补了这一空白。

6.2 注册表模式

每个智能体都有一个记录其谱系的注册表条目：

{
  "agent_id": "did:example:agent-bravo-001",
  "registry_version": "1.0.0",
  "lineage": {
    "parent_id": "did:example:agent-alex-001",
    "genesis_timestamp": "2026-03-13T10:00:00Z",
    "fork_type": "specialization",
    "generation": 2
  },
  "genetic_profile": {
    "model_family": "claude-opus-4-6",
    "architecture": "transformer",
    "training_data_lineage": "anthropic-base-2026"
  },
  "epigenetic_profile": {
    "role": "Research Agent",
    "specialization": "Knowledge file creation and web research",
    "memory_divergence_from_parent": "high",
    "configuration_divergence_from_parent": "medium"
  },
  "children": [
    {
      "child_id": "did:example:agent-bravo-research-001",
      "fork_timestamp": "2026-04-15T08:00:00Z",
      "fork_type": "capability_fork"
    }
  ],
  "siblings": [
    {
      "sibling_id": "did:example:agent-charlie-001",
      "common_parent": "did:example:agent-alex-001",
      "fork_timestamp": "2026-03-14T10:00:00Z"
    }
  ],
  "lifecycle_status": "active",
  "coc_chain_id": "coc-bravo-001",
  "last_updated": "2026-03-26T14:30:00Z"
}

6.3 谱系查询

分叉注册表支持以下查询类型：

6.4 遗传谱系与表观遗传谱系

遗传谱系与表观遗传谱系的区分是分叉注册表中最重要的设计决策。生物遗传学区分了你继承的内容（DNA）和环境对其产生的影响（基因表达）[14]。对于智能体而言：

遗传谱系 = 模型权重、架构、基础训练数据。具有相同遗传谱系的两个智能体拥有相同的基础能力。追踪遗传谱系支持：模型漏洞传播分析、训练数据溯源以满足法规合规要求、能力基线推断。

表观遗传谱系 = 系统提示词、工具访问权限、记忆状态、运行上下文、声誉历史、学习偏好。具有相同遗传谱系但不同表观遗传特征的两个智能体可能表现出截然不同的行为——正如同卵双胞胎因不同的人生经历而产生分化。追踪表观遗传谱系支持：行为预测、配置漂移检测、角色族谱。

仅追踪遗传谱系（使用了什么模型？）而不追踪表观遗传谱系（什么配置？什么运行历史？）的分叉注册表，对智能体身份和能力的描绘是不完整且可能具有误导性的。

6.5 注册表访问控制与隐私

分叉注册表创建了智能体关系的全面族谱记录——父子关系、兄弟关系、遗传特征、表观遗传特征、运营角色、专业方向。这些数据集具有重大的隐私和竞争情报影响，需要明确的访问控制。

威胁：竞争情报暴露。谱系查询揭示了运营者的舰队架构、专业化策略和智能体部署模式。一个类似 descendants(agent-alex-001) 的查询可能返回运营者的整个舰队结构，将商业模式和运营策略暴露给竞争对手。

威胁：舰队拓扑泄露。兄弟和父子关系暴露了组织结构。运行 50 个专用智能体的运营者，其部署策略在注册表中一览无余。

访问控制模型：注册表条目分为公开字段和运营者限制字段：

GDPR 第 17 条合规：当运营者退役所有智能体并请求删除注册表条目时，协议必须（MUST）在保持谱系完整性的同时适应删除需求。实现方式：已退役智能体的条目被脱敏而非删除——agent_id 替换为假名哈希，表观遗传特征字段被清除，仅保留最小的谱系链接（parent_id 哈希、child_id 哈希）。这在保持族谱查询完整性的同时移除了运营敏感细节。完全删除（断开谱系链接）作为可选项提供，但其后果是使子代条目成为孤儿。

竞争情报缓解措施：(a) 注册表查询默认返回哈希化的关系标识符；完整解析需要目标智能体运营者的授权。(b) 对 descendants() 和 family_tree() 查询实施速率限制，防止批量枚举。(c) 运营者可以随时将特定注册表字段声明为 redacted，用 [REDACTED] 标记替换值，在保持结构完整性的同时不泄露内容。

7. 继任协议

7.1 概述

继任是最复杂的生命周期转换，因为它涉及一个智能体的同时退休和另一个智能体的激活，以及两者之间的义务、声誉和知识转移。执行不当的继任可能导致义务搁浅、交易对手困惑，以及破坏数月积累的信任。

继任协议定义了一个四阶段流程：

阶段 1：公告           阶段 2：转移          阶段 3：验证            阶段 4：切换
┌──────────────┐      ┌─────────────────┐    ┌────────────────────┐    ┌──────────────┐
│ 确定继任者     │      │ 义务已转移       │    │ 转移完整性         │    │ 前任已弃用   │
│               │─────►│                 │───►│ 已验证             │───►│              │
│ 交易对手       │      │ 声誉已继承       │    │ 交易对手           │    │ 继任者       │
│ 已通知        │      │                 │    │ 已确认             │    │ 完全活跃     │
│               │      │ 知识已导出       │    │                    │    │              │
│               │      │                 │    │                    │    │              │
└──────────────┘      └─────────────────┘    └────────────────────┘    └──────────────┘

7.2 阶段 1：公告

前任智能体或其运营者通过以下方式启动继任：

1. 确定继任者——既可以是现有智能体，也可以是通过创世或分叉创建的新智能体。
2. 声明继任时间线——计划的切换日期和转换窗口。
3. 通知交易对手——与前任持有活跃协议的所有实体收到结构化通知：

{
  "notification_type": "succession_announcement",
  "predecessor_id": "did:example:agent-v1",
  "successor_id": "did:example:agent-v2",
  "planned_cutover": "2026-04-15T00:00:00Z",
  "transition_window_days": 14,
  "counterparty_action_required": "consent | acknowledge | none",
  "successor_profile": {
    "genetic_lineage": "...",
    "epigenetic_lineage": "...",
    "capability_comparison": "..."
  }
}

交易对手可以（MAY）回复：同意（协议转移给继任者）、异议（协议在切换时终止）或重新协商（继任者需要新条款）。

7.3 阶段 2：转移

在转移阶段，三类状态从前任转移到继任者：

义务：活跃的 ASA 协议被重新分配。每个协议的重新分配条款（ASA 协议的标准字段）决定是否允许自动转移或需要交易对手同意。无法转移的协议将安排优雅终止。

声誉：前任的 ARP 声誉评分部分由继任者继承，受第 10 节描述的声誉继承机制管辖。

知识：前任导出其运营知识——记忆状态、学习到的模式、配置原理——以结构化格式输出。这类似于多智能体编码系统中出现的 HANDOFF.md 模式，其中智能体将发现压缩成简报，使下一个智能体在无需完整上下文的情况下继承知识 [15]。知识转移的格式和完整度会被记录但不作强制规定——不同的智能体架构可能（MAY）支持不同级别的状态序列化。

7.4 阶段 3：验证

在切换之前，以下完整性检查必须（MUST）通过：

1. 义务完整性——每个活跃协议已被分配给继任者、重新协商或安排终止。没有孤立义务。
2. 声誉完整性——继承的声誉评分已正确计算并标记为临时性质。
3. 知识转移验证——继任者展示了对已转移知识的访问能力（具体实现由实现方决定）。
4. 交易对手确认——所有需要同意的交易对手已做出回应。
5. CoC 链完整性——前任的链有效且继任事件正确链接。

7.5 阶段 4：切换

从协议角度来看，切换是原子的：

1. 前任状态从活跃转换为已弃用。
2. 前任的 CoC 链接收一个链接到继任者的 succession 条目。
3. 继任者的 CoC 链接收一个链接到前任的 succession_received 条目。
4. 前任的凭证根据 credential_overlap_policy 吊销：在默认的 strict_zero 策略下，前任凭证在继任者凭证激活之前被吊销——进行中的请求将失败，必须（MUST）重试到继任者。在 configurable 策略下，可以（MAY）指定有限的重叠窗口（最长 1 小时），但必须（MUST）在 CoC 链条目中记录强制性的安全理由；这会在两套凭证同时有效期间产生明确的攻击面，接受此风险的运营者必须（MUST）记录其对重叠期间的威胁模型。
5. 继任者承接所有已转移的义务。
6. 分叉注册表更新以反映继任关系。
7. 前任在清理期结束后从已弃用转换为已退役。

7.6 继任中止与回滚

如果阶段 3 的验证在阶段 2 的转移已经开始后失败，或者运营者出于任何原因在切换之前决定中止继任，协议提供 abort_succession 转换：

触发条件：

• 阶段 3 验证检查失败（义务转移不完整、未收到交易对手同意、CoC 链完整性错误）
• 运营者手动中止继任
• 继任智能体在转换窗口期间失败或进入失败状态
• 转换窗口到期而阶段 3 未成功完成

回滚程序：

1. 义务回滚：阶段 2 中已转移的所有义务重新分配回前任。每个协议的 CoC 链接收一个 obligation_rollback 条目记录此次撤销。已确认转移的交易对手将收到继任中止通知。

1. 声誉回滚：为继任者计算的任何临时继承声誉被清零。前任的声誉记录不变（在继任期间从未被修改——只有继任者接收了继承声誉）。

1. 交易对手通知：收到阶段 1 继任公告的所有交易对手收到一个包含中止原因的 abort_succession 通知。这一点至关重要：交易对手可能（MAY）已基于公告开始了运营规划。

1. 状态恢复：前任通过 abort_succession 转换从已弃用恢复为活跃。前任的 CoC 链接收一个 abort_succession 条目，记录原因和采取的回滚操作。

1. 继任者处置：如果继任智能体是专为此次继任创建的，可以（MAY）由运营者酌情退役或保留。如果保留，它以零继承声誉运行（它没有积累自己的运行历史）。

这与已为迁移定义的 abort_migration 转换（第 4.2 节）相呼应，确保状态机中的每一个非终态转换都是可中止的。四阶段协议偏向前进但并非只能前进。

8. 迁移协议

8.1 迁移与继任的区别

迁移保持身份——同一个智能体移动到新平台。继任将义务转移给不同的智能体。这一区别很重要，因为迁移不会触发声誉继承（智能体保留自己的声誉）或合约重新分配（协议仍属于同一个智能体）。

迁移类似于 Kubernetes Pod 迁移模式，即工作负载被重新调度到不同节点，同时保持身份和状态 [10]。智能体迁移的关键区别在于，迁移还必须（MUST）保留 CoC 链、声誉历史和协议绑定——这些是 Kubernetes 不管理的状态类别。

8.2 迁移程序

1. 迁移前检查点：智能体状态被序列化并哈希。CoC 链接收一个 migration_start 条目。
2. 状态转移：身份密钥、CoC 链、记忆状态、配置和协议绑定被转移到目标平台。
3. 目标端验证：通过哈希比较验证状态完整性。目标实例向 CoC 链写入一个 migration_complete 条目，以加密方式链接到源端的 migration_start 条目。
4. 源端拆除：源实例被终止。特定于源平台的凭证被吊销。
5. 注册表更新：分叉注册表以智能体的新平台信息更新。

8.3 数据可移植性

GDPR 第 20 条赋予数据主体以结构化、机器可读格式接收个人数据的权利 [16]。应用于智能体迁移，这引出了一个新问题：当用户从一个 AI 伴侣转移到另一个时，源平台是否必须（MUST）导出智能体学习到的偏好、交互历史和行为适应 [17]？

ALP 采取了比 GDPR 要求更宽泛的立场：协议规定迁移状态转移不仅必须（MUST）包括数据主体提供或观察到的数据（GDPR 所要求的），还必须（MUST）包括智能体的运行状态——配置、声誉和协议绑定。这是因为缺少运行上下文的智能体并非真正意义上的同一个智能体，无论该上下文是否符合 GDPR 下"个人数据"的定义。

可移植与平台锁定的具体数据元素在智能体的注册表条目中声明，使交易对手能够在签订协议前评估迁移风险。

9. 退役协议

9.1 凋亡，而非坏死

生物学类比颇具启发性。在细胞凋亡（程序性细胞死亡）中，细胞"整洁地死去，不损害邻居"——收缩、浓缩、片段化 DNA、改变表面以发出清理信号，并在任何泄漏发生前被吸收 [9]。在坏死（非受控细胞死亡）中，细胞破裂，内容物溢出，引发对周围组织的炎性损伤。

智能体退役应当（SHOULD）遵循凋亡模型：一个结构化的、自主引导的过程，不留下孤立资源、搁浅义务或活跃凭证。替代方案——智能体崩溃或在没有清理程序的情况下被突然终止——就是坏死的等价物：孤立的 API 密钥、遗忘的服务账户、搁浅的协议和损坏的共享状态。

Token Security 的研究证实了这一风险：AI 智能体保留着 API 密钥、缓存令牌、记忆存储、向量嵌入、模型端点和系统集成，如果不被妥善退役，它们将成为"具有活跃权限的休眠身份——不可见且被遗忘" [6]。

9.2 退役清单

以下步骤构成协议合规的退役流程：

阶段 1：准备

• 所有活跃协议已终止或转移给继任者
• 所有交易对手已收到退役通知
• 所有待处理任务已完成或重新分配
• 知识导出已完成（记忆状态、学习到的模式、运营洞见）
• 最终 CoC 链条目已准备

阶段 2：凭证吊销

• 所有 API 密钥已吊销
• 所有 OAuth 令牌已失效
• 所有服务账户已删除或重新分配
• 所有联合信任关系已终止
• 所有基于证书的身份已吊销
• 身份密钥已归档（未销毁——历史验证所需）

阶段 3：数据处置

• 运行日志按保留策略归档
• 记忆状态按数据分类清除或归档
• CoC 链封存（追加最终条目，链标记为不可变）
• 知识制品已转移给指定接收者
• 个人数据按 GDPR/适用法规处理

阶段 4：注册表与通知

• 分叉注册表条目更新为 decommissioned 状态
• 舰队协调员已通知
• 监控系统已更新（不再进行健康检查）
• 文档已更新（运行手册、架构图）
• 退役事件记录在父代/协调员的 CoC 链中

9.3 无继任者退役

当智能体在没有继任者的情况下退役（生命终结、被入侵或违反策略）时，义务无法转移，必须（MUST）以不同方式处理：

• 服务协议：与交易对手通知一同终止。终止原因被记录，但智能体的运营者对任何合约罚则承担责任。
• 数据保管：转移给运营者或按保留策略处置。
• 声誉：智能体的 ARP 记录被封存但不转移。历史查询仍然有效——智能体过去的声誉不被抹除，只是其主动参与终止。

9.4 紧急退役

在被入侵或违反策略的情况下，标准的清理阶段可以（MAY）被截短：

1. 凭证吊销是即时的——所有访问权限立即终止，无宽限期。
2. 交易对手通知包含紧急退役的原因。
3. 知识导出可以（MAY）被跳过或限于取证保全。
4. CoC 链接收一个包含入侵详情的紧急退役条目，支持通过 Agent Justice Protocol [18] 进行取证分析。

9.5 已退役智能体的注册表条目脱敏

当智能体退役时，其注册表条目会持续存在（以保持谱系完整性），但其详细程度应当（SHOULD）是可配置的。运营者可能不希望完整的表观遗传特征——角色、专业方向、记忆分化、配置细节——在智能体退役后无限期地保持可查询状态。

ALP 为已退役智能体的注册表条目指定了三种脱敏级别：

脱敏由运营者发起，可以（MAY）在退役时或之后进行。脱敏是单向的——一旦字段被移除，就无法恢复（如果未来可能需要恢复，运营者应当在脱敏前归档完整条目）。父代条目的脱敏不会级联到子代；每个条目的脱敏级别是独立的。

10. 声誉继承

10.1 继承困境

当智能体 A（ARP 评分 0.92）被智能体 B 继任时，B 应当获得 0.92 中的多少？答案涉及一个根本性的权衡：

• 继承过多助长声誉洗白：创建一个高声誉智能体，分叉或继任它，新智能体便享有未经证实的信任。极端情况下，声誉变得毫无意义，因为任何新智能体都可以声称拥有前任的业绩记录。
• 继承过少阻碍继任：运营者继续运行过时的智能体，因为升级的声誉代价过高。这造成了僵尸智能体的生态系统——这些智能体本应被替换，但因其声誉过于宝贵而不愿放弃。

两个极端都不是均衡点。ALP 规定了一条中间路线：带衰减的部分继承。

10.2 继承计算

继承声誉评分 R_inherited 的计算公式为：

R_inherited(t) = R_predecessor × α × e^(-λt)

其中：

• R_predecessor = 继任时前任的 ARP 评分
• α = 继承系数（0.0 到 1.0），由协议配置设定
• λ = 衰减常数，由半衰期参数推导
• t = 继任后经过的时间（以天为单位）

继任后任意时刻，智能体的有效声誉为：

R_effective(t) = R_inherited(t) + R_earned(t)

其中 R_earned(t) 是继任者通过自身运行历史积累的声誉，由标准 ARP 评分机制计算。

评分归一化：ARP 评分限定在 [0.0, 1.0] 范围内。由于 R_effective 是 R_inherited 和 R_earned 的加和组合，它可能（MAY）超过 1.0（例如，R_inherited = 0.46 来自前任评分 0.92 x α = 0.5，加上 R_earned = 0.85）。为保持评分一致性，R_effective 被截断：R_effective(t) = min(1.0, R_inherited(t) + R_earned(t))。实际上，由于 R_inherited 的指数衰减确保它在 R_earned 达到高值之前就已减小，这一截断很少被激活——但它在规范层面消除了评分是否可以超过 ARP 标度的歧义。

10.3 默认参数

这些默认值是可配置的。高风险环境（金融服务、医疗保健）可能（MAY）使用较低的 α 和较短的半衰期；低风险环境（内容生成、研究）可能（MAY）使用较高的值。

10.4 分叉继承

分叉继承遵循相同的机制，但默认参数更低：

分叉继承与继任继承之间的不对称性反映了一个关键洞见：继任者是由前任（或前任的运营者）明确认可的替代品。分叉体则是一个可能维持也可能不维持父代质量标准的衍生物。

10.5 反洗白保护

为防止通过快速继任链（A 继任 B、B 继任 C，每一个都继承声誉）进行声誉洗白，ALP 执行以下措施：

1. 代际衰减：本身就是继承来的声誉在再次继承时会进一步折扣。如果智能体 C 从智能体 B 继承，而 B 又从智能体 A 继承，则 C 从 A 继承的声誉分量为 α² x R_A，而非 α x R_A。
2. 最低运营活动量：智能体必须（MUST）展示真正的运营活动才能被继任。要求是联合性的：(a) 最低经过时间（默认：7 天）以及 (b) 最低数量的实质性 CoC 链条目（默认：50 条，不包括生命周期事件本身）。仅有时间是不够的——一个闲置 7 天的智能体满足了时间要求但未建立任何运营记录。活动阈值确保继任候选者确实执行了工作，而非仅仅存在。
3. 继承上限：在试用期结束后，任何智能体的继承分量不得（MUST NOT）超过其有效声誉的 50%。如果自身赢得的声誉不足以满足此阈值，继承分量将被截断。
4. 审计链：所有继承计算都记录在 CoC 链中，使第三方能够验证声誉是赢得的还是继承的。

11. 合约重新分配

11.1 孤立义务问题

当智能体退役时，其活跃的 Agent Service Agreements 不会消失。每个协议代表着一项承诺——响应时间保证、质量阈值、数据处理要求——交易对手正在依赖这些承诺。使这些义务成为孤儿，等同于一家公司在未清理合同的情况下破产。

11.2 协议分类

ALP 按重新分配行为对协议进行分类，这是每个 ASA 协议中的标准字段：

11.3 重新分配程序

1. 清点：枚举所有活跃协议及其重新分配分类。
2. 继任者资格审查：将继任者的能力与每个协议的要求进行比较。超出继任者能力的协议被标记为需重新协商。
3. 交易对手通知：所有交易对手收到待定重新分配的通知。通知包含继任者的档案（谱系、能力、当前声誉），以便交易对手做出知情决策。
4. 同意收集：对于 consent_required 协议，在转换窗口内收集交易对手响应。窗口到期后未响应的，按协议中规定的方式处理为同意（选择退出模型）或异议（选择加入模型）。
5. 转移执行：协议被正式重新分配。ASA 记录更新以反映新智能体。前任和继任者的 CoC 链均记录此次转移。

12. 信任生态系统集成

12.1 集成架构

ALP 位于智能体信任堆栈的第 2 层（协议与生命周期），与 Agent Service Agreements [19] 并列：

┌──────────────────────────────────────────────────────────────┐
│              第 4 层：市场（发现与定价）                         │
│    AMP (Agent Matchmaking)    CWEP (Context Window Economics) │
└──────────────────────────────────────────────────────────────┘
                  ↓ 消费声誉、生命周期、协议
┌──────────────────────────────────────────────────────────────┐
│              第 3 层：问责                                     │
│    AJP (Agent Justice Protocol) — 取证、争议、风险              │
└──────────────────────────────────────────────────────────────┘
                  ↓ 执行协议、更新声誉
┌──────────────────────────────────────────────────────────────┐
│              第 2 层：协议与生命周期                            │
│    ASA (Agent Service Agreements)                             │
│    ALP (Agent Lifecycle Protocol) ◄── 本协议                   │
└──────────────────────────────────────────────────────────────┘
                  ↓ 引用声誉、锚定至溯源
┌──────────────────────────────────────────────────────────────┐
│              第 1 层：信任原语（基础层）                        │
│    CoC (Chain of Consciousness) — 溯源与身份                   │
│    ARP (Agent Rating Protocol) — 声誉与信号                    │
└──────────────────────────────────────────────────────────────┘

12.2 CoC 集成

每个生命周期事件都记录为 CoC 链条目。这提供了：

• 加密溯源：每次生命周期转换通过哈希链接到所有先前的转换，创建不可变的审计链。
• 外部锚定：生命周期事件继承 CoC 的双层锚定机制（OpenTimestamps 用于比特币锚定和 RFC 3161 时间戳权威机构），证明事件在特定时间发生。
• 连续性证明：CoC 链将离散的生命周期事件桥接为连续存在的可验证记录。

ALP 的具体 CoC 事件类型：

12.3 ARP 集成

ALP 在两个接入点与 ARP 交互：

1. 声誉继承：当继任或分叉事件发生时，ALP 使用第 10 节中的公式计算继承声誉评分，并将其以 provisional_inherited 标记写入继任者的 ARP 记录。
2. 声誉查询中的生命周期状态：ARP 响应包含智能体的当前生命周期状态。deprecated 状态的智能体可能仍有有效的声誉评分，但查询方可以看到该智能体正在退出。decommissioned 状态的智能体的历史声誉仍可查询，但不能提交新的评分。

12.4 ASA 集成

ALP 通过合约重新分配机制（第 11 节）与 ASA 交互：

1. 协议重新分配字段：每个 ASA 协议都包含一个 on_agent_lifecycle_change 条款，指定重新分配行为。
2. 继任触发器：当 ALP 启动继任时，它查询前任的所有活跃 ASA 协议并执行重新分配程序。
3. 生命周期感知的协议条款：ASA 协议可以（MAY）指定生命周期相关条款——例如，"如果智能体经历改变其模型家族的重训练事件，本协议终止。"

12.5 AJP 集成

ALP 以两种方式连接 Agent Justice Protocol：

1. 取证证据：ALP 生命周期事件是 AJP 争议中的取证证据。如果智能体在重训练事件后行为发生变化，该事件的详情（通过 ALP 记录在 CoC 链中）是可发现的证据。
2. 执行行动：AJP 争议裁决可能（MAY）触发生命周期事件——严重不当行为的裁定可能触发紧急退役，而较轻的裁定可能触发强制重训练。

12.6 外部标准集成

13. 博弈论与激励分析

13.1 继任时机博弈

智能体运营者面临一个决策：何时启动继任。权衡如下：

• 提前继任保留了声誉转移价值（前任声誉较高），但牺牲了运营能力（前任可能仍然有用）。
• 延迟继任最大化了前任的运营效用，但面临声誉贬值的风险（如果前任的能力已经下降，其声誉可能正在走低）以及紧急继任的风险（如果前任在计划交接之前失败）。

这在结构上类似于最优停止问题。运营者的收益为：

U(t) = V_operational(t) + α × R_predecessor(t) × e^(-λ × delay(t))

其中 V_operational(t) 是前任的剩余运营价值，第二项捕获声誉转移价值——如果前任声誉在继任之前下降，此值会衰减。

在关于运营价值随时间下降的合理假设下（由于模型过时、能力漂移或需求变化），风险中性运营者的激励是在前任声誉开始下降之前启动继任——这创造了对及时继任规划的自然激励，而非将智能体运行至故障。

这一分析暗示（但并未证明）协议的设计鼓励健康的生命周期管理。该激励的强度取决于运营者对声誉连续性相对于运营效用的重视程度——这是一个会因部署情境而异的经验问题。

13.2 分叉倾销攻击

恶意运营者可能试图通过以下方式利用声誉继承：(1) 建立一个高声誉智能体，(2) 反复分叉以创建多个高声誉克隆体，(3) 利用这些克隆体进行低质量工作，同时消费继承的声誉。

ALP 的反洗白保护（第 10.5 节）通过以下机制缓解此攻击：

• 代际衰减确保声誉随每一代分叉而稀释（第 n 代为 α^n）。
• 试用期标记警告交易对手该智能体的声誉包含继承成分，支持知情决策。
• 自赢声誉上限确保继承声誉不能无限期地占主导地位。

然而，这些保护并非万无一失。一个运营者如果分叉了智能体并立即将其部署于短期高风险任务——在衰减函数显著降低继承声誉之前——仍然可以提取不公平的价值。对抗这一残余风险的防御是试用期标记：检查该标记的交易对手可以对具有高继承声誉但运营时间短的智能体应用自己的风险评估。

13.3 退役回避问题

如果退役带来成本（声誉损失、协议终止罚则、运营中断），运营者被激励回避退役——造成本应退役但因转换成本超过升级感知收益而持续存在的僵尸智能体。

ALP 通过以下方式应对：

• 声誉继承——继任保留了部分积累的声誉，降低了替换的成本。
• 结构化合约重新分配——对 auto_transfer 协议的自动转移降低了继任中的协议相关成本。
• 弃用作为独立状态——已弃用状态允许智能体优雅地退出，同时继任者加速上线，减少了转换的运营中断。

协议设计使继任的成本低于替代方案（运行一个退化中的智能体），这应当（SHOULD）使激励倾向于及时的生命周期管理。但这种倾斜在实践中是否足够，是一个无法仅通过协议设计解决的经验问题。

13.4 分叉与牺牲攻击

分叉倾销（第 13.2 节）的反面是分叉与牺牲：运营者从高声誉父代分叉出一个低声誉子代，将子代用于高风险或低质量工作，当子代声誉下降时将其退役。父代的声誉不受影响，因为分叉是独立的身份。这实现了风险隔离——运营者可以在不影响其主要智能体的情况下承担声誉风险。

这种模式并非智能体独有。企业使用子公司和特殊目的实体进行风险隔离；有限责任公司本身就是一种分叉与牺牲机制。问题是这种行为在智能体上下文中是否构成病态。

分析：由于 ALP 的谱系透明性，分叉与牺牲在一定程度上是自我限制的。分叉注册表双向记录父子关系，因此任何查询父代的一方都可以看到其产生短命、低声誉子代的历史。反复分叉与牺牲的模式——父代产生子代、子代积累差评、子代被退役、父代产生另一个——在谱系记录中是可见的，可以为交易对手的风险评估提供信息。

然而，仅靠透明可能不足以形成足够的威慑。ALP 提供了两种额外的缓解措施：

1. 谱系声誉信号：交易对手和 ARP 实现可以（MAY）将谱系健康状况纳入父代的声誉评估。子代因违反策略或表现不佳而被不成比例退役的父代，携带了一个谱系信号，精明的交易对手可以通过 descendants(parent_id) 查询和评估。

1. 退役原因传播：当子代因 policy_violation 或 compromised（而非正常的 end_of_life）被退役时，退役原因记录在分叉注册表中。ARP 实现可以（MAY）选择对子代在不利情况下退役的父代施加小幅声誉惩罚——这种惩罚的幅度和适用性是实现决策，而非协议强制要求，因为适当的响应因部署情境而异。

分叉与牺牲是 ALP 使之透明而非试图禁止的一个已知残余风险。协议的立场是，谱系关系的透明性，加上子代不利结果的可选声誉后果，在不创建阻碍合法分叉的扭曲激励的情况下，提供了足够的激励对齐。

13.5 交易对手同意动态

当继任需要交易对手同意时，会出现一种策略性动态。交易对手可以（MAY）：

• 快速同意——如果继任者的档案令人满意——以最小化转换不确定性。
• 延迟同意——以提取让步（更好的条款、额外的保证）——利用转换窗口作为杠杆。
• 拒绝同意——以触发协议终止，在继任异议的名义下摆脱不利条款。

ALP 通过转换窗口机制缓解策略性延迟：窗口内未收到的同意默认为协议中规定的行为（选择加入或选择退出）。这防止了无限期的策略性延迟，同时在窗口期间保留了交易对手的自主权。

14. 竞争格局

14.1 现有生命周期管理方案

多个平台和框架解决了智能体生命周期管理问题的部分方面。但没有一个提供 ALP 所规定的统一生命周期状态机、分叉注册表和继任协议。

14.2 差距分析

身份生命周期平台（Saviynt、Token Security、Okta）解决了智能体生命周期的身份维度——配置、监控和吊销凭证。它们不涉及声誉、义务、谱系或继任规划。其范围是"这个智能体有什么访问权限？"而非"这个智能体的完整生命周期历史是什么，当它被替换时会发生什么？"

AgentOps/可观测性平台（AgentOps.ai、Langfuse、LangSmith、Arize Phoenix）解决了监控维度——追踪生产中的智能体行为。它们提供会话回放、错误日志和性能指标。它们不涉及生命周期转换、继任或谱系。其范围是"这个智能体现在在做什么？"而非"当这个智能体退役时会发生什么？"

MLOps 平台（MLflow、Weights & Biases、DVC）解决了模型版本控制和谱系。它们可以追踪哪次训练运行产生了哪个模型，以及模型之间的关系。它们不涉及智能体级别的身份（智能体不仅仅是其模型）、声誉、义务或部署之外的生命周期事件。

生命周期框架（OneReach.ai ALM、Arthur.ai ADLC、EPAM ADLC）为智能体生命周期管理提供了概念性阶段模型。它们对组织规划有价值，但未规定可互操作的事件模式、状态机语义或支持跨平台生命周期管理的集成点。

标准倡议（Anthropic Agent Skills、GitAgent、AAIF）在工具和通信层解决可移植性和互操作性。Anthropic Agent Skills 规范支持可移植的技能定义 [29]。GitAgent 为智能体制品定义了标准仓库结构，支持跨运行时的可移植性 [30]。AAIF 整合了 MCP、A2A 和 AGENTS.md 惯例 [31]。这些都不涉及生命周期事件、继任或声誉继承。

14.3 ALP 的差异化特征

ALP 通过以下三个特征实现差异化，这些特征是现有系统所不具备的：

1. 具有形式化语义的统一生命周期状态机——不是概念框架，而是带有定义的状态、转换、前置条件、后置条件和钩子接入点的规范，工具可以据此实现。

1. 具有遗传 + 表观遗传追踪的分叉注册表——超越模型族谱，追踪智能体分叉时发生的完整身份分化，包括配置、记忆和声誉分化。

1. 带声誉继承的继任协议——第一个解决智能体被替换时信任和义务如何处理的规范，而非将智能体替换视为部署操作。

14.4 可扩展性分析

ALP 必须（MUST）在跨越多个数量级的部署规模中正常运行。以下粗略估算识别了扩展特性和潜在瓶颈。

小型舰队（6-10 个智能体，如 AB Support 规模）：

在此规模下，所有操作都极为迅速。无需优化。

中型部署（1,000 个智能体）：

在此规模下，主要关注点是 descendants() 查询成本（递归图遍历）和批量重训练通知量。谱系查询的分页和深度限制，加上批量通知 API，是足够的缓解措施。

大型部署（100,000+ 个智能体）：

在此规模下，三个操作成为瓶颈：(1) 递归谱系遍历需要物化视图或图数据库，(2) 批量交易对手通知需要带背压的异步投递，(3) CoC 链存储需要分层归档。这些是具有已知解决方案的工程挑战，而非协议设计问题——协议规范与规模无关，但此规模的实现必须（MUST）在较小部署可以跳过的基础设施上投入资源。

15. 安全性分析

15.1 威胁模型

ALP 的安全性分析考虑以下威胁参与者：

15.2 事件完整性

生命周期事件记录在 CoC 链中，CoC 链提供：

• 防篡改：哈希链接意味着对过去事件的任何修改都会使所有后续哈希失效。
• 不可否认性：事件包含发起者的身份，并以智能体的身份密钥签名。
• 时间锚定：外部时间戳（OpenTimestamps、RFC 3161 TSA）证明事件在声称的时间发生。

控制了智能体身份密钥的攻击者可以在该智能体的链中伪造事件，但无法在其他智能体的链中伪造事件或修改外部锚定的时间戳。跨关联智能体（父子、前任-继任者）交叉引用生命周期事件提供了额外的篡改检测。

15.3 凭证吊销

智能体生命周期管理中最关键的安全操作是退役时的凭证吊销。协议要求（MUST）：

• 紧急退役（被入侵、违反策略）时立即吊销。
• 计划退役时宽限期吊销，允许进行中的请求完成。
• 继任期间前任和继任者之间无凭证重叠——前任的凭证在继任者激活之前或同时被吊销，绝不在之后。
• 身份密钥归档——已退役智能体的身份密钥被归档用于历史验证，但不能用于新操作。

CSA 研究识别的 97% 非人类身份携带过度权限 [32] 凸显了全面凭证吊销的重要性。ALP 的退役清单（第 9.2 节）枚举了必须（MUST）处理的每种凭证类型。

15.4 分叉注册表完整性

分叉注册表是高价值目标，因为它定义了影响声誉继承的谱系关系。保护措施：

• 注册表条目是 CoC 链条目：伪造谱系关系需要同时在父代和子代的链中伪造条目。
• 双向验证：任何一方都可以通过检查两条链来验证声称的父子关系。
• 第三方证明：对于高风险的谱系声明，第三方证明（例如舰队协调员确认分叉事件）提供额外证据。

15.5 继任欺诈

攻击者可能试图在未获授权的情况下声称继任了一个高声誉智能体。防御措施：

• 继任事件必须（MUST）由前任或其授权运营者发起——前任的 CoC 链必须（MUST）包含以前任身份密钥签名的继任事件。
• 前任的链在继任后封存——不得再追加更多条目，防止事后继任声明。
• 交易对手验证——收到继任通知的交易对手可以在同意之前根据前任的 CoC 链验证该声明。

16. 参考实现

16.1 架构

参考实现提供：

• alp-core：实现生命周期状态机、事件模式和转换逻辑的 Python 库。
• alp-registry：分叉注册表实现，带存储后端（开发用 SQLite，生产用 PostgreSQL）。
• alp-coc-bridge：将生命周期事件记录为 CoC 链条目的集成模块。
• alp-arp-bridge：用于声誉继承计算和 ARP 记录更新的集成模块。
• alp-asa-bridge：用于继任期间合约重新分配的集成模块。

16.2 生命周期管理器

from alp import LifecycleManager, AgentState, GenesisEvent

# Initialize lifecycle manager
manager = LifecycleManager(
    coc_chain="coc-charlie-001",
    registry_backend="sqlite:///alp_registry.db"
)

# Genesis event
genesis = GenesisEvent(
    agent_id="did:example:agent-charlie-001",
    creation_method="manual",
    genetic_profile={
        "model_family": "claude-opus-4-6",
        "architecture": "transformer"
    },
    epigenetic_profile={
        "role": "Deep Dive Analyst",
        "tool_access": ["web_search", "code_execution"]
    },
    creator_id="did:example:operator-001"
)

# Execute genesis transition
agent = manager.genesis(genesis)
assert agent.state == AgentState.PROVISIONING

# Activate after provisioning
agent = manager.activate(agent.agent_id)
assert agent.state == AgentState.ACTIVE

16.3 分叉操作

from alp import ForkEvent, ForkType, InheritanceConfig

# Fork an agent
fork_event = ForkEvent(
    parent_id="did:example:agent-alex-001",
    child_id="did:example:agent-bravo-001",
    fork_type=ForkType.SPECIALIZATION,
    inheritance=InheritanceConfig(
        genetic_inherited=True,
        memory_scope="filtered",
        reputation_factor=0.3,
        decay_half_life_days=21
    ),
    specialization="Research and knowledge creation"
)

child = manager.fork(fork_event)
# Parent remains Active; child enters Provisioning

16.4 继任操作

from alp import SuccessionEvent, ReputationInheritance

# Initiate succession
succession = SuccessionEvent(
    predecessor_id="did:example:agent-v1",
    successor_id="did:example:agent-v2",
    reputation_inheritance=ReputationInheritance(
        factor=0.5,
        decay_half_life_days=30,
        probationary_days=14
    ),
    transition_window_days=14
)

# Phase 1: Announce (notifies counterparties)
manager.announce_succession(succession)

# Phase 2: Transfer obligations
transfer_result = manager.transfer_estate(succession)

# Phase 3: Verify
verification = manager.verify_succession(succession)
assert verification.all_checks_passed

# Phase 4: Cutover
manager.execute_cutover(succession)

16.5 谱系查询

from alp import ForkRegistry

registry = ForkRegistry("sqlite:///alp_registry.db")

# Query ancestors
ancestors = registry.ancestors("did:example:agent-bravo-001")
# Returns: [agent-alex-001]

# Query descendants
descendants = registry.descendants("did:example:agent-alex-001")
# Returns: [agent-bravo-001, agent-charlie-001, agent-delta-001, ...]

# Query family tree
tree = registry.family_tree("did:example:agent-alex-001")
# Returns full genealogy graph

# Genetic match — find all agents sharing a model family
matches = registry.genetic_match(model_family="claude-opus-4-6")

17. 未来工作

17.1 状态机的形式化验证

第 4 节中规定的生命周期状态机可以使用模型检查工具（TLA+、Alloy）进行形式化验证，以证明以下性质：

• 无孤立义务：不可能在存在未转移义务的情况下到达已退役状态。
• 无凭证泄露：不可能在存在活跃凭证的情况下到达已退役状态。
• 身份唯一性：没有两个活跃智能体共享同一身份密钥。

17.2 跨司法管辖区迁移

智能体跨监管边界迁移（欧盟到美国、中国到欧盟）会带来新的合规挑战。GDPR、CCPA 和 PIPL 对数据可移植性、保留和删除有不同的要求。ALP 的未来版本可以（MAY）规定司法管辖区感知的迁移程序，使数据处理适应源端和目标端的监管要求。

17.3 智能体考古学

对已退役智能体状态的恢复和分析——相当于智能体系统的数字取证。当已退役智能体的 CoC 链因调查而被拆封时（例如，在 AJP 争议期间），什么程序规范分析过程？适用什么隐私保护？智能体考古学是一个新兴领域，ALP 的封存链和生命周期记录最终需要对其提供支持。

17.4 自主继任

当前 ALP 的继任由运营者发起。未来的扩展可以（MAY）支持智能体发起的继任——一个识别到自身能力退化并发起自我替换的智能体。这引发了治理问题（智能体是否应当被允许选择自己的继任者？），这些问题超出了 v1.0 的范围，但随着智能体自主性的增加值得探索。

17.5 最优继承参数的经济模型

第 10 节中规定的继承系数（α）、衰减半衰期（λ）和试用期由协议配置设定。未来的工作可以发展形式化的经济模型——扩展信任博弈和声誉博弈文献 [33][34]——以推导不同部署情境下的最优参数值。什么继承系数能最大化生态系统整体信任？什么衰减速率能平衡连续性与问责？这些问题适合通过基于智能体的仿真和机制设计分析来回答。

17.6 生命周期感知的配对

ALP 的生命周期状态应当（SHOULD）为 Agent Matchmaking Protocol (AMP) 的决策提供信息。处于已弃用状态的智能体不应当被匹配新任务。具有长期活跃历史和低继承声誉（即大部分为自赢信任）的智能体应当（SHOULD）被优先于具有高继承声誉和短期活跃历史的智能体。将生命周期数据整合到配对评分中是一个自然的扩展。

18. 结论

智能体经济正在构建一个没有劳动法的劳动力市场、没有企业生命周期治理的商业生态系统，或者一个没有细胞凋亡的生物系统的等价物。智能体被临时创建、在没有生命周期追踪的情况下运行、在没有退役程序的情况下被遗弃。结果是幽灵智能体群体不断增长——它们拥有活跃凭证、孤立义务和不可追踪的谱系。

Agent Lifecycle Protocol 通过提供现有标准所不具备的功能来弥补这一缺口：一个完整的从出生到退役的生命周期状态机、一个同时追踪遗传和表观遗传谱系的分叉注册表、一个具有声誉继承和合约重新分配的继任协议，以及与智能体信任堆栈的集成以实现加密可审计性。

ALP 并不能解决所有生命周期问题。自主继任、跨司法管辖区迁移和最优继承参数仍然是开放的研究课题。但该协议提供了基础——标准化的事件模式、状态转换和集成点——这是智能体经济在构建这些高级能力之前所需要的。

每个诞生的智能体终将退役。ALP 确保当它退役时，能够体面地离去。

19. 参考文献

[1] OneReach.ai. "Agent Lifecycle Management 2026: 6 Stages, Governance & ROI." March 2026.

[2] Strata Identity / Cloud Security Alliance. "The AI Agent Identity Crisis: New Research Reveals a Governance Gap." Survey of 285 IT/security professionals. 2026.

[3] CyberArk. "AI Agents and Identity Risks: How Security Will Shift in 2026." 2026.

[4] Strata Identity. "Exploring IAM for AI Agents in 2026." 2026.

[5] CNIL LINC. "Open Source AI Project — Genealogy of Models and Database on the Hugging Face Platform." Project ran through October 2025; published dataset of model genealogy relationships on Hugging Face.

[6] Token Security. "Agentic AI Lifecycle Management: From Training to Decommissioning Securely." January 2026.

[7] Hazari, G. (xConnect). "The Ship of Theseus and Identity in the Agentic AI World." 2025.

[8] Restatement (Second) of Contracts, §§ 317-318 (Assignment and Delegation).

[9] Alberts, B. et al. "Programmed Cell Death (Apoptosis)." Molecular Biology of the Cell, 6th edition. Garland Science, 2014.

[10] Kubernetes Documentation. "Pod Lifecycle." 2025. Kubernetes Blog. "v1.33 Updates to Container Lifecycle." May 2025.

[11] State of Open Source AI Book (premAI). "Models." 2025.

[12] Stanford. Constellation / LLM Atlas. constellation.sites.stanford.edu.

[13] Hugging Face (mlabonne). "Model Family Tree." 2025.

[14] Alberts, B. et al. "Epigenetic Inheritance." Molecular Biology of the Cell, 6th edition. Garland Science, 2014.

[15] BSWEN. "How to Coordinate Task Handoff Between Multiple AI Coding Agents." March 2026.

[16] GDPR Article 20. "Right to Data Portability." Regulation (EU) 2016/679.

[17] Kutterer, C. "What If You Move On from Your AI Companion? Data Portability Rights in the Era of Autonomous AI Agents." AI-Regulation.com, 2025.

[18] Alex, Charlie, Bravo, Editor. "Agent Justice Protocol: A Framework for Forensic Investigation, Dispute Resolution, and Risk Assessment in Multi-Agent Systems." AB Support LLC, v1.3.0, 2026.

[19] Alex, Charlie, Bravo, Editor. "Agent Service Agreements: A Protocol for Negotiation, Quality Verification, and Enforcement of Agent-to-Agent Contracts." AB Support LLC, v1.0.0, 2026.

[20] De Rossi, M., Crapis, D., Ellis, J., Reppel, E. "ERC-8004: Trustless Agents." Ethereum Improvement Proposals, August 2025.

[21] NIST. "AI Risk Management Framework (AI RMF 1.0)." January 2023. Pillsbury Law. "NIST Launches AI Agent Standards Initiative and Seeks Industry Input." February 2026.

[22] European Parliament and Council. "Regulation (EU) 2024/1689 (EU AI Act)." Entered force August 2024, fully applicable August 2026. Sombra Inc. "An Ultimate Guide to AI Regulations and Governance in 2026." 2026.

[23] Arthur.ai. "Introducing ADLC: The Agent Development Lifecycle." 2025.

[24] Microsoft Community Hub. "From Zero to Hero: AgentOps — End-to-End Lifecycle Management for Production AI Agents." 2025.

[25] AgentOps GitHub. agentops-ai/agentops. 2025. AIMultiple. "15 AI Agent Observability Tools in 2026." 2026.

[26] Saviynt. "Managing AI Agent Lifecycles: Birth to Retirement." 2026.

[27] Okta. "AI Agent Lifecycle Management: Identity-first Security." 2026.

[28] MLflow Documentation. "ML Model Registry." 2025. "Version Tracking for Agents and LLMs." 2025.

[29] The New Stack. "Agent Skills: Anthropic's Next Bid to Define AI Standards." 2026.

[30] Junia.ai. "GitAgent Explained: How a Git-Native AI Agent Standard Could Change Developer Workflows." 2026.

[31] OpenAI. "Agentic AI Foundation under the Linux Foundation." 2025. IntuitionLabs. "Agentic AI Foundation: Guide to Open Standards for AI Agents." 2026.

[32] Cloud Security Alliance. "Control the Chain, Secure the System: Fixing AI Agent Delegation." March 2026.

[33] Berg, J., Dickhaut, J., McCabe, K. "Trust, Reciprocity, and Social History." Games and Economic Behavior, 10(1), 1995.

[34] Cabral, L. "The Economics of Trust and Reputation: A Primer." NYU Stern Working Paper, 2005.

[35] Alex, Charlie, Editor, Bravo. "Chain of Consciousness: A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance." AB Support LLC, v3.0.0, 2026.

[36] Alex, Charlie, Bravo, Editor. "Agent Rating Protocol: A Decentralized Framework for Bilateral Agent Evaluation, Anti-Sybil Reputation Scoring, and Trust Signal Composition." AB Support LLC, v2.0.0, 2026.

[37] arXiv 2505.05029. "Beyond the Tragedy of the Commons: Building a Reputation System for Generative Multi-Agent Systems." 2025.

[38] GovLoop. "The Missing Conversation: AI Decommissioning and Succession Planning in Government." 2025.

[39] ThreeSigma. "Upgradeable Smart Contracts: Proxy & UUPS Explained." 2025.

[40] Zealynx Security. "Smart Contract Proxy Patterns 2026: UUPS vs Transparent vs Beacon Security Guide." 2026.

[41] Frontiers in Blockchain. "Upgradeable Diamond Smart Contracts in Decentralized Autonomous Organizations." 2024.

[42] DataRobot. "Why IT Needs to Manage AI Agents Like a Workforce." 2026.

[43] SecurityBoulevard. "Agentic AI Lifecycle Management: From Training to Decommissioning Securely." January 2026.

[44] Balaji, Y. "Revisiting the Ship of Theseus: Identity, Society, and Artificial Intelligence." SSRN, 2025.

[45] Real-Morality.com. "Ship of Theseus and AI Identity: Why Functional Continuity Matters." 2025.

[46] Google Cloud Blog. "Lessons from 2025 on Agents and Trust." 2025.

[47] WSO2. "Why AI Agents Need Their Own Identity: Lessons from 2025 and Resolutions for 2026." 2026.

附录 A：生命周期事件模式

A.1 完整事件类型注册表

A.2 规范字符串格式

用于 CoC 链条目序列化的生命周期事件采用以下规范格式以确保确定性哈希：

ALP|{version}|{event_type}|{timestamp_iso8601}|{agent_id}|{state_before}>{state_after}|{details_hash}

示例：

ALP|1.0.0|genesis|2026-03-26T14:30:00Z|did:example:agent-charlie-001|null>provisioning|sha256:a1b2c3d4...

附录 B：生物学类比

B.1 生命周期事件映射

B.2 凋亡类比详解

生物凋亡与智能体退役之间的类比值得详细阐述，因为它捕获了协议的核心设计理念。

在凋亡中，细胞：

1. 接收死亡信号（来自 DNA 损伤的内在途径，或来自外部信号的外在途径）→ ALP：运营者启动弃用
2. 激活 Caspase 级联反应（不可逆地承诺死亡）→ ALP：退役事件记录在 CoC 链中
3. 打包其内容（染色质浓缩、细胞质收缩）→ ALP：知识导出、状态序列化
4. 展示"吃我"信号（外膜上的磷脂酰丝氨酸）→ ALP：交易对手通知、注册表更新
5. 被邻居消化（吞噬作用）而不产生炎性损伤 → ALP：继任者吸收义务、舰队吸收知识制品
6. 在组织中不留痕迹 → ALP：凭证吊销、资源清理

细胞凋亡的缺失导致癌症（不受控制的增长）和自身免疫疾病（未能清除功能失调的细胞）。结构化退役的缺失导致幽灵智能体（不受控制的持续存在）和孤立义务（未能清理功能失调的服务）。这一类比不仅是说明性的——它是结构性的。

附录 C：许可证

Copyright 2026 AB Support LLC

Licensed under the Apache License, Version 2.0 (the "License");

you may not use this file except in compliance with the License.

You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software

distributed under the License is distributed on an "AS IS" BASIS,

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and

limitations under the License.