如何看待 DeepSeek Harness？

核心回答

DeepSeek Harness 是 DeepSeek 开源的 Agent 运行框架，命令入口是 dsh。我比较看重它的 Everything is a Plugin 设计：基于 Cordis，连模型适配、工具注册、会话日志和 Agent 循环都作为插件组合，便于按应用替换其中一层，而不是每次修改整套运行系统。

它的价值主要在可组合的工程底座：用统一服务与事件连接模块，工具执行有参数、策略和结果管线，会话日志能重建模型看到的历史。代价是开发者需要理解插件依赖、作用域、生命周期和配置组合，并承担具体业务权限与验收。

截至 2026 年 11 月，官方仍将其标为开发预览。我的判断是适合研究和验证定制 Agent 路线；是否适合作为项目底座，应以固定版本、同一模型和任务下的实际完成、恢复行为与维护成本来决定，不能从插件化直接推导性能更好。

插件化具体解决什么问题

Cordis 通过共享上下文提供 ctx.tools、ctx.llm、ctx.sessions 等服务；插件声明所需服务，依赖就绪后再加载。事件用于观察或拦截运行过程，注册的监听器和能力在插件卸载时进行清理。

例如为代码助手增加企业工单能力，可以注册查询工单的工具；若要增加统一审核规则，可以在工具执行前接入策略；若要切换模型提供方，则实现相应适配器。这里的好处是改动沿明确扩展点进入，不必把所有业务逻辑写进 Agent 循环。

但“卸载可清理注册”不等于“撤销已经发生的业务操作”。插件取消了监听器，已经提交的工单或写入的数据不会因此自动恢复，仍需业务幂等、状态查询或补偿。

工具和状态有什么值得关注

工具层不只保存函数名称。dsh-tools 将工具说明与参数契约交给模型，执行前校验参数，并支持允许、拒绝、询问等策略以及执行前后的扩展点。普通工具失败会形成可反馈的结果，供后续判断，而不必直接结束整轮任务。

需要区分声明与实际执行：当前工具定义中的 timeoutMs 只是超时声明，真正限制截止时间还需要装配对应超时策略插件。工具也要合作响应取消信号，不能仅凭配置里有超时字段就认为进程一定会被终止。

会话层采用追加式事件日志，从记录中推导模型历史；压缩可以改变当前可见内容，同时保留历史记录，便于检查与分叉。dsh-session 本身将会话保存在内存，跨进程持久化需要额外后端。事件日志帮助解释“模型看到了什么、发生过什么”，也不等于所有外部副作用都能自动重放或回滚。

我会怎样评价实际适配收益

以修复一个带边界条件的代码缺陷为例，固定仓库、任务、模型和验收条件，对比现有运行层与 DeepSeek Harness：检查工具能否正确执行，失败反馈能否帮助继续，任务中断后能否恢复，最终改动是否满足要求。

进一步测插件更换与升级：替换一个模型适配器或权限策略时，需要改多少业务代码；插件卸载后是否残留监听器；恢复是否重复执行副作用。再结合总耗时、模型和工具调用次数、人工修正及版本升级成本判断收益。

对只需几个固定接口的小流程，插件体系可能增加理解成本；对模型、执行环境和策略经常变化的产品，可替换扩展点更可能体现价值。这是按任务约束做选择，不是给所有 Agent 排一个统一名次。

追问

它和 DeepSeek 模型是什么关系？

模型负责推理与生成，Harness 负责工具、上下文、状态与运行控制。评价某个模型的能力，与评价这个运行框架是否适合业务，是两组问题。

与自己写一个 while 循环相比，多了什么？

最小循环能连接模型和工具；这里进一步提供插件组合、服务依赖、策略扩展及会话记录等基础结构。是否值得引入，取决于这些共同基础能否减少自己的维护工作。

有会话日志就能无损恢复吗？

不能直接保证。先确认持久化后端、落盘时点和中断状态，再核对外部动作；未完成写入的记录或结果未知的调用仍需恢复策略。

参考资料