Harness 全景解读：从 DeepSeek Harness 到主流 Agent 框架对比

一、为什么我们需要重新理解 “Harness”

去年我们团队用 GPT-4 搭了一个”自动写周报”的 agent。一开始效果惊艳——模型确实能读懂任务列表、能产出结构化文本。但生产环境跑了两周，问题接踵而至：上下文撑爆窗口、工具调用偶尔无限循环、子任务状态丢失、错误恢复完全靠人工。最终我们写的那坨胶水代码，比模型本身贵十倍。

这不是模型不够聪明，是我们缺一个 harness。

Harness（驾驭/挽具）：套在模型外面的工程控制平面。它不发明智能，它负责让智能可调度、可观察、可恢复、可组合。

Anthropic 在《Building Effective Agents》中给过一个被广泛引用的判断：好的 agent 系统 = 薄薄的推理内核 + 厚厚的工程控制面。前者是模型本身，后者就是 harness。今天这篇文章，我们就把这层”控制面”拆开看——从 DeepSeek 在 2026 年开源的 dsh 开始，对比 Claude Code、LangChain、AutoGPT、Cordis 五种主流 harness 的设计取舍。

---

二、DeepSeek Harness（dsh）——一切皆插件

DeepSeek Harness（命令行简称 dsh）是 DeepSeek AI 在 2026 年开源的 agent harness，目前仍处于开发者预览阶段。它的核心定位一句话：

一切皆插件（Everything is a plugin），由 Cordis 驱动。

2.1 设计哲学

它底层不是自己造一套容器，而是跑在 Cordis 之上——一个强调**时空可组合性（Spatiotemporal Composability）**的插件框架，对应论文 A Programming Paradigm for Spatiotemporal Composability。“时空”指：

• 空间：插件运行在哪个上下文（context）、能否跨进程/跨节点共享；
• 时间：插件何时启动、何时热插拔、生命周期如何管理。

这套范式给 DeepSeek Harness 带来三个直接好处：

1. 插件热加载：不改主进程就能增减能力；
2. 跨进程组合：插件既可同进程组合，也可拆到不同 worker；
3. 显式生命周期：每个能力（工具、模型适配器、UI 面板）都有 apply / dispose 两个钩子，启动/卸载行为可观察。

2.2 安装与启动

最快的方式——一行命令拉起 Web UI：

npx @deepseek-ai/dsh web
# 默认地址 http://127.0.0.1:3080

要从源码运行：

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

Web UI 默认监听 127.0.0.1:3080，详细用法见官方 Web UI 指南。

2.3 一个最小插件长什么样

按 Cordis 范式，DeepSeek Harness 的插件本质上是一个对象，包含 name、apply、dispose 三件套：

import { Context } from '@cordis/core'

export function greetPlugin(ctx: Context) {
  ctx.logger.info('greet plugin loaded')

  // 注册一个工具
  ctx.tool('greet', async (name: string) => {
    return `Hello, ${name}!`
  })

  // 注册一个 CLI 子命令
  ctx.command('hi [name]', 'say hi').action((name) => {
    console.log(`Hi, ${name ?? 'stranger'}`)
  })
}

把这段代码塞进 plugins/greet.ts，启动 dsh 时会自动被扫描加载——这就是”一切皆插件”的最朴素体现。

2.4 优劣

✅ 优势	⚠️ 代价
插件热加载、跨进程组合，扩展性极强	仍在开发者预览，未来会有破坏性变更
复用 Cordis 生态，无需重复造轮子	文档/示例偏少，学习曲线取决于 Cordis 熟悉度
显式生命周期，可观察性高	当前更适合实验/集成场景，生产化需自己兜底

适合谁：愿意自己搭骨架、需要把 agent 能力拆成大量可插拔模块的团队。

---

三、Claude Code —— 终端原生的”薄内核+厚工程”

如果说 dsh 是”框架级 harness”的代表，那 Claude Code 就是”产品级 harness”的天花板。它直接套在 Claude 系列模型外，提供终端、IDE、动态工作流等完整工程控制面。

3.1 核心架构：三层七图

Anthropic 在多篇工程博客里把它拆成三层：

• L1 入口与路由：main.tsx 解析参数、判定模式（交互/无头/远程），分派到不同入口；
• L2 会话编排：把交互请求、无头请求、远程请求统一抽象成”turn 契约”，整合工具、扩展、状态、持久化；
• L3 运行时支撑：本地运行时（完整 Agent Loop）或远程会话主机（remote/bridge/server）。

而贯穿三层的，是那个最小决策内核——Orchestration Loop（编排循环），在 src/query.ts 里实现：

1. Assemble Prompt：拼装完整上下文（系统提示 + 工具描述 + 历史 + 当前输入）；
2. Invoke Model：调用 Claude API；
3. Parse Output：解析模型返回的工具调用；
4. Execute Tools：执行工具；
5. Feed Back Results：把结果回灌给模型；
6. Continue Loop：直到模型给出无工具调用的最终回答。

