DeepSeek 开放其 Agent Harness，让每个组件都可替换

DeepSeek 发布了首个 Harness 开发者预览版，而 Google News 标题背后的冲突相当具体。这家公司并非只是为另一款编程智能体增加插件，而是将模型适配器、工具注册表、会话日志、沙箱、智能体循环和用户界面都做成了可替换组件。

这一设计让 DeepSeek Harness 处于 Claude Code、Codex 等现成编程智能体产品的底层。这些产品向开发者提供的是已组装好的智能体，并设定了明确的扩展点；DeepSeek 提供的则是一种可配置的底层基座，可生成多种智能体，其中也包括看起来像编程助手的智能体。

这种差异也暴露了该项目最大的未知数。DeepSeek 表示，所有部分都可以混合、替换或扩展，但该软件仍处于开发者预览阶段。其文档明确警告，未来将出现破坏兼容性的变更。因此，这次发布既是一项架构主张，也是对极致模块化能否经受生产环境考验的一次尚未完成的测试。

Google News 标题实际宣布了什么

DeepSeek 开放的是 AI 模型周围的整套机制，而不是发布另一款配备新聊天界面的模型。

DeepSeek Harness，也称为 dsh，是一款基于 MIT 许可证发布的开源智能体框架。智能体框架是围绕模型运行的软件，负责管理提示词、工具、文件、状态、权限以及重复的模型调用。

该项目的官方仓库提出了一个核心理念：“一切皆插件”。这包括模型、技能、工具、会话、沙箱、文件系统、循环、编排，以及呈现给用户的界面。

DeepSeek 表示，当前版本是开发者预览版。用户可以通过 npm 命令启动其浏览器界面，该应用默认在本地提供服务。开发者也可以从源代码构建该仓库。

此次公开发布之前，已有迹象表明 DeepSeek 正在组建专门的 Harness 团队。不过，代码本身比此前的招聘信号更重要。它让开发者能够检查、修改和运行一套具体系统，而无需依赖产品演示。

这也解释了为什么该消息在 Google News 上并不只是又一次代码仓库发布。DeepSeek 因具备竞争力的模型而广为人知，但 Harness 将关注点转向了决定模型如何完成实际工作的软件。

原始语言模型接收输入并生成输出。一个可工作的智能体还必须决定何时调用工具、保留哪些历史记录、允许命令在何处执行，以及何时需要人工批准。

这些决策往往解释了为何使用相似模型的两款产品会表现不同。周边系统可以从失败的命令中恢复、维持计划、压缩上下文，或阻止不安全的文件操作；它同样也可能处理不当其中任何一项职责。

DeepSeek 正将这一周边系统本身作为产品。其随附的 Web 应用只是底层组件的一种可能组合，而非所有用户都必须接受的特权实现。

该框架构建于 Cordis 之上，DeepSeek 将其描述为可动态组合软件的元框架。Cordis 允许插件向共享上下文贡献服务、类型化事件和可逆效果。

可逆效果是指某个贡献组件卸载时可以撤销的、被追踪的变更。这为运行时提供了一种结构化方式，可在不遗留未知状态的前提下添加或移除能力。

这一基础支撑了 DeepSeek 更大的承诺。开发者应能通过配置，将本地文件系统提供者替换为远程实现、切换模型适配器，或引入另一种智能体循环。

此次发布并不能证明每种组合都能可靠运行。但它确实表明，DeepSeek 已在其他智能体产品常常视为固定的组件周围划定了插件边界。

这种差异形成了核心张力：更多可替换机制赋予开发者更大控制权，但也带来了更多需要管理的接口、依赖关系和故障模式。

DeepSeek Harness 为何会给成熟编程智能体带来压力

DeepSeek 正在挑战这样一种假设：开发者只能在智能体的边缘进行定制。

大多数编程助手都会提供扩展机制，同时保留一个带有明确主张的中心。开发者可以添加工具、连接外部服务、安装技能或修改指令，但产品仍掌控其主要循环、会话模型和界面。

