企业官网建设流程全解析

你让Agent做的事其实不复杂——“查一下订单S-2048的物流状态”。它回复得比人工客服还流畅：包裹已到达某某分拨中心，预计明晚送达。你下意识觉得哪里不对，翻了一下订单系统，发现S-2048这个编号根本不存在，整段答复从订单号到物流节点全是编出来的。

更让人头疼的是，你换了一版更强的模型，问题还在。它编得更流畅、更自信、结构更完整，但数据依然是假的。做了很长一段时间AI Agent相关开发后，我越来越确定一件事：幻觉问题不能只靠换模型解决，真正能兜住幻觉的，是外面那层叫“Harness”的工程体系。这也是我写这篇文章的初衷——把AI Agent Harness Engineering这个概念拆开，讲讲我遇到的幻觉现象，以及我在实际项目中验证过的一整套解决方案。

这篇文章适合以下几类人来看：正在做Agent类应用、被模型胡编乱造折磨的开发者；刚接触Agent架构、想系统了解“除了调Prompt还能做什么”的工程师；以及负责Agent类产品落地、需要向团队解释“为什么不能只选个大模型”的技术管理者。

1. 从“换模型”到“搭框架”：AI Agent Harness Engineering到底在解决什么问题

1.1 我踩过的那条弯路

早些年做AI应用，团队里很容易形成一种默契：效果不好，就换模型。模型A幻觉多，换模型B；模型B拒绝回答太多，又换回模型A。一来二去，时间全花在调参和换接口上，幻觉问题依旧。

我接手过一个内部客服类的Agent项目，最初的架构简单得可怜：用户提问，拼上Prompt，丢给大模型，把返回文本直接展示出来。上线第一周就出了事故——用户问“我上个月的积分明细”，模型把另一个账户的消费记录拼凑进来，一本正经地编了一份明细。排查下来模型没有“故意”撒谎，它只是把上下文里最像答案的片段组织了一下。

那次事故让我彻底转变了思路：幻觉不是模型的单一缺陷，而是整个系统对“不确定性”缺乏管理的结果。如果系统里没有证据、没有约束、没有校验，那模型就只能凭概率生成，幻觉只是概率的另一种表达。

1.2 Harness到底是什么：模型是内核，框架是外设

很多开发者听到“Harness”这个词会联想到“测试脚手架”。确实，软件测试里的test harness是给被测程序搭一套运行环境和驱动框架。AI Agent这里的Harness也类似，只不过它“驱动”的不是被测程序，而是一个不可控的大模型。

我给一个直观的定义：Agent Harness就是围绕模型搭建的整套外部支撑体系，负责上下文构建、工具调用、输出约束、状态记忆、观测和评测。模型是内核，Harness是外设。内核决定智商上限，外设决定可用性下限。

现实中的Agent项目，纯靠模型本身的能力根本撑不起来。要让Agent查订单，你需要给模型接订单查询工具；要让Agent写代码，你需要给模型接代码执行环境；要让Agent回答公司制度问题，你得先把制度文档检索进来。这些就是Harness工程的一部分。

1.3 为什么幻觉问题必须在Harness层解决

模型本身是概率系统，它生成下一个词的方式本质上是在算“哪个词概率最高”。如果它训练数据里没有你系统里的真实数据，它就只能靠“合理推测”来补全。你以为它在回答问题，实际上它在做“听起来像正确答案的文本续写”。

这个特性决定了：只要模型还是生成式的，幻觉就不会被根除。但工程上我们不需要根除幻觉，我们需要的是让幻觉“出不来”或者“出来了也能被拦下来”。

问题在于，大多数团队把幻觉当模型问题处理，而模型层面的干预手段非常有限：换更大的模型、调低temperature、改写Prompt。这些手段能缓解问题，但拦不住所有场景。事实核查、工具调用、上下文控制、输出校验，这些全部发生在模型之外——也就是Harness层。把防线放在Harness层，就是用确定性的工程代码去约束不确定性的模型输出，这才是工程上真正可落地、可复现、可迭代的路径。

2. 别急着修：先给Agent的幻觉分个类

2.1 幻觉不是同一种病，是四类症状的合称

