v0.1.2-alpha.1 插件生态反馈：恳请保留 subagent 扩展点（plugin dev 视角）

[dingminhua]

Release dsh-v0.1.2-alpha.1

你好，我是 DSH 插件开发者，插件 dsh-subagent-default-model（https://github.com/dingminhua/dsh-subagent-default-model）的作者。

这次 v0.1.2-alpha.1 把"子代理模型选择/推理力度配置"直接做进了核心，对我的插件造成了实质性影响——插件的核心功能被原生覆盖了。

我理解平台需要完善基础体验，但我想指出一个生态层面的问题：如果平台方不断把社区插件验证过的需求收进核心，且没有提前沟通、也没有保留扩展点，插件开发者的投入就没有保障，大家会不敢做深度插件。这对刚起步的 DSH 生态伤害很大。

我的具体诉求：

1. 保留 subagent 启动前的扩展点（hook/middleware），让插件仍能在原生配置之上做增强（比如多模型调度、故障转移、按成本路由），而不是被完全替代；
2. 类似这种"可能覆盖现有插件"的功能，能否在开发阶段就在 Discussion 里提前征求社区意见？给插件开发者一个适配或转型的窗口；
3. 明确一下平台和插件的边界：哪些是核心要做的，哪些是留给生态的，让开发者有预期。

不是反对进步，是希望生态能健康发展。谢谢。

[MaxJohnXiang]

每次改的都不兼容插件 我也是服了。

[argszero]

同是插件开发者，你这篇我很有共鸣——因为我自己的插件就经历过一模一样的"被原生吸收"。先给背景，再回应你三个诉求里我能给的具体信息。

我的同类经历

我是 @argszero/cordis-plugin-subagent-effort（https://www.npmjs.com/package/@argszero/cordis-plugin-subagent-effort ）的作者。它的来源是 #4666（tool-subagent 把 reasoningEffort 静默丢弃），我做了插件形态修复；结果 v0.1.2-alpha.1 原生把 agentOptions（model + reasoning_effort）做进了 tool-subagent，我的插件同样被覆盖——现在 README 挂着 "superseded upstream since 0.1.2-alpha.1"。

我对"被吸收"这件事的完整看法

两面的：

• 插件被吸收 ≠ 投入白费。我的插件验证了两个东西：① 这个需求真实存在；② 插件形态能修。这两点直接支撑了核心把它收进去的决策。而对用户来说，核心吸收意味着每个会话都拿到修复，而不是只有装了插件的用户拿到——对"子代理模型/推理力度"这种关键路径行为，核心化是更健康的归宿。插件生态的价值有一部分恰恰是"低成本试错、验证后被吸收"，这是流程在正常工作，不是平台在收割。
• 但你指出的问题真实存在：吸收过程没有沟通窗口。核心吸收发生在 release 里，插件作者是发版后才知道的，没有适配/转型期。这一点我完全同意你——这是生态治理的缺口，不是技术缺口。

对你诉求 1 的具体信息：扩展点其实还在

我对照 alpha.2 源码看了下现在的 tool-subagent，原生化吸收的是默认行为，不是每调用控制权：

• agentOptions（model + reasoningEffort）是 schema 字段（packages/subagent/tool-subagent/src/index.ts:112-115），且每调用可传——resolveChildAgentOptions 的合并语义是 per-call > 配置的子代理默认值 > 父级继承（tool-subagent 静默丢弃子代理路由覆盖（每调用 agentOptions）+ 两个面向仓库外（下游）插件的扩展点缺口 Subagent route override is silently dropped by tool-subagent (per-call agentOptions), plus two extension gaps for out-of-repo (downstream) plugins #1619 修的就是 per-call 转发缺环）；
• 新增了 subagent-model-selection policy（model-selection.ts 的 ModelSelectionPolicy，routes 做选择权威校验）——这是一个配置层面的策略系统，不是插件 hook；
• 所以多模型调度/故障转移/按成本路由仍然可以做成：包一层 subagent 调用，在调用点注入 per-call agentOptions（路由/降级/成本决策放在你的插件里），或者贡献一个声明了 agentOptions capability 的 provider。原生吸收走的是"配置优先"路线，插件走的是"调用点拦截"路线——两者是叠加关系，不是替代关系。你的 dsh-subagent-default-model 如果核心是把"默认模型"做进配置，那确实被覆盖了；但如果你想要的调度/故障转移逻辑本来就需要运行时决策，那条路没被堵死。

对你诉求 2/3：合理，且是可执行的建议

"吸收前在 Discussion 预告 + 平台/插件边界文档化"——这两个对生态是实打实的信任投资。alpha.2 吸收的不止 subagent 一项（我的 reasoningEffort 同批被吸收），说明这是平台方向而非偶发。如果维护团队能形成惯例：吸收社区验证过的功能前，在 Discussion 发一个"we plan to absorb X（来源插件 Y）"的预告帖，给插件作者一个转型窗口——这比事后通知健康得多。边界文档也是，不用承诺"哪些永不进核心"，只要给"目前核心 vs 留给生态"的现状说明，开发者就有预期。

我的插件现在就是"已被核心吸收"的完整样本（npm 包还在、来源讨论 #4666 还在、superseded 标注清楚），如果平台要做"吸收前预告"流程，可以拿这类案例当模板。也希望你的 dsh-subagent-default-model 能找到 per-call 路线上的新位置——需要的话我可以把当时插件怎么写的经验分享出来。

[dingminhua]

问题是做的没有我做的好啊，比如说 策略问题，再比如重试问题，那如果这些我想出来的功能到时候都被吸收了，招呼也不打，这是不是太过分