DeepSeek 开源 Agent Harness，运行时成为主角

DeepSeek 于 8 月 13 日发布了首个公开的 agent harness，使一则 Google News 标题演变为对封闭式智能体平台的直接挑战。这次发布之所以重要，是因为 DeepSeek 不再只提供模型；它还开放了让模型能够使用工具、管理会话、运行代码并完成更长任务的软件层。

这一名为 DeepSeek Harness 的软件层以 MIT 许可证发布开发者预览版。DeepSeek 用一条核心规则描述其架构：每个主要组件都是插件。开发者无需重建整个应用，就能替换模型、工具、技能、沙箱、文件系统、界面和编排逻辑。

此次发布改变了 DeepSeek 的竞争定位。根据该公司的评测，其 V4 模型已在推理和智能体基准测试中与 OpenAI、Anthropic 和 Google 的系统竞争。Harness 将竞争从模型质量转向对完整智能体技术栈的控制能力。

这正是这则 Google News 条目背后的真正冲突。开放模型过去需要依赖第三方软件才能成为实用的智能体。DeepSeek 现在希望，围绕模型的运行时也能像模型本身一样开放且可适配。

Google News 捕捉到 DeepSeek 超越模型的举措

DeepSeek Harness 将公司的智能体战略从整合承诺转变为公开的软件项目。

官方开发者预览版将 DeepSeek Harness（也称为 dsh）描述为开源 agent harness。Agent harness 是围绕模型运行的操作软件，负责管理工具、状态、执行、权限和用户交互。

DeepSeek 基于 Cordis 构建了该项目。Cordis 是一个面向插件的框架，旨在支持可挂载、替换或重新组合的组件。该公司用一句简洁的话概括这一设计：一切皆为插件。

这一原则远不止于模型选择。智能体需要一个决定下一步行动的循环、执行操作的工具，以及保留相关状态的存储机制。它还需要受控的执行环境、界面，以及协调这些部分的规则。

DeepSeek 将这些功能置于插件边界之后。这种方法让开发者能够替换其中一层，而无需重写其周围的所有依赖项。一个团队可以更换模型提供商，同时保留其工具、界面和会话格式。

反过来也同样可行。开发者可以保留模型，同时更换沙箱、工具目录或编排策略。这种灵活性将 DeepSeek Harness 与围绕单一固定助手和严格控制工作流构建的应用区分开来。

该项目可通过 npm 命令启动本地 Web 界面。DeepSeek 表示，该界面默认运行在本地机器上。开发者也可以克隆源代码、安装依赖并直接构建。

这些细节说明，此次发布并非只是一组提示词模板。DeepSeek 正在发布一个应用运行时，其中包含多个软件包、原生组件、文档、示例和开发工具。

MIT 许可证同样重要。它允许商业使用、修改和再分发，附带的义务相对有限。初创公司可以检查实现方式、加以适配，并构建产品，而无需等待 DeepSeek 通过托管服务开放每一项功能。

不过，该项目明确尚未完成。DeepSeek 警告称，开发者预览版将出现破坏兼容性的变更。每项早期评估都应考虑这一警告，因为当前的接口和配置模式并非稳定承诺。

这一时间点也将 Harness 与 DeepSeek V4 联系起来。该公司于 4 月发布 V4 预览模型，并围绕其扩展了面向智能体的主张。Harness 提供了这些模型持续执行任务所需的执行层。

因此，Google News 的标题只捕捉到了可见事件。更深层的变化是战略性的：DeepSeek 正试图同时定义智能本身，以及让这种智能投入工作的机制。

Agent Harness 现已成为竞争层

模型产生决策，但 Harness 决定这些决策能否转化为可靠行动。

语言模型可以提出终端命令、识别文件或选择 API。但若没有能够追踪状态、验证请求、处理失败并返回结果的软件，它无法安全地执行这些步骤。

这种外围软件正日益决定智能体的实际质量。即使使用同一个模型，两款产品也可能表现得截然不同，因为其 Harness 管理上下文、工具和错误的方式不同。

以一项跨越多个文件的编码任务为例。模型首先需要准确了解代码仓库。它必须选择文件、编辑文件、运行测试、解释失败原因，并判断是否需要再次修订。

每一步都会引入必须保持一致的状态。工具输出必须返回到正确的会话。系统必须区分命令失败与命令完成，并防止智能体将部分输出误认为成功。

长任务带来的压力更大。上下文不断增长，早先的决策更难检索，重复调用工具也会创造更多出错机会。更好的模型有所帮助，但无法消除这些系统性问题。

