智能体运行环境六大组件 · agent harness engineering
Addy Osmani 在《Agent Harness Engineering》(2026-04) 里给了一个已成共识的定义：
编码智能体 = 模型 + 提示词 + 工具 + 上下文策略 + Hook + 沙箱 + 反馈回路
等号右边除了"模型"，剩下全是 harness。它已经长成一门独立的工程学科——决定一个 Agent 上限的，往往不是你用了哪个模型，而是你这层脚手架搭得好不好。
一个对比：同一个 Claude 3.5，A 团队接上 6 个工具、无审批、无沙箱，一周删了两次测试库；B 团队同样的模型，配 allowlist + 审批门 + 容器沙箱，跑半年没出过事。差别全在 harness。
harness 由六个组件构成，每个组件解决一类"模型自己解决不了"的工程问题。点下面任意一个，看它解决什么、设计上怎么取舍。
六个组件里，权限门 + 沙箱 + Hook 三件套合起来构成"多闸门护栏"——任何危险操作要过好几道闸，单闸失守不会出事。点下面任意一个操作，看它会被哪道闸拦下。
设计原则：纵深防御（defense in depth）。不要指望单道闸 100% 可靠——权限门可能漏判、沙箱可能配置错、Hook 可能被绕过。三道闸串联，单点失守不致命，这才是"敢上线"的底气。
解剖 Claude Code、Codex CLI、OpenClaw 三个公开实现，剥掉产品细节后，剩下的是同一张骨架：
| 组件 | Claude Code | Codex CLI | OpenClaw |
|---|---|---|---|
| Agent 循环 | 有 · 感知-决策-行动 | 有 · 同构 | 有 · 同构 |
| 工具系统 | Schema 注册 + 路由 | 同 | 同 |
| 权限门 | allowlist + 审批 | 沙箱模式 + 审批策略 | allowlist + 多闸门 |
| 沙箱 | 工作区隔离 | 容器隔离 | 进程 + 文件边界 |
| 上下文 | repo map + 压缩 | 同 | 同 |
| Hook | 编辑后 lint/格式化 | 测试反馈自愈 | 配置化执行点 |
结论：六大组件不是某家产品的设计，是所有可上线编码 Agent 的最小骨架。你自研时少哪一块，那块就是未来的事故现场。