在大模型技术飞速迭代的今天，AI Agent 的能力边界不断被突破，但从实验室走向真实业务场景，最大的瓶颈早已不是模型的 “智商”，而是稳定性。当 Agent 在复杂任务中出现上下文过载、工具调用混乱、执行失控、自评失真等问题时，Harness Engineering（驾驭工程）应运而生，成为 AI Agent 稳定落地的核心支柱。
一、什么是 Harness Engineering？
Harness Engineering（驾驭工程），是指在 AI 系统中，除模型本身外所有决定系统稳定交付能力的组件总和。它的核心目标，是解决 AI Agent 在真实场景中的执行稳定性问题，完成从 “能思考” 到 “能稳定做事” 的关键跨越。
如果说 Prompt Engineering（提示词工程）解决的是 “模型能不能听懂指令”，Context Engineering（上下文工程）解决的是 “模型能不能拿到正确信息”，那么 Harness Engineering 解决的，就是 “模型能不能稳定执行任务”，是 AI 工程化从 “能用” 到 “好用、可靠” 的必经之路。
AI 工程的三阶段演进
AI 工程化的发展，本质上是对 Agent 能力边界的不断拓展与约束，三个阶段层层递进：
| 阶段 | 核心问题 | 解决思路 | 技术重点 | 局限性 |
|---|---|---|---|---|
| Prompt Engineering （提示词工程） | 模型是否听懂指令 | 优化语言表达 | 角色设定、风格约束、示例引导 | 无法弥补知识缺失，不擅长管理动态信息 |
| Context Engineering （上下文工程） | 模型是否获得正确信息 | 优化信息供给 | 检索增强 (IG)、渐进式披露、信息分层 | 无法解决执行过程中的监督与纠偏问题 |
| Harness Engineering （驾驭工程） | 模型能否稳定执行任务 | 优化运行系统 | 执行编排、状态管理、错误恢复 | - |
二、成熟 Harness 的六层架构：构建 Agent 的 “稳定骨架”
一套成熟的 Harness Engineering 体系，由六层核心架构组成，从上下文约束到错误恢复，全方位保障 Agent 的稳定运行：
1. 上下文边界层：给思考划清 “安全区”
核心功能：确保模型在正确边界内思考，避免上下文过载、信息混乱。
关键组件：
- 角色与目标定义：明确模型身份、任务范围及成功标准，从源头锚定执行方向；
- 信息裁剪与选择：确保上下文相关性，而非 “越多越好”，减少无效信息干扰；
- 结构化组织：分层管理规则、任务状态、外部证据，让信息有序可追溯。
2. 工具系统层：连接模型与现实世界的桥梁
核心功能：打通 Agent 与外部工具、数据、系统的链路，让模型能力落地。
关键挑战：
- 工具选择：平衡能力覆盖与使用复杂度，避免工具滥用；
- 调用时机：避免不必要调用和错误判断；
- 结果处理：提炼工具返回结果，保持与任务的强相关性，避免信息冗余。
3. 执行编排层：让无序执行变 “闭环可控”
核心功能：将复杂任务拆解为可执行步骤，解决 Agent “想到哪做到哪” 的无序问题。
典型流程：目标理解→信息检查→分析处理→输出生成→结果检查→修正迭代
核心价值：确保任务闭环，每一步都有校验、有迭代，避免执行失控。
4. 记忆与状态层：解决 Agent 的 “失忆” 难题
核心功能：管理 Agent 的全生命周期状态，避免因上下文丢失导致的执行偏差。状态分类：
- 当前任务状态：实时同步任务进度、待办事项；
- 会话中间结果：留存多轮交互的关键产出，避免重复计算；
- 长期记忆与用户偏好：沉淀用户习惯、历史数据，实现个性化服务。
管理原则：分类存储，避免信息混乱导致的执行错误。
5. 评估与观测层：建立质量反馈的 “红绿灯”
核心功能：建立质量反馈机制，避免 Agent “自我感觉良好” 的认知偏差。
关键组件：
- 输出验证与验收：对 Agent 产出做合规性、准确性校验；
- 自动化测试系统：用自动化用例覆盖核心场景，提前发现问题；
- 日志与指标监控：全链路追踪执行过程，定位异常根因；
- 错误归因分析：对失败案例做深度拆解，持续优化系统。
6. 约束校验与恢复层：给系统装上 “安全气囊”
核心功能：保障系统鲁棒性，让 Agent 在失败中快速恢复。
三大机制：
- 约束机制：明确能力边界，定义 “能做什么 / 不能做什么”，从源头规避风险；
- 校验机制：输出前后的检查流程，拦截错误结果；
- 恢复机制：失败后的重试、回滚策略，让系统具备自我修复能力。重要性：真实环境中失败是常态，恢复能力直接决定系统可用性。
三、项目实战：AntV Skills 的 Harness Engineering 实践
AntV 图表技能生成系统（chart-visualization-skills），展示了 Harness Engineering 如何在真实项目中落地。核心目标是：让 LLM 能够稳定生成 100+ 种 G2/G6/X6 等图表的可运行代码——不只是"偶尔能跑"，而是"持续可靠"。
以 G2 为例展开。
背景：从"能生成"到"稳定生成"的工程挑战
G2 v5 的 API 体系庞大，仅 Mark 类型就超过 30 种，配合坐标系、数据变换、交互配置后，排列组合近乎无限。LLM 在没有约束的情况下，极易产生三类典型失败：
- 渲染白屏：代码语法正确，但图表容器为空，原因通常是 API 误用（如坐标系类型错误、encode 字段缺失）；
- 运行时报错：调用了 G2 中不存在的方法或使用了 V4 旧语法；
- 自评失真：LLM 自己认为代码正确，实际在浏览器环境中无法执行。
解决这三类问题，靠 Prompt 优化不够，靠人工审核成本太高。这正是 Harness Engineering 的切入点。
Harness 六层架构的项目映射
1. Skill 检索注入系统 → 上下文边界层
系统没有将全量 G2 文档塞入 context，而是建立了分层的 Skill 知识库：
- 每种图表类型对应一个独立的 Skill Markdown 文件（如
g2-mark-interval-basic.md），包含最小可运行示例、常见错误与修正、API 速查； - 构建时将 Skill 的 title / tags / description / category 等字段索引化，生成
index/*.index.json； - 运行时通过 BM25 检索（
utils/retriever.js）精准匹配最相关的 Skill，只将命中文档注入系统 Prompt 的{RETRIEVED_SKILLS_CONTENT}占位符，BM25 未命中时自动 fallback 到全文 grep 检索。
这解决了上下文边界层的核心问题：信息裁剪，而非"越多越好"。
2. Optimize Agent 的按需文档查阅 → 工具系统层
Optimize Agent 在修复 Skill 文档时，并不预加载所有官方文档，而是为 LLM 提供三个按需调用的工具：
| 工具 | 职责 | 边界约束 |
|---|---|---|
list_directory | 浏览官方文档或源码目录结构 | 仅允许访问src 和 site/docs |
read_file | 读取具体文件内容 | 单次最多 12KB，防止 context 爆炸 |
grep_files | 关键词检索定位相关文件 | 结果上限 100 行，支持正则 |
工具调用遵循最小授权原则：模型只能在配置的 refs 路径内操作，禁止访问项目之外的文件系统。
3. 五步闭环优化循环 → 执行编排层
核心编排逻辑在 validator 中，由五个职责单一的 Agent 串联构成完整闭环：
每一步职责边界清晰，互不耦合，失败只影响当前步骤，不会造成级联崩溃。
4. Skill 文档即长期记忆 → 记忆与状态层
系统没有使用外部数据库存储"经验"，而是将 Skill Markdown 文件本身作为 Agent 的长期记忆载体：
- 任务状态：每轮迭代的错误用例列表，由 render-agent 实时产出，驱动当轮优化；
- 长期记忆：历次优化后的 Skill 文档持续积累"常见错误与修正"章节，沉淀为可检索的结构化知识；
- 记忆更新：每次 optimize-agent 改写 Skill 文件后，index-agent 立即重建索引，确保下一轮 eval 能用到最新知识。
这种设计使记忆天然可审计、可版本化（git 追踪），且不引入额外依赖。
5. 环境化验证而非 LLM 自评 → 评估与观测层
系统彻底规避了"LLM 自评失真"问题，采用浏览器环境化验证作为质量的唯一判定标准：
- 渲染测试（render-agent）：用 Headless 浏览器真实执行生成代码，判定三种状态：
success（渲染成功）/blank（白屏）/error（运行时报错）； - 错误归因（analyze-agent）：将失败用例精确关联到对应 Skill 文件，而非笼统报告"有错误"；
- 收敛判定：以"连续 N 轮（默认 3 轮）零失败"为退出条件，而非单次通过，防止偶然性通过掩盖系统性问题。
6. 多重防护机制 → 约束校验与恢复层
系统在多个层面建立了约束与恢复机制：
- 能力边界约束：G2 v5 的合法 Mark 类型、禁用的 V4 语法、非法 palette 名称等规则，全部显式写入 SKILL.md，从生成源头拦截幻觉；
- 输出格式校验：optimize-agent 在写入前校验 LLM 响应必须以 YAML Front Matter（
---）开头，非法响应直接丢弃而不写坏文件； - 迭代上限保护：最大迭代次数（默认 20 轮）防止死循环，触发上限后以非零退出码报警；
- dry-run 模式：支持只记录错误日志、不修改文件的调试模式，在验证 eval 流程正确性时不产生副作用。
关键洞察：这套 Harness 解决了什么
| 问题 | 传统做法 | Harness 做法 |
|---|---|---|
| LLM 幻觉（调用不存在的 API） | 人工审核 | SKILL.md 约束层 + 浏览器渲染验证 |
| 上下文过载 | 精简 Prompt | BM25 + grep 按需检索，只注入相关 Skill |
| 自评失真 | 无解 | Headless 浏览器环境化验证，拒绝 LLM 自判 |
| 错误修复靠人工 | 人工迭代 | analyze-agent 归因 → optimize-agent 自动重写 |
| 优化效果无法量化 | 主观感受 | 连续 N 次零错误的收敛指标，可度量可追踪 |
将"图表生成能力"从依赖单次 Prompt 质量，转变为一个可持续自我优化的闭环系统。模型的上限由预训练决定，但 Harness 决定了这个上限能被稳定发挥到什么程度。
评测数据：量化提升效果
基于 174 条图表生成用例的评测结果显示，相比走 Context7 方案（80% 成功率），Harness Engineering 方案取得了显著提升：
| 模型 | 算法 | 成功率 | 提升 |
|---|---|---|---|
| qwen3-coder-480b-a35b-instruct | tool-call | 98.2% | +18.2% |
| Kimi-K2.5 | tool-call | 97.7% | +17.7% |
| GLM-5.1 | tool-call | 93.6% | +13.6% |
| DeepSeek-V3.2 | tool-call | 87.3% | +7.3% |
| Context7 方案 | - | 80% | baseline |
证明了 Harness Engineering 的价值：同一模型在 Harness 加持下，能力释放程度大幅提升。
四、关键洞察：Harness Engineering 的核心价值
- 能力边界清晰划分：Prompt 解决 “说清楚”，Context 解决 “信息对”，Harness 解决 “持续做对”，三者层层递进，缺一不可；
- 包含关系明确：Harness 包含 Prompt 与 Context 工程，是更大系统边界的工程化，是 AI 从原型到产品的核心升级；
- 落地关键：模型决定上限，Harness 决定能否稳定落地，没有成熟的驾驭工程，再强的模型也无法在真实场景商用；
- 发展趋势：AI 落地挑战正从 “让模型聪明” 转向 “让模型稳定工作”，Harness Engineering 将成为 AI 工程化的核心竞争力。
五、结语
AI Agent 的竞争早已不是模型参数的比拼，而是工程化能力的较量。Harness Engineering 作为 AI 系统的 “稳定引擎”，正在重新定义 AI 落地的标准 —— 它不是模型的 “附属品”，而是让 AI 真正服务于业务的 “基础设施”。
如果文章对你有用，别忘了给个小星星。
