Appearance
企业模型、Skill、Expert、Connector 资产生命周期
这不是一张更长的资产清单
企业 AI 资产的难点不在“有没有模型、Skill 或 Connector”，而在于能否回答：谁创建、谁批准、谁可以使用、谁能看到资料、谁负责更新，以及出现问题时谁可以停用和回收。若每个团队都在自己的目录里维护，重复建设、无 owner、版本不明、离职遗留和凭证泄露会同时出现。
产品事实与实施方法：WorkBuddy Enterprise 官方资料和公开文档提供企业版产品、管理员、专家、资产和连接能力的核对线索；不同租户是否有统一资产目录、具体菜单和原生审批流，必须以当前文档和现场权限为准。下文的生命周期、RACI、目录字段和检查清单是实施方法，不宣称平台已经内置这些流程。
一、先定义资产边界
可纳入企业治理目录的对象，先按官方文档中当前能核对的产品概念登记；如果某对象只是在内部方案里出现，不要自行把它命名为 WorkBuddy 的统一 AI Asset。
| 对象 | 资产治理时要记录什么 | 不应直接推断什么 |
|---|---|---|
| Model | 版本、用途、准入范围、费用与数据边界 | 某个模型在所有租户、区域或套餐都可用 |
| Skill | 触发、输入、Instructions、依赖、输出、版本和权限 | Skill 天然安全，或安装即代表通过审核 |
| Expert | 角色职责、方法边界、工具和适用任务 | “专家”称谓等于专业资质或自动正确 |
| Connector | 目标系统、账号、数据范围、动作和撤销方式 | 连接成功等于拥有全量读写权限 |
| Agent | 业务目标、状态、工具、数据、责任人和运行边界 | 企业一定有统一的 Agent 发布、评测或监控菜单 |
| Knowledge | 来源、版本、权限、保留期限和主版本 | 任何共享文件夹都属于企业统一知识资产 |
表格中的后一列是硬边界。企业可以用内部目录把这些对象关联起来，但目录字段和治理方法不能反过来变成未经核验的产品功能承诺。
二、统一生命周期：创建到回收
建议采用以下生命周期，状态变化要有负责人、证据和可回退动作：
| 阶段 | 产品事实核对 | 实施方法与出口条件 |
|---|---|---|
| 创建 | 当前版本是否有对应创建、导入或配置入口？ | 登记目标、来源、owner、输入输出和权限，不直接接生产数据 |
| 测试 | 当前产品是否能在限定范围试跑、预览或查看结果？ | 使用脱敏样本，覆盖正常、异常、越权和失败路径 |
| 审批 | 当前租户是否提供管理员或组织审批入口？ | 若没有原生审批，用批准记录、责任人和变更单补齐门禁 |
| 发布 | 当前可见性、分享、安装和下发范围是什么？ | 先小范围发布，明确版本、受众、限制和撤回路径 |
| 使用 | 谁能调用、读取资料或触发外部动作？ | 按组织、角色、席位和资产可见性分配最小范围 |
| 监控 | 当前版本是否提供运行状态、日志、用量或告警？ | 记录使用反馈、失败、成本、权限异常和外部依赖 |
| 更新 | 变更会影响哪些输入、输出、权限和下游任务？ | 复制旧版本，变更说明、回归测试和批准齐全后再替换 |
| 停用 | 是否有关闭、撤回、解绑或下发回收入口？ | 先停止新调用，再处理队列、依赖、使用者通知和恢复 |
| 回收 | 凭证、文件、日志和分享副本由谁处理？ | 撤销授权、回收席位、归档记录，保留合规所需证据 |
不要把状态写成“已发布 = 永久可用”。发布只是当前范围内允许使用，模型、连接器、来源、权限和合同变化都可能触发重新评估。
三、Ownership：五个角色不能混成一个名字
最少明确以下责任，实际组织可以由同一人兼任，但不能无人负责：
- 创建人。 负责把目标、输入、输出和来源写成可测试的初版；不能独自批准自己的高风险发布。
- 资产 owner。 对适用范围、版本、质量、依赖、使用反馈和停用负责。
- 安全 / 管理复核人。 检查权限、敏感数据、凭证、外部连接和审计边界。
- 使用团队。 在批准范围内调用，报告错误、越权、资料过期和业务不适用。
- 停用人。 负责撤回、解绑、通知、依赖迁移和回收凭证，不等到原 owner 离职才处理。
可用一张责任表落地：
| 决策 | R（执行） | A（最终负责） | C（需咨询） | I（需通知） |
|---|---|---|---|---|
| 创建与测试 | 创建人 / 试点团队 | 资产 owner | 安全、业务复核人 | 目标使用团队 |
| 权限与发布 | 管理员 / 安全复核人 | 资产 owner 或授权管理员 | 数据 owner、IT | 使用团队 |
| 版本替换 | 维护人 | 资产 owner | 下游任务负责人 | 所有受影响用户 |
| 事故与停用 | 维护人 / 安全团队 | 停用人 | 业务 owner、IT | 使用团队与管理层 |
| 凭证回收 | 管理员 / 凭证 owner | 安全负责人 | 资产 owner | 相关任务负责人 |
RACI 是组织实施模板，不是 WorkBuddy 后台字段。最重要的是每个资产有一个能做决定的 A，而不是把责任写成“平台负责”。
四、为什么要有资产目录
统一目录至少解决六类问题：
- 重复建设。 发现已有 Skill、Expert 或 Connector，减少多个团队维护相似版本。
- 责任缺失。 资产过期或错误时，可以找到 owner 和停用人。
- 版本不明。 使用者知道当前批准版本、变更原因和兼容输入。
- 使用不可见。 能知道哪些任务依赖某个资产，更新前先评估影响。
- 离职风险。 不让个人账号、个人目录和个人 Token 成为唯一依赖。
- 凭证风险。 把授权范围、到期、轮换和撤销方法放进资产上下文。
建议目录字段包括：资产 ID、名称、类型、版本、状态、owner、创建人、批准人、适用任务、不适用任务、输入、输出、依赖、组织范围、角色 / 席位范围、数据敏感级别、Connector 权限、测试记录、变更历史、使用依赖、停用方式、回退版本和下次复核日期。字段多不等于治理完成，必须能在变更和事故时真正找到证据。
五、权限和敏感数据
至少从五层核对权限：
- Organization。 资产属于哪个组织、部门或环境，是否允许跨组织复用；
- Role。 谁能创建、审核、发布、修改、查看运行记录和停用；
- Seat。 哪些席位可以使用，席位回收后任务和资产如何处理；
- Asset visibility。 草稿、测试、限定团队和全组织可见性的边界；
- Connector permission。 连接到什么系统、读写哪些对象、使用哪种认证和何时撤销。
敏感资料要进一步记录分类、来源、保留期限、脱敏方法、日志范围和外发限制。不要因为资产目录可见就让资产内容对所有使用者可读，也不要把 API Key、OAuth Token、Webhook Secret 或内部地址放进共享说明、示例截图或 Prompt。
六、企业 AI Asset 上线清单
- [ ] 资产类型和产品能力已经按当前官方文档、租户权限或实测核对；
- [ ] 目标任务、使用者、输入、输出、不适用场景和失败条件明确；
- [ ] 来源、版本、owner、批准人、维护人和停用人已登记；
- [ ] 组织、角色、席位、可见性和 Connector 权限符合最小范围；
- [ ] 测试覆盖正常、异常、权限不足、数据越权、工具失败和回退；
- [ ] 资料、凭证、日志和外部系统的数据路径已审查；
- [ ] 发布范围、使用说明、已知限制和人工确认点已经通知使用者；
- [ ] 更新前有旧版本、变更记录、兼容性检查和回退方案；
- [ ] 出现质量、权限或安全问题时可以停止调用、撤回分享、解绑 Connector 和回收凭证；
- [ ] 停用后仍保留必要的审计证据，不把敏感数据复制到非批准位置。
如果产品没有对应原生审批、评测或监控入口，就在目录中标记“实施方法 / 外部记录”，而不是写成“平台已支持”。
相关内容
- 企业管理员后台能管理什么？
- 企业如何统一管理模型、Skill、专家和 Connector？
- 组织、角色、席位与 OneID
- 企业版连接器与 MCP 怎么使用？
- Skill 供应链和第三方内容如何审查？
- 企业 Agent 创建、测试、运行、评测与停用
- 企业版整体安全机制怎么理解？
- Skill 创建、测试、版本与发布
来源与版本说明
本站内容根据官方资料及公开网络信息持续整理与核验。官方页面中的模型、Skill、Expert、Connector、管理员菜单、权限、数量、版本和企业能力可能变化；请以最新官方信息、当前租户实际权限和合同为准。
本站为独立整理的实操知识库，不代表 WorkBuddy 官方。
内容版本与核对日期
- 内容版本：
0.1.0 - 最后核对日期：
2026-09-26