DeepSeek Harness 不是银弹：一切皆插件背后的工程账

摘要：DeepSeek Harness 更像 Agent runtime 基础设施，不像现成办公软件。它把 Model Adapter、Tool Registry、Session Log、Agent Loop、调度、存储和 UI 都做成可替换插件，适合研究和定制。采用前要算清 token、性能、调试、安全和生态治理成本。

DSH 是底座框架

DeepSeek Harness 火起来以后，最容易出现两种反应：要么把它当成下一代 Agent 标准答案，要么因为早期毛刺太多直接否定。

图：插件化收益背后仍要支付性能、调试和治理成本

这两种判断都太快。

DSH 的确提出了很有野心的架构：把 Model Adapter、Tool Registry、Session Log、Agent Loop、调度、存储甚至 UI 都做成可替换插件。它要解决的是“Agent = Model + Harness”里 Harness 如何长期演进，而不是简单增加一个工具。

灵活性有明确成本。一切皆插件会带来上下文成本、运行时开销、调试复杂度、安全边界和生态治理压力。要不要采用 DSH，不能只看它有多可塑，还要算清楚这笔工程账。

DSH 和 Claude Code、Codex 这类开箱即用的编程助手不同。它更接近一套 Agent runtime 基础设施。

模型负责推理，Harness 负责模型之外的工程部分：工具调用、会话管理、沙箱、存储、执行调度、循环控制、可观测性。DSH 把这些能力进一步插件化，让开发者可以在配置层替换它们。

这让 DSH 很适合研究和定制，也意味着它离稳定、省心、低成本的生产工具还有距离。

一切皆插件改的是 Harness 边界

传统 Agent 框架通常是“固定内核 + 外围扩展”。工具、Hook、Skill 可以扩展，但会话、存储、主循环、模型适配往往由框架固定。

DSH 更激进。它把 Harness 自己也拆成插件：

组件	在 DSH 中的定位
Model Adapter	可替换模型提供商和协议适配
Tool Registry	可替换工具注册和执行策略
Session Log	可替换会话事实存储
Agent Loop	可替换智能体循环
Storage / Persistence	可替换持久化后端
UI / Runtime Profile	可按场景装配

底层支撑是 Cordis。它提供两类组合能力：

能力	作用
时间可组合性	插件卸载后，已登记的监听器、注册项、资源句柄应能被清理
空间可组合性	插件声明依赖，依赖出现、消失或替换时，运行时自动协调生命周期

这套机制适合多租户、多 Provider、多工具生态、多运行模式共存的场景。它不应该被简单理解成“插件市场更大”。

第一笔账：上下文膨胀

DSH 追求灵活性和可观测性，会把成体系的运行时信息注入模型上下文：工具 schema、Skill registry、系统提示词摘要、能力说明、策略约束。

这会带来直接成本：

简单任务也要携带庞大的系统信息
每个 MCP server 和工具定义都会增加上下文长度
复杂 preset 会让模型在每轮处理重复信息
长任务中的压缩、投影、恢复又会增加管理成本

有公开评测提到，DSH 在某些任务里的 token 消耗达到数十万级，甚至显著高于轻量 harness。具体数字要看模型、preset、工具集和任务，但方向很清楚：可塑 runtime 会把一部分复杂度转成 token 账单。

这不是 DSH 独有的问题。凡是把能力面大规模暴露给模型的系统，都会遇到上下文经济性问题。区别在于，DSH 的设计更容易把这件事放大。

第二笔账：更多 LLM 往返

Agent Loop 可替换是一把双刃剑。

它给开发者更多控制权，可以加入验证、重试、状态维护、停止策略和工具编排。但每一次“思考、行动、观察、再判断”都会产生模型往返。为了防止过早停止或执行不完整，Harness 往往会变得更谨慎，步骤也更多。

固定 loop 的好处是稳定、可预测、易优化。可替换 loop 的好处是可定制、可实验、可适配复杂场景。选择哪一种，取决于你要解决的是业务流程问题，还是 runtime 研究问题。

第三笔账：运行时和依赖开销

插件化会把系统切成很多小组件。组件越多，依赖解析、事件派发、生命周期管理、配置装配、资源清理的成本越明显。

公开体验里已经出现一些典型现象：安装依赖包数量多，Node.js / TypeScript runtime 带来额外内存开销，多窗口或 GUI 包装后资源占用明显，某些插件组合还可能重复初始化昂贵资源。

