kimi-tide

English ｜ 简体中文

月汐（kimi-tide）是一个小插件，装在 DSH 上。DSH 就是你平时跟 AI 一起写代码、干活的工具（DeepSeek 官方开源）。

它只做一件事：自动替你换一个更合适的 AI。 你手里通常接了好几个 AI——有的便宜、有的聪明、有的看得懂图。以前全靠自己手动切，切完还常忘了切回来；装上月汐，它每一轮自己挑：日常活先给便宜的，要紧的活交给更聪明的，图交给看得懂图的。

它给你三样东西：

• 省钱——不该花的地方不花。闲聊、翻译、改文案、整理资料这类活，继续用最便宜的那个，好钢只用在刀刃上。
• 不掉链子——关键处有强模型兜着。写代码、审代码、做数学各自走更强的那个；要紧的产出还能先让强模型审一遍（问题按严重度列出 + 改进建议 + 通过／不通过），再交到你手上。
• 不用记着切回来——贴完一张图，只有那一轮换到看得懂图的 AI，下一轮自动回到你原来用的。贵 AI 是按「段」用的，不是按「整场会话」用的。

（下文里「AI」和「模型」是一回事——DSH 管它们叫模型。）

适合谁：在用 DSH、且接了不止一个模型的人。 不适合：只用一个模型，或还没跑起 DSH 的人（先把 DSH 用起来，再回来装这个）。

它解决什么问题

场景一：贴了张截图，模型说看不了

• 以前：手动切到能看图的模型 → 贴图 → 问完 → 记得切回来。
• 装后：直接贴。带图的消息自动交给能看图的模型，下一条纯文字消息自动回到默认模型。

场景二：切完模型，忘了切回来

• 以前：为一张图切到贵的模型，之后整场会话都在烧贵的额度。
• 装后：月汐按「每一步」决策，一会话不绑死——图处理完，下一条消息就回到你的默认模型。

场景三：额度总比预期烧得快

• 以前：所有消息——包括「你好」和「帮我看下这句翻译」——都走最贵的模型。
• 装后：选「省钱」预设（一套配好的「默认模型 + 规则」方案），闲聊、翻译、日常杂活自动走便宜模型，代码和图才动用贵的模型；面板实时显示套餐余额（Kimi/GLM 等带套餐的模型，无套餐的置灰不显示）。

30 秒看懂路由逻辑

一条消息进来，月汐按这个顺序决定用哪个模型：

1. 显式点名：消息里写 @kimi（provider 级：模型取你预设里配过的那个）或 @kimi/k3（精确钉到某个模型）→ 最高优先。
2. 规则命中：按预设规则判定——带图？命中哪组关键词？→ 规则按特异度排序（命中词多者优先、带图恒第一、平手按列表序），排序后首条目标可用的规则说了算（目标不可用自动降级下一条）。
3. 默认打底：都没命中 → 用预设的默认模型。
4. 带图保险：就算选了纯文本模型，消息带图也会被强制改道给能看图的模型——不会崩。

flowchart LR
    A["💬 你的消息<br>（本轮新消息）"] --> B{"显式 @模型？"}
    B -- "@kimi 等" --> H["🎯 显式指令<br>最高优先"]
    B -- 否 --> C["📏 预设规则链<br>带图 / 关键词组<br>特异度降序 · 首条可用生效"]
    C -- 命中 --> D["🌙 规则目标：模型｜协作流<br>（不可用则降级跳过）"]
    C -- 未命中 --> E["💰 预设默认模型<br>（打底）"]
    H --> J
    D -- "目标=协作流" --> T["🌊 转述流<br>vision-exp 读图转文字"]
    D -- "目标=模型" --> F
    E --> F{"带图且目标<br>文本-only？"}
    T --> K["✍️ 转述文字<br>文本模型接力"]
    F -- 是 --> G["🖼️ 图像护栏<br>改道多模态候选"]
    F -- 否 --> J["📋 dock 面板留痕<br>选谁 + 为什么"]
    G --> J
    K --> J