这就是那句被反复引用的话：“One loop & Bash is all you need”。

3.2 围绕 Loop 的 12 项核心机制

Anthropic 把它拆成 12 个独立能力，我们挑对 harness 设计最有启发的 6 个：

机制	它解决的问题
Tools	把”能力”统一收到工具层，工具即边界
TodoWrite	让 AI 自己用笔——任务拆解比一次性回答更稳
Subagents	上下文隔离（不只是并行）
Skills	按需加载的领域知识，避免预加载撑爆上下文
Compact	不只是压缩，是上下文治理
Worktree	任务隔离是一等公民

3.3 一个能跑起来的”极简版 Claude Code”

把上面那个编排循环翻译成 ~50 行 TypeScript，就是 Claude Code 的骨架：

// 简化自 src/query.ts 的核心循环
async function agentLoop(model: Model, tools: Tool[], task: string) {
  const history: Message[] = [{ role: 'user', content: task }]

  while (true) {
    const reply = await model.invoke({
      messages: history,
      tools: tools.map(t => t.schema),
    })

    if (!reply.toolCalls?.length) {
      return reply.text              // 模型自己决定收尾
    }

    for (const call of reply.toolCalls) {
      const tool = tools.find(t => t.name === call.name)!
      const result = await tool.run(call.args)
      history.push({ role: 'tool', name: call.name, content: result })
    }
  }
}

真实代码里还要加 TodoWrite、Subagent、Skills、Compact、错误恢复、上下文截断——但**“控制面”的形状就是在这里搭起来的**。

3.4 优劣

✅ 优势	⚠️ 代价
终端原生，开发者体验极好	强绑定 Claude 模型，跨模型需要适配层
工程控制面最厚（TodoWrite/Skills/Worktree…）	闭源，想魔改只能 fork
子代理 + 动态工作流支持复杂任务	对小型自动化任务显得”杀鸡用牛刀”

适合谁：把 AI 当真”结对程序员”用的研发团队，特别是已经在 Claude 生态内的。

---

四、LangChain —— 模块化编排的”乐高式”harness

LangChain 是最早把”harness”概念产品化的框架，它不假定任何具体模型或工具链，而提供一套可组合的积木块：chains、agents、retrievers、memory、callbacks。

4.1 架构：ReAct 循环 + Tool Calling

LangChain 的 agent 核心是 ReAct 循环（Reason + Act）：

from langchain.agents import create_react_agent, AgentExecutor
from langchain_openai import ChatOpenAI
from langchain.tools import Tool

def get_weather(city: str) -> str:
    return f"{city}: 25°C, sunny"

tools = [Tool(name="get_weather", func=get_weather, description="查天气")]
llm = ChatOpenAI(model="gpt-4o")

agent = create_react_agent(llm, tools, prompt)
executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

print(executor.invoke({"input": "北京今天天气怎么样？"}))

引擎拿到用户输入 → 喂给 LLM → LLM 决定是否调工具 → 工具返回结果 → LLM 再决策 → 直到给出最终回答。这套循环和 Claude Code 本质上是同一个东西，但 LangChain 把每一步都抽象成了 Python 类，你可以随意换模型、换工具、换提示。

4.2 优劣

✅ 优势	⚠️ 代价
模型无关、组件解耦、灵活性极高	抽象层数多，2024–2025 经历过几次大重构（v0.1 → v0.3）
生态最大，retrievers/loaders/integrations 全	对初学者心智负担重，“LangChain 怎么写”是高频问题
既能写 chain 又能写 agent，又能混用	性能调优需要理解较深

适合谁：需要快速搭 RAG + 工具调用 + 多模型对比的工程团队。

---

五、AutoGPT —— 完全自主循环的早期范式

AutoGPT 是 2023 年让”agent”概念破圈的代表作。它的设计目标很激进：让 GPT 自己给自己定目标、自己拆任务、自己执行、自己评估。

5.1 核心循环

while not goal_achieved:
    think   = llm.plan(state, long_term_memory, short_term_memory)
    action  = llm.select_tool(think)
    result  = execute(action)
    reflect = llm.evaluate(result, goal)
    memory.update(result, reflect)

5.2 优劣

✅ 优势	⚠️ 代价
极致自主，演示效果震撼	极易陷入循环烧 token，单次任务花费惊人
短/长记忆分层是早期范式贡献	缺乏人为兜底时稳定性差
启发了一整代 agent 框架	现代生产环境很少直接用，更适合作为”参考实现”

适合谁：研究 LLM 自主性极限、做 agent benchmark 的团队。

---

六、Cordis —— 插件”时空可组合”的底层范式

DeepSeek Harness 没有自己造插件容器，而是直接采用 Cordis。它是 DeepSeek 团队开源的 TypeScript 框架，核心理念来自那篇论文：

