DeepSeek 2026 年 8 月开源了 Harness（命令 dsh，MIT 协议，开发者预览版），官方公式一句话：Model + Harness = Agent。模型管推理决策，Harness 管工具怎么调、状态怎么存、循环怎么结束。它和 Claude Code、Codex 的区别不在功能清单，而在这一层本身是不是产品——闭源框架只能通过 MCP"接入"，Harness 把整层开源，并宣称一切皆插件：模型适配器、工具注册表、会话、沙箱、存储、调度、UI 乃至 Agent 循环，全部可配置替换。
内核：可逆的上下文变换
插件体系建立在 Cordis 之上——一个 TypeScript 插件元框架（Koishi 框架作者出品，被 DeepSeek vendor 进仓库），设计思想有论文背书。论文把动态组合拆成两个正交维度：
时间可组合性：组件被移除时，它对共享环境的副作用必须完整逆转。实现方式是"可逆 effect"——每次注册服务、挂监听器、占资源，运行时都登记一个逆操作，卸载时按 LIFO 回滚。
空间可组合性：组件声明依赖，依赖的出现、消失、替换自动驱动组件激活或停用。
一个关键洞察：进程重启和容器编排是粗粒度的可组合性——为删一个组件重启整个进程，缓存、连接、中间计算全丢。Cordis 把这个保证下推到进程内组件级别。这解释了几个乍看奇怪的设计：能力都挂在 ctx.<key> 服务槽位上（ctx.llm、ctx.tools、ctx.agentLoop 等）；配置即插件树，部署方在 patch 层按 id 覆盖一行就完成替换；前端 UI 也是插件，浏览器里跑独立的客户端运行时。
写一个插件长什么样
插件就是一个函数，签名 (ctx, config)，可声明依赖：
import type { Context } from '@deepseek-ai/cordis'
export const name = 'greeter'
export const inject = ['llm'] // llm 服务就绪才激活
export function apply(ctx: Context, config: { greeting: string }) {
ctx.provide('greeter', {
greet: (who: string) => `${config.greeting}, ${who}!`,
})
ctx.on('greet', (who: string) => console.log('hello', who))
}
inject 声明依赖是空间可组合性的直接体现：依赖消失，插件自动停用，不需要手写生命周期管理。
落地评估：收益与代价
增量提醒（原文未给的选型判断）：这套架构适合的场景是"需要深度定制 Agent 行为且团队有 TS 工程"——改模型路由、换沙箱策略、插自定义审批层，都是改一行配置或写一个小插件的事，不用 fork 框架。不适合的场景有三：团队只做应用层 prompt 工程（用不上插件化，开销白付）；生产环境对运行时稳定性要求极高（预览版 + 插件自由度意味着配置组合爆炸，回归测试面大）；已有成熟编排层（重复建设）。验收一个 DSH 定制是否值得，用这个标准：如果定制点在插件槽位覆盖范围内，收益为正；如果需要改内核，等于放弃它相对闭源框架的全部优势，不如回到自研。
对工程文化的影响倒是确定的：把 harness 层开源并标准化，等于给"Agent 底座"这个模糊概念立了个参照物——以后评任何 Agent 框架，都可以问一句：你的循环可替换吗？
评论0