2020 年我们学会了跟模型说话（Prompt Engineering），2025 年我们学会了给模型喂信息（Context Engineering），2026 年我们学会了给模型搭脚手架（Harness Engineering）。这三个 Engineering 不是并列关系，而是严格的超集关系：PE ⊂ CE ⊂ HE。本文从"为什么上一个不够"的视角，系统梳理这条演进路径上的每一次范式跃迁。

一个类比秒懂三级跃迁

在讲技术之前，先用一个所有人都能理解的类比。

想象你要指挥一个完全失忆的天才厨师做一桌满汉全席：

  • Prompt Engineering 就是学会怎么跟厨师下达指令。你发现说"做道好吃的"不行，得说"用中火煎三分钟，翻面后加酱油 15 毫升"。这是措辞的艺术。
  • Context Engineering 就是学会怎么给厨师备料。光会下指令不够——厨师面前得摆好食材、调料、菜谱、食客的过敏信息。你要设计一个动态备料系统，让厨师在需要的时候拿到需要的东西。
  • Harness Engineering 就是学会怎么管理整个厨房。满汉全席要做三天，但厨师每隔四小时就会彻底失忆。你需要一个厨房管理系统：交接班记录、每道菜的完成清单、质检流程（试吃员）、食材库存管理。没有这个系统，厨师每次醒来都会从头开始切葱。

这就是三级跃迁的本质：从"怎么说话"到"怎么备料"再到"怎么管厨房"。

一张图看懂三级跃迁

在深入每个阶段之前，先建立一个全局视角。这三个 Engineering 的关系不是"替代"，而是"包含"——每一个都是前一个的超集，解决了前一个解决不了的问题：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌─────────────────────────────────────────────────────────────┐
│                  Harness Engineering                         │
│  跨上下文窗口的状态持久化、验证闭环、环境管理、多智能体编排     │
│                                                              │
│  ┌─────────────────────────────────────────────────────┐     │
│  │              Context Engineering                     │     │
│  │  工具调用、RAG、上下文压缩、动态信息注入、记忆管理     │     │
│  │                                                      │     │
│  │  ┌─────────────────────────────────────────────┐     │     │
│  │  │          Prompt Engineering                  │     │     │
│  │  │  指令措辞、CoT、Few-shot、输出格式控制        │     │     │
│  │  └─────────────────────────────────────────────┘     │     │
│  └─────────────────────────────────────────────────────┘     │
└─────────────────────────────────────────────────────────────┘

Harrison Chase（LangChain CEO）明确表述了这个超集关系：

Prompt engineering is a subset of context engineering. Even if you have all the context, how you assemble it in the prompt still absolutely matters.

而他在 2026 年 3 月进一步指出，Harness Engineering 是 Context Engineering 的自然延伸：

This “harness engineering” is an extension of context engineering.

下面我们沿着时间线，逐一拆解每个阶段的"为什么需要"和"为什么不够"。

第一阶：Prompt Engineering——教模型说人话

起源：GPT-3 的 Few-shot 时刻

2020 年 5 月，OpenAI 发布了 GPT-3 论文 Language Models are Few-Shot Learners。这篇论文的核心发现是：只要在 prompt 中提供几个示例，大语言模型就能在无需梯度更新的情况下完成新任务。

这个发现催生了一个全新的工程学科：如何措辞你的指令，才能让模型给出最好的回答？

核心技术演进

Prompt Engineering 在 2020-2023 年间经历了快速的技术迭代：

时间 技术 核心贡献 论文
2020.5 Few-shot Learning 通过示例教模型学习任务模式 Brown et al., GPT-3
2022.1 Chain-of-Thought (CoT) 通过中间推理步骤提升复杂推理能力 Wei et al.
2022.10 ReAct 将推理和行动交错，允许模型与外部环境交互 Yao et al.
2023.5 Tree of Thoughts (ToT) 探索多条推理路径并自我评估 Yao et al.

其中 Chain-of-Thought 是最具里程碑意义的突破。Wei et al. 在 2022 年的论文中证明：

通过生成一系列中间推理步骤（chain of thought），可以显著提升大语言模型执行复杂推理的能力。

在 GSM8K 数学应用题基准上，仅仅 8 个 CoT 示例就让 540B 参数模型达到了当时的 SOTA。这说明模型的推理能力不是不存在，而是需要被正确的 prompt 激活。

PE 解决了什么

Prompt Engineering 解决了 LLM 早期使用中的四个核心痛点：

  • 输出质量不稳定：通过结构化 prompt 和示例引导，让模型产生更一致的输出
  • 推理能力不足：CoT 等技术通过显式推理步骤，显著提升了算术、常识和符号推理任务的表现
  • 指令遵循不精确：通过清晰的指令、示例和格式要求，提高了指令遵循的准确性
  • 任务泛化性差：Few-shot learning 使模型能够快速适应新任务而无需微调

用一句话概括：PE 教会了我们如何跟模型说话，让它听懂我们要什么。

PE 的根本局限：它只管"说什么"，不管"知道什么"

但随着使用场景的复杂化，PE 的局限性逐渐暴露。这些局限不是"prompt 写得不够好"能解决的，而是 PE 这个范式本身的边界：

局限一：单次调用的天花板。 PE 本质上是优化单次 LLM 调用的输入。但复杂任务——比如"帮我重构这个模块"——需要多步骤、多工具、多轮迭代。PE 无法编排这种多步骤的工作流。

局限二：上下文窗口的盲区。 PE 只关注 prompt 本身的措辞，但模型看到的不只是 prompt——还有系统提示词、对话历史、工具定义、检索结果等。随着对话变长，模型的注意力会衰减——这个现象被称为 Context Rot（上下文腐化），PE 对此无能为力。

Chroma Research 的专项研究揭示了这个问题的严重性：

Context rot is the degradation in LLM output quality that happens as input context grows longer.

即使是在模型理论上"应该能解决"的任务上，随着输入上下文长度的增加，LLM 也会经历显著的系统性性能下降。这不是 prompt 写得好不好的问题，而是 Transformer 架构的结构性限制。

局限三：无法感知外部环境。 PE 局限于模型内部推理，无法与外部 API、数据库、文件系统交互。ReAct 论文虽然提出了推理+行动的框架，但它本质上已经超越了纯粹的 PE——它需要工具调用的基础设施支撑。

局限四：无法跨会话持久化。 PE 是会话内的技术。当一个对话结束、新的对话开始时，之前所有精心构造的 prompt 上下文都消失了。

Neo4j 的一篇技术博客精辟地总结了这个区别：

Prompt engineering focuses on wording. Context engineering focuses on supplying the right knowledge for the model to work with. Prompts shape how the model thinks. Context shapes what the model actually knows.

当我们意识到"说什么"已经不够，还需要管理"模型知道什么"时，Context Engineering 应运而生。

回到厨师的类比：你已经学会了精确下达指令（“中火煎三分钟”），但厨师面前空空如也——没有食材、没有调料、没有菜谱。光会说话不够，还得学会备料。

第二阶：Context Engineering——给模型喂正确的信息

起源：从一条推文到业界共识

2025 年 6 月，Shopify CEO Tobi Lütke 在 Twitter 上写了一条推文，引爆了这个概念：

I really like the term “context engineering” over prompt engineering. It describes the core skill better: the art of providing all the context for the task to be plausibly solvable by the LLM.

紧接着，Andrej Karpathy（前 Tesla AI 负责人、OpenAI 联合创始人）公开 +1：

Context engineering is the delicate art and science of filling the context window with just the right information for the next step. Science because doing this right involves task descriptions and explanations, few shot examples, RAG, related (possibly multimodal) data, tools, state and history, compacting […]

Simon Willison 在 2025 年 6 月 27 日撰文支持这个术语，指出它比 “prompt engineering” 更准确地描述了实际工作：

The term context engineering has recently started to gain traction as a better alternative to prompt engineering. I like it. I think this one may have sticking power.

2025 年 9 月 29 日，Anthropic 发布了官方的 Context Engineering 指南，正式将其定义为 Prompt Engineering 的自然演进：

At Anthropic, we view context engineering as the natural progression of prompt engineering.

核心定义：从"措辞"到"信息环境"

