企业官网建设流程全解析

说实话，我第一次认真研究 Agent 时，心里想的是“这不就是个能聊天的模型包装吗”。真正让我改变看法的，是在 Hermes 里把一个重复做了半年的工作流固化成了自定义技能。从那天起，我才意识到 Agent 和普通聊天工具之间的分水岭，不在模型多大、上下文多长，而在于你能不能把那些重复执行、固定指令模板的事情，变成一套可以被随时调用的能力。

Hermes 的自定义技能机制，解决的核心问题就是一件事：让 Agent 学会你希望它稳定复用的动作，而不是每次都在对话里重新教它一遍。如果你正在用 Hermes 做 Agent 开发，或者你已经受够了每天复制粘贴同一段提示词，那这篇文章值得你花十分钟看完。我会从技能机制的底层逻辑讲起，再带你手写一个能跑通的技能，最后把我调试技能时踩过的坑挨个说一遍。

1. 技能机制到底在解决什么问题

1.1 复制粘贴提示词的天花板

先还原一个我自己的真实场景。之前我在做服务巡检，每周五都需要汇总一周的服务状态、磁盘占用、错误日志，然后再按照固定格式写一份周报。最原始的做法是打开模型对话框，把日期、数据源、输出格式这些信息一次性粘贴进去，等它给我生成一段报告。

问题在于，这个流程里“固定”的部分远比我以为的多。输出格式必须跟团队模板对齐，风险等级的描述措辞有严格要求，甚至某些关键词不可以出现。这些约束每次都要在提示词里写一遍，只要哪次复制漏了一段，输出的格式立刻开始漂移。更别提不同周的数据源还要临时改来改去，整个流程既费时间又非常容易出错。

这套操作的本质是：把一段需要复用的流程，用对话的方式每次重新描述一遍。但凡模型没有严格按你脑子里的规则执行，你就要补充说明、再生成一次，循环往复。这其实就是提示词的天花板——它缺乏结构，没有被命名，没有参数接口，也谈不上稳定复用。

1.2 技能、提示词、插件与 Harness 的区别

很多人在接触 Hermes 这类框架时，会混淆几个常见概念：提示词（Prompt）、技能（Skill）、插件（Plugin）和 Harness。我在用了一段时间后，自己总结了一张对比表：

有个比较容易绕进去的问题是“Harness 和 Agent 到底谁是谁”。我的理解是：Agent 是那个做决策的大脑，它决定下一步要做什么、调用什么；Harness 是承载这个决策的运行时框架，它负责把 Agent 的决策翻译成可执行的步骤，并在每个步骤之间做状态管理。你可以把 Agent 当成一个员工，把 Harness 当成这家公司的管理制度和办公系统，而技能就是这个员工手里已有的标准作业流程（SOP）——遇到同类任务时，他不需要再从头想一遍怎么干。

把这三个东西分开之后，你就会发现技能处于一个很特殊的位置：它不是某个外部工具的适配层，而是“任务流程”的复用单元。工具是技能可以调用的资源，技能是用这些资源去完成一类任务的模板。

1.3 什么工作适合被固化成技能

不是所有任务都适合技能化。我在这上面吃过亏，一开始恨不得把什么都变成技能，结果反而把自己绕晕了。现在我评估一个工作流是否值得技能化，基本就看几条标准：

• 高频重复：这个任务你是不是每周、每天都干？一周只干一次、而且内容千差万别的事情，固化收益很低。
• 流程稳定：执行步骤是不是大致固定？如果每次执行顺序都变，技能内部的编排逻辑就没法沉淀。
• 输入输出明确：你能说清楚这个任务的输入是什么（日期、来源、参数）、输出是什么（格式、结构、审核标准）吗？
• 规则可描述：过程中的判断逻辑，比如什么情况算高风险、什么情况需要升级处理，能被写清楚。

符合这些标准的典型场景包括：日报周报生成、数据定期汇总、巡检报告输出、测试用例批量准备、固定格式文件转换等等。

反过来，那些天然依赖发散创意的任务，比如“帮我想一句品牌 slogan”或者“策划一个全新栏目”，我就建议你不要硬做成技能。因为这种任务每一次的需求差别太大，做成技能反而会限制模型的发挥空间。好的技能化候选对象，是那种你已经重复到快吐了的工作流。

2. 把技能定义拆开看：Hermes 自定义技能的构成与调用逻辑

2.1 一个技能的本质：函数化的任务模板

