这两天公开信号里CSDN 上涨得最明显的一类内容不是抽象的 Agent 愿景而是可观测性、监控和故障排查。这其实很符合真实项目节奏。团队把 Agent 接进工单、订单、设备、审批或内部运维流程以后第一批真正让人头疼的问题通常不是“模型是不是还不够聪明”而是为什么同一类任务有时几秒有时几十秒为什么成本突然飙高但追不到是哪一步多跑了两轮为什么用户说结果错了团队却只能看到最终回复为什么工具明明返回了partial下游还是把结果当成“完整成功”继续写了状态为什么事故复盘时没人能回答到底是模型判断错了、工具契约不清还是重试策略把故障放大了。这类问题如果还在靠继续改 prompt 处理排障成本会非常高。生产环境更有效的做法是先把一条最小可追溯证据链补齐再讨论模型优化。先给一个判断标准如果一个 Agent 已经满足下面三个条件里的任意两个就不该再只看最终回复日志会调用两个以上外部工具会写真实业务状态会在失败时自动重试、降级或切人工。一旦进入这个阶段问题不再只是“答得对不对”而是“整条运行链到底发生了什么”。minimum_agent_trace:run:run_id:requiredtask_type:requiredtenant_or_env:requiredfinal_status:requiredtotal_latency_ms:requiredmodel_span:provider_model_version:requiredinput_output_tokens:requiredduration_ms:requiredpurpose:requiredtool_span:tool_name:requiredinput_summary:requiredoutput_summary:requirederror_code:requiredretry_count:requiredresult_state:requiredsafety:write_gate_hit:requiredhuman_handoff:requiredrollback_or_block_reason:optional这套字段不花哨但足够把很多“玄学问题”变成工程问题。一条最小诊断链路可以先长这样否是Agent run 开始记录 run_id / task_type / envModel span: 模型版本 / token / latency / 调用目的Tool span: 工具名 / 入参摘要 / 出参摘要 / result_state是否 partial / blocked / failed记录 final_status 并进入普通复盘触发 write gate / human handoff / rollback signal事故复盘: 定位模型、工具、数据边界或重试策略反写阈值、工具契约、评测样本和 runbook1. run 级记录先把事故装进同一个盒子里很多团队的问题不是没有日志而是日志太散。模型日志一份、工具日志一份、业务系统审计一份最后没人能把它们拼成一次完整运行。所以第一层一定是 run 级上下文至少包含run_idtask_typesession_id或业务单号tenant / env / actorstarted_at / finished_atfinal_statustotal_latency_msestimated_cost如果这层没有打平后面就很难判断一次事故到底影响了哪个任务、哪个租户、哪个业务动作。2. model span 解决“慢”和“贵”到底出在哪很多团队看到成本上升先怀疑模型太贵看到延迟升高先怀疑 provider 波动。但真实项目里经常是下面几种情况更常见工具返回太碎导致模型多做两轮规划输出 schema 校验失败补了一次修复调用同一个高复杂任务走了不该走的大模型某个降级分支没有命中结果多花了一次总结步骤。所以每次模型调用都建议至少记录provider / model / versioninput tokens / output tokensduration调用目的规划、抽取、总结、回复schema 是否失败fallback 是否触发只要这些字段存在很多“模型不稳定”的判断都会被快速纠正。3. tool span 才是生产 Agent 最容易漏、也最值钱的一层公开信号里这轮最值得参考的一点是 CSDN 热门内容明显在向工程落地和排障闭环靠拢。对 Agent 来说真正能撑住排障的不是一句“工具调用失败”而是这次失败具体失败在哪一层。每次工具调用至少建议落这几类字段tool_nameinput_summaryoutput_summarystatus_code / error_codeattemptretry_countduration_msresult_state:success/partial/blocked/failedpolicy_gate_hit尤其是partial和blocked不能和普通成功混在一起。很多事故并不是“调用失败”而是工具只回了部分字段权限校验挡住了写操作下游 200 了但业务语义其实没完成重试成功了但用户看到的是重复写入的副作用。这些都需要结构化记录不能只留一句文本。4. 先抓 6 类证据字段足够覆盖第一轮排障如果团队现在还没有完整 tracing 基础设施我建议先补这 6 类证据字段run_id task_typeprovider_model_version token latencytool_name input_summary output_summaryerror_code retry_countresult_state success/partial/blocked/failedhuman_handoff / write_gate / rollback_signal一旦这 6 类字段有了很多模糊争论会立刻变得清楚是模型判断错还是工具返回不完整是工具超时还是重试策略把问题放大是写操作该拦没拦住还是本来就不该放行是单次故障还是某类任务系统性不稳。5. 一个够用的结构示例下面这类结构已经足够支持第一轮排障和复盘{runId:run_20260628_101502,taskType:refund_triage,finalStatus:blocked,latencyMs:18440,estimatedCostUsd:0.27,modelSpans:[{name:plan-next-step,provider:openai,model:gpt-5.1-mini,durationMs:1520,inputTokens:4210,outputTokens:381}],toolSpans:[{toolName:fetch_order_context,resultState:partial,durationMs:480,missingFields:[latest_payment_status]},{toolName:issue_refund,resultState:blocked,errorCode:HUMAN_APPROVAL_REQUIRED,retryCount:0,policyGateHit:refund_write_requires_approval}],handoff:{triggered:true,reason:high_risk_write_blocked}}关键不在字段名而在你能不能稳定回答哪一步先变慢哪一步开始不可信哪一步触发了风险闸门这次运行到底该不该继续自动执行。6. 先排障再把数据反写回控制面trace 和 span 的价值不只是“出了事故能回看”。一旦证据字段稳定下来后面还能直接推动三类生产改进哪些任务应该切到更便宜的模型哪些工具要增加幂等和参数契约哪些高风险写操作必须前置人工确认。这也是为什么我通常把 trace、tool-calling、审计、模型路由、权限边界放在同一套控制面里看。它们不是独立优化项而是一组生产能力。结尾判断如果一个 Agent 已经接进真实工单、订单、设备或资金流却还回答不了“这次到底用了哪个模型、调了哪个工具、为什么被拦、为什么重试、哪一步开始失真”那它离真正可运营还差一层很关键的证据基础。如果最近在准备 AI Agent Production-Readiness Review这类项通常也会优先检查trace 是否覆盖关键任务、tool span 是否能支撑复盘、写操作是否有拦截证据、人工接管和回滚信号是否能被稳定记录。重点不是把 Agent 讲得更聪明而是确认它出了问题以后能查得清、停得住、改得动。