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

一个类比秒懂三级跃迁

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

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

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

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

如果把它投射到工程现场，你可能已经见过这样的场景：让 AI Agent 实现一个功能，它思考了一下，开始写代码。200 行写完，运行 lint 直接失败——类型定义文件 import 了配置包，违反了架构分层约束。Agent 不知道这个规则，我们也没告诉它。于是它开始修复：移动代码、调整依赖、重新组织。再跑 lint——又一个新问题。循环三次后，上下文窗口被错误日志和 diff 塞满，Agent 开始"忘记"最初的任务目标。

这不是 Agent 不够聪明。这是 Agent 看不见。Prompt 写得再好，也没法穷尽代码库的所有隐式规则。上下文窗口再大，也装不下整个仓库的架构决策。Harness 工程的思路不一样：与其教 Agent 怎么做，不如让它自己验证做得对不对。靠代码、linter、测试来保证正确性，而不是靠 LLM 的"直觉"。

一张图看懂三级跃迁

在深入每个阶段之前，先建立一个全局视角。这三个 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 的实证：从评估器模式到三 Agent 架构

本章部分内容编译自 Anthropic 工程博客 Harness design for long-running application development，作者 Prithvi Rajasekaran，发布于 2026 年 3 月 24 日。

两阶段设计：初始化智能体与编码智能体

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 的核心：把"交接班协议"编码成系统规则，而不是依赖厨师的自觉。

前端设计：让主观质量变得可评分

两阶段设计解决了"如何跨会话传递状态"的问题，但还有两个更深层的挑战：自我评估偏差和主观质量度量。

当被要求评估自己产出的工作时，Agent 往往会自信地大加赞扬——即便在人类观察者看来，质量明显平庸。将做事的 Agent 与评判的 Agent 分离，被证明是解决这一问题的强力杠杆。

Anthropic 工程师 Prithvi Rajasekaran 从前端设计开始实验，因为自我评估问题在这里最为明显。受**生成对抗网络（GAN）**的启发，他设计了一种包含生成器和评估器 Agent 的多智能体结构。

两个洞察塑造了这个 Harness：第一，虽然审美无法完全化约为一个分数，但可以通过编码设计原则和偏好的评分标准来提升——"这个设计美吗？"很难一致地回答，但"这是否遵循了我们的优秀设计原则？"给了 Claude 具体可评分的依据。第二，通过将前端生成与前端评分分离，可以创建一个驱动生成器走向更强输出的反馈循环。

基于此，他写了四个评分标准，同时提供给生成器和评估器 Agent：

  • 设计质量：设计是否感觉是一个连贯的整体，而非零件的堆砌？
  • 原创性：是否有自定义决策的痕迹，还是模板布局、库默认值和 AI 生成模式？
  • 工艺：技术执行层面——字体层级、间距一致性、色彩和谐、对比度。
  • 功能性：独立于美学的可用性。用户能否理解界面的用途？

设计质量和原创性的权重被置于工艺和功能性之上——Claude 在后两者上本就表现不错，但在设计和原创性上经常产出平淡的结果。评分标准明确惩罚高度通用的"AI 糊弄"模式。

评估器配备了 Playwright MCP，让它能在评分前直接与实时页面交互。每次生成运行 5 到 15 次迭代，随着生成器响应评估器的批评，每次迭代通常会推动其走向更具特色的方向。

在一个值得关注的例子中，提示模型为一家荷兰艺术博物馆创建网站。到第九次迭代，它已经为一家虚构博物馆制作了一个简洁的深色主题落地页。然后，在第十个周期，它彻底推翻了这个方案，将网站重新构想为一种空间体验：一个用 CSS 透视渲染的棋盘格地板 3D 房间，艺术品以自由形式悬挂在墙上，画廊房间之间通过门道导航而非滚动或点击。这是单次生成中从未见过的那种创意飞跃。

三 Agent 架构与冲刺契约

将 GAN 启发的评估器模式应用到全栈开发后，Anthropic 构建了一个三 Agent 系统：

