前面研究 Claude Code、Codex 时我们逐渐形成了一套比较稳定的 Agent Harness 认知User Goal ↓ Harness ↓ Instruction ↓ Skill / Agent / Tool ↓ Policy ↓ Sandbox ↓ Execution在这套模型里通常存在一个相对稳定的Harness Core然后再围绕 Core 挂载Skill Plugin MCP Hook Custom Agent也就是说我们习惯的扩展模型大致是Harness Core │ ┌───────────┼───────────┐ ↓ ↓ ↓ Skill Plugin Tool │ │ │ └───────────┼───────────┘ ↓ Runtime但 DeepSeek 最近开源的DeepSeek Harness在架构上选择了一条明显不同的路线。官方给这个项目的核心定位非常直接Everything is a PluginDeepSeek Harness简称dsh是 DeepSeek AI 官方开源的 Agent Harness目前仍处于 Developer Preview 阶段官方明确提示其接口和架构仍然会快速演进并可能发生兼容性破坏。项目底层由 Cordis 驱动。真正值得研究的地方并不是DeepSeek Harness 支持 Plugin而是DeepSeek Harness 本身就是通过 Plugin 组合出来的。官方架构文档明确把 Model Adapter、Tool Registry、Session Log、Agent Loop 都纳入 Plugin 体系并说明运行中的 dsh 是启动阶段通过多层配置组合出来的一棵 Plugin Tree。所以理解 DeepSeek Harness 时需要先把传统的Harness Core ↓ Load Plugin换成另一种思路Plugin Plugin Plugin Composition ↓ Plugin Tree ↓ Agent Runtime这也是我们这一篇首先要建立的架构地图。一、先认识 DeepSeek Harness它到底不一样在哪里1. DeepSeek Harness 是什么从使用方式来看dsh 仍然是一个典型的 Agent Harness。官方目前可以直接通过npx deepseek-ai/dsh web启动 Web UI默认监听http://127.0.0.1:3080也可以从源码运行gitclone https://github.com/deepseek-ai/deepseek-harness.gitcddeepseek-harnesspnpminstallpnpmrun buildpnpmdsh web这些都是当前官方 README 给出的运行入口。如果只从产品形态来看它很容易让人联想到Claude Code Codex OpenCode这些 Coding Harness。因为它们最终都需要完成类似的事情User ↓ LLM ↓ Agent Loop ↓ Tool ↓ Filesystem / Shell / Web ↓ Observation ↓ Next Loop但 DeepSeek Harness 真正特别的地方不在这条 Agent Loop 本身而在于这条 Loop 是怎么被构造出来的。2. 传统 HarnessCore 先存在在很多 Harness 中我们可以用一个比较直观的模型理解Harness Core │ ├── Session Manager ├── Agent Loop ├── Tool Registry ├── Context Manager ├── Permission └── Runtime然后 Core 再提供Extension Point让外部能力加入Plugin Skill Hook Tool Agent于是Core ↓ Extension API ↓ Plugin这是一种典型的Core Extension架构。3. DeepSeek HarnessRuntime 本身也是 CompositionDeepSeek Harness 官方架构文档则强调Cordis 下面的插件可以向共享 Context 贡献 Service、Typed Event 和可逆的 Effect包括 Model Adapter、Tool Registry、Session Log、Agent Loop 在内的产品组件本身都是 Plugin。所以可以把它抽象成Cordis │ ┌───────────────┼───────────────┐ ↓ ↓ ↓ LLM Plugin Tool Plugin Session Plugin │ │ │ └───────────────┼───────────────┘ ↓ Agent Loop Plugin ↓ Runtime这里最值得注意的是Agent Loop自己也不是绝对固定的 Core。官方在 package 设计里专门将core/agent和core/agent-loop拆开前者提供 Agent 接口与 Registry后者提供默认 Driver官方 package 说明也明确指出dsh-agent-loop是可替换的。因此 DeepSeek Harness 更接近Plugin ↓ Composition ↓ Runtime而不是Runtime ↓ Plugin这就是理解整个项目的第一把钥匙。二、从源码目录建立 DeepSeek Harness 的静态地图理解一个 Harness第一步仍然应该从磁盘结构开始。因为目录结构往往能够回答几个非常基础的问题Core 在哪里 Capability 在哪里 Runtime 在哪里 Plugin 在哪里 配置与分发在哪里1. 先看整个 Monorepo目前 DeepSeek Harness 官方仓库根目录主要包括deepseek-harness/ │ ├── .agents/ ├── .claude/ ├── .github/ │ ├── apps/ ├── assets/ ├── docs/ ├── examples/ │ ├── native/ ├── packages/ ├── patches/ ├── python/ ├── scripts/ ├── vendor/ ├── website/ │ ├── AGENTS.md ├── CLAUDE.md ├── package.json ├── pnpm-workspace.yaml └── ...这是一个明显的 Monorepo官方仓库当前确实以apps/、packages/、native/、python/、vendor/等目录组织代码。如果从 Harness 架构而不是普通源码阅读的角度看可以先压缩成deepseek-harness/ │ ├── apps/ │ → Product Entry │ ├── packages/ │ → Harness Components │ ├── vendor/ │ → Underlying Framework / Vendored Dependencies │ ├── native/ │ → Native Runtime Capability │ ├── python/ │ → Python-side Capability │ └── docs/ → Architecture / Development Contract第一篇不需要把每个目录都展开。真正应该重点关注的是packages/因为大部分 Harness 能力都在这里。2. packages 并不是一个简单的 Tool 集合当前官方packages/README.md已经列出了非常多的 package group例如core api llm subprocess shell terminal sandbox fs lsp skill context subagent jobs workflow web bundle extensions hooks session settings credentials workspace interaction boot host client ...官方给每个 group 都定义了明确角色例如core → Product API spine llm → LLM capability family shell → Bash capability family fs → Filesystem capability family skill → Skill capability family subagent → Subagent capability family workflow → Workflow seam sandbox → Process confinement bundle → Profile patch layers这些角色都可以在当前 package 索引里直接确认。不过如果直接把几十个 package 平铺给读者其实很难建立整体认知。所以为了理解架构我们可以做一次工程化重新归类。注意下面这个分类不是 DeepSeek 官方真实目录层级而是本文为了理解 Harness 使用的架构抽象。3. 可以把 packages 重新理解成五层第一层Runtime CoreRuntime Core │ ├── core ├── llm ├── session ├── context ├── settings └── interaction主要解决Agent Session Prompt Tool Registry LLM Context Human Interaction其中官方核心架构目前明确列出了ctx.sessions ctx.systemPrompt ctx.tools ctx.agents ctx.agentLoop ctx.llm这些 Context Service。第二层Execution CapabilityExecution Capability │ ├── fs ├── subprocess ├── shell ├── terminal ├── lsp ├── web ├── code-runtime └── sandbox这一层解决Agent 到底可以操作什么。例如Filesystem Process Shell PTY Language Server Web Code Execution第三层Agent CapabilityAgent Capability │ ├── skill ├── subagent ├── workflow ├── jobs ├── plan ├── goal └── preset这一层开始进入Agent 如何组织工作。例如Skill Delegation Workflow Background Job Plan Goal Agent Preset第四层Runtime InfrastructureRuntime Infrastructure │ ├── credentials ├── storage ├── workspace ├── hooks ├── extensions └── telemetry related components主要解决Credential Storage Workspace Lifecycle Extension Runtime Modification Observability第五层Composition / Product SurfaceComposition │ ├── bundle ├── boot ├── host ├── client ├── api └── sdk主要解决这些能力最终怎么被组合成一个可以运行的产品。于是原本看起来非常复杂的几十个 packages就可以先收敛成DeepSeek Harness │ ├── Runtime Core │ ├── Execution Capability │ ├── Agent Capability │ ├── Runtime Infrastructure │ └── Composition从这里开始整个项目就清楚很多了。4. 先画出第一张静态架构图如果暂时不考虑实现细节可以得到DeepSeek Harness │ ┌─────────────────┼─────────────────┐ ↓ ↓ ↓ Runtime Core Capability Infrastructure │ │ │ ├────────────┬────┴───────┬─────────┤ ↓ ↓ ↓ ↓ Agent Tool Session Sandbox │ │ │ └────────────┼────────────┘ ↓ Composition ↓ Cordis但是这里马上出现一个问题这些模块到底是怎么连在一起的答案就在Cordis三、Cordis为什么 DeepSeek Harness 能做到 Everything is a PluginDeepSeek Harness 官方将 Cordis 定义为 dsh 底下的 Framework。插件通过共享 Context 提供Service Typed Event Reversible Effect同时插件卸载时对应注册可以反向撤销。所以第一篇里可以先把 Cordis 理解成Cordis Plugin Runtime Service Composition Event Extension Lifecycle Management注意这仍然是为了理解系统而做的工程抽象。1. Context所有 Plugin 的公共运行空间Cordis 中一个非常核心的概念是ContextPlugin 并不是互相直接硬编码调用。它们更多是围绕共享 Context 注册或消费能力。例如官方架构文档列出的ctx.sessions ctx.systemPrompt ctx.tools ctx.agents ctx.agentLoop ctx.llm这些都属于 Runtime 中可以被其他 Plugin 使用的 Service。可以把它抽象成Context │ ┌─────────────┼─────────────┐ ↓ ↓ ↓ Service Event Effect │ │ │ ↓ ↓ ↓ Capability Extension Lifecycle如果熟悉 Spring可以把其中Service暂时类比成Bean / Service Registry但它并不只是一个普通 DI Container因为 Cordis 还把Event Effect Plugin Lifecycle统一纳入了运行模型。2. ServicePlugin 如何向 Runtime 提供能力例如LLM Plugin ↓ ctx.llm或者Tool Plugin ↓ ctx.tools再比如Session Plugin ↓ ctx.sessions从工程上可以抽象成Plugin ↓ Provide Service ↓ Context ↓ Other Plugins Consume于是各个 Runtime 部件不需要直接依赖某个固定实现。这也为后面的Provider Replacement提供了基础。3. EventRuntime 行为本身就是扩展点Cordis 的第二个重要机制是EventDeepSeek Harness 官方架构文档明确把 Event 称为扩展点并把事件大致分成Session Events Agent Events Capability Events例如agent/* tools/* fs/*这些事件允许 Plugin 在不直接修改 Agent Loop 的情况下介入 Runtime。例如官方当前的 Tool Pipeline 包含tool/call ↓ tools/pre-execute ↓ tools/execute ↓ tools/post-execute ↓ tool/result如果放到我们之前研究 Codex Hook 的语言里就非常容易理解PreToolUse Tool Execution PostToolUse但 DeepSeek Harness 做得更彻底Event不是额外附加在 Harness 外围的一套 Hook 系统而是 Runtime 自身的扩展机制。4. EffectPlugin 生命周期为什么可以撤销Cordis 还有一个非常值得注意的概念Effect官方架构强调Plugin 的注册本身可以被视为可逆 EffectPlugin 卸载时对应注册会被撤销。所以可以抽象成Plugin Load ↓ Register Service ↓ Register Event ↓ Create Effects ↓ Runtime Running当 Plugin 被卸载Plugin Unload ↓ Dispose Effects ↓ Remove Events ↓ Remove Services于是 Plugin 不再只是startup hook而拥有真正意义上的Lifecycle这也是动态 Plugin Runtime 必须具备的基础。5. Everything is a Plugin 到底到了什么程度现在再回来理解官方的Everything is a Plugin就会清楚很多。官方直接列出的例子包括Model Adapter Tool Registry Session Log Agent Loop这些都是 Plugin并且都可以通过配置替换。也就是说Agent Loop并不是所谓不可替换的 Harness Kernel官方文档甚至明确表达了一个非常重要的原则扩展 dsh 不应该依赖修改某个特殊的特权核心而是把新的 Plugin 挂到现有 Plugin 旁边。于是Everything is a Plugin真正表达的是Harness Runtime 的组成部件原则上都通过统一 Plugin 机制参与组合而不是由一个巨大、不可替换的 Core 对外暴露少量扩展点。这和传统 Plugin System 的区别非常大。四、CapabilityTool、Skill、Subagent 为什么可以统一起来理解完 Cordis还不能直接进入 Bundle 和 Profile。中间还有一个非常重要的概念Capability Seam这是 DeepSeek Harness 设计中非常值得关注的一层。官方将一个 Seam 定义为一个可替换的 Capability并且拆成三个角色Service Definition Service Provider Consumer这实际上回答了一个非常重要的问题Tool 到底是不是 CapabilityDeepSeek Harness 给出的答案更接近不是。1. Capability 不是一个 Tool 函数传统 Agent Framework 很容易把read_file() write_file() bash() web_search()直接称为Capability但实际上 Tool 往往只是模型看到的接口。真正完成工作的可能是另一个底层实现。DeepSeek Harness 将它进一步拆成Service Definition ↓ Service Provider ↓ Consumer例如 Filesystem 可以抽象为Filesystem Interface ↓ Filesystem Provider ↓ read_file / write_file其中Service Definition定义能力是什么Provider定义能力在哪里执行而Consumer决定谁来使用这个能力Consumer 很多时候才是Model-facing Tool官方文档明确说明Consumer 通常可以是面向模型的 Tool但 Tool 本身并不等同于整个 Capability Seam。2. 用 Filesystem 举一个简单例子为了理解这个设计我们可以做一个 Java 风格工程抽象interfaceFileSystem{Stringread(Stringpath);voidwrite(Stringpath,Stringcontent);}这是Service Definition然后可以有LocalFileSystemProvider SandboxFileSystemProvider RemoteFileSystemProvider这些是Service Provider最后read_file write_file search_file是模型看到的Consumer / Tool于是形成Capability │ Service Definition │ ┌─────────┼─────────┐ ↓ ↓ ↓ Local Sandbox Remote Provider Provider Provider │ └─────────┼─────────┘ ↓ Consumer ↓ Tool这里的 Java Interface 只是为了理解架构并不是 DeepSeek Harness 的真实内部类。3. Provider 为什么比 Tool 更值得关注这种拆分最有价值的地方在于Tool 可以不变但Execution Backend 可以变化。例如 Agent 仍然调用bash但底层可以从Local Machine切换为Remote Sandbox官方架构文档专门以 Filesystem 和 Subprocess 为例说明它们共享执行世界因此当 Provider 被指向远程 Sandbox 时Bash、PTY、LSP 可以一起迁移而不需要每个 Tool 分别复制一套远程实现。这个设计非常关键。因为真正的企业 Harness 往往不是Tool 要不要换而是Tool 在哪里执行。例如Developer Laptop Docker Sandbox Remote VM Kubernetes Pod Secure Execution Environment都可能提供同一个bash能力。4. Skill、Subagent、Workflow 也被放进 Capability Family当前官方 package 索引里明确存在skill/ subagent/ workflow/并分别描述为Skill capability family Subagent capability family Workflow seam其中 Skill 包含 Provider Registry、本地 Provider 和面向模型的 Catalog/LoaderSubagent 包含 Provider Registry Contract 和 Delegation ToolWorkflow 则包含 Seam、Worker Engine 与面向模型的 Workflow Tool。因此可以把它们统一理解成Capability │ ┌─────────────────┼─────────────────┐ ↓ ↓ ↓ Filesystem Skill Subagent │ │ │ ├─────────────────┼─────────────────┤ ↓ ↓ ↓ Shell Workflow Web这和我们此前习惯的Tool Skill Agent Workflow各自拥有完全独立扩展体系的做法不太一样。DeepSeek Harness 更倾向于先问这个能力的接口是什么 谁提供它 谁消费它然后再决定它最终表现成Tool Agent Workflow UI中的哪一种形式。五、Plugin、Bundle、Profile一个 Harness Runtime 是怎样“拼”出来的到这里我们已经知道Plugin可以提供 Service、Event 和 Effect也知道Capability可以由 Definition、Provider 和 Consumer 组成。但还有一个更关键的问题dsh 启动时到底加载哪些 Plugin答案并不是一个固定写死的列表。而是Profile Bundle Patch共同完成 Runtime Composition。1. PluginRuntime 最基本的组成单元首先是Plugin从我们目前看到的架构可以把它理解为Runtime Component例如LLM Adapter Plugin Tool Plugin Session Plugin Agent Loop Plugin Sandbox PluginPlugin 进入 Cordis Context 后可以Provide Service Listen Event Create Effect最终成为 Runtime 的组成部分。2. Bundle一组 Plugin 的组合与分发如果只有 Plugin会出现另一个问题一个完整 Harness 可能需要几十个 Plugin。每次启动时逐个配置Plugin A Plugin B Plugin C Plugin D ...显然不可维护。因此 DeepSeek Harness 又增加了Bundle官方当前定义的 Bundle 是一个 npm package它通过 package manifest 中的dsh.bundle指向一个cordis.patch.yml从而成为 Profile 可以加载的一层 Patch。可以把它理解成Bundle Plugin Composition Package结构大致可以抽象成my-bundle/ │ ├── package.json │ │ │ └── dsh.bundle │ ├── cordis.patch.yml │ └── optional runtime glueBundle 最核心的内容并不是一个巨大 Runtime 类而是哪些 Plugin Row 应该被挂载。3. 官方当前有三个关键 Bundle目前官方 Bundle 目录明确列出了base web-app headless其中base是所有 Profile 先加载的共享核心层web-app增加浏览器侧运行面headless增加无 Host / Web Layer 的一次性任务运行方式。官方dsh-base当前包含的基础 Runtime 组合涉及Model Adapters Default Model Selection Tools Persistence Policy Settings / Credentials Telemetry Subagent Providers等能力并作为每个 Profile Bundle Stack 的第一层。所以dsh-base可以粗略理解为Default Runtime Foundation但仍然要注意它不是一个不可修改的 Core Binary。它本质仍然是一层 Runtime Composition。4. Profile决定“我要启动哪一种 dsh”在 Bundle 之上还有Profile官方定义 Profile 是一个存在于 Harness Home 中的命名组合它记录要堆叠哪些 Bundles 安装哪些额外 Plugin 用户自己的 cordis.patch.yml当前官方提供web headless两个模板。所以web可以先抽象理解为Profile: web │ ├── dsh-base ├── dsh-web-app └── user patch而headless则大致是Profile: headless │ ├── dsh-base ├── dsh-headless └── user patch于是三者的关系就清楚了Plugin → Runtime Component Bundle → Plugin Composition Package Profile → Named Runtime Composition5. Patch为什么 Runtime 可以层层覆盖这里最关键的配置文件是cordis.patch.yml官方架构目前给出了明确的层叠顺序Empty Entry List ↓ Profile 中声明的 Bundles ↓ Profile cordis.patch.yml ↓ Home cordis.patch.yml ↓ --patch CLI Overlay所以真正启动出来的 Runtime 并不是某一份固定配置而是Bundle A Bundle B Profile Patch Home Patch CLI Patch Effective Plugin Tree这个机制和我们前面分析 Codex 时的Effective Config有一点很像。但它更进一步。Codex 更多是在计算最终哪个配置值生效。DeepSeek Harness 这里实际上是在计算最终有哪些 Plugin Row 存在 以及它们共同构成怎样的 Runtime Topology。所以可以把它称为Effective Runtime或者更精确一点Effective Plugin Tree官方也提供了dsh--profileweb --dump-config来查看当前环境真正会启动的组合树。6. 所以 dsh 的启动过程是什么到这里就可以把启动过程串起来。传统 Harness 很容易理解成Harness Start ↓ Initialize Core ↓ Load Config ↓ Discover Plugins ↓ Register Plugins ↓ Start RuntimeDeepSeek Harness 更接近dsh Start ↓ Select Profile ↓ Resolve Bundle Stack ↓ Apply Patch Layers ↓ Build Plugin Tree ↓ Mount Plugins ↓ Register Services ↓ Register Events ↓ Create Effects ↓ Construct Runtime ↓ Start Agent Loop官方明确描述运行中的 dsh 是在启动阶段从有序 Layers 组合出来的 Plugin Tree。所以这里真正重要的一句话是Runtime 并不是先存在然后再加载 PluginRuntime 本身就是 Plugin Composition 的结果。7. 再看 Agent Loop就容易理解了官方当前把一次执行区分成Turn Step其中一个 Step 是一次模型请求 该请求产生的 Tool Calls一个 Turn 则可以包含零到多个 Step。核心链路可以简化成turn/start ↓ claim input ↓ assemble prompt tools ↓ agent/pre-step ↓ step/start ↓ derive model history ↓ agent/request ↓ llm/stream ↓ assistant/message ↓ tool/call ↓ tools/pre-execute ↓ tools/execute ↓ tools/post-execute ↓ tool/result ↓ step/end ↓ Next Step? ↓ turn/end为什么这条链可以高度扩展因为Agent Loop不是把所有逻辑硬编码进去。大量行为通过Service Event参与 Runtime。例如agent/pre-step可以介入模型即将看到的输入tools/pre-execute可以介入 Tool 执行之前tools/post-execute可以处理执行后的结果。这就是Composable Runtime真正进入运行阶段后的样子。六、重新理解 DeepSeek Harness从 Plugin System 到 Composable Runtime把前面的结构连起来之后就可以看出 DeepSeek Harness 真正值得研究的地方了。它不仅仅是在做一个新的 Coding Agent而是在探索Agent Harness 本身应该怎样被构造。1. 它和传统 Harness 最大的区别是什么如果用最简化的方式表达传统 Harness 更接近Harness Core │ ┌────────┼────────┐ ↓ ↓ ↓ Skill Tool PluginDeepSeek Harness 更接近Profile │ Bundles │ Patch │ ↓ Plugin Tree │ ┌───────┼────────┐ ↓ ↓ ↓ LLM Tool Session │ │ │ └───────┼────────┘ ↓ Agent Loop ↓ Runtime这两种架构关注的问题并不完全一样。第一种问Harness 有哪些 Extension Point第二种则进一步问Harness 本身能不能就是一种 Composition2. Plugin System 和 Composable Runtime 不是一回事很多系统都有Plugin System但通常意味着Core Optional ExtensionsDeepSeek Harness 更值得注意的是Core-like Components本身也进入 Plugin Composition。于是Plugin不再只是给 Runtime 增加一个功能还可能参与定义 Runtime 本身。所以我更愿意把 DeepSeek Harness 当前的架构称为Composable Agent Runtime而不只是Plugin-based Agent这是本文基于官方架构做出的工程抽象不是 DeepSeek 官方给出的正式架构名称。3. 这会改变我们对 Marketplace 的理解我们之前研究 Claude Code、Codex 时逐渐形成了一个 Marketplace 模型Marketplace ↓ Plugin Package ↓ Install ↓ Capability Registry ↓ Harness Runtime也就是说Marketplace主要负责分发Capability例如Skill Tool Agent MCP Hook但是到了 DeepSeek Harness这个模型可能需要再增加一层Marketplace ↓ Plugin / Bundle ↓ Profile ↓ Runtime Composition ↓ Plugin Tree ↓ Capability ↓ Agent Runtime这意味着 Marketplace 未来分发的不一定只是一个能力还可能是一套 Runtime 组合方案。例如可以设想Java Coding Profile Security Review Profile Research Profile Data Analysis Profile每个 Profile 都可能组合不同的Model Adapter Tool Set Skill Subagent Workflow Sandbox Policy Agent Loop所以Marketplace 中的商品可能从 Capability Package 进一步演进成 Runtime Blueprint。这是 DeepSeek Harness 对我们整个 Harness Marketplace 系列非常重要的一个启发。4. 对自研 Harness 的启发Registry 之外还需要 Composer我们此前设计企业 Agent Harness 时很容易想到PluginRegistry CapabilityRegistry SkillRegistry AgentRegistry ToolRegistry PolicyRegistry这些组件解决的是系统里有哪些能力。但是 DeepSeek Harness 提醒了我们另外一个问题这些能力如何组成不同类型的 Runtime于是可能还需要BundleRegistry RuntimeProfile RuntimeComposer形成Marketplace │ ↓ PluginRegistry │ ↓ BundleRegistry │ ↓ RuntimeProfile │ ↓ RuntimeComposer │ ↓ Effective Runtime │ ↓ CapabilityRegistry │ ↓ Agent Loop例如可以做一个工程抽象recordRuntimeProfile(Stringname,ListStringbundles,ListStringplugins,StringpolicyProfile){}再通过RuntimeProfile ↓ BundleResolver ↓ PluginResolver ↓ RuntimeComposer ↓ Effective Runtime构建不同的 Agent 环境。这不是 DeepSeek Harness 的真实 Java 实现而是我们从它的架构模式推导出的自研 Harness 设计。5. 不同 Agent 甚至可以拥有不同 Runtime例如Developer Agent可以组合Filesystem Write Shell LSP Git Skill Subagent而Reviewer Agent可以组合Filesystem Read Search LSP No Shell Write No NetworkProduction Agent 则可能使用Remote Sandbox Strict Permission Audited Tool Gateway Restricted Network这已经不是简单Tool Permission问题。而是Runtime Composition问题。6. Everything is a Plugin 也会带来新的治理难题当然这种高度插件化设计并不是只有好处。越多东西可以替换就意味着越多东西需要治理。例如谁可以安装 Plugin 谁可以发布 Bundle 谁可以修改 Profile Plugin 可以注册哪些 Service 一个 Plugin 能否替换 Agent Loop 谁可以提供 Sandbox Provider 谁可以提供 Credential Provider 不同 Plugin 出现 Service 冲突怎么办甚至更危险的问题是如果安全组件自己也是 Plugin 谁来保证这个 Plugin 不被替换所以企业环境最终一定需要建立Plugin Trust Bundle Trust Profile Policy Provider Allowlist Signature Version Pin Capability Diff Permission Review Audit换句话说Everything is a Plugin最终很自然会推导出Everything needs Governance这也会成为 DeepSeek Harness 系列后面权限、Sandbox 和企业 Marketplace 篇的重要问题。7. 最后把整个 DeepSeek Harness 收敛成一张图经过这一篇我们可以先形成下面这张统一架构图Marketplace │ ↓ Plugin / Bundle │ ↓ Profile │ Patch Layers │ ↓ Plugin Tree │ ↓ Cordis Context │ ┌──────────────────┼──────────────────┐ ↓ ↓ ↓ Service Event Effect │ │ │ ↓ ↓ ↓ Capability Extension Lifecycle │ ↓ Capability Seam │ ┌──────┼──────┬────────┬───────────┐ ↓ ↓ ↓ ↓ ↓ FS Shell Skill Subagent Workflow │ ↓ Provider │ ↓ Consumer / Tool │ ↓ Agent / Agent Loop │ ↓ Session / Observation │ ↓ Next Step如果继续压缩可以得到 DeepSeek Harness 当前最核心的一条链Profile ↓ Bundle Stack ↓ Patch Layers ↓ Plugin Tree ↓ Cordis Context ↓ Services / Events / Effects ↓ Capability Seams ↓ Agent Runtime ↓ Agent Loop结语DeepSeek 开源的可能不只是另一个 Coding Agent如果只从产品使用角度看DeepSeek Harness当然可以被理解为一个新的 AI Coding Harness。但从 Agent Engineering 的角度它更值得研究的问题其实是一个 Agent Harness 到底应该拥有多大的固定 CoreClaude Code、Codex 让我们重点看到的是如何给 Harness 增加能力。DeepSeek Harness 则把问题进一步推进到Harness 本身能不能也是一种可组合对象于是Model Tool Skill Subagent Workflow Session Agent Loop Sandbox不再只是Harness 内部的固定组件而越来越像Runtime Composition 中可以选择、提供、替换的服务。这也是Everything is a Plugin真正值得关注的地方。它并不只是一个 Plugin API。它背后真正体现的是一种Composable Agent Runtime架构。而要真正理解这套架构下一步就必须继续往下进入它的底层DeepSeek Harness深入 CordisEverything is a Plugin 到底是怎么实现的下一篇我们将重点拆解Context ↓ Service ↓ Plugin ↓ Effect ↓ Event ↓ Inject ↓ Isolate ↓ Plugin Lifecycle ↓ Plugin Tree真正从源码和运行机制层面回答一个 Plugin 是如何进入 Cordis 的 Service 是如何注册和发现的 Plugin 为什么能够卸载 Event 为什么能够改写 Runtime Plugin 之间如何形成依赖 最终又是怎样一步步组成 Agent Harness 的到了那里DeepSeek Harness 的Everything is a Plugin才算真正被拆开。