综合各方定义，Context Engineering 的核心可以这样理解：

Anthropic 的定义：Context Engineering 是一组策略，用于在 LLM 推理时策划和维护最优的 token 集合（信息），包括 prompt 之外的所有可能进入上下文窗口的信息。

Harrison Chase（LangChain）的定义：Context Engineering 是构建动态系统，以正确的格式提供正确的信息和工具，使 LLM 能够合理地完成任务。

Phil Schmid 的定义：Context Engineering 是设计和构建动态系统的学科，在正确的时间、以正确的格式提供正确的信息和工具，给 LLM 完成任务所需的一切。

注意这些定义中反复出现的关键词：动态系统、正确的信息、正确的格式、正确的时间。这不再是"写一个好 prompt"的问题，而是"设计一个信息供给系统"的问题。

为什么需要 CE：四个催生因素

PE 的四个局限性，恰好对应了四个催生 CE 的技术变革：

催生因素一：工具调用（Tool Use）的引入。 当 LLM 获得了调用外部工具的能力——搜索网页、读取文件、执行代码、查询数据库——每次工具调用都会产生新的数据，这些数据需要被注入上下文。工具定义本身也占据上下文空间。Anthropic 指出：工具定义了智能体与其信息/行动空间之间的契约。管理这个契约，已经超出了 PE 的范畴。

Anthropic 在 Building Effective Agents 中进一步提出了 ACI（Agent-Computer Interface） 的概念——类比于 HCI（Human-Computer Interface），ACI 是智能体与其工具和环境之间的交互界面。好的 ACI 设计意味着：工具的名称和描述要足够清晰，让模型不需要猜测就知道何时使用哪个工具；参数格式要直观，减少模型犯错的可能；错误信息要有诊断价值，帮助模型自我纠正。Anthropic 原文的表述值得铭记：

Spend just as much time optimizing your tools and tool descriptions as you do your overall prompt.

催生因素二：RAG（检索增强生成）改变了信息供给模式。 从"把所有信息预加载到 prompt 中"转向"按需检索"（Just-in-time retrieval）。Claude Code 使用轻量级标识符（文件路径、存储查询）在运行时动态加载数据，而不是一开始就把所有代码塞进上下文。这种动态检索策略需要系统级的设计。

催生因素三：Agent Loop 改变了对话模式。 智能体不再是"一问一答"，而是在 LLM 调用和工具调用之间循环——观察、思考、行动、观察、思考、行动……每一轮循环都需要重新构造上下文：哪些历史信息保留？哪些工具结果注入？哪些可以丢弃？

催生因素四：Context Rot（上下文腐化）成为实际瓶颈。 Anthropic 的研究发现，随着上下文窗口中 token 数量的增加，模型准确回忆信息的能力会下降。这不是 prompt 写得好不好的问题，而是 Transformer 架构的 n² 注意力关系和训练数据分布偏向短序列导致的结构性问题。

CE 的核心组成：四大策略

LangChain 将 Context Engineering 的策略归纳为四类：

Write Context（写入上下文）：让智能体在工作过程中主动记录信息——临时笔记（Scratchpads）、长期记忆（Memories）、持久化文件。这些信息会在后续步骤中被重新注入上下文。回到厨师类比：这就像厨师在做菜时随手在便签纸上记下"酱汁已调好，放在三号灶台"。

Select Context（选择上下文）：动态检索最相关的信息——从记忆中检索相关经验、从知识库中检索相关文档（RAG）、从工具集中选择最相关的工具（RAG for tool descriptions）。就像厨师不需要把整个仓库的食材都搬到面前，只需要在做红烧肉时，有人把五花肉、酱油和冰糖递过来。Anthropic 在其多智能体研究系统中验证了这一策略的威力：他们甚至创建了一个专门的 tool-testing agent，让它反复使用有缺陷的 MCP 工具，然后重写工具描述以避免失败。原文记录了这个过程的效果：

This process for improving tool ergonomics resulted in a 40% decrease in task completion time for future agents using the new description, because they were able to avoid most mistakes.

这不是因为工具本身变了，而是因为模型在每个步骤只看到与当前任务最相关的工具描述，减少了选择困难和 token 浪费。

Compress Context（压缩上下文）：当上下文变长时，通过摘要（Summarization）、修剪（Trimming）、压缩（Compaction）等策略，在不丢失关键信息的前提下减少 token 消耗。就像厨师的操作台空间有限，做完凉菜后要把凉菜的食材收走，腾出空间给热菜。

Isolate Context（隔离上下文）：通过多智能体架构，将不同任务的上下文隔离到不同的智能体中，避免单个上下文窗口过载。就像大型厨房分设凉菜间、热菜间、面点间——每个厨师只看到自己需要的信息，互不干扰。

Anthropic 提出了一个精炼的黄金法则：

找到最小的高信号 token 集合，最大化期望结果的可能性。

CE 的根本局限：它只管一个上下文窗口内的事

Context Engineering 是一个巨大的进步——它把工程师的视野从"一条 prompt"扩展到了"整个信息环境"。但它仍然有一个根本性的边界：CE 的作用域是单个上下文窗口。

局限一：跨上下文窗口的状态传递。 当一个复杂任务需要跨越多个上下文窗口时——比如构建一个完整的 Web 应用，可能需要数十轮对话——CE 无法解决"下一个上下文窗口如何知道上一个窗口做了什么"的问题。Anthropic 警告说，过于激进的上下文压缩可能导致"微妙但关键的上下文丢失，而这些上下文的重要性只有在后来才会显现"。

值得注意的是，上下文重置（Context Reset）与压缩（Compaction）是两种本质不同的策略。压缩是在原地对早期对话进行摘要，让同一个 Agent 在缩短的历史上继续工作——它保留了连续性，但无法给 Agent 一个干净的起点，因此"上下文焦虑"（Context Anxiety，即模型感知到上下文接近上限时提前草草收尾的行为）依然可能持续。重置则是完全清空上下文窗口并启动新 Agent，通过结构化交接文件携带前一个 Agent 的状态——它提供了干净的起点，代价是交接产物必须携带足够的状态。Anthropic 的实验表明，Claude Sonnet 4.5 的上下文焦虑严重到仅靠压缩无法支撑长任务的高质量表现，因此上下文重置成为 Harness 设计的关键突破。这正是 CE 无法独立解决、必须上升到 HE 层面处理的典型问题。

局限二：长任务的持久化。 数小时甚至数天的任务需要跨多个上下文窗口的状态管理。CE 提供了记忆工具和结构化笔记，但这些仍然是"窗口内"的解决方案——它们帮助智能体在当前窗口内记住更多信息，但不解决"窗口切换时如何恢复完整状态"的问题。

局限三：验证闭环的缺失。 CE 关注"给模型正确的信息"，但不关注"验证模型的输出是否正确"。在长任务中，智能体可能在某个步骤犯了错误，而这个错误在后续步骤中被放大。CE 没有内建的验证机制来检测和纠正这种偏差。

局限四：多智能体协调的复杂性。 CE 的"隔离上下文"策略引入了多智能体架构，但多智能体系统的成本-价值权衡远比想象中复杂。Anthropic 在其多智能体研究系统的实验中给出了精确的量化数据：

Agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats. For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance.

但这个成本换来了显著的收益：在 BrowseComp 基准测试上，多智能体系统比单智能体高出 90.2%。Anthropic 的归因分析揭示了一个关键洞察：

In our analysis, three factors explained 95% of the performance variance in the BrowseComp evaluation. We found that token usage by itself explains 80% of the variance, with the number of tool calls and the model choice as the two other explanatory factors.

他们的结论一针见血：

Multi-agent systems work mainly because they help spend enough tokens to solve the problem.

换句话说，多智能体的收益本质上来自于用更多 token 做更充分的探索——但如何在多个智能体之间高效地共享和同步状态，使这些 token 不被浪费在重复探索上，超出了 CE 的范畴。

用 Anthropic 自己的话说：

长时程任务要求智能体在一系列动作序列中保持连贯性、上下文和目标导向行为，而这些动作的 token 总量超过了 LLM 的上下文窗口。