如果你写过代码，理解技能会非常容易。技能本质上就是一个“函数化的任务模板”——它拥有和函数几乎一样的组成结构：

• 技能名称：相当于函数名，用于在能力列表中唯一标识。
• 描述信息：相当于函数的 docstring，告诉模型这个技能是干什么的、什么时候该用。
• 参数定义：相当于函数签名，声明调用这个技能需要哪些输入。
• 执行步骤/提示模板：相当于函数体，定义拿到参数之后该怎么执行。
• 输出约束：相当于返回值规范，说明最终输出的结构和格式。

我见过很多人跳过“描述信息”这一步，直接写正文，这是非常致命的。在 Hermes 这类用大模型驱动调度的框架里，描述信息不是给人看的注释，而是给模型看的“索引”。模型每次收到一个用户请求，都会在技能列表中做语义匹配，匹配的依据主要就是技能描述。描述写得好，技能才可能被正确唤起；描述写得含糊，你做得再精细也白搭。

不同的 Hermes 版本对技能文件的具体格式可能会有些差异，但思路是通用的：一个目录代表一个技能，目录里包含描述文件、模板文件和可选的脚本文件。这种“一个目录一个技能”的组织方式，结构清晰，也方便用 Git 做版本管理。

2.2 Agent 如何发现并调用技能

技能机制最核心的设计，是“以语义匹配决定是否调用”。我来描述一下实际发生的过程：

用户输入请求后，Harness 会把请求和当前上下文一起交给模型。模型在规划阶段会看到一个当前可用的技能列表——注意，模型看到的不是你代码里的文件夹名字，而是每个技能 description 字段里的自然语言描述。它开始判断：“用户要求的事情，和哪个技能描述的场景吻合？”

举个例子，你的技能叫weekly_report，描述里如果只写“生成周报”，模型在犹豫要不要调用时，其实缺乏足够的判断依据。它可能会觉得“周报”这个词太模糊，不确定用户问的“帮我总结一下这周干了啥”是不是同一件事。但如果描述写的是“当用户要求汇总本周工作内容并输出包含概况、重点事项、问题风险、下周计划的周报时使用”，匹配成功率会大幅提升。

调用时，模型还会从对话内容中抽取参数。这个环节也很关键：参数的 number 类型、格式、默认值定义得越清楚，模型抽取就越准。Hermes 内部一般会把每个参数渲染成技能模板里的变量，再交给后续执行步骤使用。换句话说，参数定义的质量会直接影响整个技能的稳定性。

2.3 技能在执行循环里如何运转

技能本身是一个模板，但它真正跑起来，是在 Harness 的执行循环里完成的。这也是为什么理解 Harness 对用好技能很重要。

在 Hermes 里，技能很少是“一条提示词直接输出结果”那么简单的。更常见的情况是：Harness 先解析技能定义，把参数注入到模板中，然后生成一个执行计划；执行计划中的每一步都会经过观测、校验、记录；如果某一步出现异常，Harness 可以选择重试、跳过或者把错误信息反馈给模型，让模型决定下一步怎么办。

这种“带截断点和状态记录”的设计，给我带来的实际好处是：技能执行到一半出问题时，我可以通过日志清楚地看到是哪一步出的问题，而不是面对一个黑盒。我第一次调试技能时，看到日志里记录了完整的工具调用链，真的有种从“盲人摸象”变成“拿着图纸干活”的感觉。后面我会详细讲那个常见报错execution terminated due to error的排查思路，本质上就是要从这个执行循环的角度去定位问题。

3. 动手写第一个技能：环境准备、目录结构与参数化模板

3.1 准备一个适合调试的 Hermes 运行环境

在写技能之前，你需要有一个能跑起来的 Hermes。我自己的部署经验是：Docker 是最省心的选择。官方镜像会把大部分依赖问题都屏蔽掉，你只需要把本地目录挂载进容器，再把模型服务的 API Key 或者本地模型地址配置好就行。

如果你用的是 Windows，我建议优先考虑 Docker Desktop，WSL2 后端比较稳。纯 Windows 原生部署也不是不能跑，但依赖版本冲突会花掉你很多本不该花的时间。我第一次在 Windows 上折腾时，光是解决 Python 和 C++ 运行库的问题就耗了一个晚上，后来切到 Docker 容器，整个安装加启动不到十分钟。

另外，技能调试阶段我强烈建议你用一个成本可控的模型后端。比如把 DeepSeek 这类价格便宜、响应速度也够用的模型接进来，作为日常技能执行的主力。这样你在反复测试技能时，不用担心调用费用像流水一样出去。等技能逻辑稳定了，再切换到效果更好的大模型也不迟。

