Agent Harness：从提示工程到驾驭工程的范式跃迁

引言：一个令人困惑却至关重要的概念

"Agent Harness"（智能体驾驭）这个术语自被正式提出以来，围绕它的困惑至今仍未消散。很多人将其简单理解为"智能体的运行环境"，但这远不足以解释它的本质。从提示工程（Prompt Engineering）到上下文工程（Context Engineering），再到如今的驾驭工程（Harness Engineering），AI编程领域正在经历一次深刻的范式变革。

本文基于B站UP主Caleb Wright的深度解析，系统梳理这一演进脉络，帮助你真正理解Agent Harness为何被认为将"改变一切"。

从4000 Token到无限可能：三代工程范式的演进

第一代：提示工程的局限

2022年ChatGPT发布之初，我们面对的是仅有4000 Token的上下文窗口。这里需要理解一个基础概念：Token是大语言模型处理文本的基本单位，一个英文单词通常对应1-2个Token，而一个中文字符通常对应1-2个Token。上下文窗口（Context Window）则是模型在一次交互中能够"看到"和处理的Token总量上限。GPT-3.5发布时仅支持4096个Token（约3000个英文单词），这意味着模型的"工作记忆"极其有限——相当于一个只能看到两三页纸内容的工程师。到2024年，主流模型的上下文窗口已扩展到128K甚至200K Token，但即便如此，对于复杂的软件工程任务来说，上下文空间仍然是一种稀缺资源。

在这个极度有限的空间里，简单的提示工程只能完成非常基础的任务——比如让AI生成一个网页，结果往往是一个"粗糙得令人尴尬"的页面，因为模型只能进行一次性响应（one-shot），无法处理任何复杂逻辑。

这种局限催生了一个核心问题：如何更高效地利用和管理有限的上下文窗口？

第二代：上下文工程的崛起与瓶颈

为了突破提示工程的天花板，行业迅速发展出上下文工程（Context Engineering），核心技术包括三大支柱：

• Tool Calling（工具调用）：让模型能够探索代码仓库、只读取与当前任务相关的文件，并在外部执行操作
• MCP（模型上下文协议）：允许在模型之上叠加供应商特定的功能。MCP（Model Context Protocol）是Anthropic于2024年底推出的开放协议标准，旨在为AI模型与外部数据源、工具之间建立统一的通信接口。在MCP出现之前，每个AI应用都需要为不同的数据源和工具编写定制化的集成代码，导致大量重复劳动和兼容性问题。MCP采用客户端-服务器架构，通过标准化的JSON-RPC协议进行通信，使得任何兼容MCP的AI应用都能即插即用地连接各种外部服务，类似于USB协议统一了硬件设备的连接方式。
• RAG（检索增强生成）：连接自定义数据库，实现按需数据随时可用。RAG的核心思想是在模型生成回答之前，先从外部知识库中检索与用户问题最相关的文档片段，然后将这些片段作为上下文注入到模型的提示中。这一过程通常依赖向量数据库（如Pinecone、Weaviate）和嵌入模型（Embedding Model）来实现语义级别的相似度匹配。RAG的优势在于它让模型能够访问训练数据之外的最新信息，同时大幅降低了模型"幻觉"（生成虚假信息）的概率。

Cursor、Windsurf、Kline、Roo和Aider等早期编码智能体都采用了工具调用来实现上下文工程，它们确实是"能完成工作的好工具"。随着底层模型的进化和上下文窗口的增长，编码智能体开始能够处理更长时间的任务，人们也开始要求它们完成越来越大范围的功能开发和Bug修复。

但问题随之而来。当任务复杂度和持续时间超过一定阈值后，上下文工程暴露出一个致命缺陷：上下文摘要化导致的信息丢失。

具体来说，当一个任务需要12小时才能完成时，上下文窗口会不断填满。为了继续工作，智能体会对已有上下文进行摘要压缩。上下文摘要化（Context Summarization）本质上是一种有损压缩——模型必须判断哪些信息"重要"、哪些可以丢弃，而这种判断往往不够准确。特别是在软件开发场景中，一个看似不重要的变量命名约定或API调用细节，可能在后续步骤中至关重要，一旦被摘要丢弃就会导致连锁错误。这个过程中，智能体可能会：

1. 在任务进行到一半时进行摘要，然后错误地认为任务已经完成
2. 过度简化任务描述，假设某些功能已经完成并验证，而实际上并没有
3. 导致网站半成品——部分按钮不工作，功能没有被完整测试

这种"弹性自管理上下文窗口"的方式看似赋予了智能体处理长期任务的能力，但实际效果远不如预期。

Harness Engineering的诞生：循环的力量

从混沌到秩序的关键一步

面对上下文工程的瓶颈，行业已经在自发地探索解决方案：有人实现了子智能体的层级上下文管理，有人部署了多智能体集群（Swarm），每个智能体拥有独立的上下文窗口。多智能体集群的概念源自分布式系统和群体智能理论。OpenAI在2024年发布了名为Swarm的实验性框架，展示了多个AI智能体协同工作的可能性。在Swarm架构中，每个智能体拥有独立的上下文窗口、独立的系统提示和独立的工具集，它们通过"交接"（Handoff）机制将任务在智能体之间传递。这种设计的灵感来自微服务架构——与其构建一个无所不能的单体应用，不如让多个专注于特定职责的小型服务协同完成复杂任务。

这些尝试都在向同一个方向收敛——为底层智能体构建更好的编排层、执行环境和上下文管理机制。

"Agent Harness"这一术语的正式提出，标志着这一方向有了统一的名称。虽然有人认为这不过是又一个行业热词，但它确实捕捉到了AI行业正在发生的一种变革性本质。