规划器（Planner）：接受 1-4 句话的简单提示，将其扩展为完整的产品需求说明。规划器刻意保持高层次——只描述要交付的成果，不预先指定细粒度的技术实现。这个设计选择背后有深刻的工程考量：Anthropic 发现，当规划器试图预先指定具体的技术栈、API 设计或数据库 schema 时，这些早期的技术假设往往是错误的，而且会级联到下游所有步骤。让规划器只描述"用户应该能看到什么、做什么"，而把"怎么实现"的决策留给生成器在实际编码时做出，反而产生了更好的结果。这本质上是软件工程中"推迟决策到最后责任时刻"原则在 Agent 架构中的体现。

生成器（Generator）：以"冲刺"（Sprint）方式工作，每次从需求说明中选取一个功能实现，配备 git 进行版本控制。

评估器（Evaluator）：使用 Playwright MCP 像真实用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态，而非仅对静态截图打分。

这个架构的核心创新是**冲刺契约（Sprint Contract）**机制。在每个冲刺之前，生成器和评估器协商一份冲刺契约：在任何代码编写之前，就该块工作的"完成"标准达成一致。生成器提出它将构建什么以及如何验证成功，评估器审查提案，两者通过文件通信迭代直到达成一致。这样做的意义在于：把隐性的工程判断显式化为可执行的契约，从根本上解决了智能体把"看起来差不多了"误解为"可以结束了"的问题。

运行 Harness：单 Agent vs 完整 Harness

Anthropic 用同一个项目（复古视频游戏制作工具）对比了有无 harness 的差异。提示只有一句话：

创建一个 2D 复古游戏制作工具，功能包括关卡编辑器、精灵编辑器、实体行为和可玩的测试模式。

Harness 时长 成本
单 Agent 20 分钟 $9
完整 Harness 6 小时 $200

Harness 的成本超过 20 倍，但输出质量的差异立竿见影。

单 Agent 运行的输出初看符合预期，但随着点击深入，问题开始浮现。布局浪费空间，固定高度的面板让大部分视口空空如也。更关键的是，游戏本身是坏的——实体出现在屏幕上，但没有任何响应输入。深入代码后发现，实体定义与游戏运行时之间的连接是断的。

完整 Harness 运行则不同。规划器将单句提示扩展为分布在十个冲刺中的 16 个功能需求说明，远超单 Agent 运行的尝试范围。应用立即展现出更多的精致感和流畅度，精灵编辑器更丰富、功能更完整，最大的差异在于游玩模式——用户实际上能够移动实体并游玩游戏了。

评估器在实践中的价值得到了量化验证。契约非常细粒度——仅冲刺 3 就有 27 个涵盖关卡编辑器的标准。下表展示了评估器识别出的几个问题示例：

契约标准 评估器发现
矩形填充工具允许点击拖动以用选定瓦片填充矩形区域 失败 — fillRectangle 函数存在但在 mouseUp 时未被正确触发。
用户可以选择并删除已放置的实体生成点 失败 — LevelEditor.tsx:892 的删除键处理程序要求同时设置 selection 和 selectedEntityId，但点击实体只设置 selectedEntityId。
用户可以通过 API 重新排序动画帧 失败 — PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 reorder 匹配为整数 frame_id 并返回 422。

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

迭代优化 Harness

第一批 Harness 结果令人鼓舞，但也臃肿、缓慢且昂贵。合乎逻辑的下一步是在不降低性能的情况下简化 Harness。这部分是常识，部分是一个更普遍原则的体现：Harness 中的每个组件都编码了一个关于模型自身无法做到什么的假设，这些假设值得持续压力测试——既因为它们可能是错误的，也因为随着模型改进，它们可能很快过时。

在 Opus 4.6 发布后，Anthropic 首先完全移除了冲刺结构。冲刺结构帮助将工作分解为模型可以连贯处理的块，但 Opus 4.6 改进的长上下文处理能力使得这种分解不再必要——Agent 在整个构建过程中作为一个连续会话运行。移除冲刺结构后，评估器改为在运行结束时进行单次评估，而非每个冲刺评分一次。

