企业官网建设流程全解析

把AI从演示Demo推进到真实生产环境，是我这几年一直在折腾的事。项目做得越多，我越发现一个朴素的道理：大模型像一匹好马，跑得确实快，但你要是不给它套上缰绳，它随时可能带着你一头冲进沟里。所谓Harness Engineering（给AI套缰绳的工程学），就是研究怎么用一套可控的工程机制，让模型在真实业务场景里稳定、安全、按预期地干活。这篇文章面向两类人：一是自己动手写AI应用、想提升产出质量的开发者；二是团队里正在做Agent或AI功能落地的负责人。我会用尽量通俗的大白话，把Harness Engineering的核心思想、关键组件、最小落地代码和常见坑一次讲清楚。文中方案都在实际项目里验证过，可以直接拿去参考。

1. 为什么需要给 AI 套上缰绳：从“会聊天”到“能干活”

1.1 一切失控都是从“太自由”开始的

先讲一个真实发生的翻车现场。某公司做客服工单自动回复，最初方案很简单：把客户留言直接扔给大模型，让它生成一段回复。模型在大多数情况下表现得像个熟练客服，态度礼貌、语气温和、内容完整。直到有一天，一条客户投诉写着“再不来人处理我就起诉你们”，模型居然自动回复了一句“您可以委托律师处理此事，请提供律师函编号”。单看这句话本身没毛病，但这公司的内部规范写得很清楚：凡是涉及法律威胁的工单，必须优先转人工，禁止由系统直接回复。模型不懂这条业务红线，于是一秒之内就把一条高风险工单处理成了正常投诉。

这种案例我见得太多了。让模型从一堆文本里提取日期，它把“下周”自动脑补成具体日期，导致整个排期系统错乱；让模型写一段产品宣传语，它自由发挥出完全不合规的极限词；让模型做数据分析，它在字段不存在的情况下仍然编出一个看似合理的结果。你会发现，问题从来不是“模型不会做”，而是“模型太会自由发挥了”。它输出的是概率上最像样的文字，而不是业务上最正确的结论。

这就是为什么需要给模型套缰绳。模型的能力边界在变大，但真实业务系统要的是确定性：字段必须合法、枚举必须在范围内、高风险动作必须被拦住。你不可能靠“祈祷模型别犯错”来交付系统，必须靠工程手段把模型的行为约束在业务可接受的范围内。

1.2 缰绳的本质：把人的要求翻译成模型能遵守的边界

很多人第一次听到Harness Engineering，以为是要限制模型的“能力”，或者给模型上什么复杂的算法。其实没那么玄乎。它的本质就三件事：说清楚规则、规定好格式、拦住坏结果。对应到具体实现上，就是指令模板、结构化输出、校验与重试机制这三板斧。

我习惯用一个类比来解释。马不懂交通法，但骑手可以通过缰绳、口令和腿部的配合，让马走在该走的路上。缰绳不是为了让马跑得更慢，而是为了让马跑得更准。模型的“语言”是提示词和接口参数，模型的“缰绳”就是一套精心设计的输入输出契约。契约定得越清楚，模型越不容易跑偏。

为什么不能靠“换一个更强的模型”来解决？我做过对比测试，更强的模型确实可以把错误率从百分之五降到百分之一，但剩下那百分之一的错误，往往更难发现、更难预测。真正上线的时候，百分之一的概率乘以每天上万次调用，就是每天一百次事故，照样让你焦头烂额。所以我的结论很明确：模型选型当然重要，但无论选哪个模型，Harness这套机制都是必须的。它解决的是系统级的确定性，而不是模型单次的正确率。

2. Harness 的核心组件拆解：指令、格式、校验、流程

2.1 指令模板：把所有约定写进 System Prompt

Harness的第一根缰绳，是系统指令。很多人的System Prompt写得特别敷衍，比如“你是一个智能助手，请帮助用户解决问题”。这种指令等于没写，模型只能靠猜。真正的指令模板应该像一份员工手册，把角色、任务、边界、输出格式、反例全部写清楚。

我常用的模板结构大概这样：

• 角色定义：你是谁，在哪个系统里工作
• 任务说明：当前要做什么事，输入是什么
• 输出要求：必须按什么格式输出，字段有哪些
• 边界条件：什么情况不能处理，必须转人工或返回默认值
• 负面示例：明确告诉它不要做什么

