一切皆插件:DeepSeek Harness 的架构赌注

最近 DeepSeek 在正式发布新模型的同时也开源了一个叫 Harness 的东西，代码使用MIT许可证，GitHub星标三天冲到了三万。

是的，不只是模型，还有一个完整的 Agent 运行时。

背后的核心主张只有四个字：一切皆插件。

模型适配器、工具注册表、会话日志、沙箱、存储、Agent Loop、调度编排、UI，全部实现为可挂载、可替换、可卸载的插件。

DeepSeek Harness 与 Claude Code、OpenAI Codex 等成品 Coding Agent 由此产生了根本差异：它更接近一个开放的 Agent Runtime 内核，而非一个"更聪明的队友"。

我们来看看这个赌注到底押在哪。

"一切皆插件"这句话并不新鲜，VS Code、Eclipse 都说过类似的话。问题在于：绝大多数插件框架只解决了"装得上"，没解决"卸得干净"。

DeepSeek Harness 的底座是一个叫 Cordis 的元框架，并非 DeepSeek 自研，而是开发者 shigma 创建的开源框架，已经在聊天机器人平台 Koishi 上运行了四年，积累了超过 4,000 个社区插件。Cordis v4 与 DeepSeek Harness 同日发布，其设计依据是同日发表的论文《A Programming Paradigm for Spatiotemporal Composability》。

论文将动态组合系统的正确性拆成两个维度。

时间可组合性：当一个插件被卸载时，它此前造成的一切影响（事件监听器、内存分配、命令处理器）都必须能被完整撤销，使系统恢复到"仿佛它从未被加载过"的状态。传统系统反复热重载后逐渐"变慢变脏"，根源就在这里——虽然代码移除了，但还是有副作用残留。

空间可组合性：当插件 A 提供的服务被插件 B 依赖时，系统必须保证 B 只在 A 就绪后才加载，在 A 停止前先卸载，且当 A 被替换时，所有受影响的组件都按声明的依赖契约得到正确通知。

Cordis 的解决方案是在运行时层面引入 `ctx.effect` 机制：插件注册副作用时返回一个"逆操作"清理函数，运行时存储并在卸载时按逆序执行。语言层面，这类似于 C++ 的 RAII 或 Rust 的 Drop trait。但 Cordis 将其从语言级提升到了运行时级，即便由不同团队编写的插件，也能被统一安全清理。

不过，Cordis 只能撤销被框架托管的副作用。如果插件发起一次 Git push 或写入远程数据库却没将其纳入 `ctx.effect` 管辖，这些外部副作用在卸载后依然残留。框架提供的是"可撤销性的必要机制"，最终的安全保证仍依赖插件作者的编程契约。

DeepSeek Harness 提供四种预设模式，分别面向不同工程场景。

第一个是 Standard（标准模式），也是默认选项。完整 Coding Agent 能力：文件系统、Shell、Web 搜索、Skill、计划模式、子 Agent，适合日常编码和项目分析。

第二个是 Code（代码模式），模型生成 TypeScript 代码来编排多轮工具调用，适合大规模搜索、并行读取等需要程序化控制的场景。

第三个是 Minimal（最小模式），仅保留 Shell 与文件编辑器，砍掉了压缩、搜索、Skill、计划和子 Agent。这个模式的存在本身就值得关注。DeepSeek 官方对 V4-Flash 和 V4-Pro 的基准测试用的就是它。

你可能会问，为什么要单独搞一个"阉割版"模式？

因为他们已经意识到"Harness 本身会影响模型能力评测"这一方法论问题。用 Minimal 模式固定测试环境，是为了剥离 Harness 层面的额外增益，更公允地衡量模型裸能力。对希望建立内部模型评测体系的团队，这个设计思路有直接借鉴价值。

第四个是 Creator（创作模式），支持运行时检查、内存中试验 Cordis 插件、组合和开发新的 Agent Preset，面向想自定义 Agent 的开发者。

架构层面，系统按 Cordis 的 Context 概念划分能力子系统：Session（追加式日志）、System Prompt、Tools（作用域受限的工具注册表）、Agent（接口与实时注册表）、LLM（模型适配器）。每个子系统通过 Context Key 暴露服务，如 `ctx.llm`、`ctx.tools`、`ctx.sessions` 等。

实际效果怎么样呢？替换模型供应商只需替换 `ctx.llm` 下的适配器插件，替换沙箱只需替换文件系统与进程提供者插件，不需要触碰 Agent Loop 或工具注册表的代码。DeepSeek Harness 也确实没有将自身锁定为仅支持 DeepSeek 模型，同时支持 Anthropic、OpenAI、AWS Bedrock、Azure、Google Gemini 等主流供应商。

会话日志是另一个有分量的工程决策。DeepSeek Harness 将追加式 Session Event 日志设计为一条强约束："模型可见的一切必须可从日志中重建。"系统提示词、推理过程、工具调用与结果、子 Agent 调度、上下文注入全部被记录，并支持搜索、恢复、分叉与回放。OpenAI Codex App Server 的 Item/Turn/Thread 会话模型有相似的工程动机，但实现路径不同：Codex 采用协议化的双向 JSON-RPC 会话模型，DeepSeek Harness 依托 Cordis 的事件系统，将日志本身作为插件系统状态变化的直接产物。

把 DeepSeek Harness 放到当前主流 Agent 基础设施中看，差异会更清晰。