为了测试更新后的 Harness，Anthropic 使用以下提示生成了一个数字音频工作站（DAW）：

使用 Web Audio API 在浏览器中构建一个功能完整的 DAW。

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

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

QA Agent 在简化后的 Harness 中仍然捕获了真实的缺口。在第一轮反馈中，它指出几个核心 DAW 功能只是展示性的，缺乏交互深度：片段无法在时间轴上拖动/移动，没有乐器 UI 面板，也没有可视化效果编辑器。

实际含义是：评估器不是一个固定的是/否决策。当任务超出当前模型单独可靠完成的范围时，它才值得付出成本。

评估器调优的教训

让评估器达到可用的水平需要大量工作。开箱即用的 Claude 是一个糟糕的 QA Agent：

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.

这个问题的根源在于模型的自我评估偏差：

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 分离。分离本身并不能立即消除宽松倾向，但将独立的评估器调教得更加挑剔，远比让生成器批判自己的作品更容易实现。调优的循环是：阅读评估器的日志，找到其判断与工程师判断出现分歧的例子，然后更新 QA 的提示词来解决这些问题。这个过程需要多轮迭代，才能让评估器的评分方式达到合理的程度。

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

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。

三级跃迁的内在逻辑

现在让我们回到开头的问题：为什么这三个 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 + 管理智能体跨越多个上下文窗口的整个生命周期

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

落地实践：从仓库到验证管道

理论和实证都讲完了。接下来是最实操的部分：怎么在你的项目里搭建 Harness。

仓库是 Agent 的操作系统

CPU 很强大，但没有操作系统它就是一块高速却无方向的芯片——不知道硬盘在哪、网络协议是什么、哪些内存地址可以写。LLM 也一样。它推理能力很强，但它不知道你的 internal/types/ 不能 import internal/config/，不知道新文件该放哪个目录。Harness 就是给它装的"操作系统"。

这个类比背后有几条关键原则。

原则一：仓库是唯一的事实来源。 某内部 CI/CD 平台里的讨论、即时通讯工具会议上的口头约定、架构师脑子里的蓝图，这些对 Agent 来说都不存在。不在仓库里，Agent 就看不见；看不见就会违反。所以第一步是把一切编码到仓库中：架构决策、层级约束、命名规范。不是写在 Wiki 里，不是发在群里，而是作为版本化的文件提交到 Git。

原则二：AGENTS.md 是地图，不是手册。 编码到仓库不意味着把所有东西塞进一个文件。很多团队的第一反应是写一份巨大的 AGENTS.md，500 行，什么都有。问题是：当一切都重要时，什么都不重要。AGENTS.md 应该是地图，不是手册——控制在 ~100 行，只做索引和指路，详细内容放在 docs/ 目录里按需加载。

AGENTS.md 已经成为业界标准。它由 Linux Foundation 旗下的 Agentic AI Foundation 托管，已被超过 60,000 个开源项目采用，20+ 主流 coding agent 工具支持自动发现和读取。

原则三：约束粒度只管边界。 Harness 不规定"你必须用这个设计模式"或"函数必须这样写"，它只管架构边界。把自然的依赖方向编码为层级编号——Layer 0 是类型定义，Layer 1-2 是工具函数和配置，Layer 3 是业务逻辑，Layer 4+ 是 HTTP handler 和 CLI 命令。规则就一条：高层可以 import 低层，反过来不行。中心化约束，本地自治。

原则四：人的角色转变。 以前是人写代码、AI 辅助补全；现在反过来了——人设计系统（架构、约束、验证规则），Agent 在系统内执行。你不再需要自己拧每一颗螺丝，但你得确保流水线是对的。

落地：从搭建到执行

