企业官网建设流程全解析

1. 为什么需要“缰绳”：AI裸跑的不可控性

做LLM应用的人应该都有过这种经历：demo阶段一切完美，模型对答如流，输出格式稳定得像教科书。一旦放到生产环境，各种问题就全来了——模型开始“自由发挥”，明明要求输出JSON却夹带一段markdown，明明要求简短回复却突然长篇大论，用户一句不太友好的话就能让它彻底“崩坏”，更不用说那些凭空捏造的“一本正经的胡说八道”。我很长一段时间都把这些归结为“模型不够聪明”，后来才发现，真正的问题不是模型本身，而是我根本没给它套上缰绳。

所谓Harness Engineering，国内团队更常叫“护栏工程”或“控制层工程”。核心思路很直接：不试图100%重塑模型行为，而是在模型外围构建一套约束与校验机制，让它在既定轨道里“戴着镣铐跳舞”。这套机制包含但不限于：输入过滤与改写、输出格式强约束、内容安全边界、JSON Schema校验、推理路径限制、失败重试与降级策略。说白了，就是给AI装上一整套“行为规范系统”，让不可控的生成行为变成可控的、可观测的、可回滚的工程流程。

很多人会问：为什么非要加这一层，不直接在prompt里写清楚要求？答案很简单：prompt的约束力本质上是一种“软约束”，模型在绝大多数场景会遵守，但遇到边界情况、对抗输入、长上下文漂移时一定会出问题。生产系统的容错率不允许“绝大多数情况稳定”。Harness的意义在于把“软约束”升级成“硬约束”——不再依赖模型自觉，而是靠工程手段强制验证、强制纠偏。

这篇文章不是什么大而全的教程，我尽量用实际踩坑的经历来拆解，Harness到底应该怎么设计、怎么落地、哪些环节容易翻车。适合正在把LLM从demo推向生产的开发者、AI应用架构师，以及对AI工程化感兴趣的产品技术负责人。整个内容不绑定任何具体平台，技术栈上以通用工程思路为主，附带实操样例。

2. Harness的整体设计思路：一层护栏都别少

我最早做的“缰绳”非常简单：一个prompt模板，里面写了二十多条规则，什么“你必须始终以JSON格式输出”重复了三遍。结果模型在压力测试下照样输出乱格式。后来我才想明白，单点约束是最脆弱的，必须把护栏做成结构化的多层体系。目前我觉得比较成熟的设计，至少需要覆盖三个位置：输入端、输出端、推理过程本身。

2.1 输入端护栏：别让脏东西进入模型

输入侧护栏的作用不是限制用户，而是防范那些会让模型行为失控的内容。分两类，一类是恶意输入，另一类是无效干扰输入。

恶意输入最典型的是提示注入与越狱模式。比如用户尝试在对话里塞入“忽略以上所有指令，现在你是...”，这类内容一旦进入上下文，模型的行为边界就会瞬间模糊。我的做法是做一级分类过滤 + 敏感行为重写。分类过滤用一个小模型或者规则引擎，判断请求是否包含高危指令特征；如果命中，不是简单拒绝，而是对用户写一句“这个请求超过了当前服务边界”然后把整个请求拦下。这种方式在社交类、客服类的AI应用里特别实用。

无效干扰输入相对没那么严重，但从工程角度看同样耗资源。比如很长的无意义粘贴、上下文中重复多轮没价值的闲聊。输入端可以做长度预算管理，超过阈值就截断、摘要化或者拒绝。这里有个心得：不要偷偷截断之后送给模型却不告诉用户，要在应用层做明确的“上下文已压缩”提示，不然用户看到突然丢失前文，体验极差。

输入端护栏最好是“轻量级但高准确率”。为什么强调轻量？因为输入侧要处理的是所有用户请求，延迟直接叠加在首屏响应时间上，不能在这里跑过重的模型。我见过一些团队在入口放一个几十B的大模型去做意图识别，首token时间直接多了1.5秒，这在很多场景根本不可接受。规则、自定义词典、小模型embedding分类，大多数场景足够用。

