DeepSeek Harness：开放 Agent 运行时不是模型发布的配菜，而是在争夺智能体时代的系统控制权

2026-08-14

一、触发新闻与一句话定义

DeepSeek 在 2026 年 8 月 13 日发布 Harness v0.1 开发者预览版，并以 MIT 许可证开放完整代码；模型适配器、工具、会话、沙箱、文件系统、执行循环、编排和界面都被拆成可替换的 Cordis 插件。官方同时明确提醒，当前版本仍在快速迭代，后续会出现破坏兼容性的改动。它不是一项模型能力更新，而是 DeepSeek 第一次把模型外面的执行系统作为独立产品交给开发者。

一句话定义：DeepSeek Harness 是一套基于 Cordis 微内核、以仅追加事件日志保存状态、用插件组合模型与行动能力的开源 Agent 运行时。

今天最容易被低估的，恰好是「运行时」三个字。

大模型收到提示词并返回文本，只完成了一次推理。Agent 要完成真实任务，还得决定读哪些文件、何时调用工具、是否允许写盘、失败后怎样恢复、上下文满了删什么、多 Agent 如何交接，以及每一步怎样留下证据。这层把概率输出变成可执行行动的系统，就是 harness。2026 年两项研究把这个隐藏变量量化了：在固定模型、工具和任务后，仅更换 coding harness，每道成功任务的 Token 消耗最多可相差 40 倍；另有实验显示，经过可观测轨迹优化的 harness 在不改模型的条件下，可让多个模型家族在 Terminal-Bench 2 上提高 5.1 至 10.1 个百分点。《The Scaffold Effect》与《Agentic Harness Engineering》给出的共同提醒是，Agent 的有效能力属于「模型—运行时」这一对组合，不能只写在模型名下面。

DeepSeek 此时开放 Harness，因而不只是补齐一个开发工具。它在回答一个更大的问题：当模型逐渐可替换，谁来定义模型如何看见环境、如何行动、如何被约束？

二、纵向分析：从诞生到当下

1. 起点不是 Agent，而是把昂贵能力做成可复制工程

DeepSeek 2023 年在杭州成立，创始人梁文锋此前共同创办量化机构幻方。这个背景不该被写成传奇，但它解释了团队早期偏好的来源：量化交易本来就是模型、数据、计算、执行和风险约束共同工作的系统，单个预测模型从来不能独立完成业务。美联社对 DeepSeek 的早期梳理也提到，幻方长期用机器学习改进量化策略，并在 2022 年前积累了大规模 A100 集群。美联社

2023 年 11 月发布的 DeepSeek-Coder，把这种工程倾向第一次摆到开发者面前。它不只训练代码补全，还把仓库级代码、16K 上下文与 fill-in-the-middle 任务放进训练设计；到 2024 年 6 月，Coder-V2 又把代码能力与通用推理结合起来。DeepSeek-Coder 官方仓库和DeepSeek-Coder-V2 官方仓库留下了一条清楚的路线：代码不是一个对话垂类，而是模型进入外部世界最自然的行动语言。

但会写代码仍不等于能做工程。模型可以给出一段漂亮补丁，却不知道工作区是否干净；可以调用 Bash，却未必知道权限边界；可以在一次对话里修好 bug，却可能在第十次上下文压缩后忘记原目标。这些问题当时被笼统归入「Agent 框架」，DeepSeek 仍把主要火力放在模型效率上。

2. 2024 年：先把推理成本压低，才有高频行动的经济基础

2024 年 5 月的 DeepSeek-V2 是第二个关键节点。论文提出 Multi-head Latent Attention（MLA）和 DeepSeekMoE：前者压缩推理时的 KV Cache，后者让总参数与每 Token 激活参数分离。DeepSeek-V2 论文公布的模型总参数为 236B，每个 Token 激活 21B。它解决的不是 Agent 编排，却为长上下文、多轮工具调用提供了经济基础。

