一切皆插件:DeepSeek Harness 的设计哲学深度拆解

QUOTE

当 Agent 的能力边界无休止地变化，真正需要被重写的不是功能，而是功能组合的方式。

DeepSeek 官方今天开源了 DeepSeek Harness (DSH) ，并发布了面向全球开发者的预览版（v0.1）（https://github.com/deepseek-ai/deepseek-harness）。

在 Agent 的工程定义中，有一个核心公式：Model + Harness = Agent。Model（模型）负责“大脑”的推理，而 Harness（编排框架）则负责任务拆解、记忆管理、工具调度以及试错回滚等“模型之外的所有工程工作”。

在 AI Agent 框架层出不穷的今天，我们习惯了拿一份标准的“功能清单”去审视新入局者：它有没有沙箱隔离？支不支持持久化工作流？能不能调用子智能体？

当我们带着这些问题去审视 DeepSeek 刚刚开源的 DeepSeek Harness (DSH) 时，很容易得出一种错觉：它似乎只是把 Claude Code、OpenHands 或 LangGraph 里已经存在的成熟概念，重新实现了一遍。

但如果你真的深入翻阅其源码与架构文档，你会发现DSH 真正试图回答的，是——“如果 Agent 的能力边界将无休止地变化，我们该以怎样的形态去组合这些功能？”

它的答案极致且激进：放弃固化的核心，一切皆插件。

本文看点

提到“插件化”，很多人的第一反应是 Pi（一款将极简主义推向极致的 Coding Agent）或者 VS Code。它们的哲学是“主板 + 外设”：保持一个核心引擎（Agent Loop、Session 管理）的绝对稳定，然后提供强大的 Extension API 让开发者挂载自定义的 Tool、Command 或 UI。

这种模式下，“核心”是不可侵犯的，插件是附属品。

但 DeepSeek Harness 走向了彻底的“微内核”无政府主义：系统不存在一个必须被打补丁才能扩展的“特权核心”（Privileged Core）。

在 DSH 的世界里，驱动 Agent 运转的 Agent Loop 是插件，记录对话的 Session Log 是插件，解析大模型的 LLM Adapter 是插件，甚至连工具注册表（Tool Registry）也是插件。

这不仅仅是代码组织方式的改变，而是 Harness 定位的质变： Pi 是“一个可以疯狂改装的 Harness”，而 DSH 试图让“Harness 本身就是动态改装的结果”。 开发者不需要围绕一个既定的核心去添加能力，因为连“什么算核心”本身，都是可以被替换和重组的。

在传统的 Agent 框架中，沙箱、记忆存储、工具调用往往是深度耦合的。而在 DeepSeek Harness 中，模型、工具、技能、会话、沙箱、存储、循环、调度、UI、终端、文件系统，甚至遥测代码，全部被抽象为独立的插件。

这种设计的直接体现就是其极其庞大却又井然有序的工程结构。在其开源仓库中，包含了超过 230 个 Workspace 成员，代码分布在 packages/、apps/、examples/ 等目录中。 每一项你认为“理所应当”的底层能力，都被剥离成了单独的插件包：

交互外设：终端（Terminal）、伪终端（PTY）、子进程管理。

开发辅助：文件系统（File System）、语言服务器（LSP）、网页访问（Web Access）。

智能体组件：技能（Skills）、子智能体（Sub-agents）、工作流（Workflows）、记忆与会话持久化。

这意味着开发者可以像搭乐高一样，自由替换、灵活重组 Agent 的能力边界，完全不需要修改框架底层代码。

看到这里，你脑子里大概会冒出一个问号：“既然连系统核心都能随便拔插替换，那岂不是很容易乱套、甚至彻底崩溃？”

实际上，“一切皆插件”绝不等于一盘散沙。恰恰相反，越是自由的拆卸，越需要极其严苛的秩序。

当你允许大模型把循环机制、聊天记录、工具箱、甚至是沙箱环境像乐高积木一样随意替换时，最大的难题就不再是“怎么去造一块积木”，而是“怎么保证这些积木拼在一起时严丝合缝，拆下来的时候又不会把别的积木扯坏”。

因此，DeepSeek Harness 里真正不可动摇的，从来不是某一个具体的 Agent 功能，而是一套管理积木如何拼装、如何拆卸的“基本法”。这套基本法，就是 Cordis。

支撑起这座庞大“全插拔”架构的，不是 DeepSeek 自己随便糊的一个模块加载器，而是一个名为 Cordis 的底层引擎（https://github.com/cordiverse/cordis）。