Harness 靠两个引擎协作：harness-creator 负责分析代码库、生成基础设施（文档、lint 脚本、目录结构）；harness-executor 在这套基础设施中执行开发任务。executor 的工作流是：检测环境 → 加载上下文 → 制定计划 → 人类批准 → 执行 → 验证 → 完成。

一个装备了 Harness 的项目，大致长这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
my-project/
├── AGENTS.md                    ← 导航地图（~100行）
├── docs/
│   ├── ARCHITECTURE.md          ← 架构、层级、依赖规则
│   ├── DEVELOPMENT.md           ← 构建/测试/lint 命令
│   ├── PRODUCT_SENSE.md         ← 业务上下文
│   ├── design-docs/             ← 组件设计文档
│   └── exec-plans/              ← 执行计划（active / completed）
├── scripts/
│   ├── lint-deps.*              ← 层级依赖检查
│   ├── lint-quality.*           ← 代码质量规则
│   ├── verify/                  ← 端到端功能验证
│   └── validate.py              ← 统一验证管道
├── harness/
│   ├── tasks/                   ← 任务状态和检查点
│   ├── trace/                   ← 执行轨迹和失败记录
│   └── memory/                  ← 经验教训存储
└── [业务代码...]

在动手之前先问"能不能做"

Harness 里的验证分几类。最核心的是依赖方向检查（lint-deps）——core/ 不能 import ui/，api/ 和 cli/ 不能互相引用。其次是质量规则检查（lint-quality），强制一些编码规范：单文件不超过 500 行，禁止 console.log / print()，禁止硬编码品牌字符串。

但重点不是事后检查，而是事前预防。Agent 通常的工作流是写代码、跑测试、发现错误、修复、再跑测试。当一个层级违反在 50 行代码写完后才被 linter 抓到，修复代价很大——撤销改动、重新设计，差不多要消耗 10 次 tool call。而如果在写代码前先问一句"这样做合法吗"，两次交互就够了：

1
2
3
4
5
6
python3 scripts/verify_action.py --action "create file internal/types/user.go"
# ✓ VALID: internal/types/ is Layer 0, user.go follows naming convention

python3 scripts/verify_action.py --action "import internal/core from internal/handler"
# ✗ INVALID: internal/handler (L4) cannot import internal/core (L3)
#   Fix: handler should depend on core through interfaces

不是每个操作都需要预验证。改个函数体不需要，加个测试文件不需要。但只要涉及"在新位置创建文件"或"添加跨包 import"，就该先验证。层级违反是 Agent 翻车的头号原因。

Linter 错误信息的质量决定 Agent 自愈能力

这里有一个容易被忽视但影响很大的细节：linter 的错误信息质量直接决定了 Agent 能不能自愈。一条 Forbidden import in core/types/user.go 看完不知道怎么办；但如果改成：

1
2
3
core/types/user.go imports core/config (Layer 0 → Layer 2).
Layer 0 packages must have NO internal dependencies.
Fix: Move config-dependent logic to a higher layer, or pass the config value as a parameter.

什么规则违反了、为什么是问题、怎么修，全在里面。一条好的报错本身就是一次教学。

四层验证管道

Harness 不鼓励 Agent 直接跑 go build 或 go test，而是提供统一验证入口 validate.py，因为"验证通过"在每个项目里含义不同。验证顺序有讲究：

1
2
3
4
5
6
build → lint-arch → test → verify
│        │         │       │
│        │         │       └─ 端到端功能验证
│        │         └─ 单元/集成测试
│        └─ 架构和质量合规
└─ 代码能否编译

先 build（编译都不过就别往下了），再 lint-arch（架构约束），然后 test（功能正确性），最后还有一步容易被漏掉——verify。

build + lint + test 能覆盖大部分问题，但有一类问题它们抓不到：功能层面的正确性。测试通过了不代表功能是对的——测试本身可能覆盖不全，或者 Agent 写的测试恰好绕过了关键路径。verify 步骤是项目级别的端到端功能验证——不是"函数返回值对不对"，而是"用户执行这个操作，最终结果对不对"。

