候选代码怎样成为可召回 Skill
一句话收获：Skill 是可验证的方法制品，不是 Prompt 模板或单个 Tool。
这个场景在解决什么问题
上一场景讲的是"代码怎么变成候选能力"，这一场景讲"候选能力怎么转正成 Skill"（技能，一种可验证、可复用的方法制品）。很多人把 Skill 理解成"一段写得好的 Prompt 模板"或"一个工具"，这是错的——Skill 是"可验证的方法制品"，有完整生命周期。
这个场景的目标（goal）是：实现契约、沙箱、测试、注册、冻结和召回。观察点（observation）是：让候选能力经过完整准入生命周期——从候选到正式 Skill，要过一道道关卡。
它值得单独学，因为它纠正一个根本误解：Skill 不是 Prompt 模板，也不是单个 Tool，而是一个"带契约、带验收、可召回、可冻结"的方法制品。
先理清这条判断链（文字版）
从"候选代码"到"可召回 Skill"是一条准入链，先补全、再验证、再注册、最后管住变化：
- 先看补齐 Skill 组成——添加适用条件、输入输出、资料、工具、权限、执行方法和验收，让它能回答"何时用、如何证明完成"。
- 再看沙箱与任务集——跑正常、边界、异常、攻击任务，限制文件、网络、资源和凭证。
- 然后看注册与按需装载——正式版本进注册表，任务匹配后按需装载方法和工具，渐进装载减少上下文。
- 最后看依赖变化触发冻结——底层 API 或规则变了，停止新任务召回、保留历史证据，修订后重新准入。
逐层详解
第 1 步：补齐 Skill 组成
原文：添加适用条件、输入输出、资料、工具、权限、执行方法和验收。
白话：把候选能力补全成一个完整的 Skill，要加齐这些要素：什么时候适用、输入输出是什么、需要哪些资料、用到哪些工具、需要什么权限、怎么执行、以及怎么验收。
类比：像把一个"会拧螺丝的徒弟"升级成"持证上岗的技工"，不能只会拧，还得有"什么活能接、用什么工具、按什么流程、干到什么标准算合格"一套完整说明。
举例：候选的"Excel 转 JSON"能力，补全成 Skill 后要写清楚：适用条件（输入是表格文件）、输入输出（Excel 进、JSON 出）、需要的资料（字段映射表）、用到的工具（转换脚本）、需要的权限（读指定目录）、执行方法（跑脚本的步骤）、验收（输出 JSON 能通过 schema 校验）。
为什么重要：正式能力要能回答何时使用和如何证明完成。一个正式 Skill 必须能回答两个问题：一是"什么时候该用它"，二是"用完之后怎么证明它完成了"——这两个答不上来，就不是正式能力。
怎么验证（证据点）：
- 契约完整：输入输出、权限、前置条件都齐。
- 依赖清楚：依赖的库、环境、资料都清楚。
- 验收存在：有明确的验收标准/方法。
别踩的坑（边界）：文档完整不能替代实际运行。把文档写得再漂亮、再完整，也不能替代真的把它跑一遍——文档齐 ≠ 能跑。
落地检查：进入隔离验证。落地时补全组成后，下一步就是进入"隔离验证"（沙箱里跑），而不是直接上线。
第 2 步：沙箱与任务集
原文：运行正常、边界、异常和攻击任务。
白话：在沙箱里，用一套"任务集"来测这个 Skill：正常任务（常规输入）、边界任务（极端输入）、异常任务（报错情况）、攻击任务（恶意输入），四类都跑。
类比：像新车上市前的测试，不能只在平路上开，还要测烂路（边界）、测故障（异常）、测碰撞（攻击），全套过了才敢卖。
举例："Excel 转 JSON"的 Skill，正常任务=标准表格；边界任务=空表、超大表、特殊字符；异常任务=文件损坏、字段缺失；攻击任务=恶意构造的公式注入、路径穿越文件名。四类都跑通才算过。
为什么重要：通用代码必须限制文件、网络、资源和凭证。Skill 是要被反复调用的"通用代码"，它跑的时候能碰什么文件、能不能联网、吃多少资源、能不能碰凭证，都必须被严格限制，否则就是个安全隐患。
怎么验证（证据点）：
- 沙箱边界：文件/网络/资源/凭证的限制是否落实。
- 任务集结果：正常/边界/异常/攻击任务的结果如何。
- 资源记录：运行时消耗的资源有记录。
别踩的坑（边界）：测试全绿不证明未来依赖永远稳定。所有测试都通过，只能证明"现在这个版本、现在这些依赖下是好的"，不保证它依赖的库/环境以后不变。
落地检查：记录版本和适用范围。落地时要记录这个 Skill 的版本号和适用范围（在什么环境、什么依赖下有效），为将来的冻结和治理做准备。
第 3 步：注册与按需装载
原文：正式版本进入注册表，任务匹配后装载方法和必要工具。
白话：验证通过的 Skill，它的"正式版本"进入一个注册表（Registry）；当有新任务时，先做"任务匹配"，匹配上了才按需装载这个 Skill 的执行方法和它必要的工具，不匹配就不装。
类比：像公司的人才库，通过了考核的员工登记进册，来了具体项目才"按需调人"，而不是把所有人天天叫到办公室干等。
举例："Excel 转 JSON"的正式 v1.0 版本进注册表。新任务来了，系统先判断"这个任务是不是表格转换类"，匹配上了才装载转换脚本和方法，没匹配（比如任务是发邮件）就根本不装载它。
为什么重要：渐进装载减少上下文和动作空间。按需装载而不是一次性把所有 Skill 都塞进上下文，能减少上下文占用、缩小 Agent 的动作空间，让它更聚焦、更不容易乱调用。
怎么验证（证据点）：
- 版本 active：当前激活的是哪个正式版本。
- 条件匹配：任务是通过条件匹配才装载的，不是瞎装。
- 工具按需：装载的工具是必要的，没有多余。
别踩的坑（边界）：模型名称相似判断不能替代契约匹配。不能靠模型"看名字觉得像"就去装载某个 Skill，必须靠契约/条件来匹配——名字像不代表适用。
落地检查：注册表决定可发现版本。落地时"哪个版本能被发现、被召回"由注册表说了算，注册表里只有 active 的版本才对外可见。
第 4 步：依赖变化触发冻结
原文：底层 API 或规则变化后停止新任务召回，保留历史证据。
白话：当 Skill 依赖的底层 API 或业务规则变了，这个 Skill 的代码可能没改、但已经失效了——这时要"冻结"它：停止让新任务再召回它，但保留它过去的历史证据（审计记录）。
类比：像一张地图，路改了（底层变了），地图本身没画错，但它已经不准了，这时要把它下架（停止使用），但留档备查（保留历史）。
举例：Skill 依赖的订单 API 从 v2 升级到 v3，返回字段变了，Skill 代码没动但已经对不上。这时冻结该 Skill：新任务不再召回 v1.0，但保留它历史上执行过的记录和证据。
为什么重要：能力未改代码也可能因依赖失效。一个能力，代码一行没改，也可能因为外部依赖（API、规则）变了而失效——所以不能只看"代码变没变"，要看"依赖变没变"。
怎么验证（证据点）：
- 依赖变化：能确认是哪个依赖发生了变化。
- 版本 frozen：该版本已被标记为 frozen（冻结）。
- 安全路径可用：有安全路径（替代方案/回退）可用。
别踩的坑（边界）：冻结能力版本不等于删除已有任务和历史审计证据。冻结只是"停止新召回"，不是把历史任务和审计证据一起删掉——历史证据要保留，删了就没法追溯。
落地检查：修订后重新运行准入测试。落地时冻结后要修订这个 Skill（适配新依赖），修订完必须重新跑一遍准入测试，通过了才能有新的 active 版本。
落地可行性小结
本场景涉及的核心技术栈：Skill（可验证的方法制品）、契约（contract）、沙箱（sandbox）、任务集（正常/边界/异常/攻击）、注册表（Registry）、按需装载（lazy loading）、冻结（freeze）、审计证据（audit trail）。
真实落地要检查的事：
- Skill 必须补全"适用条件/输入输出/资料/工具/权限/执行方法/验收"，缺一不可。
- 沙箱要限制文件、网络、资源、凭证，用正常/边界/异常/攻击四类任务集验证。
- 注册表只暴露 active 版本，装载靠条件匹配，不靠模型"猜名字"。
- 依赖变化要触发冻结：停新召回、留历史证据、修订后重新跑准入。
常见坑：
- 把 Skill 当成 Prompt 模板或单个 Tool，只写了段提示词就上线。
- 测试全绿就以为"永远稳"，没管依赖变化。
- 按需装载没做条件匹配，让模型"看名字觉得像"就装载。
- 冻结时把历史审计证据一起删了，导致无法追溯。
回顾
- Skill 是可验证的方法制品，不是 Prompt 模板，也不是单个 Tool。
- Skill 组成要补全：适用条件、输入输出、资料、工具、权限、执行方法、验收。
- 沙箱必须限制文件/网络/资源/凭证，用正常/边界/异常/攻击任务集验证。
- 注册表决定可发现版本，装载靠条件匹配，渐进装载减少上下文。
- 依赖变化要触发冻结：停新召回、留历史证据、修订后重新准入。