DeepSeek Harness 将可替换边界向内推进。其架构文档表示，不存在一个开发者必须打补丁修改的特权核心。

即使默认的智能体循环，也是通过与其他能力相同的共享上下文注册的。该循环控制用户输入如何转化为模型请求、工具调用、结果和后续步骤。

这并不意味着 Claude Code、Codex 或类似产品已经过时。成熟的编程智能体将安装、更新、身份验证、模型访问、安全规则和界面决策打包为连贯的体验。

这种封装具有真实价值。今天就需要修复测试的开发者，可能更偏好拥有合理默认设置的工具，而不是一个需要做出架构选择的框架。

DeepSeek 则是在向研究团队、平台工程师以及希望采用不同默认设置的组织施加压力。这些用户可能需要自定义沙箱、内部模型网关、受控存储或可审计的执行路径。

可替换的模型适配器尤为重要。它将智能体行为与对单一模型提供商的独占依赖分离开来。

DeepSeek 自身的 API 文档已经讨论了第三方框架，其中包括可扩展的 Pi 编程智能体。Pi 集成指南还包含免责声明：DeepSeek 不保证第三方产品的有效性或安全性。

Harness 提供了另一种答案。开发者无需将 DeepSeek 模型适配至外部智能体，DeepSeek 可以提供周边架构，同时仍允许使用其他模型提供商。

这使主要竞争不再是 DeepSeek 与某一家指定公司的较量，而是高度可配置的底层基座与成品化、带有明确主张的智能体产品之间的竞争。

底层基座路线让组织能够定义其系统的运作方式。一个团队可以使用一种模型进行规划、另一种模型生成代码，并使用本地模型处理敏感分类；各提供商可以位于共享适配器边界之后。

同一个团队还可以为不同智能体分配不同工具。数据库专家可能获得只读访问权限，而部署智能体则获得范围严格限定的发布控制。

这些限制可以存在于已注册的能力和执行策略中，而不必只依赖系统提示词中的一句话。

成品化产品路线做出了不同取舍。它限制用户需要理解的选择数量，将测试集中在受支持路径上，并形成一致的支持目标。

因此，DeepSeek Harness 是在架构层面给既有产品施压，而不一定是在日常用户层面。竞争者必须决定，应允许开发者替换多少内部机制。

它们可以保持中心受控，并扩展受支持的扩展功能；可以开放更底层的 SDK 和服务；也可以主张完全替换会带来运维复杂性，却没有足够实际收益。

眼下被迫作出的回应未必是推出一个对等框架。更强的信号将是，智能体厂商是否会明确其架构边界，并让更多行为变得可检查。

对企业买家而言，这并非抽象差异。固定的会话系统可能与留存要求冲突；固定的沙箱可能不支持组织的基础设施；固定的工具管道可能缺少必要的审批关卡。

因此，通过 Google News 关注此次发布的开发者，应将重点放在所有权上。DeepSeek 正在主张，团队应拥有更多智能体技术栈的控制权，即使这种所有权会带来额外工作。

一切皆插件，包括智能体循环

值得注意的机制并非插件数量，而是不存在插件无法替换的受保护中心。

正在运行的 DeepSeek Harness 实例以插件树形式组装。配置文件定义具名组合，而捆绑包则封装配置行及这些配置行挂载的代码。

DeepSeek 提供了 Web 和无头模板。基础捆绑包提供模型适配器、工具、持久化、沙箱控制、审批策略、凭据、设置和遥测功能。

额外捆绑包可以增加浏览器应用或一次性运行器。配置层按顺序应用，后续补丁可以替换配置行或引入新配置行。

这种安排让两个智能体能够共享大量相同代码，同时暴露不同能力。一个配置文件可能包含浏览器界面和本地 shell；另一个则可能在自动化工作流中运行，不带服务器。

