1.3 六大组件全景图
1.3 六大组件全景图
本节摘要：本节是全书之纲。把 harness 拆成六个组件——① Agent 主循环（驱动）、② 工具系统（手脚）、③ 权限与审批门（刹车）、④ 沙箱隔离（防爆舱）、⑤ 上下文工程（供料）、⑥ 观测与评测（仪表盘），一张总图讲清它们怎么在一个工具调用周期里协作：上下文组装供料、模型决策、权限门放行或拦截、沙箱内执行、结果回填、观测全程记录；再加两条贯穿暗线——Hook 与反馈回路（挂载点）和观测（横切）。每个组件给出核心职责、关键工程问题与对应章号，最后给出这张图的三种用法：读每章前的路标、解剖任何产品的模板、以及第 10 章 mini-harness 的实现清单。
学习目标
阅读完本节，你应当能够：
- 默画出六大组件全景图，并标注数据流向。
- 对每个组件说出一句"核心职责"和一个"关键工程问题"。
- 用这张图拆解任意一个智能体产品，指出它强在哪格、弱在哪格。
- 说出六组件之外两条贯穿暗线的名字与作用。
一、总图：一个工具调用周期里的六大组件
想象模型说了一句"我要执行 npm test"。从这句话到结果回填，六大组件各就各位：
（文字流程图） L ──▶ "模型调用·（function calling）" "模型调用·（function calling）" ──▶ D 放行 ──▶ "④ 沙箱内执行（第 6 章）·文件/网络/进程隔离" 失败 ──▶ "错误与拒绝反馈·（第 4.3 节）" 成功 ──▶ "结果回填" "错误与拒绝反馈·（第 4.3 节）" ──▶ "结果回填" "结果回填" ──▶ L
一条完整的环：供料 → 决策 → 把关 → 隔离执行 → 反馈 → 再供料。主循环是脊柱，其余五件都是长在脊柱上的器官。
二、逐组件速览
| # | 组件 | 核心职责 | 关键工程问题 | 章 |
|---|---|---|---|---|
| ① | Agent 主循环 | 驱动"问模型→做动作→再问模型"直到完成 | 何时终止？失败怎么办？上下文何时组装？ | 3 |
| ② | 工具系统 | 定义、注册、选择并执行工具 | schema 怎么写模型才选得对？错误怎么反馈？ | 4 |
| ③ | 权限与审批门 | 判定每个动作"直接做 / 问人 / 拒绝" | allowlist 怎么设计？何时打断人？危险命令怎么拦？ | 5 |
| ④ | 沙箱隔离 | 限制工具执行的爆炸半径 | 文件/网络/进程各隔离到什么程度？性能代价多少？ | 6 |
| ⑤ | 上下文工程 | 决定模型每一步看见什么 | 窗口装不下怎么办？哪些该记、哪些该忘？ | 7 |
| ⑥ | 观测与评测 | 记录、回放、量化 harness 的表现 | 日志记什么？怎么证明"这次改版变好了"？ | 9 |
对每个组件，再用一段话建立第一印象：
① 主循环是 harness 唯一不可省略的组件——没有它，模型只是一个被动应答的接口。循环的每一拍叫一步（step/turn），工程含量全在边角：终止条件（第 3.2 节）、失败熔断、以及每一步重新组装上下文的时机（第 3.3 节）。
② 工具系统是模型与真实世界的 API 层。模型看不见你的代码，只看得见工具的 schema——所以"工具定义即文档"，schema 的质量直接决定模型用得对不对；工具多到几十个时还要引入路由（第 4.2 节）。
③ 权限门是 harness 的价值观所在：哪些操作可以静默执行、哪些必须问人、哪些直接拒绝。它不是安全补丁，而是产品设计——审批打断的频率直接决定用户体验与安全的平衡点（第 5.2 节）。
④ 沙箱回答权限门管不住的问题：模型可能构造出你没预料的命令。沙箱用隔离（只挂项目目录、禁网、限进程）保证"即使做错了，损失也是局部的"（第 6 章）。
⑤ 上下文工程决定模型"此刻的智商"。上下文不是越多越好：塞满陈旧信息与超长日志，模型的表现会明显下降。预算分配、压缩与记忆分层是第 7 章的主题。
⑥ 观测与评测让 harness 变成可迭代的工程品：JSONL 日志回放一次任务的每一步；回归评测集回答"改了上下文策略，到底是变好还是变坏"（第 9 章）。
三、两条贯穿暗线
六组件之外，两条暗线横向贯穿全书：
暗线 1 Hook 与反馈回路（第 8 章） 循环的固定挂载点：步骤前/后、会话开始/结束、压缩前后…… 用途：注入策略、拦截改写、触发自动化、人在回路确认 暗线 2 观测（第 9 章） 不是第六个"器官"而是"神经系统"：每一步都留下记录， 支撑调试回放、成本核算、回归评测
把 Hook 理解为 harness 的"插件协议"：Claude Code 的 hooks（PreToolUse / PostToolUse 等，官方）就是这条暗线的实例——在第 2.1 节会看到它长什么样，第 8 章系统展开。
四、这张图的三种用法
- 读每章前的路标：每章支柱页的"前置知识与后续延伸"都在这张图上指位。读到任何一节迷路了，回到这张图问自己"我在哪一格、这一格解决总图里的哪个箭头"。
- 解剖任何产品的模板：拿一个产品（比如你正在用的编码智能体），逐格填写它的循环策略、工具表、权限模式、沙箱强度、上下文管理、观测能力——空格就是你与它的差距，也是它的产品秘密。第 2 章将用这个模板解剖 Claude Code、Codex 与 OpenClaw。
- 第 10 章的实现清单：mini-harness 约 500 行的行数预算就按这张图分配——循环骨架、工具注册器、权限门、简单上下文管理、JSONL 日志各占一块（沙箱在 mini 版中用受限工具集近似）。
⚠️ 别把六组件当成六个"模块目录"。它们是六个职责视角：真实代码里，权限判定可能内联在工具执行函数里，上下文组装可能就是循环里的一行函数调用。组件化的意义是设计时不漏想、讨论时有公共语言，而不是目录结构教条。
本节要点回顾
- 一张总图：供料（⑤）→ 决策（模型）→ 把关（③）→ 隔离执行（④）→ 反馈（②/①）→ 再供料（①），观测（⑥）全程记录。
- 六组件口诀：驱动（循环）、手脚（工具）、刹车（权限）、防爆舱（沙箱）、供料（上下文）、仪表盘（观测）。
- 两条暗线：Hook 反馈回路（挂载点协议）与观测（神经系统），横向贯穿六组件。
- 三种用法：每章路标、解剖模板、mini-harness 实现清单——第 3~9 章逐一点亮这六格，第 10 章全部拼装。
地图就位。下一章先不写代码，我们去解剖三个真实样本——Claude Code、Codex CLI 与 OpenClaw，看看这张全景图在工业级产品上是如何被填写的。