github

DeepSeek Harness开源解析：MIT许可证下的插件化AI Agent框架

📅 2026/8/19 👁️ 1 阅读 ✏️ 2026/8/19 更新

DeepSeek Harness开源解析：MIT许可证下的插件化AI Agent框架

2026年8月的开源社区几乎被一个公式点燃：Agent = Model + Harness。DeepSeek在8月13日同一天打出两记重拳——旗舰模型DeepSeek-V4-Pro正式GA（General Availability）发布，以及以MIT协议完全开源的Agent框架DeepSeek Harness（简称 dsh）v0.1开发者预览版。后者把过去封在闭源产品（如Claude Code）里、看不见也改不了的那一圈"代理外壳"单独拎了出来，开源到GitHub上，迅速冲上Hacker News TOP 1，Star数飙升至近4万。

本文将以工程视角解析Harness的插件化架构与设计哲学，并连带梳理同期值得关注的底层基础设施更新——Linux内核7.2与GitHub Stacked Pull Requests，因为这三件事恰好共同回答了一个问题：当AI Agent成为开发主力时，开源基础设施该如何重新自我组织。

一、为什么需要一个"Harness"层

过去两年，LLM能力以肉眼可见的速度逼近甚至超越人类工程师的单点编码能力，但"模型强≠Agent能用"。一个真正能在真实环境里持续工作的Agent，需要理解环境、调用工具、保持长程上下文、在出错时自我纠正，并遵守安全边界。这些"非模型"的部分，行业里称之为Harness（代理外壳/驾驭层）。

问题在于，绝大多数Agent能力被硬编码在核心循环里：

  • 想换一个模型提供商，要fork框架、改一堆调用代码；

  • 想换沙箱策略，要从工具执行到结果回写重写一遍；

  • 会话状态管理粗放，难以可靠地回放、分叉、压缩；

  • 工具执行缺乏统一安全管道，审批流程各自为政；

  • 多代理协作、工作流编排要从零搭。

    • DeepSeek Harness的切入点很直接：用"一切皆插件"的架构原则，把每一个能力拆成可独立替换的插件单元，同时给出完整的工具执行管道、会话事件日志和分级沙箱策略。换句话说，它把Harness本身变成了一个可组装的操作系统。

    二、Harness v0.1：一切皆插件的运行时

    2.1 项目定位与发布背景

    DeepSeek Harness是DeepSeek AI开发的开源智能体运行框架，仓库位于 github.com/deepseek-ai/deepseek-harness，采用MIT许可证开源，当前处于Developer Preview阶段（明确声明会有破坏性变更，且暂不接受外部PR）。它的定位很清晰：不是又一个编码助手，而是一个可组装、可替换、可扩展的智能体基础设施。

    一句话总结其设计理念：模型是Agent的灵魂，Harness让Agent能在真实环境里持续工作。

    快速上手的门槛极低，无需克隆源码即可启动Web UI：

    bash
    # 安装 Node.js 22+ 后直接运行，无需克隆源码
npx @deepseek-ai/dsh web
# 默认地址 http://127.0.0.1:3080
# 首次启动后在 Settings → Models 中配置 DeepSeek API Key

    从源码构建则更接近开发者的日常：

    bash
    git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
