企业官网建设流程全解析

1. 从一次翻车说起：为什么我要做这场对照评测

去年年底，团队里开始流行给 Agent 挂 Skill。那阵子几乎每周都有人往共享仓库里塞新的 skill 目录，命名五花八门，从codex-paper-skill到gis-spatial-analysis-skill，再到各种内部工具封装。大家的默认假设很朴素：能力越多，Agent 越强。直到有一次线上任务，一个原本能稳定跑通的文档处理流程，在挂载了三个新 Skill 之后开始频繁跑偏——该调工具的时候它在闲聊，该输出结构化结果的时候它开始写散文。

这件事让我意识到一个问题：给 Agent 装上 Skill，结果真的变好了吗？这个问题听起来像废话，但如果你真的做过 agent 开发，就会发现它一点都不显然。Skill 不是免费的午餐，它占用上下文、改变决策分布、引入新的失败模式。你以为是加法，实际可能是乘法，甚至是减法。

所以我决定做一次正经的对照评测。不是那种"我试了一下感觉不错"的玄学评测，而是控制变量、可复现、有量化指标的对照实验。这篇文章就是这次评测的完整记录，包括我踩过的坑、用到的评测框架、以及最后得出的那些反直觉结论。如果你正在做 agent 架构、agent skill 教程相关的工作，或者只是好奇 Claude Skills、skill-creator 这类东西到底值不值得上，这篇应该能帮你省下不少试错时间。

先说结论方向，免得你看到一半才发现不是你要的：Skill 在特定条件下确实能显著提升 Agent 表现，但在另外一些条件下，它会成为纯粹的负担。关键不在于"要不要装"，而在于"装什么、装几个、怎么装"。下面我把整个评测拆开讲。

2. 评测设计：怎么才算一次"公平"的对照

2.1 核心变量与控制组设置

做对照评测最怕的就是变量失控。我见过太多所谓的"评测"，实际上是 A 组用了新 prompt、B 组用了旧 prompt，然后得出结论说新方案更好——这根本不叫对照，这叫自欺欺人。

这次评测我锁死了几个变量。第一，基座模型固定，全程用同一个版本的模型，不做任何切换。第二，任务集固定，我准备了 60 个任务，覆盖四类场景：结构化信息抽取、多步工具调用、长文档问答、开放式创作。第三，评测脚本固定，用同一套打分逻辑跑所有组。第四，温度参数固定，统一设为 0.2，减少随机性带来的噪声。

控制组是裸 Agent，也就是不带任何 Skill 的基础 agent，只有系统提示词和基础工具集。实验组我分了四档：

• A 组：挂载 1 个高度相关的 Skill
• B 组：挂载 3 个相关 Skill
• C 组：挂载 3 个相关 + 2 个弱相关 Skill
• D 组：挂载 8 个混合 Skill（模拟真实项目里"什么都往里塞"的状态）

这样设计的原因是，我想回答的不只是"Skill 有没有用"，而是"Skill 数量和相关性如何影响效果"。很多团队的问题不是没装 Skill，而是装太多、装太杂。

2.2 任务集与评分维度

任务集的设计直接决定评测的可信度。我刻意避开了那些"Skill 天然占优"的任务，比如"请调用某个特定工具"，因为这种任务裸 Agent 本来就做不了，测出来没意义。我选的任务都是裸 Agent 理论上也能完成，但 Skill 可能让它做得更好或更差的类型。

评分维度我用了四个：

这里要特别说一下输出稳定性。这是最容易被忽略、但在生产环境里最致命的指标。一个 Skill 如果让 Agent 平均分提高了 5 分，但方差翻了一倍，那它在生产环境里就是灾难。我见过太多 demo 阶段表现惊艳、上线后天天出幺蛾子的 agent 项目，根源都在这里。

2.3 评测工具链选型

工具链这块我纠结了很久。市面上的 agent 评测框架不少，但大多要么太重、要么太轻。最后我的方案是：自建轻量评测 harness + 现成打分模型。

