企业官网建设流程全解析

给 Agent 装 Skill 已经快变成一种标配了。不管是用现成框架还是自己写脚本，大家都在往 Agent 里塞“技能”。但我做了半年 Agent 开发，发现一个问题：真正把“装 Skill 前后效果”拿数字量化的评测，少得可怜。所以我自己搭了一套对照评测，用同一个 Agent 框架、同一套模型参数，只切换是否安装 Skill，跑了上百次任务，覆盖目标型、泛化型和无关型三类任务。这篇文章会把整个评测思路、执行脚本、结果分析和踩过的坑原原本本写出来。如果你是 Agent 开发者、技术负责人，或者正好纠结“要不要给 Agent 装 Skill”，这篇应该能给你一些实在的参考依据。

1. Agent 与 Skill：先把概念对齐，再谈评测

1.1 我给 Agent 和 Skill 下的定义

在聊评测之前，得先把概念说清楚，不然很多争议其实是在鸡同鸭讲。我这里说的 Agent，不是单纯的聊天机器人，而是具备“感知-规划-行动-观察”循环的程序。它拿着大模型的推理能力，接上工具、记忆、任务上下文，去完成一个比较具体的目标。Skill 在这套体系里，我习惯叫它“可插拔能力包”。它不是一个简单的 function，而是把“触发条件、使用流程、提示词、工具组合、兜底策略”打包在一起的东西。你可以把 Skill 理解成一个游戏里的“武学秘籍”：秘籍里不仅写了招式，还写了什么时候用这套招式、用完之后怎么收招。

为什么最近 Skill 概念这么热？很简单，大模型很聪明，但不可控、不稳定。Agent 在自由状态下，同一个任务跑十次可能跑出十种路径。省事的方式就是把一些反复验证过的好流程固化下来，让 Agent 在特定场景直接走那条高效路径，这就是 Skill 的价值。我见过很多种 Skill 的实际形态：有的是一个 JSON 描述加一段很长的 system prompt，有的是包含了几个工具调用序列的 YAML，还有的是嵌入到 Agent 框架里的代码模块。像之前看到有人做 GIS 空间分析 Skill，也有人把 SolidWorks 的操作流程封装成 Skill，都是这个套路。形态不重要，重要的是它确实改变了 Agent 在推理时的行为空间。

1.2 “Skill”和“Tool/插件”到底哪儿不一样

很多人会把 Skill 当成 Tool 来理解，但两者其实差得很远。Tool 是一个原子动作，比如“执行 Python 代码”“调用搜索引擎”“读取文件”，它本身不包含决策逻辑。Skill 则是把多个工具调用、业务规则、提示词模板和常见异常处理打包成一个“流程方案”。从用户视角看，Tool 是“扳手”，Skill 是“一份用扳手修汽车发动机的标准化作业手册”。

这组对比不是咬文嚼字，而是后面评测结论的基础。如果评测前不把 Skill 的定义锁定成“会改变 Agent 规划方式”，那测出来的东西很可能只是“多个工具的顺序执行”，并不能解释真实场景。我在社区里看到大量争论，最后发现甲方乙方说的根本不是同一个东西，所以这里必须提前对齐。

1.3 为什么我会想到做对照评测

过去我也踩过“听别人说好用就直接用”的坑。最开始我从社区下载了一个数据清洗 Skill，装上去跑任务，感觉流程好像更整齐，但没注意它偶尔会把不该清洗的字段也洗掉，而且一旦数据格式不常规，它反而比裸 Agent 更容易出错。最关键的是，没有人能告诉我：这个“好”好到什么程度，“坏”坏在哪些情况下。

所以我想，与其凭感觉，不如做一次严格的对照评测。把 Skill 当成一个“被测试的干预项”，用无 Skill 做基线，看它对不同任务的影响。这篇文章的评测结果未必能直接套到你自己的任务上，但整个方法和踩坑过程是可以复用的。

2. 评测方案设计：3 个关键点让对照结果可信

2.1 控制变量：除了 Skill，其他必须原封不动

