刚刚，DeepSeek Harness震撼开源：一切皆插件
编辑｜Panda
今天凌晨， DeepSeek V4 Pro 正式版发布 ，引发热潮。现在，半天过去， DeepSeek H arn ess （开发者预览版）也来了！
当然，这并不意外，毕竟该项目之前已经铺垫了很久了，比如 DeepSeek Harness 团队的崔添翼就一直在社交网络上发预热贴以及为该团队招募人才。
我们也在 8 月初获得了 DeepSeek Harness 的内测资格，提前享受到了这个注定又会给 AI 社区带来新变革的智能体框架。
开源地址： https://github.com/deepseek-ai/deepseek-harness
比如这里，我们让配置了官方 DeepSeek-V4-Flash 的 DeepSeek Harness 我们构建了一个第一人称丧尸射击游戏。我们没有中途施加任何干预，就在 30 多分钟得到了一个虽不完美但已经相当可玩的成品：
考虑到近日 Andrej Karpathy 用 AI 生成 3D 世界的思路非常火爆，我们也让 DeepSeek Harness（V4-Flash）挑战了「华强买瓜」基准：基于文本描述将「华强买瓜」经典片段复现成 3D 动画（同样是 one-shot 提示的结果）：
整体来看，虽然离完美距离还很远，但这个动画的故事剧情大体还原，人物关系也大体能看出。相较之下，我们使用同样提示词，用配置了 GPT-5.6 sol-xhigh 的 Codex 制作出来的动画就差多了：
要知道，DeepSeek-V4-Flash 的参数规模远低于 GPT-5.6 sol。可以想见，DeepSeek Harness 应是立了大功。
今天随着 DeepSeek V4 Pro 正式版的发布，我们也将该模型接入了 DeepSeek Harness 再跑了一遍：
效果确实好一些了。
接下来，看看项目结构，非常惊人： 仓库已经包含超过 230 个 workspace 成员 ，代码分布在 packages/、apps/、examples/、python/、native/、vendor/、website/ 等区域。文件系统、终端、子进程、PTY、语言服务器、网页访问、技能、子智能体、工作流、计划模式、会话持久化、设置、凭据、遥测，几乎每一项能力都有自己的包。
如果把普通的 Agent 项目比作一台已经装好的电脑，那么 DeepSeek Harness 更像一块尺寸惊人的洞洞板：模型、工具、界面、存储、安全策略和上下文管理都可以插上去，也都可以拔下来。
它提供了一套默认组装方案，但看得出来，DeepSeek 真正想创造的并非某个固定形态的「DeepSeek 编程助手」，而是 一种组 装智能体 的方式 。
DeepSeek Harness 是什么？
先厘清一个容易混淆的问题：DeepSeek Harness 并非新的 DeepSeek 模型，也非一个单纯的 API 客户端。它是 一套用来构建、运行和扩展智能体的 SDK 与应用框架 ，默认可以连接 DeepSeek 模型（也可方便地自定义连接其它模型），让模型读取项目、修改文件、运行命令、管理任务、分配子任务，并通过 Web UI、全屏终端、Headless 命令或自动化协议与用户交互。
DeepSeek Harness 网页端提供了直接配置其它模型服务的便捷入口，无需用户手动编辑配置文件 当今的 AI 社区对 Harness 这个词已经不陌生了。其原本的含义是马具、线束、约束装置等，向上抽象一下，其作用是把力量连接到可以工作的机构上，同时又不让这股力量脱缰。具体到 AI 上，Harness 负责的是把模型接到文件系统、Shell、代码编辑器、网页和其他 Agent 上，同时记录它做了什么、限制它能做什么，并在出错时决定是重试、取消、压缩上下文，还是把问题交还给用户。
这或许也能解释为什么这个项目的代码量和包数量会如此庞大，毕竟这其中涉及的任务和工具选择非常多，包括工具调用是否可并行，取消命令能否真正停止子进程，工具结果是否会污染上下文，用户在模型运行中发来的新消息应该插到哪里，会话恢复后怎样重建当时的模型输入，子智能体拥有哪些工具，文件写入是否越过工作区，界面回放时看到的内容能否和实时运行一致。
DeepSeek Harness 试图把这些问题都变成正式的系统能力。
一切皆插件
DeepSeek Harness 最醒目的设计主张是「 一切皆插件 」，甚至连 Agent Loop 本身也被视为插件。
项目建立在 Cordis 微内核之上，运行中的 Harness 本质上是一个 Cordis Context。不同包向 Context 注册服务、事件和能力，最终由配置文件把它们组合成一套可以运行的智能体。
packages/core/ 是整个系统的核心，其中包含 Session、System Prompt、Tools、Agent 和 Agent Loop。它们解决的是最基本的问题：会话是什么，系统提示词如何组装，工具如何注册和调用，Agent 如何创建，以及一轮对话怎样从用户输入走到模型请求、工具执行和最终回答。
核心之外是大量能力包：
packages/llm/ 负责模型适配器和流式输出；
packages/shell/、packages/subprocess/ 与 packages/ terminal / 负责一次性命令、进程树和持续终端；
packages/fs/ 负责文件读写、编辑、搜索与策略限制；
packages/lsp/ 连接语言服务器，让 Agent 不只能用文本搜索，也能获得语义级代码导航；
packages/web/ 负责搜索与网页抓取；
packages/skill/ 管理可复用技能；
packages/subagent/ 和 packages/workflow/ 则把单个 Agent 扩展为可以委派和编排的多智能体系统。
再往外看，计划、目标、待办事项、后台任务、上下文压缩、会话查询、会话标题、凭据、用户设置、审批机制和遥测同样被拆成独立能力。这个结构最有意思的地方，是它体现了一种近乎执拗的边界意识：谁拥有接口，谁负责实现，谁把能力呈现给模型，尽量不要混在一起。
项目文档把典型能力拆成三层：接口、实现和消费者。
以 Bash 为例，接口定义「执行命令」是什么，本地实现负责真正创建进程，而面向模型的工具包负责把这项能力变成模型可理解的 schema 和结果。将来如果本地 Shell 要换成远程容器、云端沙箱或企业执行平台，理论上只需替换实现层，而不必重写模型工具和 Agent Loop。
这是一种典型的框架思维。它会让仓库在早期显得庞大，却也说明 DeepSeek Harness 的目标不是做一个只有官方团队能维护的成品，而是让不同部署方能换模型、换存储、换安全策略、加工具，甚至换掉智能体循环。
在这里，我们也看到了 DeepSeek 一直坚持的 真・开源 ！
cordis.yml
一份配置组装出不同的 Agent
插件化架构最终通过 cordis.yml 落到开发者手里。配置文件列出插件名称、稳定 ID 和参数，决定当前 Agent 究竟拥有哪一组能力。
同一套代码可以被组装成完全不同的产品形态。加入 DeepSeek LLM 适配器、文件系统、Bash 和 TUI，就得到终端里的编程智能体；把交互界面换成 Web 插件，就得到浏览器应用；使用 Headless 入口，它会接受一个任务，完成模型与工具轮次，打印答案后退出；换成 ACP 或 JSON-RPC 前门，它又能成为其他程序可以驱动的自动化服务。
配置还支持覆盖层。TUI 和 Web UI 可以共享一份基础配置，再叠加各自的界面插件和参数；个人配置则位于最后一层。这样，部署方不必复制整棵配置树，只需要对指定插件做替换。不过这里也有一个需要留意的细节：配置补丁替换的是目标插件的整个 config，不是深度合并。如果只写一个新字段，原有的 API Key、基础地址或其他参数可能会一起消失。它很明确，但并不一定符合初次使用者的直觉。
项目还允许在 YAML 中通过 !!js 读取环境变量和运行时表达式，例如从 DEEPSEEK_API_KEY 获取密钥。 配置只引用凭据名称，密钥在实际调用时解析。Web UI 会把密钥写入 $DSH_HOME/.credentials.yaml，而环境变量和 .env 可作为自动化或本地开发中的回退来源；密钥不应直接写入 cordis.yml 或进入会话日志。
Agent Loop
不是一个循环，而是一套交通规则
许多早期 Agent 项目的核心代码可以简化成几行：把消息发给模型，如果模型返回工具调用，就执行工具，再把结果发回模型，直到模型输出文本。DeepSeek Harness 当然也做这件事，但它把这个过程拆成了严格的生命周期。
一次用户输入会开启一个 Turn，一个 Turn 中可以包含多个 Step；一个 Step 对应一次模型请求及其后续工具执行。请求前，系统会组装稳定的系统提示词、当前运行环境、工具 schema 和会话消息；请求后，模型的流式 chunk、完整消息、工具调用、工具结果和结束原因都会进入事件流。