同年 7 月，DeepSeek API 增加 Function Calling、JSON Output、FIM 和前缀续写，其中 Function Calling 兼容 OpenAI 接口，一次最多声明 128 个函数。DeepSeek API 更新把模型从「返回答案」推进到「返回机器可解析的行动请求」。8 月上线的磁盘上下文缓存又瞄准多轮会话中反复输入的长前缀：官方披露，128K 高重复提示的首 Token 延迟可从 13 秒降到约 500 毫秒，缓存命中价格较普通输入明显降低。DeepSeek 上下文缓存说明

这两次更新连起来看，比单看价格更有意思。Function Calling 给了模型手，缓存让这双手可以频繁伸出去而不必每次重读全部历史。DeepSeek 的早期 Agent 路线，先从 API 原语和推理经济性入手，而不是先造一个庞大的编排平台。

这也是后来 Harness 架构里一个持续存在的选择：模型提供方只是一个可替换服务，不应成为系统里不可绕过的中心。DeepSeek 先通过 OpenAI 兼容接口降低模型迁移成本，后来又把这一思路推进到整个运行时。

3. 2024 年末至 2025 年初：开放权重形成分发能力，R1 把推理轨迹推到台前

2024 年 12 月的 DeepSeek-V3 将 MLA、DeepSeekMoE 和训练系统工程合在一起。官方技术报告披露，V3 总参数 671B、每 Token 激活 37B，预训练数据为 14.8 万亿 Token；代码仓库使用 MIT 许可证，模型允许商业使用。DeepSeek-V3 技术报告与官方仓库使 DeepSeek 从「便宜 API 提供者」进一步成为全球开源模型供应者。

2025 年 1 月发布的 R1 把这条路线推向推理模型。DeepSeek 开放 R1-Zero、R1 以及六个蒸馏模型；后续发表于 Nature 的论文说明，R1-Zero 主要通过强化学习激发推理行为，R1 再用多阶段训练改善可读性与通用能力。DeepSeek-R1 发布页和Nature 论文让「公开模型权重和技术细节」成为 DeepSeek 最强的分发资产。

R1 的行业影响常被归结为推理能力与成本，但对 Harness 更直接的遗产是：推理过程变长之后，模型外面的系统问题被放大了。长思考会消耗上下文；工具返回会污染历史；一次失败可能需要回退到某个中间状态；如果只存最终回答，开发者无法判断错误来自模型、提示、工具描述还是执行器。Agent 需要的已不是一个 messages 数组，而是一份能够重建现场的运行记录。

这条需求最终落在 Harness 的事件溯源设计上。它把 turn/start、step/start、用户消息、流式输出、工具调用、工具结果、审批请求和上下文压缩等事实依次追加到会话日志；模型可见的历史从日志投影出来，而不是成为唯一真相。官方架构文档还设下一条强约束：凡是送进模型请求的内容，都必须能从日志重建。DeepSeek Harness 架构文档

这不是为了把日志做得更漂亮。它把四件原本分散的事统一起来：恢复会话、回放 UI、追踪 Token、从中间节点 fork。一个 Agent 在第 37 步做错决定时，系统终于有机会回答「当时模型看见了什么」，而不是只拿最后一段文本猜原因。

4. 2025 年下半年：「Agent 时代」从模型训练目标进入产品路线

2025 年 8 月，DeepSeek 在 V3.1 发布说明里直接写下「迈向 Agent 时代的第一步」，并把工具使用、多步任务、SWE 与 Terminal-Bench 能力列为后训练重点；API 同时增加 Anthropic 格式与严格 Function Calling。DeepSeek-V3.1 发布说明是路线转向的公开证据。

这一步很关键。早期路线是让模型更便宜、更会调用函数；新的问题变成，如何让这些能力在多步任务里稳定发生。模型训练可以提高正确调用工具的概率，却不能替企业决定哪些工具应当出现、写操作是否需要审批、沙箱放在哪台机器、失败日志留多久。越往真实生产走，模型团队越会碰到一圈自己无法用参数更新消灭的系统约束。

