DeepSeek Harness 源码解析 · 第 21 讲
DeepSeek Harness 源码解析系列 第 21 讲：代码执行运行时（code-runtime） 基于 DeepSeek Harness 源码 · 2026-09-05 💡 本讲一句话： 模型写的代码凭什么敢直接跑？DeepSeek Harness 的答案是：把它关进一个 全新 worker 线程 ——空环境、堆上限、按"事件循环忙时"计费的预算，宿主把 worker 发来的每条消息都当敌意输入逐字段重建；日志先流式落地，进程被杀也留得住。读完你能带走一套"跑不可信代码而不崩宿主"的完整工程清单。 一、一个能力，两个包：seam 与 backend 第 20 讲我们看了 MCP 怎么把外部工具接进来；这一讲看 harness 自己内置的一种更激进的能力： 让模型直接写一段程序来编排工具调用 （code-mode 的 run_code ）。这段代码是模型生成的、不可信的，harness 却要在自己的进程里执行它。整个能力拆成两个包： 包 角色 关键内容 @deepseek-ai/dsh-code-runtime seam（契约）：Service Definition + 纯类型词汇表，不含任何执行逻辑 CodeRuntime 抽象类、CodeRunRequest/Result/Failure、跨后端共享的保留名集合 @deepseek-ai/dsh-code-runtime-worker-thread backend（实现）：worker 线程里跑程序 + 宿主侧驱动与预算 消息协议、扁平 JSON wire 编解码、LogBuffer/OutputLedger 字节账本、ELU 忙时预算 seam 包只回答"调用方交什么进来、拿什么回去"，它对工具和会话 一无所知 ——那些是消费端（code-mode）的事。backend 包才关心 worker 线程、类型剥离、消息端口和字节账本。这个拆分的直接收益：契约里所有保留名集合都是"跨后端共享"的，今天只有 TypeScript/worker-thread 一个已发布后端，但同一份命名空间列表将来对 Python 后端也必须有效——可移植性承诺写在 seam 层，而不是散落在各 backend 里各自为政。 二、契约：错误是"字段"，不是 reject types.ts 只有类型没有运行时代码。最关键的约定藏在 CodeRunResult 的注释里：程序失败是 已 resolve 结果上的一个字段 ， run() 本身几乎不 reject——"报告一个失败的程序是调用方的职责，不是异常路径"。 📄 packages/code-runtime/code-runtime/src/types.ts（第 73-89、103-127 行） export interface CodeRunRequest { // 一次运行的全部输入：程序 + 绑定 + 中止信号——请求自带所有运行时要动的东西，没有隐藏默认值 program: string // 程序源码；它作为 async 函数体执行——顶层 await 和 return 都合法，完成值成为 result.value bindings: CodeBindingNamespace[] // 暴露给程序的主机函数，每个命名空间一个全局对象（如 tools） signal?: AbortSignal // 中止运行：运行时硬停程序（哪怕正在死循环里），以 kind:'abort' 的失败 resolve；在途绑定调用由调用方自行了结 } // 请求契约到此为止——预算、上限都是实现侧的配置，不塞进每次请求 export interface CodeRunFailure { // 一次失败的分类 + 说明：kind 决定语义，message 供模型自我纠正 kind: 'exception' | 'timeout' | 'abort' | 'worker-exit' | 'invalid-output' | 'output-limit' // 六种失败彼此正交：预算耗尽不是异常，中止不是超时，底层死亡两者都不是 message: string // 人类可读细节，措辞上适合直接喂回给模型自我纠正 } // 失败是数据不是控制流——调用方按 kind…