DeepSeek Harness 两天冲上 10 万 Stars：AI Agent 的真正前沿，已经从模型转向基础设施

🚀 两天 10 万 Stars，真正值得问的不是“为什么这么火”

DeepSeek Harness 在极短时间内突破了 10 万 GitHub Stars。

原文记录的数字是：项目越过 112,000 Stars 和 10,000 Forks，在最初约 53 小时里，平均每小时增加超过 2,100 个 Stars。作为对比，OpenClaw 用了大约一周达到 10 万 Stars，之后增长到约 38.6 万。

这些数字是原作者在文章发布时记录的时间截面，不应被直接理解为今天的实时数据，也不等于生产环境中的活跃用户数量。GitHub Star 更像关注、收藏和试用意愿的综合信号，而不是营收、留存或企业部署数据。

但这个速度仍然提出了一个更有价值的问题：

为什么一个 Agent harness，突然值得十万名开发者在第一时间关注？

答案可能不是“DeepSeek 又发布了一个更强模型”，而是它押注了 Agent 真正难做的那一层：

• 如何选择上下文；
• 如何暴露工具；
• 如何持久化状态；
• 如何从失败中恢复；
• 如何执行权限控制；
• 如何验证 Agent 是否真的完成了任务。

DeepSeek Harness 给出的架构回答非常明确：一切都是插件。

模型适配器、工具注册表、会话日志和 Agent Loop 是插件；文件系统、子进程执行、沙箱、审批、遥测、提示词、UI 行为和持久化，也都作为可替换能力暴露出来。

🧩 DeepSeek Harness 到底是什么？

DeepSeek Harness，简称 dsh，是一个用于构建和运行 AI Agent 的开源 runtime。

它主要使用 TypeScript 编写，构建在 Cordis 之上。原文将 Cordis 描述为一个面向“时空可组合性”的元框架。换成工程语言，可以把它理解为：一个运行中的 Harness 实例，不是由一大块不可拆分的核心代码组成，而是由多个插件向共享上下文中贡献能力。

这些能力包括：

• 服务；
• 类型化事件；
• 可逆效果；
• 模型适配器；
• 工具；
• 会话行为；
• Agent Loop；
• 文件系统和子进程提供者；
• 沙箱和审批策略；
• UI 集成。

这背后的问题意识是：一个 LLM 本身只是“生成下一步动作”的模型。真正让它成为可以工作的 Agent，还需要一个运行时负责提供上下文、工具、状态、权限和反馈。

换句话说，模型回答“下一步应该做什么”，Harness 负责回答：

• 它能看到什么？
• 它能调用什么？
• 它可以改动什么？
• 改动是否需要审批？
• 失败之后从哪里恢复？
• 这次执行能否重放和审计？

🧱 为什么“把所有东西写进 agent.ts”迟早会失控

很多团队的第一个 Agent 都长这样：

构造提示词
 → 调用模型
 → 解析工具调用
 → 执行命令
 → 把结果追加回上下文
 → 重复循环

对原型而言，这完全够用。问题在于，生产需求很快就会增加：

• 远程沙箱；
• 不同租户使用不同工具集；
• 同时兼容 OpenAI 和 Anthropic 风格接口；
• 会话重放；
• 后台任务抽象；
• 结构化遥测；
• 可恢复的 Shell；
• 文件系统权限策略；
• 审批节点；
• 长时间任务的断点续跑。

最终，Agent Loop 可能膨胀成五千行框架代码，每增加一个功能就要修改它。

这会造成三个问题：

1. 能力和循环耦合：换一个工具，需要动 Agent Loop；
2. 安全和功能耦合：加审批逻辑，需要侵入执行逻辑；
3. 部署和业务耦合：本地 Agent、企业 Agent、CI Agent 各自分叉。

DeepSeek Harness 的做法是从一开始就把 runtime 当成一个组合问题，而不是一个等待不断打补丁的“超级核心”。

🧰 Profile、Bundle：同一套 runtime，组合出不同部署形态

DeepSeek Harness 引入了两个重要的配置概念：Profile 和 Bundle。

内置的 web profile 提供浏览器应用；headless profile 则提供不启动 Web 服务器的一次性 Agent runner。