Anthropic 2025 年对长任务 Agent 的复盘提供了一个旁证：即便前沿模型配上上下文压缩，只给一句高层目标，Agent 仍难以独立交付生产级应用；需要进度文件、增量验证和清晰的接班机制。Anthropic 长任务 Harness 实践说明，模型能力上升不会自动取消运行时，反而让运行时承担更多组织工作。

DeepSeek 面临的战略选择于是变得具体。它可以继续只供应模型，让 Claude Code、OpenCode、OpenHands 等外部产品决定用户如何调用 DeepSeek；也可以进入运行时层，把自己的模型、第三方模型、工具和安全机制放进同一套可控结构。选择前者更轻，选择后者才有机会获得真实 Agent 轨迹、开发者扩展和系统标准的反馈。

5. 2026 年：Cordis 把「可替换」从模型接口推到整棵系统树

Harness v0.1 的核心并不是常见的「支持插件」，而是不存在享有特权、只能打补丁修改的内核。运行中的 dsh 是一棵 Cordis 插件树：模型适配器、系统提示、工具注册表、会话存储、沙箱、审批、子 Agent、Web 界面乃至默认 Agent loop 都由插件提供。插件向共享上下文注册服务与类型化事件；卸载插件时，其注册和副作用也会撤销。Cordis 教程将它称为时空可组合性：空间上，不同上下文可以拥有不同能力；时间上，能力可以在生命周期内装入、卸载和热替换。

这套设计把过去几年的开放路线推进了一层。V3、R1 开放的是模型权重，开发者可以换模型；Harness 开放的是模型周围的执行契约，开发者可以换运行世界。

例如，文件系统与子进程共享同一个能力 seam。开发者把本地提供方换成远程沙箱后，Bash、持久终端和语言服务器都能随之迁移，不必为每个工具各写一套远程版本。审批也不是写在提示词里的礼貌要求，而是工具执行前的流水线：请求与决定作为持久事件保留，策略不可用时可以关闭执行。子 Agent 提供方还能接入 dsh 自身、Codex 或 Claude Code。系统提示词、工具 schema 和调用配置被记录为请求头快照，恢复时可以重建当时真实的模型输入。

这种架构选择来自一个判断：未来 Agent 的差异不会只落在「用了什么模型」，而会落在能力如何组合。企业可能需要本地文件系统、远程 E2B 沙箱、内部模型路由、特定审批链、SQLite 会话和自己的 UI；研究者可能只要一次性的 headless runner；模型实验可能要重放完全相同的输入流。硬编码一套默认产品很快会分叉，插件树试图把分叉变成配置。

代价也埋在同一个选择里。Cordis 是开发者需要额外理解的新抽象；服务依赖缺失时，插件可能合法地停在 PENDING 状态而不是立即报错；可热替换的组件越多，组合测试、版本约束和权限推理越难。官方甚至把当前会话格式标为预发布格式，并明确拒绝某些旧日志，而不是冒险做不完整回放。会话持久化说明表现出一种可取的保守，但也确认了 v0.1 尚不是可以冻结接口的生产底座。

因此，2026 年 8 月 13 日是「诞生节点」，不是「成熟节点」。DeepSeek 已把完整代码、npm 启动方式、Web UI、headless 模式和插件开发文档交出来，却没有在仓库的 BENCHMARK.md 中给出与 Claude Agent SDK、OpenAI Agents SDK 或 LangGraph 的正式效果对比。官方仓库只提供最小 benchmark 运行说明。现阶段能够确认的是架构边界和开放程度，不能确认性能领先、企业稳定性或插件生态质量。

这份克制反而让信号更清楚：DeepSeek 押注的不是「首日最好用」，而是「模型外的每一层都应当可审视、可替换、可重组」。

三、横向分析：竞争图谱

1. 先划清赛道：四类产品看似都叫 Agent 框架，争的控制面不同

