用 SQL 直接分析 Agent Trace，定位失效模式、归因 Token 成本，并生成 Prompt 优化建议。
原文标题：如何避免??烧光Token还出错？OpenClaw日志 x AnalyticDB Trace诊断实战
原文作者：阿里云开发者
冷月清谈：
核心痛点主要有三类：一是日志链路不可见，Agent 执行常包含多次推理、工具调用和重试，普通日志难以还原完整过程；二是 Token 成本难归因，只能看到总消耗，难以判断浪费发生在哪类失效上；三是失败经验难沉淀，排障常依赖人工猜测。
对应的实践分为四步：先用窗口函数把线性日志重建为任务链；再借助 ai_classify 和 ai_generate 在 SQL 中自动完成失败分类与根因分析；随后按任务链统计 Token 消耗，量化不同失效模式带来的成本；最后结合失败根因自动生成 Prompt 优化建议，形成从发现问题到修复的闭环。
实操结果显示，工具参数幻觉虽然只占部分任务量，却消耗了远超成功任务的 Token，说明 Token 异常可作为高灵敏度的异常信号。文章强调，Agent 失败往往具有概率性，适合用统计分布和 Trace 分析来定位问题，而数据库可以承担这一套可观测与修复闭环的核心角色。
怜星夜思：
2、问题2：文章里提到 Token 异常是很好的异常检测器，你认同吗？如果只盯 Token，会不会也有误判？
3、问题3：文里很多动作都放进 SQL 做了。你觉得把 AI 可观测性尽量收敛到数据库层，是好事还是会带来新的问题？
4、问题4：文章的案例里，根因最后更多指向工具返回数据质量，而不是模型本身。你觉得这对很多做 Agent 的团队有什么提醒？
原文内容
据 Gartner 预测，未来几年将有超过 40% 的 Agentic AI 项目因无法达成商业目标而被取消。核心原因之一：团队构建了错位的评估体系——过度依赖"幻觉率"等通用指标，无法捕获真正导致 Agent 表现失控的根因。而成功交付生产级 Agent 的研发团队做法恰恰相反：大家选择深入剖析底层 Traces，从真实数据中推演出专属评估指标。
在 Openclaw 时代，Agent Trace 日志记录了用户 Query、模型推理、工具调用及最终输出的完整执行计划。本文借助 ADB MySQL 的 Agent 日志可观测能力，在 SQL 引擎里闭环跑通这套最高 ROI 的 Agent 数据工程实践。
Agent 可观测性的三层困境，与 ADB MySQL 的解法
在深度拥抱 Agent 的企业里，我们反复看到三层痛点：
困境一：观测盲区——Trace 链路不可见
Agent 执行过程是非线性的：一次用户 Query 背后，可能触发 5 次工具调用、3 次模型推理、N 次重试。原始日志是扁平的行记录，没有任何工具能告诉你"这次任务到底发生了什么"。
→ ADB MySQL 的解法：窗口函数一行代码将线性日志重建为完整任务链（Step 1），让每条 Trace 的执行路径从黑盒变透明。
困境二：TokenOps 成本失控——烧了多少钱，不知道烧在哪
50 万 Token 消耗里，多少是正常推理，多少在和错误 API 反复死磕？传统监控只能看总量，无法归因到具体失效类型。
→ ADB MySQL 的解法：直接在 SQL 中聚合各失效模式的 Token 消耗（Step 3），精确回答"幻觉让我损失了多少钱、修哪个 Prompt 收益最大"。
困境三：失效无法定位——排障靠猜，经验无法沉淀
上下文窗口一清空，排障经验就蒸发。团队凭直觉猜测失败原因，同样的问题反复踩坑，高价值过程无人整理。
→ ADB MySQL 的解法：内置 ai_classify 和 ai_generate 函数，在 SQL 中直接调大模型完成失效分类与根因诊断（Step 2），并自动生成 Prompt 优化建议（Step 4）——零 Python 代码，失效经验自动入库沉淀。
相比于 Python 代码的单机处理，ADB MySQL 强大的分布式计算和向量化执行引擎能够在秒级完成大规模 Agent 日志 Trace 的复杂解析任务，一站式建立从日志采集到语义提取的完整解决方案。
以下是基于产研团队内部 Openclaw 日常类似的真实日志数据，来进行实操复现。
实战：从原始日志到 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;
结语
我们用 4 条 SQL 走完了从原始日志到闭环修复的全链路。三个 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 的过程里得以沉淀。
欢迎点击阅读原文了解 OpenClaw for ADB MySQL日志采集上报工具。钉钉搜索“173295003853”加入钉群交流。