corepack enable
pnpm install            # postinstall 自动配置 Lefthook Git hooks
pnpm run build          # tsc 类型检查 → tsdown 打包 → Web 前端构建
pnpm dsh web            # 启动 Web UI

    2.2 Cordis内核：插件化架构的根基

    Harness的底层依赖一个名为Cordis的依赖注入插件框架（github.com/cordiverse/cordis），其设计理念可见论文《A Programming Paradigm for Spatiotemporal Composability》。Cordis内核负责插件的挂载、卸载与依赖管理，而Agent的所有能力都住在插件里。

    这里有几个值得注意的工程取舍：

  • Registration as Effect：所有注册（工具、提示段落、适配器、监听器）都是可逆副作用。插件卸载时自动回滚注册内容，保证运行时状态干净。这意味着你可以热插拔能力而不留下"幽灵状态"。

  • Typed Events：通过TypeScript声明合并定义类型化事件，支持 emit（观察型广播）、waterfall（环绕中间件，可拦截/包装）、parallel（并行通知）、serial（串行有序有返回值）四种分发模式。事件契约即文档。

  • Capability Seam：每个能力由三角色构成——Service Definition（接口声明）、Provider（实现）、Consumer（消费方）。替换一个Provider即可改变整条能力链。

  • Model-Visible ⟺ Logged：任何到达模型请求的内容都必须可从会话日志重建，这是运行时强制的不变量，是可回放、可审计的前提。

    • 2.3 八层架构解析

    Harness把Agent运行时拆成八层，每一层都可独立替换。理解这八层，就理解了它的可组合性从何而来。

    | 层级 | 能力 | 核心服务 | 可替换要点 |
    |---|---|---|---|
    | 推理层 | 模型调用 | ctx.llm | 接入不同模型提供商，支持thinking与reasoningEffort调节 |
    | 工具注册表 | 工具注册与执行 | ctx.tools | 执行管道可被插件拦截增强 |
    | 会话状态 | 事件日志 | ctx.sessions | JSONL追加写入，支持zstd压缩、分叉、回放 |
    | 代理控制循环 | Turn/Step驱动 | ctx.agentLoop | 可替换驱动器，支持pre-step拦截与终止检查 |
    | 执行沙箱 | 文件/Shell/进程隔离 | ctx.fs ctx.shell ctx.sandbox | 分级策略：workspace-write / read-only / danger-full-access |
    | 系统提示组装 | 提示段落与工具Schema | ctx.systemPrompt | 插件可注册提示段落贡献者 |
    | 子代理委托 | spawn/fork | ctx.subagent | spawn不继承上下文，fork继承历史 |
    | Web界面与协议 | UI/Headless/ACP | dsh-web-app dsh-headless dsh-acp-demo | 三种运行模式覆盖人机交互到自动化 |

    一个完整的Agent循环是这样跑的：用户输入进入inbox队列 → turn/start → 声明待处理输入 → agent/pre-step（waterfall，可拒绝或改写）→ step/start → 组装系统提示和工具schema → agent/request → llm/stream（模型流式响应）→ assistant/chunk → assistant/message → tool/call → 工具执行管道 → tool/result* → step/end → 判断是否需要下一步 → turn/end。全程事件写入JSONL日志，可回放、分叉、压缩。

    2.4 多模型适配与运行时模式

    Harness内置DeepSeek模型适配器（支持 deepseek-v4-pro 与 deepseek-v4-flash），同时支持OpenAI兼容端点扩展，可接入Anthropic、OpenAI、Bedrock、Vertex、Azure及任意自定义OpenAI兼容端点，并支持多模型路由配置。这意味着你不必被绑定在单一供应商上。

    它还提供四种运行时模式，分别对应不同的使用姿态：

    | 模式 | 适用场景 | 能力范围 |
    |---|---|---|
    | Standard | 全功能编码Agent | 文件编辑、shell、文件与Web搜索、技能、规划、目标、子代理、工作流 |
    | Code | 让模型用代码编排多步操作 | Standard全部能力 + Code Mode SDK |
    | Minimal | 基准评测模型 | 仅持久化bash + str_replace_editor两个工具 |
    | Creator | 创建自定义Agent预设 | Standard全部能力 + 运行时检查 + 插件实验 + 预设编写 |

    Minimal模式对研究者尤其有价值：它把环境干扰降到最低，便于在不同模型间做公平的基准对比。

    2.5 同步发布的DeepSeek-V4-Pro

    同一天GA发布的DeepSeek-V4-Pro原生支持OpenAI Responses API格式，并引入三个思考强度（reasoning effort）级别，让开发者可以在"快"与"深"之间按场景权衡。在几个主流Agent基准上，V4-Pro相对此前版本取得了显著提升：

    | 基准 | 提升幅度 | 含义 |
    |---|---|---|
    | DeepSWE | +49.9 分 | 软件工程任务大幅跃升 |
    | Cybergym | +30.6 分 | 安全/网络任务显著改善 |
    | Toolathlon-Verified | +18.2 分 | 工具调用编排能力增强 |

    值得注意的是RC.8版本还增强了多模态能力。结合Harness的开源，DeepSeek实际上是在搭建一条"模型+框架"的完整开源路径——这与Claude Code那种"强模型+闭源外壳"的路线形成了鲜明对照。

    2.6 Harness插件定义实战

    要理解"一切皆插件"，最直接的方式是看一个插件长什么样。以下是一个示意性的工具插件定义，展示如何用Cordis的服务注入、事件挂载和可逆注册，把一个自定义工具接入Harness：

    typescript
    // my-grep-tool.ts —— 一个示意性的 Cordis 插件：向 Harness 注册 grep 工具
