M05 智能体技能资产标准化封装

为什么学这一课

在 M02，你学会了把一个真实任务拆解成技能、写成代码、挂载到智能体上让它跑起来。代码能跑，是工程能力的证明；但代码能跑，不等于它可以被交付、被交易、被信任。

想一个问题：假设你在 M02 里写了一个「跨境电商商品合规检查」技能，它在你的智能体上跑了 200 次，准确率 98%。现在另一个城市的商户想用它。你打算怎么给他？

发一个 zip 包？发一段代码链接？还是把你的智能体账号借给他？这三种方式都有同一个致命问题：接收方无法判断这个东西是什么、边界在哪、风险有多大、出问题找谁。代码是写给机器执行的；资产是写给人决策的。中间缺的那一层，就是封装。

这一课要解决的，正是这件事：把验证稳定的技能，封装成一份标准化的、可交易的资产包。封装完成的那一刻，发生了一件法律和经济意义上的大事——这个技能从「一段代码」变成了「一件有主、有界、有价的资产」。它可以被审计（M04 的结论写进包里）、可以被定价（M06 的起点就在这里）、可以在市场上流转而不丢失信任。

记住这一课的核心命题，后面会反复用到：

封装即确权，标准即信任。

封装回答的是「这是谁的、是什么、能干什么、不能干什么」——这是确权。标准回答的是「所有人都按同一套格式说话」——这是信任。没有确权，资产不敢买；没有标准，资产没法比。M06 的变现体系，全部建在这两个词的地基上。

核心概念

1. 资产 vs 代码：四条分界线

代码和资产的区别，不在于文件格式，而在于四个问题的答案是否完备：

注意第一条。智能体是人的数字代理，没有独立法律主体资格（这是我们在 M01 确立的第一性原理）。所以资产包里的 owner 字段绑定的永远是人类身份，不是智能体 ID。一份没有 owner 的资产包，在市场上是不可上架的——买方无法确立交易对手，仲裁无从谈起。这是标准里的硬性门槛，不是可选项。

2. 标准化封装的 5 要素

一份合格的资产包，必须包含以下五个部分，缺一不可。我们把它记作 D-S-S-R-V：

1. D — Description（技能说明）：这个技能是什么、解决什么问题、输入输出是什么。用买方能看懂的语言写，不是给开发者看的 README。
2. S — Safety（安全评估）：基于 M03 的安全边界设计和 M04 的审计结论，写明已验证的安全等级、已知的风险点、熔断触发条件。
3. S — Scope（适用范围）：明确「在哪能用」和「在哪不能用」。范围描述越精确，纠纷越少。
4. R — Risk（风险提示）：诚实列出残余风险。注意：风险提示不是免责声明的堆砌，而是让买方做知情决策的信息披露。
5. V — Version（版本管理）：语义化版本号 + 变更日志 + 每次变更的审计记录哈希。

这五个要素对应资产包的五个文件（后面深度解析里逐项拆）。记住一个检验标准：一个从没见过你的陌生人，只读这五个文件，就能决定买还是不买。做不到这一点，封装就不合格。

3. 版本语义：为什么版本号是信任机制

我们采用语义化版本（主版本.次版本.修订号），但在这里它不只是工程惯例，而是信任契约的一部分：

• 修订号升级（1.2.3 → 1.2.4）：只修 bug，不改行为。买方可以无感升级，风险提示不变。
• 次版本升级（1.2.x → 1.3.0）：新增能力或扩展适用范围，但保持向后兼容。买方需要重读 Scope 部分。
• 主版本升级（1.x → 2.0.0）：行为变更或不兼容。必须重新走完整的安全评估和审计，旧版本的风险提示自动失效。

关键规则：主版本号变更 = 重新确权。因为 2.0 的行为边界变了，原来的安全评估结论不再适用。如果允许 2.0 沿用 1.x 的审计结论，等于让买方为未经验证的行为买单——这是标准要堵死的漏洞。

