1.1 定义与反定义：harness 不等于模型不等于沙箱
1.1 定义与反定义：harness 不等于模型不等于沙箱
本节摘要：新词最大的风险是被用成"万物皆可 harness"。本节先给正定义——harness 是围绕模型构建的运行环境：一个在沙箱之外的主循环，负责调用 LLM API、组装上下文、定义与派发工具、执行权限判定、收集结果并观测全程；再给三条反定义，逐一排除最常见的三个混同：harness ≠ 模型（模型是它体内可替换的插槽）、harness ≠ 沙箱（沙箱是它派发工具执行的一个隔离组件）、harness ≠ 框架（框架是造 harness 的零件库，用框架不等于有 harness）。最后落到一张五者边界表，并说明划清边界带来的三个实际工程收益。
学习目标
阅读完本节，你应当能够：
- 写出 harness 的正定义，覆盖"循环、上下文、工具、权限、观测"五个关键词。
- 用边界表向他人解释 harness 与模型、智能体、沙箱、框架的区别。
- 举出"用框架却没有 harness"的一个真实场景。
一、正定义：一个循环，五项职责
综合 Addy Osmani 的定义（官方）与 HN 讨论的共识（社区），本书通用的正定义是：
Harness 是围绕模型的运行环境：一个运行在沙箱之外的主循环，它调用 LLM API 获取决策，把决策中的工具调用经过权限判定后派发执行（通常在沙箱内），并把执行结果组装回上下文，循环往复直到任务完成；全程留下观测数据。
拆出五个关键词，正好对应五项职责：
| 关键词 | 职责 | 一句话 |
|---|---|---|
| 循环 | 驱动 | 一个 while：问模型 → 做动作 → 再问模型 |
| 上下文 | 供料 | 决定模型每一步看见什么 |
| 工具 | 手脚 | 把"想"变成"做"的接口层 |
| 权限 | 刹车 | 决定哪些动作可以直接做、哪些要先问人 |
| 观测 | 记录 | 出了问题能回放，效果好坏能量化 |
注意这个定义里没有"聊天界面"。对话窗口只是 harness 的一种输入渠道——第 2 章会看到，OpenClaw 的输入渠道是 WhatsApp/Discord/iMessage 等（官方），渠道可以换，harness 的内核不变。
二、反定义一：harness 不等于模型
最常被混同的一对。区分的标准是可替换性：
- 模型是 harness 体内的插槽：今天插 A 模型，明天换 B 模型，harness 的代码一行不改（最多改个模型名与参数）。
- 反过来，同一个模型今天接终端 harness（Claude Code 形态），明天接聊天渠道 harness（OpenClaw 形态），就是两个完全不同的产品。
💡 工程口诀：**模型易朽，harness 长存。**你在一个季度里换掉模型的概率，远大于换掉主循环与权限系统的概率——所以架构上要让"换模型"成为配置变更，而不是重构理由。第 10 章的 mini-harness 会把
call_model抽成唯一一个可替换点，就是这个原则的落地。
三、反定义二：harness 不等于沙箱
第 0.1 节已经给出那张"沙箱之外"的图，这里补全成机制层面的论证：
Harness（沙箱之外，可信代码） │ 1. 模型请求执行 rm -rf build/ │ 2. 权限门判定：allowlist 命中？→ 问人？ │ 3. 判定通过 → 在沙箱内启动进程执行 ▼ Sandbox（沙箱之内，不可信执行） │ 4. 文件系统只挂在项目子目录 │ 5. 网络按策略禁用/放行 │ 6. 结果/错误传回 ▼ Harness 收到结果 → 组装回上下文 → 下一轮循环
沙箱解决的是"这个动作爆炸半径多大"（隔离），权限门解决的是"这个动作该不该做"（授权），harness 则是做出这两个判断并驱动全流程的那个系统。沙箱坏了，损失被隔离在沙箱内；harness 坏了（或被攻破），攻击者拿到的是 API Key 与全部权限开关——harness 是安全边界本身，所以它必须运行在沙箱之外、也必须自身可信。
四、反定义三：harness 不等于框架
框架（LangChain、LlamaIndex、各家的 agent SDK）是零件库：预置的循环抽象、工具包装器、记忆结构。用框架可以加速造 harness，但两者不能画等号：
| 框架 | Harness | |
|---|---|---|
| 本质 | 库 / 依赖 | 系统 / 在制品（产品本身） |
| 谁定义行为 | 框架的默认值 | 你的每一项工程决策 |
| 交付物 | pip install 的东西 |
你的智能体产品 |
| 可替换性 | 随时可换、可全弃 | 是你产品的核心资产 |
一个真实场景：团队引入了某个 agent 框架，跑通 demo 就宣布"我们有了内部 agent 平台"。但默认权限是全放行、错误被框架吞掉、上下文无预算管理——零件都在，车没造出来。判断标准很简单：你的权限策略是什么？上下文超预算了怎么办？没有答案，就还没有 harness。第 10 章将证明：不用任何框架，500 行也能写出可用的 harness——框架是加速器，不是必需品。
五、五者边界表（本章核心成果）
| 概念 | 一句话定义 | 核心职责 | 与 harness 的关系 |
|---|---|---|---|
| 模型 | 概率推理引擎，"大脑" | 理解、决策、生成 | harness 体内的可替换插槽 |
| Harness | 围绕模型的运行环境 | 循环、上下文、工具、权限、观测 | 本书主角 |
| 智能体（agent） | 模型 + harness 装配成的成品 | 端到端自主完成任务 | harness 装上模型后的整体 |
| 沙箱 | 受隔离的执行环境 | 限制工具执行的爆炸半径 | harness 的一个组件（第 6 章） |
| 框架 | 造 harness 的零件库 | 提供抽象、集成、加速 | 手段而非成品；可用可不用 |
划清边界的三个工程收益：
- 换模型不换车：模型迭代按"换插槽"对待，评估成本是跑一遍回归集（第 9 章），不是重写系统。
- 安全责任分层：harness 层的漏洞（权限判定被绕过）与沙箱层的漏洞（容器逃逸）由不同的机制与团队防线负责，不互相甩锅。
- 选型清醒：采购框架时问"它替我做了哪些 harness 决策、这些决策合不合我的场景"，而不是"它是否流行"。
本节要点回顾
- 正定义：harness = 沙箱之外的主循环，五项职责——驱动（循环）、供料（上下文）、手脚（工具）、刹车（权限）、记录（观测）。
- 三条反定义：≠模型（插槽论：模型易朽，harness 长存）；≠沙箱（沙箱管爆炸半径，权限管该不该做，harness 是安全边界本身）；≠框架（零件库不是车，默认值不等于你的决策）。
- 五者边界表是本章核心成果，此后全书提到"智能体"都指"模型 + harness"的成品。
- 边界清晰的收益：换模型是配置变更、安全责任分层、框架选型清醒。
疆域的边界画准了。但这片疆域为什么偏偏在 2026 年突然热闹起来、值得专门立一门学科？下一节看三股推动力。