梁练伟拆解 Agent 工作流故障排查结构与日志链路
我是梁练伟，最近把一个常用的 Agent 工作流从“出错后人工翻日志”，改成了“自动定位、自动复盘、自动给下一步建议”。这篇不是趋势评论，而是我实际搭建后的拆解：适合已经在用 n8n、Dify、Make、Zapier、LangGraph 或自研脚本的人收藏。
为什么我先做故障排查，而不是继续加功能
很多人搭 Agent 工作流，第一反应是增加工具、接更多 API、让模型做更多决策。我踩过的坑是：功能越多，失败点越分散。一个自动化流程可能卡在触发器、权限、字段映射、模型幻觉、超时、重试、第三方接口限流，最后看起来像“AI 不稳定”，其实是排查链路不完整。
我现在的原则是：每新增一个 Agent 能力，必须同时新增一段可观测能力。否则这个工作流不是资产，而是一个黑盒风险。
梁练伟的三层排查结构
我把故障排查系统拆成三层：事件层、诊断层、复盘层。
第一层是事件层，只负责记录事实。包括任务 ID、触发时间、输入来源、调用工具、模型名称、token 消耗、状态码、重试次数、最终输出。这里不要让大模型总结，因为原始事实要保持干净。
第二层是诊断层，让模型根据结构化日志判断问题类别。我常用的分类是：输入缺失、格式错误、权限失败、接口超时、模型误判、工具返回异常、业务规则冲突。分类不要太多，太多会导致后续统计失真。
第三层是复盘层，把同类错误聚合起来，生成“可执行的修复建议”。注意，我不会让它直接改生产流程，而是输出变更建议、影响范围、验证步骤和回滚方案。
我的实际工作流步骤
步骤一：给每次运行加 run_id。没有 run_id，后面所有排查都会变成猜谜。我会让触发器生成唯一编号，并贯穿每个节点。
步骤二：统一日志字段。至少包含 input_snapshot、tool_name、tool_result、model_output、error_message、latency_ms、retry_count。字段名稳定，比字段多更重要。
梁练伟分析自动化故障日志与 Agent 诊断流程
步骤三：把失败节点单独送进诊断 Agent。这个 Agent 不参与主流程决策，只做一件事：判断失败类型，并给出证据。我的 Prompt 会要求它引用日志字段，而不是凭感觉解释。
步骤四：设置严重级别。比如 P0 是影响收入或客户交付，P1 是流程中断但可人工补救，P2 是输出质量下降，P3 是可观察但暂不影响结果。这样我每天看面板时，不会被一堆小错误淹没。
步骤五：加入自动化复盘。每天固定时间汇总过去 24 小时失败记录，生成一份简报：高频错误、首次出现错误、平均修复时间、建议优先级。我会把这份简报推到 Notion 或飞书文档，方便第二天直接处理。
模型分工：不要让一个模型包办一切
在这个系统里，我一般不会用同一个模型处理全部任务。便宜快速的模型负责分类和摘要，推理能力更强的模型负责复杂根因分析，规则引擎负责硬性判断。
例如接口返回 401，不需要大模型推理，规则直接判定为权限问题。模型真正有价值的地方，是判断“为什么某类输入总是导致工具调用失败”，以及“修复字段映射会不会影响其他节点”。这就是我理解的模型协作：把确定性问题交给规则，把模糊问题交给模型，把最终变更交给人确认。
我踩过的三个坑
第一个坑是日志太详细，却没有统一结构。结果每个节点都记录一堆内容，但无法统计。后来我宁愿少记，也要字段一致。
第二个坑是让诊断 Agent 直接给结论，不要求证据。这样很容易出现“看似专业、实际胡猜”的报告。现在我要求每条结论必须绑定日志字段。
第三个坑是自动修复太激进。早期我尝试让系统自动改 Prompt、自动切换模型，结果引入了新问题。现在我的做法是：低风险动作自动执行，高风险动作只生成建议。
效率收益怎么衡量
我不会只看“省了多少时间”，而是看四个指标：平均定位时间、重复错误比例、人工介入次数、失败后恢复时间。一个月后，如果重复错误没有下降，说明复盘没有进入改进闭环；如果定位时间下降但恢复时间不变，说明建议还不够可执行。
对我来说，Agent 工作流的成熟度，不是它能不能跑通一次，而是它失败时能不能被快速理解、快速验证、快速恢复。梁练伟做自动化的核心经验就是：先让系统会暴露问题，再让系统变聪明。把故障排查系统搭好，后面加工具、加模型、加 Agent，才不会越做越乱。
梁练伟进行自动化复盘并规划 Agent 工作流优化步骤
