装了 15 个插件后,我的 Agent 变笨了

DSH 用 154 万日活证明了插件生态的胜利，也用同一批数据证明了它的代价

上周，一位开发者做了件反直觉的事。

他把自己 Agent 里 15 个以上的插件，一个一个删掉了。

这些插件没有一个是坏的：看板、主题、记忆、浏览器连接器，每一个都曾解决过具体问题。可装到第 15 个之后，他的 Agent 开始出现一种奇怪的症状——无限循环、上下文溢出、Token 消耗暴涨。

他试过调参，试过换模型，最后发现病灶不在别处：他把一个助手，装修成了一间堆满工具、连转身都困难的房间。

这件事发生在 11 月 5 日。同一天，DeepSeek Harness 公布了也许是它今年最漂亮的一份成绩单。

一、一边是 154 万日活，一边是有人在删插件

先看官方数据。

截至 11 月 4 日，以使用官方 API 的用户为统计范围，DSH 日活跃用户 154 万，日消耗 Token 约 92 万亿。第三方插件数量约 3.5 万个，约 60% 的活跃用户制作或安装过至少一款第三方插件。

从 8 月 13 日发布 v0.1 到今天，不到三个月。这个速度，放在任何开发者生态里都算得上凶猛。

官方给 DSH 的定位也很清楚：做 Agent 时代的操作系统。基础能力和通用功能由平台提供，专业场景、垂直行业、个性化需求，全部交给插件。

甚至更激进——「一切皆插件」，连内置功能都可以被第三方替换。

这是一个极具诱惑力的承诺。用户不再接受厂商预设好的工作流，而是自己拼装模型、工具、记忆和界面。有人分享过，自己从 Hermes 加 OMP 的组合换到 DSH，加了看板、主题、Token 优化、记忆、视觉连接器和浏览器，不到一天就搭出了一套完全贴合自己习惯的环境。

但同一个故事，还有 B 面。

插件越多，Agent 真的越强吗？

那位删插件的开发者给出的答案是：不一定。

他的原话大意是，每多一个插件，模型就多了一份要读的说明书、使用规则和约束。当大量插件信息同时进入上下文，模型不得不把注意力花在「怎么用工具」上，而不是「怎么解决问题」上。

他甚至提出了一个更尖锐的判断：插件越多，Agent 的自由度未必越高。过多的预设工具和规则，反而可能限制模型自主解题的空间。

这句话值得所有 Agent 重度用户停下来想一想。

二、插件税会带来哪些代价

我把这件事拆成三层，你会发现它不是「配置没调好」，而是一种结构性成本。

第一层：插件说明会占用上下文的注意力。

插件不是装上去就完事的。每一个插件都要向模型交代自己是谁、能干什么、什么时候用、参数怎么填。这些说明、规则、约束，最终都会变成上下文里的 Token。

一个插件几百 Token，十几个插件就是几千 Token。听起来不多，但上下文的总量是固定的：工具说明多占一分，任务推理就少一分。模型不是在真空中思考，它是在你给它的那几千字里思考。

第二层：选择本身就是负担。

工具越多，模型越容易在「该用哪个」上打转。选错，就要重试；重试，就要重新读一遍上下文。一次犹豫，在 Agent 的循环里会被放大成三四次工具调用。

那位开发者遇到的「无限循环」，本质上就是这种选择困难被放大后的结果——模型在两个功能重叠的插件之间来回试探，直到把上下文撑爆。

第三层：一次失败会带来一连串连锁成本。

Token 消耗不是线性的。一次错误的工具调用，会带来一次失败的返回、一次纠错、一次重跑。有用户反馈，用 DSH 完成一个小项目，Token 消耗超过 OpenCode 的 20 倍，单个任务耗时 30 到 40 分钟，而 OpenCode 大约 30 秒。

这是个例，不能当作普遍结论。但它至少说明了一件事：当 Agent 变复杂，成本的曲线不是加法，是乘法。

三、比「删插件」更重要的信号：官方正在补上这些成本

如果只是用户在抱怨，那这只是一篇吐槽文。真正值得写的是，DSH 的版本迭代里，藏着一整条「还债」的线索。

把最近几个版本连起来看，方向非常清楚：

10 月 15 日到 23 日，插件管理能力密集更新——自定义插件索引、版本兼容性检查、插件启停与卸载、依赖同步、热重载，还增加了让 Agent 辅助创建插件的入口。

同一个阶段，v0.2.1-rc.1 开始支持极简模式下的长对话自动压缩，Web 和桌面端也能用 /compact 手动压缩上下文。

10 月 28 日，v0.2.2-alpha.2 支持第三方插件包更新，热更新失败时尝试回滚旧版本，并加入实验性的开发者统计插件——可以查看上下文、缓存、模型和工具耗时。

11 月 4 日，v0.2.2-rc.1 优化了 Auto 审核在连续工具调用之间的历史缓存复用，切换小上下文模型前先用原模型压缩历史，并给全局和项目级的 AGENTS.md 设置了独立字节预算，减少指令互相挤占。

你注意到没有：压缩、回滚、耗时统计、字节预算——这四个动作，全部指向同一件事，就是上下文成本。

这不是巧合。这是平台在承认：插件带来的那份「税」，是真的。

社区里还有人给出了更彻底的建议：借鉴 Pi 的选择性披露机制，只在需要的时候，才把对应插件的说明交给模型，而不是让所有插件信息常驻上下文。

这句话如果被采纳，会是 DSH 插件架构的一次真正升级。

四、但这篇文章并不打算只劝你少装插件

写到这里，很容易滑向一个廉价的结论：插件要少装，人要自律。

我不太同意。

社区里有一种反驳很有力：在不影响核心能力、不引发回归问题的前提下保持精简，是可以的；但插件组合的第一责任人，本来就是用户自己。「我想省 Token，我就不会去装活跃气氛的插件。你不能因为家里没装修好，就怪开发商卖你毛坯房。」

这话说得刻薄，但站得住。

问题从来不是「插件太多」，而是「插件的信息没有按需出现」。

一个健康的插件体系应该像人的工具箱：柜子里可以有一百件工具，但你伸手的那一刻，只需要看见那一件。真正的解法在平台机制里——选择性披露、按需加载、工具分组、上下文预算——而不是把责任推给用户的自觉。

所以，在平台补齐这套机制之前，我给重度用户三条能立刻用的建议：

第一，按任务域拆配置，别混在一起。

写作、编程、科研，是三套不同的环境。让它们共用一个装满 15 个插件的配置，等于让一个厨师同时开三家店。

第二，只留「每周用三次以上」的插件。

用不到三次的，不是能力，是负担。装上去的那一刻很爽，之后的每一次调用，都在为它付费。

第三，每月做一次插件审计。

用官方那个统计插件，看两件事：哪些工具最耗时，哪些插件从来没被调用过。前者是优化点，后者是删掉的对象。

写在最后

DSH 的这三个月，是中国 Agent 生态里少见的一次「平台级开放」实验。3.5 万个插件、60% 的用户参与度，这些数字说明它做对了一件很难的事：让开发者愿意为它写东西。

但生态的成熟，从来不靠数量。

一个插件平台的成年礼，不是插件数破十万，而是它终于开始认真对待「装得越多、用得越差」这件事。

对平台来说，这是架构问题；对开发者来说，这是产品质量问题；对我们这些每天用 Agent 干活的人来说，这是一个更朴素的问题——

你到底是在给自己配一个助手，还是在给自己造一间仓库。

Agent 的能力上限，从来不取决于你给它装了多少工具。

而取决于它在需要的那一刻，能不能只看见那一件。