该项目将核心行为划分为多个包。会话负责仅追加的事件日志，也就是说，记录的事件会被添加，而不会被悄然覆盖。工具拥有范围受限的注册表和受保护的执行管道。

系统提示词包负责组装提示词区段和工具模式；语言模型包提供消息词汇和提供商适配器边界；智能体包则暴露实时智能体及相关事件。

一次轮次可以包含多个步骤。每个步骤由一次模型请求及该请求调用的工具组成。

执行之前，插件可以通过已定义事件检查或拒绝工作。模型输出会流入会话，工具调用会经过执行前和执行后阶段，结果则可能触发另一次模型请求。

这种事件结构十分重要，因为可扩展性本身并不能保证行为连贯。插件需要在达成共识的节点观察、修改或停止整个过程。

DeepSeek 对必须在重新加载后保留的事实使用持久会话事件，对正在进行的工作使用实时智能体事件。能力事件让策略和适配器能够连接到子系统，而无需导入整个循环。

会话日志充当模型可见上下文的事实来源。DeepSeek 表示，任何进入模型请求的内容都必须能从该日志中重建。

这一选择连接了多项通常被独立实现的功能。恢复、分叉、转录记录、持久化、回放和遥测都可以从同一事件流中派生。

另一种做法是为界面、模型上下文、已保存历史和可观测性系统维护不同表示。这些副本可能会在错误、取消或上下文压缩后产生偏差。

DeepSeek 的设计无法自动消除偏差，插件实现仍可能存在缺陷。不过，统一的事件来源为开发者提供了一个明确的位置来检查发生了什么。

能力接缝又增加了一层。DeepSeek 通过服务接口、实现该接口的提供者，以及使用该服务的消费者来定义接缝。

考虑文件系统访问。面向模型的工具可能请求文件操作，而文件系统提供程序决定这些操作在何处、以何种方式执行。

替换提供程序可以将能力从本地工作区重定向到远程沙箱。相关的 shell、终端和语言服务器操作随后也可以共享该执行环境。

这是一种比在现有助手中添加命令更深层的模块化。它无需重写每一个使用方，就能改变助手工作的地点和策略。

子代理使用类似的边界。一个提供程序可能在 Harness 内创建子代理；另一个则可能将任务委派给独立产品，同时保留父级接口。

Cordis 提供底层组合模型。其配套的框架论文将时间可组合性描述为：移除一个组件并完全逆转其影响。

该论文将空间可组合性定义为声明依赖关系，并在共享上下文发生变化时作出响应。Cordis 通过可追踪副作用、依赖解析、配置协调和热模块替换来结合这些概念。

该论文以 2026 年 8 月 13 日的草案形式发布。作者警告称，这是一篇仍在积极修订中的预印本，其内容可能发生重大变化。

这一警告很重要。正式的术语体系可以让架构更容易讨论，但它并不能独立验证性能、可靠性或安全性。

DeepSeek 的机制仍然很有吸引力，因为它将理论与可观察的仓库结构相对应。架构文档列出了服务、包、事件、配置层和替换点。

其结果更像是面向代理的运行环境，而非单一助手。模型和工具是该环境中的应用，而上下文与事件系统则负责协调它们。

对开发者而言，好处是可控的重新组合。对 DeepSeek 而言，好处是战略覆盖面。其模型可以参与其中，但 Harness 并不要求整个生态系统依赖某一个模型家族。

开发者预览警告才是真正的风险

DeepSeek 的灵活性主张在代码中清晰可见，但其生产就绪性尚未得到验证，并且已被明确免责声明所限定。

仓库用全大写字母警告称，将会发生破坏兼容性的变更。这并非一条不起眼的发布说明，而是改变了组织应如何评估该项目。

团队今天可以试用 DeepSeek Harness，但不应假设 profiles、插件契约、配置文件或内部服务会在更新之间保持稳定。

对于围绕可替换接口设计的框架而言，这种不确定性尤为重要。即使架构尽量减少直接耦合，每个自定义组件仍依赖于某种契约。