DeepSeek Harness 同时具备可直接运行的 Web 产品、headless runner、Python SDK 和底层插件框架。它的直接比较对象不能只选一个。Claude Agent SDK 是从成熟 coding agent 产品抽出的执行系统；OpenAI Agents SDK 是少数核心原语组成的应用库；Google ADK 面向企业多 Agent 的开发、评测与部署全周期；LangGraph 则用显式状态图解决长流程的确定性与恢复问题。

这张表里没有单一冠军。它们各自把最难的问题放在不同位置：DeepSeek 认为最难的是组件替换；Anthropic 认为最难的是给成熟 Agent loop 加安全边界；OpenAI 强调最少但够用的应用原语；Google 把问题扩大到企业生命周期；LangGraph 要求开发者先把状态转移画清楚。

2. Claude Agent SDK：今天最像完整成品，也是 DeepSeek 最直接的参照物

Claude Agent SDK 把 Claude Code 的能力带进 Python 和 TypeScript 应用。官方列出的现成功能包括读写文件、执行命令、Web 搜索、hooks、子 Agent、MCP、权限、会话恢复与 fork，以及从 .claude/ 加载 Skills、命令和记忆。Claude Agent SDK 文档对想做 coding agent 的团队很有吸引力：不用先设计微内核，几行代码就能运行一套经过大量真实代码任务打磨的循环。

Anthropic 在权限细节上也比「可配置」三个字走得更远。SDK 区分 default、dontAsk、acceptEdits、bypassPermissions、plan 与模型分类的 auto 模式；允许 PreToolUse hook 覆盖每一次工具调用；文档还明确提醒，白名单与 bypassPermissions 组合可能放行未列出的 Bash、Write 和 Edit，子 Agent 继承高权限模式会获得完整系统访问。Claude 权限文档把容易踩坑的行为写到了接口层。

它的优势来自产品历史。Claude Code 先作为工具被用户反复使用，再把稳定能力下沉为 SDK。开发者得到的是有真实任务反馈的默认值，hooks、Skills、子 Agent 和权限模型也已经形成共同语言。对「今天就要做一个能改代码的 Agent」的人，成熟默认值通常比理论上的无限可组合更值钱。

它的边界也同样来自历史。Claude Agent SDK 的循环与 Claude Code 紧密相关，只支持 Python 和 TypeScript 库；第三方产品不能未经批准使用 claude.ai 登录或订阅额度，使用受 Anthropic 商业条款约束。开发者可以接工具、写 hooks、装插件，却不能像在 DeepSeek Harness 中那样把会话存储、LLM 流、Agent loop、审批服务和 UI 都视为同等级别的可卸载部件。

所以两者不是简单的「开源对闭源」。Claude Agent SDK 追求的是强默认产品的可嵌入性，DeepSeek Harness 追求的是运行时结构本身的可改写性。前者当前的完成度更高；后者如果形成生态，可能更适合需要自托管、异构模型和严格审计的组织。

3. OpenAI Agents SDK：用最少原语换取低学习成本

OpenAI Agents SDK 从实验项目 Swarm 演进而来，刻意保留很少的核心概念：带指令和工具的 Agent、作为工具或 handoff 的其他 Agent，以及输入输出 guardrail。SDK 负责 agent loop、工具调用、Sessions、人机介入和 tracing，也能通过 LiteLLM 或其他适配器接非 OpenAI 模型。OpenAI Agents SDK 官方文档把设计原则写得很直白：功能要足够，但抽象要少到容易学习。

这条路线与 DeepSeek 几乎相反。OpenAI 更信任 Python/TypeScript 本身作为编排语言，开发者直接写条件、循环和 handoff；DeepSeek 则把编排语言下面的服务注册、生命周期、副作用回收和配置树也纳入框架。OpenAI 的好处是代码可读、入门快，并能自然接入 tracing、evaluation、fine-tuning 和 distillation；DeepSeek 的好处是相同应用可以通过替换 provider 改变文件系统、沙箱、模型或存储，而不必把这些差异散落在业务代码中。