图中「协作流」= 一条「先 A 后 B」的自动流程（比如：图先转成文字，再交给便宜模型作答）；「多模态」= 能看懂图片的模型；「转述」= 让能看图的模型（图中 vision-exp 是 Kimi 家一款能看图的模型名）把图里的内容写成文字；「dock 面板」= 输入框下方的「🌙 月汐」面板。

它长什么样

点图看大图。docs/assets/readme/kimi-tide-architecture.html 下载后用浏览器打开，是可平移缩放/搜索的交互式架构图（明暗双主题，节点可溯源到源码）。

快速开始

1. 前置条件

• Node.js ≥ 22
• DSH @deepseek-ai/dsh@0.1.2-rc.1 及以上（本版实机验证于 0.1.5-rc.1）
• 你想互相调度的模型已接入 DSH——不限哪一家。想用 Kimi，就准备一把 Kimi Code Console API Key（在 Kimi 控制台生成的密钥；配额面板也用这把 key）

2. 接入候选模型（DSH「设置 → Models」页）

「设置 → Models」里添加模型来源（示例：kimi-coding，apiKeyEnv 填 KIMI_API_KEY，然后在凭据区粘贴你的 Key——k3 等 4 个 Kimi 模型会自动出现在目录里）。接几家都行：月汐的候选池就是这页的全部模型。密钥由 DSH 托管保存，不会写进任何插件配置文件。

3. 安装插件

cd packages/dsh-kimi-tide
npm install && npm run build && npm pack
dsh plugin --profile web add ./dsh-kimi-tide-<version>.tgz

4. 用起来

重启 dsh web：

• 设置 → 月汐：预设行选「省钱」或「能力」，路由器即刻上岗；
• 消息里 @kimi 可以显式点名，或者靠内置关键词组自动改道（比如消息里出现「代码」就走编码模型）；
• 输入框下方的「🌙 月汐」面板实时显示每一步选了谁、为什么；
• ✅ 30 秒验收：发一句「帮我写个函数」——面板应显示命中 code 规则并改道到编码模型。看不到理由条 = 路由器没上岗，回「设置 → 月汐」确认已选预设。

预设与规则

预设 = 一套「默认模型 + 规则」方案，一键全局切换；月汐自带两套：

内置 7 组关键词（词表可改，也可自建新组）：

review 组默认服务于评审协作流（请强模型评审本轮产出）——机制、四个开关与今天的边界见下文「多模型协作评审」一节。

两个常用微调（都在「设置 → 月汐」里点几下就能配）：

• 最少命中词数：给规则配一个下限（比如 2），一句话里至少命中这个词组的 2 个词才触发——避免「做个方案」这种顺带提到关键词的普通句子误触发。
• 推理力度（effort）：给规则目标或默认模型指定「思考深度」档位（想得越深越慢越贵）；转述流的视觉模型与评审流的评审模型同样可配（设置 → 月汐 → 协作流）。下拉里只列该模型声明支持的档位——「跟随默认（该模型未声明档位）」就是没声明；模型不支持你配的档位时自动忽略，不会报错。

用量与余额（跟着命中的目标自动切）

面板第二行的额度槽会跟随当前命中的目标自动换形态：订阅类（code plan）显示用量窗（周 / 5h，条画的是剩余比例），API 计费类显示余额（余额不足以调用 API 时会明确标注）。旁边还有一个总览按钮——一屏列出全部已注册的源，以及某个源为什么没数据：「该套餐无公开 API」/「key 未配置」/「取数失败」三态分别说清，不用你猜。

取数用的凭据按 settings.yaml 里该 provider 配置的 apiKeyEnv 名字解析（并自动兼容内置别名）——你给 provider 起的 key 名与插件内置默认名不一致时，面板照样取得到数。

说明页与语义确认闸

