夜雨聆风8月13日，DeepSeek 开源了一个叫 Harness 的产品，GitHub 上 4 天拿了 14.5 万 star。
口号很响亮：一切皆插件。 模型适配器是插件，工具注册是插件，会话存储是插件，沙箱是插件，甚至 agent loop——就是"推理→调工具→回复"这个核心循环——本身也是插件。整个项目 195 个包，没有一个是"内核"，全是 Cordis 插件系统里的平等公民。
评论区很快分成了两派。一派说这是 Agent 框架的未来形态，终于有人把自由度做到极致了。另一派说这是"为了设计而设计"，产品还没做好就先搞架构，本末倒置。
但这个争议让我想到的不是 DeepSeek 的设计对不对，而是一个更尖锐的问题：当一家公司把"一切皆可替换"当作核心卖点的时候，它到底在回避什么？
它回避了"产品决策"
一个不争的事实：2026 年，Agent 这个东西已经不是只拼模型能力了。
Claude Code 为什么好用？不只是因为 Claude 4 模型强。它在 harness 层磨了很久——上下文怎么压缩、文件读写怎么编排、工具调用失败怎么恢复，这些工程层面的东西，需要时间和用户反馈来反复迭代。Codex CLI 也一样，OpenAI 的沙箱安全模型、工具调用链路，每一层都打磨了不少版本。
DeepSeek 的模型能力毫无疑问是全球第一梯队。但 harness 层的成熟度，跟 Claude Code 和 Codex 比，差了一个身位。这不是能力问题，是时间问题。
那怎么办？正面硬刚意味着要做大量的产品决策：默认配置怎么选、工具链怎么排、用户在这个场景下期望什么行为、错误了该怎么恢复……每一个决策都可能被骂，每一个决策都需要用户反馈来修正。
DeepSeek 选了另一条路：我不帮你做决定，你自己换。
这是"一切皆插件"的第一层含义——它把产品决策推给了用户和社区。
这个策略有合理的一面
我觉得，这个选择不是偷懒，是一种聪明的资源分配。
DeepSeek 是模型公司，不是工具公司。它的核心竞争力是模型研发和开源生态运营，不是打磨一个面向终端用户的 coding 产品。让它去做 Cursor 那种"我帮你全定好了"的产品，不是它的基因。
历史上这种"换赛道"策略成功过很多次。Android vs iPhone——Google 不自己做最好的手机，但 Android 让 Google 服务触达了更多设备。WordPress vs 商业 CMS——WordPress 不帮你做设计决策，但它的插件生态让所有人都在用它。Linux vs Windows——Linux 在桌面端从来没赢过，但在服务器端统治了世界。
DeepSeek Harness 的逻辑类似：我不做最好的 Agent 产品，我做让你能组装自己 Agent 的基础设施。社区帮它补全工具生态、各种集成、UI——这些它不擅长的部分。
但"不帮你做决定"本身就是个问题
问题是，大部分开发者不想自己组装一辆车，他们想开一辆车。
你想想自己平时的状态。当你需要一个 RAG 方案的时候，你是想看到"我们支持 5 种后端你自己选"，还是"我们推荐用这个方案，配置如下"？当你需要接一个模型的时候，你是想看到"我们支持一切皆插件"，还是"装一个 starter，改一行配置就能用"？
我猜大多数人的答案是后者。
Cursor 和 Claude Code 的成功恰恰在于：它们帮你做了 90% 的决定，你只需要关注剩下 10%。"一切皆插件"意味着每一个设计决策都是开放的——听起来很自由，用起来很累。
而且这种"累"在 Agent 领域尤其明显。因为这个领域现在还没有"正确答案"。长期记忆该是文件驱动还是向量检索？多 Agent 协作该是 leader-worker 还是对等模式？上下文压缩该自动还是手动？沙箱该用 Docker 还是 K8s？
这些问题还没有共识答案。 而 DeepSeek 的解法是：我不告诉你答案，你自己插一个插件试试。
插件架构最大的价值，是在架构已经稳定之后——当大家都知道一个框架该有哪些组件、边界在哪里的时候，"可替换性"才有意义。现在大家还不知道 Agent 框架该长什么样，"一切皆可插拔"有点像在房子还没设计好的时候就开始讨论换哪个房间的门锁。
它回避了生态治理
这是我觉得最值得关注的一个问题。
"一切皆插件"在架构上很漂亮，但在生态治理上是个噩梦。而且这不是假设性的担忧——npm、VS Code、Chrome 扩展、WordPress 插件，全都经历过生态混乱带来的安全事件。
AI 时代，写一个插件的门槛大幅降低了。一个人借助 AI，半小时就能写出一个能跑的 DeepSeek Harness 插件。但测试覆盖呢？边界处理呢？错误恢复呢？不存在的。
更要命的是，DeepSeek Harness 里连 agent loop 本身都是可替换的。这意味着一个恶意插件不只是偷数据，它甚至可以改变 Agent 的推理行为。Agent 做了一个你不期望的操作，你查半天都查不到原因，因为问题出在一个你信任的第三方插件里。
DeepSeek 目前的安全模型基本等于 npm 的安全模型：你信任一个 npm 包，就像你 `npm install` 任何一个包一样。没有 marketplace、没有插件签名、没有审核流程。在一个小范围的开发者社区里，这勉强够用。但如果 14.5 万 star 的社区真的开始大量贡献插件，治理能力就必须同步跟上。
这不是"以后再说"的事。生态治理的速度一旦落后于生态扩张的速度，一次安全事件就可能让整个平台的信誉归零。
它还回避了一个用户群的问题
最后说一个比较现实的事：195 个包全是 TypeScript/Node.js。
Agent 框架的核心用户是谁？企业级场景的主力是 Java 开发者，AI/ML 社区的主力是 Python 开发者。而 TypeScript 的主要人群是前端和全栈工程师。
这意味着能贡献 DeepSeek Harness 插件的人，被限定在了一个跟 Agent 框架核心用户群不太重合的圈子里。不是说前端/全栈开发者不能用 Agent，而是说他们不是 Agent 框架最典型的深度用户和生态贡献者。
AgentScope Java 版的 Channel 适配器里有钉钉、飞书、企业微信、GitHub、GitLab。这些集成能落地，是因为它的用户群就是做企业系统集成的人。DeepSeek Harness 选 TypeScript，这个用户画像就完全不一样了。
技术栈的选择本身没有对错，但它决定了谁能参与、谁会用、谁会贡献插件。14.5 万 star 里有多少人真的会去写插件，这个转化率可能是 DeepSeek 需要认真面对的。
所以它到底在回避什么？
说回来。我觉得 DeepSeek 没有在"回避"什么阴暗的东西。它面对的是一个真实的困境：模型能力全球领先，但 harness 层追不上，正面硬刚的性价比太低。
"一切皆插件"是它对这个问题给出的答案——我不做最好的产品，我做最灵活的平台，让社区来帮我。
这个策略有合理的一面。历史上类似的策略成功过。
但它也带来了三个真实的回避：回避了产品决策（不帮你选默认方案）、回避了生态治理（插件质量和安全还没机制保障）、回避了主力用户群（TypeScript 技术栈把 Java/Python 开发者挡在了门外）。
这三个回避能不能解决？也许能。社区可能用脚投票帮它做决策，生态治理可能随着规模增长逐步建立，技术栈的限制可能被足够好的文档和工具链抵消。
但"也许能"不是"已经解决了"。DeepSeek 的开发者预览声明里写得很清楚："核心插件和基础 API 将持续迭代，THERE WILL BE COMPATIBILITY-BREAKING CHANGES。"这句话翻译一下就是：我们还不确定这个东西到底行不行。
一个更大的问题
其实这个争议指向了一个更根本的行业问题：Agent 框架的终局，到底是"一个最好的默认产品"还是"一套最灵活的组装工具"？
有意思的是，这两条路可能在趋同。Claude Code 最近也在往插件化方向走，AgentScope Java 的 Middleware 机制本质上也是一种可扩展的架构。而 DeepSeek Harness 自己也需要一套"标准模式"作为默认配置，否则用户根本无从下手。
也许最终的答案是：产品做到极致需要插件化，插件做到极致需要一个"正确默认值"。殊途同归，只是出发点和节奏不同。
DeepSeek 选了一条激进的路。不管最终成不成，"一切皆插件"这个命题本身值得认真对待。行业需要有人做这种探索——哪怕最后证明走不通，也能帮所有人搞清楚边界在哪里。
只是 195 个包全是插件这件事，我还是觉得有点过于勇敢了。