今天凌晨, DeepSeek V4 Pro 正式版发布,引发热潮。现在,半天过去, DeepSeek Harness(开发者预览版)也来了!
当然,这并不意外,毕竟该项目之前已经铺垫了很久了,比如 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、完整消息、工具调用、工具结果和结束原因都会进入事件流。
上述丧尸射击游戏执行了 3 turn,127 setp
工具也不是「拿到函数名就调用」。它会经过前置策略、不可逆的安全守卫、实际执行、后置处理、内容整理和结果通知。允许或拒绝、超时、重试、指标统计、附加上下文,都可以从流水线的不同位置接入。工具可以声明某类参数下的调用是并发安全的,调度器便会让连续的只读任务并行;一旦碰到修改状态或无法确定安全性的调用,就把它当作屏障,等待前面的任务结束后独占执行。
这种设计看起来有些像在一条乡间小路上安装航空管制系统,但当 Agent 开始同时搜索十个文件、运行测试、接受用户追加指令,并且还要允许随时取消时,这些规则很快就会从「过度设计」变成「事故调查报告里最想早点拥有的东西」。
它还认真处理了运行中消息的去向。用户在 Agent 工作时发送的新内容,可能是下一轮任务,也可能是对当前工作的转向指令。系统区分排队消息、注入上下文和 Steering,并通过回执确认某条转向指令是否真正进入了某次模型请求。换句话说,它不只关心「消息收到了」,还关心「模型究竟在哪一步看到了它」。
Session Log
整个系统真正的权威来源
DeepSeek Harness 另一个值得关注的设计是 Session Log。
项目规定,凡是模型看见的内容,都必须能够从日志中重建。用户消息、运行环境上下文、模型请求信息、流式输出、工具调用和结果、压缩事件、权限切换、取消原因,都会以事件形式进入追加式会话流。界面、持久化、恢复、Fork、遥测和回放,不应该各自维护一份「差不多正确」的状态,而应从同一个事件源派生。
这项原则解决了 Agent 系统里一个非常棘手的问题:当一次任务出错时,我们究竟能不能知道模型当时看到了什么?
如果系统只保存最终聊天文本,许多关键因素会丢失。也许模型请求前刚刚注入了工作区状态,也许工具结果被裁剪过,也许系统自动切换了模型路由,也许用户在流式输出中途改变了方向。 DeepSeek Harness 会在请求边界保存足以重建消息的记录,原始流式 chunk 也会保留,以便界面和回放维持一致。
会话持久化本身仍然是插件。项目提供 JSONL 和 SQLite 等后端,查询能力可以优先访问实时会话,也可以通过 SQLite 全文检索历史记录。Resume 会沿用原会话继续工作,Fork 则从一个确定的历史边界派生新会话。对开发者而言,这能为调试、评估、审计和自动化提供了统一基础。
从一个 Agent 到一群 Agent
DeepSeek Harness 已经内置了多种子智能体和工作流能力。
主 Agent 可以把任务委派给子 Agent,子 Agent 可以是全新创建的实例,也可以从已有会话的完成边界 Fork,或者通过 ACP 连接外部子进程。
上述丧尸射击游戏创建了 5 个并行执行的子智能体
这里的作用域设计很重要。每个 Agent 拥有自己的上下文层,可以看到特定的工具、提示词和命令。某个子 Agent 可以被限制为只做搜索和分析,另一个则被允许修改文件。注册在 Agent 作用域里的能力会随 Agent 生命周期自动清理,不必依赖全局名称约定维持隔离。
工作流则更进一步:它允许用脚本驱动多智能体编排,把多个子任务、结构化输出和继续执行连接起来。项目同时提供目标、计划、待办事项和后台任务,它们并不是四个名称相近的 UI 小组件,其实是不同生命周期的协作状态。计划模式记录当前协作阶段,目标可以跨同一会话持续存在,待办事项为模型提供轻量任务清单,后台任务则负责管理仍在运行的实际工作。
这说明 Harness 想覆盖的不只是「一问一答式编程」。它希望支持长任务、并行调查、自动化运行和外部系统协调。至于模型能否稳定驾驭如此多的机制,是另一场测试;至少框架先把方向盘、仪表盘和刹车做了出来。
Web、TUI、Headless 与 SDK
面向普通用户,项目推荐 Web UI,默认监听 http://127.0.0.1:3080。它提供对话、会话侧栏、权限选择、计划模式、工具卡片和工作区交互。
Web UI 还提供了四种 Agent 预设模式。它们并非四套彼此独立的 Agent,也不只是改变提示词风格,而是基于同一套 Harness 宿主,为当前会话装配不同的工具、提示词和运行时能力:
标准模式:功能最完整的通用编码 Agent,提供文件编辑、Shell、文件与网页检索、Skills、计划、目标、子 Agent 和工作流,适合绝大多数日常开发任务;
PTC 模式:保留标准模式的全部能力,同时通过 Code Mode SDK 向模型呈现工具。模型可以编写一段 TypeScript 程序,在一次 run_code 中组合多步操作,减少模型与工具之间反复往返的开销,更适合调用链较长的复杂任务;
极简模式:只提供持久 Bash 与 str_replace_editor 两项工具。较小的工具集合减少了选择和上下文负担,适合路径明确、希望 Agent 直接动手的编码任务;
创造模式:在标准模式之上加入 Cordis 运行时检查、临时插件实验和 Agent preset 创作指导。Agent 不仅可以使用现有工具,还能探索并重新组合自己的运行时,进而创建新的自定义预设。由于它能够运行模型编写的插件代码,这是一个面向高级用户的高信任模式。
这组预设或许是「一切皆插件」最直观的产品化表达:底层的模型路由、会话持久化、沙箱和审批仍由共享宿主提供,预设只决定一个 Agent Context 中具体装入哪些能力。同一个 Web UI,因此可以从双工具的极简 Agent,切换成能够编排子 Agent 的标准模式,甚至进一步变成可以改装自身的创造模式。
举个例子,这里我们在创造模式下,让接入了 DeepSeek V4 Pro 的 DeepSeek Harness 创建了一个官方 Web UI 没有的「三栏模式」:
Web UI 之外,TUI 则面向喜欢留在终端中的开发者。
Headless 模式适合脚本和 CI:它接受一个任务,等待 Agent 完全停稳,输出最后一条有效回复后退出。如果程序需要结构化事件和持续控制,则应使用 ACP 或 JSON-RPC/Python SDK。
自动化方面,项目提供 ACP 服务和 JSON-RPC 入口。Python SDK 驱动随附的 JSON-RPC 运行时,让 Python 应用可以启动会话、发送任务、接收通知,而不必直接嵌入 Node 内核。仓库还包含 Code Mode、自指 Cordis、MCP 记忆服务等示例。
值得注意的是,这些入口并不是四套各自演化的 Agent。它们共享核心能力模型、会话事件语义和大部分基础插件,但并非简单替换一层 UI,而是通过不同 bundle 组装出 Web、一次性任务和自动化服务等产品形态。这正是「一切皆插件」最直观的成果。
Agent 可以检查甚至改装自己
DeepSeek Harness 还提供了一组自指 Cordis 工具。它们不会进入标准、PTC 或极简模式,而是通过 Web UI 中的「创造模式」作为明确的高级入口提供。选择这一预设后,Agent 可以检查当前运行时的插件树,并动态挂载或卸载临时插件。
这听上去有点像让汽车在高速公路上给自己换发动机,因而项目没有默认打开它。它适合研究或高级自动化场景:模型可以临时编写事件监听器、注册新工具、提供一个服务,再在任务完成后卸载。
自修改式 Agent 很容易沦为概念演示,但 Harness 至少把它放进了已有插件生命周期中。动态插件仍然运行在 Cordis 的 Context 和 Effect 机制下,注册项有明确的清理路径。
它还远谈不上安全无忧,却展示了这套架构真正想抵达的地方:智能体不只使用能力,也能在受控边界内重新组合自己的运行时。
Cordis 背后的设计,可以参考官方同步发布的论文《A Programming Paradigm for Spatiotemporal Composability》:
论文地址:https://github.com/cordiverse/paper
安全策略
编程智能体一旦获得文件系统和 Shell 权限,就可以修改代码、安装依赖、启动进程,甚至触碰工作区之外的主机环境。 DeepSeek Harness 显然把这件事当作基础架构问题,而不是在界面上增加一个确认弹窗便草草收工。
项目默认采用 workspace-write 模式,将命令执行和文件修改限制在当前工作区及允许的临时目录中,并配合 ask 审批策略处理需要扩大权限的操作。更宽松的 danger-full-access 模式也存在,但必须由部署方明确选择;它不会被包装成一个看似无害的兼容选项。
工具调用还要经过前置策略、单调安全守卫、执行包装和后置处理。被守卫拒绝的操作不能被后续插件重新放行;需要扩大权限的命令必须说明原因,并通过审批机制重试。文件系统、Bash 和子进程共享同一套沙箱策略,避免出现「命令受限制,但文件工具可以绕过去」的割裂边界。
更值得肯定的是, DeepSeek Harness 采用「失败关闭」原则。如果系统无法确认隔离机制真正生效,它会拒绝执行,而不是悄悄退化为无保护运行。权限切换、审批请求、工具参数、执行结果和取消原因也会进入 Session Log,为事后审计和问题复现保留依据。
这套设计并不能消除智能体执行本地操作的全部风险,但它体现了一种难得的工程态度:安全是贯穿配置、执行、审批、日志与恢复机制的系统约束。模型可以提出行动,真正决定行动能否发生的,仍然是 Harness。
DeepSeek 想做的不止是「又一个 Codex」
如果只看 Web UI 或 TUI,很容易把 DeepSeek Harness 理解为 DeepSeek 版本的 Codex、Claude Code 或其他编程助手。但从仓库结构看,它的目标明显更底层。
默认应用当然重要,它让开发者可以直接获得一个能读写项目、运行命令、规划任务和调用子 Agent 的工具。但真正占据项目中心的,是可替换的能力接口、事件驱动的生命周期、权威会话日志和声明式组合。换言之,成品 Agent 更像这套 SDK 的第一位客户。
这也给 DeepSeek 的模型生态补上了一块过去不够显眼的拼图。模型决定智能上限,Harness 决定这些智能如何进入真实环境,如何使用工具,如何保留状态,又如何在权限边界内工作。对于企业开发者而言,后者往往比聊天窗口多几个按钮更重要,因为它决定了系统能否被审计、扩展、替换和长期维护。
DeepSeek Harness 现在还远没有到「安装完成,一切丝滑」的阶段,但它已经展示出一套相当完整的技术判断:Agent 不应该是一段越来越臃肿的循环,而应该是一组可以组合、观察和替换的能力;会话不应该只是聊天记录,而应该是运行事实;工具不应该只是函数,而应该同时拥有策略、日志和呈现协议。
因此, DeepSeek Harness 最值得关注的,并非它今天能否替代你正在使用的编程助手,而是它把 DeepSeek 对 Agent 工程的答案公开到了什么程度。
本文来自微信公众号“机器之心”(ID:almosthuman2014),作者:关注DSH的机器之心