在安全上，两者也有不同重心。OpenAI 把 guardrail 作为一等概念，可以并行检查输入、输出和工具调用，并提供 sandbox agents 与可恢复沙箱会话。DeepSeek 当前更像一套可组装的策略平面：审批请求、沙箱策略和工具执行流水线都能被插件拦截，开发者必须为自己的组合承担更多验证责任。前者给你铺好的护栏，后者给你护栏的接口、螺栓和施工图。

真实选择通常很朴素。团队若围绕 OpenAI 模型、Responses API 和评测平台开发客服或研究应用，Agents SDK 的低摩擦更强；若团队必须把 LLM、执行环境、存储与审批分别接入不同内网系统，DeepSeek 的 seam 设计更有吸引力。问题在于，后一个优势只有在第三方 provider 经历生产验证后才成立，v0.1 目前还没有这份证据。

4. Google ADK：企业全栈与多语言覆盖最宽

Google 在 2025 年 Cloud Next 发布 ADK，最初就把 Build、Interact、Evaluate、Deploy 放在同一条链上。它支持层级多 Agent、Sequential、Parallel、Loop 工作流、模型动态转移、Web 调试界面、MCP 工具和 LiteLLM；2026 年的 ADK 2.0 又增加图工作流，并覆盖 Python、TypeScript、Go、Java 与 Kotlin。Google 发布博客和ADK 官方文档显示，它的目标不是一个 coding harness，而是企业 Agent 应用平台的通用开发层。

Google 的优势不是某个循环写得更精巧，而是上下游齐全。ADK 能接 Vertex AI、BigQuery、AlloyDB、Apigee 和大量企业连接器，也提供 sessions、events、memory、context compression、evaluation、observability、A2A 与部署路径。大型组织若已经在 Google Cloud 上运行数据与应用，身份、数据、模型和托管服务的连接成本往往比运行时是否能热换插件更重要。

它的短板也是生态绑定。ADK 支持多模型、也声明可以在不同环境运行，但官方明确称其对 Gemini 与 Google Cloud 做了优化。层次多、能力宽，会带来另一种复杂度：开发者需要在 Agent、workflow、graph、session、artifact、callback、plugin 和云服务之间做选择。

DeepSeek 的切口更窄也更底层。它没有 Google 那样成熟的部署与企业连接器，却允许开发者替换构成产品的几乎每一块。若把两者比作城市，ADK 已经修好了机场、道路和政务系统；Harness 更像开放了建筑规范、管线接口和可拆卸街区。前者适合直接入住，后者适合必须自己规划城市的人。

5. LangGraph：显式状态图仍是确定性流程的强对手

LangGraph 不试图成为一套预装 coding agent。它把长期运行任务表达为状态图，以 checkpoint 保存线程状态；开发者可以从历史节点 replay，也可以修改状态后 fork，新分支之后的 LLM 调用、API 请求和 interrupt 会重新执行。LangGraph Time Travel 文档甚至明确区分父图和 subgraph 的 checkpoint 粒度。

这使 LangGraph 在金融、审批、数据管道等流程里有一个很难替代的优点：状态转移是显式的。哪一步确定执行，哪一步交给模型，哪里暂停等人，开发者可以在图上说明。DeepSeek Harness 的默认 Agent loop 更动态，事件日志非常适合追责和重建，却不自动让流程变得可预测。记录「Agent 如何走错」与事先规定「Agent 可以往哪里走」，是两种不同能力。

反过来，LangGraph 的图也可能成为负担。开放式编码、研究或浏览任务很难预先枚举路径，过度显式的图会把模型的适应性压回传统工作流。DeepSeek 用事件和插件承载变化，更适合允许模型动态决定下一步、同时要求完整留痕的场景。

两者未来未必正面互斥。LangGraph 可以作为 Harness 的一个编排 provider，Harness 也可以为 LangGraph 提供沙箱、工具权限与事件存储。真正的竞争点是由谁来拥有最高层状态：是业务图的 checkpoint，还是运行时的事件日志。

6. 用户视角：DeepSeek 的首日兴奋与真正门槛

