8.Harness

引子

前七章把ClaudeCode拆到了"零件"级：工具调用循环、权限、Memory（记忆）、Skill（技能）、SubAgent（子智能体）、Hook（钩子）、MCP（Model Context Protocol，模型上下文协议）、Plugin（插件）。

随之而来的问题是：这套工具，是ClaudeCode独有的，还是所有Agent（智能体）共通的？换一个产品，比如OpenClaw，前七章的内容还有多少继续成立？

前七章，其实是一场持续的收束：《1.Start》开篇立下一句话ClaudeCode的本质是"大模型+工具调用循环+上下文管理"。之后每一章，都把一个"零件"收回到这句话上。但，这是站在ClaudeCode内部，针对一个产品的总结。

这套本质，有没有一个更大的、离开ClaudeCode也依然成立的名字？

有。Harness工程（Harness Engineering）。

$$\text{Agent}=\text{模型}+\text{Harness}$$

从提示词工程到Harness工程

三段演进

Agent的开发范式，2023年至今走过了三段。
每一段都不是推翻上一段，而是在上一段暴露出局限时，把关注点往外扩一层。

阶段	时间	关注点	上一段的局限
提示词工程（Prompt Engineering）	约2023年	打磨单次"提示-响应"，把单条提示写好。
上下文工程（Context Engineering）	约2025年	系统化地构建、管理、演化模型的整个输入语境。	单次提示无法支撑复杂任务：意图偏移、长程记忆缺失、逻辑断层。
Harness工程（Harness Engineering）	2026年	为模型造一个能长时间稳定、安全运行的环境。	仅有好的上下文不够，长时任务还需要能支撑它的运行环境。

Anthropic对第二段的描述是：对于Agent开发，正从"找对措辞"，转向一个更本质的问题：什么样的上下文配置，最可能让模型产生我们想要的行为。

而第三段的出现有其背景：2025年起，衡量Agent的标准变了，不再比单轮问答的质量，而是反复强调"能连续跑几小时、整夜执行、无人值守"。
Deep Research能持续调研数十分钟，ClaudeCode能自动编码、测试、修BUG、再测试，闭环连跑数小时，OpenClaw能7×24小时处理从邮件整理到股票监控的任务。
任务从"短时交互"迈向"长时执行"。

而"长时执行"的困难在于：

1. 模型会犯错，且错误会复利式放大。
2. 上下文越长，质量越差。

而这两个问题，都无法靠模型自身解决。

注意：虽然现在模型支持的上下文窗口越来越长，已经有1M token的窗口了，但这不意味着长上下文中，质量不会变差。

Agent = 模型 + Harness

Harness原意是"马具"，套在马身上、让人能驾驭马的那套挽具，引申为套在模型外面、让模型能够在真实环境中稳定工作的整套外围设施。

$$\text{Agent}=\text{模型}+\text{Harness}$$

回看本系列开篇提到的那句"大模型+工具调用循环+上下文管理"，其实是这个公式的一个特例：工具调用循环（Agent Loop）是Harness的引擎，上下文管理是Harness的核心课题。

AI落地的两个方面

Agent=模型+Harness，这也就是AI落地所的两个方面。

1. 训练模型，提升推理能力，或在同等能力下降低训练与部署成本。
2. 构建Harness，让同一个模型在真实世界完成更多有价值的任务。

模型决定能力的上限，Harness决定能力的兑现。

Harness在克服什么

上文「三段演进」提到过，困难在于：

1. 模型会犯错，且错误会复利式放大。
2. 上下文越长，质量越差。

一套Harness，本质上就是围绕这两个困难搭建的结构。

会发散的长程执行

长时执行会让错误复利式放大。

一个单步正确率99%的模型，单看已经相当可靠；但要它自主连续执行100步，端到端全部正确的概率是0.99的100次方，只剩约37%。
步数越多，执行链越容易在中途某一步进入错误路径，并把错误当作既成事实继续累积。
单轮问答里影响很小的低概率失误，在长程任务里会被指数级放大为整体失败。

