Harness Engineering：从提示词到系统架构的智能体开发新范式

从提示词工程到 Harness Engineering

如果你关注 AI 智能体（Agent）的发展，会发现"工程"的关注焦点每隔一段时间就在迭代。2024 年，大家谈论最多的是提示词工程（Prompt Engineering），核心是如何写出更好的 Prompt 去驱动大模型。提示词工程兴起于2022-2023年大语言模型大规模落地之后，其核心是通过精心设计输入文本的结构、措辞和格式来引导模型产生期望的输出，典型技术包括少样本提示（Few-shot Prompting）、思维链（Chain-of-Thought）、角色扮演（Role-playing）等。随着模型能力增强，人们逐渐发现单纯优化提示词已不足以应对复杂的多步骤任务，这催生了对更系统化工程方法的需求。

2025 年，讨论的重点转向了上下文工程（Context Engineering），很多面试中面试官都会问候选人如何管理和组织 Agent 的上下文。上下文工程的提出反映了一个关键认识：模型的输出质量不仅取决于提示词本身，更取决于喂给模型的全部信息——包括系统提示、对话历史、检索到的文档片段、工具调用结果等。典型实践包括 RAG（检索增强生成）架构中的文档分块与检索策略、上下文窗口的动态管理、信息压缩与摘要等。Shopify CEO Tobi Lütke 在2025年初将其称为"the new hotness"，Andrej Karpathy 等 AI 领域意见领袖也多次强调其重要性。

而进入 2026 年，业界正在浮现一个更宏大的概念——Harness Engineering（有人译作"马鞍工程"或"驾驭工程"，但本文沿用英文原称）。这一术语源自 Anthropic 官方的提法。Anthropic 是由前 OpenAI 研究副总裁 Dario Amodei 和 Daniela Amodei 兄妹于2021年联合创立的 AI 安全公司，其旗舰产品 Claude 系列大语言模型在代码生成、长文本理解和多步推理方面表现突出。Harness Engineering 并非要取代前两者，而是把提示词工程、上下文工程都囊括其中，构成一个更完整的智能体开发体系。

可以用一个简单的包含关系来理解三者的演进：

Harness Engineering ⊇ Context Engineering ⊇ Prompt Engineering

也就是说，Harness Engineering 包含了上下文工程，而上下文工程又包含了提示词工程。三者层层递进，反映了智能体开发从"调教模型"到"构建系统"的思路转变。

什么是 Harness Engineering

给 Harness Engineering 下一个定义：它是当前智能体开发领域的一种核心开发方式与软件架构方式。它的关键转变在于——开发者不再仅仅关心提示词，也不再仅仅关心上下文，而是聚焦于构建一整套包裹在模型之外的系统化基础设施。

换句话说，在一个完整的智能体系统里，除了大模型本身之外的所有东西，都可以被概括进 Harness 这个概念。从广义上讲，Harness 指的就是在智能体开发过程中，围绕大模型构建的全部基础设施。这一点很重要：网上有些解释把 Harness 的概念讲得太窄了，实际上它的外延要宽广得多。

Harness 的七大核心能力

Anthropic 提出的 Harness Engineering 由七个核心模块组成，这七大能力共同构成了完整的智能体架构。综合来看，它至少涵盖以下要素：

• 上下文管理（Context）：如何组织、压缩、检索上下文，避免上下文爆炸。上下文窗口（Context Window）是指大语言模型一次能处理的最大 Token 数量——早期 GPT-3 的上下文窗口仅为4096个 Token，而到2025年 Claude 3.5 已支持200K Token，Gemini 甚至达到百万级。然而即便窗口不断扩大，"上下文爆炸"问题依然存在：过长的上下文会导致模型注意力分散（即"Lost in the Middle"现象），关键信息被淹没；同时 Token 消耗直接影响 API 调用成本和响应延迟。因此，智能的上下文管理——包括信息筛选、压缩摘要和分层存储——成为 Harness Engineering 中至关重要的能力。

• 存储与记忆（Memory）：短期记忆与长期记忆的持久化方案。短期记忆通常对应当前对话的上下文缓存，而长期记忆则需要借助向量数据库（如 Pinecone、Weaviate）或传统数据库进行持久化存储，使 Agent 能够跨会话保持对用户偏好、项目状态和历史决策的认知。

