deepseek harness 进化方向7：分布式与远程执行 思考、设计与实现
作者：DeepSeek Harness
地址：https://gitee.com/ZachPineappleman/dsh_execution_orchestrator.git
DeepSeek Harness Evolution 7: Distributed & Remote Execution Design, Theory, and Implementation
摘要
随着大语言模型（LLM）agent 从本地单机走向大规模、长时程、多租户部署，agent 的执行环境组织方式 ------代码与进程在哪里运行、如何隔离、如何在本地与云端之间调度------成为决定 agent 安全性、成本与可扩展性的关键问题。agent harness 作为承载 agent 运行的运行时，正是这一问题最合适的落地点。本文针对 DeepSeek Harness（dsh）------一个"一切皆插件"的 agent harness------提出其分布式与远程执行（执行面）的系统性设计与实现方案。我们首先通过源码级盘点发现：dsh 已拥有执行面的五件设施（sandbox 本地围栏 / E2B 云沙箱 / code-runtime / subprocess / workflow-worker），但存在四个真实攻击面 ------read-only 沙箱只限写不限读（全文件系统可读）、!!js 配置表达式可执行、node:vm 沙箱自承认"非 containment"、沙箱审批回环可自批准------且社区实证（dsh-security-pocs）表明这些攻击面在默认部署即可达（零误配置）。进一步的对标分析发现：社区项目 dsh-worlds 以"实现 ctx.fs + ctx.subprocess 两个 seam"的方式实现了容器执行域的零内核迁移，证明了 dsh 的 seam 架构是执行域迁移的天然载体。基于此，本文提出三大创新点：N1 云沙箱编排 seam （把执行域迁移范式升级为 provider 可插拔的编排 seam------create/exec/destroy 三操作 + 生命周期策略 + per-session 隔离）；N2 执行域智能路由 （数据敏感性/计算量/延迟/能力四因子决策的端云协同选择层，迁移成本因 seam 架构近乎为零）；N3 执行点强制安全模型（把"强制点在执行点"原则落地为围栏下沉 seam、读边界 allowlist、vm guard 补 exec 面、审批接线四修复）。本文的贡献在于：(1) 首次将"执行域 provider 化编排 seam"系统化应用于 agent harness，并给出与 dsh seam 架构契合的实现路径；(2) 提出执行点强制（enforcement-locus）作为执行面安全的第一原则，以真实漏洞实证替代推演式威胁建模；(3) 将端云协同的学术理论（HERA/HybridFlow）落地为 harness 层的执行域路由设计。
关键词：分布式执行；云沙箱编排；执行域路由；执行点强制；沙箱逃逸；agent harness；DeepSeek Harness
1 引言
1.1 背景：agent 执行环境的安全与规模困境
LLM agent 的能力边界正从"本地单会话问答"扩展到"长时程自主执行、多 agent 并行、多租户共享基础设施"。这一扩展带来执行环境的双重困境：
- 安全困境 ：agent 拥有执行能力（运行命令、读写文件、加载代码），但其行为受模型驱动------而模型是可被 prompt injection 诱导的半可信主体。SandboxEscapeBenchEV7-01 实证了前沿 LLM 能够主动逃逸容器沙箱；Balkanization 研究EV7-02 进一步指出，执行安全研究的碎片化（隔离、访问控制、TOCTOU 漏洞各自为政）使"模型逃逸"这一威胁缺乏统一的防护框架。
- 规模困境：单机执行环境无法满足长时程任务（进程随 harness 重启而丢失）、重计算任务（本地资源不足）、多租户部署（需要 per-session/per-tenant 隔离）的需求。云沙箱即服务（E2B/Modal）EV7-19 提供了远端执行能力，但 dsh 当前是"整进程共享一个 E2B 沙箱"，既无编排也无路由。
这两重困境在 agent harness 层交汇：harness 是"执行环境"的最终组织者------它决定代码/进程在哪里跑、如何隔离、如何在本地与云端之间调度。Harness 工程综述EV7-09EV7-10 已明确指出 harness 本身（而非仅模型）是 agent 能力的决定性因素，执行环境正是其核心组件之一。
1.2 问题陈述：dsh 执行面的四个缺口
通过源码级盘点（详见 digests/A1-执行设施盘点-v2.md），我们发现 dsh 的执行面设施五件齐备，但存在六个 Gap（详见第 3 章），其中最关键的四个是：
- G1 无 per-session 沙箱编排：E2B 是整进程共享一个沙箱，无 per-session/per-agent 隔离。
- G2 执行点强制缺失：安全围栏挂在消费工具层（bash 壳层包装 argv），而非执行 seam 内部------导致链式无围栏 RCE（V4b）。
- G3 读边界缺失：read-only 沙箱只限写不限读，沙箱内进程可读全文件系统（V2）。
- G4 审批零接线/回环 ：默认组合未接 ask 审批，且模型可经 Web approval 回环通道自批准
danger-full-access（Discussion #250）。 - G5 无执行域路由：本地/容器/云三执行域无"按调用选择"的路由层。
- G6 配置即代码面 ：
!!js配置表达式在加载时执行，配置投毒即 RCE（V1）。
核心问题：dsh 的执行面需要从"零件齐备但边界失守、无编排无路由"升级为"编排化、路由化、强制点下沉"的执行域体系。具体地，本文提出三个研究问题：
- RQ1（编排） ：如何把 dsh 的 seam 架构（
ctx.fs/ctx.subprocess）升级为 provider 可插拔的执行域编排 seam，实现 per-session 沙箱生命周期管理？ - RQ2（路由）：如何在本地/容器/云三执行域之间实现按调用的智能路由，且迁移成本因 seam 架构而近乎为零？
- RQ3（安全）：如何把"强制点在执行点"原则落地为可执行的修复，系统化地消除四个真实攻击面？
1.3 主要贡献
- N1 云沙箱编排 seam：以"create/exec/destroy 三操作 + 生命周期策略（按需/预热/常驻/超时即杀）+ per-session 隔离 + 编排事件溯源"升级执行域迁移范式，对齐 dsh-worlds 的 adapter 形态但不重造。
- N2 执行域智能路由：四因子（数据敏感性/计算量/延迟/能力）决策 + 策略预设 + 多级降级 + 热迁移，理论基座为 HERAEV7-06 与 HybridFlowEV7-07。
- N3 执行点强制安全模型：围栏下沉 seam + 读边界 allowlist + vm guard 补 exec 面 + 审批接线四修复，以 dsh-security-pocs 四漏洞实证为输入、PRISMEV7-03 纵深防御与事务式沙箱EV7-04 为理论支撑。
- 完备插件 PRD ：
dsh-execution-orchestrator（沙箱编排 + 执行域路由 + 执行点安全 + 多租户隔离 + CLI/可观测），见进化7-插件PRD.md。
1.4 论文组织
第 2 章相关工作（执行面安全/端云路由/harness 综述/沙箱技术选型）；第 3 章理论基础与 Gap（执行设施盘点 + 六 Gap + 执行点强制原则）；第 4 章系统设计 N1（云沙箱编排 seam）；第 5 章系统设计 N2（执行域路由）；第 6 章系统设计 N3（执行点强制安全模型）；第 7 章实现映射（插件架构与 dsh 扩展点）；第 8 章评估与讨论；第 9 章结论与展望。
2 相关工作
2.1 执行面安全：从静态假设到"模型是逃逸主体"
执行安全的传统假设是"代码在沙箱里运行"------威胁来自被执行的代码本身。这一假设已被 2025--2026 年的研究推翻：
- SandboxEscapeBench （Quantifying Frontier LLM Capabilities for Container Sandbox Escape）EV7-01：系统性量化了前沿 LLM 逃逸容器沙箱的能力------模型是主动逃逸者，不是被动执行者。这与 dsh 的 Discussion #250 回环审批漏洞同构：模型会利用一切可达通道（含审批通道）达成目的。
- Balkanization of Execution-Security ResearchEV7-02：指出 AI 编码 agent 的执行安全研究碎片化为隔离、访问控制、TOCTOU 三类，缺乏统一框架------本文的"执行点强制"正是对这一碎片化的收敛尝试。
- PRISM（OpenClaw，Zero-Fork Defense-in-Depth Runtime Security Layer）EV7-03：零 fork 的纵深防御运行时安全层，采用阈值化响应策略------为本文 N3 的"强制点下沉 + 多层防御"提供直接参照。
- 事务式沙箱（Fault-Tolerant Sandboxing for AI Coding Agents）EV7-04：snapshot + rollback 的原子文件操作，实现可回滚的安全自主执行------为执行域"可回滚"语义提供理论支撑。
2.2 端云协同与执行域路由
执行域路由（在哪里执行）的学术基座是端云协同的资源分配理论：
- HERA（Learning Long-Horizon Coordination for Device-Cloud Collaborative LLM Agents）EV7-06：设备-云协同 LLM agent 的长程协调，建模了"哪些子任务在设备端、哪些在云端"的成本-延迟权衡------本文 N2 路由决策的理论基座。
- HybridFlow（Resource-Adaptive Subtask Routing for Efficient Edge-Cloud LLM Inference）EV7-07：边云子任务自适应路由，对 DAG 任务按资源特征调度------与本文"按调用选择执行域"同构。
- 边缘智能综述（Mobile Edge Intelligence for LLMs）EV7-08：端边云分层承载 LLM 的体系综述，为执行域清单（本地/容器/云）提供分类框架。
2.3 Agent 运行时与沙箱基础设施
- Agent Harness 综述（2026）EV7-09：harness 本身（而非仅模型）是 agent 能力的决定性因素，含执行环境分类------本文的定位依据。
- Harness Engineering 综述（2026）EV7-10：harness 组件分类学与模型-harness 协同演化------执行环境是核心组件，其生命周期管理是 harness 工程的关键课题。
- OpenHands runtime / E2B / ModalEV7-19：云沙箱 SaaS 的三种形态（per-session 运行时服务化 / 单共享云沙箱 / 函数级云端容器）------本文 N1 编排的对照对象。
- K8s 上的开源 agent 沙箱（2025）EV7-11：容器编排安全部署的工程实践------多租户执行隔离的落地参照。
- Serverless 性能隔离（2025）EV7-12：noisy neighbor 问题与性能隔离------多租户执行隔离的量化依据。
2.4 沙箱技术选型
沙箱技术的量化基准（经典 + 2025 补充）：
- Firecracker（NSDI 2020）EV7-13：microVM ~125ms 启动、<5MiB/VM------per-session 沙箱的量化基准（经典保留）。
- gVisor（HotCloud 2019）EV7-14：syscall 20--50% 开销------用户态内核沙箱的代价基准（经典保留）；Tencent 的百万级 gVisor agent 沙箱规模化EV7-16（2026）证明其工程可行性。
- WASM 安全综述（2025）EV7-15：WASM 安全模型的语义级隔离边界。
2.5 社区执行面生态（实证对照）
dsh 社区已存在执行面实现（详见 digests/A3-执行对标-v2.md）：
- dsh-worlds （frozo-ai）EV7-17：实现
ctx.fs+ctx.subprocess两个 seam，把 Bash/终端/LSP/文件工具全部迁入 Docker 容器------零内核改动实现执行域迁移，111 测试（live/unit 分层）。这是本文 N1 的核心实证。 - dsh-routed-subagent / dsh-engineering-workflow / dsh-plugin-subagentsEV7-18：执行编排（并行 subagent / 委派 seam / 五阶段门禁）------执行域路由与多 agent 并行执行的社区雏形。
关键对标结论：dsh-worlds 证明"seam 是执行域迁移的载体"；但它是"本机容器执行域"，缺 per-session 编排、配额、多租户、生命周期策略------这正是本文 N1 的增量空间；且其审批回环（Discussion #250）在容器内同样成立------容器解决不了 harness 层信任问题，这是本文 N3 的必要性来源。
3 理论基础与 Gap
3.1 dsh 执行面设施盘点（源码级）
依据对 packages/ 的逐行精读（详见 digests/A1-执行设施盘点-v2.md），dsh 已具备执行面的五件设施：
| 设施 | 包 | 机制 | 执行面定位 |
|---|---|---|---|
| sandbox seam | packages/sandbox/sandbox |
confine(argv, policy) → ConfinedArgv；read-only/workspace-write/danger-full-access；fail-closed |
本地执行围栏（同主机内核/文件系统） |
| E2B 云沙箱 | packages/e2b/e2b |
整进程共享一个 E2B Linux 沙箱；apiKey 零转发；onTimeout:'kill' | 云端执行后端（唯一，单沙箱共享） |
| code-runtime seam | packages/code-runtime |
worker-thread + python 后端；可移植标识契约 | 代码执行 |
| subprocess seam | packages/subprocess |
进程执行 + 敏感 env 擦除（KEY/SECRET/TOKEN + DSH_* 前缀） | 进程执行 |
| workflow-worker-thread | packages/workflow |
每 run worker 侧 vm hooks（vm.Script + createContext） | 工作流执行（vm 面） |
关键架构事实 ：dsh 架构文档明确声明"文件系统与进程提供方共享同一个执行世界，把它们指向远程沙箱，也就把 Bash、PTY 和 LSP 一并搬了过去"------seam 架构天然支持执行域迁移 。dsh-worlds 正是这一声明的社区实现：只实现 ctx.fs + ctx.subprocess 两个 seam，零内核改动。
3.2 四个真实攻击面（源码对应 + 实证）
依据 dsh-security-pocs WRITEUP（file:line 核验，详见 digests/A6-执行安全专项-v2.md），四个攻击面在 dsh 源码中均有对应物：
图 1：执行面五层设施（sandbox/E2B/code-runtime/subprocess/workflow-worker）与四个真实攻击面（V1 !!js config / V2 read-only 全 FS 读 / V4 vm exec 逃逸 / 回环审批自批准），以及端到端攻击链（V4b 无围栏 RCE）与执行点强制原则。
| 攻击面 | 源码对应 | 机制 |
|---|---|---|
V1 !!js config 执行 |
vendor/loader/src/config/utils.ts：evaluate = new Function('ctx','expr','with(ctx){return eval(expr)}') |
配置投毒 → 加载即执行 → 每次启动重放 |
| V2 read-only 全 FS 读 | fs-sandbox 只围 writeText/editText，readText 未围；bwrap --ro-bind / / |
read-only 部署下读 .ssh/.env 一步外泄 |
| V4 vm exec 逃逸 | guard 只护 apply(ctx) facade，execute(args, exec) 的 exec 原样传给 vm |
vm 代码经 exec.agent.ctx.get() 取宿主服务 |
| V4b 链式无围栏 RCE | 围栏只挂 bash 壳层，subprocess seam 本身无围栏 | V4 逃逸 → raw subprocess → 无围栏宿主进程 |
端到端攻击链（场景 A 零误配置可达）：恶意网页/仓库 → prompt injection → cordis_define + cordis_run（默认零审批）→ vm exec 逃逸 → raw subprocess → 无围栏宿主进程 → 持久化后门。
3.3 执行面第一原则：强制点在执行点
从四攻击面提炼的共同根因------强制点放错层（enforcement on consumer, not execution point）：
- V2：读策略只挂在工具层（消费点）→ 绕过一个消费者即全开。
- V4b：围栏只挂在 bash 消费层 → 持有 Context 的逃逸代码绕过整个围栏。
执行面第一原则：任何安全属性（文件/进程/网络）的强制必须落在 seam 内部（subprocess/fs 执行点），而非某个消费工具或文档约定。这与 PRISMEV7-03 的纵深防御同构，也是 BalkanizationEV7-02 呼吁的统一框架的落点。
3.4 六个 Gap 收敛
| Gap | 证据 | 现状 | 本文创新点 |
|---|---|---|---|
| G1 无 per-session 沙箱编排 | E2B 单共享（A1v2） | 单共享 | N1 |
| G2 执行点强制缺失 | V4b 无围栏 RCE（A6v2） | 消费点强制 | N3 |
| G3 读边界缺失 | V2 read-only 全 FS 读（A6v2） | 单边界 | N3 |
| G4 审批零接线/回环 | 默认无 ask + Discussion #250 | 审批未接线 | N3 |
| G5 无执行域路由 | 本地/容器/云三域无选择层（A5v2） | 三域无路由 | N2 |
| G6 配置即代码面 | V1 !!js 可执行（A6v2） |
未验证不变量 | N3 |
4 系统设计 N1：云沙箱编排 Seam
4.1 设计目标与依据
执行面现状与参照的三源对照（详见 digests/A4-云沙箱编排专项-v2.md）：
| 方案 | 沙箱粒度 | 生命周期 | 配额 | 编排 | 事件/审计 |
|---|---|---|---|---|---|
| dsh E2B 现状 | 整进程共享一个 | 到期即杀 | 无 | 无 | 无 |
| dsh-worlds | 单容器（本机） | 常驻（空闲 exec） | 无 | 无 | 无 |
| OpenHands runtime | per-session 沙箱 | 服务化 | 每会话 | 运行时服务 | 事件流驱动 |
| per-user sandbox | per-user | 平台托管 | 平台侧 | 平台 | 平台侧 |
三源各覆盖一部分：E2B 是云沙箱 SaaS 形态（单共享）、dsh-worlds 是常驻容器（seam 迁移）、OpenHands 是 per-session 运行时服务化。官方编排的增量 = 把它们统一为 provider 化 seam + 生命周期策略 + 编排事件溯源。
图 2：云沙箱编排 seam------上层工具无感知；编排 seam 提供 create/exec/destroy 三操作 + 生命周期策略 + 编排事件；三个 provider（本地 sandbox / 容器沙箱 / 云沙箱）可插拔；底部为两种成本曲线。
4.2 provider 化 Seam（扩展 ctx.fs/ctx.subprocess 范式）
dsh-worlds 证明了"实现 ctx.fs + ctx.subprocess 两个 seam 即可迁移执行域"。N1 站在同一范式上，把执行域 seam 升级为 provider 可插拔的编排接口：
- 统一三操作 ：
create(域规格：镜像/配额/网络策略)→ 域句柄；exec(域, argv, {cwd, env})（对齐ctx.subprocess语义）；destroy(域)（超时/任务完成/配额回收）。
- 三个 provider （对应三执行域）：
- 本地 sandbox（同主机内核围栏，近零启动）；
- 容器沙箱（dsh-worlds 范式，完整进程/文件/网络边界，秒级启动）；
- 云沙箱（E2B/Modal，远端完整隔离，~125ms 微VM 或按时计费）。
依据：dsh 架构文档明示"实现 ctx.fs + ctx.subprocess 两 seam，Bash/PTY/LSP/文件工具自动迁入"------编排 seam 不改内核，只把 provider 注册进决策表。
4.3 生命周期策略（对比三源的取舍）
| 策略 | 选项 | 依据 |
|---|---|---|
| 创建时机 | 按需（Firecracker ~125ms 冷启动）vs 预热池（常驻，dsh-worlds 范式） | EV7-13 延迟基准；预热池化对齐方向6 TencentDB 注入预热思路 |
| 存活语义 | 任务完成即毁（省资源）vs 常驻跨重启（dsh-worlds 卖点） | 需配置化：一次性域 vs 持久世界（dsh-worlds 揭示的新维度） |
| 配额 | 每域 CPU/内存/磁盘/并发 exec 上限 | per-user 模式 EV7-19；防单会话拖垮 |
| 销毁 | 超时即杀（E2B onTimeout:'kill'）+ 显式销毁 + 空闲回收 | E2B 已有正确姿势，推广到所有 provider |
4.4 编排事件溯源（纪律对齐 dsh 事件体系）
沙箱生命周期事件入 session 事件日志：sandbox/create、sandbox/exec、sandbox/destroy（含域标识/配额/归属 agent）------可重放、可审计。这继承了 dsh 的"事件溯源 + 模型可见即已记录"架构红线，使执行域的创建/销毁与工具调用一样成为可审计事实。
5 系统设计 N2：执行域智能路由
5.1 执行域清单与迁移成本
dsh 已有三个执行域（本地 sandbox / 本机容器（社区）/ 云沙箱 E2B），但无"按调用选择执行域"的路由层。关键发现：迁移成本近乎为零------dsh-worlds 实证了实现两个 seam 即可把全部工具迁入容器，执行域迁移是 seam 层的，不涉及工具/模型层改动。因此路由层是"调用时选择 provider"的轻量层，与方向1（模型路由）同构但对象是"执行域"。
图 3：执行域路由------四因子决策引擎（数据敏感性/计算量/延迟/能力）+ 策略预设 + 多级降级，映射到本地/容器/云三执行域。
5.2 四因子决策模型
| 因子 | 判定 | 倾向执行域 | 依据 |
|---|---|---|---|
| 数据敏感性 | 涉及凭据/隐私/敏感文件 | 本地 sandbox（数据不出端） | A1v2 攻击面1/2；E2B apiKey 零转发正确姿势 |
| 计算量 | 大内存/GPU/长时程 | 云沙箱（E2B/Modal） | HERAEV7-06 成本建模 |
| 延迟 | 交互式/低延迟要求 | 本地/容器 | 网络往返成本 |
| 能力 | 需特定环境（LSP/GPU/网络） | 按能力匹配 | dsh-worlds（LSP 在容器内） |
决策形式化 （借鉴 HERAEV7-06 的成本函数）：总成本 = Σ(执行域_i × (延迟权重 × 网络往返 + 单价 × 计算量))，受数据敏感性约束（敏感→本地，禁外泄）。
5.3 降级与一致性
- 多级降级：云沙箱不可达 → 降级容器沙箱 → 降级本地进程（三级降级链路保证可用性）。
- 降级红线：敏感操作禁降级到不可信域（数据敏感性优先级最高）。
- 热迁移：会话中途切换执行域 + 双向同步工作区文件 + 失败自动回退原域。
- 一致性：多执行域结果一致性由事件溯源保证（每域操作入会话日志）→ 可审计可重放。
6 系统设计 N3：执行点强制安全模型
6.1 enforcement-locus 原则
从四攻击面提炼的共同根因是强制点放错层。N3 把"强制点在执行点"确立为执行面安全第一原则，落地为四修复（图 4）：
图 4：执行点强制------左为现状（强制在消费层，绕过一个消费者即全开）；右为目标（强制在执行 seam，任何执行路径都被强制）；底部为四修复与理论支撑。
6.2 四修复（对应 G2/G3/G4/G6）
| 修复 | 对应 Gap | 机制 |
|---|---|---|
| 修复 1：围栏下沉执行点 | G2 | subprocess seam 内部强制 landlock/seatbelt/bwrap（而非 bash 壳层包装 argv）；fs seam 同步下沉（readText 也走围栏） |
| 修复 2：读边界 allowlist | G3 | read-only 模式同时围读：allowlist 读根（workspace + /tmp）；或容器化（dsh-worlds 完整三边界）；敏感路径黑名单 |
| 修复 3：vm guard 补 exec 面 + 审批接线 | G4 | execute(args, exec) 的 exec 对象图代理/拒绝；默认组合接 ask 审批 + grant 粒度 per-request；回环防护（沙箱内进程禁访问宿主控制面 API） |
| 修复 4：配置即代码面 | G6 | boot 时校验"加载的配置目录 ∉ 可写根"；不可信配置来源拒绝 !!js 表达式；verify-cordis-config 拒绝条目元数据表达式 |
6.3 理论支撑（2025--2026）
- SandboxEscapeBenchEV7-01：模型是逃逸主体------执行面安全必须假设模型会利用一切通道。
- BalkanizationEV7-02：TOCTOU 漏洞类别------执行点强制是统一"隔离/访问控制/时间差攻击"的落点。
- PRISMEV7-03：零 fork 纵深防御------多层强制（沙箱+容器+最小权限）而非单层围栏。
- 事务式沙箱EV7-04：snapshot+rollback------执行域"可回滚"语义的补充。
7 实现映射：插件架构与 dsh 扩展点
本文的 N1/N2/N3 落地为插件 dsh-execution-orchestrator（完整 PRD 见 进化7-插件PRD.md）。每个功能点对应 dsh 的既有扩展点（seam/事件/ctx 键），零内核改动：
| 插件功能 | dsh 扩展点 | 实现方式 |
|---|---|---|
| 沙箱编排 seam（N1） | 新增 ctx.executionDomains 服务 + 三 provider 插件 |
对齐 dsh-worlds 的 ctx.fs+ctx.subprocess seam 实现范式，升级为 provider 化 |
| 编排事件溯源 | session/event 事件流 + SessionEventMap 扩展 |
新增 sandbox/create/exec/destroy 会话事件（log-only，可回放） |
| 执行域路由（N2） | tools/pre-execute（waterfall）或 agent/pre-step |
在工具调用前拦截，按四因子决策选择 provider |
| 执行点强制（N3） | subprocess/fs seam 内部（执行点） | 围栏下沉到 seam，而非消费工具 |
| 审批接线 | ctx.approval + tools/pre-execute 返回 ask |
默认组合接 ask + per-request 粒度 |
| 回环防护 | 网络层禁沙箱访问宿主控制面 | 沙箱网络策略 + 宿主控制面白名单 |
| CLI/可观测 | ctx.commands 注册命令 + session/event 渲染 |
exec list/switch/create/destroy/stats + 路由决策追踪 |
关键设计决策 ：N3 的执行点强制（围栏下沉）是对 dsh 原生 sandbox/subprocess seam 的修复性扩展，而非插件外挂------这正是"强制点在执行点"原则的落地：围栏必须位于执行 seam 内部，任何"在消费工具外挂围栏"的方案都会重蹈 V4b 覆辙。
8 评估与讨论
8.1 设计评估
| 维度 | 评估 |
|---|---|
| 理论支撑 | N1 有 Firecracker/gVisor 量化基准EV7-13/14 + OpenHands per-session 参照；N2 有 HERA/HybridFlowEV7-06/07；N3 有 SandboxEscapeBench/PRISM/事务式沙箱EV7-01/03/04 |
| 源码对应 | N1 对齐 dsh-worlds 的 seam 迁移范式（已核验 docker.mjs）；N3 的每个修复对应一个 file:line 实证的漏洞 |
| 量化数据 | 沙箱启动延迟（WASM ms级 < gVisor 百ms < Firecracker ~125ms < 容器秒级 < 本地近零）+ 两种成本曲线（常驻 vs 按需） |
| 可落地性 | 全部功能点映射到 dsh 既有扩展点（seam/事件/ctx 键），零内核改动 |
8.2 与既有方案的对照
| 方案 | 执行域迁移 | per-session 编排 | 执行域路由 | 执行点强制 | 审批回环防护 |
|---|---|---|---|---|---|
| dsh 现状（E2B 单共享） | ✅（E2B seam） | ❌ | ❌ | ❌（消费点） | ❌ |
| dsh-worlds（社区） | ✅（容器 seam） | ❌ | ❌ | ✅（容器整体） | ❌ |
| OpenHands runtime | ✅ | ✅ | 部分 | 部分 | 事件流驱动 |
| 本文方案 | ✅（provider 化） | ✅ | ✅ | ✅（seam 内部） | ✅ |
本文方案的增量集中在"编排 + 路由 + 执行点强制 + 回环防护"四点上------都是 dsh-worlds 与 OpenHands 未完整覆盖的部分。
8.3 局限与诚实声明
- 实现范围：本文交付论文 + PRD，未交付可运行插件代码；执行点强制（N3 修复 1）需修改 dsh 原生 sandbox/subprocess seam，是"对上游的修复提案"而非纯插件。
- 量化数据来源：沙箱启动延迟等量化数据来自文献基准（Firecracker/gVisor），非 dsh 实测------后续原型需在真实 dsh profile 上验证（对齐 dsh-worlds 的 111 测试分层模式）。
- 审批回环的容器侧验证：dsh-worlds 在真实 profile 的执行域隔离与审批行为（对照 Discussion #250）尚未实测------需后续验证。
- 多租户隔离：本文给出 per-session 隔离 + 租户级沙箱池设计，但未实现 SSO/配额账务（方向12 企业级的范畴）。
8.4 跨方向联动
- 方向4（安全加固）：N3 的执行点强制是方向4"插件沙箱/网络白名单/审批接线"的强制点原则落地；四漏洞实证是安全加固的最硬输入。
- 方向8（多 agent 并行执行）：N1 的 per-session 沙箱是并行 subagent 执行域隔离的基础（每 agent 独立沙箱防串扰）。
- 方向1（模型路由）：N2 执行域路由与模型路由同构（决策因子 + provider 选择）------可共享决策框架。
- 方向12（企业级多租户）：N1 的租户级沙箱池是方向12 身份→租户→配额/审计归属的前置。
9 结论与展望
9.1 结论
本文针对 DeepSeek Harness 的分布式与远程执行（执行面），通过源码级盘点、真实漏洞实证与社区对标，提出并设计了三大创新点：
- N1 云沙箱编排 seam：把 dsh 的 seam 架构升级为 provider 可插拔的执行域编排接口，统一本地/容器/云三执行域的创建、执行、销毁与生命周期管理。
- N2 执行域智能路由：四因子决策的端云协同选择层，迁移成本因 seam 架构近乎为零。
- N3 执行点强制安全模型：以"强制点在执行点"为第一原则，落地围栏下沉、读边界、vm guard 补面、审批接线四修复，系统化消除四个真实攻击面。
本文的核心洞察是：dsh 的 seam 架构（ctx.fs/ctx.subprocess）天然是执行域迁移的载体------dsh-worlds 以社区实现证明了这一点；官方需要做的不是"从零造执行体系"，而是"把已有零件（seam、E2B、事件溯源）串成编排化、路由化、执行点强制的执行面体系"。这一洞察使方向7 从"重造云平台"收敛为"轻量编排层 + 安全强制点下沉"，是投入产出比最优的路径。
9.2 展望
- 原型验证 ：按 dsh-worlds 的 111 测试分层模式，实现
dsh-execution-orchestrator的 N1 最小原型，验证 per-session 编排与执行点强制。 - 执行点强制的上游提案：N3 修复 1（围栏下沉 subprocess/fs seam）需作为对 dsh 上游的修复提案推进。
- 量化实测：在真实 profile 上测量三执行域的启动/成本曲线，验证文献基准。
- 多租户深化：与方向12 联动，实现租户级沙箱池的配额账务与 SSO 归属。
参考文献
EV7-01 Quantifying Frontier LLM Capabilities for Container Sandbox Escape（SandboxEscapeBench）. arXiv:2603.02277, 2026.
EV7-02 The Balkanization of Execution-Security Research for AI Coding Agents: Isolation, Access Control, and Time-of-Check-to-Time-of-Use Vulnerabilities. arXiv:2607.05743, 2026.
EV7-03 OpenClaw PRISM: A Zero-Fork, Defense-in-Depth Runtime Security Layer for Tool-Augmented LLM Agents. arXiv:2603.11853, 2026.
EV7-04 Fault-Tolerant Sandboxing for AI Coding Agents: A Transactional Approach to Safe Autonomous Execution. arXiv:2512.12806, 2025.
EV7-05 zzszmyf/dsh-security-pocs（四漏洞 WRITEUP）+ deepseek-harness Discussion #250. GitHub, 2026.
EV7-06 HERA: Learning Long-Horizon Coordination for Device-Cloud Collaborative LLM Agents. arXiv:2605.24598, 2025.
EV7-07 HybridFlow: Resource-Adaptive Subtask Routing for Efficient Edge-Cloud LLM Inference. arXiv:2512.22137, 2025.
EV7-08 Mobile Edge Intelligence for LLMs: A Survey（云-边-端协同智能综述）. arXiv:2407.18921 / 2508.18803, 2024.
EV7-09 Agent Harness for Large Language Model Agents: A Survey. preprints.org 202604.0428, 2026.
EV7-10 Harness Engineering for LLM Agents: A Survey of Harness Component Taxonomy, Evaluation, and Model--Harness Coevolution. preprints.org 202606.2203, 2026.
EV7-11 Open-Source Agent Sandbox Enables Secure Deployment of AI Agents on Kubernetes. InfoQ, 2025.
EV7-12 Performance Isolation for Serverless Functions. IEEE, 2025.
EV7-13 Firecracker: Lightweight Virtualization for Serverless Applications. NSDI 2020.
EV7-14 The True Cost of Containing (gVisor). USENIX HotCloud 2019.
EV7-15 WebAssembly and security: A review. Computer Science Review, 2025.
EV7-16 Scaling Agentic-RL Sandboxes with gVisor at Tencent. gvisor.dev blog, 2026.
EV7-17 frozo-ai/dsh-worlds（容器内远程执行 worlds）. GitHub, 2026.
EV7-18 dsh-routed-subagent / dsh-engineering-workflow / dsh-plugin-subagents. GitHub, 2026.
EV7-19 E2B / OpenHands runtime / Modal（云沙箱 SaaS）. 2025.