评测最怕的是“变量没控住”。我见过有人对比两个 Agent，一个用比较强的商业模型，一个用开源模型，还说是“加了 Skill 所以效果更好”，这就完全不科学。我的做法是四条红线：

• 同一个 Agent 框架：我这里用的是一个基于消息循环的轻量 Agent，支持工具注册和 Skill 动态加载。评测期间框架代码版本锁死，不临时改逻辑。
• 同一个模型和同样参数：模型版本、temperature、top_p、max_tokens 全部固定。我用 temperature=0.2 作为主评测配置，目的是降低随机噪声；后面又补充跑了一组 temperature=0.7 的结果，用于观察真实场景下的稳定性。
• 同一个工具集合：无 Skill 组和有 Skill 组都能访问相同的内置工具，比如网页搜索、代码执行、文件读写。Skill 组额外加载 Skill，但工具底座不改变。
• 流程可重置：每个任务运行前强制清理 Agent 的内部状态和上下文，避免上一次运行残留影响下一次。

这样唯一的差异就是“是否安装了 Skill”，或者更准确地说，是“Agent 是否使用了 Skill”。这一步没有做扎实，后面所有数字都站不住。

2.2 任务集：不能只挑 Skill 擅长的题

任务集如果选歪了，评测就成了“在 Skill 的射程内打靶”，结果自然好看，但没有任何说服力。我最终把任务分成三组：

1. 目标任务组：例如“把这份 CSV 数据清洗后生成时序趋势报告”。这是我给数据分析 Skill 设计时就预期要覆盖的场景。
2. 泛化任务组：例如“给运营团队写一份周报总结”。这个和数据处理沾边，但 Skill 本身并没有专门为周报场景做过太多适配。
3. 无关任务组：例如“为用户生成一段自我介绍”。跟数据分析完全无关，用来测试技能误伤率。

为什么这组设计很关键？因为真实使用中你不可能保证每个问题都命中 Skill。我们必须观察“装 Skill 后，对泛化和无关任务的负面影响有多大”。实际测下来，泛化和无关任务的表现确实会变化，有的甚至会变差，这个后面细说。

为了减少随机误差，每个任务跑 8 次，记录每次的成功、失败、耗时和 token 消耗。最终是 30 个任务乘以 8 次乘以两组，一共 480 次运行。这个量级不算特别大，但已经足够看出趋势。如果你的算力有限，改成每个任务跑 5 次也可以，至少能看出方向。

2.3 评测指标：别只盯着“成功/失败”

一开始我的评测指标只有“成功还是失败”，后来发现太粗糙。比如任务完成了，但完成得很差，算法把那当成成功，会把 Skill 的真实收益拉平。所以我最终用了四类指标：

• 任务完成率：Agent 是否给出了一个可以被用户接受的最终答案。需要提前定义“可接受”的规则，比如“要有结构化输出”“必须包含关键字段”，否则主观性太强。
• 质量打分：让两个评分员盲评，1-5 分。代码任务直接看能否运行、通过单测；文本任务看结构、逻辑、信息覆盖率。盲评时把 A 组和 B 组的输出混在一起，只标任务编号，不标有没有 Skill，打分后再解开分组。
• 过程指标：平均耗时、token 消耗、工具调用次数、重试次数、步骤数。这些能说明 Skill 到底是不是“更高效”。
• 严重错误率：单独记录数据算错、逻辑跑偏、生成安全红线内容等低概率但高影响事件。低频错误在中位数统计里容易被淹没，必须单独列。

为什么要费劲做盲评？因为我自己写这个 Skill，心里天然偏向“它应该有用”，打分时会不自觉给带 Skill 的输出更高分。盲评能把这个心理暗示压下去。这套机制成本不高，但能明显提高结论可信度。

2.4 Skill 生效检测：别让评测变成自欺欺人

这是很多评测忽略的点。你装了个 Skill，但 Agent 真的用它了吗？如果 Skill 只是被塞进了 system prompt，而 Agent 完全忽略它，那你实际上测的是“多了一段提示词”的效果，不是 Skill 机制的效果。

