Harness Engineering 深度指南：2026 年 AI 工程的定义性技能

AI 工程的定义正在被重写。

2023 年，行业热词是 Prompt Engineering——如何写好提示词，让模型输出更好的结果。

2024-2025 年，演进到 Context Engineering——不只是单轮提示词，而是管理多轮对话的上下文、记忆和状态。

2026 年，Harness Engineering 成为新的定义性技能。

什么是 Harness Engineering？

Harness（直译"马具"）在 AI 语境中指 Agent 周围的所有编排系统——包括提示词管理、上下文路由、工具调用、状态管理、错误恢复、成本控制和可观测性。

OpenAI Codex 负责人 Ryan Lopopolo 在 AI Engineer World's Fair 2026（AIEWF 2026）上的原话是：

"Agents are not hard. The harness is hard."
（构建 Agent 本身不难，难的是 Agent 周围的系统。）

这句话为什么被反复引用？ 因为它精准地描述了 AI 工程实践的真相——大多数团队在构建 Agent 时，遇到的困难不在模型本身，而在模型周围的编排、状态管理和可靠性工程。

Lilian Weng 随后发表了 'Harness Engineering for Self-Improvement'，将 Harness Engineering 提升为一个独立的工程学科，强调它不仅是工程实践，更是 AI 系统自我改进的基础设施。

要理解 Harness Engineering，需要理解它在演进链中的位置。

2.1 Prompt Engineering（2023）

核心问题：如何写好一条提示词？

典型工作：

• 设计 system prompt
• 使用 few-shot examples
• 调整温度、top-p 等参数
• 处理格式输出（JSON mode、function calling）

局限性：只关注单次调用，不处理多轮状态和系统级问题。

2.2 Context Engineering（2024-2025）

核心问题：如何管理多轮对话的上下文？

典型工作：

• 对话历史管理（滑动窗口、摘要压缩）
• RAG（检索增强生成）
• 记忆系统（短期/长期记忆）
• 上下文注入（用户画像、偏好、历史行为）

进步：从单次调用扩展到多轮交互。

局限性：仍然以"对话"为中心，不处理工具编排、错误恢复和系统级可靠性。

2.3 Harness Engineering（2026）

核心问题：如何设计 Agent 周围的完整编排系统？

典型工作：

• Agent 编排（LangGraph、CrewAI、Claude Agent SDK）
• 工具调用管理（function calling、MCP、tool routing）
• 状态机设计（多步骤任务的状态管理）
• 错误恢复和重试策略
• 成本控制和预算管理
• 可观测性（trace、metrics、logging）
• 安全边界（sandbox、权限控制、审计日志）

进步：从"对话管理"跃迁到"系统编排"。

2.4 三层对比

一个完整的 Harness 系统包含哪些组件？

3.1 编排引擎（Orchestration Engine）

职责：管理 Agent 的执行流程——从哪里开始、调用什么工具、何时结束。

典型实现：

• LangGraph：基于图的状态机编排，2026 年最主流的 Agent 编排框架
• CrewAI：多 Agent 协作框架，强调角色分工
• Claude Agent SDK：Anthropic 的 Agent 开发框架
• Microsoft Agent Framework：统一了 AutoGen + Semantic Kernel，已 1.x GA

核心设计决策：

• 确定性流程 vs 动态规划（预定义状态机 vs 模型自主决策）
• 单 Agent vs 多 Agent
• 同步 vs 异步执行

3.2 工具管理（Tool Management）

职责：管理 Agent 可以调用的工具——注册、路由、权限、错误处理。

典型实现：

• Function Calling（OpenAI/Anthropic 原生支持）
• MCP（Model Context Protocol）——Anthropic 推动的工具协议标准
• Tool Routing（根据任务类型选择工具集）

关键挑战：

• 工具数量膨胀——当 Agent 有 50+ 工具时，如何选择？
• 工具组合——多个工具如何串联/并联？
• 工具失败——工具调用失败时的降级策略

3.3 状态管理（State Management）

职责：管理 Agent 执行过程中的状态——当前步骤、中间结果、历史记录。

典型实现：

• 检查点（Checkpoint）——保存中间状态，支持断点续传
• 状态机（State Machine）——定义合法的状态转换
• 事务（Transaction）——保证状态变更的原子性

关键挑战：

• 长任务的状态持久化——Agent 运行 10 分钟，中间状态如何保存？
• 并发状态——多个 Agent 同时操作同一资源
• 状态回滚——任务失败时如何回退到上一个安全状态

3.4 成本控制（Cost Control）

职责：管理 Agent 运行的 token 消耗和 API 成本。

典型实现：

• Token 预算——为每个任务设定 token 上限
• 模型路由——简单任务用小模型，复杂任务用大模型
• 缓存——重复查询的结果缓存，避免重复调用