验证挂了怎么办？executor 会自动进入修复循环——分析错误、改代码、重新跑验证，一般 1-3 轮就收敛。如果同一个错误转了 3 圈还没过，就别让 Agent 继续挣扎了，停下来交给人。

几条踩过坑之后的经验：

  • 故意引入违规来测试 lint，加一个跨层 import 确认能被检测到，如果 lint 没报错说明护栏是纸糊的
  • 永远不要禁用 lint 规则来"解决"问题，Agent 有时候会想绕过规则（比如注释掉 lint 配置），应该改代码而不是改规则
  • 测试不需要每次跑全量，executor 支持只跑受影响的包，速度快很多

上下文管理与多 Agent 协作

上下文是最贵的资源

如果这篇文章你只记住一件事，记这个：中等复杂度以上的任务，协调者绝不写代码。

为什么？因为 LLM 的上下文窗口是有限的。Agent 执行长任务时，窗口里慢慢堆起来的是代码 diff、编译错误、测试输出、lint 报告、重试记录……到第 40 次 tool call，早期的关键信息已经被压缩或丢弃了。Agent 开始"忘记"最初的架构决策，做出跟前面矛盾的改动。

任务越复杂，消耗的上下文越多，关键信息被压缩，决策质量下降，又产生更多错误，需要更多修复，又消耗更多上下文……一旦进去就很难出来。

协调者-执行者分层

解法是把 Agent 拆成两层。**协调者（Coordinator）**只管规划、委派、汇总，一行代码都不碰；**执行者（子代理）**每次从干净的上下文开始，拿到精确的 prompt，干完就释放。子代理不知道之前发生了什么，但它拿到的 prompt 里包含了它需要知道的一切。任务完成后，详细上下文被丢掉，协调者只保留一段摘要。

破坏这个原则最常见的方式是"只是快速改一下"。协调者发现一个小问题，心想"这么简单的东西不用启子代理，我直接改了"。一次编辑变成了五次，五次变成二十次，上下文就被消耗殆尽了。如果你发现协调者正在用 Edit 或 Write 工具修改源代码，立刻停下来，启动子代理。没有例外。

复杂度不同，执行方式也不同。改个 typo、加行日志这种小事可以直接做；多文件一致性修改就该委派给子代理；到了重构、新模块这种结构性变更，子代理还得在 Git Worktree 里隔离执行。快速判断方法：能用一句话描述且不包含"和"字的，直接做；需要清单来跟踪改了哪些地方的，委派；需要做设计决策和权衡的，委派加隔离。

多模型路由：按任务性质选择模型

委派子代理时还有一个容易被忽略的杠杆：不是所有任务都需要用最强的模型。一个"重命名变量"的任务和一个"重构认证模块"的任务，对模型能力的要求完全不同。前者要的是快和便宜，后者要的是深度推理。

协调者在委派时可以根据任务性质指定模型：

  • 快速执行类（改 typo、简单重命名）用轻量模型如 Claude Haiku，响应快、成本低
  • 深度推理类（复杂重构、架构级变更）用 GPT-5.3 Codex 或 Claude Opus，质量远比速度重要
  • 代码检索类（在大型代码库中定位相关文件）用 Gemini 3 Flash，速度第一
1
2
3
4
5
6
7
8
9
10
11
12
Agent(
    description="Execute: rename-user-field",
    model="haiku",         # 简单任务，轻量模型
    prompt="..."
)

Agent(
    description="Execute: refactor-auth-module",
    model="opus",          # 复杂任务，重量级模型
    isolation="worktree",
    prompt="..."
)

一个中等复杂度的功能开发，可能会同时调度三四个不同模型的子代理。协调者本身用中等模型就行——它不写代码，只做调度。总成本可以降低 60-70%，复杂任务的质量不打折扣。

交叉 Review：用不同模型做代码审查

