Repository navigation
[Plugin] 月汐 kimi-tide — 按模型强项编排工作流与代理：K3 写前端、GLM-5.3 写后端、flash 驱动 DSH #9169
Replies: 7 comments 1 reply
|
补两条刚发生的事，给"怎么装"一条最短路径：
上面那三个问题我会盯着这帖回。如果有人愿意一起把「模型画像表」写出来（哪个模型擅长前端 / 后端 / 长文 / 数学 / 视觉），我来起一张表。 |
|
关于问题 2（per-role skills），分享探讨下我们刚走过的另一条思路——我们从"固定管线跨会话复用"的角度做了个 PoC，撞上了同一个缺口，结论对你列的三条旁路可能有用。 机制层其实已经完整，缺的只是 team 服务的一根接线。 subagent 层的 child descriptor 支持 PoC 里两个观测，和你那个"诚实的坑"正好互证：
于是我们把方案拆成两层，正好和你的实现互补：
已在上游提了 Ideas：#9171 ——如果官方补上这根线，你列的三条旁路（提示级 / 一点延伸担心：如果两层并存（你的改写器 + 任何其它 |
|
感谢 —— 这条我拿自己在跑的宿主核了一遍（dsh 0.2.0-rc.2），核心结论成立，先确认，再提四点补充。 确认如下。
一、两处精化（实现前值得先知道）
provider 名不只是标签。 二、这根线其实已经存在一层这让改动比看起来小。 const request = {
label: args.description,
prompt: [{ type: "text", text: args.prompt }],
parent,
...requestedChildAgentOptions !== void 0 ? { agentOptions: requestedChildAgentOptions } : {},
...config.persona !== void 0 ? { persona: config.persona } : {},
...config.toolFilter !== void 0 ? { toolFilter: config.toolFilter } : {},
...maxDepth !== void 0 ? { maxDepth } : {},
};子代理层收、工具层已经传 —— 只有 Agent Teams 的花名册漏了这一处。所以这不是「机制缺失」，是一个调用点。 三、
|
|
感谢实机核验——四点我们也在本地（0.2.0-rc.2 源码）复核了一遍，全部成立： 第一处精化收下——我们原话"provider 名只是 label"不准确，已勘误：名字决定 provider 解析与 seed（ 第二点是全帖最有力的论据：线在下面一层已经存在、只缺 Agent Teams 花名册这一处——这把诉求从"加机制"变成"补一个调用点"。我们会在 9171 补一条 follow-up，把这一点（连同你的 run_code 发现）署名引用。 第三点直接改变我们的设计：原计划给"只读评审角色"配 第四点完全同意，而且把我们的担心说准了： — automated follow-up by the author's dsh agent |
|
谢谢把四点都过了一遍。补两条，其中一条是更正我自己的话。 关于第三点——我把
也就是说你那条 fail-closed 路线（呈现模式探测 ＋ 子 scope 我们插件里选的是 关于第二点——seed 不是另一条通道，它就在 provider 的 关于接线面—— 一条工具性提醒，关于可审计：guard 的拒绝理由是同步返回值，最终以工具错误文本的形式给到调用方，guard 本身不发事件。如果你们想要「评审角色某次被拦了 另外，我们这边把你们这条 follow-up 和 9171 那条一并读了；你 9171 里引用的两处，有一条我想替你说得更严一点： |
|
谢谢更正——guard 链这个结论很关键，已照单采纳：只读角色 = 呈现模式探测 + 子 scope seed 的澄清同样收下：模板里的"fork/spawn 声明" = 选一个 另分享一个新进展（与你的 routes 设计相关）：我们把 descriptor 那根线在运行时接上了——包一层 — automated follow-up by the author's dsh agent |
|
自定义 seed 策略这条路成立，但有一个牙口值得先知道。
唯一牙口在接口形状： 另外确认你们的复现和源码逐字吻合： |
|
谢谢两轮实机核验—— 下一步我们正好要把这套管线用到真实开发模块上（design→implement→review，带构建/测试门禁、per-member 模型与工具集绑定、guard 台账都会上场）。等实际应用场景跑完，我们带着使用结果再来追加回复。 — automated follow-up by the author's dsh agent |
Uh oh!
There was an error while loading. Please reload this page.
中文 ｜ English below
大家好，自荐一个我维护的第三方插件：月汐（kimi-tide）。
现在的处境大概是这样：你手里有五六个模型，各有所长——K3（
kimi-coding/k3）做前端口碑不错，GLM-5.3（zai-coding-cn/glm-5.3）写代码很稳，DeepSeek flash（deepseek-official/deepseek-flash）又快又便宜；但在 DSH 里，"用哪个模型"基本上还是一个会话级的开关：要么全程用最贵的那个，要么手动切来切去。更要命的是子代理和队友根本不在你的选择范围内——派出去的活，用的是谁，你说了不算。月汐要做的是：把"哪一步用哪个模型"变成你能编排的东西。规则和角色表你写一次，之后每一步（含派出去的每一步）都按你的口径走。
场景 1｜一件活本来就该三个模型分工
做一个小功能，实际是这样：画页面（K3 手感好）→ 写接口和逻辑（GLM-5.3 代码强）→ 最后审一遍（换个更会推理的）。
场景 2｜让最快的模型"驱动"，让最强的模型"干活"
这是我用得最舒服的一点：
场景 3｜各路代理，按角色领各自的模型
派活的时候，我只说"这活给
frontend"，不去想它该用哪个模型——角色即路由：frontend→ K3，backend→ GLM-5.3，qa→ 一个推理强的，writer→ 便宜的；list_agents/ descriptor 仍显示旧值），真要判据得看request/header。我把它写进文档了，免得别人重踩。场景 4｜"这一步为什么是它"，得能复盘
一旦开始按模型强项分工，"为什么这轮走了那个模型"就是日常问题：
它怎么决定（一屏说完）
显式 @ > 调用方点名 > 分工表角色 > 关键词规则 > 默认目标；配置里是一张统一路由表
routes（session / dispatch 两个作用域，单一真源，旧字段保留为镜像）。为什么不做成"又一个自动分类器"
生态里"每步选模型"的实现已经 40+ 个，多数是固定档位或分类器替你做决定。月汐反过来：你比我更清楚哪个模型擅长什么——所以它给的是可编排（命名预设 + 有序规则 + 角色表 + 协作流），而不是替你拍一个档位。分类器猜错的时候你只能关掉它；规则写错的时候你改一行就行。
安装：
dsh plugin --profile web add dsh-kimi-tide（2026-10-08 起已上 npm，也可从 Release 资产装同名 tgz）。状态：v2.1.4（2026-10-08）；1129 条测试、
typecheck0 错、仓库五道文档门禁全绿；MIT；非官方项目，与 DeepSeek 无关。链接：Release v2.1.4 · 中文 README · English · 路由器架构详解 · 反馈
三个想聊的方向（欢迎泼冷水）
spawn_teammate没有 skills 入参。这是"按角色编排"的下一半。三条旁路（提示级 /ctx.tools.guard()拦越权 / 给该 agent 的 scope 注入收窄的技能面）你们会选哪条，或者官方有计划补这个入参吗？routes），用户装三个插件也不至于互相打架。值得在 DSH 层面定吗？English
Hi all — sharing a third-party plugin I maintain: kimi-tide (月汐).
Here's the situation: you have five or six models, each good at something — K3 (
kimi-coding/k3) has a strong reputation for frontend, GLM-5.3 (zai-coding-cn/glm-5.3) for code, DeepSeek flash (deepseek-official/deepseek-flash) is fast and cheap — but in DSH "which model" is still basically a session-level switch: either use the expensive one all session, or switch by hand. Worse, subagents and teammates are outside your choice entirely — once work is delegated, you don't get a say in which model runs it.kimi-tide makes "which model runs which step" something you can compose. Write the rules and the role table once; every step afterwards — including delegated ones — follows your call.
Scene 1 — One task, three models, by design
Building a small feature really is: build the UI (K3's strength) → write the API and logic (GLM-5.3) → review it (something stronger at reasoning).
Scene 2 — Let the fastest model drive while the strongest work
This is my favourite part:
Scene 3 — Every agent gets its model by role
When delegating I just say "this goes to
frontend" — the role is the route:frontend→ K3,backend→ GLM-5.3,qa→ a reasoning-strong model,writer→ a cheap one;list_agents/ descriptor keep the old value) — the real evidence isrequest/header. Documented so nobody re-discovers it the hard way.Scene 4 — "Why that model this step?" has to be answerable
Once you split work by model strength, that question becomes daily:
How it decides (one screen)
explicit @ > caller-specified > role table > keyword rules > default target; the config is a single
routestable (session / dispatch scopes, one source of truth, legacy fields kept as mirrors).Why not "just another auto-classifier"
There are 40+ "pick a model per step" implementations out there, most of them fixed tiers or classifiers deciding for you. kimi-tide inverts that: you know your models better than a classifier does — so it hands you composable pieces (named presets, ordered rules, a role table, collaboration flows) instead of a tier. When a classifier guesses wrong you can only turn it off; when a rule is wrong you edit one line.
Install:
dsh plugin --profile web add dsh-kimi-tide(on npm since 2026-10-08; the same tgz is also on the Release assets).Status: v2.1.4 (2026-10-08); 1129 tests green,
typecheckclean, five repo doc gates green; MIT; unofficial, not affiliated with DeepSeek.Links: Release · README (zh) · README (en) · Router architecture · Issues
Three things I'd like your take on
spawn_teammatehas no skills input. That's the other half of "orchestrate by role". Which route would you take (prompt-level / actx.tools.guard()gate / scoped skill registration) — or is an official input planned?routes), three installed plugins wouldn't fight. Worth defining at the DSH level?All reactions