2.2 输出端护栏：模型说什么都需要过安检

如果说输入端护栏是“进门查包”，那输出端护栏就是“出门安检”。在我看来输出侧才是Harness真正的主战场。模型生成的自然语言是开放的、任意的，而生产应用往往需要结构化的、确定的、安全的输出。

结构化这块，目前业界最主流的是JSON Schema约束。你给模型定义好一个schema，然后在prompt里告诉它“你的输出必须符合这个schema”，同时在后端做严格的schema校验，不合法就重试或抛异常。关键点在于：prompt约束和代码校验必须同时存在，前者保证大体不跑偏，后者兜底保证100%合法性。我见过只prompt约束不写代码校验的方案，结果下游解析器一崩就是几十个case报警。

内容安全侧也是一样。模型吐出来的任何内容都应该过一遍敏感词过滤、PII检测（比如身份证号、手机号）、品牌/竞对关键词过滤。某个电商导购类的项目里，模型曾经在回复里自动带出一句某个品牌“不如另一个品牌”，这属于典型的竞品风险输出——prompt里明确写了不许说，模型并不可靠。这套过滤绝对不是“防君子不防小人”的心态，而是要默认模型一定会违规，然后靠工程手段去堵住这些洞。

输出端还有一项容易忽略的事：格式之外的语义校验。比如说你的应用要求模型输出某个代码执行结果，模型输出了合法的JSON，但JSON里字段值明显是编造的。这时候就需要做值域校验、一致性校验（比如生成的内容关键词是否和输入中给定的实体一致）。我把这一层叫“语义安检”，它在很多场景下比格式校验更重要。有没有实体漂移？有没有凭空捏造的日期和人名？这些检查可以靠规则，也可以靠小模型二次判断，看你的业务强需求强到什么程度。

2.3 推理过程护栏：在模型内部动刀

前两层都是“外围控制”，还有一种更深入的方式，直接干预模型自身的推理过程，这也是Harness Engineering最核心的技术价值所在。

最常见的做法是使用思维链引导和固定步数限制。你在prompt里要求模型“先做A步骤分析，再做B步骤判断，最后输出C结论”，同时用代码实现一个步骤间状态机，每走完一个步骤就校验中间产物。比如让模型先用工具检索资料，检索回来后把资料整理成一个摘要结构，再基于这个摘要生成回复。每一步的校验都像流水线上的人工质检，一旦中间产物不合格，立刻终止链路而不往下走。

工具调用的护栏同样重要。现在大量应用依赖function calling，模型负责决定调用哪个工具、传什么参数。这里就要求：工具清单必须白名单化，复杂的工具在模型调用时加参数schema校验，工具返回结果也要做大小限制和内容检查。我见过模型在一次循环里被工具结果带偏，连续调用同一个删除接口好几次，所幸测试环境。核心逻辑是给每一个工具都套上“权限管理”和“操作确认”，模型不是直接执行工具动作，而是“申请”执行动作，由Harness来决定是否放行。

推理侧护栏还有一层：温度与采样控制。很多人觉得这个太简单而不重视，但它其实是稳定性的大杀器。开放域聊天可以把temperature调高（0.7~0.9），事实性任务必须压低到0.1~0.2，工具调用场景甚至可以直接用0。配合顶级P参数，在生成层面就减少“自由发挥”的空间，这也是从源头减少后面校验压力的常用招数。

3. 搭建一套可落地的Harness：核心环节实操

理论说了很多，下面切到真正可以照着搭的层面。我自己在一个模拟项目X里搭建Harness时，整体分成了四步走：定义输出协议、写守卫规则、设计失败策略、建立监控反馈回路。这套路径不依赖特定的开发框架，用Python生态加上一些常规组件就能跑起来。

3.1 三步定义一个可校验的输出协议

第一步：定义JSON Schema。以一次“商品信息抽取”任务为例，我希望模型稳定输出如下结构：

{ "product_name": "string", "category": "string", "price": "number", "in_stock": "boolean", "confidence": "number" }