import { definePlugin, type Context } from '@cordisjs/core';

export default definePlugin((ctx: Context) => {
  // 1. 声明依赖：注入工具注册表服务
  //    ctx.tools 由 dsh-tool-registry 插件提供，此处是 Consumer 角色
  const tools = ctx.inject('tools');

  // 2. 注册工具：这是一个"可逆副作用"
  //    插件卸载时，Harness 会自动回滚这次注册，保证运行时干净
  tools.register({
    name: 'grep_workspace',
    description: '在工作区内按正则搜索文件内容',
    mode: 'barrier',          // 执行模式：并行 / 屏障
    ui: 'terminal',           // UI 渲染意图：generic / terminal / diff
    inputSchema: {
      type: 'object',
      properties: {
        pattern: { type: 'string', description: 'PCRE 正则表达式' },
        glob: { type: 'string', description: '文件名 glob，默认 **/*' },
      },
      required: ['pattern'],
    },
  });

  // 3. 订阅工具执行事件：waterfall 模式可拦截/包装
  ctx.on('tools/execute', async (event, next) => {
    if (event.tool.name !== 'grep_workspace') {
      return next();          // 不是本工具，放行给下一个监听者
    }
    const { pattern, glob = '**/*' } = event.input;
    // 走沙箱守卫：workspace-write 策略只允许读 + 临时区写
    const shell = ctx.inject('shell');
    const { stdout } = await shell.run(`rg -n '${pattern}' ${glob}`);
    // 4. 规范化结果并返回（不可变结果通知会触发 tools/result）
    return { ok: true, output: stdout, ui: 'terminal' };
  });

  // 5. （可选）贡献一段系统提示，告诉模型这个工具的存在与用法
  const prompt = ctx.inject('systemPrompt');
  prompt.contribute({
    id: 'grep-tool-hint',
    section: 'tools',
    text: 'Use grep_workspace to search file contents with regex.',
  });
});

    这段代码体现了Harness的几条核心约束：服务通过 inject 声明依赖、注册是可逆副作用、事件以类型化契约分发、模型可见内容必须可被日志重建。开发者无需改动Harness源码，只需在配置（Profile）里挂载这个插件即可启用——这正是"Compose with configuration"的含义。

    小贴士：你可以用 pnpm dsh --profile web --dump-config 查看当前Profile实际加载的插件树与配置，调试时非常有用。

    2.7 与同类框架对比

    把Harness放到行业坐标里看，差异会更清晰。下表对比了几个常见方案在架构、可替换性与安全策略上的取舍：

    | 对比维度 | DeepSeek Harness | LangChain | AutoGPT | Claude Code |
    |---|---|---|---|---|
    | 架构模式 | 全插件架构，无特权核心 | 链式调用，模块化 | 单体应用 | 封闭产品 |
    | 能力替换 | 配置文件替换，零代码修改 | 需编写适配代码 | 修改源码 | 不支持 |
    | 会话模型 | 追加写入事件日志，可回放分叉 | 内存状态为主 | 简单持久化 | 封闭 |
    | 安全策略 | 结构化沙箱管道，分级审批 | 无内置安全策略 | 无 | 内置但封闭 |
    | 插件开发 | Cordis标准化插件协议 | 自由格式 | 无标准 | 不支持 |
    | 子代理 | spawn/fork双模式 | 需自行实现 | 无 | 无 |
    | 开源协议 | MIT | MIT | MIT | 闭源 |

    可以这样概括：LangChain胜在生态广度，AutoGPT胜在"开箱即用"的端到端体验，Claude Code胜在产品打磨与模型质量，而Harness押注的是"可组合性"——它要把Agent基础设施本身做成像Linux发行版那样可拼装的东西。

    三、Linux内核7.2：底层基础设施的持续进化

    AI Agent跑得再快，脚下踩的还是操作系统。2026年8月17日发布的Linux内核7.2在调度、文件系统、网络、虚拟化与安全上都有实打实的进展。对Agent框架而言，这些更新意味着更可预测的调度、更大的IO吞吐与更细粒度的安全边界。

    3.1 缓存感知负载均衡调度器

    经过一年多持续开发与优化，缓存感知（cache-aware）负载均衡调度器在7.2合入稳定分支。它不再是把任务随便扔到一个空闲核上，而是优先把任务调度回它上次运行的、L1/L2缓存仍"热"的核上，减少跨核迁移带来的缓存失效与内存带宽浪费。对高频上下文切换的服务器负载（也正是承载Agent工具执行、模型推理调度的典型场景）收益明显。

    3.2 文件系统：Btrfs大folios与XFS zoned

    文件系统是Agent读写工作区、落盘会话日志的物理基础。

  • Btrfs：默认启用大型folios（large folios），并提供最大2MB的实验性选项。更大的folio意味着元数据与页缓存管理开销下降，对大量小文件与日志追加写入（Harness的JSONL会话日志正是追加写入）尤其友好。

  • XFS：zoned-storage支持不再实验性，正式进入主线。zoned设备（如SMR硬盘、新型NVMe）写入需按区管理，XFS的原生支持为大规模存储后端铺路。

    • 3.3 网络与虚拟化增强


  • Multipath TCP（MPTCP）：支持最多64条子流（此前为8条）。对需要多路径聚合带宽、提升可靠性的长连接Agent编排链路是利好。

  • KVM：新增Intel MBEC（Memory-Based Error Correction相关）与AMD Guest-Mode Execution Trap支持，强化虚拟化隔离与异常处理能力。

    • 3.4 安全、SBOM与Rust


  • Landlock：扩展到可限制UDP套接字，让未授信程序的网络访问边界更细。

  • SPDX SBOM：新增 make sbom 目标，可在构建时生成符合SPDX标准的软件物料清单——对供应链安全与合规审计越来越重要。

  • Rust内核代码：支持IBM s390架构，Rust在内核中的版图继续扩张。

    • 3.5 关键特性一览

    下表汇总7.2中与Agent基础设施最相关的几项特性：

    | 特性 | 类别 | 状态/变化 | 对Agent基础设施的意义 |
    |---|---|---|---|
    | 缓存感知负载均衡 | 调度 | 合入稳定 | 高频上下文切换更可预测 |
    | Btrfs大型folios | 文件系统 | 默认启用（2MB实验性） | 日志追加写入与小文件更高效 |
    | XFS zoned-storage | 文件系统 | 转正（非实验性） | 大规模存储后端更稳 |
    | MPTCP 64子流 | 网络 | 上限提升 | 长连接带宽与可靠性增强 |
    | KVM MBEC / GMET | 虚拟化 | 新增支持 | 隔离与异常处理更强 |
    | Landlock UDP限制 | 安全 | 扩展 | 细粒度网络边界 |
    | make sbom | 供应链 | 新增目标 | 生成SPDX SBOM，便于审计 |
    | Rust on s390 | 语言 | 架构扩展 | Rust内核版图扩张 |

    可以本地配置开启部分实验性选项示意（具体选项名以内核版本实际为准）：

    bash
    # 以下为示意配置，实际选项名以内核 Documentation 为准
