DeepSeek Harness 是什么：模型还是客户端？

围绕 DeepSeek^广告 Harness 的讨论里，最高频的困惑是：它到底是一个模型，还是一个客户端？答案都不是那么简单的二分法。B站UP主在「十连问」系列中给出的解释，恰好把这个概念拆得比较清楚——Harness 是模型之外的那一层工程系统。

Harness 的原意：给野马套上缰绳

Harness 在英文里的本义是马具，包括缰绳、马鞍、马灯这一整套装备。这个比喻放到大模型上相当贴切：模型本身能力很强，但使用过程中就像一匹野马，必须有人在它身上套一套装备，才能把力量导向正确的方向。

在技术语境下，Harness 指的是模型外面那一层工程系统。系统提示词、工具调用、文件系统、沙箱环境、记忆系统、上下文管理、约束机制、反馈回路、钩子中间件、编排逻辑——这些统统属于 Harness 的范畴。UP主的总结很干脆：模型负责判断，Harness 负责剩下的一切。

系统提示词（System Prompt） 是在对话开始前注入给模型的指令性文本，用来设定模型的角色、行为边界与输出风格。它不占用用户可见的对话轮次，却会持续影响后续每一次生成。在 Harness 体系中，系统提示词属于最基础的约束手段之一——它决定了模型“以什么身份、按什么规则”去调用工具和执行任务。与微调不同，系统提示词无需改动模型权重，修改成本极低，因此常被用作快速调整 Agent 行为的旋钮。理解这一点，就能明白为什么 Harness 把提示词管理视为工程层而非模型层的问题。

钩子与中间件（Hooks / Middleware） 借鉴自 Web 框架的设计模式：在请求进入模型之前、工具调用返回之后等关键节点插入可编程的拦截逻辑，用于日志记录、权限校验、结果改写或失败重试。它使得 Harness 可以在不侵入模型和工具代码的前提下，统一处理横切关注点，是“编排逻辑”落地为可维护代码的常见手段。

四种模式：模型、工具、技能与沙箱的插件化拆分

如果按插件化思路去理解 Harness 的组成，可以把它拆成几个相互独立、可自由替换的层次。

模型层负责推理与决策，是整个系统的“发动机”，但本身不带记忆、不带工具、不带执行环境。工具与技能层是模型与外部世界交互的接口，决定了它能调用什么能力。据UP主介绍，Harness 提出了“一切皆插件”的概念，通过一条命令即可一键安装，源码也在开源仓库中可以直接获取。

沙箱与存储层为执行提供隔离环境和状态保持，上下文与记忆层则解决多轮交互中的信息延续问题。再加上 UI 等外围组件，这些模块共同构成完整的 Agent 能力。关键在于“自由替换、灵活组合”——这一层设计思路，是把 Agent 从单体架构推向可组装的工程体系。

工具调用（Tool Calling / Function Calling） 指模型在生成过程中输出结构化的调用请求（通常是函数名加参数），由外部运行时真正执行并把结果回传给模型，形成“判断—执行—再判断”的循环。模型本身并不执行任何代码，它只负责决定“该调用什么、传什么参数”，真正的执行发生在 Harness 一侧。这正是“模型负责判断，Harness 负责剩下的一切”的技术依据。

沙箱（Sandbox） 是为工具执行提供的隔离运行环境，通常限制文件系统访问范围、网络出口和系统调用，防止模型生成的代码或命令影响宿主机。没有沙箱，让 Agent 自由执行命令的风险极高；有了沙箱，失败可以被安全地回滚和重试。沙箱与存储层配合，才能让 Agent 在多步任务中保持状态又不越界。

开源生态：开发预览版与全球开发者测试

Harness 以开发预览版的形式发布，面向全球 Harness 开发者开放测试，并同步开源代码。这意味着它不是一个封闭的产品封装，而更像是一套可供二次开发的骨架。

“一切皆插件”的定位让生态扩展变得直接：想替换某个环节，不需要改动整体架构，换个插件即可。对开发者而言，这种设计降低了定制门槛；对生态而言，它把能力边界交给了社区去填充。UP主也提到，如果想研究源码，直接从代码托管平台克隆下来即可。

常见的理解误区

把 Harness 当成模型，是最容易踩的坑。模型是权重与推理能力，Harness 是围绕模型搭建的工程外壳，两者不在同一个抽象层级。

把 Harness 当成单纯的客户端也不准确。客户端只是 UI 与交互入口，而 Harness 覆盖的范畴要宽得多——从沙箱到记忆，从约束到编排，都是它的组成部分。

理解这一点之后，面试中被问到“什么是 Harness”，答案就清晰了：它就是模型之外的一切。这个定义看似宽泛，但恰恰是“驾驭工程”的本质所在——模型给出判断，Harness 承担其余所有工程责任。

为什么这个概念值得关注

Agent 系统的复杂度，往往不在模型本身，而在模型与环境的接缝处。上下文怎么管理、工具怎么调、失败了怎么回滚、多轮之间怎么保持记忆——这些问题的解法，决定了 Agent 能不能真正跑起来。Harness 把这些接缝显式地命名为一套工程体系，并用插件化方式组织，思路是有价值的。

对普通用户来说，它可能表现为一个开箱即用的开发预览版；对开发者来说，它是一套可拆解、可替换、可开源改造的骨架。两种视角并不冲突，因为 Harness 本身就是连接模型与使用场景的中间层。