启动时，配置按层叠方式组合：

bundle 1
bundle 2
...
profile cordis.patch.yml
$DSH_HOME/cordis.patch.yml
--patch overlay

这意味着，与其维护多个独立分支：

agent-local
agent-enterprise
agent-ci
agent-customer-a
agent-customer-b

不如维护一组组合：

基础 runtime
+ 模型提供商
+ 沙箱提供商
+ 工具集
+ 权限策略
+ 客户专属 patch

这更像我们构建可配置基础设施的方式，而不是为每个场景复制一份 Agent。

更关键的是，开发者可以检查最终真正会启动的配置树：

dsh --profile web --dump-config

动态组合系统最怕“源配置看起来没问题，但最终组合出来的 runtime 不知道是什么”。dump-config 解决的正是可观测性问题：开发者需要看到解析后的真实系统，而不只是零散的输入文件。

⚡ 一条命令启动，但真正的价值在启动之后

原文给出的快速路径很简单：安装 Node.js，然后运行：

npx @deepseek-ai/dsh web

Web UI 默认运行在：

http://127.0.0.1:3080

接下来可以在界面中：

1. 打开 Settings → Models；
2. 添加 DeepSeek API Key；
3. 选择一个 workspace；
4. 开始会话。

一个适合作为第一次测试的提示词是：

总结这个仓库，并找出它的主要 package。

Agent 可以读取和编辑文件、执行命令、委托工作并维护计划。需要审批的操作，会通过当前生效的权限策略呈现出来。

这里有一个重要的安全转折点：一旦模型能够修改文件或执行命令，授权就不再是某个工具的附属选项，而会成为 Agent 架构的一部分。

DeepSeek Harness 将策略和执行拆成不同能力，而不是把所有权限判断硬编码进一个巨大的工具函数。这种拆分让本地运行、远程运行和受限运行之间有机会共享同一套工具接口。

🖥️ Web UI 适合探索，Headless 才更接近生产入口

Web UI 适合第一次体验，但对平台工程师而言，headless profile 可能更重要。

如果你要构建以下系统：

• CI Agent；
• 后台代码 worker；
• 自动解决 issue 的机器人；
• 内部运维自动化；
• 定时运行的仓库分析任务；
• 多租户代码处理服务。

你通常不希望每次都启动一个浏览器界面。

原文给出的调用形式是：

pnpm dsh --profile headless "summarize this workspace"

或：

dsh --profile headless "job"
dsh web

此时 CLI 更像一个组合启动器，而不是一个掌握所有未来选项的巨型命令行程序。它加载选定的 profile，然后把参数交给对应的组合处理。

这也是“runtime”与“单一代码助手”的差异：启动器不需要理解所有工具和 UI 细节，能力属于被加载的运行时组合。

🧾 Agent Loop 不是一个 while 循环，而是一组可持久化事件

原文最值得技术人员注意的设计之一，是它区分了 turn 和 step。

• 一个 step：一次模型请求，以及这次请求触发的工具调用；
• 一个 turn：可以包含多个 step。

概念上的运行流程大致是：

turn/start
 → claim input
 → assemble prompt + tool schemas
 → agent/pre-step
 → step/start
      → model request
      → assistant chunks
      → assistant message
      → tool calls
      → guarded tool execution
      → tool results
 → step/end
 → maybe another step
turn/end

这些关键事件会写入 session log。

这里有一个非常重要的原则：

凡是会影响模型所见内容的东西，都应该可以从持久化状态中重建。

一次真实的 Agent 请求，不只是一个最终字符串。它可能由以下内容共同组成：

• 之前的对话；
• 注入的上下文；
• 工具 schema；
• 插件贡献的提示词片段；
• 模型配置；
• 工具结果；
• 继续执行所需的状态。

如果只记录最后发送给模型的文本，你可以重放“发了什么”，但不一定能解释“为什么会发这个”。

事件化 session 模型的价值在于，它为以下能力提供基础：

• replay：重放；
• debugging：调试；
• forking：分叉会话；
• resuming：断点续跑；
• transcripts：生成完整记录；
• telemetry：遥测；
• audits：审计；
• deterministic tests：确定性测试。