举个例子，我之前做一个客户留言分类系统，System Prompt是这么写的：你是工单分类引擎，只负责对客户留言做结构化分类。你只能输出严格的JSON对象，包含类别、紧急度、是否转人工、摘要四个字段。类别只能是投诉、咨询、表扬、其他四选一；紧急度是0到1之间的小数；是否转人工是布尔值；摘要是不超过五十字的中文概述。如果留言内容不完整，无法判断类别，类别填“其他”，是否转人工填true。绝对不要输出JSON以外的任何解释文字。

这套Prompt看起来朴实无华，但它把边界划得非常清楚。模型不再需要“理解”业务需求，它只需要照着要求执行。提高Prompt质量最有效的手段，是收集真实反馈。每次模型输出不符合预期，就把这条样本加进测试集，调整Prompt，再跑一遍回归。Prompt不是写出来的，是迭代出来的。

2.2 结构化输出：用 Schema 代替自由文本

第二根缰绳，是输出格式约束。为什么一定要结构化输出？因为自由文本没法被程序稳定解析。模型说“我觉得这个工单很紧急，建议赶紧处理”，你的代码怎么读？没法读。但模型如果输出一个JSON对象，里面紧急度字段是0.9，你的代码立刻就能判断优先级。

结构化输出的核心思路，是明确告诉模型输出的JSON长什么样，字段名、字段类型、允许值范围都写清楚。我自己最常用的是JSON Schema思路，在Prompt里直接给出可参考的JSON模板，并且字段命名简单直白，让模型没有歧义。

比如上面那个工单分类系统，我要求在输出中包含：

{ "category": "投诉", "urgent_score": 0.9, "needs_human": true, "summary": "客户反馈商品破损且联系不到客服，要求尽快处理" }

这里有几个细节值得注意。字段名别用缩写，模型更容易理解的是“category”而不是“cat”；枚举值必须在Prompt里逐个列出来，别让模型自己发挥；JSON模板最好放在Prompt的后半段，并且紧挨着用户输入的位置，这样模型在生成时更容易参照。我自己实测下来，模板离输出越近，格式稳定性越高。

2.3 校验与重试：用代码兜住模型的嘴

第三根缰绳，也是最容易被新手忽略的，是输出校验。很多人觉得Prompt写了JSON格式，模型就会乖乖输出JSON，其实不是。模型偶尔会在JSON前面加一句“好的，这是你要的：”，偶尔会在JSON后面加一句“希望对你有帮助”，偶尔会输出一串不符合Schema的字段。这些情况你都得用代码兜住。

校验逻辑不复杂，但必须写完整。首先尝试把响应解析成JSON对象，这一步就拦截掉一半问题；然后逐字段校验类型和值域，比如category必须在四个枚举值里，urgent_score必须是0到1之间的数字，needs_human必须是布尔值。校验失败后怎么办？不要让系统直接返回错误，而是把错误信息重新喂给模型，让它重新生成。

这个“自纠错”机制是整个Harness里效果最好的设计之一。模型看到“解析失败：urgent_score字段缺失，请重新输出完整JSON”之后，大多数情况会老老实实补上。重试次数我一般设两到三次，设多了成本扛不住，也没必要。每次重试时把校验器返回的具体错误信息拼进新的Prompt，模型就知道自己错在哪，修正率非常高。

2.4 流程编排：把大任务拆成小步骤

第四根缰绳，是针对复杂任务的一层流程编排。一个常见的误区是，用户把一个复杂任务整个扔给模型，指望模型一步到位。结果模型要么输出质量差，要么中途跑偏。更稳妥的做法是，把一个大任务拆成多个小步骤，每个小步骤都单独设计Prompt、单独校验输出，再把上一步的结果作为下一步的输入。

举个例子，我之前做过一个自动生成客服回复的系统。如果让模型一步到位从“客户留言”直接生成“最终回复”，模型经常漏掉关键信息。后来拆成三步：先做意图分类，判断这条留言属于投诉还是咨询；再从留言里提取关键实体，比如订单号、商品名、用户诉求；最后根据意图和实体生成回复草稿，并且每一步的输出都做校验，任何一步失败就中止流程，不再继续往下走。

这种流水线式的设计有两个好处。第一是错误容易定位，哪一步出了问题，日志里一眼就能看到；第二是每一小步的Prompt可以写得非常聚焦，模型在小任务上的表现远比在复杂任务上稳定。代价是多了几次模型调用，延迟和成本有所增加，但换回来的是可控性和可维护性，这笔账划算。

3. 从零搭建一个最小可用的 Harness 系统

3.1 需求定义与输出契约