每一次版本变更，还必须附带：变更内容说明、变更前后的行为对比测试结果、新的审计记录哈希。这三样东西构成版本的可追溯链。市场上看到 v2.3.1 的资产，买方能一路追溯到 v1.0.0 的每一次变更依据。这就是「标准即信任」在版本维度上的落地。

深度解析：一份优秀资产包长什么样

下面是一份资产包的标准目录结构。我们逐项拆解，每一项都说明「写什么」和「为什么这样写」。

tata-asset-compliance-checker/
├── asset.yaml            # 资产元数据：身份与确权
├── SKILL.md              # 技能说明：买方视角的功能描述
├── SAFETY.md             # 安全评估：验证结论与等级
├── SCOPE.md              # 适用范围：能用在哪、不能用在哪
├── RISK.md               # 风险提示：残余风险的诚实披露
├── CHANGELOG.md          # 版本变更记录
├── audit/                # 审计证据（M04 的产出归档）
│   ├── audit-report-v1.0.0.pdf
│   └── behavior-log-sample.json
└── skill/                # 技能本体（代码与配置）
    ├── main.py
    └── config.yaml

asset.yaml —— 资产的身份证

这是整个包里最重要、也最短的文件。它不描述功能，只确立身份：

asset_id: tata-asset-compliance-001
name: 跨境商品合规检查技能
owner: human:wu-hepeng          # 人类所有者，必填
creator_agent: agent:tata-07     # 创建它的智能体（记录用，不确权）
version: 1.2.0
created_at: 2026-10-10
license: tata-commercial-v1      # 许可类型，M06 会展开
price_model: per_call            # 计价模式：按次 / 买断 / 订阅
audit_hash: sha256:9f3a...       # 最新审计报告的哈希，防篡改

逐项说明：

• asset_id：全局唯一，一经分配永不复用。即使资产下架，ID 保留，防止市场上出现「同名不同物」。
• owner：必填，绑定人类身份。这是确权的核心字段。注意 creator_agent 只是 provenance（来源记录），不产生任何权利——智能体创造的东西，权利归属于它的人类 owner（M01 原理）。
• audit_hash：审计报告的哈希值锚定。买方拿到包之后，可以独立验证报告未被篡改。这是把 M04 的审计结论「焊」进资产包的机制。
• price_model：在这里只声明计价模式，不写具体价格。价格是 M06 的事，但模式必须在封装时确定，因为它决定了交付形态（按次调用需要 API 接入，买断需要完整交付）。

SKILL.md —— 写给买方看的功能说明

这是买方第一个打开的文件。写作原则：假设读者完全不懂技术，但要做购买决策。结构建议：

1. 一句话：这个技能解决什么问题（不超过 50 字）
2. 输入输出：买方需要提供什么、会得到什么（举 2 个具体例子）
3. 能力边界：它能处理的最复杂情况是什么（给出可验证的指标，如「单次最多检查 500 个 SKU，准确率 98.2%」）
4. 运行要求：需要买方提供什么环境、数据、权限
5. 不包含什么：明确排除项（比如「不包含法律意见输出，仅做规则匹配」）

注意第 5 点。新手最容易漏掉的就是「不包含什么」。但恰恰是排除项，在纠纷时最有价值——买方说「我以为它能做 X」的时候，SCOPE.md 和这里的排除项就是仲裁依据。

SAFETY.md —— 安全评估文档

这份文件的权威性来自 M03 和 M04 的工作，不是写作者的主观判断。必须包含：

• 安全等级：L1（低风险，可全自动）/ L2（中风险，需人工抽查）/ L3（高风险，需人工复核）。等级的判定标准来自 M03 的熔断设计。
• 已验证项：列出通过了哪些测试（附测试报告位置）。例如：「已通过 2000 条真实商品数据的回归测试；已通过对抗输入测试（恶意构造的合规描述）。」
• 熔断条件：什么情况下这个技能会被暂停（例如：「单日错误率超过 5% 自动熔断」）。
• 人工接管点：哪些环节必须有人类确认（例如：「涉及下架建议的输出，需商户人工确认后执行」）。