当我们意识到"管理一个上下文窗口内的信息"已经不够，还需要"管理跨越多个上下文窗口的整个任务生命周期"时，Harness Engineering 应运而生。

回到厨师的类比：你已经学会了备料（CE），厨师在单次工作中表现出色。但满汉全席要做三天，厨师每隔四小时就会彻底失忆。他醒来后不知道哪些菜已经做了、哪些还没做、上一轮做到哪一步了。光会备料不够，还得学会管厨房。

第三阶：Harness Engineering——给模型搭操作系统

一个重要的前提：Simplicity First

在进入 Harness Engineering 的具体架构之前，有一个来自 Anthropic 的重要告诫值得铭记：从最简单的方案开始，只在确实需要时才增加复杂度。

Anthropic 在 Building Effective Agents 中明确指出：

We suggest starting with direct LLM API usage, augmenting with retrieval and in-context examples where needed. There is no need to use a framework if you find it easier to use the API directly.

他们将智能体系统分为两类：Workflows（预定义的代码路径编排 LLM 调用）和 Agents（LLM 自主决定流程）。关键洞察是：大多数任务用 Workflow 就够了，只有当任务需要灵活性和模型驱动的决策时，才应该引入 Agent。 他们甚至列出了六种具体的 Workflow 模式——Prompt Chaining、Routing、Parallelization、Orchestrator-Workers、Evaluator-Optimizer——每一种都比完整的 Agent 架构更简单、更可控。

这个原则对理解 HE 至关重要：Harness 不是越复杂越好。 一个好的 Harness 工程师，首先要判断"这个任务真的需要 Agent 吗？"——如果一个简单的 Prompt Chain 就能解决问题，那就不要搭建复杂的多智能体系统。HE 的价值不在于引入复杂度，而在于在复杂度不可避免时，提供管理复杂度的系统化方法。

起源：从 Anthropic 的实验到 Hashimoto 的命名

Harness Engineering 的起源可以追溯到一个具体的工程实验。

2026 年 2 月，Anthropic 发布了工程博客 Effective harnesses for long-running agents。他们让 Claude 在没有 harness 的情况下，仅凭一个高层提示（“构建一个 claude.ai 的克隆”）跨多个上下文窗口工作。结果出现了两种典型失败模式：

失败模式一：一次性尝试（One-shotting）。原文描述了这个问题的严重性：

The agent tended to try to do too much at once—essentially to attempt to one-shot the app. Often, this led to the model running out of context in the middle of its implementation, leaving the next session to start with a feature half-implemented and undocumented.

失败模式二：过早宣告完成。

A second failure mode would often occur later in a project. After some features had already been built, a later agent instance would look around, see that progress had been made, and declare the job done.

失败模式三：未经测试就标记完成。Anthropic 还发现了第三种失败模式——智能体会修改代码甚至编写单元测试，但不会验证功能是否端到端地工作：

One final major failure mode that we observed was Claude’s tendency to mark a feature as complete without proper testing.

Anthropic 用一个形象的比喻描述了这个困境：

想象一个软件项目由轮班工程师负责，每个新工程师到来时对上一班发生的事情毫无记忆。

这两种失败模式都不是模型能力的问题，而是架构问题：没有任何机制告诉智能体"还有什么没做"和"已经做到哪一步了"。

2026 年 1 月 5 日，Philipp Schmid 发表了一个被广泛引用的判断：

如果 2025 年是智能体的开端，2026 年将围绕 Agent Harness 展开。

2026 年 2 月 5 日，Mitchell Hashimoto（HashiCorp 创始人）在他的博客中首次明确提出了 “Harness Engineering” 这个术语：

I don’t know if there is a broad industry-accepted term for this yet, but I’ve grown to calling this “harness engineering.” It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent cannot make that mistake again.

同月，OpenAI 的 Codex 团队发表了 Harness engineering: leveraging Codex in an agent-first world，展示了他们如何在五个月内用三名工程师、零人工编码的方式构建了一个百万行代码的产品。

2026 年 3 月 7 日，Harrison Chase 在 VentureBeat 的采访中明确将 Harness Engineering 定位为 Context Engineering 的延伸：

This “harness engineering” is an extension of context engineering… The trend in harnesses is to actually give the large language model (LLM) itself more control over context engineering, letting it decide what it sees and what it doesn’t see.

起源的另一面：人的注意力成为瓶颈，放权是导火索

Hashimoto 的起源叙事是自下而上的——在个人工作流里遇到一次次错误，每次都工程化一个解决方案，最终沉淀出"harness"这个词。这个版本像极了传统软件工程的演进逻辑：bug driven。

但还有另一个自上而下的起源叙事，和 Hashimoto 的版本互补——甚至更能解释为什么 2026 年初 Harness Engineering 会突然成为行业显学。这个叙事来自 OpenAI Frontier 团队的 Ryan Lopopolo，主角不是 bug，而是人的注意力。

Ryan 在 OpenAI 官方博客《Harness engineering: leveraging Codex in an agent-first world》中记录了他们的实验：三个工程师、五个月、1500+ PR、百万行代码、零人工编写代码、零代码合并前人工 review。这个实验的核心约束不是技术上的，而是人为施加的：

As code throughput increased, our bottleneck became human QA capacity. Because the fixed constraint has been human time and attention, we’ve had to continually invest in systems that let agents review, fix, and merge work autonomously.

在 Latent Space 的访谈中，Ryan 把这个逻辑讲得更直白：

The only fundamentally scarce thing is the synchronous human attention of my team. There’s only so many hours in the day, we have to eat lunch, I would like to sleep… You have to step back, right? Like you need to take a systems thinking mindset to things.

换句话说：Token 不稀缺（并行、可并发、便宜）、Agent 不稀缺（可以同时跑 N 个）、代码不稀缺（一天 1500 个 PR），真正稀缺的只剩下一样东西——一个人坐下来盯着看的时间。 而一旦把"人必须审查每个 PR"作为硬约束，整个系统的吞吐量就卡死在人的注意力上，无论底层模型多强都没有意义。

这个观察导出了一个无法回避的结论：要让 Agent 真正创造价值，就必须放权——放掉"每行代码都要人看"、放掉"每个决策都要人拍板"、甚至放掉"合并前要人 review"。而一旦放权，Agent 的活动范围就会急剧膨胀：从一次写几行代码，到同时开几十个 worktree；从一个会话一个任务，到 24 小时不停地跑。活动范围膨胀的直接后果是错误面也随之膨胀——没被监督的 Agent 会做奇怪的事，会走偏，会把 P0 问题说成"不大要紧"然后合进主干。

这时候，循环和约束不是可选项，而是放权的必然代价：

  • 放权要求验证能自动化——所以需要 evaluator、code review agent、自动测试、Hard Gate
  • 放权要求偏差能自纠正——所以需要 sensor、feedback loop、quality score、tech tracker
  • 放权要求边界能被强制——所以需要 Guides、architectural constraints、沙箱环境、工具白名单
  • 放权要求状态能跨会话持久化——所以需要 feature_list、progress log、skills、AGENTS.md

Ryan 描述 OpenAI Frontier 团队的日常工作，已经完全不是"写代码"了：

Our most difficult challenges now center on designing environments, feedback loops, and control systems.

这就是 Harness Engineering 在自上而下视角下的真正起源：不是因为 Agent 会犯错所以要修，而是因为人决定不再做 Agent 的监工，Agent 的活动范围因此暴涨，暴涨的活动范围必须用系统化的循环和约束来驯服，否则就是灾难。

Hashimoto 的故事和 Ryan 的故事拼在一起，才是完整的起源图谱：

视角 起源 驱动力 代表人物
自下而上 修复具体错误 Agent 犯了错 → 工程化防止再犯 Mitchell Hashimoto
自上而下 放权后失控 人的注意力成为瓶颈 → 必须让 Agent 自主 → 必须约束 Ryan Lopopolo / OpenAI Frontier

两个视角都指向同一个结论：Harness 是"人退后一步"与"Agent 活动范围扩大"两者相撞后的必然产物。在 PE/CE 时代人还是中心，每个关键节点都亲自决策；到 HE 时代人退到外围，变成系统设计者而非执行监工——这正是 Hashimoto 口中"发现错误就工程化"和 Ryan 口中"systems thinking mindset"的同一件事从两端会合。