关键数据：

• 开发者 Vivek Haldar 的案例：通过将稳定步骤从自然语言指令移到确定性代码，将 Agent token 账单降低 94%
• OpenAI 提出的新指标："每美元有用工作量"（Useful Work per Dollar, UWP）——不再衡量 token 单价，而是衡量每美元能产生多少有用输出

3.5 可观测性（Observability）

职责：追踪 Agent 的执行过程——每一步做了什么、为什么这么做、花了多少钱。

典型实现：

• Trace（追踪）——记录 Agent 的完整执行路径
• Metrics（指标）——延迟、成本、成功率、token 消耗
• Logging（日志）——详细的执行日志，用于调试和审计

关键挑战：

• 非确定性行为——Agent 的执行路径每次可能不同
• 成本归因——哪个步骤花了多少钱？
• 异常检测——如何发现 Agent 进入了死循环或异常状态？

理论之后，让我们看具体的工程实践。

4.1 起步阶段：单 Agent + 确定性流程

适用场景：任务流程固定，工具数量 < 10，单 Agent 足够。

关键实践：

1. 使用 LangGraph 定义状态机——每个节点是一个明确的步骤
2. 工具调用使用 Function Calling——不要自己写工具解析逻辑
3. 设定 token 预算——防止失控
4. 添加基础 trace——至少记录每一步的输入输出

反模式：

• ❌ 让模型完全自主决定下一步——在起步阶段，确定性流程更可靠
• ❌ 不设定 token 预算——一个死循环可能消耗数千美元
• ❌ 不记录 trace——出了问题无法调试

4.2 进阶阶段：多 Agent + 动态路由

适用场景：任务类型多样，需要不同专长的 Agent 协作。

关键实践：

1. 定义 Agent 角色——每个 Agent 有明确的职责边界
2. 实现路由逻辑——根据任务类型分发给合适的 Agent
3. 使用模型路由——简单任务用小模型（如 GPT-4o-mini），复杂任务用大模型（如 GPT-5.6）
4. 实现错误恢复——Agent 失败时的重试和降级策略

关键决策：

• 多 Agent 通信方式：共享状态 vs 消息传递
• 失败处理：重试 vs 跳过 vs 人工介入
• 成本控制：每个 Agent 的预算分配

4.3 高级阶段：自适应 Harness

适用场景：Harness 需要根据任务特征自动调整配置。

关键实践：

1. 自适应工具选择——根据任务特征动态加载工具集
2. 自适应模型选择——根据任务复杂度和成本约束选择模型
3. 自适应重试策略——根据失败类型调整重试策略
4. 自适应成本控制——根据预算动态调整 Agent 行为

Lilian Weng 的 'Harness Engineering for Self-Improvement' 描述的就是这个阶段——Harness 不仅是执行系统，还是学习和改进系统。

开发者 Vivek Haldar 分享了一个引人注目的案例：将 Agent 的 token 账单降低了 94%。

5.1 问题背景

Haldar 的团队运行一个 AI Agent 处理复杂任务，token 成本持续攀升。分析后发现，大量 token 被消耗在不需要模型智能的步骤上。

5.2 核心策略：确定性代码 vs 模型判断分离

关键洞察：Agent 的很多步骤是"稳定的"——每次执行的方式基本相同，不需要模型的灵活性。这些步骤应该用确定性代码实现，而不是让模型生成。

具体做法：

1. 识别稳定步骤：分析 Agent 的执行 trace，找出每次执行方式相同的步骤
2. 移到确定性代码：将这些步骤从自然语言指令改为硬编码的代码逻辑
3. 只让模型做判断：模型只负责需要灵活性的决策步骤

示例：

优化前（全自然语言指令）：每一步都让模型处理——读取文件路径、检查文件是否存在、读取文件内容、解析 JSON 格式、提取关键字段、生成摘要。其中只有"生成摘要"这一步才真正需要模型智能。

优化后（确定性代码 + 模型判断）：稳定步骤用确定性代码——直接提取文件路径（不需要模型）、确定性检查文件是否存在、确定性读取文件内容、确定性解析 JSON、确定性提取关键字段。只有最后一步"生成摘要"交给模型判断。

5.3 成本对比

5.4 OpenAI 的"每美元有用工作量"框架

OpenAI 在 2026 年 7 月提出了一个新指标：Useful Work per Dollar（UWP，每美元有用工作量）。

核心思想：不要看 token 单价，要看每美元能产生多少有用输出。

五项 Agentic Spend 治理实践：

1. 设定 token 预算上限
2. 追踪每个任务的 token 消耗
3. 识别和优化高成本低价值步骤
4. 使用缓存减少重复调用
5. 模型路由——简单任务用小模型

