DSH：用插件组装运行器，安排工具协作

DSH 是 DeepSeek 开源的 DeepSeek Harness。Harness 可以先理解成“让模型持续工作的运行器”：它联系模型、管理会话、安排工具，并把执行结果交回模型。DSH 用插件提供这些能力，让应用可以按需要组装它们。

例如，模型一次提出读取三个文件。运行器要决定哪些读取可以同时开始、最多同时做几个，以及结果按什么顺序交回去。本篇从这件具体的事看 DSH 的设计。

工具怎样从请求走到结果

假设这三个调用依次是 A、B、C。程序先检查每次调用的输入和执行条件；需要用户审批时，必须获得允许才能继续。准备好后，允许并行的工具可以同时工作。结果出来后，程序按原调用顺序提交结果，让下一轮模型能把每个结果和自己的请求对应起来。

工具执行可以重叠，事件结果仍按调用序列提交

部分	怎样接入	负责的事情
应用组合	用插件框架 Cordis 组织插件，通过配置方案（profile）和组合包（bundle）选择服务；精简 SDK（`sdk-minimal`）也可单独接入	把模型、会话和工具等服务组装起来
工具调用	准备、审批、执行、后处理各有调用入口	检查输入和许可，执行工具，再提交对应结果
执行环境	文件系统、子进程服务和 bash sandbox 执行器	让工具使用同一执行环境，并按实际策略限制命令能访问的资源

表格依据固定版架构说明和文件系统、子进程服务说明。工具如何通过检查、执行和返回结果，可以接着读代码导读。

批次调度器限制同时执行的工具数，源码把这叫“有界池”。在允许并行的情况下，B 可以比 A 先做完；但负责提交结果的 commitReady() 会先等 A，再提交已经准备好的 B。读者可以把它想成：几个人同时做事，报告仍按任务单的顺序摆放。

这样的好处是结果顺序稳定，代价是前面的慢工具会让后面的结果多等一会儿。实际能同时执行多少，还要看并发上限和各工具的执行模式。上图画的是批次内的结果顺序；工具在外部做的事情仍可能按完成先后发生。

第一，调用要求询问用户、却没有可用审批服务时，这次调用会被拒绝。第二，bash sandbox 执行器采用 danger-full-access 策略时，会使用无约束的基础执行方式。沙箱（sandbox）是否生效，要看这次命令实际用了什么策略。

上游 SAFETY.md说明，此开发者预览尚未经过安全审计。尝试运行不可信代码时，需要另外保护真实文件、凭据和网络访问，不能只依赖它的沙箱与审批。本书尚未运行该 Harness。

Pi把循环核心与终端会话应用分开；DSH 更强调将多种服务作为插件组合。对照阅读时，先找两件事：新能力从哪里加入，工具从开始到结束由谁管理。这里比较的是组织方式，性能和易用性需要另做评测。

读完这页，可以用 A、B、C 的例子向别人解释“做完”和“交回结果”的区别。需要先熟悉基本循环的话，回到 Agent loop即可。

本文依据官方仓库 deepseek-ai/deepseek-harness@477b4f420553e8a52c2fbccc464d7561b239c443，核对日期 2026-09-27。根许可证为 MIT，另有第三方说明。这是开发者预览版，本篇只读了相关源码，尚未安装或运行它。

假设模型依次提出 A、B、C 三个工具调用。图从左往右，区分“开始做事”“做完了”和“把结果交回”三个时刻。

程序先记录请求，再准备每次调用，检查输入与执行条件。需要询问用户时，先取得允许才执行。图中 ask 指需要询问；缺少审批通道时，该调用在这里被拒绝，不会交给工具执行。图里的 dispatch 指实际派发执行，无需询问的调用按自己的规则继续。

允许并行时，“有界池”限制最多同时执行几个工具。假设 B 比 A 快，B 先做完就先保留结果；图里的 ready 表示结果已经准备好。负责交回结果的 commitReady() 要等 A 就绪，再依次交回 A、B、C。于是完成顺序可以是 B、A、C，交回顺序仍是 A、B、C。

下方虚线提醒的是外部操作：B 若修改远端数据，修改可能在它交回结果之前就已发生。图中“日志按调用顺序记录结果”说的是交回结果的次序，工具实际做事仍可能重叠；已发生的修改也要单独处理，这套提交次序没有提供事务回滚。

本图根据固定版的 executeToolCalls / runGroup 整理，版本和源码见正文，尚未采集实际运行记录。完整循环、其他插件、模式切换与取消细节留到后续阅读；运行安全和 MCP 画布与导出的一致性也未在此验证。

在线预览稿：书稿仍在校稿，系统篇以文内固定源码版本为准；静态阅读不等于运行验收。发现错误或有改进建议？按本章填写邮件，或查看反馈说明。

书稿提交：33f7dcdf7ac3。