3.2 技能目录与注册方式

在你确定 Hermes 已经能正常对话之后，下一步就是找到技能目录。我习惯把技能目录理解成“插槽”，每个子目录就是一个独立技能。常见的结构大致长这样：

hermes-skills/ └── skills/ └── weekly-report/ ├── skill.yaml ├── prompt.md └── scripts/ └── format.py

skill.yaml里放的是元信息和参数定义，prompt.md是执行模板，scripts目录放辅助脚本。不同版本的 Hermes 对字段命名可能不一样，但“描述 + 参数 + 模板”的整体框架是通用的。你可以在自己的项目仓库里搜一下skills目录，看看自带的示例技能长什么样——最好的学习方式永远是先照葫芦画瓢。

注册方式一般有两种：一种是改了目录之后需要重启 Hermes 才能重新扫描技能列表；另一种是支持热更新，扫描命令或 API 触发后可以重新加载。我个人习惯在开发阶段用热更新模式，改完技能立刻测试，效率高出不少。

3.3 用周报生成场景写一个参数化技能

下面我用“周报生成”这个场景，给你展示一个技能定义的核心内容。注意，这不是某个固定版本的标准答案，而是一个通用范式，你落到自己环境时需要对照官方 Schema 微调。

name: weekly_report description: > 当用户要求汇总本周工作，并按周报格式输出时使用。 输入：本次周报覆盖的开始日期、结束日期、工作内容来源。 输出：包含本周概况、重点事项、问题风险、下周计划的周报。 parameters: - name: start_date type: string description: 本周开始日期 example: "2026-02-09" - name: end_date type: string description: 本周结束日期 example: "2026-02-13" - name: source type: string description: 工作内容来源，如 git 提交记录、会议纪要、项目管理工具 example: "git log" prompt: | 请基于以下信息生成周报： 周期：{start_date} 至 {end_date} 内容来源：{source} 要求按以下结构输出： 1. 本周概况：用 3-5 句话概括整体进展 2. 重点事项：逐条说明，附带进展状态和影响范围 3. 问题风险：列出当前阻塞或潜在风险，并给出等级 4. 下周计划：按优先级列出不超过 5 条

这里有几个设计上的关键点：

第一，description要写成“当……时候使用”的形式，而不是简单写“生成周报”。这能显著提高模型唤起技能的准确率。

第二，参数不超过 3 个，每个参数都提供了example。示例值对模型抽取参数有很大帮助，我实测下来，给了示例之后参数抽取的准确率能提升不少。

第三，prompt里用的是变量插值，执行时 Hermes 会把{start_date}等变量替换成模型抽取出来的实际值。这样技能模板就具备了参数化能力，而不是每用一次就要改一次文件。

3.4 测试技能的三段式验证

技能写完，注册成功，不代表它就能正常工作。我平时会把测试拆成三段，分别验证，这样出了问题能快速定位。

**第一段：参数抽取测试。**只测试模型能不能从用户输入里准确提取出 start_date、end_date、source 这三个参数。我会故意用很口语化的输入，比如“帮我写下周报，这周从周一开始到周五，内容看 git 最近一周的提交”。如果模型抽出来的参数不对，那就是 description 或参数定义有问题，跟后面的执行无关。

**第二段：流程执行测试。**用固定参数直接触发技能，看执行步骤是否完整跑完。这一段重点观察有没有报错、步骤顺序对不对、输出结构是否稳定。

**第三段：多样本回归。**换不同的输入说法去调用同一个技能，验证它在不同表达下都能稳定唤起。我记得第一次测试时，用“帮我总结一下这周”能唤起，用“把周的进展整理成周报发我”就失败了。后来加了一些同义表述到描述里，问题才解决。

这三段都跑通之后，一个技能才算真正可以上岗。

4. 完整案例：把巡检报告流程固化为可复用技能

4.1 从人工巡检流程中拆出可自动化步骤

光写一个周报技能，可能还不足以展示技能机制的威力。我再用一个更有代表性的案例来说明：服务巡检报告生成。

在没做技能化之前，我每周的巡检流程是这样的人工操作：

1. 登录服务器，检查各服务进程是否存活。
2. 查看磁盘使用率，重点看有没有接近阈值的分区。
3. 拉取最近一段时间的错误日志，挑出需要关注的异常。
4. 把数据汇总到一张报告里，按“服务状态 / 磁盘 / 日志异常 / 风险提示”分组输出。
5. 根据磁盘使用率和错误日志频次，给每个风险点标记高、中、低等级。