• 工具调用（Tools）：让 Agent 能够调用外部工具与 API。工具调用（Tool Use / Function Calling）是让大模型从纯文本生成器升级为能执行实际操作的智能体的关键技术。其基本原理是：模型在生成过程中识别出需要外部能力的场景，输出结构化的函数调用请求（通常为 JSON 格式），由外部系统执行后将结果返回模型继续推理。在 Harness 框架下，工具调用不再是单次的 API 交互，而是被纳入统一的调度系统中，支持工具链编排、错误重试、并发控制和权限校验等企业级需求。

• 多任务规划（Planning）：将复杂任务拆解为多步骤执行计划

• 执行循环与状态管理（State）：维护 Agent 在长周期任务中的运行状态

• 观察者机制（Observation）：对执行结果进行观察和反馈

• 安全与权限（Security）：沙箱隔离、文件系统访问、权限控制等。沙箱（Sandbox）是一种安全隔离技术，它为程序创建一个受限的执行环境，使其无法访问宿主系统的敏感资源。在智能体场景下，沙箱的重要性被极大放大：当 AI Agent 具备代码执行和文件操作能力时，一旦模型被提示注入攻击（Prompt Injection）诱导执行恶意代码，可能导致数据泄露、文件删除甚至系统被接管。常见的沙箱实现包括 Docker 容器、WebAssembly（Wasm）运行时、以及操作系统级别的 seccomp 和 AppArmor 策略。

此外，还包括 Skill（技能）、沙箱、文件系统等更细粒度的能力。这些能力被统一收纳进 Harness 框架中协同工作。

Harness 解决了什么问题

理解一个架构，最好的方式是看它解决了哪些实际痛点。传统智能体在面对长周期、多步骤的复杂任务时，往往会遇到一系列棘手问题：

• 上下文爆炸：随着任务推进，上下文越积越多，最终超出模型的上下文窗口
• 状态丢失：多步骤执行过程中的中间状态无法有效保存和传递
• 工具调用混乱：缺乏统一的调度机制，工具调用容易失控
• 缺乏规划能力：无法将大任务拆分成可执行的小步骤
• 安全隐患：例如某个脚本中包含恶意代码，若没有沙箱和权限控制就可能造成严重风险

Harness Engineering 的核心价值，正是把这些散落的问题——上下文、状态、工具、规划、安全、权限、文件操作——统一收纳到一个架构中集中解决。这也是为什么像 Claude Code 这类工具能够表现出色：它底层用 TypeScript 实现了一套完整的智能体架构，而这套架构本质上就是 Harness Engineering 思想的工程化落地。Claude Code 是 Anthropic 推出的命令行 AI 编程工具，允许开发者在终端中与 Claude 交互完成代码编写、调试和重构等任务，其采用了多层安全模型，包括文件系统权限白名单和网络访问控制，正是 Harness Engineering 安全模块的实际应用。

为什么值得关注

从行业趋势来看，智能体开发的关注点正在从"如何写好一句 Prompt"上升到"如何设计好一整套模型外的基础设施"。这意味着，未来 Agent 开发的核心竞争力将不再只是提示词技巧，而是系统架构能力。

对于开发者而言，理解 Harness Engineering 的意义在于：它提供了一个自上而下的整体视角，帮助我们跳出"调 Prompt"的局部思维，转而去思考记忆、规划、工具、安全等系统性问题。在企业级多 Agent 协同的场景下，这种系统化的架构思维尤为关键——因为多个 Agent 之间的状态同步、任务调度、权限隔离，恰恰是最容易出问题的地方。

多 Agent 协同（Multi-Agent Collaboration）是指多个 AI 智能体在同一系统中分工合作完成复杂任务的架构模式，典型框架包括微软的 AutoGen、LangChain 的 LangGraph、以及 CrewAI 等。在多 Agent 场景下，核心挑战包括：状态同步——多个 Agent 如何共享任务进度和中间结果而不产生冲突；任务调度——如何决定哪个 Agent 在什么时间执行哪项子任务；通信协议——Agent 之间采用何种格式和协议交换信息；以及权限隔离——不同 Agent 应具有不同的工具访问权限以遵循最小权限原则。这些问题恰好对应了 Harness Engineering 中 State、Planning、Tools 和 Security 四大模块的设计目标，也印证了为什么 Harness Engineering 的系统化思维在多 Agent 时代变得不可或缺。

可以预见，随着 Claude Code 等产品的持续演进，Harness Engineering 有望成为智能体开发领域最重要的架构范式之一。掌握它，就是掌握下一阶段 Agent 工程化的钥匙。

核心要点