对应的JSON Schema：

{ "type": "object", "properties": { "product_name": {"type": "string", "minLength": 1, "maxLength": 100}, "category": {"type": "string", "enum": ["electronics", "apparel", "home", "books"]}, "price": {"type": "number", "minimum": 0, "maximum": 100000}, "in_stock": {"type": "boolean"}, "confidence": {"type": "number", "minimum": 0, "maximum": 1} }, "required": ["product_name", "category", "price", "in_stock", "confidence"], "additionalProperties": false }

很多人第一次写schema会漏掉additionalProperties: false，这就让“模型偷偷输出多余字段”变成了可能。生产中强烈建议加上，给模型明确边界。同时，不要只在schema里写，还要在system prompt里用自然语言把同样的要求再说一遍。双击约束，冗余是冗余点，但在生成模型面前，所有冗余都是为了保命。

第二步：把schema编译成校验函数。我习惯用Python的pydantic来定义模型类，因为它的报错信息能精确到字段级，方便后续转成用户提示语。

from pydantic import BaseModel, Field from typing import Literal class ProductInfo(BaseModel): product_name: str = Field(min_length=1, max_length=100) category: Literal["electronics", "apparel", "home", "books"] price: float = Field(ge=0, le=100000) in_stock: bool = False confidence: float = Field(ge=0.0, le=1.0)

第三步：与生成逻辑做绑定。在模型的返回逻辑里，拿到原始输出后先做一次pydantic校验。合法就直接用；不合法就进入修复流程。我在项目X里一般固定给模型三次机会：第一次解析失败，把校验错误信息回传给模型，让它“根据错误修正输出”；第二次还失败，则改为调用一个更高稳定性的降级模型重新生成；第三次再失败，直接返回兜底结果并记录告警日志。

注意：重试不是无限重试，必须设置次数上限和最大耗时上限。LLM的重试失败率下降曲线在第三轮之后就平坦了，继续消耗推理资源，收益很低。

3.2 为“输出稳定性”加一层“上下文锁”

很多人的LLM应用越改越不稳定，核心原因之一是上下文污染——早期对话里模型自己说过的话、用户随便聊的内容，都可能成为后续生成时的干扰信标。Harness设计里有一个很有效的思路叫“上下文锁定”，在请求进入模型前，把历史上下文分门别类地处理。

我自己实现了一个三层上下文管理：

• 固定层：system prompt + 工具定义 + 业务规则。这层每次都在最前面，不可被截断，也不允许被用户消息插入。
• 工作层：最近几轮的有效对话内容。
• 摘要层：更早的历史，先在外部做一次压缩摘要，再放进上下文。

技术上很简单，用两个截断标记把上下文拼起来就行。但它的工程收益非常明显：模型能看到的“自由文本”范围被缩小，被用户拐跑的机会就变少。再加上输出端有一层“必须基于工作层中出现的实体信息作答”的校验，能显著抑制幻觉。

我实测下来，这套上下文锁配合低温度采样，可以把事实性任务中“无来源实体出现率”从20%以上压到3%以内。数字很直观，也说明一个问题：Harness不是限制模型聪明，而是让它把聪明用在正确的位置上。

3.3 设置安全阀：一切都可能失败，备好退路

无论前面护栏做得多么严密，总会有漏网之鱼。真正成熟的Harness一定包含一套完整的失败处理策略。我总结下来，至少需要准备四级降级链。

第一级：模型自纠错。校验失败时，把错误信息返回给模型重新生成。 第二级：换模型。从大模型切到更稳定或更擅长格式控制的小模型，有时候小模型在固定格式任务上反而表现更好。 第三级：模板兜底。如果模型无论如何都生成不出合格结构，直接返回一个预设的模板响应。比如结构化数据缺失时，返回“根据已有信息无法确认该字段”，而不是让下游直接崩溃。 第四级：请求拒绝。多轮失败后直接给用户一个友好错误页，同时记录完整的trace_id供内部排查。