如果你去 GitHub 上搜这个仓库，会发现它的 Star 数在这个动辄万星的 AI 时代显得出奇的少。但就是这个看似名不见经传的底层项目，及其背后配套的论文《A Programming Paradigm for Spatiotemporal Composability》，构成了 DSH 最核心的架构骨架。

在 Cordis 的设定中，系统不存在任何需要开发者去“打补丁（Patch）”的特权内核（Privileged Core）。

那么 DSH 究竟是如何运转的？ 答案是：所有的插件，都在向一个共享上下文（Shared Context）贡献三种东西：服务（Services）、类型化事件（Typed Events）和可逆的副作用（Reversible Effects）。

当你想要扩展 DSH 时，你不是去侵入某个主循环的代码，而是仅仅把你的插件挂载（Mount）到其他插件旁边。

传统插件系统最大的痛点，往往不在于“怎么装上去”，而在于“怎么卸下来”。Cordis 漂亮地解决了两个维度的组合难题：

当“一切皆插件”的理念向下延伸到具体的执行环境时，DSH 引入了类似操作系统驱动层的概念：Capability Seam。

平时我们给大模型写工具，比如一个“执行 Bash 命令”的工具，通常是怎么写的？大多是直接调本地的子进程（比如 Node.js 的 child_process）去跑。

在本地测试时这套逻辑跑得很完美。但到了真正要落地的时候，出于安全和隔离的考虑，你通常得把执行环境搬到 Docker 容器，或者更严格的远端 E2B 沙箱里。这时候麻烦就来了：原来的工具废了，你不得不回去改代码，加一堆 if-else 来判断“现在到底在哪种环境”。这就是在企业级落地时最折磨人的“环境漂移”问题。

DeepSeek Harness 解决这个问题的思路，叫 Capability Seam（能力接缝）。

听起来有点学术，但你可以把它完全等同于操作系统的“驱动抽象”。它把一项能力硬生生拆成了三层角色：

这种三段式拆分，带来了极其强悍的跨环境复用能力。

在 DSH 里，大模型只管调用抽象的 bash() 或者 read_file()，它根本不需要知道底下是谁在干活。当你的 Agent 从本地开发机迁移到生产环境时，你只需要把底层的 Provider 从“本地”拔下来，换上“远端沙箱”的 Provider。

只要这一换，神奇的事情就发生了：因为上层的 Bash 终端、文件读写工具、甚至语言服务器（LSP）都是依赖这个“定义契约”的，所以它们会瞬间跟着一起迁移到远端沙箱里去执行，你一行 Agent 业务代码都不需要改。

在传统的 Agent 开发中，为了防止模型“胡作非为”，开发者习惯把权限校验、超时拦截、沙箱隔离等逻辑，一股脑全塞进最核心的 Agent Loop 里。久而久之，指挥中枢变成了一座臃肿的 if-else 屎山。

DSH 的解法是将其剥离为一条 Tool Pipeline。

在 DSH 里，当大模型决定调用工具时，指令并不会直接砸在系统上，而是要穿过一条被拉平的管线：前置拦截 -> 权限审批 -> 真实执行 -> 意图记录。这条 Pipeline 上的每一个节点都是开放的，你可以随时插入策略插件。外围的管线负责拦截危险、维护纪律，从而让核心的 Agent Loop 落得一身轻松，纯粹只做决策。

这种“绝不把逻辑焊死在核心”的哲学，在流程编排上玩得更野，直接演化出了 动态 Workflow。

拿当下主流的 LangGraph 来说，精髓在于人类先画好一张明确的流程图（Graph），让 Agent 在里面按部就班地跑。但 DSH 认为，Workflow 本身也应该只是一个可拔插的插件能力。熟悉 LangGraph 的硬核开发者可能会在心里反驳：“LangGraph 也有 conditional edges（条件边），能实现动态路由啊？但是LangGraph 的动态路由依然受限于人类预先定义的节点和条件边，而 DSH 则是连“图的拓扑结构”本身，都能由大模型在运行时（Runtime）即兴生成并随时销毁。

面对复杂任务，DSH 没有写死的工作流。大模型会根据现场情况，临场生成一段编排脚本（Orchestration Script），直接当场拉起一条专属于当前任务的 Workflow，交由底层引擎去跑。

在这个动态生成的 Workflow 里，如果需要召唤子智能体（Subagent）来分工，最绝的设定出现了：既然一切皆是插件，它召唤的就未必是 DeepSeek 自家的 Agent。你可以把外部的 Claude Code 甚至 Codex 直接包装成提供商（Provider）挂载进来，全盘听它调遣。

