摘要：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 的质量会随着错误案例的逐一修复持续提升。

---