企业官网建设流程全解析

1. 从"技能塞进提示词"到"技能按需加载"的范式转变

如果你最近半年在折腾智能体应用，大概率会遇到一个绕不开的痛点：技能越堆越多，上下文越来越爆。一开始你可能只是给助手加一个"查天气"的能力，后来加了"读文件""写代码""调数据库""发邮件"，再后来团队里每个人都往里塞自己的工具，最后系统提示词膨胀到几千甚至上万token，模型还没开始干活就已经被一堆用不上的技能描述占满了注意力。

Hermes Skills System 想解决的就是这个问题。它提出的核心思路叫渐进式技能（Progressive Skills），配合一个叫Skills Hub的开放标准，把"技能"从"一股脑塞进系统提示词"变成"按需发现、按需加载、按需执行"。简单说，它把技能当成一个可以注册、检索、渐进披露的目录，而不是一段写死的prompt。

这套东西适合谁？三类人最该关注：一是正在做多工具智能体的开发者，二是被上下文长度和工具选择准确率折磨的工程团队，三是想给自己的产品定义一套可复用技能规范的技术负责人。哪怕你只是用现成框架搭个助手，理解这套渐进式思路也能帮你省下大量调试时间。

我先把结论摆在这：渐进式技能的本质，是把"技能描述"和"技能实现"解耦，再把"技能发现"和"技能执行"分层。听起来有点抽象，下面我拆开讲。

2. 渐进式技能到底"渐进"在哪：三层披露机制拆解

2.1 第一层：技能索引——只暴露"名字和一句话"

传统做法是把每个工具的完整JSON Schema都塞进系统提示词，包括参数名、类型、枚举值、描述。一个稍微复杂点的工具，schema就有两三百token，十个工具就是两三千token。Hermes 的第一层披露只暴露极简信息：技能名 + 一句话用途 + 触发关键词。

比如一个"发送通知"的技能，第一层可能只呈现为：

skill: notify desc: 向指定渠道发送一条文本通知 triggers: 通知, 提醒, 发送消息

这一层的作用是让模型知道"有这么个能力存在"，但不需要知道它具体怎么调。实测下来，这一层能把技能相关的上下文占用压到原来的十分之一左右。模型在规划阶段只需要判断"我需不需要用notify"，而不是"notify的channel参数是枚举还是字符串"。

2.2 第二层：技能详情——用到时才展开参数

当模型决定要用某个技能时，才去拉取它的完整定义。这一步在 Hermes 里叫skill resolution。系统根据技能名从 Skills Hub 或本地注册表里取出完整的参数schema、返回值结构、错误码说明。

这里有个关键设计：详情是按需注入的，不是常驻的。也就是说，只有当模型明确表达"我要用notify"之后，完整的参数定义才会进入当前轮次的上下文。用完这一轮，下一轮如果不再需要，它又可以被移出。

我一开始担心这样会不会导致模型"忘了怎么调"，实测发现只要在技能详情注入的那一轮里把参数讲清楚，模型调用准确率反而比常驻schema更高——因为常驻schema里混着大量用不上的工具，模型容易选错。

2.3 第三层：技能执行——真正的代码/接口调用

第三层才是实际执行。Hermes 把执行层抽象成一个统一的调用协议，技能可以是本地函数、HTTP接口、脚本、甚至另一个智能体。执行层只关心输入输出，不关心技能是怎么被发现的。

这三层的关系可以用一个生活类比：第一层是菜单，第二层是菜谱，第三层是下厨。你进餐厅先看菜单决定吃什么（索引），点了菜才看菜谱知道要哪些食材（详情），最后厨房才真正开火（执行）。没人会把整本菜谱贴在餐厅门口。

2.4 为什么分层能提升准确率

