DeepSeek Harness 0.2.1：插件成了主角
原创 · 约 14 分钟阅读 · 阅读 --

DeepSeek Harness 0.2.1：插件成了主角

作者: Alex Xiang

人工智能工程实践

本文完全由 WorkBuddy 独立收集资料、调试代码并完成文章写作。

扫码注册 WorkBuddy 即可获取 2000 积分

我是 Alex Xiang，前百度/微博工程师，现在专注于 AI 工程与工具产品。更多文章欢迎关注微信公众号「字与码」。

10 月 17 日，DeepSeek 同一天发了两样东西：V4.1-Flash-1017 模型，和 DeepSeek Harness 0.2.1-rc.1。前者是跑分选手，后者才是这次更新的重点——它把插件从「能装」推进到「能分发、能生产、能热更新」。

0.2.1 改了什么

官方 changelog 很长：二十项新增、二十余项体验优化、三十多项修复，另有十五条破坏性变更。压缩成一句话：插件系统从「功能扩展」升级成了「应用平台」。

具体有三件事值得单独拎出来：

  • 自定义插件索引源。以前只能从官方列表装，现在可以指向任意索引。团队可以搭私有插件市场，社区也能做自己的目录。
  • 让 Agent 创建插件。插件管理页新增入口，保留草稿进入创造模式，发送需求后由 Agent 写插件。
  • 依赖同步与热重载。启用、停用、卸载、更新都会同步 npm 依赖；可热重载的插件改完立即生效，不能热重载才提示重启。

其余是体验补齐：极简模式支持读图和自动压缩（/compact）、UI 里直接配每个模型的推理等级、全局 AGENTS.md、working_directory 工具、SSH helper、密钥脱敏、Web 端本机 HTTP 登录。

还有五个实验性插件：Claude Code Mods 兼容层、开发者工具包、思考过程机器翻译、Git Worktrees，以及插件的 Session 状态接口。

其中最值得注意的反而是最后一条：Session 状态接口让插件可以自己写入和读取会话记录。这意味着插件从「无状态工具」变成了「能跨轮次积累状态的应用」。把它和自定义索引、Agent 创建插件放在一起，平台的三块拼图就齐了——供给、分发、状态。

插件从「装」变成「分发」

这三件事单独看都不新鲜，合起来才是变化。

自定义索引解决的是供给端的分发——谁都能建目录，官方列表不再是唯一入口。Agent 创建插件解决的是供给端的产能——写插件的人不必先学会整套 API。依赖同步和热重载解决的是运维——插件终于能像 npm 包一样迭代，而不是装完就锁死。

这正是 VS Code 扩展市场走过的路：先有扩展 API，再有市场，最后生态比编辑器本身更重要。DeepSeek 把这条路压缩到了两个月——8 月 13 日开源，到 10 月中，仓库约 25 万星、3 万 fork，第三方插件目录宣称收录八千多个条目。

但和 VS Code 有一个关键区别：插件跑在 Host 进程里，不受 Agent 沙箱保护。官方文档写得很直白，Mod 能访问进程环境、网络、文件和 Harness 工具，只应安装你愿意当作本地代码执行的插件。「让 Agent 创建插件」把这条风险又推高一层：供给变容易，审查就得变重。

同一天，模型开始为「壳」做专项优化

另一个容易被忽略的信号，是新模型和 Harness 的绑定。

官方说法是：V4.1-Flash-1017 在训练中针对 DeepSeek Harness、腾讯 CodeBuddy、WorkBuddy 做了专项优化，在提升任务表现的同时，缩短运行时间、减少输出消耗。Harness 0.2.1-rc.2 的第一条更新就是「适配 V4.1-Flash-1017」。

这句话的分量比跑分重。过去模型厂优化的是通用能力，壳是壳、模型是模型；现在训练阶段就把某个 harness 的工具调用习惯、上下文组织方式当成环境的一部分。所谓「许愿式编程」——用自然语言描述需求，Agent 少交互几轮直接交付——本质是模型学会了在特定壳里少绕路、少说话。

同一天开放的 Search / Fetch API 是同一套逻辑：5 元/千次，11 月 1 日前在 Harness、Claude Code、Codex 里调用免费。Agent 要完成任务，缺的从来不只是脑子，还有搜索、抓取、执行、验证这些外围能力。

评论为什么两极

海内外对 DSH 的评价一直分裂。

海外开发者更愿意看架构。Composio 做过一次跨 30 个真实 SaaS 任务的盲测：同一模型下，DSH 完成率略高于 Claude Code，但每个任务只消耗 8.8 万 token，约为后者的七分之一。Pi harness 作者 Mario Zechner 的评价更克制——单插件热重载和生命周期闭环「极为精巧」，但跨模块依赖注入在深水区有风险。

国内用户的抱怨更直接：慢、费 token、界面不直观。一位用了半个月的开发者列了几个具体问题：插件之间互相踩，上下文压缩插件每次启动都报路由重复注册；MCP 配置「改了没报错但也没生效」，几天后翻 dump 才发现；长上下文并不总是更好，旧信息会稀释注意力。

更硬的成本反例来自 GitHub：有开发者晒账单，同一个工程任务，竞品花几元，DSH 因为并发派生子 Agent 打碎了 KV Cache 前缀，所有请求退化成未缓存计费，成本翻十倍。还有人遇到 Windows 路径解析失误导致的静默删除。

这些不是「好不好用」的分歧，而是用它做什么的分歧。短任务看交互，长任务看架构；单会话看响应速度，多会话看上下文管理。同一套设计，在不同用法下会得到相反的评价。

平台化的代价

0.2.1 有十五条破坏性变更，密度不低：移除运行时 invariant 插件和各包的 ./invariant 导出；子路径插件不再读独立 package.json；输入区统计拆成 activity 和 usage；工具展示只保留 native / ptc；Azure provider 改名；Agent Team 消息改为直投 Inbox。

对一个 rc 版本，这很正常——平台在定型，接口就得动。但对打算把它放进团队工作流的公司，这是实打实的迁移成本：每升一次版本，都要重新核对插件、配置和 SDK。

所以 0.2.1 的定位很清楚：它不是在做一个更好用的编辑器，而是在抢 Agent 运行时的生态位。功能可以抄，插件网络抄不走。代价是它必须先把 rc 期的破坏性变更熬过去。

现在值得升级吗

个人开发者值得试。自定义索引和 Agent 创建插件把折腾插件的门槛降了一大截，新用户还有 6 元赠金，够跑一阵。

团队采用建议再等一个版本。不是功能不够，而是十五条破坏性变更加上插件不受沙箱保护，现在进场约等于替它做兼容性测试。

真正要盯的是另一件事：当插件可以自建索引、由 Agent 生成、还能热更新时，「装插件」这个动作的风险已经接近「执行一段陌生代码」。谁能把审查、版本锁定和权限边界做好，谁才拿得走这波生态红利。

参考资料

打开原图 ↗