这些问题不能单独证明 DSH 架构不行。开发者预览阶段出现性能毛刺很正常。它提醒我们：如果目标只是跑一个固定 coding loop，引入一整套可重组 runtime 未必划算。

成本来源	可能后果
依赖包数量多	安装慢、版本冲突、供应链审计压力
Node.js 主进程解析大日志	UI 卡顿或服务假死
插件重复初始化资源	内存膨胀、容器 OOM
动态装卸链路	问题定位从调用栈变成配置树 + 生命周期排查

第四笔账：Session Log 是优势，也是风险

DSH 的 append-only Session Log 很重要。它让系统可以恢复、分叉、回放，也让模型可见上下文能从事实链重建。

只追加日志不是魔法。它会带来三类问题。

第一是并发写入。如果多个进程共用同一个 DSH_HOME 并写同一会话日志，序列号和日志完整性就可能出问题。

第二是读取性能。大日志、损坏日志或事件数量过多时，服务端全量读取、解压、解析和校验可能阻塞主线程，导致 UI 或接口不可用。

第三是恢复语义。日志能证明某个工具调用被请求或记录过，但不能自动判断外部副作用是否已经发生。一次远程写入如果结果丢失，系统不能简单重放，否则可能造成重复提交。

Session Log 是事实源，不是事务系统。

第五笔账：插件化不等于安全

DSH 的工具执行需要面对高风险动作：文件读写、命令执行、代码运行、网络访问、外部提交。

Cordis 的 Context 可以约束依赖可见性，Effect 可以清理已登记副作用，但它们不能替代真正的安全隔离。不可信代码仍然需要进程、容器、WebAssembly、microVM 或系统级沙箱。

公开安全评估也提醒了一个现实问题：间接 prompt injection 不会因为 harness 更工程化就消失。恶意指令可能藏在网页、文件、邮件、聊天记录或 Skill 内容里。只要 Agent 会读取这些内容并具备敏感工具权限，就必须有权限分级、审批、数据外发限制、工具结果审计和安全回归。

安全设计不能只做“工具调用前弹窗”。真正需要的是：

按工具和数据类型分级授权
对外发、删除、部署、支付等动作强制确认
对读取内容中的指令注入做隔离和标注
对插件来源、构建脚本和版本兼容做审查
把安全失败作为晋升或发布的否决条件

第六笔账：生态越大，治理越难

插件生态是 DSH 的吸引力之一，也会成为风险来源。

插件数量增长很快时，质量判断会变成难题。README、Star、更新时间都不够。实际安装时可能遇到依赖下载失败、版本不兼容、构建脚本风险、环境变量缺失、插件没有正确注册等问题。

如果官方讨论区被广告和低质量项目淹没，开发者就很难判断哪些插件值得信任。插件生态要想变成生产能力，至少需要三件事：

治理项	目的
安装验证	确认插件能构建、能注册、能通过基础用例
版本兼容矩阵	明确插件适配哪些 DSH 核心版本
安全与质量分级	区分实验、可用、可信和高风险插件

否则插件市场越热闹，用户越需要额外工具来排障。

什么时候适合 DSH

DSH 更适合这些场景：

需要高度定制 Agent runtime
要同时支持多个模型提供商和运行模式
希望会话、工具、存储、审批、Loop 都能按场景替换
能接受开发者预览阶段的 API 变化和调试成本
愿意投入插件治理、安全审计和评测体系

暂时不适合这些场景：

追求开箱即用和稳定生产交付
token 预算很紧
任务链路很固定，外围工具扩展已经够用
团队没有能力维护复杂配置和插件生命周期
安全审计要求严格，但还没有额外沙箱和插件审核机制

结语

DSH 的想法很有价值：它把 Agent harness 里原本写死的部分拆出来，让模型、工具、会话、存储和 loop 都有机会按场景组合。

Cool 不等于 Ready。可塑性带来的每一分自由，都会在 token、性能、调试、安全和生态治理上收账。

更稳的判断是：先把 DSH 当成架构样本，借鉴 Cordis 的能力 seam、Session Log 的事实源设计、插件生命周期的清理模型。只有当团队真的需要多 runtime 长期并存、动态替换和插件生态治理时，再考虑把完整 DSH 放进核心链路。

AI小老六