企业官网建设流程全解析

做 Agent 开发的人应该都有过类似的体验：Skill 越攒越多，但哪个 Skill 真正靠谱、哪个该迭代、哪个干脆该删，基本靠感觉和拍脑袋。要么是线上跑挂了才反应过来，要么是换了模型后效果忽上忽下查不出原因。阿里最近开源的skill-up，就是冲着这个痛点来的——一款专门给 Agent Skill 做“体检”的评测工具。这篇文章我会从 Agent 与 Skill 的关系讲起，拆解 skill-up 的设计思路和核心评测逻辑，再带大家走一遍实际评测 Skill 的完整流程，最后整理一些我在技能工程实践中踩过的坑和排查经验，希望对正在做 Agent 项目的朋友有帮助。

1. 先搞清楚：Agent 和 Skill 到底什么关系

1.1 Skill 不是“插件的换皮”，它是一种能力契约

现在很多人一提到 Agent 的 Skill，下意识会拿“插件”来类比。这个理解方向没错，但如果只停留在“插件”这个层面，后面做评测、做优化都会很别扭。

我的理解是：Skill 的本质，是 Agent 和大模型之间的一种“能力契约”。它对 Agent 暴露的是一组可被调用的原子能力，比如“根据城市名查天气”“按关键词搜论文”“把一个 Markdown 文件转成 PDF”；对模型来说，Skill 在 prompt 层表现为一套清晰的使用说明，包括这个能力做什么、什么时候该用、参数有哪些约束、返回什么格式。插件强调的是“外部功能接入”，Skill 强调的则是“可被模型正确调用的能力边界”。

这个区别很重要。因为评测 Skill，本质是在评测两层东西：能力本身的执行质量，以及模型理解和调用这个能力的准确率。两层都是变量，如果不分开看，出了问题根本不知道是模型不会用工具，还是工具本身做坏了。

1.2 为什么 Skill 质量直接决定 Agent 上限

大模型本身的推理能力再好，落到具体任务上，最终还是要靠 Skill 去接触真实世界的数据和操作。一个 Agent 能不能稳定完成“查资料—写报告—发邮件”这类串联任务，拼的不是模型有多聪明，而是每个环节的 Skill 有多稳。

一个典型的场景：你给 Agent 配了一个“网页内容抓取” Skill，单测的时候抓静态页面一切正常，但线上跑到需要登录的站点或者动态渲染的页面就直接返回空内容。这时候如果模型已经把这个 Skill 纳入了调用计划，那整个任务链都会断掉。更难受的是，这类问题往往是概率性的——不是每次都会失败，而是十次里挂两三次。没有评测工具之前，这类问题只能靠用户投诉和日志捞取去被动发现，周期长、定位慢。

所以结论很直接：Agent 的能力上限由模型决定，但能力的稳定性下限由 Skill 决定。评测 Skill，就是在守住这个下限。

1.3 Agent 做项目真的需要一堆 Skill 吗

这是最近群里热议的话题。我的答案是：需要，但要严重克制。

从任务覆盖的角度看，一个 Agent 承接的项目越复杂，需要拆解出的原子能力自然越多。比如做一个“行业研究报告生成器”，至少需要搜索、网页抓取、PDF 解析、表格生成、文档排版这几个基础 Skill，再往上可能还要接数据库查询、API 调用。一个都不行。但 Skill 多和 Agent 强之间绝对不能画等号，Skill 越多，模型在每一步做工具选择的难度就越大，评测和运维的成本也越高。

实际操作中，我非常建议大家遵循两个原则：

• 一个 Agent 的活跃 Skill 控制在 8 到 12 个以内。超出这个范围，模型频繁选错工具的概率会显著上升，评测报告里会看到大量“Skill 调用不匹配”类问题。
• Skill 要能“合并同类项”。“查天气”和“查空气质量”完全可以合成一个“查询城市环境信息”的 Skill，通过参数区分。Skill 的粒度越合理，Agent 越容易学得会、调得准。

Skill 不是越多越好，而是越贴越好。怎么判断“贴不贴”？这就是评测工具要回答的问题。

2. skill-up 的评测逻辑与设计思路

2.1 评测到底在测什么：五个核心维度

在用过几款评测工具之后，我觉得 skill-up 对评测维度的划分是相对清楚的一套逻辑。它至少覆盖了五个维度，这五个维度基本把 Skill 从“能用”到“好用”的差距都囊括进去了。

