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

> **企业 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 的部件：  看清楚了：用户的请求先经路由，进入 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 到上一次的缓存结果，或标记该步骤需人工补充——而不是让整个流程卡死或胡乱往下走。  **记住：处理工具失败的能力，是 demo 和 production 最直接的分水岭之一。**demo 假设工具永远成功，production 假设工具随时会失败。 --- ## 四、问题二：幻觉拦截 —— 用独立校验器，而不是让模型自评 第二个问题，是所有人都怕的幻觉（hallucination）：模型一本正经地编造了一条不存在的事实、一个不存在的法律依据、一份不存在的资质。 很多团队的第一反应是"让模型自己检查一遍"。**这是个陷阱。**让生成答案的同一个模型给自己打分，是 Agent 系统里最容易自欺的地方——它对自己的错误往往视而不见。 正确的做法，是在 Harness 层放一个**独立的校验器（Validator）**，用模型之外的、确定性的逻辑去拦。Anthropic 的做法就是典型：他们不让生成的 Agent 自评，而是用一个**独立的校验器逐条核对引用**——比如用代码去 grep，确认模型引用的每一条来源是否真实存在。 Harness 的校验器通常要做三类检查： - **事实核对**：模型引用的来源、数据、条款，是否真实存在、可被追溯？ - **约束检查**：产出是否违反了硬性规则（比如报价是否突破了预算红线）？ - **一致性检查**：新结论是否和上下文里已有的状态相矛盾？ 把这三类检查落到招投标：模型说"我方满足该项资质，依据是 ××认证"——**事实核对**会去证书库里查这张认证是否真的存在、是否在有效期；模型给出报价 880 万——**约束检查**会比对预算红线，超了直接拦；模型在风险段说"无重大合规风险"，但前面的历史决策里明明标了"待核实的合规疑点"——**一致性检查**会揪出这处自相矛盾。 还要说清楚：**校验器不一定是另一个大模型，更多时候它就是确定性的规则和代码。**能用代码查库、比对、做正则的，就别用模型；只有当校验本身需要语义判断（比如"这两段表述是否实质等价"）时，才考虑用一个独立的模型来做——但即便如此，也绝不是让生成答案的那个模型自己来。校验器越确定、越独立，拦截越可信。  这正是上一篇拆解里"失败点"被工程化的地方。在招投标 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，变得可追溯、可审计、可优化。  还有一条针对多 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 三层——模型怎么思考、基于什么思考、模型之外如何可靠执行。下一篇，我们走到最外环，看看是什么在驱动整个闭环持续运转。*