什么是 Harness：大白话聊聊你的 AI 到底需不需要配 Harness
B站UP主”圣徒城的小诺”在 Claude Code 上做的 Harness 工程科普视频。不是理论架空，而是实机横评——在真实项目复杂长链路开发中注入 MCP、Subagent、Hook 等组件，验证”智能不够，工程来凑”的确定性边界。核心结论：中等模型挂载硬性 Hook 后的工程完工度，能够逼近强模型在无约束单会话下的表现。
一句话摘要
Agent = Model + Harness。Harness 的六大组件（MCP / Subagent / Skill / Rule / Hook / Agent Team）各有适用场景。三种使用范式的选择取决于模型强弱——强模型少用 Harness，让模型自己发挥；中等模型用 Harness 的工程性组件（特别是 Hook）以 token 换质量，能逼近强模型效果。
什么是 Harness：从点外卖说起
视频用一个生活化比喻讲清楚了 Harness 的概念：
你用千问大模型点外卖——千问本身是 Model（模型层）。但外卖这件事显然不是千问自己能完成的：它需要接通高德地图的 API 查位置、接入美团的工具查商家和下单、需要一套框架来维护工具调用流程和上下文。后面这些就是 Harness。
Agent = Model + Harness。 Harness 就是在模型外面套的一层框架，让模型能在特定环境中感知、推理、行动。Claude Code、Codex、Cursor、Gemini CLI 这些东西本质上都是 Harness 框架——它们都不提供智能，它们提供一个让智能可以干活的”栖居环境”。
从这个意义上讲，Harness 工程师的工作不是编写智能，而是为智能构建可操作的世界。这与 Harness工程 中的定义完全一致。
Harness 的精神：在有限注意力下让模型爆发
Harness 工程的核心精神只有一句话：在有限的注意力（上下文窗口）下，让模型爆发出最好的效果。
上下文窗口就像模型的工作台——面积有限。Harness 的工作就是决定这张桌子上摆什么、怎么摆，让模型在最干净的上下文中做最高质量的推理。上下文工程 在这一层与 Harness 工程完全交汇。
六大组件：从外到内
1. MCP（Model Context Protocol）——外部数据接入
[MCP 模型上下文协议](MCP 模型上下文协议.md) 是 Harness 最外层的组件，解决的是”模型怎么连上外部世界”的问题。它把数据库、API、文件系统等外部资源统一封装成标准化工具接口。
适用场景：需要模型访问外部数据或服务时。它是最基础、最稳定的 Harness 组件。
注意事项：一个 Playwright MCP Server 就有 21 个工具、消耗 13.7K tokens。如果一个对话需要用到多个 MCP Server，token 开销会急剧膨胀。MCP 是”能力入口”但也是”token 黑洞”。
2. Subagent——上下文隔离的执行者
Subagent 的设计目标是把大任务拆成小块，每个小块在干净的上下文里独立执行。主 Agent 把子任务委派给子 Agent，子 Agent 干完活只把结果带回来。
致命缺陷（视频中的实测发现）：主 Agent 传递复杂需求给子 Agent 时会出现省略 → 不精准 → 渐进式漂移。一个 300 行的需求描述，经过主 Agent 转述后可能只剩下 300 字——子 Agent 拿到的是一个被严重压缩和扭曲的版本。这意味着：你越依赖 Subagent 来处理复杂任务，实际执行质量反而越不可控。
视频作者给了一个很直接的评价：Subagent 目前更适合轻量级的独立任务（如”帮我搜一下 X”），不适合承载复杂需求的委派。
3. Skill——动态提示词加载
[Agent Skill](Agent Skill.md) 的核心思路是 “用到时再加载，别全塞 prompt 里”。Skill 先列目录（名称 + 简短描述），只有被匹配到的 Skill 的完整内容才会被加载到上下文中。
与 MCP 的区别：MCP 提供的是”工具”，Skill 提供的是”能力包”（包含提示词、工具配置、脚本、资源的完整套餐）。一个 Skill 内部可以调用多个 MCP 工具。
4. Rule——按文件类型触发的规则
Rule 是一种条件触发的提示词注入机制。比如”遇到 .tsx 文件时，自动注入 React 编码规范”。它解决了”如何确保 Agent 在不同类型任务中都遵守领域规范”的问题，而不需要在每次对话中都手动贴规范文档。
适用场景：需要跨文件/跨项目维护一致性规则时。比 Skill 更轻量——它只是一段条件提示词，不包含工具或脚本。
5. Hook——最被低估的确定性防线
Hook 是整个 Harness 组件中唯一没有 AI 幻觉的组件。它在 Agent 生命周期的关键节点（工具执行前/后、会话开始/结束）插入确定性脚本——不受模型推理影响，百分百可预测。
视频作者认为 Hook 是 Harness 中最稳定的”防火墙”：
- 模型不会跳过 Hook（它是 Harness 层的强制拦截，不是模型可选择执行的工具）
- Hook 不会犯错（它是确定性代码，不是概率性推理）
- Hook 在”中等模型+Harness”策略中是质量保证的基石
典型用法：代码风格检查 Hook（模型写出代码后自动跑 linter）、安全审查 Hook（执行破坏性命令前强制确认）、合规性 Hook（输出发送前检查敏感信息）。
6. Agent Team——目前还不推荐
多 Agent 协作机制（Agent Team）听起来很高级，但视频的实测结论是：不推荐。
核心问题是 token 冗余达单 Agent 的 5-10 倍。多 Agent 之间的协商、信息同步、决策传递都在消耗大量上下文，但实际产出并没有对应提升。视频作者的判断是”AI 之间的协作还不够成熟”——目前阶段，一个强模型 + 精心设计的 Harness 比一支弱模型的 Agent 团队更高效。
三种使用范式：取决于你的模型有多强
这是视频最核心的实操框架。根据模型的强弱，Harness 的使用策略应该完全不同：
范式一：强模型（Claude Opus 4.7 / GPT 5.5）——少用 Harness
如果模型本身足够聪明、可靠，少用 Harness，让模型自己发挥。 具体策略：
- 单绘画长期工作即可，不需要频繁切会话
- 减少 Subagent 的委派——强模型直接处理比丢给子 Agent 更快更准
- 给模型最大的自由度，Harness 只做最基本的环境搭建
原因：强模型的注意力在”干净”的上下文中最有效。每加一个 Harness 组件都是在消耗上下文窗口和分散模型注意力。
范式二：中等模型（GLM 5.1 / DeepSeek V4 Pro / Kimi 2.6）——重度 Harness
这是 Harness 工程最能发挥价值的场景。策略是：
- 大量使用 Hook：用确定性脚本兜底，弥补模型推理的不足
- 对抗审查多轮迭代：模型输出 → 审查 → 反馈 → 修正，循环直到质量达标
- Skill + Rule 最大化：用提示词补模型能力短板
视频通过实测验证：中等模型在挂载硬性 Hook 后的工程完工度，能够逼近强模型在无约束单会话下的表现。 这是”SMART = 智能不够，工程来凑”的最直接证据——Harness 的实际价值在于它可以让一个中等模型在特定任务上的表现逼近强模型。
范式三：普通模型——简单 Harness
直接用 Claude Code 自带的能力就够了。不需要额外配置复杂的 Harness 组件——模型的瓶颈在能力本身，加再多 Harness 也补不回来。强扭的瓜不甜。
核心理念总结
SMART 法则
SMART = 智能不够，工程来凑。
这不是说 Harness 可以替代模型能力——再好的框架也不可能让一个差模型变聪明。而是说：当模型的能力天花板已经被固定时，精心设计的 Harness 可以让模型在这个天花板内发挥出接近极限的表现。
未来趋势：拆轮子比造轮子更重要
视频提出了一个反直觉的趋势判断：模型能力在持续提升，这意味着很多今天必要的 Harness 组件明天就变成了冗余。 Harness 工程师的长期工作不仅是”造轮子”，更是”拆轮子”——当模型某个方面的能力提升到不需要对应 Harness 组件时，果断拆掉它，别让它白白消耗上下文。
这与 pi-coding-agent 的设计哲学高度吻合——“如果我不需要它，就不造它”的下一句是”如果我曾经需要但现在不需要了，就拆掉它”。
与其他笔记概念的关联
| vault 概念 | 视频中的对应 |
|---|---|
| Harness工程 | 直接定义了 Harness 的六大组件和三种范式 |
| [Agent Skill](Agent Skill.md) | Harness 六大组件之一（Skill） |
| Subagent | 详细分析了致命缺陷——需求传递中的渐进式漂移 |
| [MCP 模型上下文协议](MCP 模型上下文协议.md) | 六大组件最外层，数据入口 + token 黑洞的 double-edged sword |
| 上下文工程 | Harness 的精神就是”在有限上下文里让模型爆发” |
| learn-claude-code教程 | LCC 提供了 20 课实现 Harness 六大组件的方法 |
| pi-coding-agent | 最极端的”少用 Harness”范式——4 个工具，极简即最强 |
重要引用
“SMART = 智能不够，工程来凑”
“Harness 的精神：在有限注意力下，让模型爆发出最好的效果”
“Subagent 的致命缺陷：主绘画传递复杂需求时，出现省略、不精准、多次漂移”
“模型能力提升后，应该拆掉对应的 Harness 轮子”