harness 部分我自己写了一个 Python 脚本，核心逻辑就是批量跑任务、记录 trace、调用打分、汇总统计。之所以不用现成的 agent 框架自带的评测模块，是因为那些模块往往和框架本身耦合太深，换个 agent 实现就跑不了。自建 harness 的好处是解耦——Agent 怎么实现我不管，只要能吐出一个标准格式的 trace，我就能评。

打分部分，客观任务（抽取、工具调用）用规则匹配，主观任务（创作、问答）用一个独立的打分模型，并且做了人工抽检校准。这里有个经验：永远不要完全信任自动打分，尤其是主观任务。我抽检了 20% 的样本，发现自动打分和人工打分的一致率大概在 85% 左右，剩下 15% 的偏差主要集中在"看起来对但实际跑偏"的案例上。

3. Skill 到底改变了什么：机制层面的拆解

3.1 Skill 不是工具，是"决策先验"

很多人把 Skill 理解成"给 Agent 加了个工具"，这个理解是错的，至少是不完整的。工具是能力，Skill 是决策先验。

打个比方。工具像是给一个厨师多配了一把刀，他能不能用、什么时候用，取决于他自己的判断。而 Skill 更像是给他塞了一本"遇到川菜就先用这把刀"的小册子。它改变的不是能力边界，而是在能力边界内的选择倾向。

这个区别非常关键。因为一旦你理解了 Skill 是决策先验，你就能理解为什么它会"让结果变差"——如果这个先验和实际任务不匹配，Agent 就会在错误的时机做出错误的选择。我评测里 C 组和 D 组表现下滑，核心原因就是这个：弱相关 Skill 引入了错误的决策先验，把 Agent 往沟里带。

从机制上看，Skill 主要通过三条路径影响 Agent：

• 上下文注入：Skill 的描述、示例、约束会被塞进上下文，占用 token 的同时也改变了模型的注意力分布
• 路由引导：Skill 的触发条件会影响 Agent 在"直接回答"和"调用能力"之间的选择
• 格式约束：很多 Skill 会规定输出格式，这既是好事（稳定）也是坏事（僵化）

3.2 上下文预算：被低估的隐形税

这是我在评测里最想强调的一点。Skill 是要交税的，税种就是上下文预算。

一个中等复杂度的 Skill，描述加示例加约束，轻松占掉 500 到 1500 token。挂 8 个 Skill，光 Skill 本身就可能吃掉 8000 token 以上的上下文。这意味着什么？意味着留给实际任务内容的预算被压缩了。

我在长文档问答任务上做了个对比。裸 Agent 处理一篇 3 万字的文档时，能塞进去的正文比例大概是 70%。挂载 8 个 Skill 的 D 组，这个比例掉到了 45% 左右。结果就是 D 组在需要跨段落推理的问题上，准确率明显下滑——不是因为它不会推理，而是因为它根本没看到足够多的原文。

提示：评估 Skill 收益时，一定要把上下文占用算进去。一个 Skill 如果只提升了 3% 的准确率，却吃掉了 10% 的上下文预算，那它在长任务场景下大概率是负收益。

3.3 触发时机：Skill 最容易翻车的地方

Skill 的触发逻辑是另一个重灾区。理想情况下，Skill 应该"该出手时才出手"。但实际评测里，我看到大量误触发和漏触发。

误触发是指任务根本不需要这个 Skill，但 Agent 还是按 Skill 的套路走了。比如一个"代码审查 Skill"，在纯文本总结任务里被触发，导致 Agent 开始用代码审查的口吻点评一段产品文案。漏触发则相反，任务明明需要，Agent 却没调用。

我统计了一下，在 B 组（3 个相关 Skill）里，误触发率大约是 12%，漏触发率约 8%。到了 D 组（8 个混合 Skill），误触发率飙升到 31%。这个数字很说明问题：Skill 越多，触发判断越难，误触发越频繁。