• 「设置 → 月汐 → 说明」：面板每个元素是什么、设置里每个字段什么意思，八个分区讲清，关键条目带当前值（如「触发方式：当前＝手动 ⇒ 关键词命中不会触发评审」），另有一张症状 → 原因表。
• 语义确认闸（默认关闭，需在配置里开）：开启后关键词命中不会立刻改道——先让本预设的打底模型确认「这是本轮真意图吗」，判否就跳过该条规则、继续匹配后续规则。超时/模型不可用/输出解析失败一律按原关键词结果走；显式 @ 轮与「带图规则已排首位」的轮不发判官调用。配置项 preset.hitConfirm。
• 判词写在决策原因里：判否 / 确认 / 无结论会前置到面板的决策原因串（如「语义闸无结论 1200ms（code-kfc）」）。因为判否会让规则出链、最终落打底，带判词注记的打底决策也会照常上报——否则「判否」这个最该被看见的结果反而看不见。
• 判官按目标能力关掉思考：判官是推理模型，而这道闸只给它 64 token 的预算——如果放任它先思考，预算会被思考吃光、正文一个字都不剩，判词必然不可解析（闸门静默失效，什么都不改）。所以判官目标声明支持「off」档位时，插件会显式关掉思考；目标不支持（例如 k3）就不下发，绝不硬塞一个它不认的档位。

显式 @ 的两种写法

• @kimi（provider 级）：模型取你预设里配过的那个 kimi 目标（不是目录里碰巧排第一的），决策原因里会写明依据；
• @kimi/k3（精确到模型）：直接钉到该模型——想用哪个模型就用哪个，不受候选池顺序影响；模型不可用时会明确告诉你回落到了谁，不会静默换人。
• 只有真的 provider 才算指令：@ 后面若不是本插件认识的 provider——例如工作区路径引用 @README.md、scoped 包名 node_modules/@deepseek-ai/…、路径里的 @xxx——不会被当成显式指令，该轮照常走关键词规则，决策原因里写明「@x 非本路由器已知 provider（已忽略）」。

匹配细节（词边界、特异度排序、降级语义）、带图行为、配置全字段：见路由器架构详解。候选池 = Models 页全量目录，任何模型都能当默认或规则目标。

多模型协作评审（强模型把关）

路由决定「这一步用谁」，评审决定「这一步干得够不够好」。两者可以分开用，也可以一起用。

它做什么：一轮结束后，月汐把「本轮你的需求 + 主模型产出」发给你指定的评审模型（通常是更强、更贵的那个），拿回一份结构化评审——问题（按严重度分级：阻塞／建议／可选）→ 改进建议 → 结论（通过／有条件通过／不通过），并以评审卡贴在那一轮下面。

四个开关（设置 → 月汐 → 协作流）：

退回重做怎么走：退回不是替你改代码，而是往这一轮注入一条「按意见修订」的消息，让主模型只改被指出的问题（不重写无关部分），然后正常起下一轮。原产出仍在会话日志里，随时可回看。

• 自动：勾上「自动修订」后，评审结论为「不通过／有条件通过」即触发；结论判「通过」或解析不出结论不会触发（不猜）。
• 手动：任何一张评审卡上都有「让它重做」按钮（或敲 /kimi-tide revise），不勾自动修订也能用——评审判「通过」时你也可以让它重做。
• 不会失控：每会话最多退回「轮数」次（1–3）；到顶后事件卡会显示「已停（达上限）」，不再自动重做。评审自身失败（超时/空输出）绝不触发退回。

它今天不做的事：不会替你改代码，也不会绕过主模型自己写——退回去的活仍然是主模型干的。

成本：评审只发生在命中的轮，且只把该轮产出切片发给评审模型（单段上限 12000 字符、60 秒超时、失败不打断本轮）。开启退回后每次退回多一轮主模型调用，开着复检再多一次评审调用。研究仓库引用的业界数据里，对抗式评审回路的 token 消耗常在单模型的 2–3 倍量级——本插件自身尚未测量。