这个视角也解释了一个反直觉的现象：模型越强，Harness 的重要性不降反升。因为模型越强，人越敢放权；人越放权，Agent 活动范围越大；活动范围越大，越需要系统化的循环和约束来兜底。所以 Harness Engineering 不是模型不够好的补丁，而是模型够好之后放大的必然产物。

核心定义：从"信息环境"到"操作系统"

LangChain 提出了一个简洁的公式：

Agent = Model + Harness

Harness 是模型之外的一切——代码、配置和执行逻辑。模型提供智能，Harness 让智能变得有用。

Philipp Schmid 给出了一个更精确的定义和类比：

An Agent Harness is the infrastructure that wraps around an AI model to manage long-running tasks. It is not the agent itself. It is the software system that governs how the agent operates, ensuring it remains reliable, efficient, and steerable.

他的类比尤其精妙：

计算机概念 智能体对应
CPU Model（模型）
RAM Context Window（上下文窗口）
Operating System Agent Harness（驾驭框架）
Application Agent（智能体）

上下文窗口是 RAM——易失性的，断电就没了。Agent Harness 是操作系统——它负责在进程切换时保存和恢复状态，管理资源分配，提供系统调用接口。

HE 与 CE 的本质区别

Context Engineering 专注于优化 LLM 在推理时看到的信息——系统提示词、对话历史、检索文档、工具输出。它的作用域是单个上下文窗口内。

Harness Engineering 包含整个系统——行为约束、反馈循环、质量门控、持久化状态、验证机制、环境管理、多智能体编排。它的作用域是智能体的整个生命周期。

LangChain 在其架构文章中明确指出了这个包含关系：

The Agent harness implements “Context Engineering” strategies like reducing context via compaction, offloading state to storage, or isolating tasks into sub-agents.

换句话说：CE 是 HE 的一个子系统。HE 实现了 CE 的策略，但还包含了 CE 不涉及的持久化、验证、约束和编排能力。

HE 的六层架构

综合 Anthropic、OpenAI、LangChain 和社区的实践，一个成熟的 Agent Harness 可以分解为六个层次：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌─────────────────────────────────────────────────────┐
│  第六层：约束层（Constraints）                        │
│  安全边界、权限控制、成本限制、架构约束                 │
├─────────────────────────────────────────────────────┤
│  第五层：验证层（Verification）                       │
│  测试执行、Fitness Function、Hard Gate、偏差检测       │
│  生成器-评估器分离（GAN 启发）、评分标准校准            │
├─────────────────────────────────────────────────────┤
│  第四层：持久化层（Persistence）                      │
│  进度日志、功能清单、Git 历史、外部记忆、状态快照       │
├─────────────────────────────────────────────────────┤
│  第三层：上下文管理层（Context Management）            │
│  上下文压缩、选择性注入、知识库索引 ← CE 的核心        │
├─────────────────────────────────────────────────────┤
│  第二层：工具层（Tools）                              │
│  Shell、文件系统、浏览器、API 调用、MCP               │
├─────────────────────────────────────────────────────┤
│  第一层：循环层（Loop）                               │
│  Agent Loop、消息处理、工具调用编排、子智能体派发       │
└─────────────────────────────────────────────────────┘

注意第三层——上下文管理层——正是 Context Engineering 的核心。而 PE 的技术（CoT、Few-shot 等）则体现在系统提示词的设计中，贯穿于各层。这就是超集关系的架构体现。

业界分歧：Harness 到底包含什么？

上面的六层架构是本文综合多方实践后的归纳。但如果你去读不同来源的文章，会发现一个有趣的现象：业界对"Harness Engineering 到底包含哪些组成要件"并没有达成共识。 不同的团队基于各自的实践经验，给出了相当不同的分解方式。

Thoughtworks（Martin Fowler 站点）的三分法。 Birgitta Böckeler 在 Martin Fowler 的网站上发表的 Harness Engineering 一文，将 Harness 的组成要件分为三大类：

  • Context Engineering：系统提示词、上下文管理、信息注入——这与本文的第三层对应
  • Architectural Constraints（架构约束）：通过工具选择、文件系统权限、沙箱环境等手段，限制智能体的行为边界——对应本文的第六层和第二层
  • "Garbage Collection"（垃圾回收）：清理智能体产生的无用产物，如多余的日志文件、临时代码、冗余注释——这是一个其他来源很少单独强调的维度

值得注意的是，Böckeler 在文中明确批评了 OpenAI Codex 团队的 Harness 实践缺少功能验证环节。她指出，OpenAI 的三分法（Context Engineering + Architectural Constraints + Garbage Collection）虽然覆盖了约束和清理，但没有将测试和验证作为 Harness 的核心组件——而在 Thoughtworks 的实践中，验证闭环是不可或缺的。

Anthropic 的实践驱动定义。 与 Thoughtworks 的理论分类不同，Anthropic 的定义完全从工程实践中生长出来。他们不做抽象分类，而是直接描述一个有效 Harness 需要哪些具体产物：功能清单（feature_list.json）、进度日志（claude-progress.txt）、Git 仓库（版本控制）、环境初始化脚本（init.sh）、以及自验证机制（智能体运行测试来检查自己的工作）。Anthropic 的重心放在跨上下文窗口的状态持久化和自验证上，这恰恰是 Thoughtworks 批评 OpenAI 缺失的部分。

LangChain 的功能分层。 LangChain 在 The Anatomy of an Agent Harness 中提出了另一种分解方式，按功能层次将 Harness 解剖为六个组件：系统提示词（System Prompts）、工具与技能（Tools/Skills/MCPs）、捆绑基础设施（Bundled Infrastructure）、编排逻辑（Orchestration Logic）、钩子与中间件（Hooks/Middleware）、以及上下文管理策略。这种分解更接近软件架构的思维方式——每一层都是一个可独立配置的"旋钮"。

Mitchell Hashimoto 的极简定义。 HashiCorp 创始人给出了最简洁的定义：每当智能体犯了一个错误，你就花时间工程化一个解决方案，使得智能体不可能再犯同样的错误。这个定义的核心是错误驱动的迭代改进，不预设任何固定的组件清单——Harness 的内容完全由实践中遇到的问题决定。

HumanLayer 的反向定义。 最有趣的分歧来自 HumanLayer。他们在 Skill Issue: Harness Engineering for Coding Agents 中，将 Harness Engineering 定义为 Context Engineering 的子集——与本文的超集关系（PE ⊂ CE ⊂ HE）恰好相反。在他们看来，Harness Engineering 专注于"配置编码智能体的各个调节点以提升输出质量和可靠性"，是 Context Engineering 这个更大框架下的一个具体实践领域。

这些分歧可以归纳为三个维度：

分歧维度 立场 A 立场 B
定义范围 完整的系统架构（Anthropic、LangChain） 错误驱动的迭代改进（Hashimoto）
组件优先级 验证闭环是核心（Anthropic、Thoughtworks） 约束和清理是核心（OpenAI）
与 CE 的关系 HE 是 CE 的超集（本文、LangChain） HE 是 CE 的子集（HumanLayer）

为什么会有这些分歧？根本原因在于 Harness Engineering 仍然是一个正在形成中的学科。不同团队面对的任务类型不同（编码 vs. 研究 vs. 通用对话）、使用的模型不同（Claude vs. GPT vs. 开源模型）、积累的经验不同，自然会形成不同的认知框架。正如 Hashimoto 自己所说：“我不知道业界是否已经有一个广泛接受的术语来描述这件事。”

本文采用的六层架构是一个综合性框架，试图兼容上述各方的核心洞察：Thoughtworks 强调的架构约束和垃圾回收体现在约束层，Anthropic 强调的状态持久化和自验证体现在持久化层和验证层，LangChain 的功能分层思想贯穿整个架构，而 Hashimoto 的错误驱动理念则是整个 Harness 迭代演进的方法论。

定义的收敛：Harness 是循环还是约束？

业界的分歧暴露了一个真问题：Harness 到底是"循环"还是"约束"？是"环境设计"还是"错误迭代"？

