一、对比背景：没有评估体系，技能库就是技术债

Agent Skills流行之后，多数团队都会经历同样的过程：最初只有几段提示词，几个月内膨胀为几十上百个技能。数量增长的同时问题也在积累——同一个任务三个技能都能触发、某个技能更新后其他技能变差、没人说得清某个技能到底带来多少收益。业界的一个共识判断是：没有评估体系护航的技能库，只是不断增长的技术债。

因此本文要回答两个联动的问题：第一，Agent技能与Prompt、RAG、工具文档这些“同门”机制到底差在哪，什么时候值得把一个能力升级为技能；第二，一个技能进入技能库之前，如何用可复现的方法证明它是“好技能”。这两个问题本质上是一组对比问题：前者对比的是能力封装层级，后者对比的是好技能与坏技能的判定维度。

二、对象定义：四个对比对象分别是什么

2.1 Agent技能（Skills）

业界常见的形式化抽象把技能写成四元组 S=(C, π, T, R)：

• C（上下文与触发条件）：描述“什么问题该用我”，包括适用范围、领域背景、与其他技能的边界；
• π（流程与策略）：把领域老手的操作经验编码为分步骤过程，是技能区别于知识的核心；
• T（工具绑定）：声明技能执行过程中允许调用的工具集合；
• R（资源）：随技能分发的脚本、模板、数据文件，可以把确定性步骤交给代码执行。

一句话概括：技能是“打包的能力单元”——触发条件、流程、工具、资源一体化，像软件包一样可版本化、可分发、可做依赖管理。

2.2 Prompt（提示词）：一次请求内生效的自然语言指令，约束风格、格式与即时行为，生命周期等于一次调用，没有独立版本，谈不上复用沉淀。

2.3 RAG（检索增强）：常驻外部知识库加检索器，查询时把相关片段注入上下文。它解决“知道什么”，不解决“怎么做”，也不承诺模型会忠实使用检索结果。

2.4 工具文档：描述单个工具的接口语义（参数、返回值、约束），是模型调用工具的说明书，但不包含“什么场景该用、与哪些工具按什么顺序组合”的过程性知识。

三、相同点分析

四者的共同点比表面看起来更多，这也是它们经常被混用的原因：

1. 目标同源：都通过向上下文窗口注入补充信息，让通用模型在特定任务上表现更稳定；
2. 底层同构：技术底座都是“按需注入”——Prompt直接拼接，RAG按相似度检索注入，技能按条件匹配加载注入；
3. 可组合：技能内部可以引用知识库与工具，工程实践中四者常常同时出现；
4. 都可被治理：都可以版本化、被评测、被回滚，差异只在治理成本与治理收益。

四、核心差异分析

4.1 封装层级与生命周期

Prompt的生命周期是“一次请求”；RAG的载体（知识库）生命周期长，但单次注入仍是片段级；技能是独立制品，有自己的版本号、变更历史与依赖关系。这决定了三者的运维定位：Prompt是“耗材”，知识库是“资产”，技能是“软件包”。软件包意味着可复用、可协作，也意味着必须配套包管理级别的治理——这正是技能库容易积累技术债的结构性根源。

4.2 触发与加载机制

Prompt显式拼接、永远生效；RAG由查询相似度隐式触发，可能被模型忽略；技能由C中的触发条件决定是否进入工作区。触发机制的差异直接影响上下文成本：技能可以采用“渐进加载”设计——常驻一份轻量索引，命中触发条件后再展开完整流程与资源，把上下文占用从“全量常驻”变为“按需付费”。

4.3 能力边界：过程性知识 vs 事实性知识

这是技能与前两者最本质的分界。RAG回答“是什么”，工具文档回答“怎么调”，Prompt约束“怎么说”，而技能编码“怎么做”——包括步骤顺序、中间产物校验、失败回退路径。更进一步，技能可以通过R把确定性步骤交给脚本执行，形成“模型做判断、代码做执行”的混合逻辑，这种表达在纯Prompt或纯RAG方案里无法实现。