整个过程快的话四十分钟，慢的话一两个小时，而且每次输出的格式会因为当时心情和状态不同而飘忽不定。技能化要做的事情，就是把第 1 到第 5 步固化成一套可重复执行的逻辑。

我把这个流程拆成了三个子任务：数据采集、报告生成、通知推送。其中前两个是核心，第三个可以后续再加。拆完之后，技能设计的思路就清晰了：数据采集可以调用脚本或命令行，报告生成用固定模板，风险等级判断写成规则，不让模型自由发挥。

4.2 步骤编排与工具接入

在 Hermes 里，这种多步骤流程的技能，通常需要绑定外部工具来执行采集动作。你可以在技能里定义要执行的命令，或者依赖预先写好的采集脚本，然后让 Harness 按顺序调用。

我当时设计的技能流程是这样的：

• 步骤一：调用check_services.sh，扫描服务进程状态，输出存活列表。
• 步骤二：调用check_disk.sh，读取各分区磁盘使用率。
• 步骤三：调用scan_errors.py，从日志文件里提取最近 24 小时内的 error 级别记录。
• 步骤四：把前三步的数据送入报告生成模板，由模型按固定结构生成巡检报告。
• 步骤五：根据预设阈值，对高风险项做标注。

这里有个非常值得注意的设计原则：让脚本负责确定性的事情，让模型负责总结和润色。服务状态、磁盘数字这些都是硬数据，应该由脚本精确读取，绝不能让模型凭感觉“猜测”。模型真正擅长的，是理解这些数据并用结构化语言写出一份可读性好的报告。

每一步之间，我都加了超时设置和失败处理逻辑。比如磁盘检查脚本如果执行失败，Harness 会记录错误并把失败信息返回给模型，模型可以决定是重试还是跳过继续。如果没有这层容错，一个技能只要有一个环节偶尔抽风，整条流程就会直接死掉。

4.3 输出模板与告警分级

巡检报告的输出不是模型自由发挥的，而是我在技能模板里预先定义好的：

# 巡检报告（示例模板） ## 服务状态概览 - 存活服务：... - 异常服务：... ## 磁盘使用率 - 分区 /dev/sda1：xx% - 分区 /dev/sdb1：xx% ## 日志异常摘要 - 错误日志数量：xx - 高频错误：... ## 风险提示 - 高风险：...（例如单分区使用率超过 85%） - 中风险：... - 低风险：...

风险等级的判断规则，我会直接写进技能模板里，比如：

• 磁盘使用率超过 85% 视为高风险。
• 错误日志中出现连接拒绝、超时等关键词，且频次超过阈值，视为中风险。
• 服务进程异常退出，一律按高风险处理。

这些规则看起来简单，但价值极大。因为一旦把规则写清楚，模型就不需要靠“感觉”去判断风险等级，输出的稳定性会明显提升。这其实也是技能和普通提示词的核心差别之一：技能可以把业务规则编码进执行流程，而提示词只能靠模型临场发挥。

4.4 实测效果和调优记录

这个技能跑起来之后，效果非常直观。原来人工巡检需要四十分钟到一个小时，技能自动化后，从触发到拿到完整报告大概只需要几分钟，而且格式每次都保持一致。省下来的时间主要是两块：一是省去了反复整理数据的机械操作，二是省去了反复调整报告格式的沟通成本。

调优过程中我也遇到了一些问题。最典型的是上下文过长。技能执行到报告生成步骤时，如果采集到的日志太多，塞给模型的指令就会膨胀，模型容易在其中“迷路”，输出的报告结构开始不稳定。

我的解决办法有两个：一是对日志做前置截断，只把高频错误和最近的异常样本传给模型；二是把报告生成的模板拆得更精简，减少不必要的指令占位。调整之后，格式漂移的情况明显减少。

在模型选择上，我最终把日常执行放在了 DeepSeek 这类成本可控的模型上，报告质量完全够用。触发故障应急这样的重要场景，我才会切到更强的模型。不同模型对同一技能的执行效果会有差异，建议你在技能稳定后，多换几个模型跑一遍，看哪个最稳、哪个性价比最高。

5. 踩坑实录：技能不生效、参数抽取混乱与执行中断

5.1 Agent“看不见”技能：描述写法的锅

