考察点
这道题出自华为 AI Agent 产品经理岗二面,是整套题里风险等级最高的一道。它表面问「工具调用异常怎么办」,实际考三件事:你能不能把「异常」从一句笼统的话拆成可判定的产品规则;你懂不懂金融场景「读」和「写」的容错天差地别;你设计的人工接管是真流程还是一句「转人工」的口号。华为的服务对象里政企和金融机构占比高,面试官对「资金操作绝对安全」这七个字是当真的——你的方案里只要有一个环节让 Agent 在异常状态下自作主张,这道题就挂了。追问通常落在:重试和转人工的边界、误报率太高人工接不过来怎么办、上线前怎么验证这套机制真的管用。
参考答案
先把「结构性异常」定义成可判定的规则
面试官说「结构性异常数据」,我第一步是把它翻译成工程上能判的东西,分四类:一是 schema 层面的,返回报文解析失败、必填字段缺失、类型对不上(金额字段返回了字符串);二是数值层面的,金额、利率超出业务合理区间(比如理财收益率返回 300%),或者为负数这类明显越界;三是语义层面的,字段各自合法但组合起来矛盾——账户状态是「已销户」但余额不为零,交易时间在未来;四是空结果的误用,查询返回空,但空可能是「真的没有」也可能是「接口故障」,这两者绝不能混为一谈。每一类都对应明确的校验规则,由确定性代码在工具返回后、进入 LLM 之前执行——注意这个顺序,校验不能交给模型自己判断,模型看到异常数据很可能「好心」地脑补合理化,那才是最危险的路径。
触发条件:三层闸门,读写有别
触发人工兜底我设计三层闸门。第一层是硬触发,无条件接管:校验规则命中任何一类结构性异常、同一个工具重试两次仍失败、或者 Agent 连续两轮规划不一致。第二层是业务阈值触发,和异常无关但和金额有关:只读查询(查余额、查持仓)容错相对宽,校验通过即可自动返回;但凡涉及写操作——转账、赎回、改密码——一律要人审或用户本人的强确认,金额再分级,比如五万以下用户 App 内二次确认,五万以上必须人工坐席介入。第三层是软触发,针对拿不准的情况:模型输出的置信信号弱、用户两轮内反复纠正 Agent 的理解,这种不直接断,但会把会话标记为「低风险降级模式」,后续的写操作门槛自动抬高一档。核心原则一句话:异常状态下 Agent 的权力只减不增。
接管流程:冻结现场,带着上下文交接
触发之后流程怎么走,才是体现功力的地方。我的设计是四步。第一步冻结:Agent 立即停止一切后续工具调用,当前会话状态快照保存,任何未执行的写操作全部挂起——宁可让用户多等,不能让半个交易流出去。第二步打包:给人工坐席生成一份接管包,包含用户原始诉求、Agent 已执行的步骤和工具返回原文、命中的异常规则、Agent 的初步判断,坐席不需要从头问用户「您要办什么」,这是体验上不翻车的关键。第三步交接话术:Agent 对用户说人话,不暴露技术细节,就说「这笔操作需要专员帮您核实,正在为您转接,已为您保留当前进度」,给出预计等待时长。第四步闭环:坐席处理结果回写会话,Agent 恢复服务;同时这次异常进审计日志和 badcase 库,供后续归因——是接口问题、数据问题还是模型误判,决定下一步是修工具还是调阈值。
上线前怎么证明这套东西管用
金融场景的兜底机制不能靠「设计上应该是对的」上线。我会要求两件事:故障注入测试,在测试环境系统性地喂各种异常报文——缺字段、错类型、矛盾语义、慢响应——验证每一条触发规则都按预期动作,这个用例集至少几百条,覆盖所有工具的所有错误码;红队演练,让安全团队尝试诱导 Agent 在异常状态下完成写操作,比如篡改工具返回后观察 Agent 是否继续执行。两个都过了,再谈灰度。灰度期看两个核心指标:人工接管率(太高说明误报多,压垮坐席;目标一般控制在会话量的 3%-5%)和异常漏检率(事后审计发现「该接管没接管」的比例,这个必须趋近于零,比前者重要一个量级)。
可能的追问
- 为什么不用重试解决大部分异常,非要上人工? 答:重试只治瞬时故障(超时、限流),治不了结构性异常——字段缺失重试十次还是缺失。而且金融场景重试本身有风险,非幂等的写接口重试可能造成重复扣款,所以写操作宁可直接挂起转人工,不自动重试。
- 误报太多,人工坐席接不过来怎么办? 答:两条路。一是给触发规则做分级,硬触发无条件接管,软触发先走「降级确认」——Agent 明确告知用户「当前信息可能不完整,是否继续」,把一部分确认权交还用户;二是每周复盘接管 case 的误报率,误报集中的规则要么修工具要么调阈值,接管率长期高于预期说明系统本身没准备好,该缩功能范围。
- 「资金操作绝对安全」怎么定义成可验收的标准? 答:拆成三条验收线:异常状态下零未授权写操作(故障注入+红队验证);所有写操作 100% 有用户确认或人工审批记录,可审计可回放;资金类接口全部幂等设计,重复调用不产生重复交易。