当 AI 编程助手不再只是补全代码，而是可以执行命令、修改文件、运行脚本时，安全就从产品体验问题变成了工程基础设施问题。开源项目 DeepSeek Harness 中的沙箱设计，提供了一个观察 Coding Agent 执行安全边界的样本：它并不试图把网络、进程、文件系统风险一次性打包解决，而是把最基础也最危险的文件写入效果单独拆成一层能力。
从公开资料看，DeepSeek Harness 将沙箱模式定义为三种：read-only、workspace-write 和 danger-full-access。其中，read-only 和 workspace-write 会进入沙箱服务进行处理，而 danger-full-access 则不会经过 ctx.sandbox，由消费方直接启动原始命令。这一设计本身已经表明，DeepSeek Harness 并没有把沙箱包装成无所不能的安全屏障，而是明确划定其职责：只管文件系统效果，不管网络访问，也不覆盖进程可见性问题。
沙箱先回答一个问题：Agent 到底能碰哪些文件
Coding Agent 的风险往往来自“能力越权”。一个能写项目文件的智能体，如果缺乏边界约束，也可能误删代码、覆盖配置，甚至写入恶意内容。DeepSeek Harness 的沙箱设计首先把问题收敛到文件效果上，并将不同模式形成清晰分级。
- read-only：只允许读取，不允许写入。POSIX runner 会授予 shell 所需的 /dev/null 接收器；Windows ACL runner 不授予任何显式可写根目录。
- workspace-write：允许写入指定工作区。工作区根目录来自会话的不可变 cwd，并可额外写入 /tmp。
- danger-full-access：不经沙箱服务封装，消费方直接 spawn 原始 argv。
这种模式划分的价值在于，它把“Agent 能不能写文件”从模糊的信任问题转成了可执行策略。尤其是在 Coding Agent 频繁参与脚本运行、代码生成、项目重构等任务时，写权限的最小化是降低误操作风险的第一步。
隔离不是全局开关，而是每次调用单独解析
DeepSeek Harness 的另一个关键设计，是沙箱策略并非全局配置，而是在每次能力调用时单独解析，生成对应的 SandboxExecutionPolicy。策略中包含模式、可写工作区根目录以及会话标识等字段。
解析输入包括调用会话和显式批准的模式覆盖。优先级链为：如果存在用户审批后重试携带的显式 mode 覆盖，则优先采用；否则使用会话策略；如果仍没有，则回退到部署配置。工作区根目录会经过两步规范化处理，以避免符号链接和相对路径带来的误判。素材中提到，如果只做词法规范化，类似 /home/user/link/.. 这样的路径可能被错误处理，实际运行目录未必与表面路径一致。
这一“逐调用解析”的方式，使策略跟着会话走，而不是跟着进程走。两个并发会话可以同时向同一个 Provider 请求不同边界，而不需要改变 Provider 自身状态。对于多任务并行运行的 Agent 系统而言，这种设计比单一全局开关更贴近真实执行场景。
三大平台后端：Linux、macOS、Windows 各自如何落地
DeepSeek Harness 的本地沙箱由 dsh-sandbox-local 提供，覆盖三个平台的原生隔离后端。
- Linux：采用 bwrap 加 Landlock。bwrap 负责命名空间隔离，将根文件系统以只读方式挂载，并挂载 /dev 与 /proc，同时设置父进程退出时终止子进程；在 workspace-write 模式下，/tmp 使用 tmpfs，工作区目录以可写方式挂载。Landlock 则在内核层面对文件读写进行授权，读取根目录默认可读，可写范围包括 /dev/null、/tmp 和工作区根目录。
- macOS：使用 Seatbelt，即 sandbox-exec。策略通过 SBPL 声明，默认允许其他行为，但拒绝所有文件写入，再显式允许 /dev/null 以及可写工作区路径。
- Windows：使用 ACL 受限令牌。read-only 模式不授予任何显式可写根目录，并因环境 ACL 缺口被标记为 partial。
这里还涉及一个执行边界问题：沙箱后端会报告自身管控完整性，分为 full 与 partial。full 表示后端完整管控了该模式承诺的文件效果；partial 表示当前后端或旧内核能力只能管控其中一个子集。素材中明确列出的 partial 场景包括 Linux 缺少 Landlock，以及 Windows ACL 存在环境缺口。文档同时提醒，如果调用方需要绝对边界，就不能把 partial 当作 full。这种“宁可拒绝执行，也不假装完成隔离”的思路，体现出大声失败、不静默降级的工程原则。
沙箱不是工具内部补丁，而是执行链中的一层包装
DeepSeek Harness 并没有把沙箱逻辑塞进每个工具内部，而是在 tools/execute 事件链中作为包装层注入。以 bash 执行为例，模型请求执行命令后，会先进入 pre-execute 阶段，由 permission-presets 做静态规则匹配，必要时转交 user-approval 进行人工审批；随后进入 execute 阶段，由 bash-sandbox 包装器解析沙箱策略。如果模式为 danger-full-access，则直接启动命令；如果是 read-only 或 workspace-write，则通过沙箱 Provider 包装命令后执行。
执行过程中，系统还会为每个进程保留独立的隔离事实，包括模式、执行完整性、拒绝签名、运行器失败规则、运行器程序和工作目录等。素材中的注释解释称，Provider 可能对重叠调用报告不同的 enforcement 与诊断信息，如果共享最新状态，可能导致错误分类。
在部署层面，DeepSeek Harness 提供了两个平行 Provider：dsh-bash-local 和 dsh-bash-sandbox。前者代表本地直接执行，适用于信任环境；后者提供文件效果隔离。两者实现同一个 ctx.shell 服务定义，消费方无需感知差异。差别在于，bash-sandbox 额外注入 sandbox 和 sandboxPolicy。配置注释还强调，沙箱策略不属于执行器，而由独立的策略服务负责解析。
权限系统和沙箱分工不同，一个管审批，一个管边界
DeepSeek Harness 的安全设计并不是单点机制，而是权限系统与沙箱协同工作。权限系统负责判断“能不能做”，例如允许、拒绝或请求用户审批；沙箱负责在允许执行时限制“能做到什么程度”。
当用户批准后，重试请求可以携带显式模式覆盖。例如，默认 workspace-write 被拒绝后，用户批准以 danger-full-access 重试，此时命令不会经过沙箱服务，而是直接启动。相反，如果用户拒绝，则返回拒绝原因；如果忽略，则维持原策略。
这种分工对于当前主流 Coding Agent 场景具有现实意义。无论是类似 Claude Code、Codex 的命令行智能体，还是 Cursor Agent 等编辑器内代理，只要允许模型执行命令或修改文件，就必须面对权限审批、运行隔离与最小写入范围这三件事。DeepSeek Harness 的思路并不是追求一个全能沙箱，而是把文件效果隔离做成架构层组件，并让权限、会话和平台后端各自承担明确职责。
对行业而言，这类设计的价值在于，它把 AI Agent 安全从口号式讨论拉回到可验证、可降级、可审计的工程问题上。未来 Coding Agent 能否进入更严肃的软件生产流程，取决于模型能力之外，平台是否愿意为每一次命令执行画出清楚且可执行的边界。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/coding-agent-yue-lai-yue-hui-dong-shou-deepseek-harness-ba
