DeepSeek 在 8 月中旬把 deepseek-harness 以开发者预览开源，口号只有一句：Everything is a plugin。仓库热度起来得很快，讨论也分成两派——架构党觉得终于有人把 harness 拆干净了，务实党在问：插件化之后，配置和排障成本谁扛。
我更关心后半句。模型周刊已经够多了；能换的是循环、工具、沙箱和会话怎么拼。
Harness 在抢什么位置
2026 年的 Agent 产品，很少再是“一个 chat 框 + 几个 function call”。常见形态是：
- 模型可切换（便宜模型跑日常，贵模型升级）
- 工具面按租户/角色裁剪
- 会话与记忆可持久化、可回放
- 沙箱与出站策略在控制面，而不是写在 prompt 里
- 循环策略（单 agent / 多步 / 调度）可替换
DeepSeek Harness（dsh）把这些能力都挂到 Cordis 的插件体系上：模型、工具、skills、session、sandbox、storage、loop、调度、甚至 UI，都是插件。官方说法是没有必须去改的“特权内核”，运行实例是一棵可组装的服务树。
这对做 harness 的人很友好：你要换一套工具协议或换存储，理想路径是加插件，而不是 fork 主仓打补丁。
插件化真正贵的地方
“一切皆插件”对贡献者是蜜糖，对最终集成方常常是配置税。GitHub discussion 里已经有人点出：终端用户看到的是旋钮变多，而不是架构变美。
落地时我会强制自己回答四件事：
1. 默认装配长什么样
没有 opinionated 默认的插件平台，等于把集成测试甩给每个团队。预览阶段可以松；要进产品，必须有一条“开箱能跑完主路径”的 profile：模型 + 工具白名单 + 会话存储 + 基础沙箱。
2. 插件边界的失败语义
工具超时、鉴权失败、沙箱拒绝，是结构化错误还是一段自然语言？Agent 控制面最怕半失败：模型以为成功了，副作用只做了一半。插件接口若没有机器可读的错误码和可重试标记，上层路由全是糊墙。
3. 权限与身份在哪一层
插件能注册工具，不代表工具能碰生产密钥。身份应在 harness 外或 harness 的硬边界上完成：租户、用户、代理服务账号分离；插件只拿到裁剪后的凭据句柄。前几周业界关于 agent 越界、评测沙箱“跑出去”的讨论，核心都是控制面，不是模型智商。
4. 一次 run 能否完整回放
插件一多，线上问题会变成“当时加载了哪组插件、哪版 skill、哪条 loop 策略”。trace 若只记模型 token，不记插件图，就等于没有可观测性。Harness 宣传里 “every run is traceable” 值得当成验收项，而不是 slogan。
图：明亮实验室风格的工作台，模块化硬件块与线材整齐排列，示意可插拔组件
和现有栈怎么处
如果你已经在用自研循环、LangGraph 一类编排，或 MCP 工具网关，不必看见新 harness 就迁移。更现实的用法：
- 对新实验线：用
dsh快速拼一条可替换工具/模型的原型，验证产品假设。 - 对生产主链：继续稳住你的控制面（鉴权、配额、审计、出站），把 harness 当可替换的执行引擎候选，而不是唯一真相源。
- 对插件作者：先看官方 architecture / AGENTS 文档，搞清服务与事件怎么协作，再写业务工具；避免在插件里偷偷做全局单例。
和上周讨论的 MCP 工具协议、Agent 沙箱收敛是同一条河的两岸：一边是“工具怎么被描述和调用”，一边是“运行时怎么组装和隔离”。Harness 插件化解决的是组装；协议与策略解决的是协作与安全。两边缺一，都只是半成品。
我会怎么试
- 源码或
npx起官方 web 预览，跑通最小对话与一个自定义 tool 插件。 - 故意关掉沙箱插件或收紧出站，看失败是否可观测、可配置。
- 换一个模型插件，确认会话与工具层不用改业务代码。
- 导出一次 run 的 trace，检查能否回答：谁调了什么、为何重试、最终状态是什么。
- 只有这四步都顺，才考虑接到内部账号体系。
小结
DeepSeek Harness 把“Agent 运行时 = 插件图”摊开了，这是好事。别被 Everything is a plugin 催眠：你真正要交付的是默认装配、失败语义、身份边界和可回放的 run。模型可以明天换；控制面的债会留很久。
仓库：https://github.com/deepseek-ai/deepseek-harness
介绍：https://deepseek.com/harness/en/