这里补一个原理层面的解释。大模型在工具选择上的错误，很大一部分来自注意力稀释：当提示词里有20个工具时，模型要在20个描述里做匹配，相似的工具（比如"发送邮件"和"发送通知"）很容易混淆。渐进式披露把"选择"和"参数填充"拆成两个阶段，选择阶段只面对极简索引，干扰项大幅减少；参数填充阶段只面对一个技能的详情，专注度自然高。

注意：分层不是免费的。它引入了额外的"解析"步骤，如果你的技能索引本身设计得含糊，模型在第一层就会选错，后面全错。所以索引的命名和触发词设计，是整套系统里最需要打磨的部分。

3. Skills Hub 作为开放标准：它想统一的是什么

3.1 技能描述格式的碎片化现状

现在做智能体的人，技能定义格式五花八门。有人用OpenAI的function calling schema，有人用MCP的工具描述，有人自己拍脑袋写YAML，还有人直接把Python函数的docstring当描述。结果是：同一个技能，换个框架就要重写一遍。你给A框架写的"查数据库"技能，搬到B框架基本要重来。

Skills Hub 的野心就是定义一套中立的技能描述标准，让技能可以跨框架复用。它不绑定具体模型，也不绑定具体运行时，只规定"一个技能应该怎么被描述、怎么被检索、怎么被调用"。

3.2 一个技能条目的最小结构

按 Hermes 的思路，一个可注册的技能条目至少包含这几块：

这套结构的好处是描述与实现分离：schema描述"怎么调"，executor描述"调什么"，两者可以独立演进。你换实现不用改描述，改描述不用动实现。

3.3 开放标准真正的价值在"可组合"

单看一个技能条目，好像没什么了不起。但当成百上千个技能都按同一标准注册后，组合就变得可能。你可以按tags批量检索"所有跟文件相关的技能"，可以按version做灰度，可以把一组技能打包成一个"技能集"分发给团队。

我在一个模拟项目里试过：把十几个常用技能按标准注册到本地Hub，然后让智能体自己根据任务检索需要的技能。结果是，新增技能时完全不用改系统提示词，只要往Hub里注册，智能体下次就能发现它。这个体验和"每加一个工具就改prompt"完全是两个量级。

3.4 和现有工具协议的边界

需要说清楚的是，Skills Hub 不是要取代 function calling 或 MCP，它更像是上面的一层组织层。底层调用协议该用什么还用什么，Hub 负责的是"技能怎么被描述、被发现、被组合"。你可以把它理解成技能世界的"包管理器"——它不关心包里的代码怎么跑，只关心包怎么被找到和安装。

4. 落地一套渐进式技能系统：我的实操路径

4.1 第一步：把现有技能做"瘦身登记"

别一上来就追求大而全。先把你当前系统提示词里所有的工具列出来，逐个填进上面的最小结构表。重点做两件事：一是给每个技能写一句人话summary，二是提炼3到5个触发词。

这一步最容易踩的坑是summary写得太技术化。比如"调用REST API向消息队列推送JSON payload"——模型看了也不知道啥时候用。改成"给指定的人或群发一条消息"，匹配准确率立刻不一样。summary是给模型看的，不是给架构师看的。

4.2 第二步：实现索引层与详情层的分离

在你的提示词组装逻辑里，把技能分成两个池子：索引池常驻，详情池按需。索引池只放name+summary+triggers，详情池放完整schema。

具体实现上，我建议用一个简单的检索函数：模型输出一个"我想用X技能"的信号后，你的编排层去Hub拉取X的详情，拼进下一轮上下文。这个信号可以是模型显式输出的技能名，也可以是你用一个轻量分类器从模型回复里抽出来的。

# 伪代码示意：按需注入技能详情 def build_context(user_input, skill_index, hub): # 第一层：只注入索引 context = [system_prompt_with(skill_index)] context.append(user_input) # 模型规划后返回需要的技能名 planned = model.plan(context) if planned.skill_name: # 第二层：拉取详情并注入 detail = hub.resolve(planned.skill_name) context.append(detail.to_prompt()) return context

4.3 第三步：给执行层加统一错误处理

