据 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 链路——谁调用了什么工具、结果如何。

2ADB 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
(
CASE
WHEN
role
 = 
'user'
THEN
1
ELSE
0
END
)



               
OVER
 (
PARTITION
BY
 session_id 
ORDER
BY
 row_id) 
AS
 chain_id



    
FROM
 openclaw_logs.openclaw_sessions



    
WHERE
role
IS
NOT
NULL



),



TaskChains 
AS
 (



    
SELECT



        
CONCAT
(session_id, 
'_'
, chain_id)  
AS
 unique_chain_id,



        
GROUP_CONCAT
(... 
ORDER
BY
 row_id SEPARATOR 
' >>> '
)  
AS
 full_trace,



        
COUNT
(
CASE
WHEN
 tool_name 
IS
NOT
NULL
THEN
1
END
)    
AS
 tool_usage_count,



        ...



    
FROM
 TaskBoundaries



    
GROUP
BY
 session_id, chain_id



)



SELECT
 chain_id, session_id, tool_usage_count, 
LEFT
(full_trace, 
200
) 
AS
 trace_preview



FROM
 TaskChains 
LIMIT
5
;

执行结果： 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
 (



    
SELECT
CONCAT
(session_id, 
'_'
, chain_id) 
AS
 unique_chain_id,



           
SUM
(
IFNULL
(total_tokens, 
0
))      
AS
 chain_total_tokens



    
FROM
 TaskBoundaries 
GROUP
BY
 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



GROUP
BY
 a.failure_label



ORDER
BY
 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
 (



    
SELECT
CONCAT
(session_id, 
'_'
, chain_id) 
AS
 unique_chain_id,



           SUBSTRING_INDEX(content_text, 
CONCAT
(
'```'
, 
CHAR
(
10
), 
CHAR
(
10
)), 
-1
) 
AS
 original_prompt,



           ROW_NUMBER() 
OVER
 (
PARTITION
BY
 session_id, chain_id 
ORDER
BY
 row_id) 
AS
 rn



    
FROM
 TaskBoundaries 
WHERE
role
 = 
'user'



),



FailedChains 
AS
 (



    
SELECT
 unique_chain_id, failure_label, root_cause_notes,



           ROW_NUMBER() 
OVER
 (
PARTITION
BY
 unique_chain_id 
ORDER
BY
 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



ORDER
BY
 ct.chain_total_tokens 
DESC
LIMIT
3
;

3、结语

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

3 个 insight：

Agent 的失败是概率性的。同一条指令 10 次执行可能成功 7 次，每次失败路径不同。传统测试无效，你需要基于统计分布的失效模式分析——SQL 引擎天然擅长。
Token 异常是最好的异常检测器。 16 条幻觉链路消耗 310 万 Token，是成功任务总和的 3.27 倍。Token 飙升意味着模型在“打转”，远比规则检测灵敏。
AI 可观测性的终局是“闭环”。数据库充当“反射弧”——失败 Trace 进去，优化 Prompt 出来。封装为定时任务，Agent 就获得了持续运转的免疫系统。

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

ITPub博客

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

最新文章