DeepSeek Harness：当 Agent 学会“自己组装自己”
一个开源框架如何重新定义 AI 与代码的关系
2026 年 8 月 13 日深夜，DeepSeek 在发布 V4 Pro 正式版几个小时后，悄悄开源了一个叫 DeepSeek Harness 的项目。命令行工具名 dsh，MIT 协议，仓库挂在 GitHub 上。
当时没人能预料到接下来发生的事。
发布半小时内，GitHub Star 破万。24 小时内突破 5 万。五天后，14.9 万。社区在五天里开发了超过 5100 个插件，涉及 3500 多位作者。国家超算互联网在 8 月 15 日宣布上线它，腾讯 QQ 在同一天宣布接入它。
一个“Agent 运行时框架”——这个听起来有点抽象的定位——为什么能让开发者社区如此疯狂？
答案藏在一个公式里：Model + Harness = Agent。
一、Harness 到底是个什么东西
理解 Harness，可以从一个直白的比喻开始。
模型是一匹马力很强的马——它能跑、能拉车、能理解复杂指令。但你没法直接骑它上路，你需要缰绳、挽具和车厢。Harness（挽具）就是那一整套把马力转化为“实际载具”的东西：它连接模型与文件系统、终端、网页、API、权限、计划、上下文。
DeepSeek 官方给出的定义很清晰：Harness 是“Agent 的执行神经系统”。模型负责“思考和生成”，Harness 负责“把思考接入现实世界”。两者合起来，才是能自主行动、把任务真正干完的 Agent。
这和 Claude Code、Codex 有本质区别。Claude Code 和 Codex 是成品——模型、工具、Agent 循环被厂商深度封装进一个壳里，用户拿到的是一套配置好的“精装房”。而 DeepSeek Harness 是底盘——它把房子的施工图和所有预制件都开源了，并告诉你：墙随便拆，零件随便换。
这个定位差异，决定了后面所有事情。
二、核心原则：一切皆插件
“一切皆插件”听起来像是一句营销口号，但在 DeepSeek Harness 里，它是字面意义上的工程现实。
官方架构文档列出的最核心七个包——Session（会话日志）、System Prompt（系统提示组装）、Tools（工具系统）、Agent（Agent 注册与接口）、Agent Loop（智能体循环）、Scope（作用域注册）、LLM（模型适配接口）——在传统 Harness 中都属于“不更新版本不会动的核心组件”。但在 DSH 里，它们全部是插件。
再往外展开，默认模型选择、持久化存储、Sandbox、审批策略、设置、凭据管理，也都是插件。甚至前端 UI 组件也是插件。
这意味着什么？意味着没有“特权核心”。官方架构文档的原话是：“不存在需要打补丁的特权核心：你通过把插件挂载到其他插件旁边来扩展 dsh。”
2.1 Cordis：让“可逆”成为基建
这套插件体系的底层是 Cordis，一个基于时空可组合性理论的元框架。Cordis 只提供六种最基础的操作：装一个组件（use）、记录一次可撤销修改（effect）、提供一种能力（set）、读取一种能力（get）、隔离一种能力（isolate）、加一层使用规则（intercept）。
剩下的事情由 Runtime 自动完成。关键机制是“可逆副作用”：
每一次插件对共享环境的修改，都会向 runtime 返回一个对应的逆操作。插件卸载时，runtime 按相反顺序执行这些逆操作，把插件留下的一切痕迹干干净净地撤销。
传统插件框架卸载插件时，需要开发者手动清理自己注册的 listener 或 timer，漏一个就是内存泄漏。Cordis 把这类注册动作统一包装成可撤销的操作，卸载时由框架自动回滚。
这带来的直接收益是：热替换是安全的。换掉一个模型适配器、替换一个工具，不需要重启整个进程。依赖被替换服务的插件会自动重新加载，不依赖的插件完全不受影响。
2.2 三种核心抽象
理解了 Cordis 的约束，再看 Harness 内部如何组织代码。三个概念反复出现：
Context（上下文）：所有插件共享的同一个实例，承担服务注册、事件发布/订阅的职责。可以理解成一条共享的服务总线。
Service（服务）：插件向外暴露能力的出口。插件把具名服务挂到 ctx 上（例如 ctx.tools），其他插件按 key 消费，不关心实现方是谁。
inject（注入）：插件声明自己依赖哪些服务，例如 inject: ['tools']，表示“等 ctx.tools 就绪后我才启动”。
三者组合成一张依赖图，Cordis 据此自动调度加载和卸载顺序。
三、四种模式：一套框架，四种用法
DeepSeek Harness 预置了四种运行模式，每种模式自动加载不同的插件集：
标准模式：功能完整的编码 Agent，涵盖文件编辑、Shell 访问、网页搜索、Skills、计划模式、子代理和工作流。这是“默认的那套”。
PTC 模式（程序化工具调用）：在标准模式基础上增加 Code Mode SDK。模型不再逐个调用工具，而是生成 TypeScript 程序来组合多步操作，将原本需要五次往返的调用压缩为一次执行。
极简模式：仅保留两个工具——持久化 bash 和字符串替换编辑器。这正是 DeepSeek V4-Pro 模型卡脚注中标注的、厂商运行代码智能体基准测试所用的 Agent 框架。
创造模式：在标准模式全部能力之上，提供运行时检查、Cordis 插件实验和预设编写指导。开发者可以用它来创建自定义 Agent 预设——相当于“用 Agent 造 Agent”。
一个值得注意的细节：四种模式全部由插件组合定义，模式本身不是硬编码的枚举值，而是“一套预先配置好的插件清单”。
四、会话日志：模型看到的一切，都可以回溯
DeepSeek Harness 的 Session Event Log 有一个硬性约束，被写成仓库级架构不变量：
任何进入模型请求的信息，都必须能够从 Session Event Log 重建。
这意味着 Loop 不维护一份独立的、可偷偷修改的 conversation array。用户消息、助手消息、工具调用、工具结果——全部由事件日志派生。原始 assistant/chunk 保留 UI 与回放细节，但不会作为重复消息进入模型请求。
配套的 Trajectory 视图让开发者可以按来源追溯：哪些系统提示词段落被激活、每次工具调用的输入和返回、模型的原始响应（含思维链）、每个步骤的耗时。
找到问题节点后，可以从该节点 Fork 出新会话，修改配置后重新运行，而不需要从头开始整个任务。 这种“在任意步骤分叉重放”的能力，是传统 Harness 做不到的。
五、真实的落地场景：DSH 到底能干什么
5.1 跨仓库大规模代码迁移（Headless 批量模式）
将大型 TypeScript 项目从 fetch API 迁移到内部 HTTP 客户端，涉及 200 个文件。使用 Headless 模式逐文件批量运行，每次任务独立会话。
5.2 Agent 行为取证调试
Agent 完成复杂重构后，某个中间步骤出错。在 Trajectory 视图里定位到问题节点，从该节点 Fork，修改提示词后重新运行。
5.3 把 Claude Code 和 Codex 当子 Agent 编排
DSH 内置了将 Claude Code 和 Codex 作为子 Agent 调用的 Provider——通过解析 PATH 里的对应二进制实现委托。一个复杂任务可以：前端样式调整交给 Claude Code，后端 API 重构交给 Codex，整体编排用 DSH。
5.4 自定义 Agent Preset
团队需要一个专门做 API 文档生成的 Agent：固定工具集（只读文件 + OpenAPI 解析脚本），固定模型（长上下文擅长结构化输出），固定系统提示词。在 Creator 模式里写成 cordis.patch.yml，提交到仓库，团队成员直接使用。
六、代价与注意事项
DeepSeek Harness 目前仍是开发者预览版，官方明确提示：存在破坏兼容性变更的可能，会话格式不提供兼容承诺，升级后旧会话可能无法读取。建议用于评估和内部试验，不适合作为唯一的生产工具。
官方安全说明也强调：DSH 尚未接受安全审计，沙箱、审批与权限控制不能保证隔离。
此外，DSH 目前不接受外部代码贡献，鼓励的是 GitHub Discussions 和插件开发。
七、真正的野心：自进化的 Agent 运行时
如果只看到“可替换的插件”，会低估 DeepSeek 的野心。
与 DSH 一同被摆上台面的，还有一篇由北京大学和 DeepSeek-AI Harness 负责人崔添翼共同完成的论文《A Programming Paradigm for Spatiotemporal Composability》。论文中提出的模式与 DSH 架构基本一致——它是理论基础，DSH 是工程验证。
DSH 最值得注意的包是 @deepseek-ai/dsh-tool-cordis，官方称之为“自指的 Cordis 工具集”。它给 Agent 提供五个工具：
cordis_inspect：对当前进程只读巡检——哪些服务在运行、注册了哪些工具cordis_define：现场定义一个小插件包cordis_run：把插件放入沙箱执行cordis_stop/cordis_undefine：卸载动态包
Agent 可以检查自己运行的框架、现场编写并运行动态插件、用完再卸载——全程不动配置文件、不装 npm 包、不重启进程。
配合“双半插件”设计（宿主半跑在服务端管逻辑，浏览器半跑在网页里管 UI），DSH 的“一切皆插件”在字面意义上成立：前端 UI 组件也是插件，浏览器里运行着一个独立的 Cordis 客户端运行时。
自省 + 现场改装——这是“可进化 Agent”的雏形。论文的结论部分恰好把“自进化 Agent 运行时”列为这套理论未来的验证方向。
八、DeepSeek 为什么做 Harness
这件事需要和同一周发生的另外两件事放在一起看。
第一件：V4 Pro 正式版。相比预览版，正式版重点补齐的是 Agent 能力——工具链式执行、软件工程任务、长任务持续工作。一句话：模型本身正在为“被放进一个强 Harness 里持续干活”做准备。
第二件：API 涨价。V4 系列改为峰谷分时计价，高峰时段价格明显上浮。当价格优势缩水，DeepSeek 更需要从“卖模型”升级到“卖模型 + 执行层”。
Harness 是这场升级的载体。
九、和你的 PAOS 的关系
DSH 的“一切皆插件”和你 PAOS 的“各组件各司其职”是同一个方向：WeClaw 负责连接与编排、Knowly 负责记忆、yuangs 负责执行。而 DSH 提供的是一个可被定制、可被替换的 Agent 运行时底座。
它的“Seam（能力接缝）”设计尤其值得关注：只要插件实现了同一个 Seam 接口，就能零侵入地替换系统能力。这意味着你可以把自己的组件以插件形式接入 DSH，而不需要修改它的源码。
“Agent 可以检查自己、现场改装自己”——这个能力，恰好是你一直在做的事：用工程化方法，把 AI 从辅助工具推向生产力跃迁。
结语
DeepSeek Harness 的爆火，本质上是一个被长期忽视的需求终于被看见了：
AI Agent 不应该是一个被厂商封装死的黑箱。它应该是一个可以被理解、被检查、被改装、被进化的系统。
当每一个组件都可以被替换，当模型看到的一切都可以被回溯，当 Agent 可以检查并改装自己的运行时——Agent 就从“工具”变成了“可成长的系统”。
Model + Harness = Agent。
而这个等式里，Harness 才是那个真正决定 Agent 能走多远的变量。