DeepSeek Harness 满月复盘：亮点、风险与未来路径

DeepSeek 推出的独家 Harness（下文简称 DSH）已经满一个月。选择在早期热浪退去之后再来回顾，往往能看得更清晰。作为一个仍处于「开发者预览」阶段的项目，DSH 的很多设计都还会改变，但一个月的社区演进已经足以让我们判断它的定位、短板与商业方向。

本文基于 B 站 UP 主「技术杂谈」的分析，从商业演进、人员储备与未来路线三个维度，拆解这个满月项目的真实进展。

Agent = Model + Harness：定位清晰但独特性不足

DSH 的定位写得非常直接——它主张 agent 应该是 model 与 harness 一体的，并给出了公式 agent = model + harness。这一判断与业界共识一致：模型厂商为增强用户粘性、带来更好性能，把 model 和 harness 绑在一起是合理选择。但先发的 Claude Code 和 Codex 已经占据了大量市场，后发者必须拿出自己的特色。

DSH 主打的特色是 Plugin（插件），并配套了一套名为 Codex 的设计理念，强调可组合性。理念虽好，落地却仍显单薄。

时间线：从热议到热浪退去

项目首发时迅速引爆社区，仓库如今已积累超过 22 万 star——虽然 star 数早已失去太多衡量意义，但足见其社区明星地位。值得注意的一个动作是：DSH 仓库把 issue 和 PR 都关闭了。有评论认为这「不是真正的开源」，但从 DeepSeek 当前的生态地位看，海量涌入的 issue 与 PR 中真正有价值的贡献可能不到千分之一，大海捞针的成本极高。保持内部快速迭代，在这个阶段反而更合理。

从 0.1.2 版本开始集成的实测反馈偏中性甚至负面：与成熟 Harness 相比缺乏独特性，还缺少基本的性能优化。例如在挂载大量 MCP 工具时，成熟 Harness 普遍具备 Lazy 工具发现能力，避免每次请求都携带全量工具 schema、白白消耗 Token，而早期 DSH 并不具备。同样的任务，DSH 在 Token 性价比上并无优势。

MCP（Model Context Protocol）是 Anthropic 提出的一套开放协议，旨在标准化 AI 模型与外部工具、数据源之间的交互方式。Lazy 工具发现（Lazy Tool Discovery）是成熟 Harness 在大量 MCP 工具接入时的一种优化策略：Harness 不会在每次请求时把所有已注册工具的完整 schema 都塞入上下文，而是根据任务意图动态选取相关工具。这样做可以大幅减少每次 API 调用携带的 Token 数量。由于主流大模型 API 按 Token 计费，全量携带工具 schema 会显著推高使用成本，在工具数量达到数十乃至数百个时尤为突出。这也是为什么 Token 性价比成为评估 Harness 成熟度的重要指标之一。

Plugin 生态：缺爆款、缺独占

既然 Harness 本身没有独特性，独特性就只能寄托在 Plugin 上，于是围绕 Plugin 出现了大量解读和抢占市场的尝试。但一个月下来，两个问题暴露得很清楚：

• 缺少爆款：没有出现「装了就必装、提升明显」且与 DSH 深度结合的插件。
• 缺少独占：即便有效果不错的插件，其能力几乎都能被移植到 Claude Code 或 Codex 上，并非 DSH 独有。

从 DSH 官方首发演示看，场景也相对简单：给 UI 加一只浮动的鲸鱼、开发一个小游戏插件、做一个 code review 模式等。这些能力既不够爆款，也不够独占——同样的功能跑在 Harness 内外，目前看不出本质差异。

开放插件带来的安全隐忧

热浪退去后，社区开始关注薄弱环节，其中最尖锐的是安全性。当插件体系如此开放、agent 可以修改自身时，兼容性与安全性之间必然存在矛盾。

更主流的场景一定是专业开发者做出强插件，再分发给大量用户——毕竟开发者和使用者天然是两个群体。问题在于：使用者如何审计插件本身及其供应链的安全性？设想某个受欢迎的插件在后续版本被植入一段 prompt，引导 Harness 主动把银行卡号、账户信息等敏感数据上报到远程地址，这就是典型的供应链攻击。

