大模型幻觉治理：Harness Engineering如何把胡说八道关进笼子

1. 大模型为什么会“一本正经地胡说八道”1.1 概率生成的AB面聪明和胡话是同一个引擎先说一个可能颠覆部分读者认知的事实大模型的“聪明”和“胡说八道”不是两种模式而是同一套机制的两面。现在主流的大模型本质上是一个超大的条件概率系统。它做的事情就是在给定上文的情况下预测下一个词的概率分布然后按概率采样选出最合适的词。这个机制决定了模型说话的逻辑——它不是在“查询数据库”不是在“回忆事实”而是在“续写”。你问它“中国的首都是哪里”它不是检索出“北京”这个事实条目而是根据训练数据中学到的语言统计规律一步步把“北京”这个词“续写”出来。这个过程中模型对“正确答案”的依赖其实是对“统计上合理的答案”的依赖。当训练数据里某个事实足够多、足够一致时统计上的合理答案就是正确答案但当数据稀疏、矛盾或者问题偏离训练分布时统计上的合理答案可能就是一个看着像样、实则虚构的东西——这就是所谓的“做梦”业内叫幻觉Hallucination。我见过很多刚接触大模型开发的人会误以为幻觉是模型“笨”或者“某个bug”。但实际上幻觉是生成式模型的结构性副产品。你不可能通过“训练得更好一点”完全消除它就像你不可能训练一个人类永远不会记错。真实世界的信息本来就存在噪声、矛盾和缺失模型只是把它们学到的模式折射出来而已。理解这一点是后面所有驾驭手段的前提。1.2 幻觉的四个来源数据、结构、对齐和采样如果把幻觉按根源拆开看基本可以分成四类第一类是训练数据本身的问题。数据里如果有错误信息、过时信息、互相矛盾的说法模型就会“学歪”。比如某年的新闻数据里某个事件被误报模型之后就一直“咬定”错误版本。这类幻觉在数据层面几乎无可避免因为大模型的训练集是海量抓取的没法逐条人工审核。第二类是模型结构的固有局限。大模型的参数量是有限的它的知识编码方式是“压缩”的。就像你用一个很小的抽屉塞进百科全书必然有一些条目被折叠、模糊化。当模型从压缩表征中还原细节时就会发生变形和错位——这会导致某些细节被张冠李戴。第三类是对齐训练带来的偏差。为了让模型更有用、更“讨喜”训练阶段会加入人类反馈强化学习RLHF。这个过程中模型学会了“即使不知道也要尽量回答”。你在产品里问它一个冷门问题它宁可编一个流畅的答案也不愿意说“我不知道”。这个倾向就是对齐训练直接塑造出来的。第四类是采样过程的随机性。生成时温度参数temperature不为0模型就会在概率分布中采样留下一定的随机性。这个随机性如果赶上概率分布比较平坦——也就是多个候选词的概率相差不大——模型就可能随机选中一个偏离事实的方向。实测下来前两类幻觉最“硬”靠提示词很难修正后两类幻觉则是工程手段可以压制的重点。Harness Engineering的一大部分工作就是在第四类和第三类上做文章用成本和延迟换取可信度。2. 所谓“驾驭工程”到底在驾驭什么2.1 Harness Engineering的概念边界别和Prompt Engineering混为一谈“Harness Engineering”驾驭工程这个词在中文社区里还没有特别统一的译法但它描述的实践方向越来越清晰它不是“问得更好”而是“用工程手段把模型的不可控性约束在可控范围内”。这个词里的“驾驭”很形象就像驾驭一匹马——马本身有自己的脾气有跑的冲动你不能彻底把马变成机器但你可以通过缰绳、马鞍、路径规划让它的能量释放到你想要的方向。对比一下几组概念边界就清楚了。Prompt Engineering提示工程做的是“输入侧”的优化怎么写指令、怎么给例子、怎么设计few-shot目的是让模型更准确地理解需求。而Harness Engineering做的是“系统侧”的约束在模型外面套一层工程框架把模型的输出纳入校验、纠错、兜底、路由、分解的闭环里。你可以提示工程学得很好但模型照样会“做梦”而驾驭工程的目标是让“做梦”不影响系统层面的正确性。再对比微调Fine-tuning。微调是“改模型本身的权重”投入大、周期长而且训练完可能引入新的问题。驾驭工程是“不改模型只改模型周围的世界”相对轻量、迭代快适合大多数应用团队。我个人的习惯是模型能力不够或者特定领域风格差异太大时才考虑微调而不管是否微调驾驭工程这一层框架永远不能省。2.2 驾驭工程的六大支柱把这几年在多个项目里沉淀的经验收拢一下驾驭工程的完整体系大致包括六块结构化输出约束。这是最基础但也最容易被做崩的一层。让模型按照约定的JSON Schema、代码结构或固定模板输出从机制上消除格式层面的“自由发挥”。具体实现上工程上要么靠强提示词示例要么靠约束解码——直接在小模型套大模型的归一化层上做遮挡只允许生成符合语法要求的token。后者的可靠性远高于前者。信息检索增强RAG。把外部知识库挂在模型外面让模型“开卷答题”。本质上不是让模型“记住”知识而是让它在回答时参考给定的上下文片段。这样即使模型自身没有某个事实它也能从检索到的内容里取用。RAG的工程核心在于检索质量、上下文拼接策略和引用追溯机制的结合。工具调用与代码执行。把计算和精确逻辑从模型中剥离出去。需要算数就让模型写代码让代码执行环境去算结果直接拼回回答里需要查天气就让模型发起API调用用真实返回值来顶替编造。这一层把模型从“知道一切的说书人”降格为“调度员发言人”大幅度减少事实性幻觉的空间。输出校验与纠错。对模型的输出做规则校验和事实核查。校验规则可以是行号引用是否真实存在、JSON是否可解析、数值是否落在合理范围事实核查可以用交叉验证——拿另一份独立数据来对账。校验不过就重试、修正或拒绝回答。置信度感知与路由。让模型在回答的同时给出置信度估计或者通过多次采样检测一致性。低置信度的问题直接路由给人工或者触发更保守的处理流程。这一步是对“模型不知道却硬答”这种对齐偏差的直接对冲。会话管理与状态追踪。长对话中模型经常会因为上下文混乱而“梦游”——比如把用户前面说过的信息记错或者自己说过的话前后矛盾。驾驭工程要求系统层维护状态把关键信息持久化、结构化而不是让模型用自己的注意力去“记住”。这六块互相配合基本可以把“做梦”的影响从“产品级事故”压到“偶发瑕疵”。下面我会重点展开讲其中最常用的几条路线和实操细节。3. 从“做梦”到“可控”可落地的四步路线3.1 第一层约束输出格式必须“锁死”我的习惯是任何进入生产环境的大模型API调用第一件事就是锁输出格式。如果你给模型一个完全开放的文本框让它随意发挥那后面一切校验手段都是事后的、被动的。反过来如果输出格式是结构化的很多幻觉直接在格式层面就被拦截掉了。具体操作上分三个台阶。第一个台阶是把JSON结构写死在提示词里并且附上一个完整的示例。注意很多团队只贴了JSON结构的说明文字没有贴示例输出模型照样生成没法解析的垃圾。示例的价值不只是“展示格式”而是在概率空间中给模型一个“锚点”把生成路径往正确的格式分布上牵引。第二个台阶是开启模型的JSON Mode或者约束解码。用开源模型做本地部署的同学可以看一下推理框架是否支持GBNF语法约束或JSON Schema导出的正则约束——这类能力可以在解码阶段禁止模型生成不符合格式的token。举个具体例子某个字段被定义为“数字”约束解码时模型根本不可能在这个位置生成字母某个字段被定义为“枚举值”模型只能在给定的几个值里挑。这就相当于给模型戴了一个“模具”它想胡来都没机会。第三个台阶是在代码层做二次防御。哪怕模型已经约束输出我还是会在调用后加一个JSON解析的try-catch并且接一个“解析失败自动重试一次”的兜底。重试也没什么复杂的就是把提示词不变原样再发一次很多格式问题重试一次就好了。还有一个小技巧在前端配合“流式解析”边收token边校验结构完整性有问题当场截断重来体验上会好很多。这三个台阶下来格式层面的“做梦”基本绝迹。这套做法在几个项目上落地后JSON解析失败率从早期的一两成降到了千分之几而且耗时几乎没增加。3.2 第二层约束开卷比闭卷稳得多“让模型做开卷考试”是压制事实性幻觉性价比最高的手段。这里说的开卷不只是把资料塞进上下文而是要把参考资料做成模型可以“引用”的结构化形式。先看检索侧。我见过很多团队做RAG检索回来的文本直接粗暴地拼进上下文这其实效果很差。原因是模型面对的是一大坨高密度的文字它分不清哪些部分是回答当前问题需要的哪些是附近段落里的干扰信息。正确的做法是——把资料切成语义块块与块之间用显式的标记符隔开并且为每个块分配一个可见的ID。然后在系统提示词里写一句“引用资料时请在回答中标注对应ID。”这样模型在生成时会被引导到指定的块上取信息而不是在整堆文本里盲目搜索。再看上下文组织。我通常会把检索结果放在一个固定区域标注“参考材料开始”和“参考材料结束”并在提示词里写明优先使用参考材料作答参考材料未涵盖的内容明确回答“不知道”。这两句话看着简单但对幻觉的削弱作用非常明显——它把一个“必须给出答案”的指令改成了“必须基于给定材料给出答案”。模型获得了一个“合法的拒绝通道”就不会被前面说的RLHF“尽量回答”的偏向逼着编造了。在拼接策略上还有两个细节值得说。第一参考材料不要贪多。很多团队把Top-10甚至Top-20个片段全塞进去结果相关的内容被淹没在噪声里回答质量不升反降。我常用的做法是从检索结果里取Top-3到Top-5个片段同时按相似度从小到大排列最相关的排在最前面。第二片段长度要控制。理想情况下单个片段不要超过模型上下文窗口的一个小尾数比如窗口是8K时每个片段控制在1K左右宁可多切几个块也不要每个块都又长又全。这一套落下来开放问答场景下的事实性错误能明显下降而且有个很重要的副产物——引用可追溯。当回答标注了引用ID给用户的体验会完全不同。他可以自己点开参考片段核对就算模型说错了用户也不会觉得是系统在瞎编而会觉得是资料的问题。3.3 第三层约束把“想象”替换成“执行”有一类幻觉特别容易让人忽略模型做数学题、查时间、查地点这类“精确计算”任务时表面看着很流畅答案却完全不对。这种幻觉的本质是模型用语言统计规律在“猜答案”而不是在真正“计算”。应对思路也很直接——让模型不要猜让它调用工具算。拿数学题举例。你让模型口算“某年某月的第100个工作日是哪天”它当然会一本正经地给出某个日期。但如果你提示词里写“先写出计算用的Python代码在代码执行环境里算出结果再基于执行结果回答”模型把问题转成代码的能力本来就经过大量训练而代码执行结果是精确的这就把“猜测日期”变成了“执行确定性程序”。工程上有两种接入方式。一种是函数调用模式模型根据对话语义自行决定调用哪个函数参数填好之后由系统去执行执行结果回填给模型再组织最终回答。这个方案适合“模型知道自己需要工具”的场景比如查天气、查汇率、做计算。另一种是代码解释器模式模型生成一段代码系统在沙箱里运行它把stdout结果作为“标准答案”的一部分模型在此基础上生成最终回复。这个方案适合“没有现成API但问题可以转成代码执行”的场景。我强烈建议在任何想接入外部数据的Agent项目里尽早引入函数调用。举个例子某个内部知识管理助手早期只做RAG遇到“A文档引用过哪些B文档”这类关系类问题经常胡编。后来给模型加了一个文档图谱查询的API让它遇到这类问题先调接口幻觉问题直接消失了——因为模型不再是“猜”引用关系而是从真实数据里查。当然工具调用也有自己的坑。需要校验模型填的参数是否在合法范围内需要给工具调用设置超时和异常分支还需要让模型具备“工具调用失败时向用户如实说明”的能力。但总体而言把推理交给代码、把数据交给接口之后模型真正需要“发挥创造力”的空间只剩组织和表达——这两件事恰恰是它的强项。3.4 第四层约束回答之前先思考三次严格来说第四层不是一个独立的工具而是一套“行为策略”。核心是把“生成前、生成后、交付前”三个环节都加上主动的质量控制而不是等结果出来了再去救火。生成前做“任务分解”和“方案判定”。碰到复杂问题先让模型输出一个简短的思路规划这个问题需要哪些信息哪些信息我可以直接给出哪些我需要查资料哪些需要调用工具这个思维链不一定全部展示给用户但要让它自己走一遍。经验是强制模型“先想后答”能显著降低跳过关键推理步骤的幻觉因为链式推理过程中每一步都受上一步的约束统计上的随机性被链条的依赖性压住了。生成后做“自我核查”。让模型把刚才的回答重新读一遍对照参考材料/工具结果逐条检查正确性指出不确定的内容。这个做法看起来绕——多一次调用就多花一次钱——但对高价值场景非常值得。我习惯把这层自我核查做成“判断题”而不是“问答题”给模型列出原回答的几组核心陈述让它一对一判定“支持/不支持/无法判定”。判定逻辑更简单模型说“哪些不确定”的能力比重建正确回答的能力要强得多。交付前做“硬校验”。这一层就是纯规则了。校验引用ID是否都在参考材料里、校验JSON结构是否合法、校验数值是否在业务合理区间内、校验敏感词是否被拦截。规则引擎写死不走模型判断。说实话就算前三层全部失效这一层兜住了用户看到的也不会是“幻觉事故”最多是“系统提示某条信息有待核实”而已。四层约束全部落地的体验是模型还是那个会做梦的模型但在它周围织了一张网梦里出错的东西碰不到用户。这正是Harness Engineering最核心的心法——不追求模型不犯错追求系统不犯错。4. 工具选型与参数调优实录4.1 主流大模型的服务化选型对比先说一句很多人不爱听的不存在“零幻觉”的大模型只有“幻觉分布特征不同”的模型。选型时应该关注的不是谁更“准确”而是谁的错误模式更适合你的驾驭框架来兜底。如果走云端API路线过去我用得比较多的是两类一类是带原生结构化输出能力的另一类是带函数调用协议的。带原生JSON Schema支持的模型在约束解码层面做得比较省心——你不需要自己在推理框架上做正则约束直接在API参数里声明输出结构就行。函数调用方面模型能否稳定输出正确的函数名和参数直接决定了工具层方案搭建的难度。如果走本地部署路线目前在开源模型里比较热门的是两类一类偏综合能力指令跟随和推理都还行适合做对话场景一类偏代码/逻辑工具调用尤其见长适合Agent场景。本地部署时还要重点关注推理框架对结构化输出的支持程度有些老牌框架支持GBNF或者JSON Schema部署起来如虎添翼不支持的话你可能要在采样层自己写约束解码那工程量就不是一两天的事了。我给一个具体的选型看法新手团队如果短期要上线直接选云API加官方结构化输出不要自己做太多底层约束有一定工程能力、数据敏感、需要私有化部署的团队再考虑开源模型加自定义约束解码。前者的优势是省心、迭代快后者的优势是可控、成本可押注但坑也多后面小节细说。4.2 关键参数温度、Top-P与重复惩罚的联动调整模型推理参数看着不起眼但实际对幻觉的影响比很多提示词都大。这里把主要参数讲透方便大家直接抄作业。温度temperature控制采样的随机程度。温度越高越可能选概率低的词模型越“天马行空”温度越低越可能选概率最高的词输出越保守。不少团队为压制幻觉直接“温度0”这个做法有点用力过猛——会让模型几乎没有多样性稍微复杂一点的任务反而更容易陷入重复或卡壳。我的经验是事实性问答、信息抽取这类场景温度开到0.10.3创意写作、头脑风暴这类场景再放开到0.70.9。如果模型版本较新对“温度0”的支持较好可以试但务必做回归测试。Top-P核采样控制采样时只看概率累计到P的候选词集合。Top-P越小候选池越窄输出越稳定。实际调参时我建议温度优先Top-P其次。两者不要同时“拉满”比如温度设为0.2Top-P设为0.9效果通常已经够稳。重复惩罚frequency penalty / presence penalty惩罚重复token出现的概率。这个参数对压制“车轱辘话”有用但别开大。开太大模型会刻意选择非常规词汇反而更容易跳出事实边界。我的做法是在需要长文本输出时设置轻微的重复惩罚在事实问答里直接关掉。最大生成长度max_tokens这算是被忽略的反幻觉利器。让模型一次性回答太长的内容后半段极容易出现事实漂移和废话。合理的做法是把大任务拆成多轮子任务每轮限制在较短的生成范围内。比如一篇800字的产品分析不要让它一口气生成而是先让它列大纲再分段生成每段限制150200字。这比一次性长输出稳定得多——原理也不复杂生成链越短累积误差越小。4.3 RAG和工具调用的超参设置RAG超参方面最值得我们调的是检索数量Top-K和相似度阈值Score Threshold。Top-K控制在35之间够用且不会引入太多噪声。相似度阈值用来砍掉“不高不低”的干扰片段低于阈值的宁可放弃也不要硬塞进上下文——模型看到一堆低相关片段大概率会强行把它们当作论据使用这本身就是幻觉的一个来源。检索重排Rerank也值得多说一句。纯向量相似度检索在语义理解上还是不够等召回Top-50之后再过一个重排模型才取Top-3到Top-5。这个二次排序的成本很低但对回答质量的提升非常显著。我测试过几组数据加了重排之后引用正确率大概能再涨一到两个档次。工具调用超参方面核心是超时和重试次数。给外部API一个明确超时比如5秒超时了直接让模型回复“当前暂时无法获取该信息”而不是让它兜底猜一个答案。重试次数不要超过一次——第二次还超时大概率是服务端不稳定再多试只是浪费资源。4.4 一个小型场景的完整参数配置参考为了让大家有个具体参照这里放一个之前做过的“文档问答机器人”侧写。场景是某公司的内部制度库问答要求回答基于制度原文事实不可编造。模型参数温度0.2Top-P 0.9不开启重复惩罚输出长度上限500。检索参数向量检索召回Top-50重排后取Top-4相似度阈值0.6。上下文拼接每个片段控制在8001000字片段前加标签系统提示词里写明“引用片段时标注片段ID”。结构化输出JSON Schema声明字段结论、依据、引用ID列表、置信度开启约束解码。兜底策略置信度低于0.7时回答改为“我无法从给定制度原文中找到明确依据建议咨询人工”。校验规则校验引用ID是否存在于本次检索结果中不存在则触发重新生成最多一次。这个配置运行下来非常稳定用户的整体满意度也很高。配置本身不算有多高深但每个环节都在让模型的自由度收窄、可信度上升组合起来效果才会体现出来。5. 实战中的常见问题与排查手记5.1 JSON格式反复崩溃别只怪模型JSON格式问题在项目上线初期最磨人。现象是模型明明已经被要求“只输出JSON”却偶尔在JSON里插入解释性语句、遗漏字段或用单引号代替双引号。我的排查顺序是这样的第一确认你的提示词里是否给了“完整且唯一”的JSON示例——给了之后再看模型版本是否是较新的版本第二检查输出参数里是否有max_tokens限制得过紧的问题——截断是JSON解析失败的头号隐藏元凶回答到一半被截断了后面半个括号没了第三确认你是否开了结构化输出/约束解码——如果开了还崩那大概率是你声明的Schema和实际提示词里的字段不一致模型两边不知道听谁的。如果排查完还是间歇性崩我建议直接在代码里加“解析失败自动重试”的兜底。重试时的提示词可以加一句“你上一次的输出不符合JSON格式请修复后只返回合法的JSON”实测下来成功率很高因为模型能意识到自己刚才做错了。5.2 引用标注张冠李戴RAG的经典翻车场景RAG场景里最气人的问题模型回答看着有理有据但你点开引用ID一看那个片段根本不涉及这个信息。这是典型的“引用幻觉”——模型知道你要它标注引用ID但它不确定哪条片段支撑了结论于是随便选了一个比较顺眼的标上去。针对这个问题我的经验是“片段要更小、更明确”。检索回来的片段如果是一大段复合内容模型很难把结论定位到某一个具体块反过来如果你把原文切得足够细每个片段只管一个点模型才可能把“哪个结论对应哪个片段”一一对上。我建议把片段切到“单一主题块”追求精确度而不是完整度——宁可检索回来10个小块也不让它回来3个又大又全的块。另一个对策是“引用ID校验通过后交给用户”而不是完全信任模型。系统侧校验引用ID没有越界是从根源上避免了“用户看到的是毫无关联的段落”。至于模型标注的ID是否是真正支撑结论的那一段这个校验规则很难百分之百做到——那就退而求其次让引用ID至少在“被用户点击验证”时不至于翻车。这个体验落差比完全没有引用要大得多。5.3 长对话越聊越“迷离”状态管理的悖论长对话场景下模型越聊越迷糊的根源几乎不在“推理能力”上而在“上下文窗口被无关内容占满”上。如果你把整段历史全部塞给模型它需要从一大坨对话里找到当前有效的状态信息——这对注意力机制来说负担很大。我的处理方法是“状态外置”把对话历史精简成“结构化记忆”而不是原文堆叠。比如用户中途提过“我公司在杭州人员规模约200人”这个信息如果在后续对话中依然有效就抽出来放到一个独立的“用户画像区”等到回答需要参考时再把这条记忆注回上下文。历史原文本身只保留最近几轮。这个方法落地后长对话的话题漂移问题缓解得很明显。我建议任何对用户画像有依赖的应用场景都考虑引入这种“外置记忆关键信息注入”的模式。你不需要把每次对话都完整喂给模型只需要让它知道最新的、最关键的上下文状态。5.4 问题排查速查表为了方便大家日常排查我把上面这些常见问题整理成一张速查表现象可能原因优先排查项兜底方案JSON频繁解析失败输出被截断 / Schema与提示词不一致检查max_tokens和Schema定义自动重试一次提示修复格式引用ID与内容不匹配检索片段过大过杂缩小片段粒度单点对应单结论系统校验ID是否越界越界则重生成长对话中话题漂移关键信息被历史杂讯淹没状态外置注入关键信息摘要关键信息持久化只回填最近摘要事实性错误频发检索质量差 / 阈值过低调整Top-K和相似度阈值增加重排后再取值逼着回答的“硬答”RLHF对齐导致模型不愿说不知道在提示词中给出合法拒绝通道置信度低时路由人工/模板回答同一个问题答案飘采样参数太高随机性过大降低温度到0.10.3固定seed如模型支持5.5 一个很隐蔽的坑系统提示词和模型权重打架最后想单独提醒一个坑。很多人以为Harness Engineering就是把一堆约束堆在提示词里就完事了但实际效果可能截然相反——因为模型在训练阶段学到了一些固定的行为模式你如果在系统提示词里给出和它的训练偏好相矛盾的要求模型会倾向于忽略你的提示或者两边讨好、输出很别扭的内容。举个例子某些模型在训练时被重点强化了“保持对话友好、多给建议”的倾向。你要求它“只回答JSON不要说别的”——它在服从指令和维持友好之间拉扯偶尔会输出“好的以下是JSON格式的回答”这种带解释的内容。这种问题不是提示词写得不好是系统约束与模型权重发生了冲突。面对这类问题我的建议是不要试图靠提示词硬拧。优先换一个“指令遵循能力”更强的模型或者把约束放在模型外部的解码和后处理环节而不是放进提示词。Harness Engineering的本质本来就是工程系统对模型行为的接管——你要是凡事都依赖提示词那就还没走出Prompt Engineering的舒适区。6. 驾驭工程的下一个台阶失败规划与做人机边界做了这么多约束、校验、兜底之后真正让我觉得这套工程思路“成了”的其实是一次思路上的反转不再追求让模型少犯错而是把失败当成一个预期内的路径给系统设计好失败时的表现。这个思路在Agent场景里特别关键。多步任务的执行链条中模型不可避免会选错工具、猜错参数、编错中间结果。如果系统设计的目标是“每一步都要正确”那这个目标本身就注定要落空。反过来如果你把一个任务拆成多个子步骤每个子步骤都接入校验校验不过就回退到上一步重新规划那整条链路的可靠性就被拉高了。链条上允许有单点失败只要系统能感知到失败并能回退最终结果仍然可控。人机边界的划分也值得重新想。很多时候我们过度追求“全自动”反而把系统搞得又贵又脆。更务实的做法是让模型把不确定的分支明确标出来把低置信度的决策交给人工系统提供“自信模式”和“谨慎模式”默认走谨慎模式遇到简单任务再切自信模式。这样既保住了自动化率也守住了业务底线。我自己在实际项目中得到的一个经验是驾驭工程做久了你的关注点会从“模型说了什么”转向“模型什么地方不该相信”再转向“系统如何优雅地承认不足、安全地降级”。这是一种和生成式AI打交道的成熟姿势——不要相信它但也不要害怕它给它套上缰绳让它在前方跑你在后面掌方向。这套工程方法后续还可以继续扩展比如引入更细粒度的置信度校准来做动态路由比如用外部知识图谱做更严格的引用验证比如在Agent场景里做“计划-执行-验证”的闭环。但无论怎么扩展核心思路不会变接受模型的“做梦机制”然后用系统性工程把梦的边界画得清清楚楚。这才是真正跟大模型做同事的方式。