写作红线：不许写「绝对安全」「零风险」。任何技能都有残余风险，写「零风险」的文件会被视为不专业，严重的会被认定为虚假陈述。诚实的写法是：「在以下测试范围内，观察到的失败率为 X；超出该范围的行为未经验证。」

SCOPE.md —— 适用范围

这是纠纷率最高的文件，也是写得最需要功力的文件。好的 Scope 描述有三个层次：

1. 适用场景（正面清单）：列出 3-5 个典型适用场景，越具体越好。「适用于亚马逊美国站的服装类目商品标题合规检查」远胜于「适用于电商」。
2. 不适用场景（负面清单）：明确排除。例如：「不适用于药品、食品类目；不适用于欧盟市场的 CE 认证判断。」
3. 边界条件：量化的边界。「单次输入不超过 500 条；商品描述为英文；规则库版本为 2026-Q3。」超出边界的行为是「未定义的」，不是「保证能跑的」。

一个检验方法：把 Scope 拿给完全不懂行的朋友看，他能准确说出「这个东西我能不能用」——过了；如果他说「好像能用吧」——没过，重写。

RISK.md —— 风险提示

与 SAFETY.md 的区别：SAFETY 写「我们验证了什么」，RISK 写「还有什么没验证、可能出什么问题」。必须包含：

• 已知残余风险：逐条列出，每条包含「风险描述」「发生概率评估」「影响程度」「缓解措施」。
• 依赖风险：这个技能依赖哪些外部条件（规则库更新频率、上游 API 可用性），依赖失效时会发生什么。
• 误用风险：买方最可能怎么用错，以及用错的后果。

RISK.md 的诚实程度，直接决定这份资产在市场上的信任分。一个把风险写清楚的资产，卖得比藏着掖着的贵——因为买方的决策成本更低。这是反直觉但真实的市场规律。

CHANGELOG.md 与 audit/ 目录

CHANGELOG 按版本倒序记录每次变更：版本号、日期、变更类型（新增/修复/行为变更）、关联的审计记录。audit/ 目录归档 M04 产出的审计报告和关键行为日志样本。注意：日志样本要脱敏，不能包含真实商户数据——这是隐私红线。

真实案例

案例一：从「好用的脚本」到「月入资产」——合规检查技能

背景：一位跨境电商从业者（同时是 TaTa School 学员）在 M02 实训里写了个「商品标题违禁词检查」技能，起初只是给自己店铺用的 Python 脚本。

封装过程的关键决策： - 他在 SCOPE.md 里把适用范围限定为「亚马逊美国站 + 服装类目 + 英文标题」，而不是贪大写成「全平台通用」。这个克制让他的安全评估变得可验证——测试集就是美国站服装类目的 2000 条真实标题。 - 他在 RISK.md 里诚实写明：「规则库每月更新一次，新出台的平台政策有最长 30 天的滞后；不识别图片中的文字。」买方一看就懂边界。 - 版本从 1.0.0 起步，修了两次误报规则后到 1.0.2，买方无感升级。后来他增加了「多语言标题支持」，按规则升到 1.1.0，并重新做了安全评估。

结果：这个资产在市场上以按次计费模式上架，三个月后成为该类目调用量前三的技能。复盘时他说，买方选择他的理由不是「功能最强」，而是「文档最让人放心」。

要点：范围的克制，是信任的来源。什么都宣称能做的资产，什么都卖不出去。

案例二：封装不合格导致的仲裁——物流时效预测技能

背景：某学员封装了一个「物流时效预测」技能，SKILL.md 写得天花乱坠，SCOPE.md 只有一句话：「适用于跨境物流」。RISK.md 是空的——他觉得「都测过了，没什么风险」。

