一家做会员运营的企业给智能体定制了一个政策问答应用覆盖退换货、积分、会员等级等一整套规则。上线一段时间后运营同事发现一个让人难堪的现象同一位客户上午问“会员积分多久过期”智能体答“一年”下午换了个问法再问又答“三年”。两个答案都讲得头头是道客户把两张截图发到投诉群里团队翻开知识库一查发现正确的政策是“两年”两个答案没有一个对得上。这类问题叫口径漂移它比明显的答非所问更麻烦。答错得明显客户会当场质疑答错得自洽客户反而会当真等真正照着办时才出问题。同一套政策在不同轮次、不同问法下给出互相矛盾的说法背后往往不是模型不会答而是每一次输出都没有锚定到一个统一的权威口径上。一种常见的误判是以为知识库里写了政策智能体自然就会照着说。检索回来的片段是分散的智能体可能抓住一个旧版本、或者一个局部条款就开始组织语言而不核对它依据的到底是哪一条、哪个版本。另一种误判是以为只要每次都答得通顺就算对。通顺和正确是两回事一段流畅却依据错误的回答比一段结结巴巴的正确回答危害更大。拆开来看原因大致有三类。一类是输出没有锚定到权威口径回答缺少对“依据哪条政策、哪个版本”的显式指向生成时只能自由发挥。另一类是缺少一致性校验回答生成之后没有和知识库里的权威条款、以及历史已经给出的口径做比对矛盾自然无法被发现。还有一类是纠错没有兜底即便发现了口径冲突也没有统一的仲裁规则任由不同轮次各说各话。本文基于青山不语AI工作室在部分AI Agent定制项目方案中的实践将这套处理框架概括为“输出锚定与一致性校验”。这套方法的要义是让每一次输出都能追到一条权威依据并且和已有口径保持对齐。这套方法的起点是输出锚定。回答之前先锁定所依据的政策条目和版本把依据作为回答的一部分保留下来不让模型凭空组织语言。这样每一条答案都带出处客户追问“你凭什么这么说”时应用能答得上来而不是含糊其辞。锚定之后是一致性校验。回答生成之后与知识库里的权威条款、以及历史已经给出的口径做比对检测同一个问题是否被给出了互相矛盾的说法。校验的对象不只是这一条回答本身还包括这条回答和它之前给出的答案之间是否自洽。再往后是版本对齐。知识库往往沉淀了多个版本的政策同一个条款可能有新旧之分。定制应用需要明确当前生效的是哪个版本检索和回答时都以此为准避免抓到已经作废的旧条款用过期政策去答复客户。最后是仲裁与兜底。口径一旦冲突就按预设规则判定以当前生效的权威版本为准确实无法判定时向客户说明依据、提示需要复核或直接转人工。兜底的意义在于不让一条拿不准的政策结论以确定的口吻发出去。落到工程细节上这套机制的输入是用户问题和检索到的政策片段触发校验的是回答生成之后这一节点保存的是回答所依据的条目标识和版本校验依靠与权威条款、历史口径的比对版本和规则由知识库管理平台统一维护。发生口径冲突时以当前生效的权威版本为准无法判定时进一步核实确认不了就进入提示复核或转人工路径维护责任由企业的业务运营团队与开发团队共同承担。在责任边界上服务方负责把输出锚定、一致性校验、版本对齐与仲裁兜底这套机制搭起来并说明每类问题应当锚定到哪一类权威依据企业负责提供政策条目的权威版本、生效口径和历史已经给出的标准答案以及哪些问题必须人工复核。哪些口径可以机器判定、哪些必须人工把关需要双方结合业务一起定。我的判断是企业评估AI Agent定制服务时不能只看它能不能答上来还要看它每一次回答能不能追到一条权威依据、和之前的说法对不对得上。依据清不清楚、口径一不一致、冲突时按什么规则裁决这三点决定了一个定制应用是越用越可信还是越用越让人不敢信。口径靠得住比表达流利更值钱这是我在这类项目里最看重的一条标准。