企业官网建设流程全解析

作为一个长期在后台服务维护和 AI 工具链之间来回折腾的人，我见到过太多“技能”死在维护路上。所谓技能，可以是一段提示词模板、一个工具函数定义、一套工作流编排，也可以是给 Agent 使用的能力插件。刚开始大家都兴致勃勃，往自定义指令库里塞了上百个技能，结果三个月后没人敢动——不知道哪个过时了，哪个还能用，哪个已经被别的技能悄悄替代了。这时候我遇到了 Hermes Curator 的设计思路，它的核心就是解决“技能越攒越乱、越用越不敢清理”这个顽固痛点。它把维护过程拆成两个明确的相位：自动归档负责让历史积累有序“退场”，LLM 整合负责让还活着的技能“被看见、被理解、被复用”。这篇文章就围绕这套双相位设计，把后台维护机制的拆解思路、落地细节和踩坑经验一次说清楚。不管你是想给团队搭建技能管理平台，还是只想把自己的 Agent 指令库收拾干净，这套机制里的很多取舍思路都能直接搬走用。

1. 双相位设计到底在解决什么问题

1.1 技能维护的混乱根源

先聊聊我在实际项目里观察到的典型症状。一个团队如果已经维护了一百条以上的技能，常见情况是：有人用旧版本改了某个参数，有人基于一份已经失效的团队规范写了新技能，还有不少技能只是当初某次实验的副产品，压根没打算长期保留。但大家都不敢删，因为技能之间的引用关系往往藏在对话记录、流程日志和下游 API 的调用链里，肉眼根本看不全。

这种时候，人工维护的成本会急剧上升。每一项技能都要重新看原始定义、比对调用记录、确认历史上哪些场景还在用它，最后还得决定是归档还是继续保留。做过一次这种全量盘点的人应该都有体会：纯粹靠人去判断，几乎等于重新做一遍所有技能的调研和评审。而且人容易受路径依赖影响，总觉得“当初花了不少时间做这个，删掉太可惜”，结果就是技能库越来越像僵尸仓库。

1.2 双相位设计的基本分工

Hermes Curator 的思路是别让人在“判断单个技能死活”这件事上投入太多注意力，而是把流程拆成两段相对独立、又能互相衔接的机制。

• 自动归档相位：按规则和统计信号，把长期未使用、明显过期、已经被替代的技能识别出来，先移入归档区。归档不是删除，它保留了恢复的余地，所以决策风险低。这个相位解决的是“历史包袱”问题。
• LLM 整合相位：对仍然活跃或者新录入的技能做语义层面的加工，生成摘要、提取触发条件、建立技能之间的关联，甚至自动建议技能合并或淘汰。它解决的是“技能库越来越大之后，搜索和决策成本越来越高”的问题。

两级相位配合起来，效果不是简单的一加一。自动归档先把噪音清扫出去，LLM 整合才有机会在一个相对干净的基础上做理解和推荐。反过来，LLM 整合产生的新理解，又能反馈给归档规则，让下一次归档更精准。

1.3 适合谁来参考

如果你只是维护二三十个技能，这套机制可能确实重了，手动收拾一下更实际。但凡是技能数量接近一百、团队成员超过三个人、技能间交叉引用开始出现，或者你发现每次发布新技能都要先问一圈“有没有类似的”，那这套双相位设计的价值就很明显。

另外，就算你没打算马上落地一套完整的后台系统，只把“自动归档”和“LLM 整合”这两个相位里的部分策略摘出来，也足够改善很多日常维护困境。比如你可以在自己的指令库里加一个定期归档脚本来清理过期内容，或者用 LLM 批量生成技能摘要来替代手写文档。

2. 自动归档相位：规则、信号与安全阀

2.1 自动归档的核心原则

自动归档这一阶段，本质上是在做一次低风险的资源回收。它要避免两个极端：太激进会误伤正在使用的技能，太保守又起不到清理作用。我最终锁定的原则是：只归档，不删除；先统计，后规则；可恢复，可回滚。