机械化验证（lint、test、verify）能抓到规则层面的问题，但抓不到逻辑合理性——代码编译通过、测试全绿、架构合规，但实现思路可能有隐患：竞态条件、边界遗漏、不必要的复杂度、命名让人看不懂。这些东西只有"另一双眼睛"才能发现。

关键词是"不同模型"。如果用同一个模型既写代码又 review，它容易对自己的产出"视而不见"——类似于人写完文章自己检查总觉得没问题。换一个架构和训练数据都不同的模型来 review，思维盲区的重叠就小得多。

实际操作中，交叉 review 嵌入在子代理完成编码、机械验证通过之后，协调者接受结果之前。Review 子代理拿到变更的文件 diff、任务描述和架构文档，检查逻辑正确性、边界条件、命名清晰度、潜在性能问题，输出"通过"或"需修改"。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 编码完成后，用不同模型做交叉 review
review_result = Agent(
    description="Review: rate-limiter implementation",
    model="codex",           # 不同模型做 review
    prompt=f"""
Review the following changes for:
1. Logic correctness and edge cases
2. Consistency with architecture (see ARCHITECTURE.md)
3. Naming clarity and code readability
4. Performance implications

Changes: {coding_result.diff}
Task context: {task_description}
"""
)

不是所有任务都需要交叉 review。简单修改直接过机械验证就够了。但涉及核心业务逻辑、安全相关代码、或者影响面较广的重构，加一轮是值得的。成本上，review 子代理只需要读 diff 和文档，一次 review 的成本大约是编码成本的 10-20%。

这样做还有一个副作用：review 中发现的问题会被记录到 harness/trace/ 里。如果某类问题反复出现，说明应该把它编码成新的 lint 规则——把 review 中的"软知识"逐渐转化成验证管道中的"硬规则"。

检查点与架构决策保持

中等以上的任务还会设检查点。每完成一个阶段、跑过验证就存档，包括已有的架构决策。任务中断了，下一个 Agent 能从检查点恢复，不会做出跟前面矛盾的选择。检查点携带架构决策这一点很重要——没有它，新 Agent 可能走一条完全不同的路，引入微妙的不一致。

让 Harness 自己长大

前面讲的 Harness 还是静态的——人定规则，Agent 遵守。但真正有意思的地方在于，Harness 能从 Agent 的失败里学东西。

Critic-Refiner 反馈循环

每次 Agent 犯错都是一个信号。如果同一类错误反复出现，说明 Harness 本身有缺口——要么某个包没被 linter 覆盖，要么某条规则的错误信息写得不够清楚，要么某个场景缺少文档。与其靠人去发现这些缺口，不如让系统自己分析。

每次验证失败都被结构化地保存到 harness/trace/failures/。Critic 脚本定期分析这些记录，找出模式和根因——比如发现 internal/cache 被 7 次违规 import，根因是它没被加入层级映射表，建议修复是把它加入 Layer 1。然后 Refiner 根据建议去更新 Harness：把遗漏的包加入 linter 规则，改写含糊的错误信息，补上缺失的文档。

整个循环跑起来就是：Agent 执行 → 验证抓到问题 → Critic 分析模式 → Refiner 更新规则 → 下一个 Agent 受益。

Agent 的三种记忆

Harness 还维护着三种"记忆"：

  • 情景记忆：记录具体事件和教训，比如"macOS 下 /var 是 /private/var 的符号链接，会导致工作区路径比较失败"——这类教训可能只要 10 秒加载，却能省下一整个重试循环
  • 程序记忆：记录成功的操作步骤，比如"添加 API 端点的标准五步流程，成功率 90%"，新的子代理执行同类任务时会先查这里
  • 失败记忆：专门供 Critic 分析用

每次任务开始时，executor 会查询相关记忆，这些记忆的价值随着项目演进不断累积。

轨迹编译：从模式到脚本