近期的 agent harness 研究将代码视为推理、行动、环境建模和验证的操作基础。研究还指出，记忆、监督、共享状态和评估方面仍有未解决的问题。

DeepSeek 的插件结构回应了其中一部分问题。它为开发者提供了插入不同工具、存储、界面和控制循环的明确位置。该架构将智能体视为可替换服务的组合，而非不可分割的单一产品。

这种差异影响着谁来控制工作流。封闭式智能体应用通常决定可用工具、会话的表示方式，以及每个请求由哪个模型接收。用户可以配置产品，但很少能够控制其内部边界。

开放 Harness 暴露了更多此类选择。企业可以检查一个工具如何变得可用，在执行前加入策略检查，或将敏感操作隔离在更严格的沙箱中。

它也能将智能体连接到私有系统，而无需让每个工作流都经过单一供应商的界面。这对于受监管的工作、内部开发环境以及拥有专业基础设施的组织尤为重要。

这种架构并不会自动让部署变得安全。开源代码使检查成为可能，但检查仍需要时间和专业知识。配置不当的开放 Harness 可能带来与封闭式系统相同的运营风险。

不过，可检查性改变了买方的选择。团队可以追踪行为、修改控制措施，并在托管服务改变方向时保留一个可运行的实现。

这正是 Harness 成为竞争层的原因。模型提供商曾预计由独立框架处理编排。DeepSeek 现在显然不愿将这种关系完全交给外部项目。

DeepSeek Harness 向封闭式智能体平台施压

DeepSeek 正在挑战这样一种观念：最佳智能体体验必须依附于专有运行时。

Anthropic、OpenAI 和其他提供商已经构建了智能体产品，将模型与精选工具及经过精细调校的执行系统结合起来。它们的优势部分来自于控制从用户请求到最终行动之间的完整路径。

这种控制有助于实现一致的产品行为。供应商可以协同优化提示词、工具格式、上下文管理和安全检查。它可以更新每一层，而无需与多位独立维护者协调。

同样的整合也会造成依赖。客户可能依赖专有的会话格式、工具接口或工作流行为，而这些内容无法顺畅迁移到其他模型。仅切换模型并不能解决这个问题。

DeepSeek Harness 提出了相反的主张。模型成为更广泛运行时中的一个插件，其他组件则保持可替换性。原则上，团队可以测试另一种模型，而不必放弃其余的智能体环境。

这是一场路径与控制权之争，而不只是 DeepSeek 与某一家美国实验室之间的竞争。封闭平台通过垂直整合承诺提供成熟体验。开放 Harness 则通过暴露的边界承诺提供适应性。

DeepSeek 的模型定位让这一承诺比未知框架供应商提出时更具可信度。其 V4 发布详情介绍了两款拥有一百万 token 上下文窗口、并针对智能体进行专门优化的模型。

DeepSeek 表示，V4-Pro 总参数量为 1.6 万亿，推理时活跃参数为 490 亿；V4-Flash 总参数量为 2840 亿，推理时活跃参数为 130 亿。这些仍是公司自行报告的规格和性能主张。

该公司还表示，两款模型均可通过其服务支持思考和非思考模式。这让 Harness 开发者无需切换到不同模型家族，就能获得多种性能配置。

不过，Harness 的架构范围比 DeepSeek V4 更广。只有当开发者能够跨提供商和部署方式进行实验时，将模型视为插件才具有战略意义。

这种可能性从两个方向向模型公司施压。第一，它们必须在模型性能上竞争，而不能假设客户会采用其完整的智能体环境。第二，它们的专有 Harness 必须提供足够价值，才能证明更紧密的依赖关系是合理的。

现有的开放式智能体框架同样面临压力。DeepSeek 并非进入一个空白市场。开发者已经在使用支持多种模型的编排库、编码智能体、终端助手和自动化框架。

DeepSeek 的优势在于模型工程与 Harness 工程之间的直接协同。它可以让运行时适应特定模型的行为，同时公开这些适配以供检查。

它的劣势则是中立性。独立框架可以声称没有任何模型供应商控制其路线图。DeepSeek 必须证明，当用户选择竞争模型或替换 DeepSeek 专属组件时，其插件承诺仍然具有实质意义。

该公司自身的发布措辞并未解决这个问题。开发者需要检验，替代插件是否能获得同等的支持、文档和维护。

如果 DeepSeek 成功，竞争单位将发生变化。买方将共同评估模型、Harness、插件集合和部署路径。仅凭基准分数将越来越难揭示最终的智能体体验。