其中“只归档，不删除”真的是救命稻草。因为有这个兜底，很多原本需要人拍板的事情可以直接交给规则去处理。归档后技能不会出现在默认技能列表里，也不会被新会话加载，但管理后台里还能看到完整定义和元数据。只要有一个地方明确标注“已归档”，使用者就不会再把注意力浪费在过时条目上。

规则层面，我通常分成两个层次。第一层是硬性规则，比如“技能在最近九十天内没有任何调用记录”，这类规则简单直接，适合做初筛。第二层是加权信号，比如“技能依赖的某个上游接口已经标记为废弃”，这类规则需要结合外部状态，适合做二次确认。两层一起跑，可以把“长期没人用”和“底层已经失效”这两类问题分开处理，避免以偏概全。

2.2 应该采集哪些统计信号

初始设计时我犯过一个错误：只看调用频次。后来发现频次只能衡量“被使用了多少”，不能衡量“是不是应该继续存在”。一个技能可能每天被调用，但它是在支撑一个早已废弃的业务流程，这时候调用频次反而是误导信号。

所以归档信号尽量多维一点，我认为有价值的信号至少包括：

• 调用时间分布：最后一次调用距今多少天，近七天调用次数，近三十天调用次数。
• 引用关系变化：被哪些工作流 / 上级 Agent 引用，这些引用方最近是否还有活跃记录。
• 技能自身定义变化：是否出现新版本，旧版本是否已被覆盖，修改时间和修改频率。
• 外部依赖健康度：技能依赖的 API 接口、数据表、配置文件是否仍然可用。
• 使用者反馈标记：使用者在技能评价里是否点过“不再使用”或“有问题”。

采集这些信号不需要一次做完。第一次落地时，先把“最后一次调用时间”和“引用方活跃度”这两个拿到，就可以跑通大半个归档流程。依赖健康度和反馈标记属于增强项，等机制稳定后再逐步补上。

2.3 用衰减模型计算技能热度

为了不依赖单一阈值，我采用了加权热度衰减模型。简单说，就是给每一个技能计算一个随时间自然下降的分数，每次成功调用会“充电”，长时间不调用会“放电”。当分数跌落到某个阈值，就进入待归档名单。

一个可以上手的简化版本是这样的：

last_used = skill.last_used_timestamp now = datetime.now(timezone.utc) days_unused = (now - last_used).days half_life_days = 30 decay_factor = 0.5 ** (days_unused / half_life_days) recent_boost = 1.0 if skill.used_in_last_7_days else 0.6 score = skill.base_score * decay_factor * recent_boost

在这个模型里，base_score 可以理解成技能建立时的初始权重，可以按技能类型、重要程度或团队指定值来设。核心逻辑是：每过去一个半衰期周期，分数就衰减一半，三十天没用的技能衰减到一半，六十天衰减到四分之一。这个曲线比固定一刀切阈值温和得多，因为它同时考虑了使用历史和遗忘速度。

实际调参时我一般这样设置：六十天完全未用、且引用方也超过十五天未活跃的技能，分数会低于归档线；七天内有调用的技能，分数会被 recent_boost 拉高，不容易被误伤。这个模型跑起来的效果是，归档动作从“拍脑袋判断”变成了“基于时间衰减的可解释决策”。哪一天上线了这个模型，调试记录里会出现类似“该技能距今四十五天未用，依赖工作流近期活跃，因此未进入归档名单”这样的步骤，对后来排查问题非常有帮助。

2.4 归档流程的安全阀

安全阀是自动归档设计里不能省的部分。我见过一个系统因为误判把某个仍在使用的技能归档了，结果用户在关键时刻找不到工具，影响非常大。所以不管信号模型多精确，都要加以下三道保险：

