为什么它会成为"第三次工程化"？

近几个月，如果你在关注 AI 工程圈的讨论，一定会听到 Harness 工程这个词。

不少文章把它神化了。但说老实话，它其实就是一个必然的阶段。

让我用一个框架来解释这个必然性，以及为什么作为独立开发者或创业团队，你现在应该开始关注它。

三次工程化的演进脉络

第一次：Prompt 工程（让模型听懂你）

2022-2023 年，ChatGPT 出来了。大家都在做一件事：怎么写提示词让模型给我想要的回答。

这是对的。Prompt 工程解决的是一个最基础的问题：人-模型的沟通问题。

但它有个缺陷：每次都是一轮对话。你给一个 Prompt，模型给一个回答，完事儿。

对于简单的任务（写文案、改代码段、翻译文章），这够了。但如果你要做一个需要多步骤、需要判断、需要容错的系统，Prompt 工程就开始暴露瓶颈了。

一旦加入时间、上下文、外部数据的依赖，Prompt 工程的天花板就出现了。

第二次：Context 工程（让模型拿到对的信息）

2023 年下半年开始，大家发现了一个规律：给模型的信息质量，往往比 Prompt 怎么写更重要。

于是 RAG（检索增强生成）、向量数据库、分割策略、检索排序，这些技术开始被广泛讨论。

Context 工程的核心思想是：与其反复调 Prompt，不如确保模型看到的上下文是对的。

这个阶段确实解决了一大类问题。特别是对于有明确知识库的应用（客服、文档 QA、行业咨询），Context 工程能明显提升准确率。

但这里又出现了第二个矛盾：

即使信息是对的，模型也不一定能稳定地利用它。

特别是当系统要做编排、决策、工具调用时，单纯提升 Context 质量，还不够。你需要的是整个系统的逻辑健壮性。

第三次：Harness 工程（让系统在真实环境里可控、可测、可迭代）

这就引出了 Harness 工程。

如果说 Prompt 工程是"和模型聊天"，Context 工程是"给模型喂数据"，那 Harness 工程就是"给系统装上方向盘和刹车"。

Harness，英文字面是"采集、驾驶、掌控"。它的核心不是让模型更聪明，而是让 Agent 系统可以在生产环境里安全、稳定、可观测地运行。

三个维度：

1. 任务维度：定义清晰的任务边界、成功标准、失败回退策略
2. 执行维度：工具编排、状态管理、重试机制、超时处理
3. 治理维度：离线评测、在线监控、版本管理、成本与风控

为什么现在必须做这个阶段

作为一个做过几个 AI 项目的独立开发者，我见过很多项目卡在同一个地方：

Demo 非常惊艳，但一旦上线，就开始掉坑。

原因往往不是模型不够强，而是系统没有预案。

比如：

• Agent 决策了半小时还没结果，怎么办？
• 工具调用返回了一个脏数据，模型吞了，怎么办？
• 三个 Subagent 互相反复, 陷入死循环，怎么办？
• 成本莫名其妙翻了 10 倍，怎么发现？

这些不是 Prompt 问题，也不是数据库问题。这是工程问题。

Harness 工程的目的，就是把这些问题从线上故障，变成线下可测试的 case。

一个可执行的框架

如果你要开始做 Harness 工程，我建议从这三步开始：

第一步：写任务契约

在你写一行 Agent 代码前，先定义清楚：

1
2
3
4
5

任务名称：xxx
输入格式：（schema）
输出格式：（schema）
拒答边界：什么条件下必须说"我不确定"而不是瞎编
成功标准：什么叫一个好的结果

这听起来有点麻烦，但它会救你的命。因为一旦定义清楚了，你就知道怎么写评测 case。

第二步：补齐失败路径

最常见的失败场景：

• 超时：设置 deadline，到点就中断，返回"下次再试"
• 工具失败：有没有降级方案，缓存方案，人工兜底方案
• 决策偏航：有没有"我好像走错了"的自纠正
• 成本爆炸：是否限流，是否降低采样

把这些都想清楚，失败就不再是"惊吓"，而是"计划之内"。

第三步：建立观测

• 离线评测：收集 10-30 个高风险样本，定期跑评测集
• 在线指标：成功率、平均延迟、成本、人工接管率、用户投诉率
• 版本管理：确保能快速回滚，而不是裸奔上线

这三个东西一起才叫"Harness"。没有观测，你就盲飞。

现在就该开始的理由

我给你三个信号，判断你是否已经进入需要 Harness 工程的阶段：

1. 你开始谈 SLA（成功率 99%，延迟 <2s），而不是只说"效果还不错"
2. 你有线上回退计划，而不是"改个 Prompt 试试"
3. 你关注稳定收益，而不只是首轮的效果惊喜

如果这三个中有任何一个是真的，那你就已经进入 Harness 工程的范畴了。

对独立开发者/小团队的建议

我知道很多人听到"工程"就头大。但 Harness 工程其实不难，关键是思路对。

你不需要：

• 大团队
• 复杂的基础设施
• 事先投入很多时间

你需要：

• 在写 Agent 逻辑之前，先想想"会怎么失败"
• 用简单的文本或 CSV 做离线评测
• 用一个简单的 dashboard（比如 Google Sheets）记录关键指标

一个人，一周时间，就能搭出一个最小可用的 Harness 框架。

小结

Prompt 工程决定你能不能开始。

Context 工程决定你跑得快不快。

Harness 工程决定你能不能长期活下来。

如果你现在还只在调 Prompt，也不用急。但如果你的 Agent 已经进入生产阶段，是时候开始思考 Harness 了。

不是为了创意，是为了稳定。