LAYER 04 · 理解安全与耐久性
Sandbox、FS、Shell 与同一个执行世界
真正的隔离不是在工具层说“不许”，而是让能力提供者共享可执行边界
ctx.fs + ctx.subprocess + ctx.shell + ctx.sandbox为什么替换 subprocess provider，Bash、PTY、LSP 与外部子 Agent 会一起迁移？
先建立直觉
不是给每个工人一本“不要越界”的手册，而是把整支施工队安排在有围栏、统一门禁和同一材料仓库的工地。
MECHANISM
机制拆解
ctx.fs 抽象文件读写，ctx.subprocess 抽象进程启动，ctx.shell/terminals/lsp 作为消费者；E2B provider 可让 fs 与 subprocess 指向同一个远程 Linux 世界。
sandbox-policy 保存统一 mode 与 workspace roots；bash-sandbox、fs-sandbox、terminal 都读取同一权威策略，避免不同能力拥有不同边界。
第 1 步 / 共 5 步
折叠会话策略
默认模式与事件覆盖得到当前 sandbox/mode。
INVARIANTS
无论怎么扩展，都不能破坏
- FS 与进程必须共享同一 workspace 根策略
- 沙箱报告不能把部分强制误报为子进程失败
- 路径策略要防符号链接与 TOCTOU
FAILURE MODES
最容易踩中的坑
- ×只在 tool-bash 里做字符串黑名单
- ×让 cwd 代替 workspace root 校验
- ×本地 FS + 远程 subprocess 指向两个不同世界
VERIFY IN SOURCE
不要相信结论，去源码里复核
以下链接固定到官方 deepseek-harness@47f9438；查看当前上游时请留意后续 breaking changes。
KNOWLEDGE CHECK
先停十秒，再揭晓答案
为什么工具层 allow/deny 不能替代操作系统沙箱？
为什么下一章紧接在这里
即使执行安全，长工具输出与长会话仍会压垮模型上下文；下一章处理 compaction、token 与 spill。