这套闭环走到极致会出现一个很有意思的东西：轨迹编译。当同一类任务被成功执行了三次以上，而且步骤高度一致——比如"添加 API 端点"每次都是创建类型文件、写服务方法、加 handler、注册路由、写测试——这个模式就可以被"编译"成一个确定性脚本，像 make add-endpoint NAME=foo 这样。以后再做同类任务直接跑脚本，LLM 都省了。脚本失败了再回退到 Agent 模式就好。

这是个棘轮效应：每一个被编译的成功模式都变成了永久基础设施，Agent 被释放去处理真正需要创造力的新问题。整个系统的运行成本越来越低，能力越来越强。

Harness 随模型演进

Harness 不是一次性设计，而是随模型能力演进而持续迭代的。Anthropic 的工程实践清晰地展示了这个规律：当 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.

这揭示了一个反直觉的洞察：

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 变得多余。基于此，有几个值得铭记的经验：

  1. 始终针对你正在使用的模型进行实验，阅读其在真实问题上的追踪记录，并调优其性能以达到你期望的结果。
  2. 对于更复杂的任务，有时可以通过分解任务并将专门的 Agent 应用于问题的每个方面来获得提升空间。
  3. 当新模型发布时，通常应该重新审视 Harness，剥离不再对性能有承重作用的部分，并添加新的部分以实现之前可能无法实现的更大能力。

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.

人的注意力之所以成为瓶颈，是因为"有品味的判断"成为了瓶颈——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。当代 Harness Engineering 的全部工作，本质上就是把这套隐性的人类品味外化成可被机器执行的系统。

"品味怎么落地"这个问题就清晰了——它不是一个玄学问题，而是一个编码问题。落地路径有三层：

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

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

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

Ryan Lopopolo 给出了目前最具体的一张清单：

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（质量分）让 Agent 自己对照、打分、提出修复；Tech Tracker（技术债追踪器）编码品味要求与现实差距；Evaluator Prompt 通过"阅读日志-找分歧-更新提示词"的循环，把工程师的品味注入评估器。

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

第三层：系统治理层（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 做错一次的经验，这就是品味从"人脑里的直觉"变成"机器可执行的边界" 的过程。

Böckeler 提出的"Harness Template（Harness 模板）“正是这个方向——企业的主要服务类型各自对应一套预制的 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

最后还有一个关于品味的反常识观察：

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

未来方向

自适应 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 们更智能地协作上，但实践反复证明：协作不需要多智能，需要的是边界清晰——每条消息都有明确的类型，每种类型都有明确的处理方式，对话有明确的结束条件。这种刚性反而比弹性更可靠。

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

当前 Harness Engineering 的所有实践本质上都在解决同一个阶段的问题：开发阶段的质量控制。Evaluator 像代码 Reviewer：代码提上来，审查，有问题就退回修改，循环直到 LGTM。这是一个内循环。

但如果 Agent 已经部署到生产环境、每天自动运行，谁来持续监控？这个问题，当前的 Harness 没有回答。Reviewer 解决的是"怎么把代码写好"，SRE 解决的是"出了问题该怎么办"。前者是优化问题，后者是决策问题。

这个区分揭示了 Harness Engineering 的下一个演进方向：从纵向的开发质量控制扩展到横向的运行时健康监控。未来的 Agent Harness 可能需要同时包含这两层：内循环的 Reviewer 确保产出质量，外循环的 SRE 确保运行稳定。

Harness 即平台

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

跨领域扩展

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

从今天开始实践

好在 Harness 不是全有或全无的——哪怕不搭完整的基础设施，一个 AGENTS.md 就能让 AI 协作体验好一截。这套方法适用于任何能跑 shell 命令的 coding agent（Claude Code、Codex 等都行）。多人协作、有明确分层的中大型项目收益最明显；个人项目或原型阶段，一个 AGENTS.md 加个简单的 lint 脚本就够了。

不管哪种情况，最小起步都一样——在项目根目录创建 AGENTS.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# [项目名] Agent Guide

## 快速链接
- [架构总览](docs/ARCHITECTURE.md) — 分层规则、数据流
- [开发指南](docs/DEVELOPMENT.md) — 构建、测试、lint 命令

