企业官网建设流程全解析

1. 技能后台维护机制到底在解决什么问题

1.1 从一个真实痛点说起

做过技能系统的人大概都经历过这样的场景：后台的技能库越堆越大，早期录入的技能条目因为格式不统一、字段缺失、分类混乱，逐渐变成一团乱麻。运营同事想查一个技能的历史版本，得翻三四个表；开发想复用某个技能定义，发现字段名和半年前那套完全对不上。更麻烦的是，技能之间的依赖关系没人维护，改一个地方可能悄悄影响另外三个调用方。

Hermes Curator 这套机制，核心就是冲着这个痛点去的。它要做的不是简单地“存技能”，而是让技能库具备自我维护的能力——该归档的自动归档，该整合的自动整合，把人工从重复的清理工作中解放出来。

我最初接触这个设计时，第一反应是：为什么不直接写个定时脚本删旧数据？后来想明白了，技能数据和普通日志不一样，它有语义、有依赖、有生命周期，粗暴删除会破坏引用链。所以必须有一套分相位的机制，把“判断”和“执行”拆开。

1.2 双相位设计的核心思路

所谓双相位，指的是自动归档相位和LLM 整合相位这两个独立但协作的阶段。

自动归档相位负责“识别与隔离”。它扫描技能库，根据活跃度、引用次数、最后修改时间等指标，把长期不用的技能标记为候选归档对象。注意这里用的是“候选”，不是直接删除。归档的本质是移入冷存储，保留可追溯性。

LLM 整合相位负责“理解与重组”。它拿归档相位产出的候选列表，用大语言模型去分析这些技能之间的语义关系，判断哪些可以合并、哪些应该拆分、哪些字段需要补全。这一步是纯人工做的话，成本极高，因为要逐条读技能描述并做语义比对。

两个相位分开跑的好处很明显：归档相位是确定性的规则引擎，跑得快、可审计；整合相位是概率性的语义分析，跑得慢但价值高。分开之后，任何一边出问题都不会拖垮另一边。

1.3 适合谁来参考这套设计

如果你正在维护一个中等规模以上的技能库、配置中心、或者任何需要长期演进的元数据系统，这套双相位思路都能直接借鉴。特别是那些“数据只进不出”、越积越臃肿的后台，效果最明显。

对新手来说，不需要一上来就上 LLM。先把归档相位的规则引擎跑通，用简单的阈值判断做冷热分离，就能解决 60% 的维护问题。等技能库规模上来了，再引入整合相位做语义层面的优化。

2. 自动归档相位的规则引擎怎么搭

2.1 归档判定指标的选取逻辑

归档相位最关键的是“判什么”。指标选错了，要么误杀活跃技能，要么放过一堆僵尸数据。我实测下来，下面这几个指标组合比较稳：

权重不是拍脑袋定的。最后引用时间和引用频次放高权重，是因为它们直接反映技能的实际使用价值。依赖入度放中权重，是因为有些技能虽然自己不被直接调用，但被其他活跃技能依赖，删了会出连锁问题。字段完整度放中权重，是因为它反映的是数据质量而非使用价值，质量差的技能可能只是录入时偷懒，不代表没用。

人工标记作为否决项，意思是只要运营标记了“保护”，无论其他指标多差都不进归档候选。这是给业务留的后门，避免规则误伤。

2.2 阈值计算与冷热分界线

指标有了，接下来是划线。我见过不少团队直接拍一个“90天不用就归档”，结果要么太激进要么太保守。更合理的做法是用分位数动态计算。

具体操作：把技能库所有条目的“最后引用时间距今间隔”排序，取第 70 分位数作为冷热分界线的基准。为什么是 70 分位？因为经验上技能库的活跃条目通常占 20% 到 30%，剩下的是长尾。取 70 分位意味着把最不活跃的 30% 纳入候选，这个比例既不会漏掉真正的僵尸数据，也不会误伤偶尔用一次的技能。

import numpy as np def compute_archive_threshold(last_used_days): # last_used_days: 每个技能距今未使用的天数列表 p70 = np.percentile(last_used_days, 70) # 设置下限，避免技能库整体很新时阈值过低 threshold = max(p70, 30) return threshold

这段逻辑里max(p70, 30)那个下限很重要。如果技能库刚建立不久，所有技能都很新，70 分位可能只有 5 天，这时候按 5 天归档就太激进了。加一个 30 天的硬下限，保证新库不会误杀。

2.3 归档执行的安全策略

判定出候选之后，执行归档时有三条安全策略必须遵守。

第一条是软删除优先。归档不是物理删除，而是把技能状态标记为archived，同时移入独立的归档表。原表保留一条指向归档记录的引用，保证外键不断。

第二条是批量上限。单次归档操作不超过技能库总量的 5%。这是防止规则突然抽风导致大面积误归档。如果候选量超过 5%，说明阈值设置有问题，应该先告警人工复核。

第三条是可回滚窗口。归档后保留 7 天的快速回滚期，期间任何调用方发现依赖缺失，可以一键恢复。7 天之后才真正进入冷存储。

注意：软删除字段一定要加索引，否则查询活跃技能时全表扫描会拖慢整个后台。我踩过这个坑，归档表数据量上来之后，没加索引的查询从 50ms 涨到 3 秒。

3. LLM 整合相位的语义分析实操

3.1 为什么整合相位必须用 LLM

归档解决的是“量”的问题，整合解决的是“质”的问题。技能库里经常出现这种情况：三个技能描述的是同一件事，只是措辞不同、字段命名不同。人工合并要逐条读、逐条比对，一个中等规模的库合并一轮要花好几天。

LLM 的价值在于它能理解语义相似度，而不是简单的字符串匹配。比如“用户登录校验”和“账户认证检查”，字符串相似度很低，但语义上高度相关。传统方法用编辑距离或者关键词匹配都抓不住这种关系。

