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 的范畴。

催生因素二：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）。就像厨师不需要把整个仓库的食材都搬到面前，只需要在做红烧肉时，有人把五花肉、酱油和冰糖递过来。

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 报告说，多智能体系统的 token 使用量会增加 15 倍。如何在多个智能体之间高效地共享和同步状态，超出了 CE 的范畴。

用 Anthropic 自己的话说：

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

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

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

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

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

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

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

失败模式一：一次性尝试（One-shotting）。智能体试图在一个会话内完成所有工作，导致上下文在实现到一半时耗尽。

失败模式二：过早宣告完成。后续的智能体实例环顾四周，看到"进展已经取得"，就宣布任务完成了。

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.

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

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 等）则体现在系统提示词的设计中，贯穿于各层。这就是超集关系的架构体现。

Anthropic 的两阶段设计

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

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

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

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

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

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

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

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

  • 规划器（Planner）：接受 1-4 句话的简单提示，将其扩展为完整的产品需求说明。规划器刻意保持高层次——只描述要交付的成果，不预先指定细粒度的技术实现，避免错误的技术假设级联到下游。
  • 生成器（Generator）：以"冲刺"（Sprint）方式工作，每次从需求说明中选取一个功能实现，配备 git 进行版本控制。
  • 评估器（Evaluator）：使用 Playwright MCP 像真实用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态，而非仅对静态截图打分。

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

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

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 工程师的实践表明，开箱即用的 Claude 是一个糟糕的 QA Agent——在早期运行中，评估器会识别出合理的问题，然后说服自己这些问题没什么大不了，并批准了工作；它也倾向于浅层测试，而非探测边缘情况。调优的循环是：阅读评估器的日志，找到其判断与工程师判断出现分歧的例子，然后更新 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 随模型演进

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

这揭示了一个反直觉的洞察：随着模型改进，有趣的 Harness 组合空间不会缩小，而是会移动。更好的模型意味着可以用同样的 Harness 预算去挑战更复杂的任务，而不是让 Harness 变得多余。对于 AI 工程师来说，有趣的工作在于不断找到下一个新颖的组合——当新模型发布时，通常应该重新审视 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）等协议的出现，已经在为这个方向铺路。

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
工程师角色如何变化？ 从"写代码的人"到"设计环境的人"

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

参考资料