AI驾驭工程系列：2 Harness Engineering 定位与核心组件

什么是驾驭层？

驾驭层（Harness）不是智能体本身。 它是治理智能体如何运行的软件系统。

它管理完整的生命周期，包括工具、记忆、重试、人工审批、上下文工程、子智能体等，以便模型可以专注于推理。

Philipp Schmid 用计算机比喻得最贴切：

• 模型是原始处理能力
• 上下文窗口是有限的工作内存
• 驾驭层（Harness）是操作系统，管理上下文、初始化序列和标准工具驱动
• 智能体是运行在其上的应用程序

驾驭层在架构栈中的位置

SDK、脚手架和框架 回答的是“如何构建 AI 智能体”的问题。驾驭层回答的则是完全不同的问题，“智能体如何运行”。驾驭层不是它们的替代品，而是位于它们之上的层级。

parallel.ai 团队识别出了六个核心组件，这与 OpenAI 和 Anthropic 发布的观点一致：

1. 工具集成层（Tool Integration Layer）

通过定义的协议将模型连接到外部 API、数据库、代码执行环境和自定义工具。

2. 记忆与状态管理（Memory and State Management）

多层记忆（工作上下文、会话状态、长期记忆），持续存在于单个上下文窗口之外。

Anthropic 的方法使用进度文件（progress files）和 Git 历史来桥接会话。

3. 上下文工程与提示词管理（Context Engineering and Prompt Management）

动态策划每次模型调用中出现的信息。不是静态的提示词模板，而是基于当前任务状态的主动上下文选择。

4. 规划与任务分解（Planning and Decomposition）

引导模型通过结构化的任务序列，而不是试图一次性完成所有事情。

5. 验证与护栏（Verification and Guardrails）

验证检查、格式验证、安全过滤器。自我纠正循环。当智能体遇到困难时，驾驭层将其视为识别缺失内容的信号。

当 AI 智能体遇到困难、出错或卡住时，驾驭层（Harness）不会简单地判定为“失败”，而是将这个“困难”视为一个诊断信号，提示系统中缺少了某些必要的东西。

想象一下这个场景：

传统做法：

• 智能体执行任务 → 报错/卡住 → 系统显示“失败” → 结束

驾驭层的做法：

• 智能体执行任务 → 报错/卡住 → 驾驭层分析这个错误信号 → 识别缺失内容 → 自动补充或调整 → 重试

6. 模块化与可扩展性（Modularity and Extensibility）

可插拔的组件，可以独立启用、禁用或替换。

真实驾驭层案例

1. 案例 1： Claude Code

Claude Code 本身就是一个驾驭层。它可以读取整个代码库、管理文件系统访问、生成子智能体、处理工具编排、跨会话维护内存，并实现安全防护。

开发者专注于任务，驾驭层管理其他一切。

2. 案例 2： OpenAI Codex

OpenAI 团队构建了超过 100 万行代码的代码库，完全没有手动输入的代码，将驾驭层视为主要接口。

当智能体遇到困难时，他们将改进反馈到代码库中。上下文工程、架构约束和定期清理智能体构成了核心。

3. 案例 3： OpenAI 的 CUA 示例应用

这是一个用于计算机使用的驾驭层。运行器管理"截图 → 行动 → 验证 → 重复"的循环。

模型决定做什么，驾驭层安全地执行它。

小结

智能体定义、消息路由、任务生命周期、依赖管理、生成工作进程 ……开发者使用框架约 80% 的功能，现在模型已原生处理。

剩余的 20%：持久化、确定性重放、成本控制、可观测性、错误恢复，正是驾驭层所提供的内容。

框架层不仅仅是消失，它在分裂：智能迁移到模型中，基础设施迁移到驾驭层。

对于今天构建 AI 智能体的团队来说，核心问题正在发生转变：不再是“我们应该用哪个框架？” 而是“我们的驾驭层是什么样的？”

驾驭层决定智能体的成功与失败。一个优秀的驾驭层负责管理人工审批、文件系统访问、工具编排、子智能体、提示和生命周期等环节，其设计原则是：最小限度地干预智能体的自主运行，但同时必须能够防止灾难性的失败。