Harness 发布当天的社区讨论出现了两类声音。一类用户赞赏推理、工具调用的可视化与较少重复；另一类立刻追问，它相对 Hermes Agent、OpenCode、Codex 和 Claude Code 到底多了什么，以及 Cordis 这一年轻框架是否会成为额外负担。DeepSeek 社区首日反馈和LocalLLaMA 讨论只能当早期样本，不能当用户口碑定论。

这些问题问到了要害。开发者通常不会因为架构优雅迁移，他们为三个具体结果迁移：同一模型任务成功率更高、成本更低、出错后更容易恢复。DeepSeek 已展示第三项的架构基础，对前两项尚无自有对照数据。插件数量、文档完整度和 GitHub 热度也替代不了跨模型、跨任务、同预算测试。

我的判断是，Harness 当前的首批核心用户不会是只想找「DeepSeek 版 Claude Code」的普通开发者，而是已经在维护内部 Agent 平台、被模型适配、工具权限、会话恢复和多运行环境折磨过的基础设施团队。他们能看懂 seam 的价值，也愿意承受 v0.1 的接口变化。大众用户要等的不是更多架构图，而是稳定 profile、可靠插件市场、迁移工具和公开 benchmark。

四、横纵交汇洞察

1. DeepSeek 正把开放优势从权重层搬到轨迹层

回看纵轴，DeepSeek 的每个优势都能找到历史根源。低成本多轮调用来自 V2 的 MLA 与后续上下文缓存；多步工具能力来自 2024 年 Function Calling 和 V3.1 的 Agent 后训练；开发者分发来自 V3、R1 的开放权重；Harness 的 MIT 许可证沿用了「先把技术对象交给社区」的习惯。

但 Harness 比开放模型多了一层战略含义。权重开放让外部开发者部署模型，运行时开放则可能让 DeepSeek看见开发者怎样组织上下文、工具、审批和失败恢复。若社区愿意提交插件、issue 与轨迹级复现，DeepSeek 获得的就不只是代码贡献，而是一份关于「模型为何在真实任务里失败」的系统反馈。这类反馈可以回流到工具调用训练、上下文设计和评测集。

MiniMax 已把 Agent 使用轨迹送回训练环节，Anthropic 也持续从 Claude Code 提炼 harness 实践。模型公司开始争夺的不是一次回答，而是完整行动链。DeepSeek 过去依赖开放权重扩大分发，Harness 试图补上一个此前被外部产品截走的反馈面。

这也解释了为什么「一切皆插件」比「只支持 DeepSeek 模型」更合理。若 Harness 锁死自家模型，它得到的反馈无法区分模型缺陷和运行时缺陷；允许接入不同模型，反而能在相同环境下观察失败指纹。2026 年 Harness-Bench 的观点正是以「模型—harness 配置」作为评测单位。Harness-Bench指出，推理看似合理却与工具反馈、工作区状态或可验证输出脱节，是多种系统反复出现的执行对齐失败。开放运行时让这种失败有机会被定位到具体层。

2. 早期的好决策，正在变成今天的两面刃

DeepSeek 长期采用开放、兼容、低成本路线。它让公司迅速获得全球开发者注意，也让 DeepSeek 模型很容易被塞进别人的产品。问题是，当 OpenCode、Claude Code 或企业自研平台掌握用户入口时，DeepSeek可能只剩一个可替换 API。模型越兼容，替换它也越容易。

Harness 是对这项历史包袱的修正：既然模型层主动降低锁定，就到运行时层建立开发者关系。但 DeepSeek 没有改用封闭绑定，而是把运行时也做成可替换插件。这看似继续削弱锁定，实际押注的是另一种黏性——开发者不是因为走不了才留下，而是因为能改、能审计、能把自有系统接进来才留下。

这种黏性成立需要两个条件。第一，Cordis 插件边界长期稳定，否则每次破坏性变更都会惩罚生态贡献者；第二，默认组合必须足够好，否则无限可配置只会把系统集成成本转给用户。Linux 的价值不只来自内核开放，也来自稳定系统调用、发行版和驱动生态。Harness v0.1 现在只有「内核与设计文档」这一侧，离完整生态还有很长距离。