这些能力平时很无聊，但当 Agent 开始执行真实修改时，它们会迅速从“锦上添花”变成“能不能上线”的基础条件。

🔌 工具是插件，插件也必须有生命周期

原文用一个非常小的 TypeScript 插件说明了扩展方式：

import type { Context } from '@deepseek-ai/cordis'

export const name = 'hello-plugin'

export function apply(ctx: Context) {
  console.log('[hello-plugin] plugin loaded!')
}

挂载时，可以通过 overlay 插入：

- insert:
  - id: hello
    name: '/absolute/path/to/deepseek-harness/scratch-plugin/src/my-plugin.ts'

然后运行：

pnpm dsh web --patch ./scratch-plugin/cordis.yml

工具插件的例子则是注册一个 greet 工具，让模型可以调用它并看到 Hello, Ada!。

看起来只是几行代码，但其中隐藏了几个重要工程决策：

1. 依赖显式声明

插件声明：

export const inject = ['tools']

Cordis 会等待依赖的服务存在之后再加载插件，避免插件在运行时“猜”自己需要什么。

2. 数据值和模型展示分离

工具有标准化的输出值，同时有一个专门面向模型的 renderer。工具内部真正返回什么，与模型在上下文中看到什么，不必强行绑定为同一种格式。

3. 注册具有生命周期意识

插件卸载时，通过上下文注册的内容会自动移除。对于需要显式清理的资源，插件还可以注册可逆效果：

ctx.effect(() => {
  const timer = setInterval(() => {
    console.log('heartbeat')
  }, 5000)

  return () => clearInterval(timer)
})

这在热重载、租户专属工具、动态模型路由和临时 Agent 能力中很重要。插件系统如果没有生命周期管理，最终很容易变成内存泄漏和状态污染生成器。

⚙️ 配置错误应该在组合时失败，而不是运行 40 分钟后失败

任何可能被不同部署设置成不同值的东西，都应该是配置项。

插件可以导出类型化配置 schema，例如：

export interface Config {
  greeting: string
  maxRetries: number
  verbose?: boolean
}

部署时可以覆盖：

config:
  greeting: 'Hi there'
  maxRetries: 5

如果配置非法，应该在插件加载时失败，而不是让一个 Agent 先运行 40 分钟，最后才发现超时参数错误、凭证缺失或工具策略格式不对。

这是一条很朴素但很重要的生产原则：

能在系统组合阶段验证的错误，不要拖到任务执行阶段才暴露。

🧱 Capability Seam：让工具不必知道底层执行环境

DeepSeek Harness 把可替换能力分成三个角色：

1. Service Definition：服务接口；
2. Service Provider：具体实现；
3. Consumer：使用该服务的组件。

例如，文件系统访问不一定意味着“Node.js 直接读取本地磁盘”。

• 本地 provider 可以暴露宿主机文件；
• 远程 provider 可以暴露隔离环境内的文件；
• 工具只消费 filesystem capability，而不需要知道底层实现在哪里。

同样的模式可以应用到子进程和沙箱。文件系统和子进程 provider 可以共享一个执行世界。

于是，当你把执行 provider 从本地替换成远程沙箱时，Bash、持久终端、编辑器操作和语言服务器交互，都有机会跟着迁移，而不必分别维护：

local-bash
 docker-bash
 remote-bash

local-editor
 docker-editor
 remote-editor

更理想的结构是：

bash     → subprocess capability
editor   → filesystem capability
terminal → execution capability

然后为这些能力选择：

local provider
或
sandbox provider
或
remote provider

这实际上是 Agent 工程重新发现了接口隔离和依赖反转。听起来像老的软件工程原则，但在 Agent 时代，它们直接决定了系统能不能在本地、容器、远程沙箱和多租户环境之间迁移。

🐍 Python SDK：不只服务于 TypeScript 开发者

DeepSeek Harness 也提供 Python SDK。

原文给出的安装方式是：

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness

python -m venv .venv
. .venv/bin/activate

python -m pip install deepseek-harness-sdk

一个最小程序可以通过上下文管理器启动 Harness：

from pathlib import Path
from deepseek_harness import DeepSeekHarness