如果你看 Hashimoto，会觉得 Harness 是约束（每次发现错误就加一条新规则）。如果你看 OpenAI Codex，会觉得 Harness 是循环（build → review → merge 的自动化流水线）。如果你看 LangChain，又会觉得 Harness 是环境（系统提示词、工具集、编排逻辑的集合）。这些说法听起来各说各话，但它们其实指向同一个东西——只是从不同侧面看。

Birgitta Böckeler（Thoughtworks）在 2026 年 4 月发布的更新版长文 提供了目前最清晰的收敛框架，把这几种说法整合成了一个控制论（cybernetics）视角下的统一定义：

The agent harness acts like a cybernetic governor, combining feed-forward and feedback to regulate the codebase towards its desired state.

在这个视角下，Harness 的组成要件就两类——Guides 和 Sensors：

  • Guides（前馈控制，Feedforward）：在 Agent 行动之前约束它。预判它会犯什么错，提前把护栏架好。系统提示词、AGENTS.md、工具描述、架构规则、skills 都是 Guides。它们的作用是让 Agent 第一次就做对的概率变高。
  • Sensors（反馈控制，Feedback）：在 Agent 行动之后观察它。捕捉它实际做了什么，让它能自纠正。Lint、测试、mutation testing、LLM as judge、code review agent 都是 Sensors。它们的作用是让错误在进入人眼之前被捕获。

Böckeler 说得很直白：没有这两者的配合，你会得到一个两极失败的系统：

Separately, you get either an agent that keeps repeating the same mistakes (feedback-only) or an agent that encodes rules but never finds out whether they worked (feed-forward-only).

这就直接回答了用户的问题——Harness 不等于循环，也不等于约束，而是"约束 + 循环"的闭环控制系统。用工程语言说：Harness 是一个控制器（governor），它用 Guides 做前馈，用 Sensors 做反馈，把代码库/Agent 输出持续拉回到期望状态。环境设计是这个控制系统的物理载体，循环是它的时间维度，约束是它的空间边界——三个词不矛盾，是同一个东西从三个角度看。

Böckeler 进一步给出了两个执行维度的正交分类，这是这次定义收敛里最有实操价值的部分：

维度 计算型（Computational） 推理型（Inferential）
实现 确定性、CPU 运行 非确定性、GPU/NPU 运行
速度 毫秒到秒 秒到分钟
成本 几乎免费 贵
Guides 示例 Code mods、OpenRewrite、类型系统、LSP AGENTS.md、Skills、系统提示词
Sensors 示例 Lint、测试、ArchUnit、mutation testing LLM as judge、AI code review、语义重复检测

这个表格之所以重要，是因为它解释了 Harness 设计里一个反复出现的权衡：什么时候用确定性工具，什么时候用 LLM 当裁判。确定性工具便宜、可靠但只能覆盖语法层面；LLM 裁判能做语义判断但贵且不稳定。一个好的 Harness 会把 Computational 的东西放在 Agent 工作的内循环（每次 commit 都跑）、把 Inferential 的东西放在外循环（每天或每个 PR 跑一次），按"shift quality left"的原则把检查尽可能前置。

Böckeler 还按被约束的对象，把 Harness 进一步分成三类——这个分类解释了为什么"Harness = 环境设计"在不同场景下落地方式完全不同：

  • Maintainability Harness（可维护性约束）：规范内部代码质量。最成熟的一类——重复代码、圈复杂度、测试覆盖率、架构漂移、风格违规都有现成工具。Computational sensors 在这里最好用。
  • Architecture Fitness Harness（架构适应度约束）：检查架构特征是否持续满足。典型落地是 Fitness Function——性能、可观测性、日志质量、API 契约、模块边界。这是 Phodal 谈 Fitness Function 时指的那一层。
  • Behaviour Harness（行为约束）：验证应用在功能上是否真的对。这是目前最难的一类——靠 AI 生成的测试套件质量参差不齐，mutation testing 能补一部分，但到头来还是要靠人工测试兜底。Anthropic 的三 Agent 架构里 evaluator 的真正难点就在这一层。

这三层不是互斥的而是叠加的：一个成熟的 Harness 会三种约束并存——底下是可维护性（保证代码本身不烂）、中间是架构适应度（保证代码符合系统性要求）、上面是行为约束（保证代码真的完成了任务）。

和这个框架形成互补的是 HumanLayer 提出的两个被低估的配置点——hooks 和 skills。hooks 提供确定性控制流（比如 git pre-commit 钩子强制跑测试、PR 同步时自动触发 review agent），本质是把 Sensors 机械化；skills 提供渐进式披露（progressive disclosure），Agent 只在需要时加载对应技能文件，本质是让 Guides 按需生效而不是把整张提示词一次性灌进上下文。这两者的引入让"约束 + 循环"这个框架有了更精细的时间粒度：不是"永远生效"而是"在对的时刻生效"。

现在回头看三级跃迁，Harness = Guides + Sensors 这个定义就把 PE/CE/HE 的关系讲透了：

  • PE 的技术（CoT、Few-shot）是最简单的 Guide——它只前馈、无反馈
  • CE 的策略（RAG、压缩、隔离）是更丰富的 Guide——它动态决定喂什么，但仍然缺反馈闭环
  • HE 在 PE/CE 的 Guide 之上加了 Sensor——加了一套自动化的反馈控制系统，才让"放权"成为可能

所以"Harness 是环境设计"和"Harness 是循环和约束"不是两种定义，而是同一个定义的前端和后端：环境设计是静态描述（架构图），循环和约束是动态行为（运行时），控制论统一了两者。

Anthropic 的两阶段设计

Anthropic 提出了一个优雅的两阶段 harness 架构来解决跨上下文窗口的状态传递问题：

阶段一：初始化智能体（Initializer Agent）。第一次运行时，使用专门的提示词，让智能体生成 init.sh（环境启动脚本）、feature_list.json（功能清单，所有功能初始标记为 failing）、初始 Git 提交（基线）和 claude-progress.txt（进度日志）。

阶段二：编码智能体（Coding Agent）。每次后续运行时，智能体执行固定的"上下文恢复"序列：读取进度日志和 Git 日志 → 读取功能清单 → 选择优先级最高的未完成功能 → 实现并测试 → 更新状态 → 提交代码。

这个设计的精妙之处在于：每次会话的开始都有明确的"上下文恢复"步骤，每次会话的结束都有明确的"状态保存"步骤。 智能体不需要猜测，只需要按照协议执行。Anthropic 在原文中总结了这个设计的核心洞察：

The key insight here was finding a way for agents to quickly understand the state of work when starting with a fresh context window, which is accomplished with the claude-progress.txt file alongside the git history.

一个值得注意的设计细节是：功能清单使用 JSON 而非 Markdown 格式。Anthropic 发现模型对 JSON 文件的"尊重度"更高：

The model is less likely to inappropriately change or overwrite JSON files compared to Markdown files.

编码智能体只能修改 passes 字段，不能删除或编辑测试用例——Anthropic 用了强烈措辞的指令来约束这一点：“It is unacceptable to remove or edit tests because this could lead to missing or buggy functionality.” 这种通过格式选择来约束模型行为的策略，是 Harness Engineering 中一个精妙但容易被忽视的技巧。

用厨师类比来理解：初始化智能体就是第一天开工前的"厨房总管"，他列出所有菜品清单、准备好基础食材、写好第一份交接班记录。之后每个班次的厨师（编码智能体）醒来后，第一件事不是拿起锅铲，而是先读交接班记录——上一班做了什么、哪些菜还没做、优先做哪道——然后才开始工作。下班前，他必须更新记录并提交成果。这就是 Harness 的核心：把"交接班协议"编码成系统规则，而不是依赖厨师的自觉。

Anthropic 在第四篇工程博客中提供了令人信服的量化成本数据。他们用同一个项目（Retro Video Game Maker）对比了有无 harness 的差异：

方案 耗时 成本
无 harness（Solo） 20 分钟 $9
完整 harness（V1） 6 小时 $200

原文坦率地承认了成本差异：

The harness was over 20x more expensive, but the difference in output quality was immediately apparent.

但当 harness 架构迭代到 V2（三 Agent 架构 + 冲刺契约）后，成本结构发生了显著变化：

