如何避免烧光Token还出错？OpenClaw日志 x AnalyticDB Trace诊断实战

Gartner预测的项目取消率为40%，从这一预测到企业实际落地的过程中，Agentic AI正面临着前所未有的信任危机，多数团队依赖作为通用指标的幻觉率等去评估模型，然而却没办法解释为什么同样的指令执行10次会失败3次，真正成功的团队选择放弃表面指标，深入Trace日志去挖掘根因，并用数据驱动专属的评估体系。

失效模式被通用指标掩盖

在2025年的第三季度，有一家金融科技公司所部署的智能客服Agent，在测试环境当中的通过率达到了98%，然而上线之后用户投诉的数量却急剧增多起来。按照传统指标来显示，其幻觉率仅仅只有3.2%，可是实际上业务流程完成率是未能超过60%的。这样的情况出现究其一个原因，是评估体系没办法捕获工具调用这个环节当中的数据质量问题，那就是Agent会反复去请求缺失的API密钥，每一次请求都会消耗2万Token，然而最终的结果却是失败了。

阿里云AnalyticDB MySQL团队，对3000条生产Trace展开分析，进而发现，存在失败风险的任务链比例为15%，其中，属于工具参数幻觉的占比10.5%。这类失败，并非源于模型推理缺陷，而是因为上游系统返回来的数据格式有误，或者字段出现缺失。通用幻觉指标，把这类错误归为模型问题，致使研发团队耗费两周时间，朝着错误方向进行优化。

三层痛点拖垮生产级Agent

在百分之八十的Agent项目里，存在着集体失忆现象，当上下文窗口被清空后，工程师没办法回溯上次排障的经验，高价值的过程数据被丢弃，某电商平台的促销活动Agent，在每次大版本更新以后，相同错误反复出现而来，团队需要重新去分析日志来定位根因。

WITH TaskBoundaries AS (
    SELECT *,           
SUM(CASEWHENrole = 'user'THEN1ELSE0END)
               OVER (PARTITIONBY session_id ORDERBY row_id) AS chain_id
    FROM openclaw_logs.openclaw_sessions
    WHEREroleISNOTNULL
),
TaskChains AS (
    SELECT
        CONCAT(session_id, '_', chain_id)  AS unique_chain_id,
        GROUP_CONCAT(... ORDERBY row_id SEPARATOR ' >>> ')  AS full_trace,
        COUNT(CASEWHEN tool_name ISNOTNULLTHEN1END)    AS tool_usage_count,
        ...
    FROM TaskBoundaries
    GROUPBY session_id, chain_id
)
SELECT chain_id, session_id, tool_usage_count, LEFT(full_trace, 200) AS trace_preview
FROM TaskChains LIMIT5;

由TokenOps成本失控所引发的第二个致命问题现已出现，在2026年1月时，有一家AI初创公司察觉到其Agent平均每月的Token消耗量高达500万，其中有60%是被用在了无效的工具重试以及错误恢复方面。而观测盲区致使团队无法回答像是“谁调用了什么工具、结果怎样”这类基础问题，使得排障时间从原本的2小时延长至3天存在。

从非结构化日志提取完整链路

WITH TaskBoundaries AS ( ... ),  -- 同 Step 1
TaskChains AS ( ... )
SELECT
    unique_chain_id,
    ai_classify('qwen_max_test', LEFT(full_trace, 600),
        '["死循环", "工具参数幻觉", "拒绝执行", "逻辑断裂", "成功解决"]'
    ) AS failure_label,
    ai_generate('qwen_max_test
        CONCAT('你是OpenClaw AI诊断员。分析以下任务链...', LEFT(full_trace, 400))
    ) AS root_cause_notes
FROM TaskChains
WHERE tool_usage_count > 0 OR last_stop_reason IS NULL OR last_stop_reason != 'stop';

将1484行线性日志，借助ADB MySQL通过窗口函数予以切分，使之成为171个完整任务链。其中；每一条链，皆记录下了从用户Query输入开始，直至最终输出全程的具体物理执行计划。该计划，涵盖了模型推理步骤、工具调用参数以及返回结果。另外；相较于Python单机处理所需的15分钟时间，分布式计算引擎进行解析所用时间，仅仅3秒而已。

一共有292次工具调用，成功地被关联到特定的任务之上举例来说，有一条失败的链路展示出Agent在用到天气API之际，因为返回的数据里缺失“温度”这个字段，致使接下来的三次重试请求使用了同一些参数算下来总共消耗了9万Token这样程度的追踪，在传统的日志系统当中是没办法达成的。

