DeepSeek 把 Agent Core 也插件化了：Harness 的真正赌注
假设同一个团队要做两个 Agent 产品。
一个通过 Web 界面工作，会话存进 SQLite，允许使用 Bash 和文件工具；另一个只跑一次性任务， 会话写入 JSONL，禁止本地 Shell，通过 Python SDK 调用。再过一段时间，第二个产品甚至想换掉默认 Agent Loop。
如果模型、循环、工具、状态和界面都揉在一个 Agent 类里，团队通常只有两条路：继续增加条件分支， 或者 Fork 一份 Agent Core。分支越多，两个产品越难同步修复和升级。
DeepSeek Harness 想改变的正是这个位置。它的"Everything is a Plugin"不是说搜索和 MCP 可以装插件， 而是连模型适配器、Agent Loop、Session Log、Tool Registry 与产品 Surface 都进入同一套 Cordis 插件语义。
这也是它真正激进的地方：Agent Core 不再是一个不可触碰的中心。
我的判断是，DeepSeek Harness 的核心赌注不是做出功能更多的编码助手，而是让 Agent 产品差异通过 可组合、可卸载、可观察的运行时能力表达，减少复制 Agent Core 的必要性。它获得了更细的替换和生命周期 边界，也把复杂度转移到了插件图、接口契约、版本迁移和诊断上。
它究竟是 Harness、Runtime，还是产品
Harness、Runtime、Framework 和 Product 在行业里没有唯一强制定义。为了判断 DeepSeek Harness， 可以先采用一组操作性边界：
- Framework 提供开发者描述流程、状态和组件的库与抽象。
- Runtime 负责装载、调度、生命周期和实际执行。
- Agent Harness 围绕模型组织上下文、工具、状态、权限、反馈和停止条件。
- Product 在底层能力上给出默认界面、策略、体验和交付承诺。
DeepSeek 官方把 dsh 定位为 open-source agent harness。固定源码同时展现了明显的 Runtime 特征： Cordis 负责装载插件树，Profile 与 Bundle 决定组合，Web、Headless 和 SDK 驱动共同的底层语义。
它确实提供可运行界面，却仍是 Developer Preview。因此，"Web UI 能打开"和"已经是一款成熟的 Coding Agent 产品"是两件不同的事。
一句话概括：DeepSeek Harness 是一块用 Cordis 插件图重组 Agent 产品的运行时底盘，不是只允许在 固定 Agent Core 外围增加工具的插件框架。
"Everything"包括哪些核心能力
本文的架构判断绑定官方 Commit 47f943859bef60e4160492346772ded9b24f765a。固定架构文档明确写出，模型适配器、工具注册表、 Session Log 和 Agent Loop 本身都是插件，可以由配置替换。
| 核心能力 | 执行职责 | 进入插件语义后的变化 |
|---|---|---|
| LLM Adapter | 统一消息、流式输出与模型协议 | 换模型后端不必改 Agent Loop |
| Agent Loop | 认领输入、请求模型、执行工具并判断是否继续 | "换循环"与"换 Provider"都成为组合动作 |
| Session Log | 保存 Turn、Step、消息和工具事件 | 状态后端与循环可以分别演化 |
| Tool Registry | 汇总 Schema 并执行工具流水线 | 工具、执行 Provider 和策略不必绑在一个类里 |
| Surface | Web、Headless、SDK 等入口 | 多个产品入口不必各自复制 Agent Core |
其中最不寻常的是 Agent Loop 也只是插件。普通插件系统通常默认主循环不可替换，扩展只发生在边缘； DeepSeek Harness 则把循环、状态和工具放在同一组合机制里。
但"存在替换接缝"不能直接写成"任意实现都兼容"。错误语义、流式事件、状态格式、安全策略和性能特征， 仍然需要契约测试和受控实验。把代码拆成包是架构事实，稳定组合这些包才是工程能力。
Cordis 不只管理注册，还管理插件何时存在
如果插件只在启动时向 Map 注册一个工具，退出进程时一起销毁，普通依赖注入已经够用。Agent Runtime 真正困难的场景是动态变化：Workspace 被加载或卸载，Provider 暂时出现或消失，配置被更新，局部能力 只在某个 Agent 的生命周期中存在。
Cordis 把设计目标称为 spatiotemporal composability。用工程语言可以压缩成两个问题：
- 插件注册的服务、事件和子作用域，能否在卸载时作为可追踪副作用被回收？
- 消费者能否声明需要什么能力，并在 Provider 出现、消失或变化时重新协调？
因此，Cordis Context 不只是一个服务容器，也追踪插件产生的 effects。这让"局部装上，再完整卸下" 成为设计目标，而不是依赖开发者记住每一次清理操作。
边界同样重要。Cordis 官方仍明确说明 API 尚未稳定；相关论文材料是项目作者持续维护的设计框架， 不是已经形成同行评审共识的可靠性定理。可逆生命周期减少一类耦合风险，但不会自动消除复杂插件图中的 竞态、瞬时依赖缺失和版本兼容问题。
五个构件怎样形成真正运行的产品
只看插件目录，还无法回答"这一轮实际启用了什么"。DeepSeek Harness 用五个构件把安装包转成运行组合。
Profile：表达产品选择
Profile 是命名后的产品组合。它决定使用哪些 Bundle，并保存产品自己的配置覆盖。Web 与 Headless 可以 共享基础能力，同时选择不同入口和默认策略。
Bundle：分发能力集合
Bundle 将一组 Cordis 配置行和代码作为可复用组合。基础 Bundle 提供模型、工具、持久化、Sandbox、 设置、凭据和遥测等能力；不同 Surface 再增加自己的增量。
Patch：注入环境差异
Bundle、Profile、Home 和命令行 Patch 逐层形成最终插件树。需要特别注意：Patch 按行 ID 定位并替换 整段配置，不是任意 YAML 深度合并。它更可预测，也要求配置者清楚被替换行的完整含义。
Capability Seam：定义替换边界
官方把一个完整接缝拆成 Service Definition、Provider 和 Consumer。Consumer 面向稳定服务，Provider 决定本地、远端或具体协议实现。只有一个接口声明，还不能算完整的可替换能力。
Event Log：保存共同事实
Session 通过追加事件保存模型可见事实，模型历史由日志投影而来；UI、回放、持久化、Fork 与 Resume 也从同一事件流派生。不同 Surface 因此不必各自维护一份"当前 Agent 状态"。
不过，append-only Log 的存在不等于跨机器恢复、所有副作用幂等或长任务可靠性已经成立。这些结论需要 故障注入和真实部署证据。
五者组合起来，才是 DeepSeek Harness 的产品方法：Profile 选择，Bundle 分发，Patch 覆盖，Seam 隔离实现，Event Log 保存共同事实。
灵活性没有消灭复杂度
把 Agent Core 插件化，最直接的收益是把变化限制在更小的边界里。
- 切换 Session 后端，不必顺手重写 Agent Loop。
- 为受限产品移除 Shell，可以从最终组合撤掉相关 Tool 与 Provider，而不是给循环增加分支。
- Web 与 Headless 共享运行语义，不必维护两个逐渐分叉的核心。
- Workspace 或单个 Agent 可以拥有局部能力和独立生命周期。
代价也非常具体：
- 当前行为取决于最终插件树，只读某个入口文件不足以知道实际启用了什么。
- 服务契约除了类型，还必须覆盖错误、流事件、安全与迁移语义。
- 生命周期错误可能表现为重复注册、悬挂事件或 Provider 短暂缺失。
- Bundle 与多层 Patch 提高复用性，也提高配置漂移和升级诊断成本。
- Preview 阶段仍会发生兼容性破坏，采用者需要自行冻结版本并准备迁移。
所以，"Everything is a Plugin"并不是免费获得模块化，而是选择用显式组合图管理变化。
如果产品确实需要切换模型、循环、状态后端、执行世界或 Surface，这种复杂度可能值得。如果应用只有一个 固定 Loop、少量工具和单一部署，显式工作流加普通依赖注入往往更便宜、更容易审计。
当前证据支持到哪一步
截至 2026 年 8 月 14 日，官方仓库 HEAD 仍与固定基线 47f9438 相同；仓库快照内部版本是 rc5， npm 的 @deepseek-ai/dsh 和 PyPI 的 Python SDK 已是 rc6。PyPI 明确标记为 pre-release， 官方 README 仍标注 Developer Preview 并警告会出现兼容性破坏，Cordis 也仍声明 API 尚未稳定。
研究材料中的本机记录能证明更有限的内容：固定源码依赖可安装，Web 构建和页面检查完成，CLI 与配置 解析入口能加载，选定的 Session、Loop、Tools、Jobs、Subagent 和 Compaction 测试通过。缺少模型凭据时， Headless 返回 MISSING_CREDENTIAL。
这能证明凭据门禁真实触发，不能证明真实模型 E2E 已完成，也不能推出生产级恢复、安全或调度能力成立。
一张表判断现在是否值得采用
| 使用情境 | 当前建议 | 进入下一步前要补什么 |
|---|---|---|
| 研究 Agent Runtime，替换 Loop、状态或 Provider | 适合做隔离 PoC | 冻结 Commit 与包版本，导出最终插件树 |
| 同一底盘派生 Web、Headless、SDK 等入口 | 值得验证组合收益 | 检查状态、权限和错误语义是否一致 |
| 需要按 Workspace 或 Agent 动态装卸能力 | Cordis 路线具有针对性 | 测试重复装卸、Provider 消失和资源回收 |
| 只有固定 Loop、单一后端和少量工具 | 优先考虑简单方案 | 先证明动态组合能偿还配置与诊断成本 |
| 准备承载关键生产任务 | 当前应谨慎 | 真实模型 E2E、故障注入、迁移演练和权限审计 |
| 想直接证明它优于成熟产品或工作流框架 | 证据不足 | 固定模型、任务、权限、预算和版本后再比较 |
这张表不负责给项目打总分，而是把架构兴趣和生产证据分开。DeepSeek 已经公开了一份可以阅读源码、 可以运行局部路径的激进 Runtime 设计；它还没有替采用者完成稳定接口、迁移、故障恢复和安全验证。
结论
DeepSeek Harness 最值得关注的地方，不是插件数量，而是它把 Agent Loop、Session、LLM、Tools 与 Surface 都降为插件图中的普通参与者。产品不再围绕一个必须 Fork 的核心类生长，而是由 Profile、Bundle、Patch、 Capability Seam 与 Event Log 组合出来。
它真正获得的是替换边界和生命周期语义，真正支付的是组合、契约、版本、迁移和诊断成本。对需要派生 多个 Agent 产品或动态替换执行能力的团队，这是一条值得认真测试的路线；对固定、简单、强调稳定交付的 应用，更小的显式工作流仍可能是更好的答案。
现阶段最合理的态度不是把它当成熟产品追捧，也不是因为 Preview 就忽略它：把固定源码当作一份可以 验证的架构提案，把生产能力继续标记为待证明。
参考资料
- DeepSeek Harness 官方仓库：github.com/deepseek-ai...
- 固定 Commit 架构文档：github.com/deepseek-ai...
- 固定 Commit Capability Seams：github.com/deepseek-ai...
- Cordis 官方仓库：github.com/cordiverse/...
- DeepSeek Harness Python SDK：pypi.org/project/dee...
证据边界
- 核心插件范围、组合顺序和 Capability Seam：固定官方源码。
- Cordis 的时空组合性：项目作者的设计框架，不视为同行评审共识。
- 收益、代价和采用表：基于固定架构的工程分析。
- 本机记录：仅限已执行命令和页面范围，没有真实模型 E2E。
- 竞品性能、生产恢复、安全与跨机器调度：未验证，不作结论。