1. 二次确认：进入待归档名单后，不是直接归档，而是先在后台生成一轮“归档候选列表”，并由预设的确认机制过一遍。可以是人工批量确认，也可以是另一组独立的规则做交叉校验。
2. 延迟生效：确认后不立即生效，而是给一个缓冲期，比如二十四小时内仍可执行恢复操作。这样就算确认时看花了眼，实际操作前还有反悔空间。
3. 归档审计日志：每次归档动作都记录触发原因、执行时间、操作人，以及带走的技能版本快照。不光是安全考虑，这个日志还是后续优化归档规则最重要的数据来源。

这道安全阀看着简单，实际价值很高。它把“全自动”降级成了“自动筛选 + 半自动确认”，同时保留了自动化带来的效率优势。我一直认为，后台维护机制想要的不是无人化，而是把人的注意力集中在真正需要判断的地方。

2.5 归档之后的状态管理

技能一旦进入归档区，并不是就结束了。我会给它打一个“归档原因”标签，区分是“长期未用”“依赖失效”还是“被新技能替代”。这会影响后续的 LLM 整合相位，也会影响最终的处理策略：有些技能归档后几个月都没人找回，就可以考虑彻底删除；有些技能只是暂时退出舞台，等依赖恢复后还能重新激活。

归档状态的切换也需要记录，包括“已归档 -> 已恢复”“已归档 -> 已过期”“已归档 -> 已删除”这几条路径。设计上，归档区不应该是一个一沉到底的深渊，而应该是一个可以来回流动的缓冲区。这套状态机设计好后，后台维护人员对技能的生命周期才会有清晰把握。

3. LLM 整合相位：把技能库变成可理解的知识网络

3.1 为什么需要 LLM 整合

技能维护最大的隐形耗损，不是“归档不够多”，而是“存量技能的价值没被充分挖掘”。团队里最有经验的工程师知道某个技能应该怎么改参数，但这份经验只存在他脑子里。新来的同学面对技能列表根本不知道从哪条开始看，搜索结果里全是些似是而非的描述。时间一长，技能库变成了“只有老人才会用”的工具区。

LLM 整合相位就是来解决这个问题的。它利用大模型的语义理解能力，把原本冷冰冰的技能代码、参数列表和调用接口，转成可以被检索、被比较、被推荐的结构化知识。它不是简单地给每个技能写一段说明文字，而是要做更系统的加工。原始技能定义是原料，经过 LLM 整合后产出的是技能摘要、技能间关联、技能推荐和技能合并建议。

3.2 技能摘要：从代码到人话

首先也是最基础的功能，是用 LLM 为每个技能生成摘要。实现上不是让模型直接读原始代码，那样子效果差，而且 token 成本高。更好的是先把技能的关键信息整理成一个标准化的输入包，再交给模型生成摘要。

一个典型的输入包包含：

• 技能名称和版本号
• 技能类型（工具函数、提示词模板、工作流节点等）
• 输入参数列表
• 输出说明
• 一段简短的已知用途说明
• 最近几次调用记录里的典型输入输出

有了这些信息后，提示词可以这样组织：

你是一名技能库管理员。请根据下面的技能信息生成一份面向团队内部使用的技能摘要。 要求： 1. 用三句话以内说明这个技能的用途和适用场景。 2. 列出核心输入参数的含义和常见取值。 3. 写清楚这个技能的副作用或注意事项。 4. 如果技能依赖于其他技能或外部接口，请明确指出。 5. 输出格式：使用简短的条目式描述，不要使用JSON。

这样生成的摘要，挂在技能列表页上，新成员扫一眼就能知道这项技能是干嘛的，不用担心潜在副作用。我自己的经验是，摘要质量很大程度上取决于输入包的质量，尤其是“已知用途说明”这一栏，哪怕只有半句话，对模型的理解帮助都很大。

3.3 技能关联与语义检索

有了摘要，就能做技术含量更高的操作：语义检索和技能关联。传统的关键词搜索最大的问题是，使用者得恰好知道技能里用了什么词。比如一个技能叫“发薪日计算器”，内部参数里写的都是“pay_date”“cycle”，但使用者脑子里的概念是“下个工资日什么时候”，两边对不上，搜索就失败了。而用向量检索，可以把技能摘要和用户查询都转成嵌入向量，在语义空间里找最近邻，就能解决这类“话不同但意思相近”的问题。

