今天凌晨，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_rep