这与 Haldar 的策略高度一致——核心都是"把不需要模型智能的步骤移到确定性代码"。

5.5 Harness Engineering 的其他价值维度

成本优化只是 Harness Engineering 价值的一个切面。 完整的价值评估应该包含四个维度：

可靠性提升：通过状态机、检查点、错误恢复机制，Harness 可以将 Agent 的任务完成率从 70% 提升到 95%+。一个没有 Harness 的 Agent 在遇到 API 超时、格式错误、状态异常时会直接失败；而一个有 Harness 的 Agent 可以自动重试、回滚、降级。

可维护性改善：当 Agent 逻辑全部写在 prompt 里时，修改一个行为可能影响其他行为。Harness 将逻辑分解为独立的组件（编排、工具、状态、成本、可观测性），每个组件可以独立测试和迭代。

可观测性增强：没有 Harness 的 Agent 是黑盒——你不知道它为什么做出某个决策、花了多少钱、在哪个步骤卡住。Harness 的 trace、metrics、logging 让你能够审计 Agent 的每一步行为，这对于生产环境的调试和合规至关重要。

安全性保障：Harness 提供了 sandbox、权限控制、审计日志等安全边界。一个没有 Harness 的 Agent 可能调用任意工具、访问敏感数据、执行危险操作；而一个有 Harness 的 Agent 只能在预定义的权限范围内行动。

综合评估：当你向管理层汇报 Harness Engineering 的价值时，不要只说"降低了 94% 成本"——要说"将任务完成率从 70% 提升到 95%，成本降低 94%，同时获得了完整的可观测性和安全性"。这才是 Harness Engineering 的完整价值主张。

2026 年，Harness Engineering 已经有了成熟的工具生态。

6.1 LangGraph

定位：2026 年最主流的 Agent 编排框架。

核心特性：

• 基于图的状态机编排
• 支持循环、条件分支、并行执行
• 内置检查点和断点续传
• 与 LangChain 生态深度集成

适用场景：需要精确控制执行流程的复杂 Agent。

6.2 CrewAI

定位：多 Agent 协作框架。

核心特性：

• 角色定义——每个 Agent 有明确的职责
• 任务委派——Agent 之间可以委派任务
• 内置协作模式——顺序、并行、层级

适用场景：需要多个专长 Agent 协作的复杂任务。

6.3 Claude Agent SDK

定位：Anthropic 的 Agent 开发框架。

核心特性：

• 深度集成 Claude 模型能力
• 内置工具管理（MCP 协议）
• 强调安全性和可控性

适用场景：以 Claude 为核心模型的 Agent 开发。

6.4 Microsoft Agent Framework

定位：微软的统一 Agent 框架，已 1.x GA。

核心特性：

• 统一了 AutoGen + Semantic Kernel
• 企业级特性（安全、合规、可观测性）
• 深度集成 Azure AI 生态

适用场景：企业级 Agent 开发，特别是已使用 Azure 的组织。

6.5 工具选择指南

AIEWF 2026 的第五个趋势可能是最深刻的：工程组织正在从"写代码"转向"设计写代码的系统"。

7.1 这意味着什么？

传统软件工程：

• 工程师写代码实现功能
• 代码是最终产物

AI 时代的软件工程：

• 工程师设计一个系统，这个系统能生成代码
• Agent + Harness 是最终产物，代码是 Agent 的产出

这不是"工程师不再需要写代码"——而是工程师的核心工作从"实现"转向"编排"。

7.2 新的技能要求

Harness Engineer 需要的技能：

1. 系统设计：如何设计可靠、可扩展的 Agent 编排系统
2. 状态管理：如何管理复杂的多步骤状态
3. 成本工程：如何优化 token 消耗和 API 成本
4. 可观测性工程：如何追踪和调试非确定性的 Agent 行为
5. 安全工程：如何设计安全边界和权限控制

传统技能仍然重要：

• 软件工程基础（数据结构、算法、设计模式）
• 系统设计（分布式系统、微服务、数据库）
• 测试工程（单元测试、集成测试、端到端测试）

7.3 团队结构变化

传统团队：

• 前端工程师、后端工程师、数据工程师、QA

AI 时代团队：

• Harness Engineer（编排系统设计）
• Prompt Engineer（提示词和上下文管理）
• Tool Engineer（工具开发和管理）
• AI QA（Agent 行为验证和安全测试）

关键变化：团队规模可能更小，但每个人的影响力更大——一个 Harness Engineer 可以编排多个 Agent 完成传统团队的工作。

Harness Engineering 不是银弹。有必要审视它的局限和风险。

8.1 复杂度风险

Harness 系统的复杂度可能超过它管理的 Agent 本身的复杂度。一个过度设计的 Harness 可能成为维护负担。