Agent 与阶段 耗时 成本
Planner 4.7 分钟 $0.46
Build（第 1 轮） 2 小时 7 分钟 $71.08
QA（第 1 轮） 8.8 分钟 $3.24
Build（第 2 轮） 1 小时 2 分钟 $36.89
QA（第 2 轮） 6.8 分钟 $3.09
Build（第 3 轮） 10.9 分钟 $5.88
QA（第 3 轮） 9.6 分钟 $4.06
V2 Harness 总计 3 小时 50 分钟 $124.70

从 $200 降到 $124.70，不仅质量显著提升，成本反而降低了近 40%。这个数据打破了一个常见的直觉：“加更多结构 = 花更多钱”。事实恰恰相反：结构化的 harness 通过减少无效探索和重复工作，同时降低了成本和提升了质量。

三 Agent 架构与冲刺契约：两阶段设计的进化

Anthropic 的两阶段设计解决了"如何跨会话传递状态"的问题，但随着任务复杂度进一步提升，一个新的挑战浮现：如何让智能体在构建过程中保持对"完成"的一致理解？

Anthropic 工程师 Prithvi Rajasekaran 在实践中将两阶段设计进化为三 Agent 架构：

  • 规划器（Planner）：接受 1-4 句话的简单提示，将其扩展为完整的产品需求说明。规划器刻意保持高层次——只描述要交付的成果，不预先指定细粒度的技术实现。这个设计选择背后有深刻的工程考量：Anthropic 发现，当规划器试图预先指定具体的技术栈、API 设计或数据库 schema 时，这些早期的技术假设往往是错误的，而且会级联到下游所有步骤——生成器会忠实地按照错误的技术方案去实现，评估器也会按照错误的标准去评判。让规划器只描述"用户应该能看到什么、做什么"，而把"怎么实现"的决策留给生成器在实际编码时做出，反而产生了更好的结果。这本质上是软件工程中"推迟决策到最后责任时刻"原则在 Agent 架构中的体现。
  • 生成器（Generator）：以"冲刺"（Sprint）方式工作，每次从需求说明中选取一个功能实现，配备 git 进行版本控制。
  • 评估器（Evaluator）：使用 Playwright MCP 像真实用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态，而非仅对静态截图打分。

这个架构的核心创新是**冲刺契约（Sprint Contract）**机制。Anthropic 在第四篇工程博客中描述了这个机制：

Before each sprint, the generator and evaluator negotiated a sprint contract: agreeing on what “done” looked like for that chunk of work before any code was written.

生成器提出它将构建什么以及如何验证成功，评估器审查提案，两者通过文件通信迭代直到达成一致。这样做的意义在于：把隐性的工程判断显式化为可执行的契约，从根本上解决了智能体把"看起来差不多了"误解为"可以结束了"的问题。

评估器的价值在实践中得到了量化验证。在一次游戏制作工具的构建中，评估器识别出了生成器自我评估时完全忽略的问题，例如：

fillRectangle 函数存在但在 mouseUp 时未被正确触发；FastAPI 将路由中的 reorder 字符串匹配为整数 frame_id 并返回 422 错误。

这些问题在没有外部评估器的情况下，生成器会自信地宣告"任务完成"。将做事的 Agent 与评判的 Agent 分离，是解决自我评估偏差的强力杠杆。

LangChain 的实证：Harness 调优的威力

LangChain 团队提供了目前最具说服力的量化证据。他们的编码智能体在 Terminal Bench 2.0 基准测试上，使用同一个模型（GPT-5.2-Codex），仅通过调优 Harness，得分就从 52.8% 提升到 66.5%，排名从 Top 30 跃升到 Top 5。

这个数据的震撼之处在于：模型没换，数据没变，唯一的变量就是 Harness。正如 LangChain 博客所指出的，同一个 Opus 4.6 模型在 Claude Code 的 harness 中和在其他 harness 中的表现天差地别。

关键的"调优旋钮"包括：

  • 系统提示词的结构化：精确规定在什么条件下读取文件、运行测试、处理失败、提交代码
  • 工具选择与配置：限制工具集反而比提供更多工具效果更好——过多的选择导致智能体在工具选择上浪费 token
  • 上下文压缩策略：保留最近的工具调用结果和错误信息，比保留完整对话历史更有效
  • 重试与恢复机制：不同类型的错误需要不同的恢复策略

Harrison Chase 总结道：

Harness Engineering 是关于系统的。你在围绕模型构建工具，以优化任务性能、token 效率和安全性等目标。更好的模型本身不会让你的智能体达到顶级水平——你需要更好的 Harness。

值得注意的是，评估器本身也需要大量调优才能真正发挥价值。Anthropic 工程师在原文中坦率地承认：

Out of the box, Claude is a poor QA agent. In early runs, I watched it identify legitimate issues, then talk itself into deciding they weren’t a big deal and approve the work anyway.

这个问题的根源在于模型的自我评估偏差。Anthropic 用一句话精准概括了这个现象：

When asked to evaluate work they’ve produced, agents tend to respond by confidently praising the work—even when, to a human observer, the quality is obviously mediocre.

解决方案是将做事的 Agent 与评判的 Agent 分离：

Separating the agent doing the work from the agent judging it proves to be a strong lever to address this issue. But tuning a standalone evaluator to be skeptical turns out to be far more tractable than making a generator critical of its own work.

调优的循环是：阅读评估器的日志，找到其判断与工程师判断出现分歧的例子，然后更新 QA 的提示词来解决这些问题。这个过程需要多轮迭代，才能让评估器的评分方式达到合理的程度。

这揭示了 Harness Engineering 的一个深层规律：Harness 中的每个组件都编码了一个关于模型自身无法做到什么的假设，这些假设值得持续压力测试——既因为它们可能是错误的，也因为随着模型改进，它们可能很快过时。

三级跃迁的内在逻辑

现在让我们回到开头的问题：为什么这三个 Engineering 会依次出现？它们之间的演进逻辑是什么？

驱动力：任务复杂度的阶梯

每一次跃迁都是因为任务复杂度突破了当前范式的承载能力：

任务复杂度 典型场景 需要的能力 对应范式
单次问答 “翻译这段话” 理解指令、生成回答 Prompt Engineering
多步骤工作流 “帮我分析这个代码库的架构” 工具调用、信息检索、上下文管理 Context Engineering
跨会话长任务 “帮我构建一个完整的 Web 应用” 状态持久化、验证闭环、环境管理 Harness Engineering

每一步的"不够"

PE 不够的根本原因：PE 优化的是"模型看到的那一条 prompt"，但在 Agent 场景中，模型看到的远不止 prompt——还有工具定义、检索结果、对话历史、状态信息。这些信息的动态管理超出了 PE 的范畴。

CE 不够的根本原因：CE 优化的是"单个上下文窗口内的信息"，但复杂任务必然跨越多个上下文窗口。当上下文窗口切换时，CE 精心构造的信息环境就消失了——就像 RAM 断电一样。

HE 解决了什么：HE 在 CE 的基础上，增加了"操作系统"级别的能力——状态持久化（磁盘）、进程管理（任务编排）、系统调用（验证闭环）、多进程协调（多智能体）。

超集关系的精确表述

基于以上分析，三者的超集关系可以精确表述为：

Prompt Engineering = 优化单次 LLM 调用的输入措辞

  • 核心问题："如何说"
  • 作用域：单条 prompt
  • 关键技术：CoT、Few-shot、ToT、指令格式化

Context Engineering = PE + 动态管理 LLM 推理时的整个信息环境

  • 核心问题："模型知道什么"
  • 作用域：单个上下文窗口
  • 关键技术：RAG、工具调用、上下文压缩、记忆管理、上下文隔离

Harness Engineering = CE + 管理智能体跨越多个上下文窗口的整个生命周期

  • 核心问题："系统如何运转"
  • 作用域：智能体的完整生命周期
  • 关键技术：状态持久化、验证闭环、环境初始化、多智能体编排、约束管理

Fitness Function：重新定义"完成"

Harness Engineering 解决了"如何让智能体持续工作"的问题，但还有一个更深层的问题：系统如何判断智能体已经完成了任务？

Phodal（黄峰达）提出了一个深刻的洞察：

