为什么中间的 LLM 输出 preview 是空的？ReActAgent的工作方式：每次决定调用工具时LLM输出的是 tool_calls JSON，而不是文字。这个JSON会被LangGraph框架消费，不出现在content文本字段里。其实，只有最终一次 LLM 调用才会产生文字content。这正是 Trace 的价值：不用Trace 你看不到这 次 LLM 调用，你只知道"等了 秒"。有了 Trace 你知道： 次 LLM + 次工具，其中哪次思考最慢。Demo ：延迟时间线 老板问为什么响应慢，你只能说“模型比较忙”。没有数据支撑，每次调整都在碰运气。再看查询，"TellmeWonderBotPropriceandcalculate *forannualcost." 静默运行后分析 tracer.steps 生成 ASCII 时间线： total_ms=sum bar_scale=/total_ms for i,st epenumerate bar ="█"*max,) label ="LLM reasoning"ifstep.step_type=="llm" else f"tool:{step.name}" print

至于真实输出。 Step-by-step breakdown:Step LLM reasoning ██████████████Step tool:get_product_info █ Step LLM reasoning ███████████ Step tool:calculator █ Step LLM reasoning ███████████ ────────────────────────────────────────────────────────────Total :6457ms LL M :6455ms Tools : ̶%ofwalltime)

LLMOccupy%，tools占%。这是Agent性能调整最关键的一条 工具调用几乎是免费的。 所有延迟来自LLMOptimization方向应为减少推理次数而不是调整网络请求，避免盲目扩容浪费成本。Demo ：结构化审计日志 客户投诉答案错误，没有证据链无法定位责任；监管要求可追溯，却只有结果存档。一次入参错误可能导致财务损失，却找不到根因。查询这方面，"What'swearinShenzhenandhowmuchdoesWonderBotBasiccost?" 运行结束后把 tracer.steps序列化为JSON： def build_audit_log->dict : steps_log= fors ins.tracer.steps : entry={"type":s.step_type。"duration_ms":round} if s.step_type==" tool": entry=s.nameentry=s.input_previewentry=s.output_previewelse : entry=s.output_previewsteps_log.append...

真实输出的观点是，json{ "trac e_id ":"6c8e4b64","query ":"What'swearinShenzhenandhowmuchdoesWonderBotBasiccost?","answer ":"ThewearinShenzhenisrainywithatemperatureof degreesCelsius.Thecosto f WonderBotBasicisnotavailable.","steps":,"summ ary":{ " ste p_count ":,"too l_call_count ":,"total _ ms ":。" ll m_ ms ":," too l_ ms "} }

注意 getproductinfo 的 input 是 {'product_name': 'Basic'} —— LL M传入的是 Basic，没有带 wonderbot 前缀，导致查找失败。审计日志记录了工具的原始入参，这在排查 为什么 A gent 回答错 了 时极为关键。如果没有这条记录，你只会看到最终答案里有一句 not available。不知道是哪里出了问题，避免反复扯皮与客诉升级。

三种模式对比

模式适用场景是否影响性能输出──────────────────────────────────────────────────────────────────实时 Trace 开发调试 有 控制台事件流延迟时间线性能分析 无 ASCII 图表审计日志生产环境、合规审计 无 JSON 文件 / 数据库

三种模式共用同一个 Ag entTrac er。通过 verbose=True/False 控制实时打印，后处理分析不依赖打印行为，避免生产环境打日志拖慢响应。

设计 Checklist

Tracer 实现

Chat模型用 onchatmodelstart，不是 onllmstart ontoolstart 里记录工具名和输入。在 ontoolend 里用同一个实例变量配对 用 starttime / end_time 而不是在 end 里算 delta StepRecord 做成 dataclass，方便后续序列化和分析

审计日志

每次请求生成唯一 traceid，便于跨程序关联追踪，减少排查成本。记录工具的原始入参，不只是工具名 —— 入参是排查问题的关键。避免责任推诿到下游服务，对 LL M 中间步骤的 outputpreview 为空要有预期 ：工具体调用轮次 c ontent 为空是正常行为，不要误判为异常。生产环境把 audit log 写到数据库或日志程序。不要只打印到 stdout，否则丢失且不可检索。其实，

性能分析

区分 ll mm s 和 toolm s。前者通常占 %+ 调整方向 ：减少 L LM 调用次数 & g t;调整工具体执行速度，避免无效投入。建立 p50/p95 延迟基线，用于检测退化，及时预警服务质量下滑。

五个主要结论。让你的 A gent 从黑箱走向透明运营 :

LangChain Callback 是可观测性的基础 ：BaseCallbackHandler 的四个方法覆盖 L LM 和工具体的完整生命周期，实现全链路追踪。Chat 模型用 onchatmodelstar t ：这是容易踩的坑。onlll msta rt 对 ChatOpenAI 不触发，导致一半步骤丢失。L LM 调用轮次的 c ontent 可以为空 ：工具体调用轮的 L LM 输出是 too lcalls JSO N。不是文字，需正确解析避免误报。L LM占 ~%-%延迟 ：工具体调用在毫秒级。调整延迟应减少 L LM 调用次数，体验更好并减少成本。审计日志的价值在工具体入参 ：只记录最终答案不够。工具体接收到的原始参数才是排查问题的关键，降低客诉与合规风险。