另一个两面刃是事件日志。仅追加、可重建的记录非常适合审计、回放与金融场景中的责任追踪；记录系统提示词、工具 schema、审批结果和工具参数，也会形成高密度敏感数据。日志一旦包含代码、凭据片段、客户数据或内部决策，持久化本身就是风险。DeepSeek 把存储提供方、遥测和 spill store 做成 seam，为私有部署留下了空间，却不能替部署者完成数据分级、脱敏、保留期和访问审计。

在金融机构里，这一点尤其现实。一个投研 Agent 的最终报告可能没有敏感信息，完整轨迹却可能包含未公开持仓、研究员查询、内部数据库 schema 和被拒绝的交易动作。可审计与少留数据并不天然一致。Harness 若想进入资管、银行或券商，下一阶段需要的不是再加几个工具，而是给事件类型提供字段级策略、加密、删除证明与合规导出。

3. 竞争胜负不会由插件数量决定，而由默认组合与可验证改进决定

横向对比显示，DeepSeek 并没有进入一片空地。Claude Agent SDK 拥有成熟 coding loop 和权限经验；OpenAI Agents SDK 把应用开发压缩到少数原语，并连着评测与优化平台；Google ADK 有多语言、云部署和企业连接器；LangGraph 掌握显式状态流程。

DeepSeek 的差异不是多一项功能，而是允许用户改掉实现这项功能的整层 provider。这个差异对基础设施团队很大，对普通应用开发者却未必可见。用户不会为「会话存储可替换」付出学习 Cordis 的成本，除非默认 SQLite 确实不满足恢复、合规或规模要求；也不会为了「Agent loop 可替换」迁移，除非替换后能用同预算解决更多任务。

因此，下一阶段最关键的产品不是插件市场，而是一套严格的模型—profile 对照评测。DeepSeek 应公开相同模型在标准、极简、创造、程序化工具调用等 profile 下的任务完成率、Token、墙钟时间、审批次数与失败类型；再让第三方复现实验。只有这样，「一切皆插件」才从架构信仰变成可验证的优化空间。

这也会改变模型榜单的写法。今天的榜单通常把 Claude、GPT、Gemini、DeepSeek 当参赛者，harness 藏在脚注里。未来更诚实的参赛单位应是「DeepSeek V4 + dsh 某 profile + 某沙箱策略」，就像数据库性能不能只写 SQL 引擎名称而不写索引、缓存和事务配置。Harness 若能推动这一披露规范，影响会超过自身市场份额。

4. 三个未来剧本

最可能的剧本：成为开源 Agent 基础设施的高可塑底座，但不是大众入口。

未来 12 至 18 个月，DeepSeek 先稳定 Cordis 服务接口、事件格式和 profile，社区补上更多模型、沙箱、存储与企业工具插件。基础设施团队用它做内部 coding、研究和运维 Agent，普通用户仍主要使用 Claude Code、Codex 或厂商托管产品。Harness 在 Agent 世界里的位置接近一个可嵌入运行时：影响许多产品，却不一定拥有最大的终端品牌。

这个剧本最符合它的历史。DeepSeek 擅长开放底层能力与成本工程，不以封闭界面锁住用户；完整的 Web UI 更像参考实现，Cordis 与事件日志才是长期资产。验证信号包括：v1 前事件格式趋稳、树外插件能跨小版本工作、出现至少三个非 DeepSeek 模型的生产案例，以及官方开始发布同预算 harness benchmark。

最危险的剧本：可组合性变成配置税，生态在破坏性变更中失速。

如果插件 API、事件 schema 与 profile 频繁改动，第三方维护者会停止追版本；如果缺少强默认组合，普通用户会认为它只是更复杂的 OpenCode；如果权限 seam 的组合产生意外旁路，一次供应链或沙箱事故就会伤害「开放运行时」的信任。与此同时，Claude Agent SDK、OpenAI Agents SDK 和 Google ADK 可以逐步增加可替换后端，把 DeepSeek 的差异压缩成一种实现风格。