所以长时Agent的重点，不在"让某一步更准确"，而在"抑制整条链的发散"。

会贬值的上下文窗口

窗口有限，是本系列主线"上下文管理"背后的硬约束；这个约束需要更进一步的刻画：窗口的问题不只是"会满"，而是填充越多，质量越差。
上下文越长，模型的注意力被稀释得越严重，真正关键的内容会被淹没在大量已读文件、命令输出、历史消息里。即，输入的token越多，不代表模型理解得越好，反而可能更差。
所以上下文工程真正的目标，不是"把信息装进窗口"，而是：找出能达成目标的、最小的一组高信号token。

我们可以做一个很简单的实验。

已知公交车上有10人，到站2人下车，3人上车，问现在有多少人？
这是一个很容易回答的问题。

换一下。
已知公交车上有10人，小王、小李、小张、小赵上车了，小孙下车了，小周也下车了，小吴在关门前赶上车了。问现在有多少人？

这是一个典型的例子：上下文更长，把上下车的具体人，甚至谁是关门前赶上的，都讲清楚了。
输入的token更多了，但质量更差了。对"现在有多少人"这个目标而言，是一条噪声极大的prompt。

Harness：ClaudeCode是怎么做的

克服发散：四大模块与五大能力

无论Agent形态如何变化，业界常把一轮任务的回路拆成四个模块：感知、规划、执行、反思；工程化落地时，四个模块各对应一种能力；真实系统再补充第五种，协作（人机协作）。

模块	工程化能力	在做什么	在ClaudeCode里的对应（举例）
感知	意图识别	把自由的自然语言归到结构化意图，路由到该处理它的地方。	靠description语义匹配，决定触发哪个Skill、委派哪个SubAgent。
规划	计划模式	先输出思维链或方案，再执行。	plan模式与Plan这个内置Agent，Plan只读调研、主对话定稿。
执行	CodeAct（代码即行动）	让模型直接生成代码、交执行器运行，而非堆砌专用窄工具。	工具调用循环里的Bash工具。
反思	反思模式	对规划与执行的结果自查，发现问题就重新规划。	循环的"验证结果"阶段就是反思；"测试没过不许结束"的Stop Hook把它固化成了确定性动作。
（协作）	人机协作	关键节点交由人来决策。	权限系统的"先问我"、AskUserQuestion。

意图识别负责正确路由，计划模式先规划后执行，CodeAct让一段代码顶掉多次窄工具调用、缩短执行链（步数越少，复利放大越小），反思模式自查纠偏，人机协作在关键节点收回控制权。
这条回路针对的，正是长程执行的发散。

题外话：其实这五个能力要求（感知、规划、执行、反思、协作），不仅仅适用于Agent，对工程师这个职业（甚至所有的职业），可能同样适用。

克服贬值：上下文工程

这部分有一个正式的名字，就是「三段演进」里的第二段：上下文工程。
上下文工程没有被Harness工程取代，而是成为Harness的内核，Harness工程正是从上下文工程发展而来。

所谓上下文，不只是消息历史，还包括系统提示词、工具定义与示例，即前文说的整个输入语境。

上下文管理的手法有四种。

手法	解决什么	在ClaudeCode里的对应（举例）
持久注入	稳定知识跨会话不丢。	《2.Memory》
上下文卸载（Context Offloading）	成段指令平时不占窗口，用时才加载。	《3.Skill》
上下文隔离	高噪声子任务不污染主窗口。	《4.SubAgent》
上下文压缩（Compaction）	窗口快满时，把老对话换成摘要，腾出空间继续跑。	/compact与自动压缩，见《1.Start》

四招方向一致：保留高信号内容、去掉低信号内容。
持久注入固定最需要常驻的信息，卸载让低频指令仅在使用时加载，隔离让高噪声过程完全不进入主窗口，压缩把已经进入窗口的历史换成摘要。

但要注意：管理上下文，是在管理损失，而非消除损失。

本系列讲的记忆、技能、子智能体等等，实质是同一门上下文工程：在一个会贬值、且每次管理操作都有损失的窗口里，反复权衡信噪比。