很多人一说幻觉，就觉得是“模型编造事实”。但在我实际处理过的案例里，Agent系统里出现的“失真现象”至少可以分成四类：

我在项目里踩过最重的一跤是第二类。系统中明明接了查询接口，接口也返回了正确数据，但模型在组织答复时，把金额看错了位、把状态字段张冠李戴。这就是典型的输出阶段失控——信息是准的，表达偏了。

2.2 一个具体的案例：工具对了，结果错了

模拟项目X里有一个数据分析助手，用户让它“对比本月与上月的销售额”。Agent调用了两个查询工具，分别拿到了两组数字，按理说这个回答很简单。但模型在生成时，居然把“本月”和“上月”两列标题互换了。从逻辑上看，它的句式非常通顺，如果没有人去核对原始工具返回，根本发现不了。

这类问题的可怕之处在于：它不是知识不足导致的胡编，而是正确信息在“生成阶段”发生的语义漂移。模型不是不知道答案，而是它的注意力机制在处理多来源信息时发生了错位。

2.3 判断哪些幻觉Harness管得了、哪些管不了

不是所有幻觉都适合在Harness层解决。我一般会做一个判断：如果模型缺少某个领域知识，它编出来的东西其实更像“知识盲区”，这个可以通过提供检索材料解决。如果模型面对明确返回的数据还是答错，那就是输出约束和校验问题。但如果模型面对的是开放式的创意任务，比如“写一首诗”或者“头脑风暴”，那所谓“幻觉”反而是产品功能的一部分，不应该去约束。

先分类，再定方案。我的原则很简单：凡是回答会直接影响现实决策的（查订单、查余额、查法规），必须在Harness层上全套防御；凡是偏创意或闲聊的内容，就不用浪费成本和延迟。一套Harness配置打天下，既费钱又费力。

3. 层层设防：“证据供给—过程约束—结果校验”三明治结构

3.1 底层：把证据喂进去，让模型少凭记忆发挥

对抗事实性捏造最直接的手段，就是别让模型“凭记忆”回答。记忆是概率，检索才是事实。这里说的就是现在大家很熟的RAG（检索增强生成），但在Agent场景里，RAG要做对几个细节。

第一，检索进来的材料必须带“来源标记”。文档里哪一段是来自哪个业务系统的哪个ID，要作为元数据跟着内容一起进入上下文。第二，提示词里要明确要求：回答必须基于提供的材料，材料里没有的信息要明确说明“未查询到”，禁止自行推测。第三，对检索结果做“够用即可”的裁剪，不要一次性塞几十页文档，上下文越长，注意力分布越稀，模型越容易捡到不相关的信息。

有人会问：模型不是本身就有很强的通用知识库吗？为什么非要有检索层？答案很直接：通用知识库里的“知识”没有时效性，也没有业务区分度。你问它“某个项目的预算”，它的训练数据里不可能有实时的项目数据。没有检索层，它就一定靠编，因为它需要给出一个回答，这是它的训练目标决定的。

3.2 中层：用工具调用的结构化约束锁死“过程”

Agents类和纯Chat类最大的区别在于“工具调用”。工具调用环节是幻觉的重灾区，因为模型需要在一次输出中生成“调用哪个工具”“传什么参数”两个决定，参数稍有偏差，结果就错。

中层的核心手段是结构化约束。可以让模型输出严格符合函数的JSON参数结构，而不是输出自由文本，再靠代码去解析提取。自由文本解析的脆弱我在项目里体会太深了：模型可能说“帮我查一下这个订单的物流”，但“这个订单”到底指哪个订单号，它能写出各种各样的表达方式。用函数调用机制强制参数结构后，模型必须在参数里明确给出订单号，不给就算调用失败。

另一个容易被忽略的细节是工具执行失败后的错误信息回传。工具接口超时了、查无数据、鉴权失败，这些结果必须原封不动地回传给模型。很多实现里，开发者在工具执行失败后习惯性返回一句“查询失败，请重试”，这句模糊的信息反而给了模型自由发挥的空间——它会在下一轮编造一个看起来合理的查询结果来“弥补”失败。正确做法是把具体的错误码和错误消息透传回去，并明确提示模型不得凭空补全。

