DSH 或许会昙花一现，但它重新唤起了我们对 Agent OS 的想象
DeepSeek Harness 真正激进的地方，不是插件数量，而是把应用本身变成 Agent Runtime 的组成部分。它离操作系统还有多远？与 Codex、Deep Agents 和 Pi 相比，哪条路线更适合专业产品？
DeepSeek Harness（下文简称 DSH）发布后的一周里，迅速获得了近 20 万 GitHub Star。这个数字足以证明它制造了巨大的注意力，却还不足以证明它已经获得生产环境的信任。DSH 官方也很坦率：这是一个 developer preview，API 和插件接口仍可能发生破坏性变化。官方仓库的高热度与快速迭代，描述的是一个现象级实验，而不是一项已经定型的基础设施标准。
过去几天，我实际使用并读完 DSH 的核心架构后，产生了一个看起来有些矛盾的判断：
如果今天要开发一个稳定、可控、面向专业用户的 Agent 产品，DSH 相比 Codex 并没有显著优势；但如果我们想象十年后的计算机应该长什么样，DSH 又可能是近期最有启发性的作品之一。
它的意义未必在于成为最终赢家，而在于把一个长期停留在概念中的问题做成了可以运行的软件：未来究竟是 Agent 去调用一个个外部应用，还是应用本身最终会融入 Agent Runtime，成为它的器官？
真正的新意不是插件，而是“应用即运行时”
DSH 最响亮的口号是 “Everything is a plugin”。但如果把它理解成“可以安装很多插件”，其实低估了它，也高估了插件化本身。
工具插件、模型插件、MCP、Skills、Middleware，今天几乎每个主流 harness 都有。插件的直接价值也很朴素：复用开源社区成果，用较低成本补齐某项能力。仅凭这一点，DSH 与 Codex、Deep Agents 或 Pi 并不构成代际差异。
DSH 真正激进的地方，是它不只把外围能力做成插件，而是试图把 model adapter、tool registry、session log、agent loop、sandbox、调度乃至浏览器 UI 都放进同一棵 Cordis 组件树里。它的 Web 入口几乎只是一个薄启动器，主题、布局、侧边栏、会话、设置、输入、权限、工作流和子代理界面，都由运行时中的插件组合出来。官方架构文档所表达的，不再是“一个核心应用允许第三方扩展”，而是“产品本身就是一张在启动时生成的运行图”。
这才是 DSH 与普通插件系统的根本差别：
- 传统架构里，应用是主体，Agent 是应用调用的一项能力；
- DSH 的想象里，Agent Runtime 是主体，应用只是运行时当前装配出来的一种形态。
因此，它说“没有 privileged core”时，准确含义不是系统真的没有核心。Cordis 的 Context、Fiber、Service、事件分发、Loader，以及最底层的 Node 进程仍然是不可绕过的元运行时。DSH 消除的是产品层的特权核心：loop、session、UI 与工具不再天然高人一等，它们理论上都可以被替换。
这是一个很大胆的转变。浏览器当年把应用从操作系统原生进程搬进 Web Runtime；DSH 则在追问，能否进一步把应用从固定 GUI 搬进 Agent Runtime。
比“Everything is a plugin”更重要的，是日志成为事实源
读源码时，我反而觉得 DSH 最可能留下长期影响的设计，并不是插件，而是 session event log。
在许多 Agent 实现中，对话记录只是 agent loop 执行后的产物：loop 是主体，history 是附属品。DSH 倒了过来。Session log 是模型上下文的事实源，模型看到的历史、恢复、分叉、转录和遥测，都是同一事件流的不同投影。它在架构文档里给出了一条很好的原则：“Model-visible means logged.”
这意味着，任何插件若要改变模型的认知，就不能偷偷修改某块“幽灵上下文”，而要留下明确事件；agent loop 即便被替换，历史仍可从日志重建。它把 Agent 的基本对象从“一次不可见的循环”变成了“一段可以重放、检查和分叉的历史”。
对长时间运行的 Agent 来说，这比多几个工具重要得多。未来 Agent 系统真正需要管理的，也许不是传统意义上的进程，而是承诺：目标是什么、预算是多少、谁授权了哪些副作用、任务已经进行到哪里、哪些结果已提交、哪些步骤还能撤回。Event log 是走向这种系统的起点。
但起点不是终点。记录一个副作用，与保证副作用可恢复，是两回事；日志里写着“邮件已发送”，与系统能够阻止重复发送、补偿失败步骤、对账外部事实，也完全是两回事。
插件化的上限很高，代价也来自同一个决定
Cordis 的核心思想可以概括成两种可组合性：组件加入和移除时，其注册行为可以随生命周期撤销；组件声明依赖，依赖出现时激活、消失时挂起。它让“换掉一个 provider”不必等同于“fork 整个项目”，也让运行中的系统有机会试验、观察并撤回新能力。Cordis 论文把它称为 temporal 与 spatial composability。
这不只是为了热闹的插件市场。对于研究 harness 的团队，能够只替换 loop、session backend 或 sandbox，同时保留其他组件，确实有很高的实验价值。社区也很快利用这种能力补齐 UI、记忆、工具和模型适配层。DSH 的理论上限，的确高于一个只能在固定接缝上扩展的集成产品。
问题是，可组合性不是隔离性，可撤销注册也不是可撤销现实世界。
普通 DSH 插件以 npm 包的形式安装，并进入核心进程的组合图。一个插件能够干净地卸载，不代表它加载时不能读取凭据、改写配置或污染共享状态；一个 effect 可以回滚工具注册，不代表它能撤回已经发出的邮件、支付或泄露的数据。近期社区报告的插件兼容和故障放大问题，也说明同进程扩展一旦缺少清晰故障域，局部错误可能沿共享运行时传播。相关讨论
DSH 最富想象力的 Creator/Cordis 模式，也需要放回真实边界中理解。标准 preset 并不会默认让 Agent 改写自己；专门的 Cordis preset 才提供 cordis_inspect、cordis_define、cordis_run 等能力。模型生成的动态组件目前主要存在于进程内存中，重启即消失，也不会自动晋级为持久插件。更关键的是，官方工具文档明确说明，Host 侧的 node:vm 不是安全边界，应把这种会话视为接近 shell 权限的信任边界。
所以，DSH 展示的是一种很有价值的“运行时草稿板”，还不是能够安全、自主、持续进化的系统。自我生成代码只是第一步；真正困难的是评测、授权、隔离、灰度、回滚和追责。
DSH、Deep Agents、Pi 与 Codex，到底在竞争什么
把这几类产品放在一起比较，最容易犯的错误是数功能。更有解释力的问题是：它们把复杂度放在了哪里，又把什么承诺交给了开发者？
| 项目 | 默认目标 | 复杂度主要放在哪里 | 应用与 runtime 的边界 | 更适合谁 |
|---|---|---|---|---|
| Deep Agents | 为长任务提供一套强默认 harness | LangChain middleware 与 LangGraph 的状态、checkpoint、interrupt | 它仍是应用框架；服务协议、UI、租户与产品状态通常由开发者补齐 | 已在 LangChain/LangGraph 体系内，需要快速搭建专业 Agent 的团队 |
| Pi | 保持一个小而透明的 coding-agent 内核 | MCP、子代理、权限策略、沙箱等复杂度主动留给扩展和宿主 | SDK/RPC 易嵌入，但治理边界主要由开发者自行定义 | 希望完全拥有机制、接受自己组装系统的开发者 |
| DSH | 把整个 Agent 产品表达成可重组运行图 | Cordis 组件、Profile、Bundle、依赖与生命周期 | 应用逻辑可以进入 runtime，与 loop、session、UI 成为近似同级组件 | Harness 研究、深度定制和用户可编程环境 |
| Codex | 把 Agent 变成可嵌入、可控制的系统组件 | thread/turn/item 协议、事件、审批、沙箱与官方 runtime | 应用拥有 UI、业务规则和事实源；Codex 隔着协议拥有 loop 与执行 | 需要稳定边界、审计和产品控制权的专业开发团队 |
Deep Agents本质上是构建在 LangChain 与 LangGraph 上的 opinionated harness：文件系统、上下文压缩、Skills、Memory、Subagents 和 Human-in-the-loop 被预装成一套强默认值，持久执行能力主要继承自 LangGraph。它解决的是“怎样少搭一些脚手架”，而不是重新发明应用运行时。
Pi走向另一个方向。它把状态化 tool loop、session 与事件流做得很小，刻意不在核心里统一规定 MCP、子代理、权限弹窗和计划模式。小内核带来清晰与自由，但没有消失的复杂度最终会落到宿主、扩展、容器或开发团队身上。
DSH 则不满足于提供一个 loop。它把“产品如何存在”也变成 runtime composition。它的自由度最高，同时学习成本、兼容风险和可信计算基也最大。
而 Codex 最值得比较的对象，不只是 CLI，而是 SDK 与 app-server。
DSH 与“Codex as a platform”：方向相近，边界相反
OpenAI 在 Codex as a platform 中提出，驱动 Codex App、CLI 和 IDE 的同一个开源 harness，可以通过 codex exec、SDK 与 app-server 嵌入其他产品。此时应用自己拥有界面、业务上下文、业务规则、工具和事实源，Codex 负责 Agent loop、上下文管理、工具执行、沙箱、进度事件和人工审批。
如果只看结果，DSH 与这条路线其实没有本质差异：两者都希望开发者不必重写一个 Agent loop，就能把 Agent 变成垂直产品的一部分；两者都有工具、Skills、扩展与 UI 集成能力。DSH 并没有因为“All in runtime”就自动进入一个 Codex 无法触达的全新类别。
真正的差别，是那条边界画在哪里：
- DSH 选择融合。 应用、UI、loop、session 和能力 provider 可以进入同一个 Cordis 组合体系。它追求的是内部可塑性。
- Codex 选择分层。 应用留在宿主一侧，通过协议控制 runtime。它追求的是外部可控性。
对专业产品开发来说，这一区别非常现实。Codex app-server 把 thread → turn → item 做成明确的状态模型，宿主可以 start、resume、fork 会话，可以 steer 或 interrupt 一个 turn，并接收命令、文件修改、工具调用、审批和完成状态等结构化事件。审批不是藏在自然语言中的建议，而是由 runtime 发向客户端、带有具体上下文的协议请求。App Server 文档展示的，本质上是一套产品控制面。
相较之下，在我阅读的 DSH 本地 0.1.0-rc.5 快照中，它的内部组合机制已经非常复杂，外部 SDK 协议却仍然很薄：主要方法是初始化、提交 session prompt 与关闭；messageId 表示入队回执，并不是一次 prompt 的最终结果；还缺少中途取消、session close 和协议版本协商。当前线上版本变化很快，但这组反差仍很能说明两种路线的优先级：DSH 先解决“内部如何任意组合”，Codex 先解决“外部产品如何可靠控制”。DSH 的最新协议边界可继续参考其协议说明与客户端说明。
这就是为什么，对大多数真正要交付产品的团队，我会把 Codex 视为现阶段更稳定、可控的选择。这里的“稳定”不是品牌判断，也不是说所有接口都已冻结——例如 app-server 的 WebSocket transport 仍被官方标为实验性能力——而是它已经提供了一条更清晰的责任链：
业务真相属于应用，概率推理属于 Agent，权限与执行边界由宿主和沙箱共同强制。
开发团队因此可以把时间花在领域数据、交互、工作流和评估上，而不是把整个产品也押在同一套快速变化的插件 ABI 上。
当然，这并不意味着 Codex 在所有场景都更好。如果目标本来就是研究新 loop、动态替换 session 语义、让用户改造运行时，或探索“软件自我重组”，DSH 的内生可塑性是 Codex 的外部协议刻意不提供的。DSH 更像一间可随时拆墙的实验室，Codex 更像一栋已经铺好水电、验收流程明确的办公楼。实验室的上限更高，办公楼更适合今天开门营业。
Cordis 很薄，所以它还承载不了操作系统
“Cordis 太薄，无法取代传统操作系统”这个直觉是对的，但需要更精确一点：薄既是 Cordis 的优点，也是它的边界。
Cordis 擅长的是组件依赖、事件、生命周期和可撤销 effect。它更像 Agent 世界的动态服务容器或应用服务器内核。真正的操作系统却不是一组功能的合集，而是一组不可逃逸的责任：资源与副作用必须经过它调度、授权、隔离、记录，并在失败后由它负责恢复。
至少以下几类承诺，今天的 Cordis/DSH 还没有完整承担：
- 身份、权限与凭据。 用户、Agent、插件和外部服务需要不同身份；授权必须最小化、可过期、可撤销，并由模型之外的机制强制。
- 隔离与故障域。 一个恶意或错误插件不能共享宿主全部权限，也不能把另一个 workspace、会话或用户一起拖垮。
- 持久调度与事务恢复。 长任务要能跨重启续跑；邮件、支付、建单等副作用需要幂等、补偿和对账，而不只是聊天记录可恢复。
- 稳定能力接口与兼容层。 第三方应用必须能依赖版本化的 capability/ABI 长期运行，传统 App、文件、设备和协议也不能一夜清零。
- 分发与信任链。 插件需要来源、签名、权限清单、依赖锁定、漏洞响应、灰度升级和可回滚迁移。
- 独立的人类控制面。 用户必须能在 Agent 之外预览、批准、暂停、取消、撤销和接管；同一个可能遭受 Prompt Injection 的模型不能既做计划者又做门卫。
判断一个系统有没有真正到达 OS 层，可以问三个简单问题：
- 有没有一条副作用路径能够绕过它？
- 插件崩溃、任务重复执行或模型升级后，谁负责恢复和追责？
- 第三方能力能否基于稳定契约运行多年，而不依赖某个 prompt 或屏幕坐标？
如果答案分别是“有”“用户重试”“不能”，它就仍然是一个 shell、runtime 或 control plane，而不是完整的操作系统。
因此，更准确的评价是：DSH 展示了 Agent OS 的界面终局，却尚未承担 Agent OS 的系统责任。
未来的 Agent OS，不会只是一个无所不能的聊天框
我仍然相信，未来大多数用户不再需要理解今天的电脑或手机操作系统。
他们不必知道控制面板在哪里，不必研究某个 App 应该怎样安装和卸载，也不必在十几个窗口之间搬运信息。用户面对的是一个长期存在的 Agent：告诉它目标、约束和偏好，然后查看进度，在关键节点作决定。浏览器、编辑器、日历、文件系统、企业软件与各种设备不再是 Agent 偶尔伸手控制的外部世界，而成为它可发现、可授权、可组合的能力。
但这不意味着所有界面最终都会被聊天框取代。地图、时间线、代码 diff、电子表格、监控面板之所以存在，是因为它们比语言更高密度、更适合比较和校验。OpenAI 在 Codex 平台文章中同样强调，好的 Agent 产品不是简单地把现有 dashboard 换成通用聊天，而是把 Agent 嵌入真实工作流。
所以更可能出现的终局是：Agent 成为默认入口，专业界面成为按需生成或调用的视图；App 不再争夺用户入口，而是向 Agent 提供能力、状态与交互视图。
这样一种 Agent OS，至少包含三个相互制衡的平面：
- 意图平面：长期 Agent 理解目标、维护上下文、拆分任务，并跨设备协调工作；
- 能力平面：应用、浏览器、设备和服务暴露类型化能力、事件与可验证状态，而不是只让 Agent 看像素点按钮；
- 信任平面：确定性的身份、策略、沙箱、审计、预算与事务系统，约束模型可以做什么，并对真实副作用负责。
传统 OS 不会立刻消失。它仍会负责 CPU、内存、驱动、文件、进程和硬隔离，就像今天的用户无需理解 TCP/IP，也并不意味着网络协议已经不存在。最先消失的将是传统 OS 的存在感，而不是它的代码。Agent Runtime 会成为“人的操作系统”，现有 OS 继续成为“机器的操作系统”。
这也带来一条重要原则：Agent 越像大脑，就越不应该同时充当门锁。 规划可以是概率性的，执法必须是确定性的；Agent 可以提出方案，但权限、资金、凭据和不可逆操作应由独立系统裁决。未来的 Agent OS 不应把 Agent 变成皇帝，而应把它变成一个受宪法约束的调度者。
昙花一现的产品，也可能留下一个时代的问题
DSH 今天还不是一个成熟的 Agent OS，甚至未必是开发专业 Agent 产品时最划算的底座。它的插件生态仍在快速变化，内部自由度带来了很高的认知成本与信任成本；对于大多数垂直产品，Codex 那种“应用拥有业务真相，harness 提供可控 loop”的保守分层，可能反而更可靠。
但评价一项新技术，不应只问它是否会赢。
DSH 最重要的贡献，是把“Agent 调用应用”向前推了一步，变成“应用可以成为 Agent 世界的一部分”。它让人第一次直观看见：未来的软件也许不再首先以 App、窗口和菜单的形式存在，而是以能力、状态、事件和视图的形式，装配在一个持续运行的 Agent 系统中。
它也以自己的不成熟提醒我们：真正的 Agent OS 不会是“Everything is a plugin”这么简单。恰恰相反，当一切都能被重组时，我们更需要一个不能被随意重组的信任内核；当 Agent 可以做更多事时，我们更需要清楚地定义它不能做什么；当应用融入 runtime 时，我们更需要把业务事实、系统权限与模型推理重新分层。
所以，DSH 或许会昙花一现。但它留下的问题不会：
当 Agent 不再是电脑上的一个进程，而是用户理解整个数字世界的入口时，软件、应用与操作系统的边界，应该被重新画在哪里？
这场讨论，才刚刚开始。
说明：本文基于 2026 年 8 月 22 日可见的官方资料、社区讨论，以及本地 DeepSeek Harness
0.1.0-rc.5源码快照。项目仍处于快速迭代期，具体接口与实现可能继续变化。GitHub 热度用于描述关注度，不代表生产采用率。