Harness：模型之外的工程控制层
模型负责理解、判断和模糊决策；能不能交付，取决于模型外面那层工程控制层——六个域分别归谁负责。
模型负责理解、判断和模糊决策；能不能交付，取决于模型外面那层工程控制层。这层东西叫 Harness——它不提升模型智商，它决定模型的判断能不能落到你的系统里、出事时能不能收回。
模型负责什么，Harness 负责什么
模型擅长从含糊输入里推断意图、在不完整信息下做判断、生成需要语义的内容。它不擅长记住你公司的发布流程、在崩溃后恢复状态、或者拒绝一次越权写库。
分工因此是清楚的：语义理解、规划、模糊判断交给模型；确定性流程、校验、数据传递、状态与权限放进 Harness。把「想」和「做」拆到不同平面还有直接收益——有团队把规划（脑）与执行（手）解耦之后，p50 TTFT 降了约 60%，用户等待的第一个字节不再被工具执行的长尾拖住 cursor-agent-harness。
但要先回答一道准入题：这个 Agent 的结论，需不需要对某个人、某条规则、某次检查负责 tencent-deterministic-harness？需要——比如工单审核直接决定用户与商家权益、合规认定——就要认清 LLM 是概率性的（同一工单重跑结论可能漂移），Harness 做的所有事都是在填「概率性判断」与「确定性结论」之间的先天鸿沟，这份工程成本值得付；不需要——纯生成式任务（文案、翻译、摘要）——prompt 工程就够，Harness 反而是负担。中间还有分级可用：模型直接出结论、模型建议人工拍板、模型只给 SOP 禁止自动执行，三档按责任大小选。
先分清它和框架、MCP 不是一回事
Harness 常和「框架」「MCP」混着用，三者其实是不同层的东西，混用会让选型讨论对不上焦。分开它们只要一个问题：这一层拥有循环、状态、权限和恢复吗？
| 类别 | 拥有什么 | 代价 |
|---|---|---|
| Harness | 循环、会话状态、权限模型、沙箱、恢复，打包成一体 | 循环本身不归你改，你用控制权换现成的生产行为 |
| 框架 | 只给原语和循环骨架 | 权限策略、持久化策略、沙箱全部要自己写 |
| MCP | 只拥有工具传输，没有循环、没有状态 | 它管不了权限——规范自己写明协议层无法强制安全 mcp-spec |
选型判断因此很简单：任务是编码、运维、研究这类成熟形态，用 Harness 走得更快；需要自定义控制流、要把流程拆成能逐节点测试的图，用框架——但要接受「策略全部自己写」这笔账。
三者在实践里不是竞争关系，而是层：框架编外层的流程，Harness 在沙箱里跑其中的重步骤，MCP 承载每一次工具调用。按层选，不按品牌选。
边界还在移动——框架在往上补 Harness 层，Harness 在往下出 SDK，MCP 在长交互特性。判据不是它现在叫什么，而是它替你承担了哪些责任。
系统全景四层骨架与双向解耦
很多团队在最初探索智能体时，往往把它理解为一个单体程序——写一段提示词，配置几个外部工具接口，就认为能够支撑业务运转。在本地演示时确实能顺利运转，但是一旦接入实际生产环境，往往会遇到三处核心障碍：
第一是安全合规失控。业务系统的真实访问凭证如果直接拼入提示词，一旦模型输出产生偏差或受到恶意注入，数据库密钥和高权限令牌就会直接外泄。
第二是故障排查困难。智能体在长任务中执行了错误操作，运维人员如果只能看到模型最终输出的一句报错，就无法还原它在第几步做出了误判、调用了哪些工具。
第三是缺乏确定性防护。模型具备生成删除指令或发起资金划转的能力，如果没有任何独立的外部安全拦截机制，破坏性操作就会直接对生产系统造成不可逆的损害。
因此，企业级生产智能体不能做成单体黑盒，而必须建立分工清晰的四层工程骨架：
| 架构层级 | 业务定位与核心设施 | 解决什么问题 |
|---|---|---|
| L4 平台治理服务层 | 凭证保险箱、分布式调用追踪、基准评测集、经验与规则进化 | 解决长期安全、审计追踪、质量回归与持续演进 |
| L3 生态协议连接层 | 标准 MCP 工具总线、A2A 跨智能体协议、企业办公通道适配 | 解决外部能力发现、多角色协同与人机触达 |
| L2 智能决策编排层 | 动态上下文装配、模型路由分级、生命周期拦截管线（Hooks） | 解决意图理解、复杂规划、确定性检查与人工审批 |
| L1 沙箱执行宿主层 | 轻量虚拟化隔离环境、进程生命周期管理、秒级快照与回滚 | 解决破坏性动作隔离、执行中途崩溃恢复与环境按需销毁 |
这四层体系之所以能够稳定运转，关键在于两个维度的解耦设计：
第一是垂直解耦（服务平台与执行宿主物理分离）。 上层的治理服务专门负责管理安全策略、加密托管企业凭证以及收集全局指标，它本身绝不直接运行不可信的用户代码；底层的执行宿主专门提供纯净的算力与隔离空间，模型在宿主内部执行的任何操作都不会污染上层平台。即使宿主进程由于运行故障而崩溃，上层治理平台的审计记录与任务状态依然完好无损。
第二是水平解耦（认知大脑与操作沙箱严格拆开）。 模型负责的是理解意图、规划方案与模糊推断，它是系统的「大脑」；真实的物理世界副作用（修改文件、发起网络请求、执行系统命令）必须全部委托给专门的隔离沙箱，它是系统的「手脚」。更重要的是，在思考转化为行动的必经之路上，设置了不可绕过的生命周期拦截管线。一旦识别到高危破坏性动作，系统会主动将当前进程挂起进入安全等待状态，只有在获得具备授权的人工明确审批签名之后，动作才会被放行给沙箱执行。
这四层全景骨架构成了后续所有实战章节的技术地图： 从上下文装配与工具契约，到状态机流转与人在回路拦截（详见 Hooks 拦截器管线），再到底层沙箱的虚拟化调度与快照恢复（详见 面向过程的 Agent 运行时），以及标准协议接入（详见 生态连接与标准化协议），每一项工程机制都在这套坐标系中拥有确定的位置。
Harness 做的五件事
Harness 常被当成一个整体，其实它做五件事：Context（给什么信息）、Tools（给什么手脚）、Constrain（故障安全默认值——能力一律先关，要用才显式开放）、Verify（自动判断结果对错）、Correct（发现问题就修正或回退）ai-agent-book。前两件决定模型能不能做对，后三件决定它做错时收不收得回来。多数团队的预算集中在前两件，事故全部发生在后三件。
后两件各有一条容易漏的硬规矩。Verify 只认结构化数据：检查工具返回的 JSON 字段、退出码、断言结果，不去读模型自由生成的那段话——后者可能已经被注入操纵。用模型自己的话验收模型，等于让被告出具无罪证明。Correct 在确认救不回来之前不暴露中间态：工具失败先静默重试或接续生成，等判定确实无法恢复，再降级、回退或转人工；把半成品直接摊给用户，是拿用户体验为自己的重试买单。
这五件事和下面的六个域不是两套骨架：约束、验证、纠正三件落到责任表上，就是 Gate 和 Recovery 两域——也恰好是最常没人认领的两域。
至于这层值多少钱，有一个不依赖具体模型代际的参照：LangChain 在 Terminal Bench 2.0 上把成绩从 52.8% 提到 66.5%，排名从 30 名开外进到前 5。模型没换，改的全是 Harness——让 Agent 自己检查执行结果、检测是否陷入重复循环、调整思考策略。重点不是"Harness 值 13 个百分点"，而是当模型不再是差异项时，竞争优势整块转移到模型外面。
这一层是一层层长出来的
Harness 看起来像一套小型操作系统——管子进程、维护记忆文件、驱动工具、处理权限隔离与恢复。但它不是一次设计出来的。每一层都是模型撞上边界之后，工程系统不得不补上的回答。
| 模型撞上的边界 | 补上的部件 |
|---|---|
| 不知道上一轮聊了什么 | 上下文装配 |
| 无法改变外部世界 | 工具调用 |
| 一次调用做不完一件事 | 执行循环 |
| 历史装不下 | 记忆 |
| 循环开始产生真实副作用 | 权限与沙箱 |
| 一个循环不够并行 | 子 Agent |
这个顺序值得记住，因为它解释了一件常被误解的事：Agent 的分水岭不是「会思考」，而是建立了「模型 → 动作 → 环境 → 观察 → 模型」的闭环。模型本身只生成 token，真正决定「继续运行」的是外面的程序——它必须解析模型输出、判断是否结束、调用环境、把观察结果写回上下文。
同样的道理也解释了为什么「模型变强了，Harness 会不会消失」这个问题的答案是不会：模型越能行动，外面的运行时越不能含糊。 行动能力增强会放大后果，而不是减少对边界、恢复与记录的需求。
再看那些具体问题的来历，逻辑就顺了：任务变长，于是会话必须能恢复；副作用变强，于是权限不能只靠模型自觉；上下文不够用，于是要压缩；客户端变多（终端、IDE、桌面、Web、SDK），于是要有统一的运行状态；能力项变多，于是要有确定的发现与加载机制。这些问题单个看都能塞进应用里，一起出现时才凝结成独立的一层。
六个域，各有产物与责任人
| 域 | 职责 | 主要产物 |
|---|---|---|
| Identity | 职责、输入输出、能力、权限、禁止动作 | Agent Contract、Policy、Capability Allowlist |
| Orchestration | 路径、阶段、依赖、并行、人工节点 | Workflow、State Machine、Router |
| Context | 信息选择、隔离、压缩、引用、交接 | Context Policy、Handoff、ArtifactRef |
| Gate | 阶段准入、输出验收、发布门禁 | Validator、Checklist、Grader |
| Recovery | 状态、重试、回退、取消、恢复 | Execution Ledger、Checkpoint、Recovery Policy |
| Evolution | 失败归因、经验、规则与行为资产治理 | Trajectory、Experience、Feedback Patch |
每个 Agent 项目都要明确六域的责任归属，安全、权限、数据完整性和硬门禁必须落到系统里，不能只写在提示词中 openai-harness。最常见的两个漏洞是 Gate 和 Recovery 没人认领：Gate 退化成一句「请仔细检查」，Recovery 被默认成「失败了就重跑一次」。
可替换、可关闭、可消融
每个 Harness 组件都要记录它解决的问题、成本和验证指标，并且能单独替换、单独关闭。理由是模型会移动地基：为上一代模型的某个怪癖打的补丁，在新模型上可能从救命变成纯粹的负担——Anthropic 就遇到过为模型的 context anxiety 加的 reset 逻辑，在下一代模型上变成 dead weight。判据不是它现在有没有用，而是你能不能在五分钟内关掉它并跑一遍 eval 看差别。
对称的纪律是：采用 Harness 不等于自动引入多 Agent、向量库、耐久 Workflow 或治理平台。这些每一项都要单独过一遍复杂度阶梯。
下一代模型发布时，这笔投入是获益还是作废
每项 Harness 投入都用这一个问题检验：下一代 SOTA 模型发布时，它是获益还是作废。
替代或补偿模型推理能力的投入——拆解步骤、提示词编排、流程微调——会被模型下一次升级吸收，半衰期以一个模型版本计。给模型提供它自己造不出的信息的投入——内部系统的真实状态、构建结果、日志、测试反馈——持续增值。这不是说前者一律不做，而是你要清楚自己买的是多长时间。
组织红利是乘积，不是和
组织红利约等于模型能力乘以环境能力。模型是租来的因子，跟着厂商的节奏上涨，你控制不了；环境是自有因子，只能自建，而且只涨不跌。乘积关系意味着环境为零时，模型再强结果也是零。
Cursor 把 agent 搬到云端时踩到的正是这点：本地运行时 agent 默认拥有一整套完整环境——装好的依赖、登录态、缓存、正确的数据；云端是干净的，那些隐形前提全部消失，成为质量的隐形杀手。他们的结论是环境配置不是部署细节，而是质量的前置条件 cursor-cloud-agents。
所以工程投入优先流向环境与验证资产：把内部系统改造成有反馈、可验证的状态，让 agent 能自己拿到 ground truth。不要参与「让 AI 生成得更强」的军备竞赛，那是厂商的赛道，你在里面赢不了。