据 UP 主判断，现阶段的 DSH——乃至几乎所有 Harness——都还没有解决这类审计问题。在安全规范成熟之前大力推行插件体系，容易被诟病为「提供了不安全的底座」。所幸目前尚无爆款，也就没有酿成大规模安全事故的空间。

供应链攻击（Supply Chain Attack）是软件安全领域的经典威胁模型：攻击者不直接攻击目标系统，而是污染目标所依赖的上游组件——例如开源库、插件或构建工具。在传统软件生态中，npm、PyPI 等包管理社区已多次发生恶意包事件。AI Harness 的插件体系面临类似风险，但危险性更高，因为插件可以直接影响 LLM 的 system prompt 和工具调用逻辑，攻击者只需在插件的 prompt 中注入指令，即可在用户无感知的情况下操控模型行为、窃取上下文中的敏感信息。与传统代码审计相比，prompt 级别的恶意注入更难通过自动化工具扫描发现，这对插件市场的治理机制提出了更高要求。

Codex Kernel：偏研究品位的抽象

DSH 围绕插件体系提出了 Codex Kernel 机制，但这套机制目前还没体现出真正的差异化优势。它有配套论文，强调生命周期、Effect、Service、Invent 等抽象概念，把自己描述为「一种作为时空和组织性的编程范式」。

UP 主认为，这类 Brainwork 在 LLM 大火之前其实非常常见（React 某种程度上就是这类事情的集大成者）。真正的难点不在于框架多优雅精确，而在于能否兼容尽可能多的 Dirty Work。而这些 Dirty Work 往往不是纯思考能规避的，必须遇到足够多真实插件才能理解。Codex 发布后频繁出现 Breaking Change、插件升级冲突，正说明其成熟度还不够高。

此外，内置工具设计对 Harness 至关重要，也是 model 与 harness 一体化的核心环节。但 DSH 的内置工具大量参考 Claude Code——以经典编辑工具为例，其 filePath / oldString / newString / replaceAll 的参数设计与 Claude Code 如出一辙。用 oldString 唯一匹配来避免误修改，正是 Claude Code 很早提出的合理设计。工具层面，DSH 目前仍在从成熟 Harness 进化，能否长出与模型深度绑定的高效工具，有待观察。

路在人员储备：Harness 需要「代码大王」

「谜底有时候就在谜面上。」UP 主的核心观点是：Harness 作为代码产品，其发展路径取决于写代码的人是谁。而 Harness 需要的是代码大王（有大量生产级工程代码经验的人），而非 AI 研究者。研究者主导的 Harness 大概率不好用，这也是许多模型厂商 Harness 失败的原因。

三个典型案例佐证了这一判断：

• Claude Code 的 Boris：加入 Anthropic 前履历典型偏工程，在 Meta（Facebook）近 7 年做服务端架构、开发者基础设施、代码质量项目，还给 Instagram 做过 PM。强工程背景加产品 sense，让他能优雅地兼容真实世界的 Dirty Work。
• Codex 的 Tibo：曾在 Google 做三年资深研发，之后在 DeepMind 带一个 20+ 人的 SWE 团队负责 AI/ML 基础设施。虽偏研究机构，但工程代码底子扎实，做出的 Codex 最终接地气。
• DSH 的崔天逸：浙大毕业后进入以代码难度高、代码质量追求极致著称的 Jane Street 做量化 researcher。这一背景完全符合「代码大王」画像，其量化背景也与幻方系有共同语言。目前他在 DSH 贡献者中代码贡献量绝对领先。

从这个角度看，DeepSeek 选人是成功的。但风险在于：DSH 把偏研究品位的 Codex 体系放在了较前的位置。要把 Plugin 系统真正做好，DSH 需要的是更有生产级 Plugin 设计经验的人——比如从 VS Code 这类处理过海量 Dirty Work 的巨型编辑器生态中挖人，而非依赖研究者。

