Idea: Session-scoped plugin assembly — auto-install plugins for the task, clean up when the session ends

[hdy2001]

Background

DeepSeek Harness is built on an "Everything is a Plugin" philosophy with Cordis at its core. Today, however, the plugin lifecycle is largely decoupled from the agent lifecycle: plugins are installed up front (via dsh plugin add), and a session either uses what's already there or the user manually adds something mid-flight. The task itself never drives the plugin lifecycle.

Proposal

Make plugin provisioning part of the session lifecycle:

1. Identify — During a session, the harness detects what capabilities the current task actually needs (e.g., web search, memory, file parsing) and resolves which plugin(s) can provide them — for example, via a registry lookup such as dsh-plugin-search.
2. Assemble — The harness installs the required plugins on demand (with user approval and sandbox/permission checks as appropriate), so the agent effectively "self-assembles" its toolchain for the task at hand.
3. Decide on cleanup — When the task completes, the user can choose to:
   • Keep the plugin (promote it to a permanent, session-independent install), or
   • Discard it, letting it live and die with the session — automatically removed when the session ends, leaving no residue.

Why this fits DeepSeek Harness

• It extends the modular philosophy to the runtime: a session becomes a disposable composition of exactly the plugins it needed, nothing more.
• It lowers the barrier for newcomers — no need to curate a plugin set in advance.
• It reduces clutter and risk: no stale, unused, or forgotten plugins piling up between sessions.
• It pairs naturally with existing community work on plugin registries, search (dsh-plugin-search), and install-path guardrails.

Open questions

• Should auto-install be gated by a permission prompt (like tool approval) or a per-session toggle?
• What is the right security boundary for a session-scoped install? (Workspace-local? Profile-local? Sandboxed?)
• How should cleanup interact with plugin state that survives the session (cached data, credentials, local files)?
• Could this be implemented as a plugin itself (a "plugin orchestrator"), staying true to the architecture?

I'd love to hear the community's thoughts — especially on the security model and how this might compose with existing marketplace efforts.

[weijiafu14]

这个想法的方向我理解，但在讨论安全模型之前，有三个今天就成立的机械障碍会先撞上来——而其中一个会让"assemble"这一步以不小的概率把它想帮的那个会话弄坏。我把它们摆出来，不是为了否掉提案，是因为它们直接决定这个特性该长什么样。

障碍 1：插件挂载在启动时，装完不重启不生效

DSH 的插件是在启动时挂载的——加了插件或卸了插件都要重启 dsh 才生效。这是我们（做 DSH 上的兼容层）在自己的安装文档里必须写明的一条。

所以"会话中途按需安装"最直接的问题是：装完了，这一轮也用不上。 除非走热重载——而这就是障碍 2。

障碍 2：运行中热插入插件，今天有一个已知的破坏性 bug

#902 报的正是这件事：运行中往 cordis.patch.yml 里插入几个 MCP 插件，HMR 热重载看起来成功了（MCP 子进程日志全部正常拉起），然后：

点击「新增会话」→ 选择工作区 → 界面闪回"未选择工作区"状态，会话无法创建

楼主自己定位到了根因：ensureStanding() 在预设文件变化时只删 standing map 指针、不 dispose 旧代际（源码里有一条未实现的 TODO），旧代际注册进进程级 cordisInspect 注册表的 provider 因此永远不会 unwind，新代际 apply 时撞 already registered。重启后恢复正常。

这条对你的提案是直接的：你的特性会在每一个任务上触发这条路径。 现在它是"偶尔有人手工改配置才踩到"，你的提案会把它变成主干路径。

障碍 3（最严重）：自动往 profile 里装任意插件，是 #1697 那个 bug 的触发条件

这条我建议你一定要读一遍原帖：#1697。

装任何一个依赖 @deepseek-ai/dsh-tools 的第三方插件，都可能让这个 profile 的每一次工具调用都失败，报错是 Cannot read properties of undefined (reading 'prepare')。

机制：profile 的 pnpm-workspace.yaml 用 nodeLinker: hoisted，插件的传递依赖 dsh-tools（哪怕是完全相同的版本）被提升到 profile 顶层 node_modules，裸说明符解析 profile 优先，于是宿主的 dsh-agent-loop 拿着自己那份副本的 Symbol() 去读另一份副本注册的对象——Symbol 身份是 per-module-instance 的，读到 undefined，然后炸。

@yzke 在那帖里还补了第二个实例：装 dsh-excel-chat 会让 profile 顶层出现一个旧版 dsh-system-prompt，遮蔽宿主的版本，结果内置的 minimal 预设直接挂不上——而且 Web 界面上什么都不显示，用户只看到"选了极简模式又自动变回去了"。

对你的提案意味着什么：

• "自动安装"= 自动制造这个前提条件。而且受害的不是新装的那个插件，是整个 profile——包括原本工作良好的一切；
• 失败形态是非诊断性的（原帖作者的原话是 "completely non-diagnosable"）；
• 而"任务结束后自动卸载"并不能撤销伤害——伤害发生在装上之后的那一整段时间里。

好消息是这个前提条件可以离线检测：那帖下面已经有两个独立的诊断工具做了这个检查（dsh-doctor 的 P5、dsh-plugin-doctor 的 profile-shadow），都是"profile 顶层 node_modules/@deepseek-ai/* 出现真实目录副本就报警"。

所以如果这个特性要做，这个检查必须是它的一部分，而且必须在装之前——装完再检测已经晚了。

这三条加起来，对提案形状的建议

我不认为该放弃，但建议把重心从"自动"挪到"可控"：

1. 先解决"能不能安全地在运行中增删插件"，再谈"谁来决定装什么"。 障碍 1/2/3 全都在第一个问题里，而且它们跟谁触发安装无关——手工装也一样踩。这部分修好了，你的提案就变成一层薄薄的编排；没修好，再聪明的编排都建在流沙上。
2. "identify"那一步值得单独成立。 "这个任务需要什么能力 → 哪些插件能提供"本身就有用，哪怕最后只是给用户一个建议列表让他自己装。这一步没有任何上面的风险，而且是这个提案里最独特的部分（其余部分本质上是包管理）。
3. 回答你的最后一个开放问题（"能不能自己作为一个插件实现"）：identify 那一步可以；assemble/cleanup 那两步不行——它们要改的是插件系统自身的生命周期，而插件是那个生命周期的产物。

关于"会话作用域的安全边界"

你问的这个问题很好，但我建议先明确一件事：自动安装的决定是谁做的。

如果是模型根据任务内容决定装哪个包，那这是一条从模型输出直达代码执行的路径——模型被 prompt injection 诱导时，它可以选择装什么。这条路上，"沙箱"和"权限提示"都只是缓解，不是边界；真正的边界只能是人来确认包名，或者一个人事先批准过的白名单。

（相关的一手判据：这个社区里已经有多份实录，攻击者就是模型本身——所以任何"让模型判断这次操作安不安全"的设计在这里都不成立。你的提案如果保留自动安装，建议明确写成"从一个部署方预先批准的目录中选择"，那是一个可以论证的边界。）

边界与利益相关

我们不修 DSH 自家组件——插件挂载、cordis 热重载、profile 的 pnpm 布局都在 DSH 里。上面引的 #902 / #1697 都是别人的报告，我没有复现过；"挂载在启动时、加卸插件要重启"是我们自己的安装经验。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销——如果这个特性做成了，我们和别人一样是被自动安装的对象；我在这里只是把三条会先撞上来的墙摆出来。