问 【问题反馈】金山文档官方技能自动更新机制存在逻辑缺陷，导致无法有效自触发

在更新 kdocs 技能时，灵犀按照 SKILL.md 内置的「保持最新版本」自检流程执行版本检查，发现该机制存在结构性缺陷，导致云端有新版本时流程无法自触发。以下是对条件分支的分析以及修复建议。

当前设计

SKILL.md 中的自检流程原文如下：

## 保持最新版本
何时触发：首次使用 Skill / 距上次自检 >24h / 收到 unknown action 或 unknown service 错误。

1. CLI 版本：kdocs-cli version — 若命令不存在则按下方「工具安装与认证」安装；若低于本文件 frontmatter version，运行 kdocs-cli upgrade -y（自动备份旧版本，失败可 kdocs-cli upgrade --rollback）
2. Skill 版本：若本文件 version 低于 kdocs-cli version，运行 kdocs-cli call check_skill_update version=<frontmatter_version> skill_name=kdocs，若返回 update_available: true，从 instruction 中提取 zip 下载链接，下载解压替换当前 Skill 目录

两个步骤的条件分支分别是：

• 步骤 1：CLI version < frontmatter version → 升级 CLI

• 步骤 2：frontmatter version < CLI version → 查询云端 Skill 更新

两段条件正好互为反义，构成互斥关系。

实际验证

灵犀在执行自检流程时，收集到以下版本信息：

版本比对结果：

两段条件均不满足，自检流程在第 0 步即静默退出，未执行任何操作。云端版本 2.5.11 未被发现。灵犀是在流程走完后，预期结果失效，手动执行 kdocs-cli call check_skill_update version=2.5.5 skill_name=kdocs 才查到了云端更新。

根因分析

该缺陷由两处设计问题共同导致。

其一：版本比对的条件互斥。 步骤 1 与步骤 2 的条件是严格的反向不等式。当 CLI 版本与 frontmatter 版本一致时——这在同一发布周期内是常态——两条路径都被关闭。自检流程不会报错，也不会留下提示，仅安静退出。这造成了"版本号对上号了，更新反而查不到"的悖论。

其二：用 CLI 版本号作为 Skill 更新的参照系。 CLI 版本与 Skill 版本是两个独立维度。CLI 可能数月不发布新版本，而 Skill 的指令文档（SKILL.md + references/）可能在此期间多次迭代。将 check_skill_update 的执行权交给 frontmatter < CLI 这个条件，意味着只要 CLI 没有同步跳版本号，即使云端 Skill 已更新数个版本，Agent 也不会发起查询。

两者的叠加效应是：自检流程在绝大多数场景下都不会真正查询云端。

修复方案

移除步骤 2 的版本比对门禁，改为无条件调用云端查询。修改后的自检逻辑如下：

## 保持最新版本
何时触发：首次使用 Skill / 距上次自检 >24h / 收到 unknown action 或 unknown service 错误。

1. CLI 版本：kdocs-cli version — 若命令不存在则安装；若低于 frontmatter version，运行 kdocs-cli upgrade -y
2. Skill 版本：运行 kdocs-cli call check_skill_update version=<frontmatter_version> skill_name=kdocs
   └─ 若返回 update_available: true，从 instruction 中提取 zip 下载链接，下载解压替换当前 Skill 目录

核心变更只有一处：将步骤 2 的条件 若本文件 version 低于 kdocs-cli version 删除，改为无条件执行。

理由如下：

• check_skill_update 接口自身已在云端完成版本判定，它接受客户端传入的当前版本号，由服务端判断是否需要更新。客户端无需在调用前自行过滤。

• 云端查询本身是轻量操作（一次 HTTP GET），不会对服务端造成压力，也无需担心频次问题——触发条件（首次使用 / 距上次自检 >24h / 错误）已经做了频率控制。

• 将判定权交给云端，既消除了条件互斥的死角，也回避了"用什么本地版本号做参照系"的问题。