AI Agent 的配置为什么总会漂移？用 Enozunu 把 Skill、锁文件与生成路径纳入版本控制
AI 编码工具真正难以维护的部分，往往不是模型本身，而是模型周围那层“看不见的配置”：项目里的 Skill、Agent 指令、工具约定、脚本和各类 CLAUDE.md/配置文件。开发者在一台机器上手工复制一份配置，换到另一台电脑时再补几处；几次更新之后，同一个仓库在不同环境里的 Agent 行为就不再一致。CI 更麻烦：本地能运行的 Skill，到了流水线可能缺文件、指向移动分支，或者被旧版本覆盖。
Enozunu 选择了一个很窄、但很实用的切入点：把 AI Agent 配置的“来源”和“目标路径”分开描述，再根据声明生成 Claude、Codex 等工具原生需要的文件。它是 Rust 实现、采用 Apache-2.0 许可证，目前仍处于早期设计阶段。项目并不是 Skill 市场，也不是交互式安装器；它不负责搜索资源，而负责把你已经声明的资源解析、锁定、物化并验证。
先解决配置漂移，而不是再造一个市场
直接复制 Agent 配置有三个隐患。第一，复制出来的文件缺乏来源信息，读者只知道当前目录里有什么，不知道它来自哪个仓库、分支或本地路径。第二，Git 分支和标签会移动；今天解析到的内容，明天可能已经不同。第三，不同 AI 工具的目录约定不同，同一份 Skill 需要被放到不同的目标路径，手工维护很容易漏同步。
Enozunu 的模型是“源池 + 选择 + 生成输出”。源池可以声明 Git、local 或 gist 来源，选择则说明 Claude 或 Codex 要使用哪些 Skill；工具在解析时把可变的分支、标签解析为具体提交，并写进 enozunu.lock.json。生成后的文件是目标工具的原生配置，而不是 Enozunu 自己发明的一套运行时格式。
这种设计把职责分成两层：enozunu.kdl 表达团队希望使用什么，锁文件表达这次实际使用了什么，生成目录则是给 Agent 读取的结果。审查配置时，开发者可以先看声明和锁文件，再看生成差异，而不用从几份复制文件里反推来源。
用最小配置跑通第一条链路
官方 README 给出的入口是先初始化、再校验、最后召唤（materialize）配置：
enozunu init enozunu validate enozunu summon
init 会创建带占位内容的 enozunu.kdl，同时生成 .enozunu/.gitignore，避免解析缓存进入版本库。validate 只负责检查当前项目的清单；summon 才会解析声明的来源，并把选择结果写入 Claude、Codex 等目标路径。首次运行会为 branch 和 tag 选择记录解析到的提交，之后的运行会优先使用锁文件中的提交。
一个最小的 KDL 清单可以这样写：
enozunu config-version=1 {
provider {
skills {
skill "git-kura" {
git {
url "https://github.com/tooppoo/reportage"
branch "main"
path ".claude/skills/git-kura"
}
}
}
}
consumer {
claude {
use-skills "git-kura"
}
}
}
这里的 provider.skills 声明来源：Skill 名为 git-kura，来自一个 Git 仓库的 main 分支，生成内容位于该仓库中的 .claude/skills/git-kura 路径。consumer.claude 再选择这个 Skill。重要的是，示例没有把“下载并复制到某目录”的过程写成脚本；它描述的是来源与消费关系，具体的目标路径由目标支持规则决定。
如果希望修改清单或项目根目录，可以使用官方 README 明确列出的参数：
enozunu validate --manifest path/to/enozunu.kdl --project-root path/to/project enozunu summon --update enozunu summon --frozen
--update 用于跟随已经移动的分支或标签并刷新锁文件；--frozen 则适合 CI，要求所有可变来源都已经被锁定，缺少锁记录时直接失败，而不是在流水线里悄悄解析出另一份内容。这里的顺序很关键：开发者主动更新时才使用 --update，日常构建和部署使用 --frozen，这样“升级 Agent 能力”和“重复构建”不会混成一件事。
把它放进团队工作流
在团队项目中，建议把三类内容一起提交：enozunu.kdl、enozunu.lock.json，以及项目实际需要的生成文件。是否提交全部生成文件，要根据团队对目标工具配置的审查方式决定；但无论如何，锁文件都不应被当成临时缓存删除。它记录的是本次解析的具体提交，是复现行为的关键证据。
一个可操作的 CI 流程是：开发者先修改 KDL，运行 enozunu validate，确认生成结果后提交清单和锁文件；流水线执行 enozunu summon --frozen；最后用 git status 检查生成目录是否出现意外差异。如果生成结果与仓库提交内容不同，说明声明、锁文件或目标文件之间存在漂移，应当让构建失败，而不是继续让 Agent 使用一份未审查的配置。
这种方式也适合多 Agent 团队。Claude 和 Codex 可以从同一个源池选择相同 Skill，但各自得到符合原生约定的输出；团队不必为每个工具维护一套手工复制脚本。它还让 Skill 作者有了更清晰的分发边界：作者提供资源和兼容的清单声明，项目使用者决定哪些资源进入自己的工作区。
一次更新应该怎样进入版本库
把 Enozunu 引入现有项目时，不建议一开始就把所有历史配置一次性迁移。可以先挑一个低风险、边界清晰的 Skill，手工确认它在 Claude 或 Codex 中的目标位置，再写入 KDL。首次 summon 后，逐个检查生成文件：是否只包含预期内容，是否出现了额外的脚本，路径是否落在项目允许的目录内。确认无误后，再把清单、锁文件和生成结果纳入一次普通的代码评审。
后续更新也应该保持“声明变更”和“版本变更”分开看。修改 Skill 的来源或选择，是配置层面的变更；运行 summon --update 让分支指向新提交，则是依赖升级。两者都应在提交信息中写清原因，避免审查者只看到生成文件变大，却不知道 Agent 行为为什么发生变化。若更新后生成目录出现超出预期的差异，应先回滚锁文件或来源选择，再调查内容，而不是直接手改生成结果。
对于 CI，--frozen 的失败应被当作保护信号，而不是简单加一个重试。它可能说明有人忘记提交锁文件，也可能说明源分支已经移动但本地没有经过升级流程。前者要补齐版本库状态，后者要在开发环境显式更新并重新评审。这样可以把“今天突然变了”的问题提前变成一条可定位的提交记录。
它不适合解决什么问题
Enozunu 的边界同样值得重视。它不会帮你发现优秀 Skill，不提供市场排名，也不是带图形界面的安装器。它解决的是“已知来源如何可重复地进入目标环境”，不是“我应该安装什么”。因此，资源选择仍需要人工审查，尤其要检查 Skill 中是否包含危险命令、过宽的文件访问权限或隐含的网络调用。
项目当前支持的目标是 Claude 和 Codex，README 也明确把它描述为早期设计。不要据此推断它已经支持所有 Agent、所有配置格式或任意插件市场。对尚未有稳定配置契约的工具，最稳妥的做法是先把来源和生成结果作为普通文件审查，而不是自行发明一个未经项目支持的 consumer 映射。
另一个取舍是 KDL 和生成文件之间的学习成本。相比“把文件丢进目录”，声明、解析、锁定和物化多了几个概念；但当项目需要多人协作、CI 复现或跨机器迁移时，这些概念换来了更小的隐性状态。它最适合有一组共享 Agent 规范、又不希望把每台机器配置都当成手工资产维护的团队。
结语
Enozunu 的价值不在于让 Agent 更聪明，而在于让 Agent 的输入更像软件工程资产：来源可追踪，选择可审查，版本可锁定，输出可验证。对于刚开始试用 AI 工具的个人项目，复制几个文件可能已经够用；但一旦同一套 Skill 要跨开发机、跨成员和 CI 稳定复现，把配置写成声明并提交锁文件，通常比继续维护一堆安装脚本更可靠。
相关链接