一切皆为插件：解决一个问题，也创造另一个问题

模块化增加了选择空间，但每个可替换组件都会形成新的兼容性和安全边界。

插件架构可以让智能体系统更易于适配，但也会让系统更难理解，因为其行为来自多个独立配置组件的共同作用。

假设一家公司用连接到共享工程目录的插件替换默认文件系统插件。新插件必须执行路径限制、处理符号链接，并防止对获批工作区之外资源的非预期访问。

沙箱插件承担着类似职责。它必须决定哪些命令可以运行、网络访问范围如何，以及进程能否从环境中读取凭据。

这些并非无关紧要的实现细节。它们决定了一名仅提出操作建议的助手，与能够改变公司系统的智能体之间的差别。

工具权限同样需要结构性约束。通过提示词告知模型不要修改生产数据，其约束力弱于工具层根本不提供生产环境写入操作。

插件边界可以帮助团队明确这种限制。只读数据库插件可以完全省略变更方法。不过，这项保障取决于每个相邻组件都遵守同样的边界。

第三方插件会带来供应链风险。一个实用扩展也可能访问会话记录、工具输出、源文件或认证令牌。团队需要建立与这些资源敏感程度相匹配的审查流程。

版本频繁变动会加剧这一问题。DeepSeek 警告称，预览期间将发生破坏兼容性的变更。今天可用的插件，可能会在核心接口变更后失效；更糟的是，它也可能继续运行，但行为已经改变。

该项目在 GitHub 上的快速增长表明市场兴趣浓厚，但受欢迎并不等同于具备生产就绪性。Star 和 Fork 更直接衡量的是关注度，而非可靠性、安全性或维护质量。

最重要的评估缺口在于完整任务。模型基准测试可以评判答案，或验证补丁是否通过测试；但它们往往较少揭示智能体如何从工具中断、状态损坏或权限含糊中恢复。

一个智能体可能在基准测试中表现成功，却依然不适合长期访问敏感系统。企业需要关于可审计性、故障遏制能力，以及跨长会话可复现性的证据。

同样的担忧也适用于记忆。一个运行框架或许能保留大量上下文，但留存的信息可能过时，或在任务之间泄露数据。更多记忆并不自动意味着更好的记忆。

知识工具需要可追溯的来源、受控的留存机制，以及隔离无关项目的方法。已经在建设可搜索知识库的团队，应在将其接入自主循环前评估这些控制措施。

DeepSeek 的架构提供了可承载此类控制措施的位置，但并不能证明每个默认插件或社区插件都会正确实现它们。

这正是核心权衡。开放式组合让开发者对智能体设计拥有更大控制权，同时也将更多验证、集成和维护责任转移给开发者。

此次发布重新界定了 DeepSeek V4 的智能体主张

DeepSeek Harness 提供了一个公开环境，用于测试 V4 的智能体表现能否在基准测试条件之外延续。

DeepSeek 将 V4 介绍为一个在推理、知识与智能体能力方面有所提升的模型家族。该公司表示，V4-Pro 在智能体编程基准测试中取得了开源模型中的领先结果。

独立报道对这些结果持谨慎态度。关于 V4 发布的报道指出，分析师希望在对竞争表现作出最终结论前看到独立评估。

这种谨慎对于智能体更为重要，因为一个分数既可能反映模型本身，也可能反映其运行框架。工具描述、重试逻辑、上下文格式和执行策略都会显著影响结果。

通过高度调优的内部运行框架评估的模型，在通用框架中的表现可能不同。反过来，一个能力普通的模型，也可能因周边运行时提供了更好的状态管理与验证而获得提升。

发布 DeepSeek Harness 让研究人员多了一个可审查对象。他们可以比较 V4 在该公司首选运行时中的表现，与其在独立系统中的表现；也可以通过 DeepSeek 运行时测试其他模型。

这些比较能够将经常混在一起的三个问题区分开来：模型有多强？运行框架有多有效？两者作为组合时协作得如何？

这些答案对于采购很重要。选择智能体平台的公司，需要的不只是报告分数最高的模型，而是一个能在其文件、工具、政策和故障模式下稳定运行的系统。

现实的编程评估可能包含一个文档不完整的代码库、不稳定的测试，以及一个无法访问网络的依赖项。智能体必须识别这些条件，而不是反复尝试同一个已经失败的操作。

企业工作流还会提出其他要求。系统可能需要在发送电子邮件、修改记录或发布内容之前获得批准，并且必须保留证据，说明每项操作是由哪条指令引发的。