4. 实测数据：四组对照的完整结果

4.1 总体得分对比

跑完 60 个任务、每组重复 3 次取平均后，结果如下：

这张表信息量很大。A 组和 B 组明显优于裸 Agent，说明相关 Skill 确实有效。但 B 组相比 A 组，提升幅度已经很小了（综合分 81.5 vs 80.9），而 token 消耗多了 13%。C 组开始下滑，D 组直接跌到裸 Agent 以下。

最扎眼的是 D 组：装了 8 个 Skill，结果比什么都不装还差。这不是个例，我在不同任务类型上都复现了这个现象。

4.2 分任务类型的差异

总体分只是表象，分任务类型看才有意思：

规律很清楚。结构化抽取和多步工具调用这两类任务，Skill 收益最大，因为这两类任务对"决策先验"最敏感，Skill 能有效引导 Agent 走对路。长文档问答上，Skill 收益最小甚至在 D 组变成负收益，原因前面说了——上下文被挤占。开放式创作上，Skill 收益中等，但要注意它容易让输出变得"套路化"，这个后面细说。

4.3 稳定性：被忽视的关键指标

单独把稳定性拎出来说，因为它太重要了。裸 Agent 的稳定性是 81.2，A 组 84.7，B 组 82.3，C 组 76.8，D 组 68.4。

注意 B 组：它的平均分比 A 组高，但稳定性比 A 组低。这意味着 B 组的表现更"飘"。在生产环境里，我宁愿要一个稳定 80 分的系统，也不要一个平均 82 分但时不时掉到 60 分的系统。

D 组的稳定性 68.4 是个危险信号。我看了 trace，发现 D 组在相同任务上的行为差异极大——有时候调工具，有时候不调，有时候调这个，有时候调那个。这种不确定性在 demo 里看不出来，一上量就原形毕露。

5. 那些让我意外的发现

5.1 弱相关 Skill 的破坏力被严重低估

我原本以为弱相关 Skill 顶多是"没用"，占点上下文而已。实测下来，它的破坏力远超预期。

C 组比 B 组只多了 2 个弱相关 Skill，综合分从 81.5 掉到 76.2，掉了 5 分多。这 5 分不是均匀掉的，而是集中在那些"弱相关 Skill 可能被误触发"的任务上。一旦误触发，Agent 就会用错误的框架处理任务，结果往往比不处理还糟。

这背后的机制是：弱相关 Skill 增加了决策空间，但没有增加有效信息。Agent 面对更多选项，选择错误的概率上升，而正确选项的收益并没有增加。这就像给一个本来能选对路的人，硬塞了五张模糊的地图。

5.2 Skill 会让输出"去个性化"

开放式创作任务上有个现象很有意思。A 组和 B 组的得分确实比裸 Agent 高，但我人工读输出时发现，挂了 Skill 的版本，文风明显更"标准"、更"安全"，但也更无聊。

原因不难理解。Skill 为了稳定输出，往往会规定格式、语气、结构。这些约束在结构化任务里是优点，在创作任务里就成了枷锁。Agent 会倾向于"按 Skill 说的来"，而不是"按任务需要来"。

我甚至做了个极端测试：给一个创作任务挂上三个不同风格的写作 Skill，结果 Agent 的输出变成了三种风格的缝合怪，既不像 A 也不像 B，读起来非常别扭。这提醒我们：创作类任务上，Skill 要慎用，或者要设计得非常克制。

5.3 单个高质量 Skill 的性价比最高

如果只能记一个结论，那就是这个：一个精心设计的高相关 Skill，性价比远高于一堆普通 Skill。

A 组只挂 1 个 Skill，综合分 80.9，token 消耗 3450。B 组挂 3 个，综合分 81.5，token 消耗 3900。多花 13% 的 token，换来 0.6 分的提升。这个投入产出比，说实话不太划算。

