一个被炒热、却说不清的词

最近"驾驭工程（Harness Engineering）"这个词开始被频繁讨论——OpenAI 在 Codex 实践里、Anthropic 在 agent harness 的描述里、Martin Fowler 的文章里都在谈它。

但概念听多了，会冒出一个很实际的疑问：

道理我都懂，可是落到我每天做的活儿里——到底哪些具体动作，才算"驾驭工程"？

这篇就回答这个问题。不停在概念层面，而是把它拆成一张可对照的动作清单：你做了哪些，就说明你已经在做驾驭工程了。

---

先给个锚：驾驭工程到底是什么

一句话：

驾驭工程 = 给 Agent 搭"轨道、仪表盘、刹车、记忆、质检和交付流水线"。

它和另外两个 “engineering” 的分工很清晰：

	解决什么
Prompt Engineering	怎么"说"——怎么问模型
Context Engineering	给它"看什么"——喂哪些上下文
Harness Engineering	它如何在真实系统里一步步工作、被约束、被验证、失败恢复、留下证据

Martin Fowler 的说法也是一个意思：harness 给 Agent 提供 feedforward guides 和 feedback sensors。

它的本质不是"让模型更聪明"，而是"让模型在一套被设计好的轨道里可靠地工作"。

---

落到实处：哪些动作算驾驭工程

下面这些，是我自己结合实际工作梳理出来的。每一条都不讲大道理，都是能直接对照"我做没做"的具体动作。

1. 任务入口标准化

把用户请求先转成标准化的格式（task_object / goal / deliverable / constraints / time_horizon），而不是丢给模型自由发挥。

关键在于：自然语言需求 → 具体可执行的操作清单。模型不是从一句模糊的话开始猜，而是从一张明确的任务单开始干。

2. Agent 编排路由

让一个 Agent 去判断、拆解任务，决定交给谁、谁依赖谁、怎么合并——而不是指望一个 Agent 包打天下。

Harness 的职责是把模型能力组织成工作流，而不是让单个模型扛所有事。

3. Prompt / Skill 文件化

把系统规则、操作步骤、专家能力拆成文件（AGENTS.md、skills/*.md），按业务情况分模块——而不是把所有东西塞进一个巨型 prompt / 巨型 skill。

不是"一个 skill 放下所有内容"，而是根据业务拆分。

4. 工具权限控制

控制哪些 Agent 能用哪些工具：能不能写文件、能不能调外部 API、哪些操作要用户确认。

这点 Claude Code 里其实就有类似设计：能读重要文件的 Agent，就不该再有写文件的能力；干执行活的 Agent，就不该配置读重要内容的能力。
把 Agent 从"什么都能做"变成"在权限边界内做事"。

5. 状态管理

记录任务进度、已完成步骤、失败原因、用户确认结果。

这一条特别强调跨上下文窗口的承接——否则下一轮 Agent 根本不知道前面发生了什么，长任务就没法完成。

6. 数据持久化

把长数据产出变成固定的文件格式存下来，变成 Agent 可读的"产物"。

产物不是聊天里飘过去的一段话，而是可被下一步读取、可被复用的资产。

7. 验证机制

对产出的内容（SQL、回测、规则……）做校验，而不是默认它对。

8. 反馈链路

针对出现的问题，有一套良好的反馈机制帮 Agent 修复。这里有两个我觉得最关键的点：

• 语义化：输出的报错/反馈信息，要是"模型好理解、且能据此纠错"的内容——而不是一行裸 traceback。
• 问题的清晰定位：失败是 API 问题、模型幻觉、任务理解错、上下文缺失、还是权限不足？定位不一样，解法就不一样（重试 / 降级 / 转人工）。把这几类分开，Agent 才不会对一个"数据本来就没有"的情况傻乎乎重试五次。

9. 可观测性

记录每一步 tool_call 的输入输出、用时、token 数、成本、错误、命中的数据源——让 Agent 能根据可观测信号，在限制内更好地完成任务。两个我额外想强调的：

• 让模型知道自己当前耗了多少时间、多少 token——它才能在预算内自我调节。
• 时间的获取，不应该靠提示词变量注入，而该有个工具让 Agent 自动获取——这样更准、也更干净。

10. 评估集与回归测试

建立典型用户请求集合，系统化地看：理解问题准不准、输入合不合理、输出满不满足条件、改完有没有提升。

核心是靠专业的评估系统去看 Agent 好不好，而不是靠人为感觉。这相当于给 Agent 系统做 CI/CD。

11. Harness 模板化

把已经跑通、沉淀下来的东西模板化——比如"个股深度研究 harness"“策略回测 harness”“报告生成 harness”，不同任务类型各有一套可复用的轨道。

---

把这些动作串起来，就是一条链路

单看每个动作是点，连起来才是驾驭工程的全貌：

用户问题
  ↓
任务理解 / 意图识别          ← 任务入口标准化
  ↓
澄清判断 / 用户确认
  ↓
任务规划 / Plan 结构化       ← 状态管理、数据持久化
  ↓
Agent 路由 / 多 Agent 编排   ← 编排路由
  ↓
上下文装配 / 工具授权        ← Skill 文件化、工具权限控制
  ↓
Agent 执行                   ← 可观测性全程记录
  ↓
验证 / 事实核查 / 风险检查    ← 验证机制
  ↓
失败归因 / 自动修正          ← 反馈链路（语义化 + 清晰定位）
  ↓
最终交付 / 留痕 / 进评估集    ← 评估集与回归测试、模板化

这整条链路，才叫 Harness Engineering。

---

和 Prompt Engineering 的边界

为什么说它不是"写个更好的 prompt"？一张表看清区别：

	Prompt Engineering	Harness Engineering
关注点	怎么问模型	怎么让 Agent 稳定完成任务
产物	Prompt、示例、角色设定	工作流、工具、权限、状态、验证、日志、回归测试
范围	单轮 / 局部对话	多轮、多工具、多 Agent、长任务
质量保障	靠提示词约束	靠系统机制 + 自动验证 + 人类干预
失败处理	改 prompt	记录失败、归因、重试、修正 harness

---

收尾：它的本质是"控制系统"，不是"更聪明的模型"

回到开头那个问题——哪些事算驾驭工程？

答案其实就藏在你已经在做的活里：任务结构化、路由编排、skill 文件化、权限控制、状态记忆、过程观测、结果验证、反馈修正、评估回归…… 这些你以为"理所当然"的工程动作，合起来就是驾驭工程。

它不优化"单次回答有多漂亮"，它设计的是一套让 Agent 稳定工作的控制系统——让模型从一个"一次性生成器"，变成一个可控、可审计、可复用、可持续优化的生产级执行系统。

一句话：驾驭工程不是让模型更聪明，是给它搭一张能可靠干活的工作台。