> **企业 AI 化的四层工程体系 · 第 ⑤ 篇**
> Harness 工程：让 LLM 从一颗 CPU，变成一台能干活的机器

---

## 引言：模型一样、prompt 一样、context 一样，结果却天差地别

设想两个团队，做同一个招投标分析 Agent。

他们用同一个大模型，调了同样水平的 prompt，甚至连 context 工程都做得差不多。可结果呢？A 团队做出的是一个惊艳的 demo——演示时行云流水，赢得满堂彩，但一上线就漏洞百出，三天两头崩。B 团队做出的，是一个稳稳跑在生产里、几个月不出大事的系统。

差距在哪？

不在模型，不在 prompt，不在 context。**差距在模型之外那一层看不见的东西——当工具调用失败时谁来重试，当模型胡说时谁来拦截，当输出结构错乱时谁来兜底，当成本开始失控时谁来踩刹车。**

这一层，就是本系列前几篇反复提到、却一直没展开的那个词——**Harness**。

它是让 LLM 从一颗孤零零的 CPU，变成一台真正能干活的机器的关键。没有它，再聪明的模型也只是个 demo；有了它，普通的模型也能撑起一个 production system。这篇文章，我们就来把这层最硬核、也最决定成败的运行时，彻底讲透。

---

## 一、先划一条线：Harness 管的是"模型之外的执行"

上一篇结尾，我们立了一条贯穿工程段的边界判据。这里再强调一遍，因为它正是理解 Harness 的起点：

> **Context 层，管的是"喂什么进模型"。**
> **Harness 层，管的是"模型之外的执行与兜底"。**

这条线把两层切得干干净净。Context 负责把对的信息组织好、送到模型嘴边；而信息送进去、模型吐出判断之后，**剩下的一切——工具怎么被执行、输出怎么被校验、失败怎么被恢复、成本怎么被控制——全归 Harness。**

给它一个定义：

> **Harness = Agent 的运行时系统（runtime layer），即模型之外、包裹着每一次模型调用的那一整套执行与兜底机制。**

这正好印证了本系列第一篇那个核心论断：**真正能上生产的 Agent，大部分是被精心工程化的传统软件，只在需要判断的精确位置插入 LLM。**在这个图景里，LLM 是一个"结构化转换函数"——自然语言进，结构化数据出；而它周围那一整圈确定性软件，就是 Harness。

所以有一句话值得刻在墙上：

> **没有 Harness 的 AI，是 demo；有 Harness 的 AI，是 production system。**

「12-Factor Agents」把这件事说得更绝：**即便 LLM 再聪明 100 倍，要上生产，你仍然需要确定性控制、schema 校验和上下文压缩。**换句话说，Harness 不是模型不够强时的临时补丁，而是无论模型多强都绕不开的结构。