make menuconfig

# 调度器：启用缓存感知负载均衡
#   General setup -> Scheduler features -> Cache-aware load balancing

# Btrfs：启用大型 folios（默认已开），2MB 为实验性
#   File systems -> Btrfs -> Large folios (2MB experimental)

# XFS：zoned storage 已转正，按设备类型自动启用
#   File systems -> XFS -> Zoned device support

# MPTCP：子流上限提升为 64（路径示意）
#   Networking -> TCP -> Multipath TCP -> max subflows

# 生成 SPDX SBOM
make sbom

    四、GitHub Stacked Pull Requests：为AI辅助开发而生

    Harness解决的是"Agent如何跑"，GitHub Stacked Pull Requests（堆叠式PR）解决的则是"Agent产出如何被审查"。2026年8月18日进入公开预览的这项能力，原生支持把一个大型变更拆成顺序依赖的PR链，恰好回应了AI辅助开发最尖锐的矛盾。

    4.1 问题背景：代码生成快但审查慢

    Gartner预测AI编码Agent将在2028年前为SDLC每个阶段带来50%的生产力提升。但生产力的瓶颈已经从"写得快"转移到了"审得过来吗"。一个典型的AI生成PR常常是1000+行、把数据模型、API、客户端接线、UI全部塞进一个diff里——评审者看到1721行变更往往会直接推迟审查，反馈质量下降，合并变慢，最终under-reviewed地合入。

    4.2 工作原理：分层与依赖链

    堆叠式PR的原则很朴素：分解。把一个大PR按逻辑层拆开，每层只做一件事，并标注它依赖哪一层。以"为购物助手添加商品搜索"为例，可拆成4层：

    | Stack层/分支 | 交付内容 | 依赖 |
    |---|---|---|
    | L1 (feat/catalog-data) | 带类型的目录+种子数据+校验+数据访问模块 | main（stack base） |
    | L2 (feat/search-api) | 带校验的 /api/products/search 端点 | feat/catalog-data |
    | L3 (feat/chat-grounding) | 聊天调用API并基于真实商品数据回答 | feat/search-api |
    | L4 (feat/grounded-ui) | 商品引用卡片 + 状态 | feat/chat-grounding |

    关键约束是：如果某层代码依赖另一层，依赖必须位于同一分支或更低的分支。每层PR只显示自己这一层的diff与"相对下一层分支"的增量，评审者一次只需hold住一个小而聚焦的变更。它还保留了现有的分支保护规则、审查流程与合并策略——每个PR按其最终目标分支（如main）评估规则与保护，可以单独或经由merge queue合并，只要下方的PR先合（或同时合）。

    4.3 CLI实战

    GitHub提供了 gh stack 扩展来自动化繁琐的分支管理、rebase、设置PR base与层间导航：

    bash
    # 安装堆叠 PR CLI 扩展（需 GitHub CLI v2.0+）