说了这么多理论，接下来我把一个最小可用的Harness系统完整过一遍，就以“客户留言自动分类”为例。这个场景足够简单，又能体现指令、格式、校验、重试四个核心组件，很适合作为入门模板。

需求定义：系统接收一段客户留言文本，输出一个结构化对象，包含四个字段——类别、紧急度、是否转人工、摘要。这个输出的Schema就是整个系统的核心契约。契约越明确，校验逻辑越好写，模型也越不容易出错。

我把输出契约固定为这样一段描述，直接写进Prompt里：请以严格JSON格式输出，不要附加任何解释文字。category字段只能是“投诉”“咨询”“表扬”“其他”四选一；urgent_score是0到1之间的数字，表示紧急程度；needs_human是true或false；summary是少于五十个字的留言摘要。如果留言内容不足以判断类别，category填“其他”，needs_human填true。这段描述我称之为“输出契约”，是整个Harness的地基。

3.2 指令模板与代码实现

输出契约定了，接下来是完整代码。我用的是Python，大模型接口直接用一个client对象代替，你对接任何主流大模型服务商时换成自己的SDK即可。核心思路是通用的，不绑定任何特定厂商。

import json class ClientMessageHarness: SYSTEM_PROMPT = """ 你是工单分类引擎。你唯一的工作是根据客户留言输出严格的JSON对象。 输出格式必须如下： { "category": "投诉", "urgent_score": 0.9, "needs_human": true, "summary": "客户反馈商品破损且联系不到客服" } 字段要求： - category：只能是"投诉"、"咨询"、"表扬"、"其他"中的一个 - urgent_score：0到1之间的小数，数值越大越紧急 - needs_human：true或false - summary：少于50个字的中文摘要 额外规则： - 只输出JSON，不要输出任何解释或前缀 - 如果留言信息不足，category填"其他"，needs_human填true - 严禁编造留言中没有出现的订单号、姓名等信息 """ def __init__(self, client, max_retry=2): self.client = client self.max_retry = max_retry def _parse_output(self, raw_text): # 直接尝试解析整个输出为JSON try: data = json.loads(raw_text) return data, None except json.JSONDecodeError as e: # 部分模型会输出少量前后缀，尝试截取第一个{到最后一个} start = raw_text.find("{") end = raw_text.rfind("}") if start != -1 and end != -1 and end > start: try: data = json.loads(raw_text[start:end + 1]) return data, None except json.JSONDecodeError: pass return None, f"JSON解析失败: {e}" def _validate(self, data): # 逐字段校验，返回错误信息字符串 if not isinstance(data, dict): return "输出不是JSON对象" if data.get("category") not in ["投诉", "咨询", "表扬", "其他"]: return "category字段不在允许的枚举范围内" urgent = data.get("urgent_score") if not isinstance(urgent, (int, float)) or not (0 <= urgent <= 1): return "urgent_score必须是0到1之间的数字" if not isinstance(data.get("needs_human"), bool): return "needs_human必须是布尔值" if not isinstance(data.get("summary"), str) or len(data["summary"]) > 50: return "summary必须是少于50字的字符串" return None def run(self, user_text): for attempt in range(self.max_retry + 1): response = self.client.chat( messages=[ {"role": "system", "content": self.SYSTEM_PROMPT}, {"role": "user", "content": f"客户留言：\n{user_text}"} ], temperature=0.2, max_tokens=300 ) raw_text = response["content"] data, parse_error = self._parse_output(raw_text) if data is not None: validate_error = self._validate(data) if validate_error is None: return data # 重试时把错误信息回传给模型，让它自纠错 retry_hint = f"你刚才的输出不符合要求，错误如下：{parse_error or validate_error}。请根据原始留言重新输出，只要合法JSON。" self.client.chat( # 仅作示意，实际会把retry_hint合并进下一轮Prompt messages=[ {"role": "system", "content": self.SYSTEM_PROMPT}, {"role": "assistant", "content": raw_text}, {"role": "user", "content": retry_hint} ], temperature=0.2, max_tokens=300 ) # 重试耗尽，返回一个安全的兜底结果 return { "category": "其他", "urgent_score": 0.0, "needs_human": True, "summary": "系统无法自动分类，请人工介入处理" }

这段代码的核心就三个方法。_parse_output负责把模型输出解析成JSON，兼容模型偶尔输出前后缀的情况；_validate负责逐字段校验，任何一个字段不合法都返回具体错误信息；run负责组装流程，在解析或校验失败时把错误信息回贴给模型，触发自纠错。最后如果重试次数耗尽，直接返回一个安全的兜底结果，而不是让系统崩溃或者返回错误数据。

