引言在之前的文章中我们拆解了 Data Agent 的四层架构、多智能体协作和工具调用机制。但有一个问题始终悬在从业者心头Agent 自主跑了好几步万一其中一步错了它会自己发现并纠正吗还是一路错到底最后给你一个看起来合理、实则错误的结论这是 Agentic BI 区别于传统「写死脚本」的根本挑战。传统程序错了会报错、会中断Agent 基于大模型的推理是概率性的错误往往是「软错误」——没有异常、没有崩溃只是方向偏了。如果 Agent 没有自我纠错能力这种软错误会比程序崩溃更危险。衡石 Data Agent 在 ReAct 推理框架之上叠加了自我反思Self-Reflection、错误检测、自动恢复和验证闭环四重机制让 Agent 具备「发现错、纠正错、不再错」的能力。本文将深入这套机制。一、Agent 的「软错误」有哪些1.1 三类典型错误工具选择错误用户要的是「按销售额排序」Agent 却调用了「按销量排序」的工具。查询能执行、能返回数据但答非所问。参数生成错误日期范围算错把「上季度」算成「本季度」、维度成员选错把「华东」当成「华中」、过滤条件遗漏。这类错误最隐蔽因为单看参数是合法的只有对照意图才发现不对。解读错误工具返回了正确的数据但 Agent 对数据的解读错了——把环比下降解读成上升或者忽略了数据中的异常值直接下结论。1.2 为什么传统的 try-catch 救不了传统程序的错误处理是「异常驱动」出错抛异常、捕获、处理。但 Agent 的软错误不产生异常——SQL 合法、查询成功、返回了真实数据。try-catch 对此完全失效。Agent 需要的是语义层面的自我审视而非语法层面的异常捕获。二、第一重自我反思Self-Reflection2.1 什么是反思循环衡石 Data Agent 在每轮 ReAct 循环Thought → Action → Observation之后增加一个反思步ReflectionAgent 基于当前 Observation重新审视「我刚才这一步做得对不对、离目标近了还是远了」。反思不是另一次 LLM 调用那么简单而是一个结构化的自问自答这一步的工具选择是否匹配用户意图生成的参数是否完整、是否在合理范围返回的 Observation 是否真的回答了这一步的子问题如果错了错在哪、怎么改2.2 反思的输出反思步的输出有三种可能确认Confirm当前步无误继续下一轮。修正Revise当前步有偏差但可挽救生成修正后的 Action 重跑例如参数微调。回溯Rollback当前步方向性错误放弃该分支回到上一个稳定状态重新规划。这种「边走边看、走错了就回头」的机制让 Agent 不再是一根筋地往前冲。2.3 反思与规划的协同反思不仅作用于单步还会反馈到顶层规划。如果反思发现「原定计划的第一步假设就不成立」例如发现用户要的数据源根本没有权限访问Agent 会触发动态重规划——放弃原计划基于新的认知重新生成执行路径而不是硬着头皮执行注定失败的旧计划。三、第二重错误检测Error Detection3.1 基于规则的硬性检测有些错误可以用规则明确判定衡石在工具执行层部署了硬性检测空结果检测查询返回零行。可能是参数错了过滤太严也可能是真没数据。Agent 会区分这两种情况——如果零结果出现在「理应有很多数据」的查询上标记为可疑触发参数复查。量级异常检测返回的聚合值相比历史基线偏离过大例如本月销售额是上月的 100 倍触发告警要求 Agent 复核口径和时间窗。Schema 一致性检测工具返回字段与预期不一致例如期望数值却返回文本立即报错并重试。3.2 基于模型的软性检测对于规则难以覆盖的语义错误衡石引入一个独立的校验模型Critic Model作为「第二双眼睛」。它不负责执行只负责审阅给定用户原始问题、Agent 的中间步骤和当前结果Critic 模型判断「这个结果是否真正回答了用户问题」。Critic 模型的价值在于打破「自己审自己」的盲区。让执行 Agent 自我反思偶尔会陷入「确认偏误」——它倾向于认为自己没错。独立的 Critic 提供了外部视角显著提升错误检出率。3.3 与置信度体系的联动在 ChatBI 文章中我们介绍了置信度评估。Data Agent 同样对每个关键步骤产出置信度。当某步置信度低于阈值Agent 不会带着疑点继续而是先解决疑点追问用户、换工具、或标记不确定再前进。置信度把「软错误」量化成了可决策的信号。四、第三重自动恢复Auto-Recovery4.1 重试策略检测到错误后Agent 首先尝试自动恢复。恢复策略按错误类型分层参数类错误最常见。Agent 基于反思修正参数如修正日期范围、补全省略的过滤条件后重跑同一工具。工具类错误当前工具不适合Agent 从工具集中选择替代工具如排序工具返回格式不对改用聚合排序组合。数据类错误所需数据缺失或无权限Agent 切换数据源或向用户请求授权/澄清。4.2 重试上限与降级自动恢复不能无限循环。衡石为每类错误设置重试上限例如参数修正最多 3 次。超过上限仍未解决Agent 进入降级模式不再执着于完美答案而是返回「部分结果 明确说明未解决的部分 建议下一步」把控制权交还用户而不是卡死或编造。这种「优雅降级」设计保证了 Agent 在任何情况下都有可交付的输出不会出现「转圈半小时最后报错」的糟糕体验。4.3 恢复的可追溯每一次错误检测和自动恢复都会记录在 Trace 中与可观测性体系打通。管理员能清楚看到「这一步错了、怎么错的、怎么恢复的」。这不仅用于审计更是模型迭代的养料——高频错误模式会被提炼成新的规则让 Agent 越用越聪明。五、第四重验证闭环Verification Loop5.1 终态验证在所有步骤执行完毕、Agent 准备给出最终答案前还有一个终态验证环节把最终答案对照用户原始问题做最后一次完整性检查。三个必检项意图覆盖用户问的所有子问题都回答了吗例如用户问「华东和华北对比」最终答案是否两个地区都有数据一致最终结论引用的数字能否从工具返回的数据中推导出来防止 Agent 脑补数字口径自洽使用的指标口径、时间窗是否与用户确认的一致任何一项不通过Agent 回到对应步骤补全或修正而非带着缺陷交付。5.2 交叉验证对于关键结论Agent 会做交叉验证用不同工具或不同路径得到同一结果相互印证。例如「华东销量 top 1 是产品 A」这个结论Agent 既用排序工具得出又用聚合过滤工具独立验证一次。两个路径一致置信度大幅提升不一致则触发深入排查。5.3 与人工确认的衔接当终态验证仍存疑例如涉及重大业务决策、或数据极度稀疏Agent 不会强行给确定结论而是把验证过程中发现的疑点汇总请求人工确认。这种「机器能定的自己定定不了的主动问」的分级策略是 Agent 落地的务实之道。六、四重机制如何协同四重机制不是孤立的而是嵌在 Agent 的执行生命周期里规划阶段动态重规划能力反思的延伸确保计划基于正确假设。执行阶段每步反思 硬性/软性错误检测实时发现偏差。恢复阶段自动重试 优雅降级把错误转化为可交付结果。交付阶段终态验证 交叉验证给答案做最后一道安检。它们共同构成一个「预防—发现—纠正—验证」的闭环让 Data Agent 的错误率从「靠运气」变成「靠机制」。七、效果与权衡7.1 加了反思会不会变慢、变贵会。每轮反思是额外的 LLM 调用Critic 模型也是额外开销客观上增加了延迟和 token 成本。衡石的应对策略是分级启用简单任务单步查询走轻量路径少反思、快返回。复杂任务多步分析、涉及决策走完整反思Critic 路径宁可慢一点也要准。 这种「按任务难度分配算力」的思路在成本和质量间取得平衡。7.2 实测收益在衡石内部压测中引入四重纠错机制后复杂多步任务的「最终答案错误率」从约 18% 下降到 5% 以内而平均延迟仅增加 20%-30%复杂任务本就耗时这个比例可接受。对于严肃分析场景这个交换比非常划算。八、技术对比能力无纠错 Agent仅重试 Agent四重纠错 Agent衡石软错误发现几乎无弱靠异常强反思Critic自动恢复无有限分层重试降级终态验证无无意图/数据/口径三检错误可追溯无弱全链路 Trace九、FAQQ1反思机制会不会让 Agent「想太多」陷入死循环不会。反思有次数和深度限制且每次反思都产出明确的 Confirm/Revise/Rollback 决策推动状态前进而非原地打转。配合重试上限和降级循环问题被严格约束。Q2Critic 模型会不会误判把对的说成错的有可能但 Critic 的输出是「建议」而非「否决」。它被设计为偏向保守宁可多查一遍最终决策仍由执行 Agent 综合判断。双模型的设计目标是提升召回少漏错而非追求零误报。Q3自我纠错能完全替代人工审核吗不能也不应该。纠错机制把错误率降到很低但严肃决策场景仍建议人工确认关键结论。Agent 的定位是「把人从重复核查中解放出来」而非「替代人的最终判断」。十、总结Data Agent 的可信度不取决于它「一次就做对」的概率而取决于它「做错了能不能自己发现并纠正」的能力。衡石 Data Agent 通过自我反思、错误检测、自动恢复、验证闭环四重机制把概率性的大模型推理约束成了一个有自愈能力的工程系统。核心认知是Agent 不怕犯错怕的是错了还不知道。当 Agent 能自己发现偏差、自己修正路径、自己验证结论它才真正配得上「智能体」三个字——不是因为它永远对而是因为它会成长。下一篇我们离开「机制」看「落地」Data Agent 在金融、零售、制造的具体业务里到底怎么帮企业干活。