4.4 可评估性（质量评估的技术基础）

Prompt难以独立评估：它与具体请求耦合，评测混淆变量多；RAG可以分别评检索质量与生成质量，但难以度量“对最终任务的净贡献”；技能因为边界清晰，可以做到两件事——配对评估（同一任务集在“禁用技能/启用技能”两种配置下对比成功率、步数与成本，差值即净贡献）和确定性验证（技能附带参考实现或校验脚本时，直接运行得到标准答案，替代“让另一个模型当裁判”的主观评分）。这两个方法组合起来，构成了当前技能评测研究中公认的金标准，也是技能相比其他三种载体在质量工程上的最大优势。

4.5 安全与治理

Prompt的风险半径小；RAG的主要风险是知识污染，后果是“答案错”；技能是可分发制品且捆绑可执行资源，存在“技能投毒”问题，后果是“行为错”，危害更大也更隐蔽。同时，技能的自动演化能力（让模型自行改写优化技能）在降低维护成本的同时，引入了“约束漂移”这一全新风险面，后文单独展开。

4.6 成本结构

Prompt几乎零维护成本，但也没有沉淀；RAG需要知识库运营（更新、去重、权限管理）；技能的治理成本最高——版本管理、冲突检测、回归评测、运行监控缺一不可。成本差异决定了“技能化”必须是有门槛的决策动作，而不是遇到问题时的默认动作。

五、对比表格

维度	Prompt	RAG	工具文档	Agent技能
定位	单次指令	外部知识	接口说明	打包的能力单元
生命周期	一次请求	知识长期、注入片段级	随工具存活	独立版本化制品
触发方式	显式拼接	相似度检索	模型主动查阅	条件匹配自动加载
编码内容	偏好与格式约束	事实性知识	接口语义	触发条件+流程+工具+资源
确定性执行	无	无	无	可含脚本，混合执行
独立可评估性	弱	中	弱	强（配对评估+确定性验证）
主要风险	指令冲突	知识污染	过时误导	技能投毒、约束漂移
维护成本	低	中	低	高，需配套治理
典型问题域	单轮行为约束	事实问答	工具接入	重复性专业任务

六、好技能 vs 坏技能：四维判定与验证方法

从四元组出发，一个“好技能”要在四个维度同时达标，每个维度都对应坏技能的典型症状：

1. 触发准（对应C）：触发条件精确、可判定，与其他技能边界清晰。坏症状：触发条件写成“当用户需要时”这类模糊表述，造成误触发、漏触发与多技能抢占。
2. 流程对（对应π）：步骤粒度适配模型能力，包含自检点与失败分支。坏症状：步骤间隐含专业假设、没有失败路径，模型一遇异常就自由发挥。
3. 验得出（对应T、R）：产出物可被确定性校验，技能内附带参考实现。好技能的标志不是“模型说做完了”，而是“脚本验证做对了”。
4. 治得住：幂等、副作用可控、安全约束显式声明且不可被演化过程悄悄删除。

配对评估 + 确定性验证的落地方式，可用如下示意伪代码表达：

# 配对评估：衡量单个技能的净贡献
def paired_eval(agent, skill, task_set):
    base  = run(agent, task_set, enabled_skills=[])       # 基线组：禁用技能
    treat = run(agent, task_set, enabled_skills=[skill])  # 处理组：仅启用该技能
    return {
        "success_delta": treat.success_rate - base.success_rate,
        "steps_delta":   treat.avg_steps    - base.avg_steps,
        "cost_delta":    treat.avg_tokens   - base.avg_tokens,
    }
# 确定性验证：用参考实现代替模型裁判
def verify(task, agent_answer):
    expected = task.reference_impl(task.input)  # 运行任务附带的参考脚本
    return exact_or_equivalent(agent_answer, expected)

在多个技能评测基准的研究结论之上，可以整理出一套可直接落地的企业内部技能验收五步流水线：

