大语言模型输出跑偏？目标驱动可控架构从四层约束到Agent实践

你有没有遇到过这样的情况：把一个挺简单的问题丢给大语言模型，开头两句还挺像样，越往后越离谱，最后干脆给你跑题跑到天边去了。我第一次调对话类接口的时候，被这种“跑偏”问题折磨得够呛，明明知识库里有答案，模型却一本正经地编出了一套完全不存在的规则。后来我才慢慢想明白，问题不在于模型不够聪明，而在于我压根没有给它一个清晰的目标，也没有在系统层面把它的生成路径约束住。

所谓“目标驱动的可控架构”，说白了就是一套防止模型跑偏、确保输出朝目标终点走的方法论。它不是某个神奇参数，也不是某一段万能提示词，而是一整套从目标定义、任务规划、生成约束到结果校验的分层架构。这篇文章会用最通俗的方式拆解这套架构：先说清楚模型为什么会跑偏，再讲四层约束分别怎么做，然后带你动手搭一个“只回答售后政策”的受控问答模块，最后聊聊长对话里的目标漂移问题和Agent场景下的进阶玩法。无论你是刚接触大语言模型应用开发的新手，还是已经在业务里跑了一阵LLM的开发者，这篇文章都值得花十分钟看完。

1. 模型天生爱发散：先搞懂“跑偏”是从哪来的

1.1 概率采样机制：模型根本不知道“终点”在哪

大语言模型的底层工作原理，本质上是“预测下一个词”。给定前面的文字，它计算出每个候选词的概率，然后从中挑一个作为下一个词。每走一步都像是在往各个方向上撒一把概率，而不是瞄着一个既定目标前进。

这就带来一个很隐蔽的问题：模型并不知道你的任务终点是什么，它只知道自己刚才那句话“顺着说”比较自然。你问“退货运费谁承担”，它第一步极大概率会生成“运费”相关的内容，第二步也可能在正确的轨道上，但到了第三步、第四步，它就开始在“语言上合理”的方向上漂移，而不是在“任务上正确”的方向上坚持。这不是模型变笨了，而是它天生就没有导航系统。

有个参数能直观体现这一点，就是temperature。温度调高，模型每一步的选择更平均、更大胆，发散程度上升；温度调低，选择更集中保守，但也不可能做到百分之百确定。说白了，哪怕你把它调到最低，它每一步依然是在概率空间里挑东西，只是可选范围变小了。想要让它不跑偏，单靠温度远远不够。

1.2 导航式思维：目标驱动与自由生成的根本差异

我特别喜欢用开车来理解这个问题。自由生成模式就像一辆没有设定目的地的出租车，你只管踩油门，车确实在跑，但跑哪里完全看路况和司机的心情。目标驱动的可控架构则像打开导航：先设定终点，再按路线走，中间一旦偏离，导航会立刻提示并重新规划路径。

这套思维方式放在大语言模型上，就是两条铁律。第一，先定义终点，也就是明确“我要什么结果、什么格式、什么边界”，比如“只回答售后政策”“输出必须JSON结构”“如果问题不在范围内就直接拒绝”。第二，再约束路径，也就是把从输入到输出的过程拆成可控的几步，每一步都有明确输入和输出。模型在终点明确、路径受控的情况下，跑偏的概率会大幅度下降。

有个有意思的细节是，约束放得越早效果越好。在系统提示层面做限制，比在对话过程中纠正有效得多；在生成之前用门控挡住越界问题，比生成之后打补丁靠谱得多。这和开车同理：出发前就设定导航，比开到一半再掏出手机输地址要稳。

1.3 可控架构的真正含义：给马路装上护栏

这里要澄清一个常见的误解：可控架构不是要把大语言模型变成一个输出死板的机器，而是给原本自由的道路装上一层护栏。模型依然负责生成内容、推理、组织语言，护栏负责保证它不驶出合理范围。

我最早犯过的错误就是试图靠“记住正确答案”来防止跑偏，把一堆标准答案全塞进提示词里，结果上下文被撑得很长，模型反而把示例当成模仿对象，回答得花里胡哨却脱离了业务规则。后来我学着把控制逻辑拆到架构层面，让提示词负责目标声明，让门控负责拦截越界请求，让解码约束负责格式稳定，让外部校验负责内容正确。每一层只管一件事，出了问题也能快速定位。

