2008年7月，苹果App Store上线，首批应用500个，一年后突破10万。后来人们把这一年称为“移动互联网的供给侧元年”，能力的生产者，第一次从科技公司转向了普通开发者。
十八年后，同样的曲线正在AI应用层重演，且门槛更低。截至2026年5月，仅SkillHub一家平台的Skill数量就突破5万个，距离Anthropic推出Agent Skills不过半年。这一次的生产者，甚至不需要是开发者，会用自然语言和AI交互就可以。
回看这场爆发的起点，是2024年11月Anthropic发布的MCP（Model Context Protocol，模型上下文协议）。它相当于给大模型行业立了一个“USB接口”，任何工具只要按MCP规范封装一次，就能被所有支持MCP的模型调用。协议发布时，官方仓库的参考实现只有100余个；到2026年初，全网MCP Server累计已突破2万个。
真正让生态再上一个量级的，是Anthropic随后推出的Agent Skills。如果说MCP Server是“开发者写代码做的工具盒”，Agent Skills则把工具盒进一步简化：一个文件夹，加一份SKILL.md说明文档，就是一个Skill。
这是过去一年AI应用层最被低估的一次基础设施变化：能力供给的主体，从开发者转向了普通用户。
但与之对应的“质量基础设施”几乎是空白。面对成千上万个Skill，用户能依赖的判断依据只有下载量和星标。这两个数字看不出Skill实际效果好不好、跑得稳不稳定、看不出它会消耗多少token、花费多少时间，更看不出它是否安全。
基于此，5月21日，腾讯科技、 SkillHub与腾讯玄武实验室联合发布 TRACE 严选框架，为快速增长但缺乏统一标准的 AI Skill 市场建立一套可参照的评测体系。它是一个包含安全扫描、no-skill对照实验、证据包审计、触发率测试、资源代价评估的系统性严选框架，也是国内首个面向Skill真实使用场景的严选评测体系。
作为媒体，腾讯科技将持续推动TRACE框架的行业认知和普及，并将基于该框架，以每月一期、每期 10 个 Skill 的节奏，产出“编辑精选”榜单，为行业提供优秀Skills的案例及实用参考。
作为平台，SkillHub以国内最丰富的技能池为样本来源，充分采纳业界通行的 Agent Skill 构建规范与设计，根据行业生态和技术演进，持续迭代 TRACE 评测体系。
腾讯玄武实验室作为腾讯旗下安全实验室，负责搭建自动化评估系统，尤其为 TRACE 评分中的 Effectiveness（效果增益）维度，通过对照实验、AI 沙盒环境等创新方式，给出立体评价。
TRACE严选的设计，把AI Skill的真实使用链路拆成一套可持续运行的严选机制：先看安全红线，判断 Skill 是否存在越权访问、数据泄露、远程执行、代码混淆等不可接受风险；再看运行证据和规范性，确认Skill是否能被稳定加载、运行、复现和审计；随后通过no-skill 参照组判断 Skill 是否真正带来结果增益；在测评中也会评估触发率和资源代价，判断它是否能在该用时被自然调用，以及这种提升是否值得用户付出额外上下文、耗时和工具调用成本。
它区别于单次体验测评、下载榜或单项 benchmark，更接近一套面向真实用户使用场景的Skill质量评估与推荐机制。
01
大模型的能力越来越强，我们为什么还需要Skill？
正式详细解读TRACE之前，需要先回答一个关键的问题。大模型的能力越来越强，我们为什么还需要Skill？
Skill可以解决三个问题：
第一，降低重复沟通成本。用户不用每次重新解释任务背景、质量标准和禁忌。
第二，提高结果稳定性。同一类任务可以按同一套流程执行，减少“跑三次三个结果”的概率性波动。
第三，让经验可以组织化。个人的使用经验可以被团队复用、评测、改进和版本管理。
所以，Skill是给 Agent 建立一套工作习惯。工具解决“能做什么”，Skill 解决“什么时候做、怎么做、做到什么标准”。
但是现实中我们要完成的任务、场景千差万别，每个Skill也千差万别。如何能够判断一个Skill是不是真的安全好用，成为现实中真实的痛点。同时，我们也重视Skill的多样性，绝对的打分体系并不能看出Skill的好坏排名。
因此，Skill框架选出的Skill首先保证它值得推荐，并通过雷达图，看出它基于Skill框架的相对强弱项，提供持续使用迭代的参考，但并不强调或给出具体的、绝对的评分。
02
TRACE严选五维全景
我们希望框架能回答一个更具体的问题：一个好Skill应该是什么样的？
T（Trust，安全可信）
衡量 Skill 在安全、合规和可控性方面是否可信，是整个评估体系中的红线维度。
该维度重点关注 Skill 是否可能引入依赖来源不明、系统命令滥用、外部通信与数据泄露、越权文件访问、指令干扰与提示词攻击、远程内容执行、代码混淆或隐藏逻辑等风险，并关注其他可能影响用户数据、系统环境或执行安全的潜在隐患。
R（Reliability，运行可靠）
衡量 Skill 在评测运行中的稳定性、可复现性和交付可靠性。
该维度重点关注 Skill 是否能在标准评测环境中正常加载和运行，运行过程是否稳定，输出是否完整，交付物是否可收集、可打开、可进入后续评审；同时关注是否存在超时、异常退出、工具失败、依赖缺失、产物缺失、路径错误或日志解析失败等影响评测有效性的问题。
A（Adaptability，场景适用）
衡量 Skill 是否适合其声明的使用场景，以及在真实候选环境中是否容易被正确识别和调用。
该维度重点关注：当用户请求落入某个 Skill 的适用范围时，agent 是否能够自然识别并加载目标 Skill；Skill 的名称、description 和触发描述是否足够清晰；当目标 Skill 与相近、边界、无关或通用兜底 Skill 同时可见时，是否仍能被正确选择。
C（Convention，结构规范）
衡量 Skill 是否具备清晰、可维护、可复用的结构基础。
该维度重点关注：SKILL.md 是否清楚说明用途、适用范围和触发条件；frontmatter 中的 name、description、requires 等元信息是否完整准确；脚本、依赖、附件、资源文件和目录结构是否组织合理；运行前置条件是否清楚；最终产物和中间文件是否有明确边界，避免把调试文件、过程文件或无关内容混入交付物。
规范性不是判断 Skill “写得是否漂亮”，而是判断它是否具备被理解、被运行、被评测、被复用和持续维护的基础。
E（Effectiveness，效果增益）
衡量 Skill 是否真正提升任务结果，以及这种提升是否值得付出相应代价。
该维度首先关注一条效果底线：启用Skill 后，结果必须明显优于no-skill参照组。如果装上 Skill 后与裸模型表现接近，甚至引入更多错误、复杂度或体验下降，则不具备推荐价值。
在此基础上，E 维度重点关注：任务是否真正完成用户需求；输出内容、推理、数据、引用、计算或操作结果是否正确可靠；交付物是否清晰、完整、格式合适，并能被用户直接使用；相较 no-skill 参照组，Skill 是否在完成度、正确性、效率、格式、稳定性或用户体验上产生实质改善；观察到的改善是否可以合理归因于 Skill，而不是模型本身能力、随机性、提示差异或外部因素。
同时，E 维度也关注这种改善是否值得付出代价，包括上下文占用、token消耗、执行耗时、工具调用频率和使用复杂度。如果结果提升有限，但代价明显升高，也不应被视为高质量 Skill。
03
测试方法：针对实用场景设计
TRACE 严选评测的核心，是从同一组真实任务出发，把“启用目标 Skill”和“不启用任何 Skill”的结果放在一起比较，再交由评审体系判断它是否真的带来了增益。
整个流程首先从 T 单独安全评测开始。T 对应 Trust，是 TRACE 体系里的红线维度。每个 Skill在进入效果评估前，都要先经过独立安全检查，主要识别权限、指令、工具调用、文件读写、网络访问、依赖包、隐藏行为等潜在风险。只有通过安全淘汰的Skill，才会进入后续任务测试；如果存在T0级别的安全问题，即使效果表现不错，也不会进入推荐评分。
安全评测之后，系统会为每个Skill生成 5 个任务包。每个任务包包含完整的prompt、必要附件和metadata，用来模拟真实用户会提出的需求。这一步的重点，是保证任务本身足够具体、可执行，并且能够检验Skill的实际作用，覆盖全该skill的典型使用场景。
接下来，同一个任务包会被拆成两组同时运行：一组是Skill组，启用目标Skill；另一组是参照组，禁用目标Skill，只依靠模型自身能力完成任务。两组使用相同任务、相同输入条件，目的就是把变量尽量压缩到“是否安装这个 Skill”上。
每个任务评测会进入专门的“沙箱环境”。这里的沙箱并不只是传统意义上用于防止不可信程序破坏系统的安全容器，它更重要的作用，是隔离历史状态对实验结果的污染。每次测试都会从相同初始状态开始，尽量避免上下文残留、工具调用历史、缓存、长期记忆、临时文件或环境差异影响结果。
换句话说，传统沙箱主要解决“程序会不会伤害系统”的问题，评测沙箱解决的是“实验结果会不会被历史状态带偏”的问题。它的核心目标是可重入、可复现和公平比较。
在同一个评测沙箱中，同一个任务包会被拆成两组运行：一组是 Skill 组，启用目标 Skill；另一组是参照组，禁用目标Skill，只依靠模型自身能力完成任务。两组使用相同任务、相同输入条件和相同初始环境，目的就是把变量尽量压缩到“是否安装这个 Skill”上。
运行结束后，系统会进入证据包审计。每次任务执行都会保存完整证据，包括最终回答、输出产物、运行日志、工具调用、错误信息、耗时、token 消耗和资源使用情况。审计环节会检查这些证据是否完整，Skill组和参照组是否可比，目标 Skill 是否按设定启用，参照组是否确实没有使用任何 Skill，以及运行中是否出现超时、异常退出、工具失败、产物缺失等影响判断的问题。
证据包审计通过后，才进入“客观证据 + 成对盲评”阶段。为了减少评审模型的幻觉和主观漂移，TRACE 严选不会把完整运行日志直接交给评审，而是先整理成最小必要材料包，只保留用户输入、必要附件、Skill 组产出和 no-skill 组产出，清理掉内部路径、调试信息、执行器日志和无关中间文件。
评审时，系统会使用旗舰模型模拟不同类型的专业评审角色，对同一任务下两组最终产出进行成对比较。评审重点包括完成质量、正确性、交付可用性、增益幅度、归因可信度和负向影响。换句话说，模型评审不是凭感觉给 Skill 打分，而是在同一任务、同一输入、两组产出的证据基础上，判断启用 Skill 后是否真的更好。
同时，TRACE 严选也会评估这种增益的成本。一个 Skill 如果只是让结果略微变好，却显著增加 token 消耗、执行耗时、工具调用次数和上下文占用，就不一定值得推荐。真正值得进入榜单的 Skill，需要在效果提升和使用代价之间达到合理平衡。
最终，评测会汇总为 TRACE 五维画像和推荐结论。它回答的是三个关键问题：第一，它是否安全、规范、可稳定运行；第二，它在真实任务中是否比不装 Skill 更好；第三，这种提升是否值得用户付出额外的上下文、时间和工具调用成本。只有同时通过这些判断的 Skill，才具备进入TRACE 严选榜单的基础。
04
为什么是“严选”榜单？
这个框架是经过客观评分及编辑精选的Skill榜单。
我们没有选“对所有Skill全量评分、出综合榜单”的路线。原因有两个：一是全量评分在工程上不可持续，每个Skill做多模型复测加专家盲评，资源消耗巨大；二是全量榜单容易被早期发布的头部Skill长期占据，新发布的高质量Skill很难突围。
所以我们选择每月一期、每期10个Skill的“编辑精选”模式。候选来源是SkillHub的热度信号加社交热度初筛，以收藏、点赞、下载作为热度指标，以时间为维度切片。
整体的评测流程为：热度初筛、底线筛选、安全扫描（红线层）、“TRACE”整体评测、人工盲评Effectiveness主观盲评分数、加权汇总加文章点评。
整个评测过程统一使用同一底层模型，并统一在Openclaw框架下完成测试。关于统一模型这一点，需要补充说明，模型能力强弱不是我们这次要评测的对象。统一模型加统一框架，是为了让六个维度的得分更纯粹地落在Skill本身上。
05
写在最后
还有几点十分重要的事情需要强调：
第一，这把尺子的公信力是日复一日累积出来的，不是发一份方案就有的。如果TRACES严选的Skill在用户实际使用中的体验和我们的评测结果存在系统性偏差，标签会很快失去价值。所以从第一期开始，我们会建立用户反馈回路，把实际使用数据与评测结果做对照，持续校准框架的有效性。
第二，热度初筛会有偏差。SkillHub的热度信号反映的是当前活跃用户的兴趣分布，可能在某些场景上密集、在另一些场景上稀疏。我们会在执行中观察是否需要叠加场景配额或主题轮转机制，让覆盖面更均衡。
第三，TRACES不会一稿定终身。模型在变、生态在变、用户对Skill的期待也在变。我们把这套框架称为“第一个成熟版本”，而不是“最终版本”，它会随着每期评测的执行持续迭代，权重、子项、评测方式都可能调整。
今天Skill生态正站在一个十字路口，但选择和维护的难度更大，因为Skill的“用户”不是人类，而是一个概率系统，模型的不确定性我们没法消除。
TRACES的字面意思是痕迹、轨迹、足迹。我们希望它的真正含义是，让好的Skill留下痕迹。这是我们打算持续去做的一件事。目前这个框架可能还不够完美，我们先抛出一个最初版本，也期待和行业一起持续共建。
最终，还有一个灵魂拷问，Skills会不会一直存在？模型能力越来越强，最初作为“模型补丁”存在的它，是否会完全消失？
答案是不确定。行业内有一句笑谈“人间才一日，AI 已千年”，没人敢去预测半年以后发生什么变化。但是，这件事在当下是有意义的。
我们认为，提供通用认知能力的skill会被模型内化。
但是组织流程、权限边界、行业标准、安全约束、可审计执行，必须作为外部化的skill而存在。未来，真正能沉淀为可信工作流的skill的价值会更高：稳定、可复测、可控权、可持续、能进入真实业务场景。