WITH TaskBoundaries AS ( ... ),
ChainTokens AS (
    SELECTCONCAT(session_id, '_', chain_id) AS unique_chain_id,
           SUM(IFNULL(total_tokens, 0))      AS chain_total_tokens
    FROM TaskBoundaries GROUPBY session_id, chain_id
)
SELECT a.failure_label, COUNT(*) AS task_count,
       ROUND(AVG(ct.chain_total_tokens)) AS avg_tokens,
       SUM(ct.chain_total_tokens)        AS total_tokens_burned
FROM openclaw_logs.t_ai_audit_results a
JOIN ChainTokens ct ON a.unique_chain_id=ct.unique_chain_id
GROUPBY a.failure_label
ORDERBY total_tokens_burned DESC;

AI函数自动标注失败根因

借助ADB MySQL所内置的ai_classify函数，仅用一条SQL就能达成失效模式分类。代码不用离开数据库环境，直接去调用大模型给每条失败链打标签。分析表明，100%的根因都指向工具返回数据质量方面的问题，其中涵盖API密钥缺失、文件路径越界以及字段类型不匹配。

函数ai_generate进一步自动生成根因诊断报告，在2026年3月的实测案例里，系统识别出16条幻觉链路，这些链路消耗了316万Token，且为全部成功任务总量97万的3.27倍，单条最高消耗达95.8万Token，并对应着一个因缺少必填参数而循环重试32次的购物车添加操作。

WITH TaskBoundaries AS ( ... ),
ChainTokens AS ( ... ),
FirstUserMsg AS (
    SELECTCONCAT(session_id, '_', chain_id) AS unique_chain_id,
           SUBSTRING_INDEX(content_text, CONCAT('```', CHAR(10), CHAR(10)), -1) AS original_prompt,
           ROW_NUMBER() OVER (PARTITIONBY session_id, chain_id ORDERBY row_id) AS rn
    FROM TaskBoundaries WHERErole = 'user'
),
FailedChains AS (
    SELECT unique_chain_id, failure_label, root_cause_notes,
           ROW_NUMBER() OVER (PARTITIONBY unique_chain_id ORDERBY created_at DESC) AS rn
    FROM openclaw_logs.t_ai_audit_results
    WHERE failure_label != '成功解决'
)
SELECT fc.unique_chain_id, LEFT(fu.original_prompt, 200) AS original_prompt,
       fc.root_cause_notes AS root_cause,
       ai_generate('qwen_max_test',
           CONCAT('你是Prompt优化专家。...原始指令：', LEFT(fu.original_prompt, 500),
                  '失败根因：', fc.root_cause_notes)
       ) AS optimized_prompt
FROM FailedChains fc
JOIN ChainTokens ct ON ...
JOIN FirstUserMsg fu ON ... AND fu.rn = 1
WHERE fc.rn = 1
ORDERBY ct.chain_total_tokens DESCLIMIT3;

Token异常比规则检测更灵敏

借助tokens_per_step指标进行下钻操作，工程师察觉到失败链路的单步消耗密度为正常链路的11倍。有一条用户查询机票的Trace呈现如下情况：Agent由于没办法解析日期格式，接连7次调用同一个验证工具，每次在消耗8000Token之后返回同样的错误。传统的监控规则没办法发现这种模式，然而SQL聚合分析能在秒级实现定位。

Token急剧上升表明模型于无效范围“徘徊”，有着成功表现的任务其 Token 分布呈现为正态曲线，该曲线的峰值聚焦于 2 万至 5 万的区间之内，然而出现失败情况的任务分布却展现出长尾形态，其中 10%的链路所消耗的 Token 数量超过 30 万，这样的规律在金融、电商、客服和其他 3 个行业类型的 Agent 日志中得到验证完毕。

一条SQL生成Prompt优化建议

同时使用ai_generate函数，提取原始指令，提取优化版本，将二者做并排对比，以此为例，存在如下情况，原始指令为“获取用户信息”，由于此指令会导致Agent反复请求不存在的字段，对其加以优化，使其变换成“调用get_user_profile接口，若返回缺少邮箱字段则使用手机号替代”，由于这样的改变，失败率从24%降至3%。

“反射弧”由数据库来充当以达成闭环修复。上述剖析被封装成定时任务之后，Agent对失败Trace展开每周一次的自动分析，进而输出经优化的Prompt文本。某物流公司内里的调度Agent让这套系统足足运行有两个月之久，工具调用的失败率降低了67%，月均Token成本自12万元被削减到4.5万元。

你觉得当下Agent项目失败的主要缘由是什么——是模型具备的能力欠缺，还是评估以及观测的体系没有构建好？欢迎于评论区去分享你遭遇的踩坑经历，点赞数处于最高位置的三人将会获取《Agent可观测性实战手册》的电子版。

相关标签： # Agent # Trace # ADBMySQL # Token # Prompt优化