3.3 顶层：生成之后再做一轮“事实核对”

如果说中层的约束是防患于未然，那顶层的校验就是事后的第二道保险。无论前面做得再好，模型最终生成的回复仍然可能出错，所以必须加一道独立的校验管线。

校验管线一般包含三个动作。第一，结构校验——话术必须包含哪些必填字段，比如订单号、查询时间、状态字段是否齐全；对于要求JSON输出的场景，直接用Schema校验，不满足就判定为失败并触发重试或兜底话术。第二，引用断言——模型在回答里提到的关键数据，必须能在它收到的检索材料或工具返回中找到对应证据。举个例子，模型如果断言“物流状态为已签收”，校验逻辑里就应该有代码去核对工具返回里明明写着“运输中”，两边对不上，立即拦截。第三，语义一致性——这个更进阶，用另一个模型实例来评估输出与上下文是否一致，或者用向量相似度来判断语义是否偏移。语义校验成本高，通常只用在关键场景。

3.4 校验管线落地示意

下面这段伪代码是我在项目里用的一个简化版校验管线，核心思路是“先结构、再引用、后语义”：

def validate_answer(response, evidence, tool_results): # 1. 结构校验：必填字段必须存在 required_fields = ["order_id", "status", "estimated_time"] for field in required_fields: if field not in response.parsed_data: return FAILED, f"缺少必填字段: {field}" # 2. 引用校验：答案中的关键数值必须在证据中可追溯 if response.parsed_data["status"] != tool_results["express_status"]: return FAILED, "物流状态与工具返回不一致" # 3. 追加LLM做语义一致性评估（可选，仅关键链路开启） consistency_score = judge_model.check_consistency( question=question, answer=response.text, evidence=evidence ) if consistency_score < 0.85: return FAILED, "语义一致性低于阈值" return PASSED, "校验通过"

三层校验全部通过，才允许把回复展示给用户。这里的每一层都可能会误伤正常回答，所以后面还会讲阈值怎么调。

3.5 容易忽略的坑：检索到了，模型不一定“用对”

RAG有一个经典陷阱：检索回来的材料确实是相关的，但模型在生成时可能没引用，或者只引用了一部分，然后自己补充了一大段“推测内容”。我把它称为“检索到但没用对”。

我的解决方案有两个。一是给材料加“强制引用”标记，在提示词中明确要求：回答中所有涉及材料内容的地方必须标注来源编号，未标注来源的句子不得输出。这是把“是否用了证据”这个抽象要求转成可检查的具体行为。二是对引用覆盖率做统计监控，定期检查“有多少回答完全没有引用来源”。如果引用率很低，那不是模型的问题，是提示词的约束失效了，需要回去调整。

4. 教Agent承认“不知道”：拒绝机制与置信度路由设计

4.1 让“不知道”成为一个合法回答

很多开发者在写系统提示词时，恨不得把“你必须回答”写三遍，生怕模型说不知道。这恰恰是幻觉的重要推手。当“不知道”不是一个可选项时，模型就只能编一个“知道的”来满足指令。用户在业务场景里问一个数据库里不存在的数据，模型最正确的行为就是明确说“我未查询到相关信息”，而不是顺着用户的提问编造一个最贴近的数字。

所以我做系统提示词时，会故意写一段“信息不足时怎么办”的专项指令：如果检索结果为空、工具报错、或上下文里没有足够信息支持回答，必须以“抱歉，我未查询到相关信息”开头，并说明缺少的是哪部分信息。这段指令看着简单，但它给了模型一条“合法后退”的路径，相当于在生成概率上压低“强行续写”的权重。

4.2 工具失败信息要“透传”，不要“翻译”

前面已经提到，工具失败后返回模糊的提示信息是幻觉的催化剂。这里展开说。

有一次，我们的订单查询接口偶发超时，Harness把超时封装成了“查询遇到异常，请稍后再试”。模型拿到这个信息后，为了“帮助用户”，自己补了一段“可能是系统正在维护，建议您去官网查询”——整体看没有大毛病，但问题是它把“查询失败”包装成了“系统维护”，这是一种非常隐蔽的误导。如果用户真的去了官网，发现没有维护，投诉就来了。