既然连 Agent Loop 都被拆成了插件，那么系统的状态靠什么来维系？答案是 Event-Sourced Session（事件溯源会话）。

DSH 为这个组件定下了一条极为严苛的铁律：Model-visible means logged（模型看到的，必须被记录）。

它不再像传统框架那样单纯保存 messages（聊天记录），而是维护一个 Append-only（只增不改）的无损事件账本。这个账本里死死钉着极其底层的细节：当前回合的系统提示词、加载的工具 Schema、推理配置，甚至流式分块。大模型当前上下文里的一针一线，都是由这个底层事件账本“派生投影”出来的。

LangGraph 的核心抽象是基于检查点（Checkpoint）的状态机，它记录的是“计算走到哪里了”，类似于游戏存档，方便任务中断后从断点继续跑。而 DSH 的 Event-Sourced Session 更像飞机的“黑匣子”，它记录的是“在这个 Agent 世界里，当时究竟发生过什么”。

一个就像图片，只记录当下的状态；另一个就像视频，记录了完整的过程。

这种设计，让插件的任意替换有了绝对可靠的溯源依据。

前文拆解的“可逆生命周期”、“能力接缝”与“事件溯源”，单看都只是严谨的底层模块设计。但当你把这些机制串联起来，就会发现 DSH 架构设计的一条暗线：它花费巨大代价拆解系统并制定严格的律法，其实是在为一个极具前瞻性的工程目标做基础设施——让 Agent 具备在运行时动态修改自身 Harness 的能力（Self-Modifying Runtime）。

在常规的 Agent 框架中，如果模型在执行任务时临时缺少一个工具（比如某个小众数据的解析器），任务通常会直接卡死，只能等待人类开发者去补充代码。即使在 Pi 这样以高扩展性著称的框架里，Agent 的做法通常也是写一个扩展文件，然后让系统执行 Reload（重载）来生效。

但在 DSH 的哲学里，这种扩展变成了原生的“内存级闭环”。

借助内置的 cordis_inspect 工具，Agent 获得了“运行时反射（Runtime Reflection）”的能力。它可以直接窥探当前 Harness 的状态：系统里挂载了哪些服务？这些服务暴露了什么样的 API 契约？一旦判断需要补充能力，Agent 可以直接执行以下工作流：

正是在这一步，前文所有的底层铺垫全部展现了价值： 因为有 Cordis 的副作用撤销机制，这个临时插件卸载后，它挂载的监听器、工具注册会被框架自动清扫，系统瞬间恢复干净，不会留下任何内存泄漏或脏状态； 因为有 Event-Sourced Session 的不可变账本，Agent“生成了什么插件、什么时候挂载、什么时候调用”的全过程，都被死死钉在日志里，保证了这种动态行为具有 100% 的可审计性。

这才是“一切皆插件”最深层的哲学意图：LLM 彻底跨过了“写业务代码”的边界，开始“写自己的运行环境”。相比于通过编辑外部文件并重载系统，这种基于内存的实时反射与突变，无疑是动态系统的一大步。

在深挖各类 AI 工具与 Agent 生产力的这段时间里，坦白说，在 DeepSeek Harness 发布之前，我个人最偏爱的框架其实是 Pi。它极简的设计哲学对我来说恰到好处，那套克制而透明的扩展机制，足够让我游刃有余地构建属于自己的自定义插件，而不必陷入臃肿框架的泥潭。

但我们正处在一个智力大爆炸的周期。以前是每隔半年、三个月，现在甚至每隔两三天，你就能听到新模型发布的轰炸。模型变得越来越聪明，这就把我们逼回了最原点的问题：Agent = Model + Harness。当“大脑（Model）”的智力逐渐溢出时，“躯干（Harness）”该如何自处？

Anthropic 给出的答案是“做减法”。在近期 Claude Code 的更新中，随着底层模型能力的跃升，官方直接大刀阔斧地删除了超过 80% 的系统提示词（System Prompt）。是的，既然曾经用来给弱模型打补丁的冗长规则已经被新模型内化，Harness 就该把空间和自由还给模型。

然而，DeepSeek Harness 却给出了一个截然不同、也更为激进的答案。

DeepSeek Harness 目前仍处于 Developer Preview 阶段，甚至官方已经明确警告未来会有破坏性更新。此刻拿它去和成熟的商业化产品比拼“开箱即用”，既不公平，也毫无意义。

它真正独特的价值，在于它展现了下一代 Agent 架构的另一种可能：用一套严格的组合语法（Cordis），去对抗 Agent 能力演进带来的无序膨胀。