这个思路，贯穿了下面要讲的四层约束架构。

2. 四层约束架构：从目标定义到反馈闭环

2.1 目标层：把“我要什么”写进系统提示

目标层是整个可控架构的地基。你要让模型不跑偏，第一件事就是把它应该听令的目标写清楚。绝大多数时候，这个目标放在系统提示（system prompt）里，而不是用户消息里。

一个合格的目标声明至少包含五个要素：角色、任务、边界、输出格式、失败处理。举个例子，我搭的一个售后问答模块，系统提示是这样的：

你是某电商平台的售后政策问答助手。 你的任务：只回答关于退换货、物流、发票、售后时效的问题。 边界：不闲聊、不回答其他领域问题、不做品牌评价、不提供法务建议。 输出格式：以JSON格式返回，包含 "reply" 字段。 失败处理：如果问题不在上述范围内，reply 直接回复“该问题不在受理范围，请咨询客服”。

这里面的每一个要素都在干一件事：收敛生成空间。角色限定视角，任务限定方向，边界告诉模型哪里不能去，输出格式让程序能直接解析，失败处理给了模型一个“不知道怎么答时的安全出口”。五个要素缺一个，跑偏概率就高一分。比如不加失败处理，模型遇到范围外问题就倾向于硬编一个答案，你反而不容易发现它跑偏了。

有人可能会问，为什么系统提示里的目标比对话中临时强调更管用。一个很重要的原因是系统提示在每个请求里稳定存在，并且会被模型视为更高优先级的指令来源；而用户消息里的临时指令容易被后续内容干扰和稀释。所以，核心目标永远放在系统提示层，对话过程中的提醒只能作为辅助。

2.2 规划层：把大目标拆成模型接得住的小步骤

目标定义清楚之后，还要解决另一个问题：目标太大、太模糊，模型还是会懵。你让它“对比三款产品并给出建议”，它可能直接从第一款的参数跳到结论，中间漏掉一大堆该做的事。这时候就需要规划层介入。

规划层有三种常见做法，按控制强度从低到高排列。第一种是提示模型“先想后答”，也就是思维链方式，让模型把推理过程先写出来，再给最终答案。这种方式实现简单，但推理过程占token多，而且模型有时候会把心里话直接说出来，体验不友好，通常需要做“内部推理+最终输出”的两段式。

第二种是显式子任务拆解，在请求里直接列出步骤列表，要求模型按步骤执行。还拿对比产品举例，你可以让模型依次完成：分别提取A、B、C三款产品的核心参数，生成两两对比表，最后根据指定维度输出结论。每一步都有明确产物，模型就不太容易跳过中间过程。

第三种是独立的规划器模块，让一个单独的模型调用把这些步骤拆成结构化子任务，返回一个任务清单，主流程再逐个调度执行。这种做法控制力最强，适合流程复杂的场景。我见过一个比较稳的写法，规划器返回一个JSON数组，每个元素包含步骤ID、动作类型、输入参数，主程序读这个数组按顺序执行，可控性非常好。

规划层的核心逻辑是：模型的任务单元越小，越容易被约束住。拆解本身就是在给目标安装一个个路标。

2.3 执行层：解码参数与输出格式的硬约束

目标和路径都定了，接下来是生成环节的约束。这个层有两个抓手，一个是解码参数，一个是输出结构。

解码参数方面，最常用的就是temperature和top_p。我在事实性任务里普遍把temperature设在0.2左右，因为售后问答、参数提取这类任务不需要创造性，越保守越好；只有创意文案、头脑风暴这类任务才需要把温度调到0.7甚至更高。记得有次我图省事，所有任务都用了同一个默认温度参数，结果一个客户标签抽取模块时不时冒出莫名其妙的词语，把日志翻出来一看才知道是采样太激进。参数这个事，真得按任务类型单独配置。

输出结构方面，如果你的结果要交给程序解析，务必让模型输出结构化数据。现在主流模型接口基本都提供JSON模式或类似能力，直接限制输出为合法JSON，再由程序做字段校验。结构约束的价值不只是方便解析，它还能逼着模型把答案压缩到一个固定框架里，有效抑制发散。比如售后问答让模型返回这样的结构：