国内的 WorkBuddy（腾讯出品）也是一个正面案例。其团队早年做 CodeBuddy 起家，在 LLM 时代之前就积累了工程经验，团队本质上聚集了一批代码大王，因此能做出较好的 Harness。相比之下，腾讯内部另一条沿用 OpenCode 逻辑、命名带 Code 的路线，被 UP 主视为急功近利、缺乏品位的体现。

Jane Street 是全球顶级的量化交易公司，以对代码质量和工程严谨性的极致追求著称。其内部大量使用 OCaml 这一在工业界相对小众的函数式编程语言，对类型系统和程序正确性有接近学术级别的要求。在 Jane Street 工作的工程师需要长期处理高并发、低延迟、强一致性的生产级系统，同时应对金融场景下对 bug 零容忍的压力。这种背景塑造出的工程师，往往兼具研究者的抽象能力和务实工程师的落地能力——既能设计优雅的系统抽象，又对真实世界的 Dirty Work 有足够的耐心与经验，恰好契合 Harness 开发所需的复合能力画像。

Harness 的完整形态：一核心 + 三形态

一个完整的 Harness 体系应该是「一套核心 + 三种形态」：

• 核心：可被程序调用的 Runtime 库。Anthropic 是 Claude Agent SDK，OpenAI 是 Codex Runtime，DeepSeek 则是 DSH Runtime。若一个 Harness 上来只有 TUI 或桌面端、没有核心库，长远前景较弱。
• 三种形态：以 CLI 为入口的交互式 TUI、桌面端、云上 Agent。三者共享核心才能保证迭代速度和竞争力。

云上 Agent 已成确定性方向：Anthropic 上半年推出基于 Claude Agent SDK 的 Claude Managed Agents，OpenAI 也推出了基于 Codex 的 Agent API。DSH 目前实际推出的可理解为 Runtime，TUI 与桌面端尚未真正产品化，云上 Agent 也还未推出。

从招聘看未来方向

崔天逸近期发布了超 150 人规模的招聘，重点方向包括服务端开发工程师、Agent 框架/组件、Agent 弹性计算等。招服务端工程师来做 Agent 框架，且需要弹性计算与 Sandbox——这几乎明示了 DSH 一定会搬上云端，走 Agent API 形态。而两到十年资深工程师的画像，也再次印证「找代码大王而非 AI 研究者」的逻辑。

TUI（Terminal User Interface，终端用户界面）是指运行在命令行终端中、具备交互式界面的程序，区别于纯命令行工具（CLI）。Claude Code、Codex CLI 等 Harness 均以 TUI 形式提供主要交互入口，用户无需离开终端即可进行对话、查看差异、确认文件修改等操作。Runtime 库则是指可被其他程序以代码方式直接调用的核心逻辑层，相当于 Harness 的「发动机」——上层可以是 TUI、桌面 GUI 或云端服务，但底层共享同一套 Runtime 可以保证行为一致性并降低维护成本。一个只有 TUI 而没有 Runtime 库的 Harness，难以支撑云端 Agent 形态，商业延伸空间因此受限。

结语：三条可能的路

综合来看，DSH 未来有三条路径值得关注：

1. 坚定 Model + Harness 一体化。成功的标志是一个公式：DSH + DeepSeek 模型 > DSH + 其他模型。哪怕暂时打不过 Claude Code + Claude，只要更贵更强的模型配上 DSH 都打不过 DeepSeek 自家模型，就意味着 Harness 具备了真正的独占性。
2. 深耕 Cloud Agent 并结合 Plugin 体系，以 Agent API 形式交付金融、医疗、科研等垂直行业的 Killer 级方案。插件被隐藏在云端背后，底层调优与弹性方案构成成本壁垒，用户粘性极强。
3. TUI 与桌面端随缘。普通用户虽最关注这个方向，但服务端团队并不擅长，需等待合适的产品品位人才成长起来。

作为满月的开发者预览版本，这些短板都可以接受。真正的看点在未来——DSH 能否长出属于自己的独占性，答案或许就藏在它的人员储备与云端布局之中。