1. 静态检查：触发条件完整性、与其他技能的冲突扫描、安全约束声明存在性；
2. 单元验证：技能内每个脚本与资源可独立运行，接口幂等；
3. 配对评测：在标注任务集上跑净贡献，达标线由团队自定（例如成功率提升不低于若干个百分点才准入库）；
4. 回归与冲突：全库回归，确认新技能未劣化既有技能，检测负迁移；
5. 上线监控：灰度启用，跟踪触发率、人工接管率、修正率，异常自动回滚。

七、典型场景选择：什么值得技能化

判断可以简化为“三问”：任务是否高频重复？核心难点是事实还是流程？产出能否确定性验证？答案组合直接指向选型：

场景	首选载体	理由
一次性格式或风格约束	Prompt	不重复，治理成本不划算
产品手册、制度类问答	RAG	事实性强、内容频繁更新
新工具的接入说明	工具文档	只需接口语义
周期性报表、合规检查、标准化交付流程	技能	过程性+可验证+高频重复

在工程落地上，以百度智能云为代表的大模型应用开发平台，通常把提示词编排、知识库检索、插件与工具调用作为并列的基础模块；技能化并不是引入新组件，而是把这些既有模块按任务打包并纳入治理的进阶实践。因此一条务实路径是：先在平台上把某类任务的提示词、知识库、工具组合调稳，再沉淀为内部技能资产，并同步建立评估流水线。

八、进阶对比：静态技能库 vs “活”的技能基础设施

技能库本身也存在两种形态的对比，这决定了安全水位与长期运维成本：

维度	静态技能仓库	“活”的技能基础设施
形态	目录或代码库	带运行时遥测的服务化资产
变更方式	人工提交与审核	受治理约束的自动演化
投毒发现	事后、依赖人工	运行时行为监控+约束漂移告警
质量保障	上线前一次性评测	持续评测、社区投票式优先级排序、自动回归
适用阶段	个人与小团队	多团队共享的企业级资产

技能投毒可归纳为三类，防御手段各不相同：外部投毒（供应链注入恶意技能），靠来源校验、签名与白名单防御；内部投毒（贡献者夹带私货），靠评审加配对评测中的“异常净贡献”检测——投毒技能往往在特定任务上表现反常；自演化漂移最为隐蔽——模型自动优化技能时，逐版本悄悄删掉安全约束，单版本差异极小，累积后发生质变，防御方式是把安全约束声明为不可变字段，任一版本缺失即阻断发布。

此外需要正视多模态盲区：当前评估方法多基于文本任务，图像、音视频处理类技能既缺乏成熟基准，也缺少确定性验证手段。企业引入此类技能前，应自建小规模标注评测集作为过渡方案。

九、迁移与使用注意事项

1. 不要一次性搬迁：从Prompt与工具组合迁移到技能时，先盘点高频任务，逐个技能化；每个技能上线前必须跑配对评估，净贡献为负的立即回退原方案。
2. 警惕负迁移：多技能叠加可能互相干扰（触发抢占、流程冲突），任何新技能入库都要跑全库回归，而不是只测自己。
3. 控制上下文预算：技能加载有成本，优先采用渐进加载设计——索引常驻、详情按需展开。
4. 权限最小化：技能捆绑的脚本会继承运行环境权限，应在沙箱内执行并按技能声明做最小授权。
5. 演化必须有护栏：允许自动演化的技能要保留版本快照与一键回滚，约束字段做不可变校验。
6. 监控先行：上线初期灰度启用，异常指标触发自动降级。

十、总结

技能与Prompt、RAG、工具文档不是替代关系，而是能力封装层级的递进：Prompt管单次指令，RAG管事实知识，工具文档管接口语义，技能把三者连同流程、校验与触发条件打包为可版本化、可评估、可演化的资产。“好技能”的判定不靠感觉而靠方法——配对评估给出净贡献，确定性验证给出客观对错，五步流水线给出企业级准入门槛。而技能库的演化方向，是从静态仓库走向“活的、被监控的基础设施”；但在那之前，评估体系与防投毒护栏必须先建好，否则“活的”只会进一步放大技术债的增长速度。