我第一次写完技能，注册成功后兴冲冲地跟 Hermes 说“帮我检查一下服务”，结果它完全没调用我的技能，而是直接按常识回答了我一通。当时我就很困惑：技能明明加载了，为什么不生效？

后来我查看了日志，发现模型仍在“可用技能列表”中搜索，但它觉得用户请求和技能描述匹配不上。问题就出在我给技能的 description 写得太简短。我写的是“执行服务巡检”，而用户说的是“帮我查一下现在这服务还正常吗”——模型认为这两句话语义对不上，所以去了普通对话分支。

解法也很简单：把 description 改写成包含更多触发场景的描述，核心是解决“模型在什么情况下该调用它”的问题。改完之后，用户哪怕换几十种说法提问，模型都能稳定命中这个技能。从那以后，我写技能第一步永远是“先把 description 写到能覆盖三种常见用户说法为止”。

5.2 参数过多会导致抽取不稳定

另一个我踩得很深的坑是参数泛滥。有一段时间我想做一个复杂一点的数据分析技能，定义了八个参数，包括数据源地址、日期范围、统计维度、排序方式、对比基准等等。结果测试时发现，模型经常抽错参数，要么漏填，要么把两个相近参数的值搞反。

这个问题的根源在于，大模型对长参数列表的抽取能力并不像你以为的那么强。超过五个参数之后，混淆率会明显上升。我的调整思路是：

• 固定不变的配置写死在技能内部，不暴露成参数。
• 能合并的参数尽量合并，比如把“开始日期”和“结束日期”合并为一个“日期范围”字符串。
• 每个参数必须给出示例值，帮助模型理解格式。

最终我把参数压缩到了三个，抽取准确率一下子回到了非常理想的水平。记住一条经验：技能参数越少，模型越不容易犯错。参数不是展示你设计能力的舞台，而是影响稳定性的变量。

5.3 execution terminated due to error 的完整排查链路

如果你经常和 Agent 框架打交道，大概率见过execution terminated due to error这个通用错误提示。我第一次遇到它时，整个人是懵的，因为它看起来像是一个信息量为零的报错。经过几次调试后，我总结出一套固定排查链路。

这是一次完整的问题排查记录：

1. 复现最小场景：不要带着完整的长流程去测，先用最简单的最小输入触发技能。比如只跑数据采集，不跑报告生成；只传一个参数，不传全部参数。这样可以缩小问题范围。

2. 看日志定位阶段：在 Hermes 的日志里找到执行链路，确认是从规划阶段（模型拟定步骤）就失败，还是执行阶段（工具调用/脚本运行）才失败。两个阶段的修复方式完全不同。规划阶段出错，多半是模板太复杂；执行阶段出错，多半是工具或命令的问题。

3. 检查工具调用返回：如果你的技能里绑定了脚本，把脚本单独拿出来跑一遍。我遇到过最蠢的情况是脚本本身没问题，但在 Hermes 的运行目录下路径不一样，导致找不到文件。这种问题看错误日志里的路径信息很快就能发现。

4. 检查上下文是否超限：技能执行到中间步骤时，如果每个步骤的输出都被塞进上下文，长流程很容易把上下文窗口占满。占满之后后续步骤无法继续，就会形成执行中断。我的发现是，很多中断不是逻辑bug，就是上下文管理的问题——要么截断，要么压缩，要么减少步骤产出的文本量。

5. 分段隔离测试：把技能模板从中间拆开，前半段跑一次，后半段跑一次，确定具体是哪一个步骤导致的中断。这种方法虽然原始，但定位问题非常高效，特别适合在完整链路中找不到线索的时候。

6. 修复后回归：改完一处之后，不要只跑一次成功就算完。我会连续跑五次，确保修复是稳定的。因为技能执行涉及大模型决策，天然带有随机性，单次通过不代表问题已经消失。

5.4 技能描述撞车：多个相似技能怎么区分

当你的技能库越来越大，另一个问题会出现：两个技能描述很像，模型不知该调哪个。我当时的处境是有一个“日报生成”技能和一个“周报生成”技能，description 写得都差不多，结果用户说“帮我写个总结”，模型随机挑了一个，输出格式完全不对。

解决办法是在描述里写清楚时间范围和其他区分条件。日产的描述突出“仅汇总当天工作”，周报强调“汇总某一周、包含下周计划”，同时在参数里把日期范围的不同点写明。模型在匹配时就会更倾向于根据用户请求中的时间信息做判断。

