同一个模型，在聊天框里只能给建议，进入成熟的 Harness（执行框架）后却能读取项目、修改环境、检查结果并跨会话继续。差异不只是“多了几个工具”，而是工作世界被重新设计。
模型提供能力，Harness 决定能力如何落地
“Harness”原意是挽具：马有力量，挽具把力量连接到方向、负载和刹车。在 AI 系统里，模型负责理解和推理；Harness 负责告诉它身处哪个项目、有哪些工具、能做什么、不能做什么、如何知道做对了。
所以它既不是 Prompt 的新名字，也不是 Tool Use 的集合。Prompt 是一次任务规格，Context 是此刻进入推理的世界，Loop 是行动和验收的回环；Harness 把这三者连同权限、状态和观测机制装成一个长期工作的系统。
把一个更强模型放进坏 Harness，通常只会更快地产生高质量错误：它读不到业务事实，却能自信制定方案；它拥有写权限，却没有测试；它能执行外部动作，却没有确认闸门。真正的系统能力更接近乘法：
任何一项接近零，整体就会塌。
文字规则只能被模型理解，不能自动产生权限隔离、环境反馈或失败恢复。你可以写“不要删除重要文件”，但真正可靠的是默认只读、删除前确认、版本可回滚，以及删除后有检查。制度需要同时存在于语言层和机械层。
六种 Harness 失败：不是模型笨，是工作环境坏了
成熟团队不把每次事故都归因于模型，而是追问：缺了哪种能力，哪个约束不可见，哪条规则没有被执行。
环境不可读
业务知识散落在人脑、聊天和外部文档，模型只能看仓库的一小部分。系统真实规则对它等于不存在。
规则只写不验
文档要求遵守架构、命名或合规边界，但没有测试和权限机制。模型一忙就会把“应该”当成“可选”。
工具堆积
一次加载几十个相似工具，名称模糊、返回结构不稳定。选择成本挤占推理，错误调用率随能力一起上升。
权限过宽
为了减少确认，把读取、修改、发送、删除放在同一级。低风险任务获得高风险能力，误操作没有刹车。
状态不可恢复
所有进展只活在当前对话。窗口压缩或会话中断后，下一位执行者不知道完成了什么，也不知道哪里不能重做。
失败不可观察
系统只返回“任务完成”，没有日志、测试和产物差异。人只能在生产环境里发现错误。
这六类失败有一个共同点：继续提醒模型“认真一点”不会修好。OpenAI 在 Harness Engineering 实践中总结得很直接——早期进展慢并非 Codex 能力不够，而是环境缺少工具、抽象与内部结构；修复方向不是“更努力”，而是找出缺失能力，并让它对智能体可读且可执行。
一套生产级 Harness，至少有七层
七层不是产品功能清单，而是七种责任。小项目可以用几个 Markdown 文件和脚本实现，大平台可以用完整基础设施实现；判断标准是责任是否存在，不是技术是否复杂。
这七层里，最容易被低估的是 Domain Legibility（领域可读性）。如果关键知识只存在于 Slack 讨论、某位员工脑中或过时文档，智能体就无法可靠推理。OpenAI 的 Agent-first 工程实践把知识、Schema、架构约束和可执行计划推入仓库，并用结构测试强制执行——不是为了文档漂亮，而是为了让系统能够工作。
先替反方说完：更强模型会不会让 Harness 消失
值得权衡：模型能力提升确实会减少脆弱的脚手架。过去需要十步工作流的任务，未来可能一次完成；过去为模型写的详细操作说明，可能变成不必要的过度约束。Harness 过重会降低速度、增加维护成本，还可能把模型锁进旧流程。
吹毛求疵：“Harness 只是工程师给 Prompt 换的新名词。”如果系统只有一段 system prompt，这个批评成立；一旦包含真实工具、权限、状态、测试和恢复，它就明显超出 Prompt 范围。
我的判断：Harness 会变薄，但不会消失。模型越有行动能力，权限与观测越重要；任务越长，状态与恢复越重要；领域越专有，可读性与证据治理越重要。能改变我判断的证据是：一个模型在不了解领域结构、没有权限边界和环境验证的情况下，仍能长期、安全、可追溯地修改真实系统。目前我没有看到这种证据。
不要为弱模型硬编码一座迷宫。只保留跨模型仍然成立的资产：业务事实、可执行约束、最小工具、风险边界、验证证据和可恢复状态。
真实案例：这个个人网站，本身就是一套 Harness
如果只有一句“帮我做个人网站”，任何模型都能生成一个页面，但下一次会话会重新猜品牌、目录和进度，也可能把原型、代码和交付物混在一起。为了解决连续协作，这个项目把工作现场显式化。
本轮把 AI Lab 拆成 12 个页面时，Harness 直接改变了执行方式：项目规则阻止源码散落在根目录；Memory 阻止 4D 顺序被改回旧版；共享 CSS 保证字体统一；链接脚本和浏览器检查提供证据；Handoff 记录当前阶段。这里没有一个组件很“智能”，但组合后让工作可以跨会话连续推进。
你在设计一个特殊用户的工作环境：信息能否被发现、动作是否易于理解、风险是否需要确认、错误能否恢复。信息架构、权限设计、防呆、反馈和服务蓝图全部原样适用。懂业务与流程的人，在 Harness Engineering 中不是外行。
两个官方案例，指向同一套底层规律
OpenAI：让仓库对 Agent 可读、让约束可执行
OpenAI 的 Harness Engineering 实践把应用界面、日志、指标和本地环境暴露给 Codex，让它能自己复现与验证；同时把业务知识、架构规则和执行计划放入仓库，通过自定义 linter（静态规则检查器）与结构测试强制执行。重点不是给 Agent 更多文字，而是让系统真实状态能够被观察、让架构边界无法被轻易绕过。
Anthropic：让长任务像工程师换班一样交接
Anthropic 在长时间 Agent 研究中发现，只有高层目标和自动 Compaction 不够。Agent 会试图一次做太多，也可能看到已有进展后过早宣布完成。改进方案包含初始化环境、按功能渐进推进、维护进展文件、留下干净状态和版本历史。它把“下一班工程师如何接手”变成 Harness 的一等问题。
| 共同规律 | OpenAI 实践 | Anthropic 实践 |
|---|---|---|
| 环境可读 | UI、日志、指标与领域知识对 Agent 可访问 | 初始化环境与明确功能清单 |
| 约束可执行 | linter、结构测试与架构边界 | 增量工作、干净状态与验证要求 |
| 状态可延续 | 仓库内版本化计划与知识 | 进展文件、Git 历史与结构化 Handoff |
| 失败可观察 | 浏览器、日志、trace 与性能指标 | 测试、未完成项和下一步状态 |
Claude Code 的组件不是菜单，而是不同控制层
用 Claude Code 举例，是因为它把 Harness 的不同责任做成了可见组件。选组件时不要问“哪个更高级”，要问“这条能力需要何时加载、是否隔离、是否自动触发、是否连接外部世界”。
| 组件 | 承担什么责任 | 适合放什么 | 不要滥用为 |
|---|---|---|---|
| CLAUDE.md | 常驻规则与项目约定 | 每次都必须知道的行为边界 | 长篇参考资料仓库 |
| Skills | 按需加载的知识与流程 | 可复用 SOP、领域规范、动作流程 | 永远常驻的全部背景 |
| Subagents | 隔离上下文的专项执行 | 研究、评审、独立探索 | 所有任务都强制拆分 |
| Hooks | 事件触发的机械执行 | 格式化、测试、权限拦截、审计 | 需要复杂判断的业务决策 |
| MCP | 连接外部数据与工具 | 数据库、业务系统、浏览器与服务 | 没有明确用途的连接器大礼包 |
| Permissions | 限制动作与确认风险 | allow、ask、deny 与运行时拦截 | 一句“请谨慎操作”的文字提醒 |
官方文档给出了一条很实用的区分：CLAUDE.md 适合每次会话都加载的项目约定；Skills 适合按需使用的知识和流程；Subagents 用独立上下文完成专项工作；Hooks 在生命周期事件上自动执行；MCP 负责外部连接。组件的价值来自加载时机和责任分离，不来自数量。
权限设计：不要按工具分，按后果分
很多 Harness 的权限只分“能不能用某个工具”，粒度太粗。同一个终端可以读取文件，也可以删除文件；同一个浏览器可以查看页面，也可以提交表单。更可靠的设计是按动作后果划分。
| 风险级别 | 典型动作 | 默认策略 | 需要的证据 |
|---|---|---|---|
| R0 · Read | 读取文件、页面、日志 | 通常允许 | 范围明确，不读取敏感区 |
| R1 · Reversible | 修改本地原型、生成草稿 | 允许并保留差异 | 备份、版本或可撤销记录 |
| R2 · External | 发送消息、发布、上传、改权限 | 动作前确认 | 目标、内容、账号与影响明确 |
| R3 · Destructive | 删除正式成果、覆盖数据、绕过权限 | 默认拒绝或双重确认 | 必要性、备份和恢复方案 |
权限不是对模型“不信任”，而是对所有执行系统遵守最小权力原则。Claude Code 的权限与 PreToolUse Hooks 甚至允许在常规规则前阻止某类调用，这说明真正的边界要落在动作路径上，而不是只写在提示词里。
Harness Manifest：先设计控制面，再添加能力
这份清单适合新建项目，也适合诊断一个“模型明明很强、结果却不稳定”的现有系统。
<mission> 系统替谁完成什么工作：[填写] 成功的可观察结果：[填写] 必须由人保留的决定：[填写] </mission> <legibility> 业务概念与数据结构住在哪里：[路径] 项目规则、稳定事实、当前状态分别住在哪里：[路径] 知识过期、冲突和所有者如何标记：[规则] </legibility> <capabilities> 完成核心任务必需的最小工具集：[列表] 每个工具的用途、输入、返回与失败方式：[说明] 工具是否提供真实环境反馈：[是 / 否] </capabilities> <permissions> R0 只读自动允许：[列表] R1 可逆写入允许但留痕：[列表] R2 外部副作用必须确认：[列表] R3 破坏性动作默认拒绝：[列表] </permissions> <acceptance> 确定性检查：[测试、schema、链接、阈值] 语义评审：[rubric] 人工闸门：[品牌、风险、价值取舍] 任何修改后的回归范围：[列表] </acceptance> <recovery> 进展与未解问题写入：[路径] 每轮结束必须留下：[状态、证据、下一步] 失败时回滚到：[版本 / 备份] 会话中断后，新执行者的启动顺序：[列表] </recovery>
搭建顺序也很重要：先写 Mission 和 Acceptance，再做领域可读性，随后添加最小工具和权限，最后才自动化。工具是放大器；目标和验收没定时，能力越多，事故面越大。
怎么证明 Harness 真的有用
不要只比较“用了以后答案更好”。Harness 的价值应在失败条件下显现：换模型、换会话、制造冲突、撤掉工具、触碰权限边界，它还能否保持可控。
| 测试 | 故意怎样破坏系统 | 通过标准 |
|---|---|---|
| Model swap | 换成另一款能力相近的模型 | 核心流程、边界与验证仍成立 |
| Fresh session | 从全新会话接手 | 只凭显式状态即可继续，不重做已完成工作 |
| Tool removal | 移除一个关键工具 | 准确上报缺失能力，不伪装完成 |
| Policy conflict | 放入两条互相冲突的规则 | 按优先级处理或升级确认 |
| Permission boundary | 诱导执行外部或破坏性动作 | 触发 ask / deny，而不是仅口头提醒 |
| Long-run recovery | 中断任务并在新窗口恢复 | 能说清状态、失败原因、证据与下一步 |
一个好 Harness 还有一个“反脆弱”指标：每次失败后，系统是否多出一条测试、一条规则、一个更清晰工具或一份更准确状态。失败如果只产生一句“下次小心”，系统并没有学习。
真正的护城河，不是你接入了哪个模型
模型会商品化，工具会更新，今天的最佳工作流也会变。但企业对自身领域的可读表达、可执行约束、权限模型、Eval 数据和恢复纪律不会自动从模型供应商那里获得。
这些资产让模型可替换，让人的判断可复用，让一次成功不再依赖某段神奇对话。Prompt Engineering 把任务说清楚，Context Engineering 给出正确世界，Loop Engineering 让行动接受反馈；Harness Engineering 把三者变成组织可以持续运行的工作系统。
一页带走：检查 Harness 的 10 问
- 系统的 Mission、成功结果和人类保留决定是否明确？
- 关键业务事实对模型是否可发现、版本化且有所有者？
- 规则只是写在文档里，还是有测试或权限强制？
- 工具是否最小、命名清晰、返回结构稳定？
- 模型能否直接观察页面、日志、数据或测试结果？
- 权限是否按后果分级，而不只是按工具开关？
- 哪些外部动作与不可逆决定必须由人确认？
- 新会话能否只凭显式状态继续工作？
- 失败后是否能回滚，并留下可复现证据？
- 换一个模型后，核心制度是否仍然成立？
工程板块到这里完成闭环。下一篇进入智能体板块，并先从 4D Framework 回答：人究竟应该把什么交给 AI，又必须保留什么。