3.3 关键参数怎么定：温度、长度、重试次数

第一次做Harness的人，经常对三个参数拿捏不准：temperature、max_tokens、重试次数。我直接给一套经验值，你在这个基础上调就行。

temperature代表随机性，分类、抽取这类追求稳定性的任务，我一般设在0到0.2之间，让模型输出尽量保守；创意类任务比如写文案、出点子，才需要调到0.7以上。之前见过有人分类任务用默认的0.7，结果同一个工单跑两次得到两个不同分类，这就是温度太高导致的。结构化输出场景，温度越低越好。

max_tokens要稍微给宽一点。你预期输出两百字，至少设到三百，留出余量，否则输出被截断，JSON不完整，白跑一次。重试次数我推荐两到三次，第一轮没过的样本，第二轮大概率能过；如果两轮都过不了，说明Prompt设计有问题，靠重试解决不了，应该回头改Prompt而不是继续烧钱。

成本方面也要有个概念。每次重试都要重新计费，而且多轮重试会成倍增加延迟。所以Harness的设计目标不是“完全不出错”，而是“出错时系统不崩、能自纠、有兜底”。把重试次数控制在两到三次，是成本和稳定性之间的平衡点。

3.4 上线前必做的事：准备回归测试集

最后，上线之前强烈建议准备一组回归测试数据。不需要很多，二十到三十条典型输入就够了，覆盖面要广：正常投诉、正常咨询、语气很激烈的投诉、内容含糊不清的留言、包含订单号/不包含订单号的、纯英文的（看业务需要）、超长的留言等等。每跑一次Prompt或代码改动，就把这组数据完整跑一遍，看有没有回归问题。

这个习惯帮我省了太多事。最典型的一次，我改了一句Prompt想让模型摘要更短，结果分类准确率掉了八个点，如果没有回归测试集，这种问题直接上线根本发现不了。团队版的测试集建议放在统一目录，用同样的JSON格式存输入和期望输出，配合自动化脚本每次提交代码时自动跑一遍。Harness工程的可维护性，很大程度就取决于这条兜底的测试防线。

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

4.1 模型“不听话”的三种典型表现

做Harness久了，会发现模型“不听话”的表现其实就那么几类，对症下药很快。

第一种是输出带多余的前缀后缀。比如JSON前面多一句“好的，这是结果”。我的处理方式是在_parse_output里用截取策略，直接从第一个左花括号切到最后一个右花括号。这个办法覆盖了百分之九十几的情况，偶尔还有极端情况，就把Prompt里那句“只输出JSON，不要输出任何解释或前缀”加粗强调，并附一个错误示例“不要输出'好的，这是结果'这类文字”。

第二种是枚举字段超出范围。让模型四选一，它给你输出一个“比较紧急”这种描述。本质原因是枚举值的定义不够封闭。解决办法是把枚举值写得更死，比如“category只能是以下字符串之一：'投诉'、'咨询'、'表扬'、'其他'，禁止输出其他任何文本”。同时校验器里必须有枚举判断，不能只靠Prompt自觉。

第三种是编造信息。留言里根本没提订单号，模型在摘要里强行编一个出来。这类问题靠Prompt和校验器都很难根治，我用的办法是在Prompt里明确声明“严禁编造留言中不存在的订单号、姓名、日期等信息”，同时在业务层面对关键字段做交叉校验，比如提取出的订单号必须在订单系统里真实存在。如果校验不通过，直接打回重试。尽量不在一次调用里紧耦合所有校验，但这个兜底原则是通用的。

4.2 输出解析失败的高频原因

解析失败是Harness最常见的技术问题，我整理了一个排查速查表，遇到问题直接对照着查。

这张表看起来简单，但每一条都是真实项目里踩出来的。我强烈建议团队里把这些典型问题沉淀成文档，每次新成员接入Harness开发时先读一遍，能省掉大量重复排查时间。

4.3 延迟与成本失控的隐形坑

Harness做得越完善，模型调用次数就越多。一个简单的工单分类都可能在重试机制下变成两三次调用。如果你做的还是多步骤流水线，每一步都带两三次重试，延迟和成本就会指数级膨胀。这块必须从一开始就盯着。

我的经验是给整套流程设一个总预算。比如分类这个单步任务，最多重试两次，单次超时十秒，整步不超过三十秒；如果业务对实时性要求高，可以把重试次数砍到一次，宁可走人工兜底也不拖住用户。日志里必须记录每次请求的耗时、token消耗和重试次数，这样哪一步超支，一眼就能看出来。