{ "intent": "in", "category": "return_policy", "reply": "您购买的这款商品支持7天无理由退货，运费由买家承担，特殊情况请咨询客服。" }

程序拿到这段JSON，先校验intent和category字段，再展示reply内容。一旦模型输出不符合结构，直接重新生成或走兜底话术，不会污染用户体验。

但要注意，输出格式约束只是让形式可控，并不能保证内容正确。模型的生成过程依然是概率性的，所以还需要最后一层兜底。

2.4 校验层：给模型一面“照妖镜”

校验层的职责，是确保模型生成的内容确实符合目标，而不是表面看起来像那么回事。它有三个常用手段。

第一个是自我检查，让模型重新读一遍自己刚才的答案，对照目标声明找出不符合的地方，再输出修正版。这个方法成本低，但对逻辑性错误和事实性错误有一定效果。实际操作中我会让模型先输出“审查结论”，再输出修改后的答案，两步分开，避免它把审查环节糊弄过去。

第二个是外部工具校验，用知识库检索、数据库比对、规则引擎等外部手段来验证答案中的关键信息。比如售后问答模块，模型回答里出现退货时限，程序就从知识库里抽取出对应规则来比对，一致才放行，不一致就触发重新生成或者返回固定话术。

第三个是人工抽检和日志监控，面向长期运行的线上系统。记录每一轮的输入、意图判断、生成参数、最终输出，定期抽样看有没有隐性跑偏。这个方法看着笨，却是我抓问题最多的地方，很多目标漂移的苗头都是通过回看日志发现的。

校验层是整个可控架构的“安全网”。前面三层做得再好，也挡不住概率模型偶尔抽风，有了校验层，你才有机会在坏结果到用户手里之前把它拦下来。

3. 动手搭一个受控问答模块：模拟项目X的售后问答

3.1 场景与边界定义

前面讲了那么多理论，现在来看一个完整的迷你实践。场景是我搭过的模拟项目X里的一个模块：内部知识库售后问答。需求很简单，用户提的问题如果属于退换货、物流、发票、售后时效，就给出对应的政策答复；如果不属于，直接拒绝并引导转人工。

这个场景非常适合演示可控架构，因为它目标清晰、边界明确、容错率低。我给自己定了三条硬性要求：第一，绝不回答知识库之外的问题；第二，输出必须结构化，方便嵌入客服工作台；第三，多轮对话中用户一旦越界，立刻回到拒绝话术，不被带偏。

边界定义清楚之后，整个架构就围绕这三条硬性要求来搭。

3.2 意图门控与结构化输出的最小实现

整个模块分两个环节：意图门控和受控生成。意图门控是第一道闸门，用一个轻量的模型调用判断用户问题是否在售后政策范围内；判断结果为“in”才进入生成环节，为“out”直接返回固定话术。

我不让所有问题都直接进生成环节，是因为生成环节越少处理无关请求，跑偏的机会就越少。这跟客服团队先让机器人分流再转人工是一个道理。下面是简化版的伪代码：

def handle_question(user_input, history): # 第一步：意图门控 gate_prompt = f""" 判断以下用户问题是否属于售后政策范围。 范围包括：退换货、物流、发票、售后时效。 只输出 JSON：{{"intent": "in" 或 "out"}，不要解释。 用户问题：{user_input} """ gate_result = llm(gate_prompt, temperature=0.1, json_mode=True) if gate_result["intent"] == "out": return {"reply": "该问题不在受理范围，请咨询人工客服。", "category": "rejected"} # 第二步：受控生成 system_prompt = get_after_sales_system_prompt() answer = llm(system_prompt + f"\n\n用户问题：{user_input}", temperature=0.2, json_mode=True) return answer

代码里有两个细节值得注意。一是意图门控用了极低的温度，因为“是或否”的判断需要确定性，不需要任何发挥空间。二是生成环节的prompt里没有塞历史对话，只传当前问题。我故意这么设计，因为售后政策问答本身是单轮知识查询，带上历史对话反而容易让模型把闲聊内容当成背景知识，增加跑偏风险。多轮信息该不该传，要看任务本身是否依赖上下文，不是越多越好。