如果你有多个技能确实功能高度重叠，那说明你可能不需要把它们分开定义，合并成一个带模式参数的技能会更省事。技能之间要有清晰的边界，不要让模型去做艰难的二选一。

6. 从单个技能走向技能库：版本、组合与团队协作

6.1 把技能当代码来管理

技能不是写完就一劳永逸。它会随着业务流程调整、模型版本更替而需要修改。一旦你开始认真维护技能，就应该把它当成代码来管理：放进 Git 仓库、写清楚提交信息、每次修改都经过可追溯的变更记录。

我见过一些人直接在部署机器的目录里改技能文件，改完也不记录。等到技能出了问题，想回退都不知道该回退到哪个版本。更合理的做法是：本地开发测试完，提交到仓库，再通过部署流程同步到运行环境。这样整个变更链路有迹可循，也方便多人在同一套技能库上协作。

还有一点是技能的回归测试。每次修改技能，不要只验证你改的那个点，要把这个技能覆盖的典型场景全部跑一遍。大模型执行的不确定性决定了，一个字段的修改可能影响另一个原本正常的流程。

6.2 组合技能：让子技能互相调用

当技能数量多起来之后，你会发现很多技能之间存在公共部分。比如“报告生成”这个能力，周报在用，巡检报告也在用。这时候不用每建一个技能就把公共逻辑复制一遍，更好的做法是拆出基础子技能，再让主流程去调用它们。

以巡检报告为例，我最终把技能拆成了下面这样：

• collect_metrics：负责执行数据采集脚本，输出结构化数据。
• generate_report：负责根据数据和模板生成报告。
• send_notice：负责把报告推送到指定的通知渠道。

巡检报告主技能只需要描述自己的整体流程，内部按顺序调用这三个子技能。这样每个子技能保持简单、单独可测，组合在一起又能覆盖复杂的业务场景。这个思路跟代码开发里的“函数组合”完全一致。

6.3 团队共用技能库的规范

如果你不是一个人在维护技能，而是和团队共享一套技能库，那就需要一些共识性的规范。根据我自己带小团队用 Agent 的经验，下面几条规则能让协作顺畅很多：

• 命名规范：技能名统一用snake_case，比如generate_report，不要用中文名或带空格的名字。
• 描述规范：description 必须以“当用户要求……时使用”开头，保证模型对每个技能的业务边界都清楚。
• 参数规范：必须有 example 字段，避免让模型通过猜的方式去填参数。
• 安全边界：技能涉及命令执行、文件访问时，要做权限控制。给技能最小权限，能读就只读，能只调一个脚本就不要放开任意命令执行。这不只是防外部风险，也是防止模型在某次规划中做出不可预期的危险操作。

团队协作中还有一个容易忽略的点：技能库要有“负责人”。每个技能必须有人对它负责，出了问题能找到人来修。否则技能库很快就会变成谁都能改、但又没人真正维护的垃圾场。

6.4 有些事真的不适合技能化

讲了这么多技能怎么建、怎么维护，最后我想泼一点冷水：不是什么东西都该变成技能。

我见过有人试图把“项目复盘报告”做成长长长的技能，里面塞了十几条指令，结果用起来效果还不如让模型直接生成。原因是项目复盘这件事，每次的目标对象、结论深度、受众群体差异极大，根本不具备“稳定的执行流程”。强行技能化，反而让模型的自由度被压缩，输出的内容变得套路化。

判断一个任务该不该技能化，你可以回到开头那几条标准问自己：它高频吗？流程稳定吗？输入输出明确吗？规则可描述吗？如果四个问题里有任何一个是否定的，那就先别急，等流程再跑一段时间，成熟了再固化。技能化的目的是解放你，而不是为了让你维护一套沉重的技能模板。

我自己现在的习惯是，每隔一段时间就复盘一下手上的重复工作，挑出最烦人、最机械的那个流程，把它做成技能。一次只做一个，做扎实了再做下一个。这样技能库始终保持精简，每个技能也都被真实业务验证过，而不是一堆中看不中用的半成品。

最后分享一个我自己的小体会：刚开始用 Hermes 时，我总想着让 Agent 一步到位学会所有东西，结果很快被技能维护的成本压得喘不过气。真正让我尝到甜头的，反而是从最简单、最痛的单一流程入手，把一个技能打磨到其他同事也愿意使用。那之后我才慢慢意识到，自定义技能的价值不在于数量多，而在于每一个都能稳定复用。造工具最开心的一刻，永远是它帮你把一件原本不想干的重复工作彻底甩开的时候。