作者 | 褚杏娟
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 服务器、模型路由、Agent 预设和本地依赖。一旦升级过程中配置被覆盖，损失的就不仅是某个插件，而是此前积累的整套工作环境。
因此，插件生态还需要可靠的版本管理、依赖检查、配置保护、自动备份和故障回滚机制。尤其当 Agent 开始承担更复杂的工作时，用户对工作环境稳定性的要求会越来越高。
开发者扶持，着手建设插件市场
此次 DeepSeek Harness 公布的开发者支持计划，正是围绕生态持续建设展开。
官方表示，未来将进一步提升插件 API 的稳定性与兼容性，完善插件安全机制，并建设官方插件市场，让开发者能够更方便地上传插件，用户也能够更容易地发现和安装所需功能。
在开发者激励方面，DeepSeek Harness 正在筹备专门面向插件作者的支持计划，初步考虑通过 Token 激励、技术交流和作品推荐等方式，支持开发者探索新想法、持续完善已有作品。
不过，Token 激励能够降低开发者探索和测试的成本，却不能直接保证插件质量；作品推荐能够提高插件曝光度，也不意味着插件一定具备长期维护能力。对于平台而言，如何让开发者获得持续收益，让用户能够找到真正可靠的插件，并让不同插件在同一个 Agent 环境中稳定协作，才是生态能否持续发展的关键。
DeepSeek Harness 目前已经初步形成了用户和开发者生态规模，下一阶段需要建立一套让插件持续运行、相互兼容并且容易使用的基础设施。官方插件市场除了提供分发渠道，还需要考虑插件审核、质量评级、版本兼容、权限管理和安全提示。否则，插件数量越多，用户筛选和维护的负担也可能越重。