第一个是成功率，也就是 Skill 在限定条件下完成任务的概率。这个很好理解，但是要注意“完成”的定义得提前定好。比如一个“发送邮件” Skill，只要邮件发出去了就算成功，还是必须等收件方真正收到才算成功？不同定义下，结果可能差很多。

第二个是稳定性。同一个 Skill 用同样的输入跑十次，结果是不是一致的？有些 Skill 依赖外部服务，网络抖动、API 限流、第三方接口返回值变化都会让结果漂移。稳定性的价值在于它暴露了 Skill 对外部环境的敏感度，这是压力测试下最容易率先崩掉的环节。

第三个是质量分。成功率只回答“做了没有”，质量分回答“做得好不好”。同样是“摘要生成” Skill，一个输出是逻辑通顺的段落，另一个输出是关键词堆砌，两者都可以算作执行成功，但质量天差地别。质量分一般需要借助评测集里的标准答案或规则引擎来综合打分。

第四个是效率。包括端到端耗时和 token 消耗。现在团队都在控成本，一个 Skill 如果每次调用都要多烧几百个 token，日活一上来成本差距就是千级别以上的。评测工具如果能记录 token 消耗，就能帮我们精准找到那些“功能没问题但亏钱”的 Skill。

第五个是鲁棒性。换一种说法就是抗干扰能力。输入稍微不规范，比如日期格式从2025-01-01变成了1月1号，Skill 还能不能正常跑？第三方 API 返回了意料之外的字段，Skill 会不会直接抛异常？鲁棒性不够的 Skill，在真实场景里就是一颗定时炸弹。

2.2 评测集怎么来，结果怎么算

评测设计里最容易被忽略但其实最关键的，就是评测集的建设。没有一份够好的评测集，评测工具本身再强也发挥不出来。skill-up 这类工具的评测集，一般建议大家至少包含三类数据：

• 真实历史请求：从线上日志里抽样，这部分数据最贴近真实用户的使用习惯，覆盖面广，是评测集的底座。
• 人工构造边界用例：针对 Skill 的输入约束设计极端情况，比如空参数、超长字符串、特殊字符、并发调用等，目的是把 Skill 的弱点炸出来。
• 对抗性样本：故意构造容易被模型误解的请求。比如调用“删除文件” Skill 时，描述里加一些模糊表达“把那个不要的文档处理掉”，看看模型能不能正确映射到删除操作，而不是去调用“归档” Skill。

结果的计算逻辑，通用的做法是把单次评测拆成“执行是否完成”和“结果是否达标”两步。前者对应成功率，后者对应质量分。如果一次执行完成了但结果质量不达标，只算完成不算通过。这样能把那些“答非所问但强行返回”的 Skill 暴露出来。

2.3 为什么评测工具一定要“可复现”

我对评测工具的底线要求只有四个字：可复现。

不可复现的评测没有意义。你周一跑出来成功率和周五跑出来的不一样，如果排除不了是代码改动、数据漂移、还是环境变化引起的，那这个评测结果就无法指导任何决策。skill-up 在这方面的思路是尽量减少对实时外部服务的依赖，评测时可以通过 mock 第三方接口或者固定返回值来隔离外部噪音，跑出来的数据真正做到“同一条用例、同一个版本、同一组结果”。

我自己在实际使用中也有个习惯，每次评测前都记录下三个东西：Skill 的版本号、评测集文件版本号、评测环境的依赖锁文件。这三样信息缺一不可，没有它们，就算评测报告再漂亮，也无法定位回归问题。

3. 实操：用 skill-up 给 Skill 做一次体检

3.1 环境准备与快速起步

skill-up 的安装方式遵循常见的开源工具习惯。它通常是一个基于 Python 的命令行工具，通过包管理器安装即可。具体安装命令建议以官方 README 为准，这里分享几个安装和起步时容易忽略的点。

第一，准备好 Python 虚拟环境。这是老生常谈，但我真心建议别偷懒。评测工具往往要装很多依赖，直接装在全局环境里很容易和项目其他依赖打架，虚拟环境可以省掉很多后续麻烦。

第二，第一次运行建议先跑一个最小的示例 Skill，不要一上来就把自己的复杂 Skill 接进去。先把工具本身的流程跑通，理解配置项都有什么作用，再逐步替换成自己的内容，排查起来会轻松得多。