回到上文的例子，“已知公交车上有10人，小王、小李、小张、小赵上车了，小孙下车了，小周也下车了，小吴在关门前赶上车了”，压缩成了"已知公交车上有10人，到站有5人上车了、2人下车"。
现在问，小吴上车了吗？
这就是在压缩中，丢失了需要的细节。

所以，ClaudeCode简直绝了，我们在工作中，可能会丢1000行的日志给ClaudeCode，ClaudeCode不但能从1000行日志中找出有用的5行，还能在上下文压缩中，把无用的内容丢掉。

总表：从七章到通用模式

现在回到前七章。每一章讲的ClaudeCode机制，都不是ClaudeCode的私产，而是通用Harness模式。

本系列章	ClaudeCode里的样子	通用Harness模式	克服哪个困难	换个Agent一样需要它
《1.Start》	工具调用循环	Agent Loop	发散	任何长时Agent的引擎，没有Loop就只有单轮问答。
《1.Start》	权限系统	安全边界与沙箱	发散	长时、无人值守运行必须有的护栏。
《2.Memory》	Memory	长期记忆与持久上下文	贬值	跨会话、跨任务的知识不必每次重建。
《3.Skill》	Skill	上下文卸载	贬值	能力按需加载，不常驻消耗窗口。
《4.SubAgent》	SubAgent	上下文隔离与多Agent	贬值	拆分噪声、并行协作。
《5.Hook》	Hook	确定性脚手架	发散	在概率内核外面加"必然发生"的动作。
《6.MCP》	MCP	工具边界扩展	配套：扩展边界	接入外部系统的标准接口。
《7.Plugin》	Plugin	Harness的打包分发	配套：打包分发	把积累的Harness复用、共享、版本化。

八项机制中，Memory、Skill、SubAgent克服窗口贬值，Agent Loop、权限、Hook克服执行发散；其余两项是配套设施，MCP负责扩展边界，Plugin负责打包分发。

注意：Skill和SubAgent在前文「克服发散：四大模块与五大能力」的表里也出现过，那是它们的description路由在充当意图识别。同一个机制可以两头出力，总表按它主要克服的困难归类。

至此，回答本章开头的问题：这套工具，不是ClaudeCode独有的，是所有Agent共通的。

设计哲学：一个微妙的平衡

总表回答了"需要哪些零件"；还剩一个问题：确定性的部分给多少，交给模型的部分留多少。这是每副Harness都绕不开的配比题，也是ClaudeCode设计哲学的核心。

编工作流，还是造Agent

Anthropic在《Building effective agents》里划过一条界：工作流（workflow） 是用预设好的代码路径去编排模型与工具；Agent 是让模型自主决定怎么用工具、怎么推进任务。

维度	工作流	Agent
谁定每一步	开发者预先写死的代码路径。	模型临场决定。
适合	步骤可预测、可穷举的任务。	开放式、步数无法预先确定的任务。
代价	可控但僵硬，换个场景就得重编。	灵活但需要对模型的判断有基本信任。

现实中的复杂Harness往往是两者的混合，主干让模型自主，个别必须卡死的节点用工作流兜底。

概率内核和确定性脚手架

过去两年有一条弯路：给模型排一套复杂的固定工作流，强行引导模型的每一步。
ClaudeCode没有走这条弯路，而是反过来：
不替模型规定每一步怎么走，而是为模型构建一个合适的工作环境，把执行决策留给模型。

但这并不是说完全放任模型自由发挥。

模型是一个概率内核，它大概率遵循指令，但不是百分之百。不应该假设内核完全可靠，需要加一些确定性的脚手架。

但脚手架不是越多越好。

脚手架越多，行为越可预测，但系统也越僵化，越接近被ClaudeCode避开的"复杂工作流"；交给模型的越多，能力越强、越灵活，但失败模式也越开放、越难事先穷举。

Harness工程的一项核心工作，就是确定这条线的位置。是在可预测性和能力之间，做一个微妙的平衡。