据 Gartner 预测，未来几年将有超过 40% 的 Agentic AI 项目因无法达成商业目标而被取消。核心原因之一：团队构建了错位的评估体系——过度依赖“幻觉率”等通用指标，无法捕获真正导致 Agent 表现失控的根因。而成功交付生产级 Agent 的研发团队做法恰恰相反：大家选择深入剖析底层 Traces，从真实数据中推演出专属评估指标。 

在 OpenClaw 时代，Agent Trace 日志记录了用户 Query、模型推理、工具调用及最终输出的完整的物理执行计划。本文借助阿里云瑶池旗下的云原生数据仓库 AnalyticDB MySQL 版（以下简称为ADB MySQL）完整的 Agent 日志可观测能力，在 SQL 引擎里闭环的跑通这套高 ROI 的 Agent 数据工程实践。同时，相比于 Python 代码的单机处理，ADB MySQL 强大的分布式计算和向量化执行引擎能够在秒级完成大规模 Agent 日志 Trace 的复杂解析任务。

1、AnalyticDB MySQL提供的Agent日志可观测能力

在深度拥抱 Agent 的企业里，我们反复看到三层痛点：

• 集体失忆：上下文窗口一清空，排障经验就蒸发，高价值过程无人整理。

• TokenOps 成本失控：50 万 Token 消耗里，多少是推理，多少在和错误 API 死磕？

• 观测盲区：Agent 时代真正有价值的是 Trace 链路——谁调用了什么工具、结果如何。

ADB MySQL 面向基于 OpenClaw 等 Agent 生态构建了统一的日志分析基础设施，一站式建立从日志采集和语义提取的完整解决方案。

日志采集层，可使用我们提供的OpenClaw for ADB MySQL日志采集上报工具，详见链接：https://click.aliyun.com/m/1000411480/，以下是基于产研团队内部 OpenClaw 日常类似的真实日志数据，来进行实操复现。

2、实战：从原始日志到 Token 归因与 Prompt 优化

Step 1：从非结构化日志提取完整执行链路

Agent 日志是高度非结构化的，首先要将线性日志切分为有业务意义的“任务链”。在 ADB MySQL 中，一个窗口函数即可完成：

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;

执行结果：1484 行日志 → 171 个完整任务链，292 次工具调用。

Step 2：用 AI 函数自动标注失败模式

ADB MySQL 的ai_classify在 SQL 中直接调大模型完成失效分类，ai_generate自动生成根因诊断——零 Python 代码：

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';

分析结果：15% 的任务链存在失败风险，其中 10.5% 陷入"工具参数幻觉"。100% 的根因指向工具返回数据质量问题（API 密钥缺失、路径越界等），而非模型推理缺陷。

Step 3：量化各失效模式的 Token 消耗

失效模式定义后，下一步量化它——幻觉让我损失了多少 Token，修哪个 Prompt 收益最大？

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;

结论令人震惊：工具参数幻觉仅占 15% 的任务量，却烧掉了 3,161,237 Token——是全部成功任务总量的 3.27 倍！ 单条最高消耗达 958,743 Token。

进一步通过 tokens_per_step 下钻，可精准定位每条失败链路的单步消耗密度：

Step 4：基于根因生成Prompt优化建议

Agent 失败分两种：规范失败（指令不清晰）和泛化失败（模型无法应用指令）。最优先动作：先修 Prompt，别急着建评估器。利用ai_generate，一条 SQL 同时提取原始指令和优化 Prompt 做并排对比：

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;

3、结语

我们用 4 条 SQL 走完了从原始日志到闭环修复的全链路。

3 个 insight：

1. Agent 的失败是概率性的。 同一条指令 10 次执行可能成功 7 次，每次失败路径不同。传统测试无效，你需要基于统计分布的失效模式分析——SQL 引擎天然擅长。

2. Token 异常是最好的异常检测器。 16 条幻觉链路消耗 310 万 Token，是成功任务总和的 3.27 倍。Token 飙升意味着模型在“打转”，远比规则检测灵敏。

3. AI 可观测性的终局是“闭环”。 数据库充当“反射弧”——失败 Trace 进去，优化 Prompt 出来。封装为定时任务，Agent 就获得了持续运转的免疫系统。

不要把 AI 的命脉交给通用外部指标。 死磕 Trace，围绕真实问题构建专属评估体系——ADB MySQL 把这套工程压缩成了几行 SQL，轻松的嵌入到企业日常的 workflow 里。这为企业提供了一个绝佳的“经验回放缓冲区”，让高价值的 SOP 在 Agent 进行 Bootstrapping 的过程里得以沉淀。欢迎钉钉搜索“173295003853”加入钉群交流。