第三，确认是否有内置的 mock 服务或录制回放能力。这个对可复现评测非常重要，能大幅降低外部依赖带来的波动。

3.2 配置评测任务的三要素

评测任务的配置一般围绕三样东西展开：评测集、被测 Skill 的启动方式、评测后端的模型与服务参数。

评测集是第一步。常见的组织方式是维护一个包含多个用例的文件，每个用例至少包含：输入、期望输出或判定规则、用例类别。这里我强调一下“判定规则”的作用。有些场景我们能写出明确的期望输出，比如“返回的 JSON 必须包含字段 code 且 code 的值为 200”；但很多生成式任务没有标准答案，比如“根据材料生成一份摘要”，这时候就得靠规则来判分，比如检查摘要长度是否符合范围、是否包含关键信息点、有没有明显的重复语句。在设计判定规则时，量化指标越多越好，这样报告中呈现的质量评分解释性才更强。

被测 Skill 的启动方式也很重要。skill-up 一般支持直接加载 Skill 的入口函数或通过 API 方式访问。我的建议是优先走 API 方式，因为更贴近真实生产环境，评测结果更有说服力。但同时要保证环境隔离，评测的时候不能去操作生产数据，否则风险太高。

模型与服务参数主要影响评测成本。同一组评测用例在不同模型上跑，结果会有差异，甚至不同 temperature 参数都会导致结果不同。评测时务必固定参数，否则结果之间没有可比性。

3.3 跑完结果怎么看：读懂评测报告

评测跑完会生成一份报告，一般包含总体得分、每个维度的分项得分，以及每个用例的执行详情。很多人只看一个总分，这是浪费了报告里最有价值的信息。

我会按三步来读报告：

1. 先看分项得分。哪个维度拖了后腿，优先级就最高。比如成功率 98% 但效率分只有 60，说明 Skill 功能上是 OK 的，但耗时或 token 消耗有优化空间。
2. 再翻用例级别的失败记录。逐个看失败的输入是什么、Skill 返回了什么、错误出在哪一步。这个环节非常关键，它是定位 bug 的直接线索。
3. 最后看稳定性相关数据。如果某个用例在多次执行中结果不一致，报告里一般会有波动标记，这类问题就是典型的隐藏雷区。

3.4 评测场景的进阶玩法

当你对整个流程熟了以后，可以尝试一些进阶用法。

第一个是回归评测。每改一次 Skill，就把完整评测集跑一遍，确保没有改坏已有功能。这在团队协作中尤其重要，经常出现一个人改了 A 功能，B 功能悄悄挂掉的情况。回归评测跑得勤一点，这类问题就能在合入前被拦住。

第二个是多模型矩阵评测。同一个 Skill，分别用几款主流模型去评测，横向对比调用成功率和质量分。别指望一个 Skill 在所有模型上表现一致，实际结果经常是有些模型更擅长调用工具，有些更容易误解参数。带着评测数据去选型和优化 prompt，会更有依据。

第三个是评测集本身的分层。把用例按紧急程度或使用频率分层：核心链路用例每次必跑，边缘扩展用例每周跑一次，长尾用例每月跑一次。这样既能保证核心质量，又不会占用太多机器资源。

4. 评测结果不好怎么办：Skill 优化实战

4.1 失败样本归因，先分清是 Skill 的问题还是编排的问题

拿到失败的评测用例后，第一件事不是急着改代码，而是做归因。经常有这种情况：评测报告显示某个用例失败，但仔细看下来不是 Skill 的功能坏了，而是整个 Agent 链路里模型把参数传错了。比如模型调用“天气查询” Skill 时，把“城市”参数传成了“省份”，Skill 本身没问题，但它收到的输入就是错的。

归因时我习惯用一个很简单的判断方法：把出问题的输入直接通过脚本调用一次 Skill 的底层函数，绕过模型。如果函数自己执行正确，那问题出在模型对 Skill 的理解上，应该去优化 Skill 的功能描述和参数说明；如果函数自己也执行失败，那才是 Skill 的代码或依赖出了问题。这个区分能省掉大量无效排查时间。

4.2 常见翻车现场与修复方法

先整理一个我实测中高频出现的翻车场景表格，方便大家对照排查。

拿“参数传递总是错”来说，很多时候不是因为模型笨，而是参数定义太抽象了。举个实际例子，一个“生成图表” Skill 的参数如果叫type，可选值范围是数字 1 到 5，模型大概率会困惑；如果你把参数改成chart_type，可选值直接写bar, line, pie，再给一个示例值chart_type="bar"，模型基本不会出错。Skill 的 prompt 设计核心就是降低模型的理解成本。