config = Path("examples/jsonrpc-agent/minimal.cordis.yml").resolve()
workspace = Path("/absolute/path/to/workspace").resolve()
sessions = Path("/absolute/path/to/sessions").resolve()

with DeepSeekHarness(
    provider="deepseek-official",
    model="deepseek-v4-flash",
    max_tokens=49_152,
    cwd=str(workspace),
    session_root=str(sessions),
    cordis=str(config),
) as harness:
    result = harness.run(
        "Inspect the repository and fix the failing tests.",
        session_id="example-001",
    )
    print(result.final_response)

这对已经用 Python 编排 ML 工作负载的平台团队尤其重要：他们不一定想改成 TypeScript，但可以把同一套 runtime 放进已有的 Python 服务中。

如果复用同一个 session_id，就可以继续同一段持久化会话，包括：

• 工作目录；
• 环境变量；
• 持久化 Bash 进程；
• Shell 函数；
• 之前的对话和执行状态。

如果需要隔离执行状态，就使用新的 session ID。

🔒 最不能跳过的安全警告：Workspace 不是安全边界

原文特别强调，Python 示例使用了非常宽松的 danger-full-access 组合。

在这种模式下，Bash 和编辑器可能修改 runtime 进程能够看到的任意路径。DeepSeek 明确建议只在一次性 checkout 或容器中运行。

这应该成为所有 Coding Agent 的默认安全认知：

如果模型可以执行 Shell 命令并编辑文件，那么“工作目录”本身就不是安全边界，除非操作系统或沙箱真的把它隔离开了。

面向严肃部署，至少需要纵深防御：

Agent policy
+ tool policy
+ filesystem boundary
+ subprocess isolation
+ OS/container sandbox
+ credential scoping
+ network policy
+ audit log

DeepSeek Harness 将这些安全关注点表达成可替换能力，而不是塞进一个巨大的 executeTool() 函数。

同时，第三方 Harness 插件也必须被当成高风险依赖：如果一个 npm 包可以在你的机器上执行命令，那么它和“能执行命令的 Agent 插件”本质上都需要同等级别的审查。

📈 Harness Engineering：模型之外的第二条性能曲线

这篇文章最核心的判断，是 2026 年的 Agent 研究正在把“模型能力”和“Harness 能力”逐渐分开。

原文引用了一项 Claw-SWE-Bench 比较：在受控条件下，更换模型让 Pass@1 改变了 29.4 个百分点，而更换 Harness 让 Pass@1 改变了 27.4 个百分点。

这个差距非常接近。

文章还引用了 Agentic Harness Engineering 的研究：通过自动改进工具、中间件、记忆等 runtime 组件，Terminal-Bench 2 的结果从 69.7% 提升到 77.0%。

这些数字必须带着 benchmark 条件来读：它们不是所有任务、所有模型和所有部署环境中的普遍保证，也不意味着 Harness 一定比模型更重要。更准确的结论是：在 Agent 任务中，模型只是完整系统的一部分。

运行时决定了：

• 模型拿到什么上下文；
• 系统提供哪些工具；
• 工具 schema 如何表达；
• 什么时候需要审批；
• 哪些内容被持久化；
• 失败如何恢复；
• 长任务如何继续；
• 执行环境如何隔离；
• 哪些事件被记录；
• 会话能否重放；
• 模型能否被替换。

到了这个阶段，Harness 就不再是模型外面的薄壳，而是整个 Agent 系统的一部分。

🧠 “模型 + Harness + 环境”才是 Agent 的真实能力

传统的模型评测倾向于问：这个模型在某个 benchmark 上得分多少？

但一个可以真正工作的 Coding Agent 还必须处理：

• 仓库上下文是否完整；
• 文件是否能正确读取；
• 工具调用是否可靠；
• 终端是否可持续；
• 错误是否会被反馈给模型；
• 权限是否会在危险操作前阻断；
• 会话是否能在进程重启后恢复；
• 最终修改是否经过测试和验证。

因此更完整的能力表达应该是：

Agent capability
= model
+ harness
+ tools
+ memory
+ execution environment
+ verification loop

