企业把 AI Agent 接到真实业务场景后的头一两周,常常会出现一类尴尬现象:模型本身没坏、流程也没断,但它开始给出一些不在预期内的回答——把内部代号说成产品功能、把尚未上线的功能描述成已经能用、把客户填错的数据解释成行业惯例。这类问题比直接报错更难处理,因为它会一句一句流到客户那边,等运营人员发现时往往已经发出去几十条。
运营侧最容易踩的坑,是用一个万能兜底把所有问题都堵回去。真实场景里的预期外回答至少可以拆成三类,各自对应的拦截位置完全不同,放在同一层做兜底只能解决其中一种。第一类是越权回答,模型说出了它本来不应该知道的字段、价格或者客户分级;第二类是推测内部参数,模型在没有数据的情况下替客户推断一个看起来合理的数字;第三类是上下文漂移,长对话里模型把前面的口径和后面的口径混着用,客户拿到一份自相矛盾的回复。三类问题最好分别划在调用前、调用中和调用后三层做拦截,而不是全部丢给事后人工。
调用前这一层,核心是把模型能拿到的工具、数据和角色先收成一个白名单。具体做法是给每类场景写一份允许工具列表,比如面向 C 端用户的客服只能查订单状态、物流时效和退换货规则,不能查内部工号、不能调价格修改接口。模型在准备调用工具之前,先过一次前置校验,不在白名单的请求直接拒绝并返回一段中性提示,而不是让模型自己判断要不要执行。这一层解决的是越权回答,它的特点是预防成本最低、漏判后影响最大,所以优先级最高。
调用中这一层,重点是给模型能写的文字加一份模板校验。常见做法是给每类问题预设回答骨架,例如退换货类必须包含订单号、时间窗和下一步动作三段,不允许出现具体金额承诺,也不允许出现还未生效的政策描述。回答生成后用一个轻量的规则检查器扫一遍,命中违规则直接用模板替换成中性回复,没命中再交给用户。这一层解决的是推测内部参数,它的特点是漏判后只能靠事后纠正,所以模板要尽量短、尽量可解释,不要为了美观堆一长串条件。
调用后这一层,才轮到兜底话术和人工接管。这一层的关键是给每条外发回答打一个置信度标签:高置信直接发,中置信附带一句提示词让客户复核关键数字,低置信自动转人工排队,而不是让客户自己去判断一条回复靠不靠谱。兜底话术本身也要分类,例如面向 C 端的兜底和面向员工的兜底要分开写,前者强调我帮你转人工,后者强调这份内容还需要审核,语气和承诺口径完全不同。
按这三层布好之后,真正的收益来自两个细节。一是上线初期每天都要复盘一次预期外回答样本,把新出现的越权表述和推测口径补进调用前白名单和调用中模板,而不是写一份通用规则就丢给一线客服。二是兜底话术不要承诺模型本身做不到的事,例如不要写我 100% 保证答复准确,一旦被客户截图就会变成公关问题。
回到 ClawMercs 这类面向企业的智能体中心,上线初期最容易出问题的环节往往是调用前白名单和调用中模板没跟上产品迭代。当产品功能一周一更,Agent 的工具列表还停留在上线当天的版本,模型就会按训练语感去推断它见过的相似接口,推断出来的就是预期外回答。把工具列表和数据访问规则跟产品版本管理绑在一起,每次发版同步更新白名单,比任何事后兜底都更稳。