证据分级：机制设计与三轮实证见 kimi-tide-research。其中「评审能否提升弱模型产出质量」尚未度量（意见接受率、与「强模型独立完成」的对照基线、修复引入新问题的比率均无数据），因此本节不写效果数字；「转移效率对照实验」原定随 v1.4.0 交付，v1.4.0 先只交机制本身（退回重做），对照实验顺延到下一版——它的载体（产品自身跑评审闭环）正好在 v1.4.0 就位。

团队派发（把专项活交给专家模型）

路由管「这一步用谁」，协作评审管「这一步干得够不够好」；分工表管「这类活以后归谁」。月汐把分工表做成一张给模型看的技能卡——主模型派活前自己照着办，不用你在提示词里手抄模型名。

• 配一张分工表（设置 → 月汐 → 分工表）：一行一个角色，写明 id（也是队友名的认领键）、标签与目标模型，例如「前端 → kimi-coding/k3」「后端 → zai-coding-cn/glm-5.3」。两个角色抢同一个队友名的认领冲突在保存时当场拦下。
• 队友名就是认领：用角色 id（或它的别名）建队友，月汐就把它的每一步请求改道到目标模型；不认识的队友名一律不动（保持它被创建时继承的模型），子代理轮也不会被任务描述里的关键词二次改道。
• 模型看得见这张表：分工表非空且路由开启时，月汐自动注册一张运行时技能（kimi-tide-team）——派活前读它，按两种配方之一办事：一次性任务（workflow 点名目标）或常驻队友（spawn_teammate，名字取认领列）。你改表，存活会话的技能卡下一轮自动换新；表清空则整张卡退出。
• 主驱动恒定：想让主会话的打底永远是某个模型（而不是预设默认），在设置里打开「主驱动恒定」并指定目标即可——关键词规则与 @kimi 指定照样优先。主驱动留空＝跟随宿主默认模型。
• 每次派发都留痕：决策面板的「最近派发」列出依据（role / unclaimed / explicit / keep）、队友、角色标签与最终生效的模型（每父会话最近 20 条）；角色目标不可用时不静默换人，面板逐字写明「「〈角色名〉」目标不可用 → 保持继承（〈实际生效目标〉）」。

配置字段（roles / driver / driverSticky / rulesApplyToChildren）、五档决策优先级与迁移口径见路由器架构详解的「2.0.0 团队派发」节；实机验收判据与结果见 team-dispatch-acceptance.md。

常见问题

Q：以前的 OAuth 接入方式去哪了？ A：退役了。DSH 官方生态已原生支持 Kimi 接入，自研的那层属于重复造轮，已整体删除。现在一把 Console API Key + 官方 Models 页配置即可。历史存档见 docs/legacy-setup.md。

Q：还需要装 Kimi CLI 并 kimi login 吗？ A：不需要。一把 Console API Key + 官方 Models 页配置即可。

Q：带图会话有什么限制？ A：默认「锁存」姿态下，会话一旦带过图就锁定在能看图的模型上——如果它的额度/Key 失效，这个会话切不回文本模型，只能新开。想避免：把预设的带图兜底改成「懒转述」（图片先转成文字，文本模型接力）或「盲答」（当没图处理）。转述结果有缓存，失败不会反复重试。重要的带图任务，保持模型额度健康即可。

Q：之前听说有个「能力评分引擎」？ A：退役了。以前靠机器打分选模型，黑箱难懂；现在改成你写得出的规则——命中即路由，未命中走默认，每个决策你都能读懂、改得动。旧评分配置升级时自动转成预设。

Q：路由配置存在哪里？升级会丢吗？ A：存在 DSH 设置里（「设置 → 月汐」编辑，重启保持）。跨版本升级自动迁移，旧配置自动留档；细节见路由器架构详解的「迁移链」节。

版本与路线

当前版本：v2.0.0（2026-10-06）

• 每个版本你得到了什么：CHANGELOG.md
• 维护者证据链（commit 锚点 / 验收记录）：docs/release-evidence.md
• 规划中：v2.0.0 的「角色 × 带图」组合实机补验（等宿主 GUI 开放队友会话的图片附件）、子代理转述、0.8.5「强化与包装」小版本——详见证据链文档「规划中」条。