我的检测方式是在 Agent 的回调里记录每一步的 plan 和 tool_call，并且要求 Skill 在使用后必须输出一个特定标记。例如数据分析 Skill 的末尾有一句话：“当你使用本 Skill 完成分析时，请在第一段输出前添加 SKILL:data_analyzer_v2”。每次试跑后我解析日志，如果完全没有出现这个标记，就判定为“未生效”。这类运行我单独统计，和“生效但执行失败”分开。

第一次评测时，我以为 Skill 会大幅提升，结果跑完发现无 Skill 和有 Skill 差异很小。一查日志，40% 的运行 Agent 根本没触发 Skill，原因是一些任务里它认为用普通工具就够，不需要走完整流程。后面我把 Skill 的触发描述改得更明确，才真正让 Agent“用起来”。这个发现本身就很值钱：装了不等于用了，评测如果不追踪生效路径，很容易得出错误结论。

3. 评测结果解析：数字不会说谎，但看数字要带脑子

3.1 总体结果：先放一张表

这是我这一轮评测的部分汇总数据，直观感受一下差异：

目标任务上提升非常明显，完成率从 52% 提高到 78%，耗时下降 24%，token 也节省约 11%。这符合预期：Skill 把 Agent 拉到了更稳、更直接的流程上。但泛化和无关任务的完成率都出现下降，说明“装 Skill”不是免费的午餐。它会让 Agent 产生一种路径依赖，遇到沾边但不完全匹配的任务时更容易生搬硬套。

这里必须强调：不能把这个结果当成“Skill 一定有用”的证明。正确解读是“在 Skill 覆盖范围内的高频任务，收益明显；在范围外，可能付出轻微代价”。后续所有判断都要基于这个边界感，而不是盯着 52% 到 78% 那一个数字激动。

3.2 拆开看过程：稳定性的提升和灵活性的损失

只看指标还不够，我翻了很多 trace 记录，挑两个典型案例说。

一个目标任务的典型流程：无 Skill 的 Agent 先自己写清洗代码，中途发现 CSV 有编码问题，又去查资料，最后在报告里漏掉了用户“忽略缺失值”的要求。带 Skill 的 Agent 进入流程后，第一步就检查编码和缺失值，然后按预设步骤处理，最终报告结构完整。虽然偶尔有点机械，但结果稳定，这就是 Skill 带来的正面价值。

再看一个泛化任务：任务是把运营周报总结成要点，但安装的是论文写作 Skill。带 Skill 组在总结时非要按摘要、引言、结论的格式来，内容本身没大错，用户真正想要的“要点式总结”却被冲散了，质量评分反而不如无 Skill 组。这说明 Skill 的“护栏”和“约束”是同一枚硬币的两面。评测的核心，就是找出这枚硬币在什么位置翻转。

3.3 成本核算：省 token 可能是一种幻觉

很多人宣传 Skill 时会说“因为减少思考，所以省 token”，这句话要分情况。Skill 本身会占用上下文。比如我的数据分析 Skill 描述加上示例大概 1500 个 token，每次对话都要带进去。如果一次任务原本只消耗 2500 token，那么安装后即使过程变紧凑，总 token 也很可能比原来高，因为固定开销还没被摊薄。

我做了个简单测算：当任务复杂到原始 token 消耗超过 4000 的时候，Skill 通常才开始真正“省钱”；低于这个临界点，装 Skill 反而更贵。这个临界点取决于 Skill 的长度和任务复杂度，你可以在自己的评测里用日志算出来。

还有一个容易被忽略的细节：同时装多个 Skill 时，如果所有 Skill 的描述都塞进 system prompt，上下文会线性膨胀，甚至导致 Agent 忽略核心指令。我在第二轮评测里试过同时装 3 个 Skill，结果 Agent 频繁串台，token 消耗比只装 1 个明显更高。更稳妥的做法是把 Skill 描述精简成“索引卡片”放在外部，等到 Agent 判断匹配了再动态加载完整内容，这种按需加载会友好很多。