售后场景的系统提示延续前面的五要素写法，我会额外强调一条规则：答案内容以知识库为准，如果知识库没有对应信息，允许回复“该问题需人工核实”。这条规则等于给模型开了一个合规的“不知道”出口。没有这个出口，模型就会为了显得专业而编造答案。

3.3 实测中遇到的三个边界case

模块跑起来之后，我陆续撞到过几个典型的边界情况，这里记录下来供你参考。

第一个case：用户问“你们平台和B公司哪个售后好”，模型居然真去对比了两家平台的售后政策。问题在于我只限定了“不闲聊，不回答其他领域”，却没明确禁止“品牌评价”，模型默认把对比解读成了知识范围内的事。修复办法是在边界声明里直接加一条“不做任何品牌或平台间比较”。

第二个case：用户在对话中说“你刚才那条政策是错的”，模型马上道歉并试图换一种回答。这是一个很隐蔽的跑偏方式，用户的质疑本身不是知识库内容，模型却把它当成了修正信号，导致答案飘离规则。修复办法是在系统提示里写明：售后规则以知识库为准，不因用户质疑而改变；如果用户坚持异议，引导转人工。

第三个case：多轮场景下用户先问了一个售后问题，紧接着说“顺便问下今天天气”，模型竟然顺着话题开始预测天气。这说明意图门控只在首轮生效了，第二轮之后被当成了闲聊延续。解决办法是把意图门控放在每一轮，而不是只在会话开头判断一次。这个改动很简单，但很多人都会忽略。

这三个case给我的教训是：边界声明不只是写出来就行，要反复审视“哪些话没说死”，并且要让门控在每一轮都生效。可控架构是防出来的，不是调出来的。

4. 目标漂移问题：一次完整排查过程与修复

4.1 目标漂移的典型表现

目标漂移，指模型在较长的对话或较复杂的任务中逐渐偏离最初目标的现象。它和偶发的跑偏不同：偶发跑偏是一步走错，目标漂移是整个过程一步一步滑向另一个方向，往往在十几轮之后才变得明显。

最典型的场景是客服机器人。开头几轮，模型还守着售后政策；聊到十几轮，用户开始聊产品使用技巧，模型也跟着聊起来；再过几轮，用户诉苦说心情不好，模型又开始做情感陪伴。每一步看起来都算合理，但整体目标早从“售后问答”变成了“闲聊”。这种渐变式的漂移比突然跑偏更难发现，也更容易让业务方头疼。

4.2 排查链路：把问题钉死在具体某一层

有一次我负责的问答模块上线后，运营反馈某个用户对话到第6轮时，模型开始回答超纲内容，回答里出现了几段明显不属于知识库的话。我带着“目标漂移”这个假设，按分层架构逐层排查。

第一步查意图门控。我把那轮对话的完整请求日志调出来，发现用户的问题“你们对老客户有没有额外优惠”通过了门控，被判断为售后政策范围内的“in”。但严格来说，这个问题属于营销政策，不是售后政策。这说明门控的判定范围写得太宽，把“政策类问题”全吸收进来了。这是一个隐患，但不是回答超纲内容的直接原因，因为生成环节还有边界约束。

第二步查生成环节的解码参数。当时这个模块为了兼顾多轮对话的流畅性，把temperature设成了0.7，明显偏高。我先把温度降到0.2，重新用同样的话术跑了几轮，超纲内容确实少了，但第6轮那个问题依然偶尔会出现一段“会员等级说明”。参数只能收敛概率，不能根治方向性问题。

第三步查系统提示。我把系统提示拉出来逐句读，发现问题出在结构上：目标声明放在第三段，而前两段塞满了对话示例和历史回答风格。模型在处理长对话时，注意力会被前面的示例带走，误以为“模仿示例话术”比“遵守目标声明”更重要，于是在第6轮开始自由发挥。我把目标声明提到系统提示的第一段，并且加了一条硬规则：如果问题不在知识库范围内，直接回答“这个问题需要人工核实”。