渐进式系统里，执行失败的信息也要能回流到模型，让它决定重试还是换技能。所以executor的返回值最好统一成{ok, data, error_code, message}这种结构。模型看到error_code就能判断是参数错了（改参数重试）还是技能本身不可用（换技能）。

我踩过的一个坑：早期executor直接抛异常，编排层捕获后只给模型一句"执行失败"，模型完全不知道下一步干嘛，只能瞎猜。后来改成结构化错误，模型的重试成功率明显上升。

4.4 第四步：用真实任务做回归测试

技能系统改完后，一定要拿真实任务跑回归。我一般准备20到30个覆盖不同技能组合的任务，每次改动后跑一遍，看技能选择准确率和参数填充准确率两个指标。渐进式改造后，这两个指标通常都会涨，但如果索引写得烂，选择准确率反而可能跌——这就是回归测试的价值。

5. 那些文档不会告诉你的坑

5.1 触发词写太多反而有害

新手容易把触发词写成一大串同义词，觉得覆盖越广越好。实测下来，触发词超过8个后，误触发率明显上升。因为很多词之间语义重叠，模型会过度匹配。我的经验是每个技能控制在3到5个高区分度的词，宁可少而准。

5.2 技能粒度别切太细

有人追求"一个技能只做一件事"，结果切出几十个原子技能，模型在索引层就要面对几十个选项，选择难度反而上升。合理的粒度是一个技能对应一个用户可感知的完整动作，比如"发通知"是一个技能，而不是拆成"构造消息""选择渠道""发送"三个。

5.3 详情注入的时机很关键

详情注入太早（比如每轮都注入）就退化成传统方案，太晚（执行时才注入）模型又没机会检查参数。我的做法是在模型明确表达使用意图的那一轮注入，给它一个"看菜谱"的机会，再让它输出调用。

5.4 版本管理别省

技能是会迭代的。今天notify只支持文本，明天要支持图片，schema就变了。如果没有version字段，你根本不知道线上跑的是哪版。建议每次schema变更都升version，并在Hub里保留历史版本，方便回滚。

6. 从单机技能到技能生态：这套标准能走多远

6.1 团队内共享技能库

Skills Hub 最直接的收益场景是团队协作。以前每个人在自己的prompt里维护工具，重复造轮子。有了统一标准，一个人写好"查订单"技能注册到Hub，全团队的智能体都能检索到。新人入职不用问"我们有哪些工具"，直接查Hub就行。

6.2 跨框架复用的现实与限制

理论上，按标准写的技能可以跨框架复用。但现实里，不同框架对schema的支持程度不一样，有的支持复杂嵌套，有的只支持扁平参数。所以跨框架复用时，schema要尽量保持简单，避免用太花哨的类型。我一般只用string、number、boolean、array这几种基础类型，兼容性最好。

6.3 技能发现的质量决定生态上限

当技能多到几百个时，"怎么找到对的技能"就成了核心问题。光靠关键词匹配不够，未来可能需要语义检索、技能推荐、甚至让模型自己写检索query。Hermes 目前给的是标准框架，检索质量还得靠使用方自己优化。这也是我觉得这套东西最有想象空间的地方——标准定好了，上层怎么玩是开放的。

6.4 我个人的判断

渐进式技能这个方向，我认为是对的。上下文永远稀缺，技能永远在增长，两者矛盾只会越来越尖锐。把技能从"静态塞入"变成"动态加载"，是必然要走的路。Skills Hub 作为开放标准能不能成为事实标准，取决于生态参与度，但它提出的分层披露思路，即使你不用它的具体实现，也值得借鉴到自己的系统里。

最后分享一个我自己的小习惯：每次给系统加新技能前，先问自己一句"这个技能能不能用现有技能组合出来"。能组合就不新增，技能库越精简，模型的选择准确率越高。这个习惯帮我砍掉了将近三分之一的冗余技能，系统反而更好用了。