kimi-tide 定位与维护策略
August 31, 2026 · View on GitHub
一份诚实的自我定位声明：这个项目是什么、不是什么、哪些部分会被时间淘汰、哪些部分值得长期投入。 适用范围：本声明基于 kimi-tide v0.1.3（已发布）与 DSH 0.1.0-rc.7（本机实机验证）；0.2.x 路由器/面板与 0.3.0 能力评分路由均已在 main 分支落地（未发布；路由器失效已于 2026-08-18 commit 71b1d18 修复；带图会话锁存 fcbf421 存在已知死锁限制，见 §5），定位研判按此更新。**0.4.x「API key 直连」已实施（v0.4.0 已发布）——自研 OAuth 接入层退役，kimi-tide 收敛为「纯分工层 + 方法层」（见 §3/§5）。****0.5.0 规则驱动路由已发布（2026-08-21，tag
v0.5.0）：评分引擎退役，分工层收敛为「命名预设 + 有序规则」的预设层（见 §3.1）。**0.6.0 协作编排已发布（2026-08-23，tagv0.6.0）：预设层之上新增「协作流」维度——规则目标可指向预置流（图像转述/评审），分工层从「模型路由」升维为「模型+流程编排」（见 §3.2）。 2026-08-31 更新：v1.0.0 大版本已发布（关键词匹配 + 规则体系/effort + 品牌主题化 + 多 plan 配额）；本文 §3 层次框架与 §5 退役计划继续有效；竞争地图 v2 待 0.8.5-T5。 写于 2026-08，背景是项目发布后的第一次战略审视（对照 Open Design 等生态项目）。
1. 一句话定位
白话版：月汐给 DSH 装上「每一步自动选对模型」的能力——装的、选的、为什么选，全是你说了算，全看得见。
kimi-tide 是 DSH 生态的模型接入与互补分工层，不是应用。
- Open Design 是应用（回答"怎么用 AI 做设计"），kimi-tide 是基础设施（回答"怎么在 DSH 里用 Kimi、怎么让两个模型分工"）
- 两者不竞争，可共存/互补：Open Design 把 DSH 当运行后端，而 kimi-tide 让 DSH 里多一个 Kimi 模型可选（该推演基于公开架构，未实机验证；Open Design 未来也可能经官方 ACP 直接调用 Kimi，绕过模型接入层）
- 与
dsh-kimi-bridge的分工（历史——2026-08-23 归档退役）：bridge 曾把 Kimi CLI 当外部进程调（独立 agent 会话），kimi-tide 把 Kimi 作为功能上在 DSH 模型选择器中可用的 provider（与 DeepSeek 平级可切换；0.4.x 起经官方 pi-ai 原生kimi-coding路由 + Console API Key，非自研 token workaround）。bridge 的「独立 Kimi 会话/审查」角色已由 @kimi 子代理经 kimi-tide 路由承接，vendored fork 已移出仓库（git 历史保留）
2. 与 Open Design 的区别（对照表）
| 维度 | Open Design | kimi-tide |
|---|---|---|
| 层次 | 应用层（垂直：设计/原型/PPT/视频） | 分工层（路由/护栏/观测，接入层已退役） |
| 用户 | 做设计工作流的人 | 在 DSH 里做任何事的人 |
| Kimi 的角色 | 26 个可选引擎之一，外部子进程（kimi acp） | 功能上作为 DSH 可选 provider |
| DSH 的角色 | 运行后端（经自定义 stdio 帧协议驱动） | 宿主平台 |
| 合规性 | ✅ 官方 ACP 协议 | ✅ 官方 API Key 路径（0.4.x 起） |
| 核心问题 | 设计产物生成 | 模型接入 + 互补分工 |
3. 项目价值的三层拆解（按"官方替代性"排序）
| 层 | 内容 | 官方会替代吗 | 策略 |
|---|---|---|---|
| 接入层（0.1.x token 方案） | pi-ai 适配 + OAuth token 轮换 | 会——当 DSH 原生提供 Kimi 官方 provider（含适配器与合法鉴权）时即退役 | 已退役（0.4.x）：pi-ai 原生 kimi-coding 路由 + API key 接管，自研接入层整体删除 |
| 分工层（0.2.x 路由器已接线 → 0.3.0 能力评分 → 0.5.0 规则驱动 → 0.6.0 协作编排，v0.6.0 已发布 2026-08-23） | 预设/规则路由、能力缺口补偿；0.5.0 起为命名预设（省钱/能力/可自建）+ 有序规则（带图/关键词组）+ 全量候选池枚举；0.6.0 起规则目标泛化为「模型 | 协作流」（预置图像转述流/评审流） | 短期内被替代的概率低，但非绝对——官方/社区可能推出通用路由选择器；需持续跟踪机制演进 |
| 方法层（协作闭环文档） | 审查-修复-复检流程、踩坑档案、模板 | 不会，且与项目存亡无关 | 持续沉淀：独立价值；方法论的独立研究见 kimi-tide-research（tafcear × Kimi，架构/损耗/可行性） |
一句话策略：别在租来的时间上盖楼，把砖都铺到自己的地上。
3.1 0.5.0 差异化定位：预设层，而非「又一个关键词路由器」
关键词/规则路由在 DSH 社区已是红海——superboy911/dsh-model-router 已实现「默认模型 + 有序关键词规则、first-match、未命中不动」，同类还有 dsh-auto-gearbox、dsh-omni-router 等。0.5.0 的规则核心（有序规则 + 关键词组 + first-match）与它们逐条重合是有意为之的收敛（规则是用户能读懂的形态），差异化在规则之外的预设层：
- 命名预设：内置「省钱」「能力」双预设（默认模型 + 各自规则集），一键全局切换——同一套规则引擎服务两种相反的使用策略；
- 用户自建命名预设：新建/复制/删除，预设即数据，与内置同构；
- 打底语义：未命中规则 ≠ 不动，而是路由到预设默认模型（社区路由器多为「未命中不动」）；
- 全量候选池：provider 无关的全量目录枚举（无白名单），未接入目标自动降级跳过 + UI 标灰。
此组合（预设层 × 规则集 × 全局切换 × 全量池）在社区无先例。边界声明：我们不做「又一个关键词规则表」；规则匹配逻辑保持刻意简单（子串、大小写不敏感），复杂性全部上移到预设管理与可观测层。
3.2 0.6.0 升维：协作流（编排层），而非「又一个路由器」
0.6.0 把规则目标从「模型」泛化为「模型 | 协作流」——预设层之上新增一层可编程协作：
- 预置流注册但不绑定：
transcribe（vision-exp 读图转文字，eager/lazy 双时态）与review（一模型产出、另一模型评审，P2 触发）随版本内置，用户把 image 规则改挂流即启用； - 按图三态 + imageFallback：布尔锁存退役，每张图独立跟踪 native/transcribed/blind，预设级兜底三态（锁存/盲答/懒转述）用户可选；
- 智能投影：
llm/stream拦截器把已转述图块替换为转述文字——文本模型凭文字接力看图，这是「图片不进主历史」根解的落地形态（T4 门实测通过）。
边界声明：这是双模型协作的通用编排器雏形，不是 N 模型流水线（不立项）；review 流默认 manual、rounds 上限、评审消息不触发评审——防额度失控是编排层的硬约束。
4. 诚实清单（项目的边界与灰区）
- ⚠️
token 方案是条款灰色地带（0.1.x 历史项，0.4.x 退役）：现默认走 Console API Key 官方路径，个人使用安心 - ⚠️ 兼容 DSH ^0.1.0-rc.6（本机 rc.7 实机验证通过）：事件/适配器契约在 rc 快速迭代中可能变更，升级 DSH 可能导致插件失效
- ⚠️
依赖 Kimi CLI 的内部协议（0.1.x 历史项，0.4.x 退役）：接入层改走 pi-ai 原生kimi-coding路由 + Console API Key，不再依赖 Kimi CLI 登录态 - ⚠️ 高频调用可能触发官方限流或条款 enforcement（Console Key 仍请勿高频批量调用/共享密钥）
- ⚠️ 单人维护，无 SLA：问题响应取决于维护者的可用时间
- ✅ 代码与构建流程可复现；运行时需要用户自有 Console API Key 与 DSH 环境（0.4.x 起不再需要 Kimi Code 订阅/OAuth 登录态）
- ✅ 不依赖任何闭源组件、凭据零入库
5. 维护策略与退役计划
| 事件 | 行动 |
|---|---|
| 日常 | 接入层已退役，投入分工层、沉淀方法层 |
| DSH 原生提供 Kimi 官方 provider（含适配器与合法鉴权） | ✅ 已发生（0.4.x）：pi-ai 原生 kimi-coding 路由 + API key 接管，token 接入层退役（README 标注 legacy），分工层保留 |
| DSH 子代理后端注册表开放 opt-in 挂载（实际扩展点 = subagents 命名注册表 + host plane 挂载，先例 codex/claude-code 后端） | 不退役接入层——子代理后端是"DSH 调用外部 agent"的机制，与原生模型接入不同；路由器可将其列为分工层扩展路径（任务路由给独立 Kimi agent；并可实现「子代理图片外包」——子代理读图回传文字、图片不进主历史，同时解决带图会话成本与锁存死锁） |
| DeepSeek V4 后续版本支持多模态 | 路由器的"图片补偿"改为能力检测（前提：DSH 模型元数据暴露 inputModalities 且适配器同步支持；否则保留硬编码补偿） |
| Kimi 侧多模态（当前可用能力） | 图片补偿已是现实能力而非纯未来项——kimi-for-coding 图片识别脚本实测通过、k3 等目录声明 text+image；图片类任务可直接走 Kimi 补偿（0.2.x 图像护栏已接线，方向已于 71b1d18 修正：带图步骤从文本-only primary 改道多模态 premium）。⚠️ 2026-08-19 实测：带图会话锁存（fcbf421）在 k3 额度/Key 失效时致整会话死锁——锁存非终态方案，根解=图像转述模式 / 子代理图片外包（0.3.x 规划） |
6. 项目的时间观
kimi-tide 是一个过渡期方案：它在官方能力到位的窗口里提供真实价值——就本项目所知，它是当前已发布且可用的 DSH 原生 provider 路径之一——并在窗口关闭时把可迁移的资产（路由器、方法论）带走。明确这一点，比任何承诺都更能指导日常取舍：什么值得维护、什么准备退役、什么留给官方。