Harness Engineering：智能体开发的新范式解析

从提示词工程到 Harness Engineering

智能体开发领域的关注焦点一直在演变。早期开发者最看重的是提示词工程（Prompt Engineering），即如何编写高质量的提示词让模型输出更符合预期。随后，**上下文工程（Context Engineering）**成为主流话题——不少求职面试中，面试官都会围绕上下文管理提问，考察候选人如何在有限的上下文窗口里组织信息、维护状态。

而据该 B 站 UP 主的分析，当前阶段智能体开发的核心正在向 Harness Engineering（马缰工程） 迁移。这个概念据称由 Anthropic 提出，被视为智能体开发领域的下一个关键范式。它并非要取代前两者，而是把提示词工程、上下文工程都囊括其中，构成一个更完整的体系。

用一句话概括三者的关系：Harness Engineering 包含 Context Engineering，Context Engineering 又包含 Prompt Engineering。这是一种层层递进的包含关系，但 Harness 的边界要宽得多，覆盖了远超上下文管理的内容。

提示词工程起源于 GPT-3 时代，核心技巧包括 few-shot 示例、思维链（Chain-of-Thought）、角色设定等，目标是通过措辞优化让模型在单次交互中输出更理想的结果。上下文工程则随着长上下文模型（如 Claude 的 200K token 窗口）和多轮 Agent 任务的普及而兴起，关注如何在有限的 token 预算内动态组织信息——例如何时压缩历史对话、如何检索外部知识注入上下文、以及如何在多步骤任务中保留关键状态。两者的共同局限在于视角都集中于「送给模型的内容」，而忽视了模型之外的整个运行环境。

Harness 到底指什么

Harness 直译为中文是「马缰」或「缰绳」，形象地表达了它的作用——对大模型这匹「烈马」进行约束、引导和控制。它的核心定义是：在一个智能体系统中，除了大模型本身之外的所有基础设施，统称为 Harness。

换句话说，程序员的关注点不应该只停留在提示词或上下文这些局部问题上，而应聚焦于构建一整套「包裹在模型之外」的系统化基础设施。这套设施把工具调用、记忆、规划、安全、执行循环、状态管理、Skill、沙箱、文件系统、权限控制等能力整合到一起，形成一个统一的架构层。

这种思路的转变很关键。它意味着智能体的能力上限，越来越取决于模型外围工程的成熟度，而不仅仅是模型本身的智能水平。以 Claude Code 为例，UP 主认为它之所以好用，正是因为团队用 TypeScript 开发了一套全新的智能体架构，而这套架构正体现了 Harness Engineering 的理念。

七大核心能力构成完整体系

据视频内容，Harness Engineer 由七个核心模块组成，这七块能力共同支撑起一个完整的智能体运行框架。

虽然原始素材没有逐一详尽拆解每个模块的实现细节，但结合上下文可以梳理出这套架构关注的几个关键维度：

• 上下文工程：管理模型的输入输出信息组织
• 存储与记忆：让智能体具备跨任务的持久记忆能力
• 多任务规划：拆解复杂目标为可执行步骤
• 行为与观察：执行动作并观察反馈，形成闭环
• 工具调用：让智能体能够调用外部工具完成任务
• 安全与权限：防范恶意代码、控制文件操作权限
• 状态管理与执行循环：维护长周期任务中的一致性

这些模块并非孤立存在，而是相互协作，构成了智能体运行的「操作系统」级别的基础设施。

Harness 要解决的核心痛点

为什么需要这样一套体系？因为传统智能体在处理长周期、多步骤的复杂任务时，往往会暴露出一系列棘手问题：

上下文爆炸——任务步骤越多，累积的上下文信息越庞大，很快超出模型窗口限制。

状态丢失——多轮交互后，智能体容易「忘记」之前的关键状态和决策。

工具调用混乱——缺乏统一的调度机制，工具调用容易出错或冲突。

缺乏规划能力——面对复杂任务无法有效拆解，导致执行走偏。

安全隐患——这是常被忽视但极其重要的一环。UP 主特别举例：如果一个脚本里含有恶意代码，智能体不能对此视而不见。文件操作、权限控制、沙箱隔离等安全机制必须成为架构的一部分，而不是事后补丁。

Harness Engineering 的价值，正是把这些散落的问题统一收拢到一个新架构中系统化解决。对于企业级的多 Agent 协同场景而言，这种系统化的基础设施尤为重要——多个智能体协作时，状态一致性、权限隔离、任务规划的复杂度会成倍增加。

上下文爆炸问题在实际工程中尤为突出：以 GPT-4o 或 Claude 3.5 Sonnet 为例，即便拥有 128K–200K token 的窗口，一个涉及数十次工具调用的复杂任务仍然可能在数小时内耗尽上下文容量，且 token 消耗与成本成正比。工业界的常见应对手段包括滑动窗口截断、摘要压缩（Summarization）、向量数据库外置记忆（RAG）等，但这些方案若缺乏统一的架构层协调，会导致信息丢失不可预期。状态丢失问题则在多 Agent 协同场景下更为严重——不同 Agent 各自维护独立上下文，若没有共享状态存储（如 Redis 或结构化数据库），协作任务极易因状态不一致而失败。Harness Engineering 的价值之一，正是为这些问题提供架构层面的统一解法，而非依赖零散的临时补丁。

对开发者的启示

从提示词到上下文再到 Harness，这条演进路线反映了智能体开发正在从「调教模型」走向「工程化系统建设」。对于希望深入智能体开发的工程师而言，仅仅掌握提示词技巧已经远远不够，理解并构建模型外围的完整基础设施，才是构建可靠、可扩展智能体的关键。

需要说明的是，本文基于单一来源的视频内容整理，Harness Engineering 目前更多是一种概念性框架的表述，其七大模块的具体实现方案和落地细节仍有待更系统的资料佐证。感兴趣的开发者可以从 Claude Code 等已有产品的架构设计中，观察这一理念的实际应用。