gh extension install github/gh-stack

# 教你的 AI 编码 Agent 懂得如何操作堆叠 PR
gh skill install github/gh-stack
# 或
npx skills add github/gh-stack

# —— 典型工作流 ——
gh stack init          # 初始化一个 stack，设置 stack base
gh stack add           # 在当前层之上叠加新层
gh stack push          # 推送本地堆叠分支到远端
gh stack submit        # 在 GitHub 上创建并串联各层 PR
gh stack rebase        # 本地级联 rebase（用自己的 git 配置，提交可签名）
gh stack sync          # 一键 fetch + 级联 rebase + push + 同步 PR 状态

    这里有个工程细节值得强调：GitHub网页上的"Rebase stack"按钮虽然方便，但它跑在GitHub服务器上，会把committer改成点击者、结果提交不带签名；如果你的分支保护要求签名提交，网页rebase会悄悄破坏签名。更稳妥的做法是用 gh stack rebase 在本地用自己的git配置完成级联rebase，再 gh stack push。

    4.4 审查流程：自上而下读，自下而上审

    审查堆叠PR的诀窍藏在一个方向性约定里：

  • 自上而下读（获取上下文与目标全貌）：先看栈顶PR，明白最终要达成什么，再往下读各层如何一步步搭起来。

  • 自下而上审（逐层构建理解）：从最底层PR开始审，因为每一层只有在上一层被理解后才说得通。

    • 这样，一个1721行、让人望而生畏的巨型PR，被拆成了多个自包含的小目标。Copilot Code Review可以在每层自动跑、自动抓问题；人类评审者按层分段、按负责人分派——数据层给数据owner，UI层给UI owner。这种工作流其实在Meta内部早已使用类似形式，GitHub这次是把它产品化、原生化了。

    五、其他开源动态速览

    除了上述三大主角，2026年8月的开源生态还有几条值得记录的线索。

    5.1 COSMIC Desktop 1.6

    由System76主导、用Rust编写的桌面环境COSMIC Desktop发布1.6版本。它从底层用内存安全语言重写桌面基础设施，是近年来少有的"从零造桌面"的大型开源项目之一，对Linux桌面生态的长期健康有标杆意义。

    5.2 Firefox 154

    Firefox 154发布，引入WebSocket本地网络保护与AI控制相关特性。前者收紧了本地网络上WebSocket的暴露面，后者则为浏览器与AI能力的交互提供了更可控的边界——这与Landlock收紧UDP、Harness收紧沙箱审批，方向一致：能力越开放，边界越要清楚。

    5.3 Tokenomics Foundation

    由Linux Foundation发起的Tokenomics Foundation，瞄准的是"AI经济"的可计量与可结算基础设施。当Agent可以自主调用工具、消耗token、甚至自主完成任务编排时，token的计量、定价与审计将成为新的公共议题，需要一个中立基金会来托管标准。

    5.4 FINOS Fluxnova 3.0与FDC3 3.0

    金融开源社区FINOS发布Fluxnova 3.0和FDC3 3.0，并引入MCP（Model Context Protocol）集成。这标志着Agent协议正在向金融这种强监管、强互操作行业渗透——FDC3作为金融应用互操作标准，接入MCP意味着Agent可以作为一等公民进入交易、风控、合规流程，而不再只是外挂助手。

    六、生态启示：开源正在重新定义AI基础设施

    把这几件事并排放在一起，会发现一条清晰的暗线：开源社区正从三个层面重新组织AI时代的基础设施。

  • 应用层（Harness）：把Agent外壳从闭源产品里解放出来，变成可组装的插件运行时。它的价值不在"又一个Agent"，而在"让任何人都能组装自己的Agent"。

  • 内核层（Linux 7.2）：持续打磨调度、文件系统、网络、虚拟化与安全，让Agent跑得更稳、更安全、更可审计。make sbom这种看似不起眼的目标，实则是把供应链安全下沉到内核构建流程里。

  • 协作层（Stacked PRs）：承认AI让"写"变快了，于是把"审"也重塑成可堆叠、可分派、可级联同步的新形态。这不是工具更新，而是工作流范式更新。

    • 更深一层，这三件事共享同一种审美：把大而封闭的整体，拆成小而可替换的单元，再用清晰的契约把它们组合起来。 Harness用Cordis拆Agent能力，Linux用模块拆内核能力，Stacked PRs把巨型diff拆成有序层。甚至FINOS把MCP引入FDC3、Linux Foundation发起Tokenomics Foundation，都是在做同一件事——为Agent时代的互操作、计量与治理建立中立标准。

    对工程师而言，几个实践建议值得记下：

  • 如果你在构建Agent平台：认真研究Harness的Capability Seam三角色与可逆注册，它给出的可组合性范式比"再写一个Agent框架"更有长期价值；但也要清醒它在Developer Preview、暂不接受外部PR、基于Node.js 22+/TypeScript 6技术栈，不适合需要生产级稳定性的场景。

  • 如果你在调优承载Agent的服务器：升级到Linux 7.2，开启缓存感知调度与Btrfs大folios，会话日志追加写入会受益；同时用 make sbom 把供应链审计纳入常规流程。

  • 如果你在管理AI生成代码的评审：把Stacked PRs纳入团队的Agent工作流，给Agent装上 gh-stack skill，让它学会"分解再提交"而非"一锅端"；记住自上而下读、自下而上审的方向性约定。

  • 如果你关心生态标准：留意MCP在金融等强监管行业的落地（FDC3 3.0）以及Tokenomics Foundation的token计量标准——这些将决定Agent能否作为一等公民进入真实业务流。

    • 开源的迷人之处在于：当闭源产品把能力封进黑盒时，总有人把它拆成可组合的零件再放回桌面。DeepSeek Harness、Linux 7.2与GitHub Stacked PRs在2026年8月这一周的同框，正是这种精神的又一次集中显影——AI Agent要成为可靠的基础设施，前提是它脚下的每一层都是开放、可替换、可审计的。而这，从来都是开源最擅长的事。

    本文基于DeepSeek官方Harness站点与开发者文档、Linux内核社区发布说明、GitHub工程博客及公开报道整理分析而成。Harness当前为Developer Preview，API会有破坏性变更，请在生产环境采用前评估风险。

    💬 评论区 (0)

    0/500

    暂无评论，快来抢沙发吧！