具体落地时，我用的是常见的“离线向量化 + 在线近邻检索”结构。后台有一个异步任务，每当技能新增或更新，就把它的摘要、标签、参数说明、调用样例合并成一段文本，再通过本地部署的向量模型生成 embedding，存入向量库。检索时把用户查询向量化，然后做余弦相似度检索，返回前几个最相关的技能。

这里有一个很重要的工程细节：摘要过了期，向量也失了真。所以当技能定义发生变更时，摘要和向量必须同步重新生成，不能只更新代码不管索引。我之前就因为只更新了技能本体，忘了刷新索引，结果用户搜出来的还是一周前的旧描述，定位问题花了大半天。现在我把“触发技能变更 -> 重建向量索引”这一条定义成强一致流程，不允许出现不一致窗口。

3.4 技能合并与淘汰建议

再往上一层，LLM 整合还可以做“集群视角”的分析。每隔一段时间，把所有活跃技能的摘要和描述放到一起，让模型做一次类聚，看看哪些技能可能在功能上重叠。这个分析不一定非常精确，但能给出一个候选清单，比如：

• 技能 A 和技能 B 的输入参数几乎一致，输出只有一个字段的差异。
• 技能 C 的描述和技能 D 的标签都指向同一个业务场景，而且调用记录高度重合。
• 技能 E 有多个历史版本，最新版本已经完全覆盖了旧版本的功能。

有了这些候选之后，系统可以生成“合并建议”或“弃用建议”，交给人工复核。这一步如果做得准，可以显著降低技能库的冗余度，而且因为有 LLM 帮忙做初筛，人工只需要看几十条候选记录而不是几百条原始技能。

3.5 整合结果如何反馈给归档相位

双相位设计里关键的一环：LLM 整合的结果不能只停留在展示层面，要反向影响自动归档规则。比如模型分析发现技能 A 被技能 B 完全覆盖，那这个“被覆盖”的事实就是一个强信号，自动归档相位在计算技能 A 的热度时，就应该额外加一个“功能重叠”权重。

这样两个相位就形成了一个闭环：自动归档负责清理噪音，LLM 整合负责理解存量，理解的结果再改进清理规则。我对闭环的体会是：如果只做自动归档，规则再完善，也永远只能靠时间维度和使用频次这两个单薄的信号来判断技能去留；如果只做 LLM 整合，产出就会停在文档层，跟真正的生命周期管理脱节。两个相位合起来，才是一个可持续、能自我迭代的后台维护机制。

4. 实操落地：一步步搭起这套维护机制

4.1 数据模型怎么设计

落地这套机制的第一步，是给技能建立一个能支撑两个相位的数据模型。我建议至少要有这几张核心表：

先看技能主表，它的字段包括技能 ID、版本、类型、基础分数、当前状态、创建时间、更新时间。这个状态字段用来存储“活跃 / 归档 / 待复核 / 已删除”等生命周期状态，是整个机制的核心枢纽。

然后是技能快照表：每次技能更新时生成一份不可变的快照。为什么需要它？因为归档日志、版本回滚、LLM 分析都需要回到历史时点，如果只有一个可变表很容易丢失过程信息。

接着是技能指标表，这用于存储自动归档相位需要的各种信号。调用次数、最近调用时间、引用方活跃度、依赖健康度等字段都放这里，由后台异步任务持续更新，减轻实时统计对主服务的压力。

最后还需要技能关联表，用于保存 LLM 整合产出的技能间关联、合并建议、语义标签，以及关系类型。

这里有个建议：冗余比规范更重要。在技能指标表里，与其每次现算近七天调用次数，不如定期批量计算好直接存入表里，查询时省出的开销很有价值。对中大规模技能库来说，实时统计的成本累积起来相当可观。

4.2 自动归档相位的落地步骤