由于组件均已开放，DeepSeek Harness 可以支持围绕这些需求的实验。研究人员可以修改循环、限制工具，或替换会话存储，而无需等待托管产品更新。

不过，公开代码并不保证结果可复现。评估者仍需要固定版本、记录完善的配置、固定的工具环境和完整的执行轨迹。

他们还必须披露，某项结果来自 DeepSeek 的最小化配置、更丰富的工具集合，还是自定义插件栈。否则，运行框架会成为另一场误导性比较中不可见的变量。

最公平的测试应在匹配的权限和资源条件下比较系统。拥有不受限 Shell 访问权限的模型，不应在未解释差异的情况下与仅限使用狭窄编辑器的模型进行排名比较。

因此，Google News 读者应将此次发布视为测试邀请，而非胜利宣言。DeepSeek 已经开放了智能体行为背后的机制，但社区仍需对其进行衡量。

开发者和企业买家接下来应关注什么

下一阶段的证据必须来自兼容性、独立任务结果和可强制执行的控制措施，而不是发布当天的关注度。

第一个信号是插件互操作性。开发者应关注随着预览版演进，独立的模型、工具、存储和沙箱插件能否持续正常运行。

健康的插件系统不仅需要扩展点，还需要稳定的契约、迁移指引、版本兼容性，以及能在部署前暴露破坏性行为的测试。

如果 DeepSeek 在支持第三方提供商的同时发展出这些实践，其开放运行时的论点将更具说服力。如果插件反复损坏，或依赖未记录的内部机制，这套架构就会显得开放，却无法可靠移植。

第二个信号是独立评估。研究人员应在同一个运行框架内测试 DeepSeek V4 和竞争模型，然后在不同运行框架中重复比较。

这些研究应衡量的不只是最终任务完成情况。有用的指标包括工具失败后的恢复、不必要的操作、权限违规、上下文丢失，以及已完成工作的可复现性。

结果还应区分简单任务和长周期工作流。DeepSeek 曾表示，V4-Flash 在简单智能体任务上的表现与 V4-Pro 相当。更长的任务将更能揭示这种关系是否成立。

如果独立发现复现了 DeepSeek 的表现，将增强该公司关于其模型和运行时构成具竞争力智能体栈的主张。若不同运行框架之间的性能变化很大，则说明编排仍是决定性变量。

第三个信号是安全治理。企业应关注权限控制、审计日志、插件来源、隔离保障和明确的漏洞政策。

可信的安全模型必须说明每个插件可以访问什么，以及这些权限如何被强制执行。它还应展示管理员如何在不依赖提示词指令的情况下撤销能力。

买家应询问会话是否可以重放、导出、删除，并按工作区隔离。他们还应测试工具返回格式错误的数据，或插件在任务进行到一半不可用时会发生什么。

他们也应审视谁在维护关键扩展。一个拥有广泛文件系统或网络访问权限的社区插件，值得受到与任何特权内部服务同等程度的审查。

DeepSeek 的开发者预览警告应在整个过程中保持醒目。该项目适用于受控实验，但该公司并未将其定位为稳定的企业平台。

对于个人开发者而言，最有用的首次测试是受限的本地工作流。为运行框架提供一个可丢弃的代码库、有限的凭据，以及一个结果可验证的任务。

观察其决策，而不只是结果。检查它读取了哪些文件、运行了哪些命令、如何应对失败，以及其他人能否重建其执行路径。

对于组织而言，决策应从工作流所有权开始。确定哪些组件必须保持可移植、哪些数据不能离开受控基础设施，以及哪些环节必须获得人工批准。

然后比较完整系统。与不可靠运行框架搭配的低成本模型，可能会带来昂贵的监督工作；而一个成熟的封闭式智能体，一旦其运行时成为日常运营的核心，也可能带来迁移成本。

这则 Google News 报道之所以重要，是因为 DeepSeek 更清楚地揭示了这一选择。该公司主张，智能体基础设施应当可检查、可组合，并可在单一托管服务之外使用。

这一主张能否成立，取决于开放组件能否在真实运营压力下协同工作。兼容性故障、薄弱的权限边界或不一致的评估都会削弱这一论点。

开发者现在拥有了一个可以具体审查的产物。下一步不是接受“一切皆为插件”的口号，而是测试这些插件能否构建出一个在工作变得困难时仍保持可理解性的智能体。

在将配备真实工具的智能体交付信任之前，你当前 AI 工作流中的哪一部分最需要由你控制：模型、记忆、权限，还是执行环境？