6.3 harness与沙箱的边界
6.3 harness与沙箱的边界
本节摘要：一个新手问题收束整章：harness 自己要不要跑在沙箱里？Hacker News 上有一条被反复引用的共识观点——"harness 本身在沙箱之外"。理由回到定义（第 1.1 节）：harness 是调用 LLM API 并执行工具的循环，沙箱约束的是工具执行而非 harness 本体。本节画出责任划分图：沙箱内住着工具执行的子进程、被生成与执行的代码、工具能读写的文件；沙箱外住着主循环与上下文组装、权限门与审批 UI、模型 API 客户端与密钥、观测日志。四条理由：密钥可达性（进墙=模型可读）、API 出网（沙箱禁网会掐断模型调用）、人在回路（审批必须能越过墙喊人）、日志完整性（记录不能被墙内进程篡改）。三个反例展示边界画错时的典型事故，最后收束：权限判准 + 沙箱兜底是同一信任问题的两半。
学习目标
阅读完本节，你应当能够：
- 复述"harness 本身在沙箱之外"的观点及其论证。
- 画出责任划分图，说出每件东西住墙内还是墙外。
- 用四条理由解释为什么边界必须这么画。
- 识别边界画错的三个典型事故形态。
一、问题与共识观点
新手直觉常是"全部塞进沙箱最安全"。但先想一个事实：harness 是那个调用 LLM API 并执行工具的循环（第 1.1 节定义）——它拿着 API Key 出网调用模型，再回头执行模型要求的动作。把它自己关进沙箱，会发生什么？
Hacker News 上关于沙箱化智能体的公开讨论里，有一条被反复引用并形成共识的观点：
"harness 本身在沙箱之外。" 沙箱约束的是工具执行（tool execution），不是 harness 本体。（社区观点，表述从英文讨论整理）
这不是偷懒，而是职责推导的结果：沙箱是给"不可信代码"建的隔离舱，而 harness 是信任基座（trusted computing base）——它是执行隔离的那个主体，把裁判自己关进被告的笼子，隔离就失去了执行者。
二、责任划分图
┌─ 沙箱外：harness 本体（信任基座）──────────────┐ ┌─ 沙箱内：工具执行 ──────────────┐ │ │ │ │ │ 主循环 + 上下文组装（第 3/7 章） │ 传入 │ run_bash 派生的子进程 │ │ 工具注册表与派发（第 4 章） │ 命令 ─▶│ 模型生成的代码与脚本 │ │ 权限门 / 审批 UI（第 5 章） │ │ 工具能读写的文件（工作区内） │ │ 模型 API 客户端 + 密钥（环境变量/密管） │◀─ 结果 │ 依赖安装、测试进程 │ │ 观测日志与 token 账本（第 9 章） │ 受控回流│ │ │ Hook 执行器（第 8 章） │ │ （墙 = 6.2 的文件/网络边界 │ │ │ │ + 6.1 的进程/资源边界） │ └──────────────────────────────────────────────┘ └────────────────────────────────┘
穿越墙的数据流只有两条：命令进（经权限门放行后的执行请求）与结果出（截断、脱敏后的受控回流——回流的正是 3.1 节第四拍"观察"）。墙内没有任何东西能直接发起对墙外资源的读写。
三、四条理由
| # | 理由 | 如果违反会发生什么 |
|---|---|---|
| 1 | 密钥可达性：API Key、数据库口令留在墙外，由 harness 持有 | 密钥挂进沙箱 = 模型可经工具读到 → 一条 cat 就把它读进上下文、写进日志（5.1 节 deny .env 的沙箱版） |
| 2 | API 出网：模型调用需要稳定的出网通道 | 沙箱禁网（6.2 默认策略）会掐断 harness 与模型的连接——整个循环第一步就死 |
| 3 | 人在回路：审批 UI 必须在墙外 | 审批提示被墙内状态阻塞，模型发起的危险操作要么无人可问、要么问不到真人 |
| 4 | 日志完整性：trace 与账本是审计证据 | 墙内进程可以篡改/删除对自己不利的记录——观测失去公信力（第 9 章的前提在这里） |
💡 顺着理由 1 再推一步：不仅密钥，harness 自身的配置（权限规则、hook 配置、沙箱档位）也必须对墙内不可见且不可写——否则模型经工具改写权限规则，等于从墙内拆墙。这正是 6.2 掩码区里放
.mini_harness的原因，第 8.3 节会把这一点升级为 hook 安全的专门讨论。
四、边界画错的三个反例
| 反例 | 形态 | 后果 |
|---|---|---|
| 密钥进墙 | 为"让测试连数据库"把 .env 挂进沙箱 |
模型一次 read_file 就把口令读进上下文；之后每一次出网白名单都是为它开的 |
| 信任墙内回传 | 工具结果不经截断/脱敏直接回填 | 超长输出淹没预算（7.1 节）；敏感内容直接进上下文与日志 |
| 墙内可写墙外配置 | 权限规则文件落在工作区内可写路径 | 模型"顺手"把 deny 行删了再执行原本被拦的命令——护栏被自己看守的犯人拆掉 |
三个反例共同点：边界不是"多堵墙"，而是数据流上少数几个受控穿越点——命令进、结果出，再无其他。
给自己留一个日常自检口诀，出任何沙箱相关事故时按序三问：
一问：密钥与配置对墙内可见吗？（可达性） 二问：除了"命令进、结果出"，还有别的数据流穿墙吗？（穿越点清点） 三问：日志在墙外吗、墙内进程改得到吗？（可审计性）
三问都过，事故多半出在判错（回第 5 章）；任何一问不过，先修边界再谈别的。
五、第 6 章收束：同一信任问题的两半
回收 2.1 节的对照结论：Claude Code 把功夫下在权限粒度，Codex 把功夫下在隔离强度——现在可以说透为什么两者都必要：
权限门（第 5 章）：判准每一次出手 —— 软防线：语义、可解释、可打断、概率性 沙箱（本章） ：接住每一次失手 —— 硬防线：物理、结构性、零误放、有开销 两半拼起来，才是"敢让模型动手"的完整信任模型
本节要点回顾
- 共识观点：harness 本身在沙箱之外——沙箱约束工具执行而非 harness 本体；harness 是信任基座，不能自己关自己。
- 责任划分：墙内=子进程、生成代码、可写文件；墙外=循环、权限门、密钥、审批 UI、观测日志；穿越点只有"命令进、结果出"。
- 四条理由：密钥可达性、API 出网、人在回路、日志完整性——每条都能推出一个反例事故。
- 收束：权限判准（软）+ 沙箱兜底（硬）= 同一信任问题的两半。
刹车与防爆舱都已就位，六大组件还差最"软"也最影响产出质量的一件：供料。下一章进入上下文工程——窗口预算、压缩与记忆分层，决定模型"此刻的智商"。