自动归档相位尽量以异步任务的方式跑，不要占用户主链路。我的落地顺序是这样的：

1. 定时采集技能指标：每小时扫描一次技能调用日志、引用关系和依赖状态，更新技能指标表。
2. 计算热度分数：每天凌晨运行一次分数计算，把结果写入技能指标表的 score 字段，低于阈值的技能进入待归档名单。
3. 二次确认：发送待归档候选到管理后台上，等待负责人勾选确认。这一步不必很重，只需在客户端提醒“本周有 N 个技能可能不再需要”。
4. 延迟生效：确认后把技能状态改成“待归档”，二十四小时后自动变成“已归档”，期间可以在管理后台一键撤销。
5. 记录归档日志：生成包含技能快照 ID、确认人、触发原因、归档时间在内的审计记录。
6. 更新向量索引：如果归档的技能还残留在向量检索中，应从活跃索引中移除，避免用户搜索到不可用的结果。

每一步之间可以做成独立任务队列，这样一旦某一步失败不会阻塞其他任务。比如依赖健康度分析那一步挂了，热度计算仍然可以先跑起来。

4.3 LLM 整合相位的落地步骤

LLM 整合相位也不会是高频实时任务，我建议按“事件驱动 + 周期批处理”的方式跑。事件驱动处理技能的新增和更新，也就是变更时立刻重新生成摘要和向量；周期批处理则在每周或每两周做一次技能聚类和重叠度分析，产出维护建议报告。

事件驱动的流程很清晰：

1. 监听技能更新的消息队列事件。
2. 拿到技能新版本的主要信息，构造输入包。
3. 调用 LLM 生成技能摘要。
4. 把摘要和技能描述拼接成文本，调用向量模型生成 embedding。
5. 更新技能摘要字段和技能关联表中的向量索引，再更新技能指标表里的“摘要更新时间”。

周级批处理的流程是把所有活跃技能的摘要取出来，分批次丢给模型做语义相似度比较，输出“重叠技能候选组”。这个过程会消耗一点 token，但很值得。输出结果可以让运营人员看一眼，决定是否将某些技能标记为“被替代”。

4.4 提示词与模型选型的经验

整套流程里，提示词的质量直接决定了摘要和关联分析的可用程度。我踩过不少坑，后来总结出几个要点。

对技能摘要的生成来说，提示词里一定要带上“面向内部团队”这个背景词。没有这个限定，模型很容易生成面向客户的漂亮话，公众号文章式摘要对维护工作没一点用。限定以后，模型输出的文字更贴近研发同事日常沟通的语气，省掉了很多二次润色。

对技能关联分析来说，不要直接让模型输出“是否合并”，而是让它先输出几个更细的材料，比如“功能重叠度分数”“差异点列表”“推荐动作及理由”。人工审视结构化材料比审视一句“建议合并”要靠谱得多。

模型选型上，我倾向于摘要生成用云端大模型，向量化用本地小模型，性能要求高的检索可以一键切换。关键是不能为了省钱把所有环节都用一个小模型硬扛，结果摘要质量没法看，反而把维护成本拉高了。

4.5 人工复核环节如何设计

即使自动化和 LLM 再强，后台维护机制里仍然要有人工复核这个把手。人工不能成为瓶颈，所以设计上要尽量把“让人做判断”的门槛降到最低。

我习惯在管理后台提供一个统一的“维护工作台”界面，它会列出所有待确认事项：

• 待归档技能候选，并附上“近一个月调用次数”“最后活跃时间”“关联工作流”等简要证据。
• 技能合并候选，并附上模型给出的重叠度分数。
• 技能摘要待确认列表，允许快速编辑。

效率最高的操作方式是“默认通过、一键改判”。意思是系统给出的候选默认进入推荐状态，人只需要在少数有异议的项目上做修改。这样安排能把人工复核的时间从几小时压到几十分钟，同时保留人对最终结果的否决权。

5. 常见问题与排查技巧实录

5.1 链接与引用关系断裂

