2026-09-07 Kimi 额度打顶后的 ZCode 备用引擎适配

背景与目标

Kimi Code 的 Plan 套餐周额度打顶,正在进行的工作被打断。这不是"省着用"能解决的问题——周额度是结构性约束,再省也会在周中耗尽。本人指令原话:

本项目之前都是用kimi code 搭建的,昨天kimi code code plan 额度周上限了,任务打断了,你看看先把kimi code 相关的工作配置完全复制适配到zcode,先给方案,再动手。

目标定得很清楚:不是"ZCode 能聊天就行",而是工作配置体系整体接班——章程、技能、MCP、防休眠链、台账纪律全对齐,达到可无缝切换的状态。

过程回顾

第一步:摸底定盘,先算清哪些不用迁

先读配置登记册(docs/config-registry.md)并加载 ZCode 官方配置指南,再列两边目录比对。结论出乎意料地省事:

• 技能零迁移:.agents/skills/ 本来就是跨工具共用标准目录,ZCode 会话一开就加载了全部 20 个技能,实证;
• 项目章程零迁移:AGENTS.md 是 ZCode 原生支持的指令文件,同文件直读;
• 凭据零迁移:YXIANG_TOKEN 等环境变量系统级共享,实测可见。

真正要动手的只有三块:用户级章程、项目 MCP、防休眠 hooks。

第二步:细节侦查,把 Kimi 配置拆开看

读 Kimi 的 config.toml(160 行)和 hooks 脚本,摸清防休眠链的完整结构:

• hooks 挂 4 个事件(UserPromptSubmit→active,Stop/Interrupt/StopFailure→idle);
• awake-set.ps1 写状态文件,awake-keeper.ps1 常驻进程每 20 秒轮询,持活跃时调 SetThreadExecutionState 保持机器清醒;
• keeper 自启靠启动文件夹的 vbs 隐藏窗口拉起;
• 顺带查了 cron 目录:4 个 JSON 全是 8 月已过期的一次性盯梢任务,不迁。

再加载 ZCode 的 hooks 诊断技能拿硬约束:只支持七个事件(没有 Interrupt/StopFailure)、配置文件 hooks 必须显式 enabled: true 才会跑、process 类型走参数数组不经 shell 最稳。

第三步:方案先行,6 文件一次落盘

按"先给方案,再动手"的约束,先出了对照表(迁移 6 件、不迁 4 件各附理由),本人放行后执行。6 个新文件:

第四步:验证闭环,不是"应该能跑"

• 两个 JSON 语法校验通过;
• awake-set 手工执行 exit 0,状态文件落盘正确;
• keeper 拉起后日志出现 HOLD (state=active);
• 置 idle 等过 2 分钟宽限期,日志出现 RELEASE——HOLD/RELEASE 全链路实测闭环;
• 进程精查确认 ZCode keeper 仅一个实例,Kimi 原 keeper(PID 21256)未受影响。

收尾:登记册(119→124 项)+ 变更台账 + 记忆三落账,git 提交 f6c032ec。

关键踩坑

• 照抄即互踩:Kimi 的 keeper 认 kimi 进程、状态文件在 .kimi-code/ 下。原样复制的话,两引擎并行时状态文件互相覆盖,keeper 判定直接错乱。解决:ZCode 侧状态文件、日志、进程判定全部独立一套,两引擎可同时在线互不干扰。
• ZCode 少两个兜底事件:Kimi 靠 Interrupt/StopFailure 兜"会话被强杀后状态卡在 active"的场景;ZCode 没有这两个事件,active 会永久滞留、机器永不休眠。解决:keeper 里给 active 状态加 4 小时僵尸过期——超龄的 active 视为异常中断,不再持锁。
• MCP 格式不同:Kimi 用顶层 mcpServers,ZCode 用 mcp.servers 嵌套且文件路径不同,照抄 JSON 会静默不生效。

最终方案

核心不是文件本身,是双轨对应关系:技能与项目章程共用一份(天然同源),用户级章程和 MCP 各养一份副本(修订须双改),防休眠链完全独立(并行安全)。这套对应关系已写进登记册备注和记忆,后续任何一侧修订都有据可查。

做得好的地方

• 先摸底再动手:三块零迁移的判断省掉了 20 个技能文件的无效复制,也避免产生第二份漂移源;
• 不迁移项显式列清单:权限规则、模型 provider(ZCode 无对应概念)、过期 cron(无价值),垃圾不搬家;
• 验证是真跑了:HOLD/RELEASE 用真实等待(150 秒)验证,不是"逻辑上应该没问题";
• 迁移可追溯:台账/登记册/记忆三处同步落账,下次改任何一侧都知道另一侧的存在。

复盘与改进

• MCP 自动连接未实测(要等下次 ZCode 会话启动才能确认)——下次 ZCode 会话开场第一件事查 playwright-crawler 挂载状态,回填台账 ⏳;
• 用户级章程双副本是新的漂移风险点:登记册已标注"修订须双改",更优解是同步脚本或硬链接,但修订频率是月级,先靠登记册纪律扛,不值得为它写工具;
• 可复用方法论:跨工具配置迁移的检查顺序=先找天然共用目录(零迁移项)→再对格式差异(schema 级,不是路径级)→最后才复制内容。这次三块零迁移能识别出来,靠的就是先查工具的配置发现规则而不是直接开搬。

个人成长评估

改进一条:跨引擎配置迁移类任务,先建"迁移核对清单"(源文件→目标文件→验证命令三列),编辑前重读目标段落而非凭记忆匹配。

AI 自评段:本次军师失分点——①登记册 Edit 时把 awake-set/awake-keeper 行序记反,old_string 不匹配失败一次,重读后修正,教训是"凭上轮阅读记忆做精确匹配"不可靠;②首轮 keeper 进程检查把查询进程自身计入,输出两个 PID 造成短暂误判,靠 CommandLine 二次精查纠偏;③验证环节的 150 秒等待串行占用了整个回合,台账落账本可并行先做,时序编排有余地。

素材点

• "额度打顶不停摆":单点依赖任何 AI 工具都是架构缺陷,备用引擎是买期权不是买保险;
• 配置迁移三步法:先找天然共用目录→再对格式差异→最后才复制内容,顺序反了就是垃圾搬家;
• 双引擎防休眠互踩:两个常驻 keeper 共用一个状态文件的隐雷,分家+僵尸过期双保险。