DeepSeek Harness日活154万，官方开始给插件作者发Token：Agent生态要靠开发者了

11月5日晚，DeepSeek Harness 公布了产品及社区最新进展。截至11月4日，以使用官方 API 的用户为统计范围，DeepSeek Harness 日活跃用户已达到154万，日消耗 Token 约92万亿。与此同时，平台第三方插件数量已增长至约3.5万个，约60%的活跃用户制作或安装了至少一款第三方插件。 DeepSeek Harness 表示，希望成为 Agent 时代的操作系统，为用户提供稳定的基础能力和通用功能，而专业场景、特定行业及个性化需求则交由开发者通过插件实现。其提出的“一切皆插件”设计，甚至意味着内置功能也可以由第三方插件替换。 从8月13日发布 v0.1 版本至今，DeepSeek Harness 正在从一款 Agent 工具向开放式应用平台扩展。社区开发者已经围绕内容创作、设计、上下文管理和科研等场景，开发了大量第三方插件。 不过，随着插件数量增加，新的问题也开始出现：插件越多，Agent 是否真的越强？大量插件说明和工具规则会不会挤占模型上下文，增加执行成本？对于普通用户而言，究竟应该获得自由组合能力的空间，还是一套开箱即用的完整产品？ 高度开放，但插件越多会让Agent越难用吗？ DeepSeek Harness 高度开放的插件架构是其最有吸引力的地方：用户不必接受厂商预先定义的 Agent 工作流，而是可以根据自己的需求组合模型、工具、记忆和界面，搭建一套专属的工作环境。 有用户分享，自己此前主要使用 Hermes 处理通用任务、OMP 进行编程，但两款工具都难以完全满足其定制化需求。转向 DeepSeek Harness 后，他通过插件加入看板、主题、Token 优化、记忆、视觉连接器和浏览器等能力，不到一天就搭建出了一套符合自己工作习惯的 Agent 环境。更让他惊喜的是，同一个 Qwen 3.8 模型此前可能需要24小时才能找到的 Bug，DeepSeek Harness 速度更快。 还有用户正在尝试将 DeepSeek Harness 从单一工具扩展为通用 Agent 工作环境。 例如，有开发者推出 dsh-aio-agent，将 Cursor、Claude Code、Codex、OpenCode、CodeBuddy 和 Kimi Code 等多款编码 Agent 接入 DeepSeek Harness，用户可以在统一界面中选择不同工具执行任务；另有开发者通过 dsh-ltm 构建本地长期记忆系统，支持中文关键词检索、按项目划分记忆召回范围，以及记忆去重、修改和管理。 还有开发者推出 TheOne 插件，通过大模型识别用户消息所属的话题，并自动路由至对应的独立会话，避免多个项目和话题混杂在同一段对话中。还有社区项目使用 ESP32-S3 开发板作为 iPhone 的 USB 鼠标和键盘，同时通过 AirPlay 接收手机屏幕镜像，Agent 可以截图、点击、长按、滑动和输入文字，控制一台未越狱的真实 iPhone。 DeepSeek Harness 的插件生态已经出现了非常多具有实际使用价值的应用。但另一方面，插件扩展能力的同时，也可能增加 Agent 的使用复杂性。 11月5日，一位开发者分享了自己从“一切借插件”到主动删减插件的经历。他表示，自己曾经给 Agent 安装了15个以上的插件，但随着插件数量增加，系统反而出现无限循环、上下文溢出和 Token 消耗增加等问题。 在他看来，每增加一个插件，模型就需要额外理解相应的说明、使用规则和约束。如果大量插件的信息同时进入上下文，模型就不得不花费更多注意力处理工具本身，而不是专注于任务推理。他还提出，插件越多，Agent 的自由度未必越高，过多的预设工具和规则反而可能限制模型自主解决问题的空间。 不过有用户指出，在不影响核心能力、不会导致回归问题的前提下保持精简是可以的，但开发者首先得为自己的插件组合负责。“例如，如果我希望省token，那么我根本不会安装活跃气氛的插件。在我看来，这些例子是转嫁自我责任的，你不能因为家里没装修好，就怪房地产商卖你毛坯房而不是精装房。” 此外，有用户指出，DeepSeek Harness 相比 Pi 的提示词体量偏大，建议借鉴其选择性披露机制，仅在需要时向模型提供对应插件的说明，而不是让所有插件信息始终占据上下文。 类似的担忧也出现在执行成本上。有用户表示，自己使用 DeepSeek Harness 完成一个小型项目时，Token 消耗超 OpenCode 的20倍，单个任务耗时30至40分钟，而 OpenCode 约30秒。这只是个别用户的体验，但至少反映出用户对调用工具成本的关注。 频繁迭代，插件治理远未结束 面对插件管理、上下文成本和使用门槛等问题，DeepSeek Harness 在过去几个月里已经进行了多轮版本迭代。梳理官方 GitHub Releases 可以发现，其优化方向正逐渐从提供插件扩展接口，转向完善插件的发现、安装、更新、依赖管理和运行监控。 10月15日至23日，DeepSeek Harness 连续更新插件管理能力，先后支持自定义插件索引、版本兼容性检查，以及插件启停、卸载、依赖同步和热重载，并增加 Agent 辅助创建插件的入口。同时，v0.2.1-rc.1 开始支持极简模式下的长对话自动压缩，Web 和桌面端也可以通过 /compact 指令手动压缩上下文。 10月28日发布的 v0.2.2-alpha.2，开始支持第三方插件包更新，并在热更新失败时尝试恢复旧版本，同时增加实验性的开发者统计插件，可以查看上下文、缓存、模型和工具耗时；11月3日发布的 v0.2.2-alpha.3，进一步增加插件安装失败诊断和 Host 日志入口，区分安装失败与安装后启用失败，帮助用户定位问题。 11月4日发布的 v0.2.2-rc.1，作为0.2.2系列首个候选版本，汇总了此前多个版本的改进，还优化了 Auto 自动审核在连续工具调用之间的历史上下文缓存复用，并在切换至上下文容量较小的模型时，先使用原模型压缩历史记录；同时为全局和项目级 AGENTS.md 设置独立字节预算，减少指令相互挤占。 从这些更新可以看出，DeepSeek Harness 已经开始回应社区提出的部分问题：插件发现和管理入口更加完善，依赖同步与热重载降低了维护成本，长对话压缩和缓存复用开始处理上下文与 Token 消耗，统计工具则让开发者能够观察 Agent 的实际执行成本。 不过，部分反馈显示，插件更新和配置恢复机制仍然存在不稳定因素。 11月5日，一位 Windows 用户报告，自己将桌面端从 v0.2.1-rc.5 升级至 v0.2.2-rc.1 后，原先配置的32个第三方及本地插件包条目丢失，配置文件中的插件数量从34项缩减至2项。同时，由于一个本地化插件与新版本不兼容，应用首次启动直接失败。由于当时缺少更新前的自动配置备份，客户端也不支持版本回滚，用户只能手动恢复工作环境，整个故障修复过程耗时约5小时。 对于长期使用 Agent 的用户而言，插件不只是一个可以随时替换的小工具。用户可能已经围绕特定插件建立了自己的工作流，配置了 MCP 服务器、模型路由、Agen