这里最危险的不是功能落后，而是抽象过早。Cordis 试图一次性统一服务、事件、生命周期、配置、热替换和 UI 扩展，设计面很大。若真实用户的主要痛点只是稳定 coding loop 与低 Token 成本，他们不会为理论完整性买单。观察指标是 GitHub issue 是否集中在安装、依赖与兼容，而不是新 provider；插件仓库是否大量停更；官方是否长期无法给出任务效果数据。

最乐观的剧本：Harness 成为开放 Agent 的事实接口，并反向改进模型。

在这个剧本里，DeepSeek 稳定核心 seam，建立经过签名与权限声明的插件生态；事件日志形成可移植轨迹格式，模型、工具、沙箱和 UI 都能在不丢审计语义的条件下更换。开发者用同一批轨迹比较不同模型与 profile，失败被自动归因到上下文、工具、执行、验证或权限层；高质量轨迹再进入后训练和 Harness 优化。

届时，DeepSeek 获得的不是传统平台锁定，而是一种协议地位。模型厂商会适配它，企业会要求插件兼容它，评测机构会用它固定运行条件。DeepSeek 模型也能从跨模型失败对照中获得更干净的训练信号。开放权重带来的分发、低成本推理带来的高频调用、事件轨迹带来的系统反馈，终于首尾相接。

这个剧本很诱人，也最难。它要求 DeepSeek 在开放速度之外建立标准治理能力：稳定版本、兼容承诺、安全响应、插件签名、基准中立和跨组织决策机制。一个模型团队能否同时成为可信运行时社区的维护者，尚无答案。

5. 最后的判断

我的判断是，DeepSeek Harness 当前最重要的价值不是「又多了一个 Agent 框架」，而是头部模型公司公开承认：模型已经不是 Agent 产品里唯一需要竞争的技术对象。

从 2024 年的 Function Calling，到 2025 年 V3.1 宣布进入 Agent 时代，再到 2026 年把模型、工具、会话、沙箱、审批和循环全部拆成插件，DeepSeek 的路线发生了明确位移。过去它优化每个 Token 怎样更便宜地产生；现在它开始优化这个 Token 产生之后怎样进入世界、留下证据，并在失败后被重新组织。

开头那句「运行时」因此值得再看一遍。它不是模型外面的包装，而是把智能变成行动时必须经过的制度层：谁能做什么，谁批准，怎样记账，出错后回到哪里。DeepSeek 开放了这层的施工图，却还没有证明自己建成了最可靠的城市。

今天可以下的结论到这里为止：架构方向成立，行业信号足够强，产品胜负仍待验证。接下来真正决定 Harness 命运的，不是发布日的关注，而是半年后同一条旧轨迹还能不能重放、第三方插件能不能继续运行、以及相同模型是否能用更少成本完成更多真实任务。

五、信息来源

1. DeepSeek Harness 官方仓库 2. DeepSeek Harness 架构文档 3. DeepSeek Harness 会话与持久化事件目录 4. Cordis 插件框架教程 5. DeepSeek API：Function Calling、JSON Output 与 FIM 更新 6. DeepSeek API：磁盘上下文缓存 7. DeepSeek-V2 论文 8. DeepSeek-V3 技术报告 9. DeepSeek-R1 发布说明 10. DeepSeek-R1 Nature 论文 11. DeepSeek-V3.1 发布说明 12. Claude Agent SDK 官方文档 13. Claude Agent SDK 权限文档 14. Anthropic：Effective harnesses for long-running agents 15. OpenAI Agents SDK 官方文档 16. Google Agent Development Kit 官方发布博客 17. Google ADK 官方文档 18. LangGraph：Time Travel、Replay 与 Fork 19. The Scaffold Effect in Coding Agents 20. Harness-Bench 21. Agentic Harness Engineering 22. 美联社：DeepSeek 与梁文锋早期背景 23. DeepSeek 社区首日反馈 24. LocalLLaMA：DeepSeek Harness 首日讨论