DeepSeek Harness刷屏：别只盯模型，AI真正变强的是“工作台”

从聊天框到可运行的 Agent，竞争正在从“谁会回答”转向“谁能把工具、文件、终端和流程组织起来”。

导读

如果你这两天在开发者社区看到 DeepSeek Harness，先别急着把它理解成又一个聊天助手。它更像一套把模型、工具、技能、会话、沙箱、存储、调度和界面拼到一起的 Agent 工作台。

这篇不教你安装，也不把它吹成万能工具。我们关心的是：为什么“一切皆插件”会让 AI 产品的竞争点发生变化；为什么一个看似程序员向的终端工具，最后会影响普通人使用 AI 的方式。

为了避免只看项目宣传，本文把 DeepSeek Harness 官方说明、Cordis 论文草稿和 Self-Harness 论文放在一起读：前者讲产品形态，中间讲插件系统的理论底座，后者给出“harness 能不能让 Agent 真的变强”的实验线索。

资料来源

1. 1. DeepSeek Harness 开发者预览版：一切皆插件
   官方页面说明 dsh 面向 Harness 开发者开放测试，模型、工具、技能、会话、沙箱、存储、循环、调度、UI 等 Agent 能力均由插件组合。

   https://deepseek.com/harness/

2. 2. deepseek-ai/deepseek-harness GitHub README
   项目 README 将 DeepSeek Harness 定义为 DeepSeek AI 开发的开源 agent harness，并标注当前处于 developer preview。

   https://github.com/deepseek-ai/deepseek-harness

3. 3. A Programming Paradigm for Spatiotemporal Composability
   Cordis 论文草稿，讨论动态组件组合、可回滚 effect、reactive coeffect，以及插件系统的时空可组合性。

   https://github.com/cordiverse/paper

4. 4. Self-Harness: Harnesses That Improve Themselves
   arXiv 论文，提出 Weakness Mining、Harness Proposal、Proposal Validation 三阶段循环，并在 Terminal-Bench-2.0、SWE-bench Verified、AppWorld 上评估 harness 自改进。

   https://arxiv.org/abs/2606.09498

一句话看懂：模型像大脑，Harness 像身体和工作台。以前大家争谁的大脑更聪明，现在开始争谁的身体更稳、工具更顺、记忆更清楚、动作更可追踪。

真实文献信息截图：Self-Harness 论文标题、作者与摘要入口

1. 先把概念说清楚：Harness 不是外壳，是 Agent 的“工位”

很多人看到 Harness 会自然翻译成“外壳”。这个翻译不算错，但容易低估它的重要性。

一个只会聊天的模型，拿到你的问题后输出一段文字；一个真正能干活的 Agent，需要看到文件、拆任务、调用工具、运行命令、保存中间结果、遇到失败后恢复、在关键动作前等你批准。把这些能力组织成稳定流程的那一层，就是 harness。

解释图：模型、Harness、插件/工具三层关系。读者先看图，再往下读就不会被术语绊住。

你可以把它想成程序员的工位：模型是坐在工位前的人，终端、编辑器、浏览器、权限弹窗、日志系统、任务看板、回滚机制、测试命令，都是工位的一部分。人再聪明，桌上没有工具、文件乱放、没有测试、没有操作记录，也很难稳定交付。

DeepSeek Harness 这次最值得看的点，不是“又多了一个模型入口”，而是它把 Agent 能力拆成可组合插件：模型是一块，工具是一块，技能是一块，沙箱是一块，存储和会话也是一块。每一块都可以被替换、启用、禁用或组合，这会把 Agent 从单一产品变成可装配系统。

模型层

负责理解、推理、生成，但它本身并不知道你的电脑里有什么文件，也不能天然执行动作。

工具层

把文件读取、网页检索、终端命令、代码编辑、数据库查询等动作暴露给模型。

Harness 层

决定模型什么时候看什么、调用哪个工具、怎样记录轨迹、何时停下等人批准。

插件层

把能力拆成可以安装、卸载、替换的部件，让 Agent 不必每次从头重写。

2. “一切皆插件”为什么容易让开发者兴奋

因为它把 Agent 的复杂度从“写死在产品里”，变成“挂在系统上”。

传统 AI 应用常常是一个固定盒子：你能用什么模型、能连什么工具、日志怎么保存、是否能调终端、是否能跑测试，基本由产品方决定。插件化之后，这些能力不再是铁板一块，而是可以像积木一样重排。

这对程序员尤其敏感。一个编码 Agent 如果只能聊天，它最多像旁边的聪明同事；如果它能读仓库、看报错、改文件、跑测试、等你批准 shell 命令、把每一步写入轨迹日志，它就更像一个正在你电脑旁边工作的副驾驶。差别不是“回答更像人”，而是“动作更像工作流”。

论文原图 Figure 1：人手改 harness、外部 Meta-Harness、Self-Harness 三种范式放在一起比较。

DeepSeek Harness 官方页面强调，模型、工具、技能、会话、沙箱、存储、循环、调度、UI 等能力都由插件组合而成；Cordis 论文草稿进一步把这种组合拆成两个维度：时间上能不能撤回副作用，空间上能不能声明并管理组件依赖。说人话就是：插件不能只是能装上去，还要能知道自己改了什么、依赖什么、拆掉之后留下什么。

