正在加载，请稍候
DeepSeek Harness（dsh）开源后，自建还是采购 Agent 运行时？从定制深度、维护人力、评测能力、沙箱安全 4 个判断维度出发，附 GitHub 两周近 20 万 star 实证、npx 启动细节与 0.1 预览版供应链审查要点。
2026-08-26，DeepSeek 发布 Harness（dsh）开发者预览版，把模型适配、工具注册、沙箱、事件分发全部拆成独立插件；GitHub 仓库上线两周已接近 199626 star。
自建智能体运行时的决策，从"自己写循环"变成了"选一套底座"。本文拆解它与一体化框架的差异，再给出 4 个判断维度。站内《Agent Framework 运行时选型：98.4% 代码是护栏不是模型》提过一个结论：运行时的大部分代码不是模型，而是护栏。dsh 把护栏变成了可替换插件，但判断逻辑不变。
dsh 不是又一个编排框架，而是智能体执行运行时。仓库自述 Everything is a Plugin，基于 Cordis 元框架实现微内核：模型适配器、工具注册表、沙箱环境、会话状态处理器、事件分发器和用户界面都作为独立扩展加载，彼此隔离、可替换，而不是单体系统的模块。配置通过 YAML 或 JSON 声明式定义环境约束、插件依赖和运行时参数，切换远程 API 与本地模型服务器、替换执行工作流都不动核心逻辑。
对比 LangChain（仓库自述 The agent engineering platform）和 CrewAI（多角色编排框架），一体化框架把"智能体怎么跑"写死在 SDK 抽象里：换模型端点、改工具策略，通常要跟着框架版本走；LangChain 自己也在往托管方向收缩（2026-08-08 公测托管智能体，见8 月 8 日 AI 早报）。dsh 走的是相反路线：把运行过程下沉为可装配的插件层。插件化不是孤立信号，8 月中旬的《开源底座重开选型窗口》已提示过权重开放与插件化框架叠加的工程含义。
| 配置 | 内置工具集 | 适合的业务场景 |
|---|---|---|
| Standard | Shell 执行 + Web 检索 | 通用研究 / 任务型智能体，内部知识问答、调研助手 |
| Code | SDK 接口，编程化批处理多步工具调用 | 批量任务、数据管道、CI 流水线里按脚本驱动的执行单元 |
| Minimal | 持久化 Shell 会话 + 文本编辑 | 代码仓库内改造、受控低权限环境，压缩攻击面 |
| Creator | 诊断环境 | 插件开发调试、验证自定义扩展行为 |
选配置的本质是回答"执行单元要碰什么"。只做检索就上 Standard，跑批处理就选 Code，改仓库文件就压到 Minimal，先定边界再选，不要被框架默认值带着走。
dsh 内置一个仅追加的事件日志子系统：每条用户消息、工具调用、中间推理状态、Token 指标、子智能体派发都记录到统一的执行轨迹里。这套结构化数据可直接用于历史回放、错误隔离、跨模型基准测试，也能在开发环境评估决策路径。
对 B 端企业来说，这是"敢不敢把智能体放进生产"的前提：可观测、审计、故障复盘都要有据可查。但日志只是原料，闭环还需要有人消费——接入自己的回归集、埋点平台或可观测系统。基础设施组件本身也在快速演进（见《智能体基础设施迁移：K3开源、托管升级与搜索组件三线并进》），日志格式能否对接你的现状，直接决定迁移成本。
要替换模型端点、自研工具、定制沙箱策略的团队，插件化运行时的收益最大；只跑通框架默认行为的话，配置换来的灵活度用不上，反而多背一层维护。
0.1 预览版迭代很快，契约可能破坏性变更。要算清谁跟进 upstream、谁维护内部 fork 和插件兼容层。没有专职人力，就不要在生产依赖未稳定的底座。托管与自建的取舍可参考《智能体基础设施托管化元年》对 Astra、Kitesurf 等托管运行时的风险拆解。
已有评测 / 回归体系的团队，要看 dsh 日志格式能否对接；还没有评测能力的，日志反而是补短板的机会。两者都没有且短期不打算建，采购成熟托管平台更省事。
Shell、Web、文件工具的执行边界直接决定合规风险；dsh-plugin 生态刚起步，第三方插件要按供应链标准审查。金融、政务等强合规场景建议先做沙箱隔离验证再谈落地。
官方 README 写得很直白：当前处于开发者预览阶段，THERE WILL BE COMPATIBILITY-BREAKING CHANGES。仓库 2026-08-13 创建，截至 2026-08-27 约 199626 star、22780 fork；本地启动命令是 npx @deepseek-ai/dsh web，Web UI 默认监听 127.0.0.1:3080。社区讨论集中在响应式生命周期管理和动态插件注册上，插件生态仍在早期。InfoQ 的判断是：能否被广泛采用，取决于插件生态稳定性、API 长期维护以及与现有开发工作流集成的能力。务实路线是先拿低风险场景做 PoC，生产依赖等 1.0 或至少契约冻结。
不能简单替换。dsh 是执行运行时，LangChain/CrewAI 是编排框架，抽象层次不同。更现实的组合是先让 dsh 跑通运行层，把编排逻辑通过插件接进来，而不是全量迁移。
官方明示会有破坏性变更，建议先做 PoC 和沙箱验证，关键业务等 1.0 或契约冻结后再依赖。
传统日志记录进程行为，dsh 的事件日志记录决策轨迹：消息、工具调用、Token 指标、子智能体派发统一可回放，更适合评测和故障隔离。
不建议。预览版维护成本高，没有人力跟进 upstream 和插件兼容，优先选成熟托管平台或一体化框架。