先看 Claude Code / Claude Agent SDK。 Anthropic 的 SDK 提供与 Claude Code 相同的工具、Agent Loop 和上下文管理，以 Hooks 和 Subagents 为核心扩展机制。但模型支持限定于 Claude 系列，Agent Loop 本身由 SDK 固定提供，开发者只能在既定框架内添加扩展点。

再看 OpenAI Codex / Agents SDK。 Codex App Server 以 Item/Turn/Thread 三层协议解耦核心逻辑与多端客户端，Agents SDK 采用 Agent/Tool/Handoff/Guardrail 四个极简原语。编排逻辑由开发者代码显式控制，但核心 Loop 仍由厂商定义。

LangGraph 则是通用的图编排框架，基于图的状态化编排，节点表示 Agent 或计算步骤，支持暂停恢复，但非专为 Coding Agent 设计，节点和边的定义需要开发者显式承担。

DeepSeek Harness 的差异化主张在于：Agent Loop 本身也是可替换的插件，而不是需要被"扩展"的固定核心。理论上开发者可以完全替换掉标准的 ReAct 式循环，实现自定义的规划-执行-反思循环，不必绕过或包裹既有的 Loop 实现。这更接近操作系统内核与用户态服务的关系，而非应用与插件的关系。

但这种开放性是权衡，不是单向优势。SDK 模式的好处是厂商可以对 Loop 的健壮性、上下文压缩质量、重试策略做集中优化和持续验证，开发者可以直接信任这些经过长期生产验证的默认行为。DeepSeek Harness 将更多正确性责任下放给了插件开发者和企业集成方。"开放"本身并不自动等于"更安全"或"更适合直接生产部署"，其价值兑现取决于插件生态的质量、文档完善度与安全审查机制能否同步成熟。

DeepSeek 官方在《安全使用政策》中明确将 Harness 定性为"本地优先、可扩展的 Coding Agent 与 Agent 开发运行环境"，并特别指出：由于 Harness 具备运行代码和在用户计算机上执行操作的能力，会带来独特的安全风险。官方给出的核心安全建议包括：使用专用虚拟机或容器运行、始终审查 Agent 生成的代码、避免提供敏感信息、对高影响操作要求人工确认、仅安装已审查的插件。

数据处理方面，Harness 默认在用户本地设备上处理和存储数据，未经用户同意不上传服务端。本地优先架构对需要数据不出域的中国企业具有潜在价值，但仍需结合具体插件逐一审查数据流向，不能仅凭整体定位就假定所有插件都不会产生数据外发行为。

对中国企业来说，DeepSeek Harness 的模型供应商中立设计理论上可以同时接入 DeepSeek、Qwen、GLM、MiniMax 等国产模型以及本地部署的开源模型，MIT 许可证也降低了源码审查和二次开发的门槛。但以上判断目前仍停留在"架构潜力"层面。v0.1 作为刚发布几天的开发者预览版，尚无公开的中国企业私有化部署案例，插件生态、身份认证集成能力、与国产模型 API 的适配质量都需要通过实际 PoC 逐一确认。

关于生产采用，建议按四级框架评估自身阶段：

无论企业最终是否直接采用 DeepSeek Harness，其架构设计对自研 Agent Platform 的团队具有独立参考价值。

值得借鉴的五条原则：

能力与实现解耦。Agent 应依赖稳定的服务接口，而非绑定具体的模型、工具或存储实现，这是通过 `ctx.llm`、`ctx.tools`、`ctx.sessions` 等 Context Key 机制所体现的核心原则。

Runtime First。将 Session、Sandbox、Policy、Loop、Telemetry 当作系统一等公民来设计，而非业务逻辑之外的附属能力。

插件生命周期可治理。注册一个插件并不等同于安全，必须追踪其 effect、依赖关系和占用资源，并保证撤销路径的存在。

事件溯源优先。将每一次 Agent 行为作为可查询、可回放、可审计的事件记录下来。OpenAI Codex App Server 的会话模型也体现出相似方向。

控制平面与数据平面分离。模型推理和工具执行属于数据平面，预算控制、审批流程、路由策略、终止条件、审计记录则应作为独立的控制平面能力统一治理。

同样要清楚哪些不该直接复制：

不该为了"万物皆插件"的架构美感而将本应稳定的核心过度拆碎，这会显著增加认知复杂度和调试难度。不该允许高权限插件在缺乏隔离和签名验证的条件下动态加载——官方"仅安装审查过的插件"这条提示恰恰说明，插件化本身不自动带来安全性。追加式日志的完整性与日志的安全治理是两件事，日志中可能包含密钥片段等敏感信息，不能因为"可审计"就忽视数据安全。支持运行时自我修改的 Creator 模式更适合作为受控的开发调试环境，不应直接开放到生产环境允许无监督的自主演化。

DeepSeek Harness 最值得关注的贡献，是把"Agent 运行时应该如何被设计"这个问题，从产品实现细节拉到了可以被公开讨论、验证和借鉴的架构范式层面。Cordis 对插件生命周期、依赖关系与副作用撤销的系统性处理，加上将会话轨迹作为运行时一等数据的设计思路，是当前公开可得的高参考价值开源 Agent 架构材料之一。

但生产环境中的最终采用决策，仍应建立在企业自身完成的独立验证之上，而非仅依据产品发布时的架构主张。

至于这个"一切皆插件"的赌注能不能赢，最终拼的可能不是架构多优雅，而是插件生态能不能长起来。Koishi 用了四年才有 4,000 个插件。Agent 场景比聊天机器人复杂得多，DeepSeek Harness 的生态成熟度，恐怕也需要用年来看。