把”空间”（上下文）和”时间”（生命周期）作为一等公民，让插件既能跨进程组合，又能热插拔。

6.1 插件的最简骨架

import { Context, Service } from '@cordis/core'

class GreetService extends Service {
  constructor(ctx: Context) {
    super(ctx, 'greet')
    this.ctx.logger.info('greet service ready')
  }

  hello(name: string) {
    return `Hello, ${name}!`
  }
}

export function greetPlugin(ctx: Context) {
  ctx.plugin(GreetService)
}

启动时 cordis.load(greetPlugin) 即可启用，关闭时自动调用 dispose。这套范式天然适合做 agent harness，因为：

• 每个工具就是一个独立 service；
• 每个生命周期钩子对应 harness 的 start/stop；
• 上下文隔离让多 agent / 多 session 不互相污染。

6.2 与传统插件框架对比

维度	Cordis	Koa/Midway 插件	OOP 抽象类
空间可组合	✅ 跨 context	❌ 同进程	❌ 单继承
时间可组合	✅ 热插拔	⚠️ 需重启	❌ 编译期
显式生命周期	✅ apply/dispose	⚠️ 隐式	⚠️ 构造/析构
学术支撑	✅ 有论文	❌	❌

---

七、五种 Harness 横向对比

维度	DeepSeek dsh	Claude Code	LangChain	AutoGPT	Cordis
定位	框架级 harness	产品级 harness	模块化编排库	自主 agent 参考实现	插件运行时底座
架构核心	一切皆插件 + Cordis	编排循环 + 12 机制	ReAct + 可组合链	完全自主循环	时空可组合插件
模型绑定	多模型（DeepSeek 优先）	强绑定 Claude	模型无关	多模型	与模型无关
扩展方式	写插件	工具/Subagent/Skills	换 chain/agent	改 prompt + 工具	写 service
学习曲线	中（依赖 Cordis）	低（终端即用）	高（抽象层多）	中	低（TypeScript 友好）
生产就绪度	开发者预览	✅ 高	✅ 高	⚠️ 演示级	✅ 高（基础设施层）
开源/闭源	MIT 开源	闭源	MIT 开源	MIT 开源	MIT 开源
适合场景	高度定制化集成	研发日常编码	RAG + 工具调用	自主性研究	自己搭 harness

---

八、选型决策树

你要拿来做什么？
│
├─ 日常写代码、改 bug、做重构
│   └─ ✅ Claude Code（开箱即用，控制面最厚）
│
├─ 给现有业务接 RAG / 工具调用，要快
│   └─ ✅ LangChain（生态最大、模型无关）
│
├─ 想自己造一套 agent 平台，要高度可定制
│   ├─ JS/TS 技术栈 → ✅ DeepSeek Harness (dsh)
│   └─ 其他语言栈    → 借鉴 Cordis 思路自己实现，或基于 LangChain 改造
│
├─ 研究"LLM 自主性"上限、跑 benchmark
│   └─ ✅ AutoGPT（参考实现）
│
└─ 写插件的底层规范（service、lifecycle、context）
    └─ ✅ Cordis（被 dsh 选中的底座）

---

九、设计哲学总结：控制面 ≠ 推理内核

把这五种 harness 放一起看，能提炼出三条反复出现的工程判断：

1. 薄内核 + 厚控制面：模型自己越来越强，harness 的价值越来越体现在工程控制上——可观察、可恢复、可组合、可治理。
2. 可组合性优先于功能数量：Cordis 的”时空可组合”、LangChain 的”chain/agent 可拼装”、Claude Code 的”Subagent + Skills + Worktree”——都在押注”组合”而非”全能”。
3. 生命周期显式化是稳定性的前提：每个 harness 都逼着开发者想清楚”何时启、何时停、失败怎么回滚”——这是胶水代码时代我们最缺的东西。

底层逻辑：harness 不是银弹，而是把”模型能做的事”翻译成”生产系统能稳定交付的事”的工程契约。把它当操作系统写，不要当 prompt 写。

---

参考资料

• DeepSeek Harness（中文 README）: https://github.com/deepseek-ai/deepseek-harness/blob/master/README.zh.md
• Cordis 框架与时空可组合论文: https://github.com/cordiverse/cordis · https://github.com/cordiverse/paper
• Anthropic《Building Effective Agents》: https://www.anthropic.com/engineering/building-agents
• Claude Code 架构与 Harness 设计: https://docs.claude.com/claude-code/architecture · http://www.uml.org.cn/ai/202604101.asp?artid=27332
• LangChain Agent 架构: https://docs.langchain.com/agents/architecture
• AutoGPT 架构: https://agpt.co/docs/architecture
• 横向对比：Claude Code vs LangChain vs AutoGPT: https://composio.dev/blog/claude-code-vs-langchain-vs-autogpt