3.4 这个评测能回答谁的问题

顺着结果聊一下影响范围。对不同角色的价值不太一样。

如果你是 Agent 框架开发者，这个评测会帮助你判断“Skill 插件机制”是否值得投入。我的结论是值得，但必须建设好生效检测和触发路由，不能只把 Skill 堆在那里。如果你是业务方，想为 GIS 分析、教学设计、SolidWorks 操作这类垂直场景做专用 Skill，我的建议是先跑一个小规模的目标任务评测。垂直场景重复度高，收益概率通常比较大。如果你是普通用户，这篇评测的意义在于：别把 Skill 当成魔法，它只是一套被验证过的流程沉淀。它不会让本来能力不足的模型变强，只会让能力表现变得更稳定、更可控。

4. 实操记录：评测脚本和踩坑过程

4.1 一个可以直接改着用的评测脚本骨架

评测本身不复杂，核心就是循环跑任务并记录结果。这是我这套脚本里最核心的部分，去掉框架细节后大概长这样：

def run_case(agent, task, has_skill): agent.set_skill_enabled(has_skill) result = agent.run(task) return { "task": task, "has_skill": has_skill, "completed": result.completed, "steps": result.steps, "tokens": result.tokens, "latency": result.latency, "used_skill": result.used_skill } def evaluate(agent, tasks, n_runs=8): rows = [] for task in tasks: for has_skill in [False, True]: for i in range(n_runs): r = run_case(agent, task, has_skill) if has_skill and r["used_skill"] is False: r["note"] = "skill_not_triggered" rows.append(r) return rows

实际使用时，我会把 agent.run 改成你自己的框架调用，并且把 JSON 输出落盘，后面再用 pandas 或 Excel 分析。注意每跑完一个任务后要重置 Agent 状态，避免上下文污染。如果你用现成框架，还要确认工具注册表一致，别让无 Skill 组漏了某个工具，那就不算对照了。

4.2 我的评测脚本调整过三轮，原因都来自坑

第一轮，任务集全是我精心挑选的目标任务，结果无 Skill 50%、有 Skill 90%，当时我差点直接下结论“这个 Skill 真好”。朋友问了一句：“那你有我解决不了的任务吗？”我一愣，赶紧加了泛化和无关任务，结论就从“压倒性好”变成“有条件好”。所以任务集偏差是评测最隐蔽的坑。

第二轮，我重新实现了 Skill 加载，但没加生效检测。结果发现成功任务的输出和没装 Skill 的几乎一样，追日志才发现 Agent 经常忽略 Skill。原因是我只把 Skill 放进了可选工具列表，并没有形成强约束。后来我在 Skill 说明里写得更直接，又加了强制标记，才真正让 Agent“使用 Skill”。

第三轮，温度设置出了问题。我用 0.7 跑，方差非常大，每轮结果都不一样，根本看不出差异。改成 0.2 之后，规律才变得清楚。但要注意，temperature=0.2 的结论对真实场景可能偏乐观，因为用户实际使用时温度往往更高。所以我又补跑了一轮 0.7，作为稳健性参考。如果你也想做评测，至少跑两种温度，看结论是否一致。

4.3 Skill 帮倒忙的三个经典场景

经验都是踩出来的，我遇到这三个坑最为典型。

第一个，Skill 抢答无关任务。比如 Agent 装了代码生成 Skill，用户问“怎么安慰刚失恋的朋友”，Agent 居然用“明确需求、拆解问题、输出方案”的结构来回答，听起来很滑稽，但确实会发生。原因就是触发条件写得太宽，导致误匹配。解决办法是给 Skill 增加严格的意图门控，比如只有用户明确要求写程序时才触发。

第二个，Skill 里写死过时流程。最常见的是 API 版本更新，Skill 还在调用旧接口。有 Skill 的 Agent 反而比无 Skill 更糟，因为它过度信任 Skill，会拒绝尝试新工具。这提醒我们，Skill 需要版本管理，评测前也一定要确认 Skill 里的工具调用和当前工具集合同步。

