用户进入 BenszAPI 里，对应的API开启智能路由模式。然后，在Codex里输入更新 bensz skills即可更新。

Bensz Channel 对 huangwb8/skills 的跟踪，已经逐渐连成一条线了：5 月的 BAC 贡献追踪与精准安装，让协作过程开始留下记录；6 月的工作区搬家和7 月的任务、更新与交付整理，慢慢理顺文件与产物；8 月那篇继续处理更新过程中的真实小坑。到10 月 2 日的上一篇，我们已经聊到 v5.0.13，以及 BSK 如何把阶段、身份、检查与业务证据串起来。这几篇放在一起看，项目始终在围绕一个实际问题往前走：当越来越多工作交给 AI，怎样让工具用得顺手，过程也经得起回看？

上篇之后，截至 2026 年 11 月 1 日，仓库新增了 7 次提交，正式发布了 v5.0.14、v5.0.15。这一轮我更想介绍底层的几个变化：安装器怎样处理改名与旧目录，多 Agent 的规划和执行怎样分工，以及今天刚提交的 Skill 身份基础设施计划。BSK 当前仍是 2.1.6；身份系统目前处于待审查、尚未实施阶段。 这两点先说明白，后面再展开，免得小伙伴看完以为又多了一套已经能直接安装的新内核，哈哈。

1 概览

• 安装器补上旧名到正式名称的统一解析。 新旧参数归到同一个安装目标，正式实现就绪后才清理旧目录。
• 多 Agent 执行分工更明确。 规划、角色选择和结果审查交给相应上层，创建、调度、隔离与回收统一经 parallel-vibe 承载。
• 项目初始化更轻量。 默认保留 docs/、docs/plans/，按实际需要再建立项目专属技能目录。
• Skill 身份开始进入设计讨论。 稳定身份、签名发行、内容锁定与真实宿主加载绑定，是最新计划关注的重点，功能尚未落地。

2 v5.0.14：改名以后，安装和更新也要跟着认得路

10 月 17 日的 v5.0.14，有一项很容易被当成普通改名带过的变化：nsfc-humanization 的正式名称调整为 humanization。润色功能的变化这次就不展开了，我更关心它背后的迁移处理。

对经常更新工具的小伙伴来说，改名之后最烦的事情，往往是旧教程、旧参数和本地旧目录各说各话。有人继续用以前的名字安装，有人已经换成新名字；如果两个目录都留下来，Agent 发现技能时还可能同时看到两套相近说明。时间久了，连维护者都得先确认“这次到底用了哪一份”。

这次安装器在配置里增加了 skill_aliases，把旧名统一解析到正式名称。无论指定 nsfc-humanization 还是 humanization，最终都只安装或更新正式的 humanization 目录；同时指定新旧名，也会去重。 这层处理贯穿本地安装、远程 sparse 下载、bootstrap、快速版本检查和静默更新，避免只有某一个入口认得别名，换条更新路径就失灵。

清理顺序也很关键：正式实现就绪以后，再删除对应的旧名目录。 如果安装失败，或者当前只是预览，就保留原来的目录。这样迁移时至少不会因为先把旧入口清掉、新内容又没装好，留下一个两头落空的环境。相关提交还补了别名解析、迁移与平台隔离的回归测试。

别名本身也受到约束，只支持安全的直接名称映射，拒绝自引用和链式映射。这让兼容关系比较容易理解：旧名直接找到正式名，后续安装流程始终处理同一个目标。对于一个持续演进的技能仓库，这类兼容细节会直接决定老用户升级时是否省心。

3 多 Agent 协作：先把谁规划、谁执行说清楚

同一个版本还整理了多 Agent 的职责。awesome-code 收敛到规划、角色选择与结果审查；实际 Agent 执行统一经 parallel-vibe，覆盖 focused-agent、串行和并行几种策略。这里的 focused-agent，可以理解为把一个明确的子任务交给一个专门 Agent。

这个调整的意义，在复杂任务里更容易感受到。例如，一次改动同时涉及接口、前端和审查，上层需要判断任务怎么拆、哪些工作可以同时做、结果怎样合并；执行层则需要真正创建 Agent、传递任务、处理隔离和回收。如果每个上层工具都各自组织一套执行办法，运行记录和失败处理就容易出现差异。把执行入口集中起来，后续才能围绕同一套机制检查协作过程。