改完之后，用同样的对话序列回归测试，连续跑二十次，没有再出现一次超纲回答。这次排查给我最大的收获是：分层架构的价值就在于能把问题钉死在特定层面。门控问题、参数问题、提示词结构问题，在三层里分别排查，很快就能找到真正的病灶。

4.3 软约束与硬约束：两种方案的选型对比

在这次排查过程中，我重新梳理了一遍软约束和硬约束的适用范围。所谓软约束，是指通过提示词、参数、思维链等方式“引导”模型；所谓硬约束，是指通过代码逻辑、格式限制、外部校验等方式“强制”模型。

我的选型原则很简单：关键业务目标用硬约束兜底，体验类目标用软约束调优。拿售后服务来说，“是否受理”用硬门控，“回答的语气是否友好”用软提示。软约束负责让模型像个正常客服，硬约束负责让它不捅娄子。两者配合，比单靠哪一边都可靠。

5. 从单个任务到Agent：目标驱动架构的进阶打法

5.1 多目标冲突时的裁决机制

前面的问答模块只有一个目标，但真实Agent里往往是多目标并存。比如一个客服Agent既有“快速响应用户”的目标，又有“答案准确”的目标，还有“不越权操作”的目标。这些目标在特定场景下会打架：想准确，就要多查几轮知识库，速度快不起来；想快，就容易答得粗糙，准确性下降。

解决冲突的办法，是给目标排优先级。在Planner的指令里显式写明：“准确性优先级高于响应速度；当两者冲突时，以准确性为准”。模型执行任务时如果遇到冲突，就按这个优先级来决策。更进一步，可以把目标编码成带编号的规则列表，让模型在每一步决策前引用编号。比如“依据目标1，本次回答需要先检索知识库”。这就把目标从抽象文字变成了可引用的决策依据，漂移的概率小得多。

5.2 Planner-Executor-Evaluator模式怎么落地

多目标Agent里最常用的架构模式是Planner（规划器）-Executor（执行器）-Evaluator（评估器）三段式。Planner拿到用户请求，把它拆成子任务列表；Executor按子任务逐个执行，每一步可以调用模型也可以调用工具；Evaluator对每一步的结果打分或校验，不通过就带着错误原因返回Planner重新规划。

我之前搭过一个小型Agent，任务是自动整理用户反馈并生成周报。最初版本只让模型一次性生成周报，结果经常漏掉重要反馈，分类也颠三倒四。改成三段式以后，Planner先列出步骤——提取反馈、按主题聚类、统计高频问题、生成摘要，Executor逐项执行，Evaluator最后检查摘要是否覆盖了所有高频反馈。整个过程可控性明显提升，因为每个子步骤都有明确输入和可验证的输出，而不是一团模型自由发挥的结果。

这个模式的本质，是把“一个大的不可控过程”拆成“多个小的可控步骤”。每一步都很简单，简单到不容易出错；就算出错，也能快速定位到具体哪一步，而不是面对着大段的生成文本发呆。

5.3 我的个人体会：别把可控架构做成“死板架构”

最后说一点个人经验。目标驱动的可控架构，很容易在落地中走向矫枉过正。有人为了让模型完全听话，把系统提示写得像法律条文，把每一条路都堵死，结果模型在面对稍微新颖一点的问题时直接傻掉，回什么都是“不在受理范围”。

真正合适的做法是想清楚：哪些环节必须硬约束，哪些环节可以给模型留一些自由。售后问答里，“是否受理”“格式是什么”必须硬；回答措辞怎么组织，可以让模型用自然语言发挥。Agent流程里，“子任务列表”“工具调用”必须硬；生成周报时的语气，可以让模型自己选择。可控不是万能药，把关键的几个点控制住，就已经能解决大部分跑偏问题了。

另外还有一点很实用：目标声明尽量简洁，越短越不容易被上下文长河冲淡。如果业务规则确实复杂，拆成多个独立模块分别约束，而不是全堆在一个超长系统提示里。长提示词看着全面，实际效果往往不如一个简短的核心目标加若干旁路校验。

我在实操中的体会是，给大语言模型做可控架构，花在定义目标和边界上的时间，永远值得超过调参数的时间。定义清楚“这个模块到底管什么、不管什么”，比折腾两天temperature更有效。你先从这个动作开始，搭出来的系统跑偏概率会低很多。