​摘要​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 核心版本安全与质量分级区分实验、可用、可信和高风险插件否则插件市场越热闹用户越需要额外工具来排障。什么时候适合 DSHDSH 更适合这些场景需要高度定制 Agent runtime要同时支持多个模型提供商和运行模式希望会话、工具、存储、审批、Loop 都能按场景替换能接受开发者预览阶段的 API 变化和调试成本愿意投入插件治理、安全审计和评测体系暂时不适合这些场景追求开箱即用和稳定生产交付token 预算很紧任务链路很固定外围工具扩展已经够用团队没有能力维护复杂配置和插件生命周期安全审计要求严格但还没有额外沙箱和插件审核机制结语DSH 的想法很有价值它把 Agent harness 里原本写死的部分拆出来让模型、工具、会话、存储和 loop 都有机会按场景组合。Cool 不等于 Ready。可塑性带来的每一分自由都会在 token、性能、调试、安全和生态治理上收账。更稳的判断是先把 DSH 当成架构样本借鉴 Cordis 的能力 seam、Session Log 的事实源设计、插件生命周期的清理模型。只有当团队真的需要多 runtime 长期并存、动态替换和插件生态治理时再考虑把完整 DSH 放进核心链路。