如果这些契约发生变化，插件开发者就必须更新其实现。深度模块化可以控制变更的影响范围，但无法消除维护边界的成本。

配置也带来一种微妙风险。文档说明的分层系统会替换目标行的完整配置，而不是自动合并所有嵌套值。

这一规则对经验丰富的运维人员而言可能很可预测。但当用户以为局部补丁会保留未指定字段时，也可能导致设置缺失。

更大的挑战在于组合测试。一个成熟产品可以验证有限数量的模型、工具、沙箱和接口组合。

而允许每一层都发生变化的框架，会面临大得多的兼容性覆盖面。DeepSeek 无法现实地测试每一个第三方模型适配器与每一条工具流水线及存储提供程序之间的组合。

因此，责任转向 profile 作者和部署团队。他们必须测试自己计划运行的确切组合。

安全性同样需要谨慎对待。可替换的沙箱和工具策略为更强的隔离创造了机会，但可替换性并不保证配置安全。

宽松的子进程提供程序可能削弱经过严密限制的工具列表。自定义插件可能错误处理凭据、暴露敏感上下文，或绕过预期的审批行为。

开源有助于审查者检查这些路径，但并不意味着每个带有 dsh-plugin 主题的插件都经过了安全审计。

插件发现本身也会成为信任问题。开发者需要来源信息、版本兼容性、维护信号，以及理解哪些代码会获得会话或凭据访问权限的方法。

传统软件包生态系统已经在恶意依赖和被弃用模块方面苦苦挣扎。代理插件可能扮演更敏感的角色，因为它或许能观察提示词、源代码、工具结果和执行状态。

追加式日志带来了另一项权衡。详细的事件历史支持重放和审计，但存储的模型上下文可能包含专有代码、内部文档或敏感用户输入。

组织必须决定日志存放在哪里、谁能搜索它、保留多久，以及如何执行删除要求。

该框架将存储作为可替换的关注点提供。企业就绪性将取决于真实部署能否在不削弱重放保证的情况下配置保留和访问控制。

Google News 的关注也有可能将架构热情转化为缺乏依据的性能主张。DeepSeek 并未通过此次发布证明 Harness 能让其模型比竞争对手更准确。

此次发布没有提供中立基准来表明插件组合能够提升任务完成率。它也没有证明 Cordis 恢复机制能在长时间运行的工作中产生更好的结果。

一个强大的 harness 可以通过提供合适的工具和上下文，让模型变得更有用。但它无法修复底层模型的所有局限。

薄弱的规划仍然是薄弱的规划。不正确的工具选择依然可能导致失败。代理可能完整保留一次失败方案的日志。

发布后立即出现的用户报告可以提供有价值的线索，但不能替代受控测试。早期采用者本身具有选择性，配置各不相同，新鲜感也会影响判断。

开发者应使用具有代表性的仓库和可重复任务来评估该框架。测试应包括中断操作、被拒绝的权限、失败的工具、上下文压缩和插件升级。

他们还应比较等效的模型和工具配置。否则，积极结果可能反映的是更好的模型、更宽泛的权限集，或更简单的任务，而非 harness 本身。

DeepSeek 值得肯定，因为它准确标注了这次发布。开发者预览警告诚实地传达了该项目正快速演进的预期。

下一个问题是，随着采用规模扩大，DeepSeek 是否会保持这种清晰度。稳定的版本控制、迁移指南、安全报告和兼容性测试，将比最初的发布口号更重要。

Google News 关注之后该观察什么

三个信号将表明 DeepSeek Harness 会成为持久基础设施，还是仍只是一个备受赞赏的实验。

第一个信号是契约稳定化。开发者应关注发布说明中围绕插件、profiles、会话事件和能力接口定义的兼容性政策。

在早期预览阶段，破坏性变更很正常。重要的衡量标准是，这些变更是否逐渐收敛到有文档说明的稳定接口。