建议：从简单开始，只在确实需要时才增加复杂度。

8.2 过度工程化风险

不是所有 AI 应用都需要复杂的 Harness。一个简单的 prompt + API 调用可能就够了。

建议：评估实际需求——如果任务简单，不要用复杂的 Harness。

8.3 抽象泄漏风险

Harness 框架试图抽象 Agent 编排的复杂性，但抽象总会泄漏。当抽象泄漏时，工程师需要深入理解底层机制。

建议：不要盲目信任框架——理解框架背后的原理。

8.4 快速变化风险

Harness Engineering 的工具和最佳实践仍在快速变化。今天选择的框架可能半年后就被淘汰。

建议：关注原则而非工具——掌握核心概念（状态管理、成本控制、可观测性），工具可以换。

8.5 与 Prompt/Context Engineering 的关系

Harness Engineering 不是替代 Prompt/Context Engineering，而是包含它们。一个好的 Harness 系统仍然需要好的 prompt 和好的上下文管理。

三层关系的正确理解：

• Prompt Engineering 是基础——没有好的 prompt，Harness 再复杂也没用
• Context Engineering 是扩展——管理多轮上下文
• Harness Engineering 是系统——将 prompt 和 context 管理纳入完整的编排系统

如果你刚开始接触 Harness Engineering，以下是一个分阶段的实践路线图。

阶段 1：基础（1-2 周）

1. 掌握 Prompt Engineering：确保你能写出高质量的提示词
2. 学习 Function Calling：理解模型如何调用工具
3. 使用 LangGraph 构建第一个 Agent：从简单的单 Agent 开始
4. 添加基础 trace：记录每一步的输入输出

阶段 2：进阶（2-4 周）

1. 学习状态管理：理解检查点、状态机、事务
2. 实现成本控制：添加 token 预算和模型路由
3. 构建多 Agent 系统：使用 CrewAI 或 LangGraph 实现 Agent 协作
4. 添加错误恢复：实现重试和降级策略

阶段 3：高级（4-8 周）

1. 实现自适应 Harness：根据任务特征自动调整配置
2. 深度可观测性：实现完整的 trace、metrics、logging
3. 安全工程：设计 sandbox、权限控制、审计日志
4. 成本优化：应用 Haldar 的 94% 成本降低策略

推荐学习资源

Harness Engineering 的兴起标志着 AI 工程正在从"实验"走向"生产"。

当 AI 应用只是 demo 时，一个 prompt 就够了。当 AI 应用进入生产环境，你需要的是一个完整的系统——可靠、可控、可观测、成本可控。

这就是 Harness Engineering 要解决的问题。

三个核心判断：

1. Harness Engineering 不是 buzzword——它是 AI 工程成熟的标志。 就像 DevOps 不是 buzzword，而是软件工程成熟的标志一样。

2. 掌握 Harness Engineering 的工程师将成为 AI 时代最稀缺的人才。 因为这不是一个可以在学校学到的技能——它需要在生产环境中实践和积累。

3. 工具会变，原则不变。 LangGraph 可能被更好的框架替代，但状态管理、成本控制、可观测性的原则不会变。掌握原则，而非工具。

Ryan Lopopolo 说得对：'Agents are not hard. The harness is hard.'

但"难"正是价值所在。 解决了难的问题，你就是那个定义 AI 工程标准的人。

补充分析：Harness Engineering 的量化价值

从 Vivek Haldar 的 94% 成本降低案例，我们可以量化 Harness Engineering 的具体价值：

成本对比：

关键洞察： Harness Engineering 不是理论概念，而是已经被验证的工程实践。94% 的成本降低来自将确定性任务（数据库查询、格式化输出）从 LLM 移到确定性代码——这是 Harness 设计的核心原则之一。

对工程师的实际建议： 如果你正在构建 Agent 系统，立即审计你的工作流，识别哪些步骤可以用确定性代码替代。从简单的开始：数据格式转换、API 路由、结果拼接。这些"无聊"的工程工作，正是成本优化的关键。

补充分析：Harness Engineering 的组织影响

Harness Engineering 不仅是技术实践，更是组织变革。从"写代码"到"设计写代码的系统"，工程师的核心工作正在从"实现"转向"编排"。

团队结构的变化：

关键变化： 团队规模可能更小，但每个人的影响力更大——一个 Harness Engineer 可以编排多个 Agent 完成传统团队的工作。这不是"工程师不再需要写代码"——而是工程师的核心工作从"实现"转向"编排"。

对 CTO 的建议： 现在就开始培养团队的 Harness Engineering 能力。从系统设计、状态管理、成本控制、可观测性四个维度入手。工具会变（LangGraph 可能被更好的框架替代），但原则不变。掌握原则的工程师，将是 AI 时代最稀缺的人才。