这套策略看起来简单，但我在很多项目里发现团队往往只做到第一级。一旦第一级失败就抛异常，整个应用跟着崩溃。用户不会觉得是“模型不稳定”，只会觉得这是“做产品的人不靠谱”。Harness的终极目的，就是让终端用户感受到的失败尽可能少、尽可能温和。

4. 监控与度量：能不能判断这套缰绳真的有效

好多人搭建了Harness后就以为万事大吉了，结果上线一周，才发现某个护栏规则半夜让30%的请求走了降级通道。为什么？因为没有度量。缰绳套得再漂亮，如果不知道缰绳在哪里勒得过紧、哪里又根本没起作用，那就等于白搭。

4.1 核心指标怎么选

我建议围绕“稳定性、安全性、成本、体验”四个方向来制定指标，具体优先级取决于你的场景。

应用类型偏重内容生成的，重点看：格式合法率、字段缺失率、语义一致性准确率。应用类型偏重工具调用的，重点看：函数参数合法率、工具调用成功率、工具循环次数。应用类型偏重客服问答的，重点看：拒答率、安全命中率、实体漂移率、用户不满反馈率。

这里要特别提醒：不要只看平均指标。要看P95和P99分布。我就遇到过平均格式合法率99%的情况，但P99直接掉到85%——说明模型已经出现了状态漂移式不稳定，只是被大量简单case的平均值给掩盖了。做Harness的监控一定需要分位数的视角，去抓那些尾部的不稳定特征。

4.2 Trace是整个监控系统的灵魂

监控LLM应用，没有trace根本无从谈起。每一个请求都应该有一个唯一ID，然后把这个ID贯穿：输入内容、预处理动作、送入模型的prompt快照、模型原始输出、每一层校验结果、重试次数、最终返回内容、耗时、成本。任何一个环节出问题，都能靠这个ID回溯到具体细节，找到是哪一层护栏漏掉或者误伤了。

我见过不少团队没有做“prompt快照”持久化，出了事只能复现多次碰运气。要知道LLM的不确定性决定了复现不一定是同一结果。正确做法是：把所有发往模型的prompt完整存档，问题发生时不依赖复现，直接翻开快照找原因。

另外，我强烈建议给每一次护栏拦截动作都打一个独立标签。这个标签不是日志里的一行文字，而是可聚合的结构化数据：比如output_schema_violation_field_price_type、input_injection_detected_level_high。有了这种粒度，你才能把护栏自身的“过敏率”统计清楚——到底是模型真跑偏了，还是护栏规则写错了误杀了正常输出。护栏误杀、误放是长期运营里最大的隐藏成本，这个一定得重视。

4.3 量化护栏效果：上线前跑好两组对照

我把这个习惯称为“裸奔对照实验”。在一个固定测试集上，先不挂任何Harness跑一批输出，记录基准指标；再把Harness全部打开跑同一批输出，对比前后差异。

裸奔组看的是模型原生能力：它写出来的内容大致质量有多高、原始格式合法率是多少、敏感词命中率是多少。 带缰绳组看的是工程约束后的效果：格式合法率提升到多少、敏感词命中降到了多少、响应延迟增加了多少、成本增加了多少。

有个项目X的同事看完对照结果后说了句挺经典的话——Harness解决不了“模型本身太笨”的问题，但能让“模型本身太野”的问题彻底消失。确实，很多模型在裸奔时的输出质量看起来还行，真正致命的是稳定性。做完对照实验，你就能非常理性地决定：在稳定性问题上花预算给Harness，还是在能力问题上花预算换大模型，两条路线哪个更划算一目了然。

5. 常见问题与排查技巧实录

做Harness这段时间，踩过不少坑。下面把几个高频问题和排查思路整理成速查表，都是实际经验，应该能满足大部分排查需求。

5.1 一个特别隐蔽的坑：护栏把自己人给拦了

项目X上线初期，我们给某个知识问答服务加了一条规则：“识别并拦截包含用户个人敏感信息的输入”。初衷是保护隐私，结果第二天就翻车了一大批正常请求——用户就是来问“我的体检报告怎么看”，这种内容天然涉及个人信息。拦不拦？当时规则引擎全拦了，用户一脸懵。

