Agent 答错了最让人抓狂的不是错是你不知道它哪一步错了。一次回答背后可能调了三四个工具、查了知识库、又问了一遍模型黑箱一团。我后来给每个 Agent 都加了链路追踪把这次回答走了哪几步全记下来排错效率直接翻倍。这篇讲我怎么追的。为什么必须追链路举个把我坑惨的例子。用户问我上个月话费多少Agent 回了个明显错的数。我盯着最终输出看半天看不出毛病。加了链路追踪后一看记录才发现它该调查账单工具的结果调成了查套餐参数还传错了月份。问题压根不在模型生成那步在工具选择那步。没有链路我能瞎猜一整天。一条链路该记哪些字段我每一步都落这几样缺一不可步骤序号 类型模型推理 / 工具调用 / 知识检索输入这步拿到了什么输出这步吐出了什么耗时这步花了多久谁触发了下一步模型决定调哪个工具、为什么最后那条最值钱。Agent 的核心决策就是下一步调谁把模型的这个选择理由记下来错在哪一眼就看出来。一条真实链路长这样[1] 模型推理 输入:上月话费多少 决策:调用 query_bill 工具 [2] 工具调用 query_bill(month2026-05) 耗时 420ms 输出:{amount:89} [3] 模型推理 输入:账单结果 输出:您上月话费89元一目了然。要是第 2 步调成了 query_package立刻就暴露了。追踪要注意的坑坑一别把敏感信息明文记进链路。我一开始把用户手机号、账单明细原样落日志事后想想后怕。后来对敏感字段做了脱敏手机号中间打码链路照样能看隐私不外泄。坑二长输入要截断。知识检索那步召回的内容动辄几千字全记下来日志爆炸还难看。我对每个字段设了长度上限超了就截断加省略号留个钩子能溯源就够。坑三耗时一定要记。有次用户反馈答得慢我靠每步耗时一眼定位到是某个外部工具调用卡了 3 秒模型本身很快。没有分步耗时你只知道总共慢不知道慢在哪。一个小取舍全量记录链路是有成本的存储和性能都吃一点。我没给所有请求都开只对出错的和随机抽样 5%的请求记完整链路正常请求只记关键节点。全量留痕虽好但没必要为了万分之一的排错需求拖慢所有人。怎么实现的我用的是一个拖拖拽拽就能配工作流、还自带测评的智能体平台每个节点的输入输出和耗时它本身就有记录我顺着扒出来拼成链路视图就行没自己埋点。中间各步调的模型 API 走讯飞星辰 MaaS现成接口省了自建。调试 Agent 的第一原则先让它可观测再谈优化。