## 构建命令
make build      # 构建项目
make test       # 运行测试
make lint-arch  # 运行架构 lint

## 分层规则
Layer 0: types/         → 纯类型定义，无内部依赖
Layer 1: utils/         → 工具函数，仅依赖 Layer 0
Layer 2: config/        → 配置，依赖 Layer 0-1
Layer 3: core/services/ → 业务逻辑，依赖 Layer 0-2
Layer 4: api/ cli/ ui/  → 接口层，依赖 Layer 0-3，彼此不互相引用

## 质量标准
- 结构化日志，禁止 console.log / print()
- 单文件不超过 500 行
- PascalCase（类型）、camelCase（函数）、kebab-case（文件名）

建议的节奏：今天先把 AGENTS.md 建出来；这周加一个 lint-deps 脚本把层级规则定下来；这个月搭完整的验证管道；之后开启 Critic → Refiner 反馈循环，让 Harness 跟着代码一起长。

回到开头那个场景。装了 Harness 之后，同样的任务会变成这样：Agent 启动，读 AGENTS.md 找到相关文档；列出执行计划，你扫一眼批准；子代理开始写代码，每个结构性操作前先跑预验证；层级违反在写代码前就被拦住了；完成后另一个模型的子代理做交叉 review，抓出机械验证发现不了的逻辑问题；每个阶段存检查点、跑验证；任务做完，经验教训记下来，下一个 Agent 接着用。

Agent 不需要更聪明——它只是能看见更多了。

说到底，环境设计的投入回报远高于 prompt 调优。一套好的 Harness 能让普通模型产出可靠的代码，而没有 Harness 的顶级模型照样会在同样的坑里反复栽。搭建的前期成本不高——一个下午就能建好基本的 AGENTS.md 和 lint 脚本。但它的价值会随着时间复利式增长：记忆越来越丰富，lint 规则越来越完善，越来越多的操作模式被编译成确定性脚本。半年后回头看，你的仓库已经变成了一个高度适配你们团队工作方式的 Agent 运行环境，任何新加入的人（或新会话的 Agent）都能立刻进入状态。

竞争优势不再是 Prompt，而是 Trajectory。这些积累，换个模型复制不来。

小结

问题 答案
三者是什么关系？ 严格的超集关系：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 持续、可靠、可验证地完成复杂任务"时，答案就是这条演进路径：先学会说话，再学会喂信息，最后学会搭脚手架。

附录：规划器 Agent 生成的示例计划

以下示例来自 Anthropic 工程博客中的实验案例，展示了规划器 Agent 如何将一句话提示扩展为完整需求说明。

RetroForge - 2D 复古游戏制作工具

概述

RetroForge 是一个基于 Web 的创意工作室，用于设计和构建 2D 复古风格视频游戏。它将经典 8 位和 16 位游戏美学的怀旧魅力与现代直觉编辑工具相结合——让从业余创作者到独立开发者的任何人都能在不编写传统代码的情况下将游戏创意变为现实。

该平台提供四个集成创意模块：用于设计游戏世界的基于瓦片的关卡编辑器、用于制作视觉资产的像素艺术精灵编辑器、用于定义游戏逻辑的可视化实体行为系统，以及用于实时游戏测试的即时可玩测试模式。通过在整个过程中融入 AI 辅助（由 Claude 提供支持），RetroForge 加速了创作过程——帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。

功能概要

  1. 项目仪表板与管理：创建、查看、复制、删除游戏项目，带视觉卡片和缩略图预览
  2. 关卡编辑器：基于瓦片的编辑器，支持矩形填充、实体放置、多图层管理
  3. 精灵编辑器：像素艺术创作工具，支持动画帧和颜色管理
  4. 实体行为系统：可视化定义游戏逻辑——移动、碰撞、状态机
  5. 可玩测试模式：即时游玩并调试关卡
  6. AI 辅助功能：通过 Claude 集成，用自然语言生成精灵、设计关卡

参考资料