所以我的建议是：先把一个 Skill 做到极致，再考虑加第二个。很多团队一上来就铺一堆 Skill，结果每个都做得半吊子，反而拖累了整体表现。

6. 怎么设计一个"不拖后腿"的 Skill

6.1 描述要精准，别写成说明书

Skill 的描述是触发判断的核心依据。我见过太多 Skill 描述写得像产品说明书，洋洋洒洒几百字，结果 Agent 根本抓不住重点。

好的描述应该回答三个问题：什么时候用、用来干什么、不用会怎样。而且要短。我的经验是，核心描述控制在 100 字以内，把最关键的触发条件放在最前面。

举个例子，一个"数据清洗 Skill"的描述，差的写法是："本 Skill 用于对各类数据进行清洗，支持缺失值处理、异常值检测、格式统一等多种功能……"好的写法是："当任务涉及原始数据、脏数据、格式不一致的数据时使用。负责缺失值填充、异常值标记、字段格式统一。纯文本任务不要用。"

看出区别了吗？好的描述有明确的触发边界和排除条件。排除条件特别重要，它能显著降低误触发率。

6.2 示例要少而精

Skill 里的示例是双刃剑。示例能帮 Agent 理解怎么用，但示例太多会占用大量上下文，还会让 Agent 过度模仿示例的具体形式。

我的做法是：每个 Skill 最多放 2 个示例，一个正例一个反例。正例展示理想用法，反例展示"看起来像但其实不该用"的情况。反例对降低误触发特别有效。

6.3 给 Skill 设"退出条件"

这是我从评测里总结出的一个实用技巧。很多 Skill 只写了"什么时候进入"，没写"什么时候退出"。结果 Agent 一旦进入某个 Skill 的框架，就一路走到黑。

给 Skill 加退出条件，比如"如果连续两次尝试都失败，放弃本 Skill 的流程，回到通用处理"，能有效减少"卡死在错误路径上"的情况。我在 B 组的基础上加了退出条件后重跑，稳定性从 82.3 提升到了 85.1。

7. 常见问题与排查速查

7.1 装了 Skill 反而变差，怎么排查

这是最高频的问题。排查顺序我建议这样：

7.2 怎么判断一个 Skill 该不该留

我有个简单的判断标准，叫**"三问法"**：

1. 移除这个 Skill，任务完成度会掉多少？掉不到 3 分，考虑移除。
2. 这个 Skill 占多少上下文？超过 1000 token 且收益不明显，考虑精简。
3. 这个 Skill 的误触发率多高？超过 15%，重新设计描述。

7.3 实操心得：先做减法，再做加法

最后分享一个我踩坑踩出来的经验。新项目不要一上来就堆 Skill。先用裸 Agent 跑通基线，记录每个任务类型的表现。然后针对表现最差的那一类，加一个 Skill，再测。有效就留，无效就撤。

这个过程慢，但稳。我见过太多团队为了赶进度，一次性挂十几个 Skill，结果出了问题根本不知道是哪个 Skill 的锅，只能全部推倒重来，反而更慢。

8. 关于 Skill 评测，我现在的做法

跑完这轮评测，我调整了自己团队的流程。现在我们的做法是：每个 Skill 上线前必须过一遍对照评测，没有例外。评测不用很复杂，20 个代表性任务、跑 3 次、看综合分和稳定性两个指标，就足够筛掉大部分"看起来有用其实拖后腿"的 Skill。

另外我把 Skill 的上下文占用也纳入了 review 清单。以前大家只关心"这个 Skill 能不能提升效果"，现在还要回答"它值不值这个 token"。这个视角的转变，帮我们砍掉了将近一半的低效 Skill，整体 agent 表现反而更好了。

Skill 这东西，本质上是在给 Agent 做"决策减负"。减得好，它跑得更稳更准；减得不好，你只是给它套了更多枷锁。评测的意义，就是让你知道到底是在减负还是在加锁。