一个完整的企业级 Agent，模型只是中间那一环，外面包着的全是 Harness 的部件：
![企业级 Agent 架构：Harness 包裹着每一次模型调用.png](https://developer.qcloudimg.com/http-save/yehe-7660620/7d2ca83f3f36a073387f72a2e95b3b76.png)

看清楚了：用户的请求先经路由，进入 Harness；Harness 调度工具、校验结果、读写记忆，最后产出。模型在哪里？它被嵌在 Harness 内部，只在需要判断时被调用一下。**模型是引擎，Harness 是整台车。**

那么，这层运行时具体要解决什么？答案是四个问题——四个会让 demo 死在生产里的问题。

---

## 二、Harness 要解决的，是四个让 demo 死在生产里的问题

为什么 demo 总是上不了生产？因为 demo 阶段，你只走"happy path（顺利路径）"——输入规规矩矩，工具次次成功，模型恰好不抽风。可一上生产，真实世界的混乱涌进来，四个问题会接连爆发：

1. **工具失败怎么办？**——API 超时、参数错误、返回异常。
2. **幻觉怎么拦？**——模型自信地编造了不存在的事实。
3. **schema 不匹配怎么办？**——模型吐出的结构不合规，下游程序全断。
4. **成本爆炸怎么办？**——Agent 在闭环里循环，token 像流水一样烧出去。

这四个问题，在 demo 里几乎都不会暴露，因为 demo 太短、太顺。但它们恰恰是生产环境的常态。

这就是 demo 骗人的地方：demo 是一条被精心挑选过的、不会出错的"顺路"。你演示时，输入是干净的、工具恰好都通、模型恰好没抽风、流程恰好一遍过。可生产环境是另一个世界——脏数据、超时的 API、格式诡异的文件、深夜流量高峰、千奇百怪的边角输入。**demo 测的是"它能不能跑通一次"，生产测的是"它能不能在一万次里稳定地不崩"。**这两者之间的距离，几乎全部由 Harness 填补。一个团队在 demo 上花了一周、却没在这四个问题上花过一天工程，结果几乎注定：演示惊艳，上线翻车。

**Harness 工程，本质上就是为这四个问题，分别建立"企业必须有的应对机制"。**下面，我们一个一个拆。

---

## 三、问题一：工具失败 —— 执行器 + 重试 + self-heal + 兜底

先看一个会让很多人意外的数字：Anthropic 在复盘自家 Agent 系统时发现，**工具调用失败出现在多达 36% 的对话里。**三分之一的交互，会在"调工具"这一环出岔子。

这意味着一件事：**工具失败不是例外，是常态。**一个把工具调用当成"必然成功"来设计的 Agent，注定在生产里频繁崩溃。

要处理好工具，先要理解工具在 Harness 里的本质。「12-Factor Agents」有一条很反直觉的洞察：**所谓"工具调用"，本质上就是模型产出一段结构化输出（structured output），再由确定性代码去执行它。**模型负责把"查一下这家供应商的资质"翻译成一个 typed 的函数调用，真正的执行是普通代码干的。想清楚这一点，你就不会指望模型"自己把工具用对"，而会把执行的可靠性交给工程。

如果不这么做，会发生什么？会发生最危险的一种崩溃——**级联失败。**一次工具调用失败了，如果 Harness 不拦，模型不会停，它会拿着这个失败（或者一个空结果、一段错误信息）当成"正常输入"继续往下走，在错误的地基上叠出一整套错误的结论。在招投标里，这可能是：竞品报价查询超时返回了空，模型却把"无竞品"当真，给出了一个毫无竞争力的高价建议。**失败本身不可怕，可怕的是失败被静默地吞掉、然后污染了后面的每一步。**所以 Harness 处理工具失败的第一原则不是"修好它"，而是"绝不让一个未处理的失败悄悄流到下一步"。

这里还有一条必须守的纪律（上一篇也提过）：**工具不是越多越好。**实测显示，可用工具从 3 个增加到 12 个，模型选对工具的准确率从 95% 暴跌到 70%。所以 Harness 要做受控工具集——按子任务暴露、描述清晰、宁可拆细也不堆杂。

那工具真失败了怎么办？Harness 要有一套分层的应对机制：

- **重试 + self-heal**：调用失败时，不要崩，把错误信息喂回上下文，让模型读懂错误、调整下一步——模型其实很擅长读 API 报错并自我修正。
- **三振机制**：但绝不无限重试。设一个计数器，连续失败几次（比如三次）就停手，转入兜底。
- **兜底 / fallback**：换一条路径——降级到缓存结果、切换到备用工具或备用模型、或者升级给人处理。

把它落到招投标：当"条款库检索"工具超时，Harness 先重试两次（把超时错误喂回去）；仍失败，则 fallback 到上一次的缓存结果，或标记该步骤需人工补充——而不是让整个流程卡死或胡乱往下走。
![工具失败的处理：重试 → 兜底 → 升级.png](https://developer.qcloudimg.com/http-save/yehe-7660620/2394b78756646c49b01ac78458f18328.png)

**记住：处理工具失败的能力，是 demo 和 production 最直接的分水岭之一。**demo 假设工具永远成功，production 假设工具随时会失败。

---

## 四、问题二：幻觉拦截 —— 用独立校验器，而不是让模型自评

第二个问题，是所有人都怕的幻觉（hallucination）：模型一本正经地编造了一条不存在的事实、一个不存在的法律依据、一份不存在的资质。

很多团队的第一反应是"让模型自己检查一遍"。**这是个陷阱。**让生成答案的同一个模型给自己打分，是 Agent 系统里最容易自欺的地方——它对自己的错误往往视而不见。

正确的做法，是在 Harness 层放一个**独立的校验器（Validator）**，用模型之外的、确定性的逻辑去拦。Anthropic 的做法就是典型：他们不让生成的 Agent 自评，而是用一个**独立的校验器逐条核对引用**——比如用代码去 grep，确认模型引用的每一条来源是否真实存在。

Harness 的校验器通常要做三类检查：

- **事实核对**：模型引用的来源、数据、条款，是否真实存在、可被追溯？
- **约束检查**：产出是否违反了硬性规则（比如报价是否突破了预算红线）？
- **一致性检查**：新结论是否和上下文里已有的状态相矛盾？

把这三类检查落到招投标：模型说"我方满足该项资质，依据是 ××认证"——**事实核对**会去证书库里查这张认证是否真的存在、是否在有效期；模型给出报价 880 万——**约束检查**会比对预算红线，超了直接拦；模型在风险段说"无重大合规风险"，但前面的历史决策里明明标了"待核实的合规疑点"——**一致性检查**会揪出这处自相矛盾。

还要说清楚：**校验器不一定是另一个大模型，更多时候它就是确定性的规则和代码。**能用代码查库、比对、做正则的，就别用模型；只有当校验本身需要语义判断（比如"这两段表述是否实质等价"）时，才考虑用一个独立的模型来做——但即便如此，也绝不是让生成答案的那个模型自己来。校验器越确定、越独立，拦截越可信。
![幻觉拦截：独立校验器（不让模型给自己打分）.png](https://developer.qcloudimg.com/http-save/yehe-7660620/6b6a1c36e867e3c617040a77741e7c90.png)

这正是上一篇拆解里"失败点"被工程化的地方。在招投标 Agent 里，每一条风险结论，都要被独立校验器拿去核对它引用的条款是否真实存在；编造的"依据"，在这一步被当场拦下，进不了最终报告。

**一句话：幻觉不能靠模型自觉，只能靠 Harness 在模型之外拦。**自评是自欺，独立校验才是工程。

---

## 五、问题三：schema 不匹配 —— 结构化校验 + 带错重试

第三个问题更隐蔽，却同样致命：**模型吐出的结构不合规。**

回想上一篇说的——Prompt 这一层负责约束输出格式，比如报价建议必须是一个包含"报价区间、依据、置信度、风险等级"的固定结构。但 prompt 的约束不是 100% 可靠的，模型偶尔会漏一个字段、写错一个类型、把 JSON 写崩。而下游的程序化处理（入库、校验、人工复核界面）是按固定 schema 写的——结构一乱，整条链路就断。

Harness 在这里要做的，是给输出加一道**结构化校验（structured output validation）**：每一次模型产出，都用预定义的 schema 去校验。不合规怎么办？**把校验错误喂回上下文，让模型带着"你漏了 X 字段、Y 类型不对"的反馈重试**——这又是一次 self-heal。

工程上，这一层有不少现成武器：function calling、JSON mode、constrained decoding（约束解码），都能大幅提高模型一次产出合规结构的概率。但即便用了它们，Harness 的校验和重试机制依然不能省——**它是最后那道保证"接口稳定性"的防线。**

所以你会看到一个漂亮的双保险：**Prompt 层用 schema 约束去"提高产对的概率"，Harness 层用 schema 校验去"兜住产错的情况"。**内环负责争取，外环负责兜底，两层配合，接口才真正稳。

招投标的例子很直接：报价建议产出后，Harness 立刻用报价 schema 校验；若缺了"风险等级"字段，就把这个具体错误喂回去让模型补全，而不是把一个残缺结构直接塞给下游。

---

## 六、问题四：成本爆炸 —— 预算 + 成本控制 + 可观测性

第四个问题，是最容易被忽略、却最能"惊喜"地烧掉预算的：**成本爆炸。**

Agent 的本质是在闭环里循环。而循环一旦没有约束，一次任务调用几十、上百次模型并不罕见。一个让人警醒的事实是：**连 Anthropic 这样的团队，都坦言至今缺少一个好用的"单次任务成本硬上限"方案**，只能靠禁止递归来杀掉最吓人的成本乘数。

Harness 必须为成本建立三道闸：

- **循环预算（loop budget）**：给每次任务设最大轮数、最大 token 上限，逼近就强制收尾或升级。这是防止"无限循环烧钱"的硬约束。
- **成本控制（cost control）**：按任务、按 agent 粒度追踪 token 消耗；并用 **fallback model routing**——简单的步骤用便宜的小模型，只有真正难的判断才上贵的大模型。这往往能省下惊人的开支。
- **可观测性（tracing）**：这是前三道的前提。没有 tracing，你根本不知道钱花在了哪一步、哪一步在打转、哪一步在反复失败。

把这三道闸落到招投标，就具体了：**循环预算**设成"单次分析最多 8 轮迭代、token 上限 N"，逼近就强制收尾并把当前结论交人复核；**成本控制**上，把"解析文件、字段抽取、格式整理"这类确定性步骤路由给便宜的小模型，只把"是否投标、报价与风险"这两个真正吃判断的决策点留给贵的大模型——光这一条路由策略，常常就能把单次任务成本砍掉一大半；**可观测性**上，给每一次招投标分析留一条完整 trace，事后能回放"它在哪一步多绕了三轮、为什么"。要知道，一个没有预算闸的研究型 Agent，遇到一个开放式难题时打转几十轮、单次烧掉数美元甚至更多，是真实发生过的事——成本闸不是锦上添花，是防止账单失控的保险丝。

可观测性这一块，业界已经长出了成熟的工具栈——AgentOps 这类**控制平面**提供实时监控、按 token 的成本可视化、会话回放（session replay）、乃至"时间旅行式"的逐步调试。它们让一个原本是黑箱的 Agent，变得可追溯、可审计、可优化。
![成本与可观测性：Harness 的四道闸.png](https://developer.qcloudimg.com/http-save/yehe-7660620/3141af2f77d101b907ef6f54c6afb4e9.png)

还有一条针对多 Agent 的成本铁律（第一篇提过）：**绝不能让子 Agent 再生子 Agent。**递归繁衍是成本失控最吓人的乘数，这个限制要在 Harness 的编排层用代码强制，而不是在 prompt 里"求"模型别这么干。

---

## 七、Harness 是"在模型几乎成功的边界上做可靠"——一个真实案例

讲完四个问题，你可能会问：Harness 听起来像是一堆补丁，它的工程哲学到底是什么？

「12-Factor Agents」给了一句精准的总结：**在模型"几乎能成功"的边界上，用工程把它做可靠。**模型有八成把握、但偶尔翻车的地方，正是 Harness 用重试、校验、兜底去补上那两成的战场。Harness 不创造智能，它把智能变得可靠。

而这件事有多硬？看一个真实案例就懂了。知识管理平台 Notion，为了把企业级 Agent 真正推上生产，**前后花了数年、把整套 Agent 基础设施彻底重建了四到五次**，最终才打磨出一套生产级的 harness——里面包含渐进式工具暴露（progressive tool disclosure）、类 SQL 的数据抽象、为模型消费优化的 markdown 接口，以及完整的评估框架。

这个案例传递了一个对企业极其重要的信号：**Harness 不是买个框架、连几根线就有的，它是要持续工程化、反复打磨的硬骨头。**那些以为"接个编排框架就完事"的团队，往往就栽在这里——框架给你的是积木，而把积木搭成一个在真实混乱中不崩的系统，是 Harness 工程的真功夫。

为什么连 Notion 这样的团队都要重建四五次？因为 Harness 的难，不在于单个部件——重试、校验、tracing 单拎出来都不复杂——而在于**它们必须在真实流量的千百种组合下协同工作**，而这些组合你在设计时根本想不全。第一版总是漏掉某类失败，第二版又在成本上栽跟头，第三版的校验拦截了太多正常输出……每一次重建，都是把上一次在生产里学到的"原来这里也会崩"沉淀进架构。这给企业的忠告很直接：**给 Harness 留足迭代的预期和耐心，别指望一版到位；也别把它当成一次性的"集成工作"，它是一条要长期养护的生产线。**真正的护城河，往往就藏在这些别人不愿反复打磨的脏活里。

把 Harness 放回那张同心圆：它**往内**包裹着 Context 和 Prompt（为它们供给可靠的工具输出和执行），**往外**被 Loop 驱动（Loop 决定什么时候调用它、循环到何时停），同时它产生的每一步留痕，又**向外**喂给 Eval 去度量。它是整台机器真正"干活"的那一层。

---

## 结论：用四个问题，给你的 Agent 验明正身

这篇文章想留给你的，是一把可以立刻拿去用的"验机"尺子：

> **拿你的 Agent 出来，问四个问题——工具失败有没有重试和兜底？幻觉有没有独立校验拦截？输出有没有 schema 校验？成本有没有预算和追踪？**

四个问题，只要有一个的答案是"没有显式机制"，那它大概率还只是个 demo，而不是 production system。把本篇的核心判断收成一句话：

> **没有 Harness 的 AI 是 demo，有 Harness 的 AI 是产品；而 Harness，就是为"工具失败、幻觉、schema 错乱、成本爆炸"这四个问题，建立模型之外的执行与兜底。**

如果你是技术决策者，现在就可以推动团队做一次"Harness 体检"：把这四道机制逐一对照现有系统，缺哪补哪。这往往比再调一百遍 prompt、再等一个更强的模型，更能决定你的 AI 项目能不能真正上线。

最后，留一个问题，作为下一篇的引子：

Harness 给了我们一堆可靠的执行积木——可靠的工具调用、可靠的校验、可靠的兜底。可是，**到底是谁在决定"这一步该调哪个积木、下一步往哪走、循环到什么时候该停、状态如何随每一步演进"？**是什么东西，把这些静态的积木，驱动成一个真正"持续运转、自我推进"的系统？

这个驱动整台机器的外环，正是让 Agent 区别于一次性调用、真正具备"智能"的来源。它叫 Loop。如何设计它，正是本系列**第⑥篇《Loop 工程：Agent 真正"智能"的来源》**要深入的内容。

我们下一篇见。

---

*本文为「企业 AI 化的四层工程体系」系列第 ⑤ 篇。我们已经走过 Prompt、Context、Harness 三层——模型怎么思考、基于什么思考、模型之外如何可靠执行。下一篇，我们走到最外环，看看是什么在驱动整个闭环持续运转。*

企业 AI 化的四层工程体系 · 第 ⑤ 篇 Harness 工程：让 LLM 从一颗 CPU，变成一台能干活的机器

Harness Engineering —— 企业AI系统的真正核心

同样接入大模型，凭什么有人做出 demo，有人做出产品？差距在模型之外那层看不见的运行时——Harness。本文用四个"让 demo 死在生产里"的问题，带你看清这层最硬核、却最决定成败的工程。

资深架构师

人工智能

后端

架构设计

企业AI化的关键在Harness工程，它解决工具失败、幻觉拦截、结构校验和成本控制四大生产难题。通过重试机制、独立校验器、结构化兜底和预算管理，将LLM从演示原型升级为稳定系统。Harness层决定AI能否真正落地，是区分demo与产品的核心要素。

结构化数据

路由

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Harness Engineering —— 企业AI系统的真正核心-腾讯云开发者社区-腾讯云

Harness Engineering —— 企业AI系统的真正核心

Harness Engineering —— 企业AI系统的真正核心

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