实际运营中很容易遇到一个场景：某个技能被自动归档了，但某个工作流还在尝试调用它，导致请求持续失败。排查这个问题的思路是两步：先查引用方最新活跃时间，再查技能调用日志。如果引用方很活跃，而技能已经没有新日志，基本可以断定存在调用失败。

解决方法是双保险：自动归档动作触发时，先扫描引用列表，生成“受影响工作流清单”，如果清单非空，就强制加一层人工确认。另外，调用层要做兜底，也就是技能不存在时不能直接抛出一个不可读的内部错误，而要在响应里附带“技能已归档，请查看归档建议”这种明确提示。

5.2 向量索引与技能状态不一致

这个问题出现的频率非常高。典型现象是：技能已经归档，但用户在搜索框里仍然能找到它。我遇到过一次，排查后发现问题根源是归档流程只更新了主表状态，没有触发向量索引删除任务。从那以后，我把“任何技能状态变更”都统一发到事件总线上，让向量索引同步消费，而不是在各处手动调用更新函数。

5.3 密钥与调用频率限制影响自动归档

自动归档相位需要大量读取调用日志和外部状态，如果后台系统自身没有充分配额，很容易被限流。我建议所有采集工作放在非高峰时段跑，同时日志采集与实时调用链路要彻底分离。宁可让指标延迟更新，也不能让采样任务拖慢服务主线。

5.4 摘要生成不稳定

LLM 生成同一技能的摘要，可能每次结果描述方式都不一样。这对后续比较和检索不够友好。我给摘要生成增加了一层“结构约束”，比如一定有一个“用途”字段、一个“参数”字段、一个“限制条件”字段，且每个字段的长度上限固定。这样即使句子措辞有变化，结构保持一致，后续比较、聚类、向量化都会稳定很多。

5.5 常见排查速查表

为了方便日常维护，我把几个高频问题整理成了速查表：

这五类问题我们在开发阶段几乎都遇到过，整理成速查表之后，维护效率提升得很明显。谁值班的时候照着表扫一遍，就能定位大半问题。

6. 使用 Hermes Curator 双相位设计后的变化

这套机制跑通之后，最大的感受不是“技能少了”，而是“技能库终于敢被使用了”。以前每次要新增一个技能，团队成员得先问一圈 “有没有类似的”“那个老的能不能用”“描述在哪里” 。现在只要在搜索框里输入一句自然语言，比如“计算项目剩余工作量”，系统就能把隐藏在技能库里名字完全不一样但语义最接近的几条技能列出来，还附上了摘要和依赖说明。这个体验上的改变，比后台指标本身更能说明机制的价值。

而且归档机制带来的安全感，让团队更愿意去规划新技能。以前是“能做但不敢做，怕以后没人维护”，现在是“先建起来，配套的摘要、索引、归档策略会自动帮忙管理”。技能创建的积极性提高了，整个工具生态的更新速度反而变快了。

从数据上看，技能重复率明显下降。过去靠人肉清理很难发现的“功能重叠技能”，在 LLM 聚类分析的辅助下，每两周都能揪出好几组。这些重叠项要么合并，要么明确旧版弃用，用户维护的时候心里的底数也变得更加清楚。

我现在比较建议的思路是，不要把这套机制当成一个一次性的“大项目”，而是当成一个持续迭代的维护习惯。第一版哪怕只做“自动归档 + 基础摘要”这两个最小闭环，也已经能比纯人工维护好上一大截。随着技能数量、团队规模、业务复杂度上升，再把“语义检索、重叠分析、反馈闭环”一层层加进来，维护压力不会像以前那样猛烈放大。

最后再分享一个小技巧：自动归档的触发阈值不要一开始就设得很激进。先用一套保守参数跑两周，把每一次归档结果都拿给团队看一眼，收集意见后再慢慢加大力度。归档机制的本质是给人省心，不是制造新的不安全感。只要体验过一次“技能库干净、搜索精准、改动可控”的状态，你就很难再回到那个又乱又怕动的手工管理时代了。