真正困难的问题不是"Agent 能不能写出代码"，而是：系统究竟如何判断，这个 Agent 已经完成了任务。

在传统软件工程中，“完成"是一种被团队经验默契支撑的判断。但在 Agent Loop 中，这个默认前提不再成立。Agent 很容易把"看起来差不多了"误解为"可以结束了”。

Fitness Function 最早来自演进式架构，用于持续验证系统是否满足某些架构特征。在 AI Agent 场景中，它的角色变成了完成条件机制——把隐性的工程条件编码成系统可执行的规则。

其中最关键的机制是 Hard Gate：

Gate 命令 阈值
测试通过 npm run test:run 100%
API 契约一致 npm run api:check pass
代码规范 npm run lint 0 errors

Hard Gate 失败会直接阻断流程，而不是进入评分体系。Hard Gate 就是 Agent 时代的 Definition of Done：它明确规定，在什么条件下，这个自动化参与者才被允许退出循环。

工程师角色的根本转变

这三级跃迁带来的最深远影响，不是技术架构的变化，而是工程师角色的根本转变。

OpenAI 的 Codex 团队明确指出：

工程师的角色从"写代码的人"变成了"设计环境的人"。

在 PE 时代，工程师学习如何写好 prompt。在 CE 时代，工程师学习如何设计信息供给系统。在 HE 时代，工程师学习如何设计让智能体高效工作的整个运行时环境——包括工具、约束、反馈循环和验证机制。

HumanLayer 在其博客 Skill Issue: Harness Engineering for Coding Agents 中提出了一个尖锐的观点：

Harness engineering is the art and science of leveraging your coding agent’s configuration points to improve output quality and increase reliability. It’s not a model problem. It’s a configuration problem.

翻译过来就是：当你的智能体表现不佳时，这不是模型的问题，而是你的配置问题——这是一个"技能问题"（Skill Issue）。

这个观点的潜台词是：在 HE 范式下，工程师的能力不再体现在写出多优雅的代码，而是体现在能否设计出让智能体持续产出高质量代码的系统。

最后的 Harness：把品味编码进系统

前面两节回答了 Harness 的起源（放权）和定义（Guides + Sensors）。还有一个看似老生常谈、但实际上是最硬核的问题：不管模型怎么变，决定最终产出质量的那个关键 Harness，是人的品味——这句话听起来像废话，但在当代 Harness 里究竟怎样落地？

先把"废话"说清楚：为什么品味必然是最后的瓶颈。这个判断不是价值判断，是工程判断。

Designative 在 2026 年 2 月的文章 Taste Is the New Bottleneck 里给出了这个判断的基础：

When execution is no longer scarce, judgment is. What differentiates good work is no longer the ability to generate ideas, but the ability to discriminate between them.

这句话和前文 OpenAI Ryan 说的"the only fundamentally scarce thing is the synchronous human attention"其实是同一件事的两面。人的注意力之所以成为瓶颈，是因为"有品味的判断"成为了瓶颈——Agent 可以并行、可以 24 小时跑、可以消费几十亿 token，但"这个方案是不是对"、“这个抽象是不是合理”、“这个选择是不是值得”——这类判断目前只有人能给。模型可以生成一百个技术正确的方案，但决定"哪一个值得存在"的那个筛子，是人的品味。

Böckeler 用一句话精准定位了人在 Harness 里的角色：

Harnesses are an attempt to externalise and make explicit what human developer experience brings to the table, but it can only go so far.

翻译过来：人本身就是一个隐性的 Harness。 一个资深工程师走进代码库，他的经验、审美、对系统的直觉，就是一套自带的 Guides 和 Sensors——他会下意识拒绝 300 行的函数，会在代码闻起来不对时停下来，会知道哪些约定是承重的、哪些只是习惯。当代 Harness Engineering 的全部工作，本质上就是把这套隐性的人类品味外化成可被机器执行的系统。

这个视角下，"品味怎么落地"这个问题就清晰了——它不是一个玄学问题，而是一个编码问题：把"一个有品味的工程师会怎么想、会怎么做"翻译成 Agent 可以消费的文本、规则、测试、评分标准。落地路径有三层，恰好对应 Designative 给出的品味三层模型：

第一层：问题框架层（What’s worth solving）—— 把"值得做什么"的品味编码进 Spec 和 PRD

这是最容易被忽略的一层。Ryan Lopopolo 在 OpenAI 博客里反复强调 SPEC.md 和各级短小 AGENTS.md 的作用——因为在 Agent 动手之前，让它知道"要做成什么样"本身就是注入品味的最佳时机。Anthropic 三 Agent 架构里 Planner 刻意保持高层次、不预先指定技术方案，正是为了把品味保留在"要交付什么用户体验"这一层，而不是过早地固化在"用哪个技术栈"上。

具体落地物：SPEC.md、AGENTS.md、CLAUDE.md、产品愿景文档、用户旅程描述、冲刺契约（Sprint Contract）。这些文件的每一行都是一条品味——品味不是写在文档里的形容词（“优雅”、“好用”），而是写在里面的具体约束（“任何 API 调用必须有超时”、“任何错误必须可诊断”、“任何新功能必须能被观测”）。

第二层：方案评估层（What’s “good enough” here）—— 把"什么叫做得对"的品味编码进 Evaluator 和 Quality Score

这是当代 Harness 里品味落地最密集的一层。Ryan 给出了目前最具体的一张清单：

Skills, docs, tests, markdown trackers, and quality scores as ways of encoding engineering taste and non-functional requirements directly into context the agent can use.

把这句话拆开看，每一个具体产物都是品味的编码器：

  • Quality Score（质量分）：一个 markdown 表格，列出所有业务逻辑的"质量维度"，让 Codex 自己对照、打分、提出修复。品味被编码成一张评分表。
  • Tech Tracker（技术债追踪器）：业务逻辑 → 品味要求 → 差距 → 跟进工作。品味被编码成一张差距表。
  • Evaluator Prompt：Anthropic 在三 Agent 架构里不断调优 QA 的提示词，每一轮调优都是"阅读评估器日志，找到它与工程师判断出现分歧的例子，然后更新提示词"——这个循环本质上就是在把工程师的品味注入评估器。
  • Rubric（评分标准）：把"P0/P1/P2"这样的严重性分级显式化，Codex 的 review agent 才知道什么问题要阻断、什么问题可以忽略。

Ryan 对这个机制的描述尤其精妙——他们甚至给 review agent 配了"push back"的权限（允许它反驳主 Agent 的意见），也给主 Agent 配了"defer"的权限（允许它把不紧急的建议挪到 backlog）。**这本身就是品味：知道什么时候坚持、什么时候妥协。**而品味落地的方式就是把"何时坚持、何时妥协"写进两个 Agent 各自的提示词。

第三层：系统治理层（What our tools learn to prefer）—— 把"什么不能做"的品味编码进 Constraint 和 Fitness Function

这一层处理的是最硬的品味：系统底线。Hashimoto 说的"anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent cannot make that mistake again"——每一条这样的工程化规则，都是一次品味的沉淀。Ghostty 的 AGENTS.md 每一行都来自 Hashimoto 亲眼看着 Agent 做错一次的经验，这就是品味从"人脑里的直觉"变成"机器可执行的边界" 的过程。

具体落地物：

  • Hard Gate：npm run lint 0 errors、npm run test:run 100%、npm run api:check pass——不过就不能合并。
  • Fitness Function：性能阈值、日志覆盖率、可观测性基线——持续监测，漂移就告警。
  • Architectural Constraint：工具白名单、文件系统权限、沙箱边界——从物理上让 Agent 做不了坏事。
  • Hook：git pre-commit、PR 同步触发器——把"应该做但容易忘"的事情机械化。

值得特别点出的是：这一层落地的品味，尤其会跨越单个项目沉淀成团队的共同财产。Böckeler 提出的"Harness Template（Harness 模板）“正是这个方向——企业的主要服务类型（业务 API、事件处理、数据看板）各自对应一套预制的 Guides + Sensors，团队选技术栈时不仅看语言和框架，还看"这套技术栈有没有配套的 Harness”。当品味被模板化，它就从少数资深工程师的脑袋里，变成了整个组织的资产。