文档索引

这个项目的三条原则：官方优先 · 规则透明 · 决策可观测——路由依据是你写得出的规则，每次自动选路都有理由、有留痕。

我想用

• 快速开始（本页）
• 常见问题（本页）
• 更新日志

我想深挖

• 路由器架构详解：预设/规则/降级/迁移链/配置全字段
• 交互式架构图（下载后浏览器打开；静态版见上文「它长什么样」）
• DSH 宿主平台契约调研
• 项目定位与维护策略
• 双模型协作闭环方法论（本项目自己的开发方式；独立研究见 kimi-tide-research）

我想参与

• 来 Discussions 聊使用体验
• 报告问题、提交修复（欢迎任何形式的贡献，见下方贡献者）

开发与测试

cd packages/dsh-kimi-tide
npm install
npm run typecheck   # tsc --noEmit
npm test            # vitest
npm run build       # tsc 宿主 + esbuild 浏览器

质量基线：全量测试绿 + typecheck 0 错误 + build 通过方可提交。本仓库实践「实施 → 独立审查 → 修复 → 复检验收」双模型协作闭环（见 docs/agent-collaboration-loop.md）。

文档门禁：npm run check 跑三条机器门禁——CHANGELOG / README / package 版本三方一致、全库文档链接不断、两个 README 双语对一致（版本行 / 章节骨架 / 徽章 / 本地文档链接集合四项，规则见 docs/agents/readme-pair.md）——任何用户可见改动，中英两份 README 必须同一次提交里一起改。

Release 双语四段式：每个新版本的 Release 正文（= 附注 tag 消息）必须是双语——中文整块在上、English 整块在下，每种语言内部四段：① 一句话定位 ② 本次更新 / What's new ③ 安装与升级 / Install & upgrade ④ 验证与验收 / Verification & acceptance。打 tag 前用 node scripts/check-release-notes.mjs --file <正文草稿> 自检，Actions 在 gh release create 前再拦一次（模板与细则见 docs/agents/release-notes.md）。

发布门禁：任何版本发版（打 tag / 触发 Actions Release）前，必须在真实宿主上跑通该版本的实机验收清单并全绿，且由维护者裁定 tag——「单元测试绿」不等于「宿主里能跑」。各版本验收记录见 docs/release-evidence.md。

发布规范（维护者）：DSH 插件必须声明 dsh.bundle.patch（指向 cordis.patch.yml）才能作为 profile 层加载。本插件已按官方规范声明，升级版本时请勿移除该字段。

贡献者

• 感谢 @dracpet 的实机诊断与社区贡献：PR #1（OAuth 过期刷新）、PR #2（commands/execute 跨宿主契约容错）、PR #3（YAML null 配置归一化）与 Issue #4（rc.2 投影 wire 契约诊断）——你的反馈直接加固了 0.5.x–0.6.0 的发布质量。
• 感谢 @pandashere 的 dsh-kimi-bridge（MIT）：项目初期的 Kimi CLI 桥接由此起步，早期审查轮与双面插件/投影机制为月汐的面板链路提供了先行验证；该组件已随官方接入路径成熟而退役归档（git 历史保留），特此致谢。
• 也欢迎任何形式的贡献：报告问题、提交修复，或来 Discussions 聊聊使用体验。

许可证与合规提示

• kimi-tide 本体：MIT（Copyright 2026 kimi-tide contributors）
• 第三方组件：@earendil-works/pi-ai（MIT）、@deepseek-ai/dsh-llm-pi-ai（MIT, DeepSeek）、schemastery（MIT）、zod（MIT）、yaml（MIT）、dsh-kimi-bridge（MIT，历史致谢，已归档）
• 合规：默认走 Console API Key 官方路径，个人使用安心；Kimi Code 订阅条款仍以官方表述为准，请勿高频批量调用或共享密钥。
• 本仓库不含任何凭据；请勿将 ~/.dsh/.credentials.yaml、环境变量中的密钥提交到仓库。