夜雨聆风舟覆乃见善游，马奔乃见良御。—— 《淮南子·说林训》
Deepseek harness 出来之后，已经有很多文章介绍其独特性。我觉得有必要使用 deepseek harness 自身来证明其价值 —— 把我博客 repo new_hope 扔给他，直接给一个非常简单的 prompt：“帮我撰写一篇新的博客，介绍 deepseek harness 和 codex 等其他 harness 的主要区别及未来展望”。于是在一系列眼花缭乱的操作后，6 分钟左右，一整篇文章就出炉了。文章显然参考了我目前文章的行文格式和风格，保持了非常好的一致性。文章内容可读性也很不错。
为了生成这篇文章，它访问了 dsh 自己通过 npx 安装的代码和 readme，网上的资料，还找到了我博客里一年前写的 codex 的介绍，也探索和使用了我本地 claude/codex 的 skills，使用了 2.5M 输入 token（缓存命中 98%），最终输出了 33k token。
dsh 的主操作界面：
这个视图记录了整个运行轨迹，如果你点击某个点，右侧会展开详细的 telemetry 信息，这在产品上直观地可视化了其策略：log everything：
由于我使用的是 v4 flash model，整体价格非常低：
从对其代码的一次浅层 Agentic 分析来看，最让我兴奋的部分（或者说其核心理念）是：整个 harness 几乎彻底而激进地建立在插件体系之上。这些插件不仅能够访问几乎所有上下文，而且可以被热重载（hot reload），甚至连 Agent Loop 本身也可以通过插件扩展或替换。相比之下，Codex 虽然也支持插件，但它的 Agent Loop 是固化在核心系统里的；插件能访问的信息非常有限，更像是一个被 Agent 调用的“工具”，而不是整个系统的“合作伙伴”。这意味着，我们可能真正实现一种能够自我进化的 Agent，甚至自我进化的软件系统：当它在解决某个具体问题时，可以动态编写新的代码，并即时加载这些代码，从而在运行过程中升级自身能力。
如果说 Anthropic 的 Dynamic Workflow 已经向“运行时动态生成工作流”迈出了一大步，那么这种架构又向前推进了一步：不仅工作流可以动态变化，连执行工作流的系统本身都可以动态进化。我会继续研究 dsh 的代码和架构，有机会再写点东西。
以下是 dsh + deepseek v4 flash 撰写的内容全文，一次成型，质量还是很不错的，可读性非常好，全文无修改。大家感兴趣可以读读。
这篇文章，是我坐在 DeepSeek Harness 的 Web UI 里写完的。
写完开头才意识到这个巧合本身就值得写一篇。一年前我写过一篇拆解 Codex 架构 的文章，讲它 Session、Task、Turn 三层抽象怎么体现人机协作的智慧。今天 DeepSeek 把 Harness 开源了，回答的是同一个问题：Agent 应该被构造成什么样？答案却完全相反。
8 月 10 日，npm 上已经能拉到 @deepseek-ai/dsh 的 rc 包；8 月 13 日，GitHub 仓库正式公开，开源当天就冲上 6 万多 star。同一天 DeepSeek V4 Pro 发布，Harness 晚了不到半天就跟了上来。一个模型厂在这个节点开源自己的 Agent 框架，这件事本身就有意思。
先搞清楚：Harness 到底是什么
先说结论：它不是一个模型，也不是一个 API 客户端，而是一整套用来构建、运行、扩展 Agent 的 SDK 和框架。
“Harness” 这个词起得很准。它的本义是马具、线束、约束装置。电学里的 wiring harness 负责把动力接到工作机构上，同时防止动力失控。AI 语境下同理：模型本身只有文本进出，让它能读文件、改代码、跑命令、查网页、调用别的 Agent，中间必须有一层东西把它接到世界上，记录它做了什么，限制它能做什么，出错时决定重试、取消、压缩上下文，还是把问题交还给人。
这一层就是 harness。Codex、Claude Code、Gemini CLI 本质都是 harness，只不过它们以「产品」的形态出现，核心是固定的，用户只能在外围做文章。DeepSeek Harness 想当的是另外一回事。
机器之心那篇报道里有个比喻我特别喜欢：普通 Agent 项目像一台装好的整机，DeepSeek Harness 更像一块面包板，模型、工具、界面、存储、安全策略、上下文管理全都可以插上，也随时可以拔下来。它给了一个默认的组装方案，但它真正想做的显然不是一个固定形态的「DeepSeek 编程助手」，而是一套通用的 Agent 组装方式。
一年前我拆过 Codex：一座优雅的单体
先把我熟悉的那边讲清楚，对比才有基准。
Codex CLI 是 Rust 写的，六十来个 crate，编译出一个单二进制。它的架构精髓是三层抽象：Session 管环境和配置，Task 管意图和执行流程，Turn 管单次交互。通信走提交队列加事件队列，模型和界面彻底解耦；安全上有一套 SandboxPolicy 枚举，从完全信任到只读；MCP 支持把外部工具接进来。
我当时得出的结论是：Codex 把「注意力是单一资源」这类对人机协作的认知做进了架构。一次只跑一个 Task，输出永远可以追溯到输入，错误处理按语义分类而不是按技术分类。它是一台精心设计的整机，设计师想清楚了每个零件的形状和位置。
它的哲学可以概括为：核心先做对，扩展后补。单体给你的是确定性和性能，代价是核心只有一个团队能改。后来 Codex 也陆续加了插件和扩展机制，但那些都是在固定核心外面长出来的附加层。
现在来了 DeepSeek Harness：一切皆插件
DeepSeek Harness 最反直觉的一句话是：连 Agent Loop 本身都是插件。
它跑在 Cordis 微内核上。Cordis 是 Shigma 维护的元框架，脱胎于 Koishi 机器人生态。它最近还出了一篇论文《A Programming Paradigm for Spatiotemporal Composability》，草稿日期恰好就是 8 月 13 日，和开源同一天。论文讲的是两种组合性：时间组合性，卸载一个插件时，它的副作用被完整撤销；空间组合性，组件之间声明依赖关系，Context 变化时响应式地通知各方。
在这个内核之上，运行中的 Harness 本质上就是一个 Cordis Context。文件系统、Shell、子进程、PTY、语言服务器、网页搜索、技能、子代理、工作流、规划模式、会话持久化、设置、凭证、遥测，几乎每个能力都有自己独立的包。仓库里是两百多个 workspace 包，几乎把「边界感」做到了偏执的程度：谁拥有接口，谁负责实现，谁把能力呈现给模型，被严格分开。
组装靠的是 profile、bundle、patch 三件套。profile 是放在 $DSH_HOME/profiles 下的组合清单；bundle 是分发的插件层，每个 bundle 声明自己往配置树里插入哪些行；cordis.patch.yml 是用户自己的覆盖层。层按顺序叠加，dsh --dump-config 可以把整棵配置树打出来，树上的任何一行都能被 patch 替换。
跑起来也很简单，两条命令的事：
npx @deepseek-ai/dsh web # 启动 Web UI，默认 http://127.0.0.1:3080
dsh --profile headless "完成这个任务并打印结果" # 一次性任务，适合 CI 和自动化
dsh --profile web --dump-config # 不启动，直接看整棵配置树
同一个代码库，往配置里加 DeepSeek 适配器、文件系统、Bash 和 TUI，就是一个终端里跑的编程 Agent；把界面换成 Web 插件，就是浏览器应用；用 Headless 入口，接受一个任务、跑完模型和工具的交互轮次、打印答案退出，适合 CI 和自动化；再接一个 ACP 或 JSON-RPC 门面，就变成可以被其他程序驱动的自动化服务。
最本质的区别：换掉组件，还是换掉核心
前面说的都是表面差异，真正的分水岭在这里。
Codex 的插件机制、Claude Code 的 hooks 和 plugins，都是在固定核心上做扩展。Agent Loop、会话管理、工具管线这些最底层的部件是固定资产，不开放。你在房子上加窗户，但不能拆承重墙。
DeepSeek Harness 的文档里有一句话说得非常直白：这里没有需要 patch 的特权核心，你通过在旁边挂一个插件来扩展 dsh，注册都是效果，插件卸载时自动撤销。扩展不是在外围加东西，而是和核心平起平坐。
支撑这一点的是 seam（能力缝）的设计。每个能力拆成三个角色：接口定义、服务实现、消费者。以 Bash 为例：接口定义「执行命令」是什么，本地实现负责真正创建进程，模型端工具负责把它变成模型能理解的 schema 和结果。三件事各自独立。
未来想把本地 Shell 换成远程容器、云沙箱、企业执行平台，按设计只需要换实现层，模型工具和 Agent Loop 一行都不用改。这就是典型的框架式思维：它不追求做一个只有官方团队能维护的成品，而是让不同部署者换模型、换存储、换安全策略、加工具，甚至整体替换 Agent Loop。
代价也很明显：早期代码库会显得异常庞大，新手进来不知道该碰哪里。后文我会专门说这一点。
会话日志：模型看见了什么，就记录了什么
聊完架构聊运行。DSH 的会话是一条只追加的 SessionEvent 日志，它是唯一持久的真相源，UI、回放、续跑、遥测全部从它派生。
里面有一条 invariant 非常硬核：模型可见即被记录。任何进入模型请求的内容，都必须能从日志里重建出来，运行时还有断言在查这个。这不是审计的附加需求，而是架构的底层约束。所以你要给模型加一点新的可见输入，就必须先定义一个新的会话事件。
这带来几个很实用的结果。JSONL 格式落盘，会话可以跨进程恢复，turn 编号和上下文接着上次的走；SQLite FTS5 做全文检索，你可以翻旧会话找当时那个决定；OpenTelemetry 后端把遥测接进现有监控体系。我在这套 Web UI 里最常用的其实是轨迹视图，一次 Agent 运行像录像一样可以重放，每一步模型看到了什么、调用了什么工具、结果是什么，全部可查。调试 Agent 的时候，这种回放能力比什么都值钱。
Codex 也有 conversation history 和 log_id 那一套，但它是「有历史记录」；DSH 是「日志即架构」。一个是功能，一个是地基。
沙箱词汇表几乎一样
有个细节很有意思，值得单独拿出来说：两者的沙箱模型几乎是同一个词汇表。
Codex 的 SandboxPolicy 枚举是 DangerFullAccess、ReadOnly、WorkspaceWrite；DSH 的 SandboxMode 是 read-only、workspace-write、danger-full-access。实现路线也一致，都走 OS 级的同世界约束：Linux 上 Landlock 或 bubblewrap，macOS 上 Seatbelt，不是容器也不是虚拟机。也就是说，两边对「文件效果」这件事的边界划分已经收敛了。
DSH 的差异在细节。策略跟着调用走，不跟着 provider 走：同一个 bash 工具，这次调用在 read-only 下跑，下一次在 workspace-write 下跑，各管各的；一个被批准的升级重试，就是一次带更宽策略的新调用。而且 fail-closed，没有可用的沙箱后端时直接拒绝执行，绝不裸奔。
这个收敛说明安全模型是行业共识，谈不上谁抄谁，只能说大家踩过的坑都一样深。
编排是一等公民
第三个让我印象深刻的地方：多 Agent 编排不是锦上添花，而是模型可以直接调用的工具。
subagent 支持 spawn、fork、ACP 几种 provider，背后换 provider 就换传输方式，执行契约不变。后台子代理可以是「可持续对话」的，父代理随时用 send_message 给它派新活，子代理结束时会主动通知父代理。workflow 更狠：模型自己写一段 JavaScript 编排脚本，一次性扇出十几个子代理，分阶段并行，脚本负责汇总结果，跑完把返回值交回给模型。goal 则是同一个会话里的长期目标，带轮次上限，可以暂停、恢复、完成、阻塞，适合那种要跨很多轮才能做完的长跑任务。
skills、plan mode、background jobs、context compaction，这些词在 Codex 和 Claude Code 里也都有。但在 DSH 里，它们全部挂在统一的事件系统上，任何一环都可以被策略插件拦截和改写。编排能力不是产品特性，是平台能力。
其他 harness 扫一圈
把视野拉开一点，2026 年这个赛道已经很热闹了。
Claude Code 的 hooks、skills、subagents 生态最成熟，产品体验也最好，但核心是闭源的。你想改它处理消息的方式，做不到，只能在外面挂钩子。
Gemini CLI 是开源的，TypeScript 写的，Google 家的，定位和 Claude Code 接近。Cursor 走 IDE 路线，把 Agent 嵌进编辑器。Aider、OpenHands 这些开源项目各有拥趸，但定位和野心都不太一样。
共同趋势很清楚：沙箱、MCP、编排、可观测性，大家都在往前推。真正的分水岭只有一个，你的核心能不能换。闭源产品不能，单体开源项目很难，DSH 从第一天起就把「能换」写进了架构。
为什么 DeepSeek 要开源这个
从商业角度想一层，这个动作并不难理解。
V4 Pro 发布当天就把 Harness 开源，明显是组合拳：模型和缰绳一起给。MIT 协议，代码和文档全部公开，这不是营销姿势，是产品节奏。
更深一层，harness 是模型的使用现场。谁掌握了 harness，谁就掌握了模型被怎么用、被用来做什么的场景和数据。模型本身会越来越同质化，但使用现场不会。开源 Harness 表面上是把地盘让出来，实际上是把「使用现场」的标准握在手里。
再往外一层，这是标准的生态战争打法。dsh-plugin 话题、Discord 社区、开发者预览期就鼓励第三方插件，这套路和 VSCode 当年一模一样。先让插件生态滚起来，再让生态反哺主项目。
它还不是一个成熟产品
说了这么多好话，也该诚实泼点冷水。
它现在明确是 developer preview，官方明说会有破坏兼容性的变更。版本号还停在 0.1.0-rc。
有几个坑是真实的。patch 是整体替换配置而不是深合并，你只写一个新字段，原来的 API Key 和 base URL 可能就一起没了，第一次用很容易踩。沙箱目前只约束文件效果，不约束网络、进程和系统调用。workflow 会阻塞父回合直到整个编排跑完，没有后台启动再轮询的接口。
两百多个包对新手是实打实的心智负担，文档里还大量引用 .agents/notes 内部决策记录，说明它连自己的文档形态都还没稳定。
但反过来说，这些恰恰是「认真做框架」的证据。一个随便糊的产品不会给每个能力都配接口、实现、消费者三层，也不会给会话日志写运行时断言。它的问题都是成长中的问题，不是敷衍的问题。
未来展望：harness 会成为下一个战场
最后聊聊我看到的走向。
模型能力的差距会继续缩小，之后真正拉开差距的是三件事：连接世界的能力、约束能力、可观测能力。harness 恰好是这三件事的集合。所以我的判断是，两年内每家主流模型厂都会有自己的 harness，开源的那几个会决定开发者默认选哪个。
具体到技术上，几个方向几乎可以确定。多模型路由会普及：同一个会话里，写代码走一个模型，做研究走另一个模型，provider 中立让这变成配置问题而不是代码问题。沙箱会从「文件效果」走向全策略，云沙箱、容器、远程执行会以「换实现层」的方式接入，而不是重写工具。
会话格式会走向标准化。MCP 已经统一了工具，OTel 统一了遥测，DSH 这种事件日志式的会话存储有潜力成为可移植会话的事实标准。
生态层面，插件市场会像 VSCode 那样滚起来。面包板和整机的路线之争会长期存在：大部分人还是想要一台插上电就能用的整机，但越来越多的人会发现，有些需求只有面包板能满足。
对我来说，这件事最大的意义在于：一年前我写 Codex，学会的是欣赏「把核心做对」的克制；今天 DeepSeek Harness 告诉我，另一条路同样成立，把核心交出去，让所有人一起改。两条路最后都会通向同一个问题。
当模型本身不再稀缺，稀缺的是那根缰绳。而缰绳握在谁手里，将决定下一轮 Agent 生态长什么样。