过去两年，AI 行业的叙事一直围绕模型展开：参数规模、benchmark、上下文窗口、推理速度、价格曲线，以及“谁的模型更强”这种最直观、也最容易传播的竞争维度。这样的讨论并不错误，但它越来越不足以解释一个更现实的问题：为什么看上去能力接近的模型，被放进不同产品后，实际体验差异会如此之大。
真正的分水岭，往往不发生在模型层，而发生在模型外层的工程组织方式上。
当一个模型被真正放进终端、文件系统、Shell、代码仓库、审批流程与团队协作机制之后，它面对的就不再是抽象的问答任务，而是一个充满边界、反馈、失败、恢复与治理要求的真实工程环境。此时，决定产品上限的已经不只是模型本身，而是那一整套把不稳定智能约束为稳定系统的运行时结构。
这套结构，正是 Harness Engineering。
导读
《Harness Engineering：Claude Code 设计指南》的导读提供了一个非常清晰的切入点：
它关心的不是“模型会不会写代码”，而是“一个会写代码的模型被放进终端、仓库和团队流程以后，怎样才不会把系统带偏”。
这句话几乎可以作为整个 AI Agent 时代的工程命题。因为它把讨论焦点从“能力展示”转向了“运行时治理”。从控制平面、主循环、工具权限与中断，到上下文治理、错误恢复、多代理验证，再到团队落地与制度化，这些结构并不是某一家产品的工程癖好，而是 AI 工具一旦走向生产级，几乎必然会长出来的系统骨架。
也正因为如此，今天如果还有团队把 AI Agent 理解为“模型 + Prompt + 一层 UI”，那么它大概率仍停留在 demo 时代。真正进入下一阶段的产品，拼的已经不是“会不会”，而是“如何稳定地做”。
核心要点
- Harness Engineering 的核心，不是增强模型能力，而是把模型输出收束进稳定、可治理的工程系统。
- 一个成熟的 Agent 产品，至少需要覆盖控制平面、Query Loop、工具与权限、上下文治理、错误恢复、多代理验证与团队制度化这几层能力。
- Prompt 不是人格包装，而是控制平面；Memory 不是仓库，而是预算制度；多代理也不是炫技，而是对冲模型不稳定性的工程结构。
- 未来 AI 工具行业的竞争，将越来越像运行时平台竞争，而不是单纯的模型能力竞争。
- 对企业与开发者而言，真正有价值的 AI 产品，不是最会展示“智能”的那个，而是最能稳定执行、可被治理、可被部署的那个。
Harness Engineering 究竟是什么
可以把 Harness 理解为 AI Agent 的运行时骨架。
模型更像“大脑”，而大脑本身并不会天然变成一个可长期信任的行动者。要让它真正工作，还需要边界、流程、反馈、恢复、记忆、验证、协作与制度化约束。Harness Engineering 处理的，正是这部分问题。
它要回答的不是“模型会不会”，而是下面这些更接近系统设计的问题：
- 模型何时推理，何时行动
- 行动时能调用哪些工具
- 哪些动作可以自动执行，哪些必须中断审批
- 长任务中的记忆如何组织，如何避免上下文腐烂
- 工具失败或方向偏离之后，系统如何恢复
- 多个代理之间如何分工、隔离与相互验证
- 团队如何把这些规则沉淀成可复用的制度
从这个意义上看，Harness Engineering 不是“模型上的附加层”，而是 Agent 产品从实验走向生产的真正分水岭。
一套标准设计，至少应包含六层结构
一、控制平面：Prompt 不是人格，而是政策层
《设计指南》中有一个非常关键的判断：Prompt 不是人格，而是控制平面。
这意味着系统提示最重要的价值，不在于把模型塑造成一个“有趣角色”，而在于明确系统边界。一个成熟 Agent 的 Prompt，更像一份运行时政策，它需要规定：
- 角色与任务边界
- 工具访问规则
- 风险升级条件
- 成本与预算限制
- 记忆写入约束
- 审批触发条件
- 失败后的恢复原则
- 多代理分工的基本规则
也就是说，Prompt 的目标不是让模型“更像人”，而是让系统“更像程序”。
二、Query Loop：代理系统的心跳
如果说控制平面定义了“边界”，那么 Query Loop 就定义了“生命体征”。
真正的 Agent 并不是“一次输入，一次输出”的聊天机，而是在不断重复一个系统循环：
理解任务 → 形成计划 → 调用工具 → 读取结果 → 更新状态 → 决定下一步
这个主循环决定了系统究竟是：
- 一个只会回答问题的助手
- 还是一个能持续推进任务的执行体
而一个成熟的 Query Loop，至少要解决四类问题：
- 状态推进：任务如何持续接近完成，而不是来回空转。
- 动作切换：什么时候该继续推理，什么时候该触发工具。
- 失败管理：工具失败、权限被拒或上下文不足时怎么办。
- 停止条件：什么时候应该结束，而不是陷入无限循环。
没有稳定的 Query Loop，就没有真正意义上的 Agent。
三、工具与权限：为什么 Agent 不能直接碰世界
只要 Agent 拥有读写文件、运行命令、访问网络、连接第三方服务的能力，它就不再只是一个“生成内容”的模型，而是在执行现实动作。
这意味着权限体系必须前置，而不是事后补洞。
一套标准设计，至少应包含：
- allow / ask / deny 三层策略
- 路径级、参数级或命令模式级限制
- 对高风险行为的人工中断
- 对执行结果的完整审计记录
- 对沙箱逃逸、路径穿透的保护
这层结构的意义，并不是“削弱智能”，而是让智能进入真实世界后仍然可被信任。
四、上下文治理：Memory 是预算制度，而不是仓库
《设计指南》把 Memory、CLAUDE.md 与 Compact 理解为“预算制度”，这个判断非常准确。
很多团队一开始都会犯一个错误：把更多历史、更多文件、更多日志都塞进上下文，希望模型“知道得越多越聪明”。但长任务中最先崩掉的，通常不是知识量，而是上下文质量。
更合理的结构，往往是三层：
- 常驻索引层：保留任务状态、关键事实与定位信息
- 主题知识层：按主题组织、按需读取
- 原始日志层：保留历史，但只做检索，不整体灌回上下文
这样设计的意义，并不仅仅是节省 token，更是为了让系统长期保持认知清洁度。Memory 如果没有治理，最终只会把 Agent 变成一个在噪音里迷路的系统。
五、错误恢复：把失败当作系统常态
生产级 Agent 必须假设失败会不断发生：
- 模型会误判
- 工具会超时
- Shell 命令会报错
- 审批会中断
- 多代理协作会失配
- 上下文会被污染
因此，系统设计的重点不能是“绝不出错”，而必须是“出错后仍能继续工作”。
标准恢复机制通常包括：
- 文件写入失败后的回滚或重试
- 批任务的检查点与断点续跑
- 工具失败后的替代路径
- 不确定结论的显式标注与复核
- 会话恢复与上下文重建能力
这层能力决定了 Agent 是一个易碎玩具，还是一个真正可进入生产环境的系统。
六、多代理与验证：用结构对冲不稳定性
《设计指南》把多代理与验证单列为一章，本身就说明了问题的重要性。
在复杂任务里，单代理往往需要同时承担理解、规划、执行、复核与总结等多种职责。一旦这些角色全部叠在同一个上下文里，就很容易导致信息污染、判断失真与任务漂移。
更成熟的方式，是通过结构分工来降低风险：
- 主代理负责任务拆解与最终整合
- 执行代理完成具体子任务
- 验证代理复核关键结果
- 隔离工作区或隔离上下文，避免互相污染
- 代理之间通过明确协议交换结论，而不是共享一锅混乱上下文
多代理的价值，不是为了“显得高级”，而是为了在复杂任务中把模型的不稳定性关进结构里。
为什么这套标准会成为行业共识
从行业演进看，Harness Engineering 并不是某一家公司的内部偏好，而更像一种技术必然。
原因其实很简单：
- 模型能力会逐步扩散
- Prompt 技巧会被复制
- UI 交互会被模仿
- 但运行时架构、权限系统、恢复机制、上下文治理与多代理协议，复制成本更高，也更贴近真实生产价值
因此，未来真正拉开差距的，不会只是“谁的模型更强”，而是：
- 谁的 Agent 更稳
- 谁的治理更可信
- 谁的长任务能力更强
- 谁的组织落地成本更低
- 谁能把这些机制沉淀为可复用制度
这也是为什么 Harness Engineering 会成为 AI 工具行业下一阶段真正的主战场。
我对前沿 AI 工具行业的看法
如果把视角再拉高一点，我对未来前沿 AI 工具行业有几个比较明确的判断。
1. 模型差距仍重要，但不再解释全部产品竞争
未来仍然会有模型代差，也仍然会有 benchmark 竞争，但最终产品体验的差异，会越来越多地来自运行时，而不是基础模型的单点指标。
2. AI coding 与开发者工具仍然是最前沿试验场
原因很简单：代码、终端、仓库、测试、CI/CD 这些环境天然结构化、可验证、可回滚，也更适合 Agent 深度介入。所以很多先进的 Harness 设计，会先在开发者工具领域成熟，再向更广的企业工作流扩散。
3. 安全与治理会从成本项变成卖点
早期团队往往把权限、审计、恢复、沙箱这些能力视为“拖慢创新的负担”，但当 Agent 真正走进企业，用户最愿意买单的，恰恰是这些看起来不性感的能力。因为它们决定了产品能不能进入生产环境。
4. 行业竞争会从“惊艳演示”转向“稳定自治”
未来最强的产品，不一定是第一次试用时最惊艳的那个，而是第三十次、第一百次使用时，仍能稳定完成任务、清楚给出依据、并且可被组织级部署的那个。
5. 下一代头部产品，会越来越像认知执行基础设施
最终胜出的 AI 工具，很可能不只是聊天入口，也不只是 IDE 插件，而是长在操作系统和工作流之上的一层“认知执行基础设施”：它理解目标、连接工具、维护上下文、分配代理、执行任务，并保留审计与恢复能力。
谁先把这层基础设施做成标准，谁就更有机会定义下一代工作台。
结语
Harness Engineering 真正重要的地方在于，它让整个行业开始正视一个事实：
AI Agent 产品的竞争，正在从“模型会不会”转向“系统允许模型怎样稳定地做事”。
这不是某个框架流行起来带来的话术变化，也不是某一家产品的内部黑话，而是未来几年 AI 工具行业最核心的结构性变化之一。
对于开发者、产品经理、创业者和企业技术负责人来说，越早建立对 Harness Engineering 的理解，就越能看清：哪些产品只是 demo，哪些产品正在长成下一代基础设施。
参考信息
- Harness Engineering：Claude Code 设计指南（导读）
- Claude Code 相关公开技术讨论
- AI Agent、终端工具与开发者工作流产品的近期演进