同一个模型，换套马具，Agent 能差一截
8 月 13 日晚上，DeepSeek 把 DeepSeek Harness（仓库里的命令名是 dsh）以开发者预览的形式开源了。协议是 MIT，仓库在 deepseek-ai/deepseek-harness。
同一天早上，DeepSeek-V4-Pro-0813 已经先上了 App、Web 和 API。1M 上下文、最高 384K 输出，官方自己报的 Agent 基准里，Terminal Bench 2.1 是 87.9，DeepSWE 是 62.7，Toolathlon-Verified 是 74.1，DSBench-FullStack 是 71.1。
很多人第一反应是：DeepSeek 终于有自己的 Claude Code 了。
这个判断只对了一半。
Claude Code、Codex、Cursor 是成品。你打开就能干活。DeepSeek Harness 的定位不是这个。官方 README 第一句写得很克制：它是一个开源的 agent harness，架构原则就一句话——everything is a plugin，一切皆插件。
它不是新模型，也不是又一个 API 客户端。它做的事是：把模型接到文件系统、终端、网页、代码工具和其他 Agent 上，再把上下文、工具调用、任务执行组织起来。
用更工程的话说：模型负责想下一步，Harness 负责让这一步在真实环境里发生，并且决定它能不能发生。
这篇文章不写安装教程合集，也不写「吊打谁」的对照表。那些东西第二天就会过期——官方自己用大写字母写了，这是 Developer Preview，THERE WILL BE COMPATIBILITY-BREAKING CHANGES。
我想讲清楚三件事：Harness 这个词在 2026 年到底指什么；DeepSeek 这套实现把哪些长期被藏在产品里的决策摊开了；以及作为做 Agent 的人，哪些部分值得学，哪些部分现在还不能当生产答案。
事实来自官方仓库、官方架构文档，以及同日发布的预印本 A Programming Paradigm for Spatiotemporal Composability。二手解读里对不上官方原文的，我不用。
一、先把词说准：Harness 不是框架，也不是聊天框
Harness 这个词本身就比「框架」准。
马具、线束、约束装置——本意都是同一件事：把一股力量接到能干活的机构上，同时不让它脱缰。
落到 Agent 上，Harness 管的是模型输出之后的全部工程问题：
模型能看见哪些工具；系统提示词怎么拼；上下文满了怎么压；工具结果怎么回灌；命令跑在哪一层隔离里；失败了是重试、取消，还是把问题交还给人；用户在模型跑到一半时插进来的那句话，到底算新任务，还是对当前工作的转向。
这些问题，2024 年大家还觉得是「产品细节」。2025 年到 2026 年，它们已经决定同一个模型在不同产品里的体感差距。
传统聊天模型吃进一个问题，吐出一段文本。Coding Agent 不是这样。它要反复走完「理解任务 → 找文件 → 改代码 → 跑命令 → 看结果 → 再改」这条环。环上任何一环松了，模型再强也只是在正确的方向上更自信地犯错。
所以行业里慢慢收敛出一句不太好听、但很管用的话：
Model + Harness = Agent。
模型给智能的上限。Harness 给智能一个身体，再给这具身体一套不能被模型一句话掀翻的规矩。
上图不是营销公式。它是在提醒一件很容易被忽略的分工：模型决定「下一步想做什么」，它看不见真实文件系统，也执行不了终端命令。文件系统、沙箱、审批、会话恢复，全在模型外面。
DeepSeek 这次把外面这一层开源了。而且开源的方式很明确——不是把一个锁死的桌面产品丢出来让你逆向，而是把这一层拆成可以替换的插件树。
二、时间线比发布会更能说明意图
这件事不是 8 月 13 日晚上突然出现的。
2026 年 5 月，DeepSeek 对外招 Agent Harness 产品经理和 Agent Harness 研发工程师。岗位描述里写得很直：除模型本身以外的所有工作，都属于 Harness。产品经理那一侧，点名要深度用过 Claude Code、Cowork、Codex、Cursor、OpenCode、GitHub Copilot、Manus、OpenClaw、Hermes。研发那一侧，要的是上下文管理、工具调用、文件 I/O、终端执行、测试反馈闭环。
资深研究员陈德里当时公开说过，内部在组一个新的 Harness 团队，方向就是 Code Harness。
7 月 31 日，V4 Flash 正式版更新日志里有一行很容易被滑过去的话：公开 Code Agent benchmark 用的测试框架，是「即将发布」的 DeepSeek Harness 极简模式。
也就是说，Harness 在对外之前，已经先给自家模型当过考场。这很重要。很多团队是先做产品，再补评测环境。DeepSeek 反过来：先用一套极简工具集把模型的 Agent 能力测清楚，再把这套环境本身变成产品。
8 月 13 日上午，V4-Pro-0813 转正。下午到晚上，Harness 开发者预览开源。
把这两次更新叠在一起看，逻辑是清楚的。前两年 DeepSeek 的主战场是模型：训练效率、开源权重、API 价格。V4 Pro 把智能往上推一档，Harness 负责让这档智能进到代码库和终端里连续工作。
基础模型公司不再满足于卖 API。它们开始争模型和真实计算环境之间的那一层。Anthropic 有 Claude Code，OpenAI 有 Codex，DeepSeek 现在有一套自己定义的执行层，并且把定义公开了。
公开，才是这次和「再做一个编程助手」的真正差别。
三、它现在能跑成什么样
先把能核实的入口说清楚，避免后面讨论悬空。
官方推荐的最快路径：装好 Node.js，然后：
npx @deepseek-ai/dsh webWeb UI 默认听 http://127.0.0.1:3080。这是本机服务，不是把你的仓库交到云上。源码安装、插件开发和架构说明在仓库的 docs/development.md、docs/architecture.md。面向 Agent 自己读仓库的约定写在 AGENTS.md。
它现在至少有几类入口，而且官方强调这些入口不是四套各自演化的 Agent：
- Web UI：给人直接用的工作台
- TUI：留给愿意待在终端里的人
- Headless：适合脚本和 CI，吃进一个任务，等 Agent 停稳，打出最后一条有效回复后退出
- ACP、JSON-RPC，以及驱动 JSON-RPC 运行时的 Python SDK：给其他程序用
共享的是能力模型、会话事件语义和大部分基础插件。换的是组装方式。Web 是一种 bundle，一次性任务是另一种，自动化服务又是一种。
功能面上，公开资料和架构文档对得上的能力包括：项目管理、长任务协作、多 Agent 编排、上下文管理、联网搜索、Skill、计划、目标、待办、后台任务。你可以把一个代码目录交给它，让它读结构、改文件、跑测试，再根据报错继续改，而不是每一步把 diff 和日志复制回聊天框。
主 Agent 可以把活拆给子 Agent：一个搜，一个改，一个测，再汇总。这不是演示用的「多角色扮演」，是运行时里的委派。
有两件现在不能说满的话，先钉死。
第一，它不是生产就绪。官方自己把兼容性破坏写进了 README。用来评估、拆架构、写插件可以；用来绑进核心流水线，现在还早。
第二，框架免费，模型不免费。MIT 协议覆盖的是 Harness 本身。跑起来要接模型供应商。官方文档除了 DeepSeek API，也覆盖其他供应商和自定义 OpenAI 兼容端点。模型适配器本身就是插件。
所以「只能配 DeepSeek 模型」这句话，是错的。更准确的说法是：默认组合会偏向自家模型，但架构没有把你锁死在这一家。
四、一切皆插件，不是口号，是替换权
Agent 项目写到后期，最难受的不是「再加一个工具」，是「我想换掉中间某一层，发现它和循环焊在一起」。
换存储，要改会话恢复。换沙箱，要改工具执行。换模型协议，要改提示词组装。最后你不是在扩展系统，你是在和系统的历史决定谈判。
DeepSeek Harness 把这件事设成第一原则：运行中的 dsh，本质是一个 Cordis Context。模型适配器、工具注册、Session Log，连 Agent Loop 本身都是插件。每一样都可以从配置里换掉。
官方架构文档给了一张很实用的对照表，我按工程含义转写一遍：
- 加模型供应商：在
ctx.llm上注册适配器 - 加模型能看见的能力：注册到
ctx.tools，schema 会进入提示词组装 - 让某一个会话拥有不同能力集：组合 Agent preset；需要隔离的服务行要带
isolaterealm - 加 Shell：注册
ctx.shell后端，本地实现通过ctx.subprocess拉起进程 - 加持久终端：
ctx.terminals后端，再加对应工具包 - 加人能直接发的命令：注册到
ctx.commands，不必走一轮模型 - 加后台工作：注册到
ctx.jobs - 加文件系统或文件策略：注册
ctx.fs，或听fs/事件 - 限制子进程：用
ctx.sandbox后端，消费者在 spawn 前包一层 argv - 拦截一次请求、一次工具或一轮 turn：听
agent/或tools/事件 - 给模型加一段上下文：
agent.inject()，落在下一次被接纳的请求里 - 做 UI：驱动
ctx.agents，从session/event渲染 - 做持久会话状态：扩展
SessionEventMap，从日志回放
这张表比任何「插件化」宣传都有用。它回答的是：你想动哪一层，该去注册什么，不该去改循环。
核心包的边界也切得很死。
packages/core/ 里是 Session、System Prompt、Tools、Agent、Agent Loop。它们只回答最基本的问题：会话是什么，系统提示词怎么拼，工具怎么注册和调用，Agent 怎么创建，一轮对话怎么从用户输入走到模型请求、工具执行和最终回答。
外面再挂能力包：packages/llm/ 管适配器和流式输出；shell/、subprocess/、terminal/ 管一次性命令、进程树和持续终端；fs/ 管读写、编辑、搜索和策略；lsp/ 接语言服务器，让 Agent 不只会 grep；web/ 管搜索和抓取；skill/ 管可复用技能；subagent/ 和 workflow/ 把单个 Agent 扩成可委派、可编排的系统。
再往外，计划、目标、待办、后台任务、上下文压缩、会话查询、会话标题、凭据、用户设置、审批、遥测，同样拆成独立能力。
这种切法有代价：仓库早期会显得大，包很多，概念密度高。换来的是一件更贵的东西——接口、实现、消费者可以分开换。
文档里用 Bash 举过例子。接口定义「执行命令」是什么；本地实现负责真正创建进程；面向模型的工具包负责把这项能力变成模型能懂的 schema 和结果。以后本地 Shell 要换成远程容器、云端沙箱或企业执行平台，理论上只换实现层，不必重写模型工具，也不必重写 Agent Loop。
做内部 Agent 平台的人，对这句话会有体感。你们真正想要的往往不是「官方的那套文件工具」，而是「文件工具这个接口，后面能接公司自己的执行平面」。
五、Cordis 解决的不是美化插件，是装得上还卸得下来
「一切皆插件」如果只做到「能装」，那和现在满地的 skill 市场没有本质差别。难的是卸。
普通插件系统里，卸载经常等于「配置里删一行，然后重启进程」。VS Code 就是典型。论文里写过一组可以核对的观察：截至 2026 年 6 月 9 日，VS Code Marketplace 排名前 100 的扩展里，87 个包含可执行代码，一旦激活就无法在运行时单独卸载，禁用或删除后必须重启整个扩展宿主。
聊天机器人重启一下，用户顶多觉得你掉线了。Agent 重启一下，正在跑的长任务、检索缓存、已经拉起来的子进程、还连着的 MCP，可能一起没了。
DeepSeek Harness 底下的 Cordis，就是冲着这个问题去的。实现在 cordiverse/cordis。设计写在同日放出的预印本 A Programming Paradigm for Spatiotemporal Composability（Draft of August 13, 2026，仓库 cordiverse/paper）。论文自己声明这是仍在修订的预印本，引用要以最新版为准。
论文把动态组合拆成两个正交维度：
时间可组合性：组件卸掉时，它留在共享环境里的副作用要能被完整撤回，系统回到装上它之前的状态。
空间可组合性：组件能声明自己依赖谁，依赖拓扑变了，相关组件能跟着激活或停掉。
对应到运行时，是两套机制。
第一套是可撤销效应（revertible effects）。对上下文的每一次修改，都带着一个逆操作。加载时把逆操作叠成撤销链，卸载时反向执行。不是靠作者在文档里写一句「请在 deactivate 里记得关连接」。
第二套是反应式余效应（reactive coeffects）。组件声明自己需要哪些服务。依赖齐了才进入 ACTIVE，缺一个就保持 INACTIVE。提供者走了，依赖者先停、先把自己的 effect 撤回，提供者再完成卸载。循环依赖不会在运行时卡死成死锁，相关组件会停在未激活——这是声明写出来就能看出来的静态事实。
官方 README 对 Cordis 的概括更短：插件向共享 Context 贡献服务、类型化事件和可撤销副作用。
翻译成做 Agent 的人能用的话：
你加一个「监听某个内部群」的能力。它会注册工具、拉起长连接、往会话里灌消息。十分钟后你发现这个能力写坏了。你要的不是杀整个 Agent 进程，也不是只把工具 schema 从下一轮提示词里拿掉、却留下一条还在推消息的 websocket。你要的是：工具、连接、监听器、临时文件，顺着撤销链一起消失。
这就是「卸得下来」四个字的工程含义。
论文还把「自我演化的 Agent Harness」列为重要场景：未来的运行时可能要管理工具、执行环境、权限、记忆和多智能体协作，甚至由模型自己持续生成和部署新组件。如果每次修改都重启，状态会丢；如果修改出错，还得能回到改之前。
注意边界。论文把自我演化写成验证方向，不是在宣布 DeepSeek Harness 今天已经能稳定地自己改自己。创造模式提供了自指工具，后面单独讲。现在如果有人把它写成「DeepSeek 发布了会自我进化的 Agent」，那是把研究方向说成了产品能力。
Cordis 也不是实验室里刚画出来的图。公开材料里，这套思路已经在 Koishi 聊天机器人框架上跑过多年，社区插件量到了四千以上。Koishi 验证的是插件生命周期，不是 Coding Agent。能说明的是：可撤销插件这套语义，至少在一个高插件密度的生产系统里活下来了。换到 Agent 运行时，压力会更大——工具会改磁盘、会拉子进程、会在模型循环中途被换掉。这条路值不值得走，要看后面几个月的破坏性变更怎么收。
但对做 Harness 的人，论文里有一句比产品发布更有用：提示词组合解决「模型下一轮看见什么」；进程组合解决「操作系统收回什么」；组件组合解决「同一个进程里，一块能力怎么出现、怎么消失，而不把旁边的带走」。
现在通行的 Agent 工程，前两层已经很厚。第三层几乎还是空的。DeepSeek 把第三层做成了开源内核。
六、四种预设：同一套宿主，装进不同的脑子和手
Web UI 里能看到标准、PTC、极简、创造四档。它们不是四套彼此独立的 Agent，也不只是换一套人设提示词。
共享宿主继续提供模型路由、会话持久化、沙箱和审批。预设只决定：当前这个 Agent Context 里，具体装哪些工具、哪些提示词、哪些运行时能力。
标准模式是功能最完整的通用编码 Agent。文件编辑、Shell、文件与网页检索、Skills、计划、目标、子 Agent、工作流，都在。绝大多数日常开发任务走这一档。
PTC 模式保留标准模式的全部能力，同时通过 Code Mode SDK 把工具呈现给模型。模型可以写一段 TypeScript，在一次 run_code 里组合多步操作。目的很具体：少让模型和工具来回握手。调用链一长，传统 function calling 的税就高——每一步都要再进一次模型，上下文被工具结果反复污染，延迟和费用一起涨。PTC 把「多步工具编排」从模型对话里挪到一段程序里。这不是新发明，但做成一档可切换预设，说明他们把「工具怎么被模型看见」也当成了可替换层。
极简模式只留两件工具：持久 Bash，和 str_replace_editor。工具越少，选择负担越小，上下文越干净。路径明确、你就是希望它直接动手时，这一档更合适。V4 Flash 的公开 Code Agent 评测，用的就是这一档。评测环境和产品环境拆开，是件正确的事。工具一多，benchmark 测到的就不只是模型，还有提示词和工具选择策略。
创造模式在标准模式之上，加入 Cordis 运行时检查、临时插件实验、Agent preset 创作指导。Agent 不但能用现有工具，还能查看当前插件树，动态挂载或卸载临时插件，甚至运行模型自己写的插件代码。官方把它标成面向高级用户的高信任模式。它不进入标准、PTC、极简的默认组合，必须你自己选。
这四档放在一起，才看得出「一切皆插件」的产品形状。同一个 Web UI，可以从双工具的极简 Agent，切到能编排子 Agent 的标准模式，再切到能改装自身的创造模式。切的不是皮肤，是能力集。
创造模式值得单独泼一点冷水。
让 Agent 在高速公路上给自己换发动机，听着很酷。工程上它意味着：模型生成的代码会进入和官方插件同一套生命周期。Cordis 的 Context 和 Effect 能给注册项一条清理路径，这比「eval 一段脚本就完了」强。但它消不掉高信任本身。能改运行时的 Agent，攻击面从「错误地调用已有工具」扩到了「给自己注册新工具」。所以它被单独放在一档，而且默认不开，这个克制是对的。
企业里如果有人要把创造模式直接接到生产工作区，先问三个问题：插件代码跑在谁的权限里？卸载失败怎么办？这段自改装有没有进入 Session Log，能不能整段回滚？
答不上来，就别开。
七、Agent Loop 不是 while True，是一套交通规则
很多早期 Agent 项目的核心，真的可以压成几行：把消息发给模型；如果返回工具调用，就执行；把结果发回去；直到模型开始说人话。
DeepSeek Harness 当然也做这件事。它把过程拆成了严格的生命周期。
一次用户输入打开一个 Turn。一个 Turn 里可以有多个 Step。一个 Step 对应一次模型请求，加上这次请求引发的工具执行。Turn 在第一份输入被认领前打开，在「不再欠任何一步」时关闭。
请求前，系统组装稳定的系统提示词、当前运行环境、工具 schema、会话消息。请求后，流式 chunk、完整消息、工具调用、工具结果、结束原因，全部进入事件流。
工具也不是「拿到函数名就调用」。它会经过前置策略、不可逆的安全守卫、实际执行、后置处理、内容整理、结果通知。允许或拒绝、超时、重试、指标、附加上下文，都可以从流水线不同位置接入。
调度上有一条很关键的规则：工具可以声明某类参数下的调用是并发安全的，调度器就让连续的只读任务并行；一旦碰到修改状态、或无法确定安全性的调用，就把它当作屏障，等前面的任务结束再独占执行。
这套东西在「单 Agent、单工具、单用户盯着」的演示里显得重。等 Agent 同时搜十个文件、跑测试、接受用户追加指令、还要允许随时取消时，这些规则会从「过度设计」变成事故调查里最想早点拥有的东西。
它还认真处理了运行中消息的去向。用户在 Agent 工作时发来的新内容，可能是下一轮任务，也可能是对当前工作的转向。系统区分排队消息、注入上下文，和 Steering，并且用回执确认：某条转向指令是否真正进入了某次模型请求。
这句话值得停一下。
很多产品只做到「消息收到了」。模型当时在跑一轮已经组装好的请求，你后发的那句「别改测试，先改实现」，可能要等这一轮结束才被看见，甚至被下一轮当成全新任务。DeepSeek Harness 至少把「模型究竟在哪一步看到了它」做成了事件，而不是靠前端动画假装已经听进去了。
做长任务 Agent 的人知道，这个细节比再加一个子 Agent 更值钱。
八、Session Log 才是系统的权威来源
如果只能从这套设计里拿走一个概念，我建议拿走这个：会话的权威来源不是内存里的 messages 数组，是一条仅追加的事件日志。
模型看见的系统提示词、推理过程、工具调用、子 Agent 调度、上下文注入、权限切换、审批请求、工具参数、执行结果、取消原因，都进 Session Log。恢复、分叉、检索、回放，走同一条事件流。
这和「把聊天记录存进数据库」不是一回事。
聊天记录存的是对人可见的对话。Session Log 存的是模型实际经历过的世界。两边经常对不齐。你在界面上看到一句「我去跑一下测试」，日志里可能是三次失败的命令、一次被守卫拒绝的路径穿越、一次压缩后的上下文替换。没有后半段，你没法解释 Agent 为什么突然改了策略。
它也直接决定调试方式。Trajectory 视图不是装饰。你要看的是：这一步模型看见了哪些工具 schema，注入的上下文是哪一段，子 Agent 带了什么能力集出去，回来的结果有没有被截断。
做内部平台时，我见过太多系统把「可观测」理解成打几行 info 日志。真出事的时候，你需要的是能从日志重建当时的模型输入。DeepSeek Harness 把这件事做成了核心包，而不是事后补的 dashboard。
有一个连带约束：密钥不能进这条日志。
配置里可以通过 !!js 读环境变量和运行时表达式，例如从 DEEPSEEK_API_KEY 取密钥。配置只引用凭据名，真正调用时再解析。Web UI 把密钥写到 $DSH_HOME/.credentials.yaml。环境变量和 .env 是自动化或本地开发的回退。官方口径很明确：密钥不要写进 cordis.yml，也不要进会话日志。
仅追加日志一旦脏了，分叉和回放会把秘密一起复制出去。这条规矩看起来像运维细节，其实是安全设计。
九、安全被当成架构问题，不是弹窗问题
编程智能体一旦拿到文件系统和 Shell，就可以改代码、装依赖、起进程，也可以摸到工作区以外的主机环境。
DeepSeek Harness 没有把这件事收成界面上的一个确认框。
默认是 workspace-write：命令执行和文件修改限制在当前工作区以及允许的临时目录。需要扩大权限，走 ask 审批，而且必须说明原因，再通过审批机制重试。更宽松的 danger-full-access 也存在，但必须由部署方明确选择，不会被包装成一个看起来无害的兼容选项。
工具调用经过前置策略、单调安全守卫、执行包装、后置处理。被守卫拒绝的操作，不能被后续插件重新放行。文件系统、Bash、子进程共享同一套沙箱策略，避免出现「命令被限制，文件工具却能绕过去」这种割裂边界。
还有一条失败关闭原则：如果系统无法确认隔离机制真正生效，它拒绝执行，而不是悄悄退化成无保护运行。
这套设计消不掉本地执行的全部风险。没有任何 Harness 能消掉。模型仍然可能在工作区里做出你事后才后悔的修改；审批仍然可能被点成习惯性放行；创造模式仍然能运行模型写的插件。
它体现的是分工：模型可以提出行动，真正决定行动能否发生的，是 Harness。
单调守卫这条尤其值得学。很多插件系统允许后面的中间件把前面的拒绝改成允许，「灵活」得像没设防。DeepSeek 把拒绝做成不可回放。权限只能收，不能在管道后半段偷开。这和最小权限是一套思想。
企业落地时，还是要把默认档和你自己的威胁模型对一下。workspace-write 防的是越出工作区，防不住工作区里的破坏性操作，也防不住模型把密钥写进它够得着的文件。审批如果没有对象、没有过期、没有审计字段，最后会变成「一路点允许」。这些不是 DeepSeek 没做，是任何本地 Agent 都要自己补的运营层。
我在这个系列里反复写过同一句话：安全必须落在架构层，不能靠模型聪明，也不能靠上游会帮你过滤。DeepSeek Harness 这次至少把架构层的钩子留在了明处。
十、cordis.yml：Agent 变成一份可以审查的装配清单
插件化最后要落到一份人能读的配置上，否则「一切皆插件」只存在于作者脑子里。
cordis.yml 列出插件名称、稳定 ID 和参数，决定当前 Agent 究竟拥有哪一组能力。同一套代码，换一份配置，就能组装出完全不同的产品形态：
- 加上 DeepSeek LLM 适配器、文件系统、Bash 和 TUI，得到终端里的编程智能体
- 把交互换成 Web 插件，得到浏览器工作台
- 走 Headless，得到「吃任务、打答案、退出」的一次性工人
- 换成 ACP 或 JSON-RPC 前门，得到其他程序可以驱动的服务
配置支持覆盖层。TUI 和 Web UI 可以共享一份基础配置，再叠各自的界面插件。个人配置在最后一层。部署方不必复制整棵配置树，只对指定插件做替换。
这里有一个不那么直觉、但非常重要的细节：配置补丁替换的是目标插件的整段 config，不是深度合并。 你只写一个新字段，原有的 API Key、基础地址或其他参数可能一起消失。
这是明确，不是方便。明确的好处是：打开 diff 就能看出这个插件现在到底以什么参数运行，不会有「默认值在另一层、你的覆盖在这一层、实际生效的是某次深合并」这种幽灵状态。代价是：第一次改配置的人很容易把自己改停。
做内部平台时，我反而更接受这种「整段替换」。Agent 配置一旦开始深合并，出事时没人说得清模型为什么连到了旧的 base URL。审查一份完整的插件列表，比审查一棵三层覆盖树要容易。
把 Agent 写成配置，还有一层组织上的好处。权限、工具集、模型路由，可以进代码评审。谁给这个 Agent 开了 danger-full-access，谁把创造模式配进了默认会话，都会留在 git 历史里。这比写在某个隐藏页面的开关里健康。
十一、它和 Claude Code、Codex 到底差在哪
对使用者，体感会像：又一个能进仓库改代码的本地 Agent。对开发者，差别在替换权。
Claude Code、Codex CLI 是面向终端用户的成品。它们把模型、工具、权限、界面、升级路径收成一个产品决策。你要的是尽快把活干完，不必知道循环怎么写。
DeepSeek Harness 更偏底座。默认 Web UI 和默认工具集，只是官方给出的一种组合。官方 FAQ 的口径也是这个：后者是成品应用，前者强调每一层都能被替换和重组。
所以「DeepSeek 版 Claude Code」这个叫法，用来形容用户入口可以，用来形容架构不行。
还有一个常被忽略的差别：成品 Agent 的演进节奏由一家公司的产品路线决定；开源 Harness 的演进节奏，会同时被官方破坏性变更和社区插件拉扯。仓库鼓励插件仓库打上 dsh-plugin 主题，问题走 GitHub Discussions。开源当天就能看到社区往这个主题上挂工作流层、侧边栏、浏览器插件、启动器。这是生态信号，不是质量保证。
插件市场一旦起来，安全模型会从「官方工具够不够稳」变成「你装的第三个插件会不会在后置处理里改写工具结果」。DeepSeek 把守卫设计成单调的，就是在给这种未来留后手。但单调守卫防的是「拒绝被改成允许」，防不住「一个看起来无害的插件，在允许的范围内把工作区读走」。
开源 Harness 的供应链问题，会比开源模型更早到来。模型权重大，审核成本高；一个 dsh-plugin 小，审核成本低，装的人多。
十二、作为 Agent 工程师，我会怎么用它，而不是怎么吹它
如果把 DeepSeek Harness 只当成「免费的编程助手」，你会错过真正值钱的部分，也会踩在 Preview 的坑里。
我自己会按四个用途来用，由轻到重。
第一，当对照物，不当信仰。
把你现在的 Agent 运行时摊开，按它的包边界对一下：会话有没有仅追加的权威日志？工具执行有没有不可回放的拒绝？只读和写入有没有调度屏障？用户中途插入的话，有没有回执告诉你模型看见了没有？配置能不能完整审查？
对得上的，留下。对不上的，别急着移植 Cordis。先把缺口写成自己的设计约束。一套还在破坏性变更的预览版，不适合当你们下个季度的技术选型结论。
第二，当评测夹具。
极简模式只有 Bash 和编辑器。这是个干净的实验环境。同一模型、同一任务，分别丢进你们自己的循环、极简模式、标准模式，看的不是谁更能写公众号标题，而是：工具一多，模型是更强了，还是在选工具上浪费步数了；上下文是更完整了，还是被检索结果糊住了。
7 月 31 日那行更新日志已经提示了这种方法：先固定 Harness，再谈模型分数。反过来也成立——先固定模型，再谈 Harness 分数。两头同时变，数字没有解释力。
第三，当插件实验床，尤其是内部执行平面。
如果你们已经有远程沙箱、内部代码搜索、统一密钥、审批流，最值得试的不是把官方 Web UI 推给全员，而是写一个 ctx.sandbox 或 ctx.fs 的内部实现，看接口层是否真的够用。够用，说明这套「接口 / 实现 / 消费者」不是文档幻想；不够用，你也只是提前发现它和你的环境合不上，成本比全面迁移低得多。
第四，创造模式只留在研究会话。
让模型临时挂一个监听器、注册一个工具、做完卸载，用来理解 Cordis 的生命周期，很合适。用来改生产仓库，不合适。高信任模式的正确用法，是把它当成显微镜，不是当成默认工作档。
还有几条我不会做的事。
我不会把 Preview 的 API 写进长期合同。不会在还没读懂配置整段替换规则时，就把个人 cordis.yml 补丁同步到团队。不会在没看 Session Log 的情况下，凭 Web UI 的一句话判断 Agent「已经理解了需求」。不会把社区插件的 star 数当成安全审计。
这些不是对 DeepSeek 不友好。这是对待任何能在你机器上跑命令的软件的正常态度。
十三、它暴露了 2026 年 Agent 工程的真实水位
把 DeepSeek Harness 放回这一年的上下文里，会看见一条比产品更清楚的线。
2023 年大家讨论 Prompt。2024 年讨论 Function Calling 和多 Agent 角色扮演。2025 年讨论上下文工程、MCP、评测。2026 年，竞争滑到了执行层：谁能把模型稳定地接到真实环境，谁能在不重启的前提下改运行时，谁能把一次失败的工具调用解释清楚。
这条线上，DeepSeek 做对了几件不讨巧的事。
它承认 Agent 不是模型的皮肤。V4 Pro 和 Harness 同一天出现，本身就是在说：分数和身体要一起交。
它把循环、会话、工具守卫做成可替换单元，而不是把它们藏进客户端。开源的是定义，不只是可执行文件。
它把「卸插件」当成和「装插件」同级的问题，并且愿意为这个问题配一篇八十多页的预印本。不管你是否接受效应 / 余效应这套形式化，问题本身是真的。Agent 开始自己生成工具之后，重启即丢失会变成不可接受的产品行为。
它把高风险能力单独做成创造模式，而不是默认打开然后在文档角落写一行警告。
它也留下了现在还没交卷的部分。
CLI 作为完整交互界面，和作为启动器，不是一回事。仓库里有 dsh，能拉起 Web、管理插件、跑 headless。社区第一晚就在问：能不能像 Claude Code 那样长期待在终端里看 diff、做审批、切会话。这个问题会决定它先变成开发者框架，还是先变成日常入口。框架和入口可以共存，但默认路径只有一条。
破坏性变更会考验插件生态。MIT 加上 Preview，意味着你今天按文档写的插件，下个月可能要对着新的 Context 形状改。生态要的是稳定缝，不是每周一个新理念。
多模型只是适配器可替换，不等于体验一致。换一个不按 DeepSeek 工具风格训练的模型，标准模式里那一长串工具可能立刻变成负担。极简模式在这里会显得更诚实。
本地工作台也解决不了组织级问题：统一审计、集中策略、跨机器的会话迁移、给不同职级的人发不同的工具集。cordis.yml 提供了装配点，装配点后面的治理，还得你们自己做。
这些缺口不让发布变小。它们只是在提醒：执行层被摊开之后，工作量不会变少，只会从「猜官方客户端怎么写的」变成「你自己得把这些决策做完」。
十四、对内部平台团队，一份能直接用的对照清单
如果你们正在做公司自己的 Agent 运行时，不必等 DeepSeek Harness 稳定。现在就能拿它当评分表。
会话。 有没有一条仅追加、可回放、可分叉的事件流？回放出来的模型输入，能不能和当时一致？密钥有没有从这条流里物理隔开？
循环。 Turn 和 Step 有没有显式边界？取消是取消当前工具、当前 Step，还是整个 Turn？用户中途插入的文本，有没有类型，有没有回执？
工具。 接口和实现是否分离？只读和写入是否在调度层被区分？拒绝之后有没有人能在下游改成允许？
权限。 默认是工作区写，还是主机写？扩大权限是否必须说明原因？隔离不确定时，是失败关闭，还是静默降级？
装配。 Agent 的能力集能不能用一份完整配置描述清楚？这份配置能不能进代码评审？覆盖规则是整段替换还是深合并，团队是否都知道？
多 Agent。 子 Agent 带出去的工具集，是父级的超集、子集，还是另一份白名单？回来的结果以谁的会话日志为准？
自改装。 如果允许模型写插件，生命周期是否走和官方插件同一套撤销链？失败是否停在出事的那一个实例上，而不是把整张工具表一起带走？
评测。 你们有没有一个「极简档」，用来单独看模型，而不是看模型和一堆工具的混合物？
这份清单里任何一条答「没有」，都不意味着你们做错了。很多团队还在第一代 ReAct 循环上赚钱。它意味着：下一次有人提议「我们做一个自己的 Claude Code」时，你知道要做的不是皮肤。
十五、发布之后，真正要盯的不是 star
开源当天仓库 star 涨得很快，我写这篇文章时 GitHub 上已经到了约六万。这个数字能说明注意力，不能说明运行时质量。
更值得盯的是四条更慢的线。
破坏性变更怎么发。 README 已经提前说了会有。看他们是提供迁移说明和配置校验，还是让社区在 Discussions 里对报错。前者是框架，后者是实验田。
极简模式是否继续当官方评测档。 如果以后模型分数都改在标准模式或 PTC 上测，分数会更好看，解释会更差。把评测钉在最小工具集上，是对用户少一点自欺。
创造模式会不会被默认化。 现在它被单独标成高信任，这是对的。一旦被做成「更智能」的默认档，安全模型就会从架构退回提示词。
内部执行平面有没有人真的在换。 如果三个月后社区插件全是皮肤、宠物、侧边栏，而很少有人替换 ctx.sandbox / ctx.fs / ctx.llm，说明大家还是把它当应用。如果开始出现公司自己的实现层，说明这套接口值回票价。
至于「单任务多少钱」「会不会取代某某产品」，现在下结论都早。框架不收费，模型收费；任务成本取决于你选的模型、上下文有多脏、工具往返有多少次。PTC 存在的理由之一，就是承认往返本身是成本。
核心判断
8 月 13 日 DeepSeek 开源的是执行层，不是又一个聊天产品。
dsh是开发者预览，MIT 协议，官方明确会有破坏兼容性的变更。Model + Harness = Agent 这句分工是对的。 模型给上限，Harness 给身体和缰绳。同一模型换一套执行环境，体感可以差一截。
一切皆插件的价值是替换权。 模型、工具、会话、沙箱、Loop、UI 都能从配置组装。目标不是官方 UI 好看，是你能换实现层。
Cordis 真正难的是卸，不是装。 可撤销效应管时间，反应式余效应管空间。自我演化是论文里的方向，不是今天的产品承诺。
四种预设是同一宿主上的不同装配。 标准给人用，PTC 减往返，极简给评测和直接动手，创造给高信任自改装。不要把创造模式当默认。
Session Log 是权威来源。 恢复、分叉、回放、审计，都应该能从同一条仅追加事件流重建。密钥不得进入这条流。
安全默认是工作区写、失败关闭、拒绝不可回放。
danger-full-access必须显式打开。模型提议，系统批准。现在适合对照、评测、试内部实现，不适合当作已冻结的生产底座。 先用它给自己的运行时打分，再决定搬哪些部分。
Agent 的智商不取决于你把哪家模型写进配置，取决于模型走完一步之后，系统还允许世界变成什么样。 DeepSeek 把「允许世界变成什么样」这件事开源了。剩下的工作，还是得自己做。
事实核对：DeepSeek Harness 官方仓库 github.com/deepseek-ai/deepseek-harness（README、docs/architecture.md，2026-08-13 开发者预览）；Cordis 实现 github.com/cordiverse/cordis；预印本 A Programming Paradigm for Spatiotemporal Composability，Draft of August 13, 2026，github.com/cordiverse/paper。V4-Pro-0813 的上下文长度、输出上限与 Agent 基准数字来自 DeepSeek 当日公开材料，属官方自测口径。本文不转载其他媒体原文，也不把预印本中的研究方向写成已交付能力。Preview 迭代快，命令、预设和行为以仓库当前文档为准。