同一个模型放进不同 Harness，可能表现出完全不同的任务完成率。一个有更好上下文选择、工具设计、持久化和验证闭环的旧模型，未必会输给一个被放在简陋脚本里的新模型。

这也改变了软件团队的竞争方式。未来的核心资产不一定只是“我接入了哪个最强模型”，还可能是：

• 我如何组织工具；
• 我如何设计运行时事件；
• 我如何把失败轨迹变成可学习数据；
• 我如何管理权限和风险；
• 我如何让任务可以暂停、恢复、审计；
• 我如何在模型变化时保留自己的系统能力。

⚠️ 这篇文章哪些地方需要保持谨慎？

第一，Stars 不是采用量

112,000 Stars 和 10,000 Forks 说明项目引发了强烈兴趣，但无法直接证明有多少企业在生产使用，有多少用户每天运行 Agent，也不能证明项目已经成熟。

第二，模型名和版本需要以官方仓库为准

PDF 是一篇 Medium 分析文章，不是 DeepSeek 官方文档。文章中的版本、命令、SDK 名称和模型名，在实际安装前应以官方仓库和发行说明为准。

第三，benchmark 不是普遍规律

29.4、27.4、69.7% 和 77.0% 都对应特定任务、模型、Harness、参数和实验设置。它们能支持“运行时影响很大”这个方向性判断，但不能直接变成“换 Harness 一定等于换模型”的宣传语。

第四，插件化也会增加复杂度

一切都是插件，意味着一切都可以替换，但也意味着：

• 依赖关系更多；
• 配置解析更复杂；
• 插件版本兼容更难；
• 运行时行为不容易从单个仓库文件看懂；
• 恶意或脆弱插件可能扩大攻击面；
• 调试需要更好的事件、配置和依赖可视化。

插件化不是自动获得的架构优势，只有配套的类型系统、生命周期、配置校验、审计和测试体系跟上时，它才会成为基础设施。

🛠️ 对开发团队的实际启示

如果你现在正在搭建 Agent 平台，可以从 DeepSeek Harness 的思路中提炼出几条可执行原则：

1. 先定义能力接口，再决定本地还是远程实现

不要让工具直接绑定本地磁盘、Docker 或某个云沙箱。先定义 filesystem、execution、subprocess、approval 等能力接口，再提供不同 provider。

2. 把 Agent 事件当成产品数据

记录的不只是最终回答，还包括上下文组装、工具 schema、工具调用、审批、结果和失败恢复路径。

3. 把危险权限从工具实现中分离

工具负责“能做什么”，策略负责“什么时候允许做”。这样才能针对不同用户、租户、环境和任务切换权限。

4. 默认把长期任务当成可恢复任务

如果任务可能运行十几分钟甚至数小时，就不要只依赖进程内存。需要 session log、状态持久化、断点恢复和审计记录。

5. 把验证闭环放在 Agent Loop 里

“模型说完成了”不等于任务完成。代码 Agent 至少需要测试、静态检查、文件差异、结果校验或人工审批中的一部分。

🧭 最后的判断：模型是发动机，Harness 是整辆车

DeepSeek Harness 的爆发式关注，未必只是一次开源项目营销成功。它更像是一个信号：开发者开始意识到，Agent 的下一个瓶颈可能不只是模型参数量和 benchmark 得分，而是模型周围那套经常被忽略的运行时基础设施。

一个真正可靠的 Agent，需要知道：

• 它看到了什么；
• 它可以调用什么；
• 它被允许修改什么；
• 它如何记录自己的行动；
• 它失败后如何回来；
• 它如何证明自己真的完成了任务。

这就是 Harness Engineering 的核心。

模型决定“能不能想出一个方向”，Harness 决定“这个方向能不能在真实环境中被安全、持续、可验证地执行”。

所以，DeepSeek Harness 最值得关注的地方，可能不是它今天能不能替代某个代码助手，而是它把一个更大的问题摆到了台面上：

未来的 Agent 竞争，究竟是在争夺更强的模型，还是在争夺更好的模型运行方式？

答案很可能是：两者都会重要，但真正能进入生产环境的系统，必须把模型、Harness、工具、记忆、执行环境和验证机制作为一个整体来设计。