问题

智能体一旦能调工具，排错就变成噩梦。它内部可能连着调三四个工具：查天气→搜航班→算价格→下单。中间哪一步出岔子，用户只看到最后一句"抱歉没能帮你订上"，你也只看到一句。到底哪步挂的、传了什么参数、工具回了什么，全是黑盒。

我之前定位一个"订单总下不成功"的问题，靠加print、复现、再加print，来回两个多小时。后来把调用链结构化存下来之后，同类问题十分钟定位。

我存了哪些字段

核心思路就一句：把每一次工具调用，当成一条独立的结构化记录落下来。我设计的表大概长这样：

关键是trace_id要贯穿全程，这样一捞就是完整一条链，从用户提问到最终回复，每一跳都在。

落库的两个细节

input和output存原文，别加工。 我一开始想着省空间，把工具返回截断了存，结果真出问题的时候，恰恰是被我截掉的那段里有报错信息。后来改成全量JSON存，磁盘是小事，排错信息完整才是命。

error要把异常栈也带上。 status是error的，单独再存一个error_detail，把工具抛的异常或HTTP错误码原样塞进去。我现在排错第一步就是WHERE status='error' ORDER BY ts DESC，一目了然。

SELECT step, tool_name, status, latency_ms, error_detail
FROM agent_trace
WHERE trace_id = 'xxx'
ORDER BY step;

跑出来就是一条干净的时间线，哪步慢、哪步报错、传了啥，全在眼前。

顺手发现的副产品

存了latency之后，我顺手做了个统计，发现有个"查物流"的工具平均要1.8秒，是整条链最慢的一环——它是个老接口，没加缓存。这本来不在排错范围内，纯属看数据看出来的，加了层缓存之后整体响应快了不少。算意外收获。

工程上我没自己搭这套埋点。我用的那种拖一拖就能配智能体的工具，本身每个工具节点的出入参就是可以结构化导出的，我做的主要是把它接到我自己的存储里、按trace_id组织起来。省了从零写trace框架的活。

一个小遗憾：我的latency统计目前只算单工具耗时，模型推理那部分的耗时没拆进来，所以"整轮慢"的时候还得另外查。下一步想补上。

模型这层补一句：智能体每步决策都得问大模型，模型API我直接用了讯飞的MaaS（现成大模型服务，不用自己养算力），接进来就能用。

—

你们做Agent可观测都上什么？有没有直接接OpenTelemetry那套的？我这个手搓的表能用，但总觉得不够正规，想听听标准做法。