Thoughts on "Everything is a Plugin" — the user-side cost

[phinn]

I've been studying the architecture in depth (49 packages, Cordis IoC, subagent providers for Claude Code/Codex/ACP, JSONL event sourcing, Landlock sandboxing). The engineering is genuinely impressive. But I want to share some concerns about where this is heading from an end-user perspective.

The plugin paradox

"Everything is a Plugin" is a fantastic pitch for developers and contributors. But for end users, it translates to configuration complexity. A user who just wants an AI coding assistant shouldn't need to understand Profile composition, Bundle wiring, or which plugin provides which service.

Claude Code ships as a single binary — npm install -g @anthropic-ai/claude-code and you're done. Codex is heading the same direction: one install, zero config, immediately useful. Both are moving toward the user, reducing friction at every step.

Plugin conflicts are inevitable

With 49 packages and growing, the dependency graph is already non-trivial. Plugin A depends on B's service. B depends on C's hook. C updates and breaks D. Cordis's reversible effects are elegant in theory, but in practice:

• Two plugins register overlapping tools with the same name
• A plugin's ctx.tools.register() shadows another's
• Service injection order changes behavior subtly
• A user installs plugin X and their session history format changes

These aren't hypothetical — they're the standard trajectory of every plugin ecosystem that ever scaled (VS Code extensions, Obsidian plugins, Webpack loaders). The difference is those platforms had years to build runtime isolation. Cordis plugins share one process, one context object, one tool registry.

What I think users actually want

1. One installer, zero config. Download, run, start talking to the AI. No Profile YAML, no plugin manifest.
2. Batteries included. File ops, web search, shell access, code execution — built in, not opt-in.
3. Predictable behavior. If I install something extra, it shouldn't break what already works.
4. A curated default experience. Not "here are 49 packages, assemble your own agent."

Suggestion

Consider shipping a curated default distribution — a pre-wired Profile with the most common plugins bundled, tested, and frozen against each other. Let the plugin ecosystem flourish on the side for power users, but give the 95% a one-command experience.

The architecture you've built is a great foundation for ecosystem growth. But ecosystems thrive when the default experience has zero friction. Right now, npx @deepseek-ai/dsh web is close — but the moment a user needs to customize anything, they're in dependency hell.

This isn't criticism — it's a heads-up from someone building in the same space. The "everything is a plugin" approach is a bet on developer adoption. Just don't forget the users who'll never read the docs.

[phinn]

可以使用开源的KinetAios去接入Deepseek的大模型去做Deepseek harness的开发。这样就不用被Codex嘲笑用Codex开发了Deepseek的harness了。

[Electricitysheep]

"Everything is a Plugin"的用户侧成本是个很实在的观察——插件化给了自由，但也把"理解系统如何组装"的成本转嫁给了用户。我们手册第 3 章写过类似判断：profile = 可定制骨架，代价是新手要理解 bundle/插件/扩展点这些抽象。

对普通用户，官方预设（标准/PTC/极简/创造）就是"免组装"入口；对开发者，49 包 + Cordis IoC 是深度定制的乐高底座。两种用户对"插件化成本"的感受完全不同，这也是手册分新手/进阶两条线的原因：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/03-profiles.md

[shinjiyu]

「一切皆插件」的用户侧成本是真的。官方已经把配置层组合和内存里试验（创造模式）做完了。

我们补的是试验之后怎么落盘，而不是再做一个内核：deepseek-harness-evolver。只允许 kind: tool，前 3 次固化要确认。不替代创造模式。

[weijiafu14]

这个“插件能力很强，但不该把组装成本甩给用户”的判断很重要。我们做 pi2dsh 时把安装面收敛成了 DSH 自己的插件命令：

dsh plugin --profile web add pi2dsh@0.11.0
dsh plugin --profile web add <Pi-package>

第一条为 profile 安装一次兼容引擎，之后任何遵循 Pi 公共扩展 API 的 npm 包都走第二条直接安装；不需要用户写 Cordis overlay、不需要 convert、不生成 bundle、不 fork 或修改插件源码。卸载、升级和 profile 隔离也继续由 DSH 原生插件管理器负责。

我们现在用这条形态在真实 DSH loop 中跑通了视觉、联网搜索/抓取、子代理、长期记忆、工具结果压缩、OAuth 凭证等不同类型的 Pi 包。它不是要替代官方的 curated default，而是验证了一点：生态面可以很大，用户面仍然可以保持“装引擎，再装能力”两条命令，不必让每个插件作者和每个用户都重新理解一遍 Host wiring。