正确做法是原样透传具体的错误码和错误描述，同时给模型明确规定：工具未返回有效数据时，不得解释原因，只能说“服务暂时不可用，请稍后重试或联系人工”。把解释权从模型手里收回来，交给确定性代码。这是Harness工程里“控制生成空间”思想的典型体现——能不让模型承担判断的地方，尽量不让它承担。

4.3 置信度路由：低置信度的回答不直接出街

拒绝机制不能只靠模型的自觉，要在Harness层面加一个“置信度”的概念。我通常会把回答场景分为三档：

• 高置信度：有明确工具返回支撑，且校验全通过，直接展示。
• 中置信度：有佐证材料但不够完整，展示时附加“信息来源”说明，并附带免责提示。
• 低置信度：模型表达含糊、无引用、多个证据来源互相矛盾，触发转人工，或要求用户进一步明确问题。

很多团队觉得“无引用就不展示”太粗暴，会大幅降低系统可用性。更好的做法是给低置信度回答降级——比如客服场景里，模型如果对答案把握不足，可以直接生成一条转接人工的中间页，而不是硬给一个答案。有些时候，用户宁可多等30秒转人工，也不愿意读一段流畅但不可信的回复。

4.4 但要小心：不要让Agent变成“满嘴不知道”的复读机

拒绝机制有一个反向风险——过度防御。模型在压力下容易滑向“这个我不知道、那个我也不知道”，导致用户体验直线下降。我在实际调试中发现，模型对拒绝的“倾向”可以用提示词里的优先级编排来控制：要求模型在回答前先自行检索已有的证据，只有证据确实不足时才允许拒绝，而不是遇到困难直接摆烂。

还有一种温和的降级策略：不确定完整答案时，给出“可确认的部分信息”，同时明确标注“以下数据未经最终确认”。比如用户问“这批货什么时候到”，工具返回了“已出库但无预计送达时间”，模型可以说：“包裹已出库，但系统暂时没有预计到达时间，有结果我会再同步给你。”这比强行报一个日期要专业得多。

5. 把幻觉从玄学变成指标：回放评测与线上度量

5.1 没有评测集的防幻觉，都是自我感动

很多人改了提示词、加了校验，就问“效果怎么样”。如果回答是“感觉好多了”，那心里一定没底。幻觉是否减少，不能靠感觉，要靠回放评测。

回放评测的核心是把真实用户的历史Prompt保存下来，定期喂给当前版本的Agent，检查输出与预期是否一致。最关键的是把线上出过事故的Prompt沉淀成“回归用例”。比如那次订单号编造案例，我会专门把S-2048这类不存在订单号的查询存成一条用例，每次改动Harness结构都跑一遍，确保同样的问题不再出现。评测集不是一次建完就完事的，它是和线上事故一起生长的资产。

5.2 三段式的自动校验：断言、语义、LLM评审

回放评测的自动判定，我一般用三级手段叠加：

硬断言适合检查“有没有”，比如回复是否包含订单号、是否含有“未查询到”这样的关键词；语义相似度适合检查“像不像”，但它的弱点在于无法判断事实是否正确；LLM评审则适合判断“合不合理”，在工具调用链路的日志上跑LLM评审，能发现“模型明明拿到了正确数据但答错”这类语义漂移问题。

我建议分场景配置，而不是全部打开。对实时交互链路，优先硬断言和结构化校验；对离线评测，再上LLM评审，评估结果汇总成周报。毕竟每个线上请求都跑两遍LLM，成本会非常感人。

5.3 什么时候跑回放：每次Harness变动，都得跑主链路

回放评测的触发时机也很重要。我的经验是：只要Harness层有任何配置变更——换了提示词模板、改了工具返回结构、调整了校验规则——就至少跑一遍主链路回归集。主链路回归集不用太大，我一般保持在200到500条覆盖典型场景和事故案例的Prompt。跑一次全量回归，十几分钟就能完成，但这十几分钟能拦住大量的“改好一个bug、引出另一个bug”。

除了变更时跑，我还会每天凌晨定时跑一次全量回放，用前一天的新增线上Prompt来训练和检验当前版本。这样即便白天上线了问题，第二天早上也能被评测结果及早暴露出来。