4.3 Skill 的“最小可用集”经验

最后聊一个团队管理层面的经验：到底一个项目配多少 Skill 合适。

我的建议是先做减法再做加法。第一版只保留任务链路里真正绕不开的 3 到 5 个 Skill，用评测工具跑通核心链路，确保每一步的调用成功率和质量分都达标。然后在这个底子上逐步加 Skill，每加一个都要回答两个问题：这个 Skill 是不是现有 Skill 的变体？没有它，任务链路会不会断？

实测下来，多数常规的 Agent 项目，8 到 12 个 Skill 已经覆盖得很好了。超过这个数，评测报告里会出现一类新的失败模式——模型本身开始“选择困难”，频繁在相近的 Skill 之间选错。这时候不是继续堆 Skill，而是回过头合并、收敛。

5. 常见问题速查与避坑清单

5.1 评测过程中的高频问题

Q1：评测集用多少条用例合适？没有绝对标准，但经验上核心 Skill 至少要有 30 到 50 条用例，覆盖正常路径、边界路径和异常路径。用例太少，评测结果不具统计意义；用例太多，每次回归耗时和成本暴涨。建议分核心、扩展、长尾三层管理。

Q2：评测结果不稳定怎么办？先检查评测环境是否受外部网络或服务影响，优先用 mock 或录制回放隔离外部依赖。再检查模型参数是否每次都一致，比如 temperature、max_tokens 这些设置会直接改变生成结果。排除这两项后仍不稳定，大概率是 Skill 本身对外部环境敏感，需要在 Skill 内部做兜底。

Q3：一个 Skill 在开发环境评测全过，上生产就出问题，怎么回事？最常见的原因是开发环境和生产环境的依赖不一致。另一个原因是生产环境的并发量更高，触发了外部 API 的限流。建议评测时在测试环境里制造一定的并发压力，同时把依赖锁文件维护好。

Q4：评测报告显示质量分低，但功能看起来正常？这就要回头检查判定规则是不是太严格或者不合理了。比如生成内容长度限制设得过短，或者规则依赖了错误栏位。先把失败用例拎出来人工复核一遍，看是对结果误判，还是真的有质量问题。

5.2 评测工具使用中的额外提醒

用 skill-up 这类评测工具时，有几个坑提醒大家注意。

第一个是评测集污染。不要直接在评测集里混合真实用户敏感数据。评测集需要脱敏处理，否则存在隐私风险。建议在评测集生成阶段就建立脱敏流程，把身份证、电话、地址等字段替换成模拟数据。

第二个是过度拟合评测集。如果评测集长期不变，Skill 的开发会不自觉地“针对评测集调优”，看起来分数很高，但一遇到真实数据就原形毕露。建议每个月从线上日志中抽样补充评测集，保持数据的新鲜度。

第三个是忽略评测成本。跑一次完整评测集的算力和 token 成本不是小数，尤其是大模型矩阵评测场景。建议按频率分层执行，核心数据集高频跑，全量数据集低频跑，成本和风险之间取一个平衡。

5.3 团队落地 Skill 评测的三点建议

最后给想在公司内部落地 Skill 评测机制的朋友三个建议。

第一，把评测结果接入开发流程。不要把评测变成“上线的最后一步”，而是每次提交代码都触发一次快速评测，让开发人员在提交阶段就拿到质量反馈，尽早发现问题。

第二，建立评测基线基线版本化。每次评测完把报告和对应的代码版本、评测集版本、依赖版本一起归档。后面一旦出现线上问题，可以快速回溯是哪个版本引入了回归。

第三，让写 Skill 的人参与到判分规则制定里。判分规则如果只由平台同学写，很容易和实际场景脱节。外面写 Skill 模块的人最清楚哪些输出是不能接受的、哪些误差在合理范围内，他们参与进判定规则设计，评测结果才具备真正的业务指导价值。

关于 Skill 评测和技能工程，我试过的路子还有很多方向没聊透，比如 Skill 的动态加载、基于评测结果自动优化描述、多 Agent 场景下 Skill 的协作评测等，这些话题以后有机会再单独展开。如果你正在做 Agent 项目，我的建议是把 Skill 评测当成基础设施来建设，越早投入，后面的坑就越少。