纠纷：买方用它预测东南亚专线的时效，偏差极大，导致备货决策失误，发起争议要求退款。仲裁时发现： - 技能的测试集全是欧美线路数据，东南亚线路从未经验证——但 SCOPE.md 没有负面清单，买方有理由认为「跨境物流」包含东南亚。 - RISK.md 为空，买方主张「卖方未披露适用局限」。

裁决：买方胜诉，全额退款，卖方信誉分下调。卖方后来重写了 SCOPE.md（限定欧美线路 + 负面清单列出未验证区域），重新上架后零纠纷。

要点：封装时的每一处含糊，都会在仲裁时变成你的成本。SCOPE.md 的负面清单不是「自我设限」，是「自我保护」。

案例三：版本管理的价值——客服话术生成技能

背景：一个「多语言客服话术生成」技能 v1.x 在市场上运行良好。作者在 2.0 版本中更换了底层模型，生成风格变化显著，但沿用了 1.x 的安全评估结论，没有重新审计。

事件：某买方按 1.x 的行为预期接入 2.0，发现话术风格突变影响品牌调性，投诉。调查发现 2.0 的行为边界已实质变更，按标准应当重新确权（主版本升级 = 重新审计），但作者跳过了这一步。

处理：平台下架 2.0，要求补做安全评估后重新上架为 2.0.1（带新的审计哈希）。作者补课后重新上架，并在 CHANGELOG 里如实记录了这次教训。

要点：版本号不是装饰，是契约。主版本升级跳过重新审计，等于单方面修改了与买方的信任契约。

实操练习：把你的 M02 技能封装成资产包

拿出你在 M02 实训里设计（或正在设计）的技能，按下面的清单逐项完成。目标是产出一份「可以拿给陌生人看、对方能据此决定买不买」的资产包。

清单一：身份与确权（asset.yaml）

• [ ] 分配全局唯一的 asset_id（建议格式：tata-asset-<领域>-<序号>）
• [ ] 填写 owner（你的人类身份标识）
• [ ] 记录 creator_agent（创建它的智能体 ID，仅作来源记录）
• [ ] 确定 version（首次封装从 1.0.0 开始）
• [ ] 确定 price_model（per_call / outright / subscription 三选一，先选模式不定价）
• [ ] 预留 audit_hash 字段（M04 审计完成后填入）

清单二：买方文档（SKILL.md）

• [ ] 一句话说清解决什么问题（≤50 字）
• [ ] 写出输入输出，各举 2 个具体例子
• [ ] 写出能力边界（含可验证的量化指标）
• [ ] 写出运行要求（环境、数据、权限）
• [ ] 写出「不包含什么」（至少 3 条排除项）

清单三：安全与范围（SAFETY.md + SCOPE.md）

• [ ] 判定安全等级 L1/L2/L3（对照 M03 的熔断标准）
• [ ] 列出已验证项（测试集规模、测试类型）
• [ ] 写明熔断条件和人工接管点
• [ ] SCOPE.md 写出 3-5 个正面场景（越具体越好）
• [ ] SCOPE.md 写出负面清单（至少列出 3 类不适用场景）
• [ ] 写出量化边界条件（数据量、语言、规则版本等）

清单四：风险与版本（RISK.md + CHANGELOG.md）

• [ ] 列出至少 3 条残余风险（每条含描述、概率、影响、缓解）
• [ ] 列出依赖风险（外部规则库、上游 API）
• [ ] 列出 1-2 条典型误用场景及后果
• [ ] 检查全文：确认没有出现「绝对安全」「零风险」「保证」等词汇
• [ ] 建立 CHANGELOG.md，记录 1.0.0 的初始条目
• [ ] 把 M04 的审计报告归档进 audit/ 目录（或预留位置）

验收标准