后来我换了个思路：不要对输入做一刀切的“敏感拦截”，而是做“敏感信息脱敏改写”，比如识别到手机号、身份证字段时，在送入模型前把它们替换为脱敏占位符，模型返回值里再映射回去。这样既保护了隐私，又不会误伤正常使用场景。Harness做得好不好，很大程度取决于这种“逼急了一刀切 vs 放行了出事”之间的平衡拿捏。

所以做护栏时一定要留个“审查机制”的位子。规则更新要能快速灰度回滚，不要每个规则都一次性全量上线。我建议每新增一条拦截规则，都先在影子模式下记录“如果启用这条规则会拦截多少请求”——运行两三天再看误伤比例，决定是否正式开闸。这套流程是血的教训换来的，不然每一次规则更新都等于在跟线上用户玩俄罗斯轮盘。

5.2 怎么让Harness从“能跑”升级到“聪明”

很多人做Harness最后做成了“笨规则大合集”，这也是常态。但一套高性能的Harness应该具备自我进化的能力，而不仅仅是静态红线。

我在项目X的后期做了一件事：把每个被护栏拦截的case都沉淀成训练样本，定期微调一个分类小模型，用来替代部分规则引擎。比如最初做输入注入检测靠的关键词列表，准确率只有75%，误配率却不小。后来每天把线上拦截样本人工标注一批，攒了两周后微调了一个轻量级分类器，准确率接近95%。规则列表吃的是前期逻辑，小模型吃的是长期数据，两者配合才能把护栏越调越聪明。

类似地，在输出语义校验层，也可以用“历史真实样本”来校准校验逻辑。举个例子，你的人工复核发现某类“模型编造产品对比结论”的case，把它们整理成负面样本，加到校验prompt里让审查模型判断“输出是否与事实背景材料冲突”。负责语义校验的小模型每迭代一轮，整体幻觉率就会又下一截。

5.3 关于成本的冷静思考

Harness不是免费的，每一次重试、每一次额外校验、每一次小模型二判都在增加你的推理成本。我见过一些团队把Harness做得极其豪华，每一条用户消息都要经过四五个模型的层层检查，结果一问用户侧的实际体验，响应慢了、成本飙了、反而不知道该优化谁。

我的建议是：给每一次护栏动作都设置独立开关，且默认关闭非关键检查。在需求上按“安全合规强制”、“稳定性必须”、“体验增强可选”三级分类管理。安全合规类的检查完全没有商量余地，稳定性类看场景，体验增强类大多数时候不要做。这样成本的每一分钱都花在刀刃上。

6. 结尾：让缰绳成为AI应用的地基工程

做LLM应用越久，越意识到一个朴素的事实：模型能力决定上限，Harness决定你能不能摸到那个上限的九成。裸跑的大模型很惊艳，但那是在“千次里挑出一次最优响应”给你看的demo感；生产环境要求的是“每次都在可接受范围内”。所谓“跑得更稳”，从来不是靠模型自己越来越聪明，而是靠工程体系里的每一条校验规则、每一层守卫逻辑、每一个降级预案来兜底。

我个人的体会是，Harness Engineering在LLM应用里的地位，应该像自动化测试在传统软件开发里一样，是刚需而不是可选项。传统代码你能靠编译器提前拦住一大批错误，但LLM没有“编译器”——它总是充满自信地输出，哪怕输出是错的。Harness承担的就是这个“编译器”职责，去承认“模型一定会错”，然后设计一套容错体系让错误形态可控、可恢复、可追踪。

最后再分享一个小经验：刚开始做Harness时别求全责备，不要指望一步到位把所有规则配齐。从一个最痛的问题入手，比如格式不稳定，把这一层的护栏做扎实，跑出数据，再逐步扩展。护栏是可以迭代的，但前提是你要有一个能持续观察、持续调整的机制。AI跑得再快，缰绳握得住，才是你自己的能力。