这也是它不像普通扩展市场的地方。浏览器插件主要扩展浏览器，IDE 插件主要扩展编辑器；Agent 插件扩展的是“能替你行动的系统”。一旦插件能接触文件、终端、账号、数据库，插件就不再只是小功能，而是权限边界的一部分。

用户目标

我要修一个 bug、整理一个项目、生成一份报告，而不是只问一句话。

↓

Harness 编排

把目标拆成读取文件、运行命令、调用工具、记录轨迹、等待确认。

↓

插件执行

不同插件提供模型、检索、文件系统、shell、测试、UI 或沙箱能力。

↓

可追踪结果

每一步留下轨迹，可恢复、可分叉、可回放，也更容易被审计。

3. 真正的看点：Agent 变强，不一定只靠换更贵的模型

Self-Harness 论文给了一个特别有意思的角度：让 Agent 从自己的失败轨迹里改工作方式。

论文把问题拆得很细：LLM Agent 的表现不只由 base model 决定，也由 harness 决定。相同模型，换一套更适合它的工具使用规则、失败恢复策略、验证流程，结果可能完全不同。

Self-Harness 的循环有三步。第一步叫 Weakness Mining：让固定模型在任务里跑，收集执行轨迹和可验证结果，把失败聚成模式，而不是只看单个错误。第二步叫 Harness Proposal：根据失败模式提出小而具体的 harness 修改，例如更早创建必需文件、对工具错误触发恢复策略、限制无尽探索。第三步叫 Proposal Validation：候选修改必须通过回归测试，只有在不伤害 held-out 任务的前提下才会被提升。

论文原图 Figure 2：Self-Harness 的三段式循环——挖失败、提修改、做验证。

这个机制和“多写几句提示词”不一样。提示词更像给人打鸡血，Self-Harness 更像改工作流程：如果你总是忘记交附件，那就把“先创建附件骨架”写进流程；如果你总是在同一个工具错误上打转，那就加一个失败后转向的中间件；如果你总是在探索里耗光预算，那就要求到某个阶段必须进入实现和验证。

论文里的数字也能说明问题。在 Terminal-Bench-2.0 上，MiniMax M2.5 的 held-out pass rate 从 40.5% 提到 61.9%；Qwen3.5-35B-A3B 从 23.8% 提到 38.1%；GLM-5 从 42.9% 提到 57.1%。这不是说 harness 可以替代模型能力，而是说明“怎么让模型行动”本身就有明显杠杆。

结果图卡

论文结果段落截图

最像现实工作的一点是：很多失败并不是不会推理，而是流程失控。文件没留下、命令超时没换路、测试没跑完就收工、工具返回结构不合规却继续往下走。人类团队会用 SOP、代码评审、测试门禁、回滚机制解决这些问题；Agent 也需要类似的制度。

4. 普通人为什么也该关心：AI 正从“回答问题”变成“接手流程”

你不写代码，也会被这种产品形态影响。

当 AI 只在聊天框里回答，风险和价值都比较有限：它可能胡说，但它很难直接改你的文件、发你的邮件、连你的数据库。可是当 AI 变成工作台，它开始接触真实世界：文档、表格、日历、浏览器、网盘、客户系统、支付后台。效率上限提高，误操作和越权的下限也被打开。

未来更常见的使用场景可能不是“问 AI 一个问题”，而是“给 AI 一段可执行任务”。比如：把本周客户会议整理成周报、检查项目里的 TODO、根据数据表生成初版图表、读完三份 PDF 写比较表、把网页里的订单信息录入系统。这些任务都需要文件、网页、账号、工具链和确认机制。

这就是为什么 DeepSeek Harness 值得被非程序员理解。它代表一种方向：AI 产品的核心不只是模型，更是围绕模型的工作环境。谁能让模型更安全地看见上下文、更稳定地调用工具、更清楚地记录过程、更容易地被人接管，谁就更可能从“聊天产品”走向“工作基础设施”。

• 看模型能力：它能不能理解目标、拆解任务、判断失败。

• 看工具边界：它能不能只拿必要权限，而不是一次性拿走全部。

• 看轨迹记录：它做过什么、看过什么、调用过什么，是否能复盘。

• 看人工确认：删除、发送、付款、提交代码这类动作，是否必须让人看到参数后确认。

• 看失败恢复：遇到报错是无限重试，还是切换策略并验证结果。

5. 它的想象力，也正是它的风险入口

插件化越强，边界越要清楚。

DeepSeek Harness 让人兴奋，是因为它把 Agent 能力拆得足够细；但同样因为拆得细，安全问题也不能靠一句“相信模型”解决。插件是谁写的？它要读哪些文件？它能不能联网？它有没有 shell 权限？它拿到的 token 是只读还是可写？它的工具描述会不会被偷偷改掉？这些问题都会从工程细节变成普通用户的真实风险。

所以更成熟的 Agent 竞争，不会只拼“能做多少事”，还会拼“哪些事默认不能做”。一个好的工作台不应该让 AI 随意狂奔，而应该有清晰的权限分层、会话轨迹、沙箱隔离、可撤回设计和人工确认。真正有价值的自动化不是把人踢出流程，而是把人放在关键节点。

如果说 DeepSeek Harness 让我们看到 Agent 的上限，下一篇就要看它的另一面：当 MCP、Skill、Plugin 这些能力开始拿权限，插件投毒会怎样把便利变成入口。

结论很朴素：别只问“这个 AI 聪不聪明”，还要问“它在哪张工位上干活，谁给它配的工具，出了事能不能查清楚”。