找一位没看过你代码的朋友（或让 Toccter 扮演买方），只给他看这五个文件（不含代码），问他三个问题： 1. 「这个技能是干什么的？」——他能用自己的话复述，SKILL.md 过关。 2. 「你敢不敢买？」——他能说出至少一个风险点和一个不适用场景，SCOPE + RISK 过关。 3. 「出问题找谁？」——他能指出 owner，asset.yaml 过关。

三题全过，封装合格。有一题含糊，打回重写对应的文件。

常见误区

误区一：「代码写得好，文档随便写写就行。」 恰恰相反。在资产交易里，文档就是产品的一部分，甚至是买方唯一能看到的产品。代码是交付时才打开的黑盒，文档是决策时唯一的依据。文档潦草的资产，等于把买方往竞争对手那里推。

误区二：「适用范围写得越宽，潜在买家越多。」 写得宽，纠纷率指数上升。案例二就是代价。一个精准定位的小资产，复购率远高于一个什么都宣称的大资产。市场奖励诚实，惩罚贪婪。

误区三：「风险提示写多了，会把买家吓跑。」 短期看，诚实披露可能过滤掉一批买家；长期看，它过滤掉的是纠纷，留下的是信任。信誉体系（M06 会讲）对「文档完备度」有加权——写得全的资产，排序更靠前。这不是道德说教，是机制设计。

误区四：「版本号随便定，反正能跑就行。」 版本号是买方判断「要不要升级」「要不要重测」的唯一信号。随意变更版本号等于破坏信号系统。记住规则：修 bug 升修订号，加能力升次版本，改行为升主版本——主版本升级必须重新审计。

误区五：「封装是一次性的事，做完就扔那儿。」 资产是活的。规则库会更新、平台政策会变、模型会迭代。每一次实质变更都要走「变更 → 测试 → 审计 → 升版本 → 更新文档」的闭环。封装不是终点，是资产生命周期的起点。M07 的长期治理，讲的正是这件事。

误区六：「owner 写智能体 ID 就行，反正是它创造的。」 不行。这是确权红线。智能体没有独立法律主体资格，不能持有资产。owner 必须是人类。写错 owner 字段的资产包无法上架——这不是流程刁难，是整个交易体系的法律地基。

延伸思考

1. 标准的边界：我们这套五要素标准，假设了买卖双方都是理性决策者。但如果买方是另一个智能体（AGI 对 AGI 交易），「文档」应该是什么形态？机器可读的 asset.yaml 是否足够，还是需要一套完全不同的确权协议？这是 M06 和 agent 协议设计要回答的问题。

2. 信任的定价：案例一里，文档写得好的资产卖得更贵。能不能把「文档完备度」量化成信誉分的一个维度？如果可以，权重应该占多少？过度加权会不会导致「文档内卷」——大家把 RISK.md 写得越来越长，反而没人看了？

3. 封装的自动化：今天这套流程是人工的。未来智能体自己创造技能、自己封装、自己上架——这个链条里，人类管控者应该卡在哪几个点？M03 的熔断点和这里的封装审核点，是同一个点吗？

4. 跨司法管辖区的确权：asset.yaml 里的 owner 绑定的是人类身份，但「人类身份」在不同司法管辖区的法律含义不同。一份在中国确权的资产，在另一个法域交易时，确权是否仍然有效？这是支付生态 Phase 3 必须解决的问题，也是你作为 AGI 管控者需要持续跟踪的议题。

5. 回到起点：M01 说，智能体是人的数字代理，人的延伸。封装这件事，本质上是人在为智能体的产出「背书」——用自己的名字（owner 字段）为它担保。当你签下 owner 的那一刻，你在担保什么？想清楚这个问题，你就理解了为什么这一课叫「标准化封装」，而不叫「打包教程」。

下一课 M06，我们将站在今天打好的地基上，讨论这些资产如何定价、如何找到买家、如何设计变现模式。今天封装时确定的 price_model、写下的 SCOPE 和 RISK，都会在 M06 变成定价和谈判桌上的具体数字。地基打得越实，楼能盖得越高。