Owner / 版本 / 状态的资产生命周期

Owner / 版本 / 状态的资产生命周期

本节摘要:资产不是静态记录,它有生命周期——从新建、审核、分享、配装,到归档收回。本节拆解驱动这个生命周期的三个字段:Owner 决定「归谁管」,版本决定「是第几版、能否回滚」,状态决定「现在能不能用」。三者协作,让一条资产既能被归属清晰管理,又能随时间演进而不丢历史,还能在过时后安全退出。本节是这个统一模型里偏「时间维度」的一半,与下一节的可见性(空间维度)合起来,构成资产治理的完整图景。

一、资产生命周期的状态流转

一条资产从生到灭,状态大致这样流转:

┌────────┐    审核    ┌────────┐    分享    ┌────────┐    过时/收回
│ 新建    │──────────▶│ 审核中  │──────────▶│ 可用    │──────────▶┌────────┐
│(私有)   │           │         │           │(参与召回)│            │ 归档    │
└────────┘           └────────┘           └────────┘            └────────┘
                                                 ▲                    │
                                                 │     发现问题         │
                                                 └─────(回退)──────────┘
​

关键概念:状态字段的核心作用是「控制是否参与召回」——只有「可用」状态的资产才会被召回引擎取到。这一点在上一节的过滤流程里已经提过,本节把它与 Owner、版本串成完整生命周期。

二、Owner:归属即管理权

Owner 字段标记资产的归属者,它带来一条重要规则:Owner 自动获得对应资产的管理权限。

Owner 的两层含义
  ① 归属:这条资产算谁的(责任归属)
  ② 权限:Owner 自动能管理(改/分享/收回),无需额外授权
​

这与第 5 章的角色体系配合:Team Admin 能管理团队内所有资产(治理权),但 Owner 是「天然归属者」。两者的区别在于「权力来源」——Admin 的权力来自角色,Owner 的权力来自归属。

💡 技巧:实践中,新建资产时 Owner 默认是创建者。这意味着「你创建的资产你天然能管」,不需要别人给你授权——这降低了治理的摩擦。但要注意,Owner 不是「永久独占」,Owner 可以是团队角色(团队共建资产)。

三、版本:让资产可演进可回滚

版本字段解决「经验会过时,要能管理历史」的问题。一条 Skill 尤其需要版本——它是可执行流程,改错了一版要能回退:

版本的价值(以 Skill 为例)
  v1: 排障 Skill 初版(基本步骤)
  v2: + 增加了日志检查步骤
  v3: + 增加了回滚验证(当前在用)
  
  若 v3 的回滚验证有问题 → 回退到 v2,无需重写
​

版本与状态协作:同一资产可以有多个版本并存,但通常只有一个版本处于「可用」状态。这让资产既能演进(出新版),又能回滚(退回旧版),还不丢历史(旧版仍在)。

⚠️ 注意:版本管理是有成本的——每多保留一个版本就多占存储。实践中通常只保留近 N 个版本,更老的归档或清理。对 Chat Memory 这类高频变更的资产,版本粒度可能更粗;对 Skill 这类需要精确回滚的,版本粒度更细。

四、三字段协作:一个完整生命周期示例

用一个 Skill 的真实生命周期,把三字段串起来:

时间轴 ─────────────────────────────────────────────────▶
        
t1  alice 创建「发布检查 Skill」v1
    Owner=alice  版本=v1  状态=新建(私有)
    
t2  alice 完善后提交审核
                    状态=审核中
    
t3  Team Admin 审核通过,分享给团队
                    状态=可用  可见性=team
    
t4  该 Skill 配装给 Release Agent
                    绑定=[Release]
    
t5  发现 v1 漏了「数据库备份检查」,alice 出 v2
    Owner=alice  版本=v2  状态=可用(v1 仍保留但不再可用)
    
t6  v2 用了一段时间稳定,成为团队标准
    使用计数=N(被召回 N 次)
    
t7  发布流程大改,旧 Skill 过时
                    状态=归档(退出召回,但保留历史)
​

这个例子里,Owner 自始至终是 alice(她能管),版本从 v1 演进到 v2(能回滚),状态从新建流转到归档(可控退出)。三者协作,让一条「经验」既能被归属、又能演进、还能善终。

五、生命周期与召回的关系

要把生命周期和召回的关系钉死,记住一句话:召回只看「可用」状态、「当前版本」、且「绑定含当前 Agent」的资产。

召回时的生命周期过滤
  所有资产
    └─ 状态=可用?            (归档的不要)
        └─ 是当前版本?        (旧版的不要)
            └─ 绑定含当前 Agent? (没装配的不要)
                └─ 通过 → 进入候选集 → 检索
​

这意味着「归档」「出新版后的旧版」「没装配的资产」都不会进召回——生命周期治理直接影响召回质量。这就是为什么第 5 章控制台要让人能方便地管理这些状态——它是召回准确性的「人工把关」环节。

本节要点回顾

1. 状态流转:新建→审核中→可用→归档,只有「可用」参与召回。
2. Owner 双层:归属 + 自动管理权,权力来自归属而非角色。
3. 版本价值:让资产可演进可回滚,Skill 尤其需要;与状态协作,通常只一版可用。
4. 三字段协作:Owner(归谁管)+ 版本(第几版)+ 状态(能否用),构成完整生命周期。
5. 生命周期影响召回:归档/旧版/未装配的资产不进召回——治理是召回质量的把关环节。

时间维度清楚后,下一节看空间维度——可见性如何控制「谁能读」,让团队共享经验却不必共享全部隐私。