5.4 围绕幻觉设计可观测指标

很多人问“我应该看哪个指标”，我会先明确：幻觉很难直接测出数量，但可以测出“防御体系的健康度”。我重点盯这几个读数和过程量。

第一个是拦截率：多少次回答被校验层拦截了。这个数字高并不全是坏事，它说明防幻觉机制正在工作，但如果一个月只拦截个位数，那要怀疑是不是校验规则太松了。第二个是无引用率：生成了回复但没有附加任何来源的比例，这个指标越高，系统越接近“裸奔”。第三个是转人工率：低置信度路由触发转人工的比例，这个数字要结合用户满意度一起看，太高说明系统能力不足，太低说明风险被低估。第四是回归退化率：每次改动后，评测集里“从通过变成失败”的用例数量。退化率为零是理想目标，但现实中只要有改动，退化率就是唯一要考虑的第一指标。

这些指标都不需要去“识别幻觉本身”，它们度量的是我们的防线覆盖是否到位、失效是否及时暴露。把幻觉这个模糊概念拆成一系列可观测的管线信号之后，团队内部讨论问题就具体多了。

6. 边界、成本与迭代顺序：一些踩坑后的个人体会

6.1 Harness不能消除幻觉，只能让幻觉“可发现、可拦截”

走到最后，我想先泼一盆冷水：Harness做得再好，也不能彻底消灭幻觉。因为模型的生成机制本身决定了，它永远有概率输出失真内容。Harness的价值在于把幻觉从“用户不可见”变成“可发现、可拦截、可修正”，把致命伤害降低到业务可接受的范围内。

我见过一些团队追求“零幻觉”目标，把校验阈值调得非常严格，结果大量正常回答被拦下来，用户体验崩了，项目也黄了。正确的工程目标是“幻觉造成的业务影响可控”，而不是“幻觉不再出现”。理解了这一点，你就会明白为什么前面所有方案都在谈“拦截”和“兜底”，而不是“根治”。

6.2 延迟、成本、准确性：三角形的取舍没那么难

防幻觉体系不是免费的。检索层增加延迟，校验层增加计算成本，LLM评审更是吞钱大户。我一般会给“防幻觉的强度”分等级：核心链路（涉及金钱、健康、身份信息）上全套防御，中间链路只要过程和结果校验，外围链路只做提示词约束。分级管理，既守住风险，又控制成本和延迟。

分级之后还要做可观测的动态调优。如果某个场景拦截率一直很高，但人工复核后又发现拦截得对，那说明这个场景本身的风险高，应该评估是否加更高的防御级别；如果拦截率很高但绝大部分都是误伤，那就要把校验规则从“宁可错杀”调到“精准打击”。

6.3 迭代顺序：先固定痛例，再动结构

给正准备动手的团队一个建议：不要一上来就铺开做全套Harness。先做一件事——把最近一个月线上用户投诉中，所有和“Agent胡说八道”相关的案例捞出来，逐条标好类型、根因、当时上下文，建成一个“痛例集”。

然后针对这个痛例集，一次只解决一个类型的幻觉。比如这一轮只治“事实性捏造”，那就先加检索层和引用校验；跑通、看指标、看退化，稳定了再治“工具误读”。这个顺序的好处是，每一次改动都有明确的目标和验证标准，不会出现“东西都加了但不知道是谁起效”的糊涂账。

6.4 最后分享一个很朴素的心得

搞了这么久Agent防幻觉，我最深的一个体会是：最有效的防幻觉方案几乎都绕不开“可追溯”三个字。给回答加引用来源、把工具返回原样透传、给评测集保留线上事故记录、让每次变更都能回放，这些做法本质上都是为了让系统里的每一句话都有据可查。

幻觉这个东西，最让人头疼的地方是它“不可观测”。一旦你通过Harness把不确定性的来源、流向和出口全部标记得清清楚楚，它就从玄学变成了工程问题，而工程问题，终究是能被分解、被解决、被量化的。这大概就是Harness Engineering这门“手艺”最值得投入的地方——不是为了让模型变聪明，而是为了让整个系统变可靠。