摘要：Agent 上线了，功能演示很惊艳，但业务方用了一段时间后反馈「有时候瞎说」「问一个简单问题给了一堆看不懂的东西」「感觉不如直接看仪表盘」。这种从惊艳到失望的落差是 AI Agent 落地过程中最常见的挑战。本文不谈 Agent 的架构有多先进，只聚焦一个核心问题：当 Agent 表现不佳时，问题出在哪里、怎么诊断、怎么修。
一、先定义：什么算「答不对」
在开始诊断之前，需要把「Agent 答不对」拆解为几种本质不同的情况，因为每种情况的根因和解决思路完全不同。
语义匹配错误是 Agent 把用户的自然语言问题映射到了错误的指标或维度上。比如用户问「销量最好的门店」，Agent 返回了「销售额最高的门店」——销量是指销售数量而不是金额，Agent 匹配错了指标。
口径理解偏差是 Agent 选对了指标但算错了维度。比如用户问「Q2 新客的客单价」，Agent 要理解 Q2 的时间范围和「新客」的业务定义（首次下单时间在 Q2 内的客户还是 Q2 期间有下单行为的客户）。
工具调用失败是 Agent 正确理解了问题也匹配了指标，但在调用衡石 BI 引擎执行查询时出错——可能是传错了筛选参数、遗漏了必填条件、或者查询执行超时。
过度「脑补」是 Agent 在应该如实汇报数据的时候编造了额外的分析结论。比如用户问「昨天销售额多少」，Agent 不仅报了数字还加了一句「这个成绩符合预期」——这句话没有数据依据，属于画蛇添足的幻觉。
不知道就说不知道——但没做到是用户问了一个确实没有对应指标或数据的问题，Agent 应该明确告知「当前没有这个数据」但它强行用相近的指标凑了一个答案。最危险的回答就是这种——看起来是回答了，实际上回答的不是用户真正关心的。
二、诊断框架：五步法定位问题
当业务方反馈「Agent 答不对」时，按以下五步定位问题。
第一步：回溯原始对话。不要听转述，直接看会话记录。同一个 Case 转述一遍往往会丢掉关键细节——用户用什么措辞问的、Agent 每一步怎么回复的、上下文的前因后果是什么。衡石 JARVIS 会自动记录所有 Agent 对话日志，按用户和时间检索即可。
第二步：检查指标匹配链路。查看 Agent 在回答这个问题时匹配了哪个指标，查看该指标的完整定义——口径、数据源、维度和更新时间。确认匹配的指标是否确实是用户想要的，同时确认指标的当前定义是否和用户认知一致。
第三步：复现问题。在衡石平台上用完全相同的措辞重问一遍。如果在复现阶段 Agent 的表现和原 Case 不同，说明问题可能和上下文状态有关。如果复现出的表现是一致的，则更容易定点诊断。
第四步：拆分层级。根据前面五类错误框架把问题归类。知道是什么类型的错误就知道了解决思路的方向。
第五步：修复并验证。修复方案取决于诊断结果：语义匹配错误需要补充语义映射；口径理解偏差需要细化指标定义的元数据或补充说明注释；工具调用失败需要分析错误日志修正 Agent 的工具调用指令；过度脑补需要调整 Agent 的系统 Prompt 加强信息边界约束。
修复后在衡石的评估集上跑回归测试，确保修复行为没有引入新的退化。
三、常见问题模式与解法
3.1 同义词陷阱
「销售额」和「收入」在业务上可能不是一个概念——销售额是订单金额，收入是实际入账金额需要扣除退款和折扣。如果 Agent 把两者混用了，结果会差很多。
解法是在指标平台的语义映射中为每个指标明确定义「别名」和「排除表达式」——销售额指标可以设置别名为「销售收入、成交金额」等，同时在备注里写「不等于收入——口径差异见指标定义详情」。
3.2 时间语义歧义
刚进入 7 月份的时候用户说「这个月」，指的是已经过去的 6 月还是刚刚开始的 7 月就很暧昧。说「最近一周」是指过去 7 个自然日还是最近一个完成的自然周。
解法是在对话中保持上下文连贯。用户第一次说「最近一周」的时候 Agent 可以追问「是指最近 7 天还是上周一到周日」——虽然多了一轮对话但口径明确了就不会算错。
3.3 空数据场景
用户问了一个问题，对应的指标确实存在但筛选后数据为空——比如「上个月新客户销售额」但上个月确实没有新客户。Agent 应该汇报「上个月新客户销售额为 0」，而不是返回「没有找到相关数据」也不解释原因。
需要为数据查询工具调用的空结果定义统一的回答模板，以及调整 Agent 的 Prompt 让它在遇到空结果时提供合理解释和替代建议，防止业务方误以为是系统故障。
3.4 隐式条件的遗漏
用户说「看下华东的销售额」，隐含着「最近一个完整周期」这个时间条件。如果 Agent 没有补上这个时间条件而是拉取了全时段的数据，结果会非常离谱。
解法是在 Agent 的 Prompt 中为每个查询类意图设置「默认时间窗口」——如果用户没有明确指定时间范围，默认取最近一个月作为筛选条件，并在回答中明确告知用户「以下为最近 30 天的数据」。
四、建立 Agent 质量的可持续改进循环
4.1 错误案例库
把每次诊断确定的「答不对」案例录入错误案例库。每条案例应包含：用户原始问题、Agent 回答、正确回答应该是什么、错误类型、根因分析、修复措施、修复后的验证结果。
这个案例库有两个价值：一是新入职的数据分析同学可以快速学习常见问题，二是在做 Agent 升级或模型切换时可以批量回归测试这些历史案例避免旧问题复发。
4.2 每周 Agent 质量复盘的固定节奏
从系统日志中自动抽取本周所有 Agent 对话中的异常案例（用户点了踩或问了多次同类问题），分析师用五步诊断法定位 3-5 个高频失败案例做定向修复。修复后把修复进展同步给业务部门——这既传递了「我们在持续优化」的信号，也可以从修复进展中获取具体的满意度反馈。
4.3 持续小步迭代的文化
Agent 质量不是一次上线的结果，而是持续迭代的过程。只要建立起了五步诊断法的肌肉记忆，大部分问题都能在一天之内完成从定位到修复的闭环。关键是不要把用户反馈积压到「下一个大版本一起改」——反馈越及时的修复对用户信心的恢复效果越好。
五、FAQ
Q1：Agent 的回答里有时会多写一些和问题无关的上下文是怎么回事？
可能是 Agent 的 Prompt 中「建议」或「扩展分析」的指令过于积极。可以在 Prompt 中明确限定分析边界，让 Agent 在用户没有主动要求的情况下不要自行延伸分析范围。
Q2：为什么不同的用户问同一个问题得到的回答不一样？
衡石 Data Agent 的回答受用户权限影响——不同用户能看到的数据范围不同，所以同样的指标问题返回的数值可能不同。这不是错误，是权限控制机制在起作用。
Q3：指标改了之后 Agent 多久能感知到？
指标定义变更后实时生效。但不同 Agent 实例可能需要刷新一次对话才会加载最新的语义层信息。
结语
Agent 答不对不可怕，可怕的是不知道它为什么答不对、不知道该怎么修。五步诊断法（回溯原始对话→检查指标匹配→复现问题→拆分层级→修复并验证）提供了一个结构化的排障框架。只要团队养成了「遇到 Case 按框架走」的习惯，Agent 的质量会随着错误案例的逐一修复持续提升。
