当前位置：首页 > news >正文

Data Agent 答错了会自己发现吗？衡石自我纠错与反思机制技术解析

news 2026/8/19 11:55:39

引言

在之前的文章中，我们拆解了 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-Reflection）

2.1 什么是反思循环

衡石 Data Agent 在每轮 ReAct 循环（Thought → Action → Observation）之后，增加一个反思步（Reflection）：Agent 基于当前 Observation，重新审视「我刚才这一步做得对不对、离目标近了还是远了」。

反思不是另一次 LLM 调用那么简单，而是一个结构化的自问自答：

这一步的工具选择是否匹配用户意图？
生成的参数是否完整、是否在合理范围？
返回的 Observation 是否真的回答了这一步的子问题？
如果错了，错在哪、怎么改？

2.2 反思的输出

反思步的输出有三种可能：

确认（Confirm）：当前步无误，继续下一轮。
修正（Revise）：当前步有偏差但可挽救，生成修正后的 Action 重跑（例如参数微调）。
回溯（Rollback）：当前步方向性错误，放弃该分支，回到上一个稳定状态重新规划。

这种「边走边看、走错了就回头」的机制，让 Agent 不再是一根筋地往前冲。

2.3 反思与规划的协同

反思不仅作用于单步，还会反馈到顶层规划。如果反思发现「原定计划的第一步假设就不成立」（例如发现用户要的数据源根本没有权限访问），Agent 会触发动态重规划——放弃原计划，基于新的认知重新生成执行路径，而不是硬着头皮执行注定失败的旧计划。

三、第二重：错误检测（Error Detection）

3.1 基于规则的硬性检测

有些错误可以用规则明确判定，衡石在工具执行层部署了硬性检测：

空结果检测：查询返回零行。可能是参数错了（过滤太严），也可能是真没数据。Agent 会区分这两种情况——如果零结果出现在「理应有很多数据」的查询上，标记为可疑，触发参数复查。
量级异常检测：返回的聚合值相比历史基线偏离过大（例如本月销售额是上月的 100 倍），触发告警，要求 Agent 复核口径和时间窗。
Schema 一致性检测：工具返回字段与预期不一致（例如期望数值却返回文本），立即报错并重试。

3.2 基于模型的软性检测

对于规则难以覆盖的语义错误，衡石引入一个独立的校验模型（Critic Model）作为「第二双眼睛」。它不负责执行，只负责审阅：给定用户原始问题、Agent 的中间步骤和当前结果，Critic 模型判断「这个结果是否真正回答了用户问题」。

Critic 模型的价值在于打破「自己审自己」的盲区。让执行 Agent 自我反思，偶尔会陷入「确认偏误」——它倾向于认为自己没错。独立的 Critic 提供了外部视角，显著提升错误检出率。

3.3 与置信度体系的联动

在 ChatBI 文章中我们介绍了置信度评估。Data Agent 同样对每个关键步骤产出置信度。当某步置信度低于阈值，Agent 不会带着疑点继续，而是先解决疑点（追问用户、换工具、或标记不确定）再前进。置信度把「软错误」量化成了可决策的信号。

四、第三重：自动恢复（Auto-Recovery）

4.1 重试策略

检测到错误后，Agent 首先尝试自动恢复。恢复策略按错误类型分层：

参数类错误：最常见。Agent 基于反思，修正参数（如修正日期范围、补全省略的过滤条件）后重跑同一工具。
工具类错误：当前工具不适合，Agent 从工具集中选择替代工具（如排序工具返回格式不对，改用聚合+排序组合）。
数据类错误：所需数据缺失或无权限，Agent 切换数据源或向用户请求授权/澄清。

4.2 重试上限与降级

自动恢复不能无限循环。衡石为每类错误设置重试上限（例如参数修正最多 3 次）。超过上限仍未解决，Agent 进入降级模式：不再执着于完美答案，而是返回「部分结果 + 明确说明未解决的部分 + 建议下一步」，把控制权交还用户，而不是卡死或编造。

这种「优雅降级」设计，保证了 Agent 在任何情况下都有可交付的输出，不会出现「转圈半小时最后报错」的糟糕体验。

4.3 恢复的可追溯

每一次错误检测和自动恢复，都会记录在 Trace 中（与可观测性体系打通）。管理员能清楚看到「这一步错了、怎么错的、怎么恢复的」。这不仅用于审计，更是模型迭代的养料——高频错误模式会被提炼成新的规则，让 Agent 越用越聪明。

五、第四重：验证闭环（Verification Loop）

5.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