## 开篇：从"AI 的过去架构"看懂 Harness 的本质 **DeepSeek Harness（dsh）** —— 8 月 13 日发布即登顶 GitHub 趋势榜、两周 Star 破 17 万的 Agent 框架。但要真正读懂它，得先回答一个关键问题：**Harness 到底是什么？为什么 2026 年它成了 AI 世界的核心词汇？** 如果你关注 AI 圈，最近一定频繁看到一个新词——**Harness**（驭具 / 马具）。Databricks、LangChain、OpenAI 官方都在讲 **"Harness Engineering"**。这不是炒作。看一组数据： - LangChain 的编码 Agent 在 Terminal Bench 2.0 上，**只优化 Harness、不动模型**，得分从 52.8% 提升到 66.5%，排名从第 30 跃升到第 5。 - OpenAI 用 Codex 智能体在"禁止人工写代码"的约束下，构建了超百万行代码的内部产品——工程师的角色变成了**设计 Harness**。 - 2026 年一个关键认知：**Agent 的成败，大部分问题出在 Harness，而不是模型本身。** 一句话先立住核心公式： > **Agent = Model + Harness** **Model 负责"思考"（推理），Harness 负责"其他一切"（行动）。** 如果你花了几个月优化 Prompt 和选模型，却依然得到一个脆弱的 Agent，很可能是一直在优化错误的东西——忽略了占大头的那 68%。 --- ## 一、AI 之前的架构是怎么样的？（三代演进全景图）要理解 Harness，先看它之前的架构长什么样。AI Agent 系统大致经历了**三代**演进——下图是三代架构的对比全景： ```mermaid flowchart TD subgraph 第一代["第一代：Prompt Chaining（提示词串联）"] A1[LLM 调用] --> A2[LLM 调用] --> A3[LLM 调用] A0[文本输出
无工具·无记忆] -.-> A1 end subgraph 第二代["第二代：Tool + RAG（工具调用 + 向量检索）"] B1[LLM] -->|调用| B2[(Function Call 工具)] B1 -->|检索| B3[(向量数据库 RAG)] B0[手动拼接上下文
if-else 权限] -.-> B1 end subgraph 第三代["第三代：Harness（2025–2026）"] C1[Agent 循环 while] --> C2[工具执行] C1 --> C3[分层记忆] C1 --> C4[权限治理] C1 --> C5[多 Agent 协作] C0[系统化编排
生产级可靠] -.-> C1 end 第一代 --> 第二代 --> 第三代 ``` **三代演进一句话总结**：第一代只会"答话"（无工具），第二代能"调用"（但有工具、无治理），第三代能"持续可靠地干活"（工具 + 记忆 + 权限 + 编排的系统工程）。 ### 第一代：Prompt Chaining（提示词串联）早期的 AI 应用就是"把提示词喂给 LLM，拿到文本结果"。做复杂任务就**把多个 LLM 调用串起来**——这叫 Prompt Chaining。这段生成的输出，作为下一段的输入。 **问题非常明显**： - 模型没有任何工具，只能"纸上谈兵"，无法真正做事（查库、改文件、调 API） - 上下文（context）完全靠人手写死，没有管理 - 没有状态、没有记忆、没有安全概念 - 一旦流程复杂，全靠人写大量 if-else 拼接，代码变成"意大利面" > 形象点说：第一代是**让一匹没戴马具的马拉车**——力气是有的，但完全使不上劲，只能对着空跑。 ### 第二代：Tool + RAG（工具调用 + 向量检索）后来出现了 Function Call（函数调用）——模型终于能调用工具了。配合 RAG（检索增强生成），能从向量数据库里捞知识喂给模型。 **这批框架的代表是 LangChain、AutoGPT**。能力确实上来了，AI 终于能"做事"了。 **但问题在于"拼凑"**： - 上下文管理 = 手动拼字符串，错乱是常态 - 权限检查 = if-else 硬编码，一改就崩 - 记忆 = 往向量库里塞完事，没有系统设计 - 工具之间没有统一注册和执行机制，越做越乱 > 第二代是**给马戴上了鞍，但缰绳、勒口、挽具各装各的**——能拉车了，但一上复杂路况就散架。 ### 第三代：Harness（2025–2026） 2025 年，Claude Code、Codex CLI、Devin 出现，标志着**第三代**的到来。本质区别一句话： > **上下文管理和安全治理，同时从"ad-hoc 拼凑"变成了"系统工程"。** 这就是 Harness 的诞生。 --- ## 二、为什么需要 Harness？它解决了什么 ### 核心矛盾：模型会"思考"，但不会"活着" 裸的 LLM 是什么？它是**无状态的**——用完一次就忘，不记得刚才说过什么，也不知道怎么调工具，更没有"持续干完一件事"的概念。要让模型真正"干活"（不是答个题就完），必须在它外面套一层基础设施。下图展示了 Harness 如何"包裹"模型并赋予它行动能力： ```mermaid flowchart LR User[用户/任务] --> H[Harness 运行时] H --> M[LLM 模型
负责推理] H --> T[工具执行
代码·文件·API] H --> Mem[(记忆/状态管理)] H --> Sec[安全边界
权限·沙箱] H --> Loop[执行循环
while 持续迭代] M -.决策.-> H T --> H Mem --> H Sec --> H Loop --> H H -->|结果/输出| User ``` 它给模型这 5 样东西： 1. **工具**——能调用代码、文件、网络、API（通过 MCP 等协议） 2. **记忆**——跨步骤、跨会话记得状态和偏好 3. **循环**——不是调一次 API 就结束，而是 while 循环持续迭代，直到任务完成 4. **安全边界**——权限控制、沙箱隔离、危险操作拦截 5. **错误恢复**——工具调用失败能重试、能兜底 **这一整套"让模型真正干活"的基础设施，就是 Harness。** ### 一个贴切的比喻：LLM 是 CPU，Context 是 RAM，Harness 是操作系统 ```mermaid flowchart LR subgraph 硬件层["硬件层"] CPU[CPU
LLM 模型] RAM[RAM
Context 上下文] end subgraph 软件层["软件层"] OS[操作系统
Harness] end CPU --> OS RAM --> OS OS -->|资源管理·调度·I/O| Apps[应用/Agent 任务] ``` **LLM = CPU**：只负责"执行指令"，本身无法管理自己 **Context = RAM**：暂存当下工作数据，易失、容量有限 **Harness = 操作系统（OS）**：负责**资源管理**（哪些上下文保留/丢弃）、**进程调度**（哪个 Agent 何时响应）、**I/O 操作**（与外部系统接口）。就像 OS 把硬件复杂性抽象成稳定接口，Harness 把 LLM 不可预测的输出，转化为**可靠、可组合、可审计的服务**。 **这个比喻是理解整篇文章的钥匙：你架构的不再是"单个模型"，而是一套拥有资源分配、容错模式、服务保证的"AI 操作系统"。Harness 就是那层运行在这套系统上的"OS"。** --- ## 三、Harness vs 提示词 vs 上下文：本质区别这是最容易混淆的地方。很多人以为"把提示词写好、把上下文塞满"就是做好了 Agent。**大错特错。** ### 一张表看清三个概念 | 维度 | 提示词（Prompt） | 上下文（Context） | Harness | |------|------------------|-------------------|---------| | **本质** | 一段"开场指令"，告诉模型干什么 | 喂给模型的所有信息（对话历史、工具定义、检索结果） | 包裹模型的整套执行与治理基础设施 | | **作用层级** | 输入层面（告诉做什么） | 输入层面（提供依据） | 系统层面（让模型能行动、能持续、能安全） | | **生命周期** | 每次请求都变，随对话改写 | 随会话动态增长/压缩 | 贯穿 Agent 整个生命周期，持续运行 | | **能否让模型"干活"** | 不能，只是"希望"它干活 | 不能，只是"允许"它知道更多 | **能**，提供工具/循环/记忆/权限让其真正执行 | | **类比** | 给厨师的"菜谱" | 厨房里的"食材与调料" | 整个"厨房系统"（炉灶+刀具+流程+食品安全） | ### 关键洞察：Prompt 和 Context 只是 Harness 里的两个零件 Databricks 说得最透彻： > **Prompt and context engineering both live inside harness engineering.**（提示词工程和上下文工程，都属于 Harness 工程的一部分。）提示词和上下文是 Harness 这个系统里的**组成部分**，不是对立面，更不是全部。 **还有一个扎心数据**（来自 Harness 深度分析）： > Agent 实际看到的上下文里：**工具输出占 67.6%，工具定义占 10.7%，系统提示词只占 3.4%。** 如果你一直在优化系统提示词而忽略工具输出格式，那相当于**只优化了 Agent 3% 的上下文，却无视了 68% 的部分**。冗长的工具输出，是导致"上下文腐烂"（context rot）最快的路径——这也是 Harness 要重点治理的。 --- ## 四、DeepSeek Harness（dsh）怎么用理解了上面三节，现在上手一个真实的 Harness——**DeepSeek Harness**。它的核心口号是 **Everything is a Plugin（万物皆插件）**，构建在 [Cordis](https://github.com/cordiverse/cordis) 之上，把 Agent 的骨架（工具、记忆、路由、UI、甚至执行循环本身）全部插件化。 ### 前提条件 | 项目 | 要求 | |------|------| | Node.js | 已安装（推荐 LTS 版本） | | 网络 | 可访问 npm 与 GitHub | | 可选 | DeepSeek API Key（如需接入官方模型） | ### 方式一：一条命令快速启动（推荐） ```bash # 安装并启动，默认 Web UI 在 http://127.0.0.1:3080 npx @deepseek-ai/dsh web ``` 命令会启动 Web UI 并自动打开浏览器。若在 SSH 环境（无本地浏览器），加 `--no-open` 只打印地址： ```bash npx @deepseek-ai/dsh web --no-open ``` ### 方式二：从源码运行 ```bash git clone https://github.com/deepseek-ai/deepseek-harness.git cd deepseek-harness pnpm install pnpm run build # 使用构建产物启动（无需重新编译） pnpm dsh web ``` ### 方式三：开发插件 dsh 的灵魂是插件。官方用 `dsh-plugin` 话题做插件发现，你写的插件打上这个 topic 即可被社区检索到： - 接入 **MCP** 桥接已有工具 - 构建**代码执行沙箱**、**记忆系统**、**模型网关** - 甚至替换默认的 **Agent 执行循环** ### 启动后做什么 1. 浏览器打开 `http://127.0.0.1:3080` 2. 通过 Web UI 配置要接入的模型（含 DeepSeek 官方模型） 3. 按需挂载插件（工具、记忆、MCP 服务等） 4. 开始给 Agent 派发真实任务——让它不仅能聊天，更能**调工具、持续执行、跨会话记忆** **更多入口**：架构文档见官方 `docs/architecture.md`，开发指南见 `docs/development.md`，插件示例可搜索 GitHub 上的 `dsh-plugin` 话题。遇到问题可到官方 GitHub Discussions 反馈。 --- ## 结语 DeepSeek Harness 的爆红不是孤立事件，而是 2026 年"开源 AI 竞争单位从代码库转向 Agent 工程系统"大潮的缩影。理解它的真正价值，不在于记住"万物皆插件"这句口号，而在于看清它背后那个更本质的趋势： > **AI 正在从"会说话的工具"进化为"会干活的系统"，而 Harness 就是那套让模型真正"活起来"的操作系统。** 技能是肌肉、记忆是海马体、路由是循环系统——当巨头们把骨架拆成乐高积木，真正的较量，是看谁能把这套"AI 操作系统"拼得又稳又强。

DeepSeek Harness 深度解析：从「AI 的过去架构」看懂 Harness 的本质

DeepSeek Harness 深度解析：从「AI 的过去架构」看懂 Harness 的本质