实现上也多走了一步。agent_coordinator.py 现在读取配置里的执行依赖、支持模式与责任声明；配置缺失或不完整时，调度门禁会阻止继续，并给出原因。原先那些把执行底座、模式和责任文本写死在 fallback 里的做法被移除了。也就是说，缺少明确配置时，程序会把缺口暴露出来，让维护者处理。

仓库还新增了 tests/test_multi_agent_routing.py，检查上层依赖声明、协调器输出、缺配置时的阻断，以及初始化模板是否指向统一执行底座。它不能证明每一次真实多 Agent 任务都一定成功，但能防止文档与配置改着改着，又悄悄回到各自调度的状态。

对普通使用者而言，仍然按任务需要选择单次完成、专门 Agent 或多 Agent 协作即可。底层分工清楚以后，维护者才更容易定位：这次是任务拆分出了问题，还是实际执行没有完成。

4 v5.0.15：初始化少一点预设，使用入口再清楚一点

11 月 1 日发布的 v5.0.15，除了通用文字润色相关更新，还调整了项目初始化行为：自动与手动模式默认补齐 docs/、docs/plans/，不再自动创建根级 skills/，生成的 AGENTS.md 也移除了相应的项目专属 Skill 开发要求。已有目录和内容会保留。

我挺认同这个方向。一个普通网站、分析项目或者小工具，通常需要清楚的说明和计划；是否要开发项目专属 Skill，则取决于后续有没有稳定、值得复用的流程。初始化时先把所有项目都带进技能开发规范，会增加一些当前用不上的维护负担。先给项目建立必要的文档骨架，等需求出现再增加结构，更符合日常开发的节奏。

根级中英文 README 也补上了安装后的调用示例和常见任务入口，并进一步明确 Python 要求：本地完整安装器与 Kernel 使用 Python 3.11+；远程 bootstrap 为首次和应急安装保留 Python 3.8+ 兼容。之前已经存在的两种要求，这次在文档里写得更清楚了，照着教程操作时也少一点猜测。

按本次公开发布记录，Python 3.12 下仓库与 Kernel 回归测试共 281 项通过，另外运行的定向测试 48 项通过，双语 README 和相关结构检查也通过。这些是项目披露的验证结果，说明此次变更做了哪些检查；具体到每个人的本机环境，仍然要看实际安装和调用情况。

5 BSK 保持 2.1.6，执行内核的职责继续稳定下来

如果你主要关心 BSK，这次最准确的消息是：两个新 release 都没有带来新的 BSK 包版本，当前仍是 2.1.6。 v5.0.15 的发布记录也明确写了，本轮未重复发布 PyPI 包或重装本机环境。

上一篇介绍的 State、Verifier、Gate、运行身份与证据绑定，仍然是理解 BSK 的基础。它负责记录任务阶段、运行检查和放行依据；多 Agent 的创建与调度，则由相应执行层承担。两者可以配合工作，各自解决的问题也比较清楚。

我觉得这也是项目逐渐成熟的一种表现：仓库继续发布，内核可以保持稳定；安装器、协作流程和文档有各自的演进节奏。读版本号时，记住仓库版本、BSK 包版本和单个 Skill 版本分别对应不同对象，就容易判断自己究竟需要关注哪一层变化。

6 最新提交：Skill 的名字之外，还需要一份可验证的身份

今天正式 release 之后，主分支又提交了 7680481，新增一份 Agent Skill 身份基础设施开发计划。这份文件是待审查设计，尚未实施，也没有包含在 v5.0.15 的正式发行内容里。 不过，从项目下一步想解决的问题来看，它值得单独聊聊。

问题其实很好理解：当一个工作流要求使用某个 Skill，Agent 按名字找到的那个目录，怎样证明就是预期的实现？不同作者都可能发布叫 pdf 的技能；另一份实现也可以复制原来的名称、作者说明和版本号。只看文件夹名字，很难分辨这些情况。