迁移工具将增强这一论点。明确的弃用周期和可由机器检查的配置 schema，将降低维护自定义 profiles 的成本。

如果 DeepSeek 能在不冻结架构进展的情况下稳定主要衔接点，其框架论点将更具说服力。反复重写插件集成则会削弱它。

第二个信号是独立的运营证据。团队需要涉及真实仓库、长会话、工具故障和受限沙箱的可复现测试。

任务成功只是一个指标。评估者还应衡量恢复行为、重复工作、上下文准确性、权限执行，以及诊断故障所需的工作量。

基准测试应将模型能力与 harness 行为区分开来。在可能的情况下，同一模型应在不同 harness 配置中运行。

可信的测试还应公布其权限和可用工具。拥有不受限制 shell 访问权限的代理，不应与在狭窄沙箱中运行的代理随意比较。

如果独立评估显示出可靠恢复和可检查的执行过程，DeepSeek 的机制就会获得支持。如果结果依赖大量人工调优，该框架将仍主要对专家更有用。

第三个信号是插件生态系统的质量。仓库数量和社交关注衡量的是好奇心，而非可靠供给。

有用的插件需要持续维护的文档、测试覆盖、安全实践和明确的兼容性信息。受信任的生态系统还需要报告恶意或被弃用软件包的流程。

DeepSeek 鼓励开发者为插件仓库添加标签以便发现。下一步是建立可靠方式，评估哪些扩展值得获得工具、会话和凭据的访问权限。

这一信号将决定谁会采用该框架。研究团队可以自行审计实验性模块。大多数企业团队则需要一组规模更小、受到支持且可审查的组件。

竞争对手在这三个信号中的反应也值得关注。竞争者无需复制 Cordis，便能验证 DeepSeek 的方向。

更多可替换沙箱、可导出的事件历史、文档化的代理循环，或更底层的编排 SDK，都将表明开发者正在要求界面之下的控制权。

沉默并不自动意味着失败。成熟产品仍可通过易用性、支持服务和集成式模型性能持续取胜。

对 DeepSeek 而言，最理想的结果将是市场分化。成熟代理将服务于希望获得连贯工具的用户，而 Harness 将服务于使用可互换组件构建专业代理的团队。

这种分化映照了更广泛的软件历史。框架和成熟应用通常会共存，因为它们解决的是不同的所有权问题。

知识工作者或许不会直接操作 DeepSeek Harness，但它的架构仍会影响他们。代理系统日益接触项目文件、内部研究、消息和组织知识。

当这些系统失败时，用户需要知道模型接收了哪些上下文，以及哪些工具执行了操作。可重建的事件历史可以让这类调查更具体。

构建相关 AI 工作流的团队，也应对其信息来源采用同样的严谨态度。一个持续维护的AI knowledge base可以保留围绕代理输出的文档和决策。

这种做法无法解决运行时安全问题，但能帮助人们区分生成的结论，以及用于得出这些结论的证据和机构上下文。

最终判断应保持聚焦。DeepSeek 已发布了一项严肃的架构提案，包含可运行代码、详细文档，以及对插件异常广泛的定义。

它尚未证明普通开发者能够安全地管理这种灵活性。它也尚未证明第三方组件会保持兼容，或该设计能带来更好的任务结果。

Google News 的标题抓住了令人难忘的想法，但未来三个月应通过稳定契约、独立运营测试和可信插件来评判。

如果你正在评估 DeepSeek Harness，先从一个边界明确的工作流开始。记录所用模型、工具、权限、配置档案及预期结果。随后中断运行、拒绝一次工具调用、更换一个提供商，并检查事件日志是否仍能解释结果。相比功能清单，这项演练更能有效检验 DeepSeek 的实际核心主张。关键不在于是否所有内容都能成为插件，而在于团队能否在不牺牲可靠性、安全性或理解其智能体行为能力的前提下替换这些插件。