3.2 整合相位的输入构造

给 LLM 的输入不能是原始技能数据的堆砌，那样 token 消耗大且效果差。我的做法是构造一个结构化的候选对列表。

具体步骤：先从归档候选里取出字段完整度低于阈值的技能，以及引用频次低但语义上可能重复的技能。然后两两组合，每组构造成一个 prompt。

def build_merge_prompt(skill_a, skill_b): prompt = f"""判断以下两个技能是否应该合并： 技能A： - 名称：{skill_a['name']} - 描述：{skill_a['description']} - 输入参数：{skill_a['inputs']} - 输出：{skill_a['outputs']} 技能B： - 名称：{skill_b['name']} - 描述：{skill_b['description']} - 输入参数：{skill_b['inputs']} - 输出：{skill_b['outputs']} 请回答： 1. 是否应该合并（是/否） 2. 如果合并，建议保留哪个名称 3. 合并后的描述应该怎么写 4. 置信度（0-1）""" return prompt

这个 prompt 的设计要点是：把技能的关键字段都列出来，让 LLM 有足够信息判断。要求输出置信度是为了后续做阈值过滤，置信度低于 0.7 的合并建议直接丢弃，避免误合并。

3.3 整合结果的落地方式

LLM 给出合并建议后，不能直接自动执行。我的做法是生成一份“整合建议报告”，推送给技能库的维护人员审核。报告里包含原始技能、建议合并后的技能、置信度、以及 LLM 给出的理由。

审核通过后，执行合并操作：保留主技能，把被合并技能的引用关系迁移到主技能上，被合并技能标记为merged状态并指向主技能。这样调用方即使还在用旧 ID，也能通过重定向找到新技能。

提示：合并操作一定要记录迁移日志，包括哪些调用方被影响、迁移前后的 ID 映射。出问题时这份日志是唯一的排查依据。

4. 双相位协作的调度与冲突处理

4.1 两个相位的执行顺序

归档相位和整合相位不是并行跑的，有明确的先后依赖。归档相位先跑，产出候选列表；整合相位基于候选列表做语义分析。如果反过来，整合相位面对的是全量技能库，计算量会大很多。

调度上我建议用“归档每日跑、整合每周跑”的节奏。归档是轻量规则计算，每天跑一次能及时清理；整合涉及 LLM 调用，成本高，每周跑一次足够。

4.2 冲突场景与处理

两个相位可能产生冲突。比如归档相位把某技能标记为候选，但整合相位发现这个技能和另一个活跃技能高度相关，建议保留。这时候以整合相位的结论为准，因为语义相关性比使用频次更能反映技能的真实价值。

处理逻辑：整合相位产出的“保留建议”优先级高于归档相位的“归档建议”。在最终执行前，做一次交集比对，把被整合相位标记为保留的技能从归档候选里剔除。

4.3 监控指标与告警

双相位机制跑起来之后，需要监控几个关键指标：

这些指标我是在实际运行中逐步调出来的。最开始没监控归档量占比，结果有一次阈值配置错误，一天归档了 30% 的技能，调用方大面积报错。后来加了这条告警，再没出过类似问题。

5. 实操中踩过的坑与排查技巧

5.1 归档后引用断裂的排查

最常见的故障是归档了某个技能，但还有调用方在引用它。排查思路：先查调用日志里报“技能不存在”的请求，拿到技能 ID；然后去归档表里查这个 ID 是否存在；如果存在，说明归档判定时漏掉了这个调用方的引用关系。

根因通常是依赖图没更新及时。解决办法是在归档执行前，强制刷新一次依赖图，确保引用关系是最新的。这个刷新操作我建议做成归档流程的固定前置步骤，别省。

5.2 LLM 整合建议质量下降的处理

LLM 整合建议的采纳率如果突然下降，通常是两个原因：一是技能描述本身质量变差，LLM 拿不到足够信息；二是 prompt 需要更新。

排查方法：抽样看几条被拒绝的合并建议，人工判断 LLM 的判断是否合理。如果 LLM 判断合理但审核人拒绝，说明审核标准太严；如果 LLM 判断明显错误，说明 prompt 或模型需要调整。

我遇到过一次采纳率从 60% 掉到 15%，查下来是技能描述字段被上游系统改成了纯代码格式，LLM 读不懂。后来在 prompt 里加了一段“如果描述是代码格式，请先解析其语义”的指令，采纳率就恢复了。

5.3 性能优化的几个实用技巧

技能库规模到十万级以上时，归档相位的扫描会变慢。优化手段：给“最后引用时间”字段加索引，把全表扫描变成范围查询；归档候选的计算结果做缓存，避免每次全量重算；整合相位的 LLM 调用做批量合并，把多个候选对打包成一个请求，减少网络往返。

批量合并这里有个细节：打包的候选对不能太多，否则单次请求 token 超限。我实测下来，每批 5 到 8 对比较合适，既能摊薄网络开销，又不会触发 token 限制。

6. 后续可以扩展的方向

这套双相位机制跑稳之后，还有几个方向可以继续挖。一是把归档相位的规则引擎做成可配置的，让运营自己调阈值，不用每次找开发改代码。二是整合相位引入多轮对话，让 LLM 对拿不准的合并建议主动追问更多上下文。三是把两个相位的产出做成可视化报表，让技能库的健康度一目了然。

我个人在实际操作中的体会是，这套机制最大的价值不是省了多少人工，而是让技能库的维护从“被动救火”变成“主动治理”。以前是出了问题才去清理，现在是系统自己告诉你哪里该清理、哪里该合并。这个转变对长期维护一个大型技能库来说，意义比单次清理大得多。