第三个，多个 Skill 重叠后互相干扰。比如“数据分析 Skill”和“图表生成 Skill”都要求处理可视化，Agent 可能做两遍，也可能输出格式冲突。解决方式是在 Skill 元数据里定义优先级，并让 Agent 在“路由”阶段只激活一个。如果所有 Skill 都同时生效，评测时你会看到很多莫名其妙的结果，但其实不是模型问题，是编排问题。

4.4 让 Skill 真正有效的几个调参心得

写 Skill 时，不要只写“你要做什么”，一定要写“你什么时候不要做什么”。我在 Skill 末尾加过一句“若当前输入不属于典型应用场景，请忽略本 Skill 并采用常规推理”，这句回退指令能把泛化任务的误用率压下去不少。

给 Skill 加 few-shot 示例比写一堆规则更有效。尤其是“边界输入”的失败示例，能帮 Agent 理解什么情况下不该用。这有点像给人做培训，光讲工作流没感觉，多举几个反例立刻清醒。

Skill 要做到可观测。让 Agent 在输出中留下使用标记，甚至输出“我使用了哪个 Skill、哪一步”，复盘时才能看清问题出在匹配、执行还是输出。还有，建议用版本化 Skill ID。下次改 Skill，ID 可以不变，但 version 一定要变，因为测评需要追踪是哪个版本的改动导致指标变化。

5. 到底该不该给 Agent 装 Skill：我现在的判断标准

5.1 值得装 Skill 的三类场景

根据评测结果，三类场景收益最明显。

高频重复、有固定流程的任务。比如日报生成、特定格式报告、数据管道清洗，这类任务只要固化一个最优流程，每次运行都能吃到稳定性的红利。需要领域知识但模型本身不熟悉的任务。比如 GIS 空间分析、SolidWorks 操作、备课话术生成，Skill 可以把专业步骤“搬运”进 Agent 的思维，等于给模型装了一个领域外脑。对输出一致性要求很高的任务，比如客服回复、合规审查，用户不希望每次生成的风格或语气都不一样，Skill 就是统一话术。

5.2 先别着急装 Skill 的三类情况

任务高度开放、依赖创意的场景，装 Skill 反而会约束住思路。模型指令遵循能力不强的时候也不适合，复杂 Skill 会被忽略或曲解，导致“装了还不如不装”。还有一种是触发边界还没想清楚的场景，与其做一个宽泛的 Skill，不如先做一个小闭环，只在精准场景使用。

我见过不少人一上来就想做一个“全公司通用 Agent Skill”，结果十个任务里八个触发不了，两个误触发，最后骂框架不好用。其实问题不在框架，在边界定义。

5.3 如果从头再做一次，我会怎么做

如果让我重新来一遍，我会先把“评测集”建好，再写 Skill。很多人把顺序搞反，先写了一个“看起来很全面”的 Skill，再随便找几个任务验证，自然效果不好。

我会先收集业务中最常出现的 20 个任务，给每个任务标类型；再用裸 Agent 跑一遍，记录基线；然后针对表现最差但重复度最高的任务设计 Skill，再跑同一套任务集，对比差值。这样做每一步都有数据支撑，而不是凭感觉加技能。Skill 不是越多越好，而是越准越好。装一个 Skill 就像给员工发一份 SOP，SOP 写得再全面，也架不住员工乱用。

写这篇文章的时候，我又把手里几个新 Skill 翻出来试了一遍，结果和第一次评测又有了变化。我自己最大的体会是：Agent 的能力进化，不取决于你装了多少 Skill，而取决于你能不能发现“哪些流程值得固化成 Skill”。对照评测不是一次性的工作，而是一种习惯。每次换模型、改模块，我都会把固定的那组任务重新跑一遍，几十行脚本就能做到。

如果你也在做 Agent，我建议别光听宣传，先搭一个自己的小评测集。哪怕只有 10 个任务、跑 5 遍，也足够帮你把“感觉”变成“数据”。在这个领域，谁先建立稳定的评测习惯，谁就更容易把 Agent 做成真正可靠的工具。