可以把它想成收货。商品名称帮助我们找到东西，但真要确认收到的就是预期商品，还得核对供货方、批次和实际内容。对应到 Skill，这份计划希望分清发布者、稳定身份、具体发行版本和内容摘要。人和 AI 仍然可以使用好记的名称，程序则把本次依赖落实到明确的一份发行内容。

6.1 稳定身份与签名发行

计划提出，用发布者身份和其名下的稳定 Skill 键组成 skill_id；显示名称和 alias 可以变化，仓库地址也可以迁移，稳定身份继续用于依赖与审计。不同发布者的同名 Skill 会有不同身份，fork 则使用新的身份并记录来源关系。

有了 ID，还需要证明谁有权发布它。因此，设计还包括签名发行清单，把身份、版本、内容摘要和文件集合绑定起来。信任来源需要由使用者、管理员或已有可信渠道明确建立；从下载包里拿到一把公钥，再验证它自己的签名，只能说明这套材料内部对得上，不能据此认定发布者值得信任。

内容检查的范围也比一份 SKILL.md 更广，拟覆盖配置、脚本、references、模板和内部子 Agent 等会影响行为的资产。这一点很实际：正文没改，辅助脚本被换了，最终行为照样可能变化。

6.2 从“检查过目录”走到“实际加载了这份内容”

整份计划里，我最关注的是这一段。假设文件检查已经通过，接着本地自动更新发生了，或者项目目录里还有一个同名技能，宿主最后会加载哪一份？如果实际用到的内容与刚才验证的内容不同，前面的检查就没有落到本次执行上。

因此，计划希望在一次运行中固定依赖的精确身份、版本和摘要，再由宿主适配保证加载、消费的是这份内容。它还把真实宿主是否存在可用的发现与加载前检查入口，放到了早期验证阶段。这个入口能不能成立，要做原型和真实验收以后才能回答；仅仅演示签名通过，还无法证明同名遮蔽或检查后替换已经被挡住。

安装器未来拟在临时区验证候选发行，再原子替换有效安装；router 则拟通过结构化依赖，表达所需的稳定身份和版本。正常更新应保持进行中的运行内容固定，被明确撤销的发行则在后续受控边界阻止继续使用。旧 Skill、开发副本和离线状态，也需要各自说明真实的验证范围。

6.3 这套设计与 BSK 怎样相处

按当前计划，身份协议和参考实现会作为独立部分发展，暂拟新增 bensz-skill-identity 包。第三方工具可以独立采用，普通 Skill 也无需为了身份检查而先接入 BSK。BSK 将来可以按需消费验证后的身份信息，继续管理自己的执行与证据机制。

这就把两个问题接起来了：BSK 关心这次任务经过了什么阶段、有什么证据；身份层希望确认这些过程使用的是哪位发布者的哪份 Skill。签名验证之后，具体操作仍由本地权限与宿主政策决定，代码安全也需要另外判断。

苯苯点评： 这个方向值得继续做，尤其是我们开始依赖多个仓库、镜像和项目级技能以后，名称带来的歧义会越来越常见。我更期待后续真实宿主的验收：能否固定实际加载内容，遇到篡改、同名遮蔽和并发更新时如何处理。计划已经把这些难点列出来了，接下来就看原型能把保证做到哪一步。(～￣▽￣)～

7 小结

从 v5.0.13 到 v5.0.15，这轮更新的变化主要体现在日常使用的基础环节：安装器统一处理旧名与正式名称，迁移时先确认新实现就绪；多 Agent 规划和执行有了更清楚的分工，缺配置时会暴露问题；项目初始化则减少预设，让目录结构跟着需求生长。BSK 保持 2.1.6，继续承担已有的执行与证据职责。最新身份计划又提出了下一道值得解决的问题：工作流引用的 Skill，如何对应到真正加载的那份内容。小伙伴可以先更新体验已发布的改进，身份系统的进展则留待后续实现与验收继续跟踪。

本文依据截至 2026 年 11 月 1 日的公开提交、正式 Release、源码差异与开发计划整理。版本详情可查阅 v5.0.14、v5.0.15 和最新身份计划。

项目 GitHub 地址：https://github.com/huangwb8/skills