核心机制：循环迭代 + 全新上下文

Harness Engineering最关键的创新在于**循环（Loop）**的引入。它的工作方式是：

1. 规划阶段：将一个大型需求拆解为结构化的任务文档（如产品需求文档PRD），并将其细化为JSON格式的任务列表。PRD（Product Requirements Document）是软件工程中用于描述产品功能、用户故事和验收标准的标准文档。在Harness Engineering的语境中，PRD被用作智能体的"北极星"——它为整个开发任务提供全局视图和明确的完成标准。将PRD进一步细化为JSON格式的任务列表，是为了让机器能够精确解析每个子任务的依赖关系、优先级和完成条件。这种做法借鉴了敏捷开发中"用户故事拆分"和"Sprint Backlog"的思想，但将人类项目经理的角色交给了AI规划器。
2. 循环执行：在每次迭代中，智能体只从文档中选取一个任务来完成
3. 全新上下文：每次迭代开始时，智能体都获得全新的提示和全新的上下文，而非在不断膨胀的旧上下文上继续工作
4. 测试与记录：每个步骤完成后进行测试和文档记录
5. 持续循环：直到所有任务全部完成

这种架构的精妙之处在于，它从根本上解决了上下文摘要化带来的信息丢失问题——因为每次迭代都是一个干净的起点，智能体不再需要"记住"之前所有的工作细节，只需要知道当前要完成哪个具体任务。这与计算机科学中"无状态服务"（Stateless Service）的设计哲学异曲同工：将状态外部化存储（在这里是任务文档和代码仓库），让每次执行都保持轻量和可预测。

Roo的成功验证

Roo是这一架构最具代表性的成功案例，它"席卷了整个互联网"，不仅因为其惊人的效果，更因为其底层架构的极度简洁。从Roo的文档中可以看到，整个流程就是：创建PRD → 输出JSON任务文件 → 循环实现功能。查看其代码仓库，你会惊讶于整个项目的体量之小。

Anthropic对Harness的简单演示同样如此——轻量级、简洁的环境。越简单的架构，反而产生了越强大的效果，这本身就说明了范式转换的力量。

Harness与前代技术的关系：叠加而非替代

一个常见的误解是，Harness Engineering会取代提示工程和上下文工程。事实恰恰相反。

如果你深入查看Kline等开源编码智能体的源码，会发现它们的系统提示仍然由精心编写的提示词驱动。三层工程的关系是：

• 提示工程：告诉智能体"你是谁"——赋予它编码智能体的角色和行为准则，是最底层的组件
• 上下文工程：管理智能体"知道什么"——通过工具调用、MCP、RAG等技术管理信息流
• 驾驭工程：定义智能体"如何工作"——构建循环执行环境，编排任务流程，管理迭代节奏

Harness Engineering是在前两者之上的更高层抽象，它有效地利用了提示工程和上下文工程的能力，但将重心从"如何写好一个提示"或"如何管理好上下文"转移到了"如何为智能体构建最优的执行环境"。这种分层架构与软件工程中的经典模式高度一致——就像操作系统不会取代CPU指令集，而是在其之上提供更高效的资源管理和任务调度能力。

实际应用：从手动到全自动的进化

以Cursor为例，我们可以看到Harness思想在实际产品中的渐进式体现：

1. 本地智能体：在本地启动Cursor，让智能体更新网站信息
2. 并发智能体：同时生成多个智能体，各自拥有独立上下文，并发修复不同功能
3. 云端智能体：将任务推到云端运行，关闭本地Cursor后任务继续执行，完成后自动创建Pull Request。Pull Request（PR）是现代软件开发中基于Git版本控制系统的协作机制——开发者在独立分支上完成代码修改后，通过创建PR请求将代码合并到主分支，其他团队成员可以在PR中进行代码审查。当云端智能体自动创建PR时，它实际上模拟了一个完整的开发者工作流：创建分支、编写代码、运行测试、提交变更、发起合并请求。这与CI/CD（持续集成/持续部署）管道的结合，使得AI生成的代码能够经过与人类代码相同的质量门控流程，包括自动化测试、代码风格检查和安全扫描。
4. 集成自动化：通过Slack发送功能需求，云端智能体自动执行并在完成后通知
5. 全自动运行：设置云端自动化任务，每日检查新模型发布，自动保持网站信息最新

这个从手动到全自动的演进路径，正是Harness Engineering赋能的典型场景——智能体不再是一个需要你盯着它工作的工具，而是一个可以在结构化环境中自主运行的"数字员工"。

为什么说Harness会改变一切

如今，越来越多的编码智能体公司已经在产品中直接集成了Harness层，尽管各家的实现方式不尽相同。这一趋势的背后是一个简单而深刻的事实：当你不再试图让一个智能体在一个巨大的上下文中完成所有事情，而是为它构建一个结构化的循环执行环境时，效果会产生质的飞跃。

Harness Engineering的真正价值不在于某个具体的技术突破，而在于它代表了一种思维方式的转变——从"如何让AI更聪明"到"如何为AI构建更好的工作环境"。这与人类工程管理的逻辑如出一辙：一个优秀的工程师在混乱的环境中也会表现平庸，而一个合理的工作流程能让普通工程师产出优秀的成果。这一洞察也呼应了软件工程领域的经典论断——Fred Brooks在《人月神话》中指出，软件开发的核心困难不在于编码本身，而在于概念的完整性和系统的架构设计。Harness Engineering正是将这一智慧应用于AI智能体的管理之中。

对于AI从业者而言，理解并掌握Harness Engineering，可能是当下最值得投入的技能之一。

核心要点