三层组合起来，就是当代 Harness 里"品味落地"的完整路径：

品味所处层 编码形式 典型产物
What’s worth solving 高层次意图 SPEC.md、AGENTS.md、Sprint Contract
What’s good enough 可运行的评估器 Quality Score、Evaluator Prompt、Rubric、Tech Tracker
What must not happen 强制约束 Hard Gate、Fitness Function、Architectural Constraint、Hooks

最后还有一个关于品味的反常识观察，来自 Böckeler，值得单独强调：

A good harness should not necessarily aim to fully eliminate human input, but to direct it to where our input is most important.

好的 Harness 不是要消除人的参与，而是要把人的注意力引导到最值得他介入的地方。 这句话回到了前面"放权"那一节的逻辑闭环：我们不是因为人没用了所以搭 Harness，恰恰相反，我们是因为人的品味太宝贵、太不可复制，所以要用 Harness 把人从重复劳动里解放出来，专注在只有人能做的判断上——也就是品味本身。

一个成熟的 Harness 工程师最终会意识到：他搭的不是脚手架，而是自己品味的镜像。Harness 里的每一条规则、每一个评分标准、每一个 Hard Gate，都是他在"我会怎么做"这个问题上的一次显式回答。模型会迭代、工具会更新、架构会演进，但什么叫做得好这个问题的答案，必须由人亲自给。Harness 的价值，就是把这个答案编码到足够细的粒度，让 Agent 哪怕在凌晨三点、在工程师睡着的时候，也能继续按照这个答案去工作。

这也是 Harness Engineering 时代最根本的一条职业洞察：当执行不再稀缺，你的品味就是你的护城河。而把品味编码进系统，就是这条护城河在 AI 时代的施工方式。

未来方向

Harness 随模型演进

Anthropic 的工程实践揭示了一个重要规律：Harness 不是一次性设计，而是随模型能力演进而持续迭代的。当 Claude Sonnet 4.5 存在严重的"上下文焦虑"时，Harness 需要引入冲刺分解和上下文重置机制；而当 Opus 4.6 发布后，其改进的长上下文处理能力使得冲刺结构变得不再必要——同一个 Harness 中的评估器，从"每个冲刺都必须介入"演变为"只在任务超出模型能力边界时才值得付出成本"。

Anthropic 在原文中用精确的语言描述了这个边界的移动：

On 4.5, that boundary was close: our builds were at the edge of what the generator could do well solo, and the evaluator caught meaningful issues across the build. On 4.6, the model’s raw capability increased, so the boundary moved outward. Tasks that used to need the evaluator’s check to be implemented coherently were now often within what the generator handled well on its own.

这揭示了一个反直觉的洞察。Anthropic 原文的总结堪称经典：

The space of interesting harness combinations doesn’t shrink as models improve. Instead, it moves, and the interesting work for AI engineers is to keep finding the next novel combination.

更好的模型意味着可以用同样的 Harness 预算去挑战更复杂的任务，而不是让 Harness 变得多余。当新模型发布时，通常应该重新审视 Harness，剥离不再对性能有承重作用的部分，并添加新的部分以实现之前可能无法实现的更大能力。

自适应 Harness

当前的 Harness 大多是静态配置的。未来的方向是自适应 Harness：系统根据智能体的历史表现，动态调整约束的松紧度、工具的可用性、上下文的注入策略。Harrison Chase 已经指出了这个趋势：

The trend in harnesses is to actually give the LLM itself more control over context engineering, letting it decide what it sees and what it doesn’t see.

多智能体编排

当多个专业化智能体需要协同工作时，Harness 需要从"管理一个智能体"升级为"编排一个智能体团队"。MCP（Model Context Protocol）、A2A（Agent-to-Agent）等协议的出现，已经在为这个方向铺路。

但多智能体编排中有一个被严重低估的设计要素：硬终止条件。没有显式终止条件的多智能体系统，最终一定会死于无限循环——两个 Agent 互相回复、互相触发，永远停不下来。Anthropic 的多智能体研究系统靠 token budget 和 tool call 上限来收敛；社区中的 Hermes supervisor 方案则靠 ACK 终止信号和 3 轮上限来确保对话必然结束。很多人设计多智能体系统时，把精力花在怎么让 Agent 们更智能地协作上，但实践反复证明：协作不需要多智能，需要的是边界清晰——每条消息都有明确的类型，每种类型都有明确的处理方式，对话有明确的结束条件。这种刚性反而比弹性更可靠。

从 Reviewer 到 SRE：Harness 的下一个边界

当前 Harness Engineering 的所有实践——Anthropic 的 evaluator、冲刺契约、LangChain 的调优旋钮——本质上都在解决同一个阶段的问题：开发阶段的质量控制。Evaluator 像代码 Reviewer：代码提上来，审查，有问题就退回修改，循环直到 LGTM。这是一个内循环——生成、审查、反馈、修改、再审查——质量问题在"合并"前解决。

但如果 Agent 已经部署到生产环境、每天自动运行，谁来持续监控？这个问题，当前的 Harness 没有回答。

社区中已经出现了探索这个方向的实践。NousResearch 的 Hermes supervisor 方案展示了一种截然不同的模式：它不是 Reviewer，而是 SRE。Reviewer 的判断回流给代码作者，驱动新一轮迭代；SRE 的判断不回流给系统——要么自己处理掉（ACK 关闭），要么带着诊断升级给更高级的人（Escalation）。Reviewer 解决的是"怎么把代码写好"，SRE 解决的是"出了问题该怎么办"。前者是优化问题，后者是决策问题。

这个区分揭示了 Harness Engineering 的下一个演进方向：从纵向的开发质量控制（在开发流程的某一步反复打磨）扩展到横向的运行时健康监控（覆盖系统运行的整个生命周期）。Reviewer 的终点是代码合并，SRE 没有终点——只要系统在跑就要一直盯着。未来的 Agent Harness 可能需要同时包含这两层：内循环的 Reviewer 确保产出质量，外循环的 SRE 确保运行稳定。

Harness 即平台

随着 HE 的成熟，它可能会从"每个团队自建"演进为"平台化服务"。就像 CI/CD 从自建脚本演进为 GitHub Actions 一样，Agent Harness 也可能会出现标准化的平台和协议。

跨领域扩展

Anthropic 在其 Harness 工程博客中提到，这些经验"可以应用到科学研究或金融建模等领域所需的长期智能体任务类型"。HE 的核心原则——状态持久化、验证闭环、约束编码——并不局限于编码场景。

小结

问题 答案
三者是什么关系？ 严格的超集关系：PE ⊂ CE ⊂ HE
PE 解决了什么？ 教模型说人话：通过措辞优化提升单次调用质量
PE 为什么不够？ 只管"说什么"，不管"知道什么"；无法处理工具调用、动态信息、上下文衰减
CE 解决了什么？ 给模型喂正确的信息：动态管理上下文窗口内的信息环境
CE 为什么不够？ 只管一个上下文窗口内的事；无法跨会话持久化、无验证闭环
HE 解决了什么？ 给模型搭操作系统：管理智能体跨越多个上下文窗口的整个生命周期
核心类比是什么？ Model=CPU, Context Window=RAM, Agent Harness=OS
HE 为什么会出现？ 人的注意力成为瓶颈 → 必须放权 → Agent 活动范围暴涨 → 必须用循环和约束驯服
Harness = 循环还是约束？ 都是：Harness 是 Guides（前馈约束）+ Sensors（反馈循环）的控制论系统
HE 当前解决了什么阶段？ 开发阶段的质量控制（Reviewer 内循环），运维阶段的持续监控（SRE 外循环）是下一个边界
工程师角色如何变化？ 从"写代码的人"到"设计环境的人"、再到"把品味编码进系统的人"
最终的护城河是什么？ 人的品味：分三层落地到 Spec/Evaluator/Constraint，把隐性判断变成可执行规则

这三级跃迁的本质，是 AI 工程从"调参数"走向"搭系统"的过程。当我们不再问"AI 能不能写代码"，而是问"如何让 AI 持续、可靠、可验证地完成复杂任务"时，答案就是这条演进路径：先学会说话，再学会喂信息，最后学会搭脚手架。

参考资料