另外一个小技巧：对稳定的输入做缓存。像工单分类这种任务，如果同一类留言经常出现，可以在前面加一层哈希缓存，完全相同的输入直接复用上次的结果。这个优化在某些场景能把成本砍掉近一半，值得试一下。

4.4 日志是 Harness 的另一条缰绳

最后特别强调日志的重要性。Harness系统比一般接口多了好几层逻辑，排查问题时，没有日志几乎无从下手。我每次上线Harness都会要求至少记录这些字段：请求ID、输入文本、完整系统Prompt、模型原始输出、解析结果、校验错误信息、重试次数、最终返回值、耗时、token消耗。

这些日志不仅用于事后排查，更是持续优化Prompt的依据。把校验失败的所有样本收集起来，每周翻一次，你就会发现某个错误模式反复出现。比如某个字段频繁缺失，说明Prompt里对它的强调不够；某类输入频繁触发重试，说明漏了一种边界情况。Harness工程不是一个写完就结束的静态系统，它更像一个持续迭代的闭环，而日志就是这个闭环的反馈信号。

5. 从单次调用到Agent场景：Harness 的进阶思路

5.1 用状态机约束 Agent 的行动路径

上面讲的主要是单次模型调用的Harness，到了Agent场景，问题又会复杂一个量级。Agent不再只是“根据输入生成一段输出”，它可以自主决定调用哪些工具、按什么顺序执行、什么时候停下来。这个自由度是双刃剑，用得好了能干复杂的活，用不好就变成失控的野马。

我对Agent场景的核心做法，是把自由行动变成有限的状态机。预先把整个任务拆成若干个状态节点，每个节点上Agent只能做预设的操作：要么调用指定工具，要么生成一段特定格式的中间结果。步骤之间由状态机控制流转，Agent不能自己跳到下一步，更不能自己发明新步骤。

举个例子，之前做一个自动查询订单状态的Agent。我给它定义了四个状态：提取订单号、查询订单状态、生成回复、标记完成。在提取订单号这个状态里，它只能调用“订单号提取”工具，输出必须是纯订单号或者“未找到”。它不能擅自跳到查询状态，更不能自己去查用户资料库。每次工具调用的输入输出都经过同样一套校验和日志机制。看起来限制了自由，实际反而让整个流程更稳，因为用户和开发者都能看清楚Agent每一步在干什么。

5.2 高风险动作必须人工兜底

在Agent场景里，一定要划出“高风险动作”清单。我的原则很简单：凡是不可逆、影响面大、涉及资金或隐私的操作，一律不算Agent自动执行的结果，必须走人工确认。比如自动发邮件、自动删除数据、自动转账、自动修改线上配置，这些操作不管模型校验通过与否，最后一步都要有人点确认。

这不是不信任模型，而是工程系统的底线规则。模型可以在“生成草稿”这一步做得很好，但“执行生效”这一步属于你的系统责任，不该让一个概率模型独自承担。Harness工程的最终目标不是把人类的控制全部去掉，而是把AI的能力框在一个边界内，让风险始终可控。

5.3 权限最小化：别给模型全局钥匙

结合上面的思路，权限最小化是Agent Harness最容易忽略的一环。很多人做Agent时图方便，直接把所有工具和所有数据接口一股脑提供给模型。模型的能力是强了，但风险也成倍放大。

正确做法是，按当前任务需求，只开放必要的工具权限。办公场景里的“读取工单信息”权限，和“写入工单状态”的权限，必须分开；普通查询场景，只给只读接口，不给写入和删除接口。这套设计和给人类员工分配权限的逻辑完全一样：一个新入职的实习生，你不会第一天就给他核心数据库的删除权限，AI也一样。

我见过太多Agent项目死在权限这一步上。模型本身表现很好，但团队因为害怕权限事故，迟迟不敢让Agent真正接手业务。与其这样，不如一开始就做最小权限设计，把风险面压到最低。权限越小，Harness越好做，系统越敢上线。

最后说一点个人体会。做Harness Engineering这两年，我最大的感受是：别等模型出错了再补缰绳，要从第一个Demo就开始设计这套约束机制。项目迭代过程中，每次模型跑偏的样本都要及时加进回归测试集，Prompt和校验器一起改，慢慢沉淀成一套团队共用的基础框架。最后分享一个小技巧：每次模型返回的原始输出都完整留档，哪怕当时一切正常，将来出了问题排查时，这些留档就是最宝贵的证据。你永远不知道哪一条看起来普通的输出，会是某个诡异问题的突破口。