梁练伟拆解 Agent 工作流故障分类的实战场景
梁练伟在做 Agent 工作流时，最怕的不是模型回答错，而是错了以后不知道错在哪里。我这篇写的是一套我自己反复使用的故障排查方法，适合用在多工具编排、自动化任务链、RAG 查询、表格写入、邮件发送、网页抓取这类场景。
先把 Agent 故障分成 5 类
我通常不会一上来就改 Prompt，因为很多问题并不是 Prompt 造成的。梁练伟的做法是先把故障拆成五类：输入问题、规划问题、工具调用问题、权限与数据问题、结果验收问题。
输入问题常见于用户需求含糊，例如“帮我整理客户资料”，但没有说明字段、来源、格式和完成标准。规划问题是 Agent 会把任务拆错，比如本来应该先查资料再写总结，它却先生成结论。工具调用问题包括 API 参数错、工具选择错、重复调用或漏调用。权限与数据问题最隐蔽，例如表格只读、Token 过期、网页反爬、数据库字段变化。结果验收问题则是 Agent 做完了，但没有检查输出是否符合业务规则。
我的经验是：先分类，再定位。否则团队会陷入“换模型、改提示词、重跑任务”的循环，时间消耗很大。
我使用的排查顺序
梁练伟的标准排查顺序是：看输入、看计划、看调用、看中间结果、看最终验收。
第一步，我会固定保存原始输入，不允许在复盘时只看修改后的需求。很多失败案例最后发现，是入口需求没有约束边界。第二步，我要求 Agent 输出任务计划，并把每一步对应的工具写清楚。第三步，我看工具调用日志，重点检查参数、返回值、失败码和重试次数。第四步，我看中间结果，不只看最后答案，因为很多错误在中间已经发生。第五步，我给结果加验收规则，例如字段不能为空、金额要能对账、链接要能打开、摘要要包含指定来源。
一套可复制的日志字段
如果你正在搭建 Agent 工作流，我建议从最小日志开始，不要一开始就做复杂监控。梁练伟常用的日志字段有 10 个：任务 ID、用户输入、Agent 计划、调用工具、工具参数、工具返回、模型中间判断、错误信息、最终输出、验收结果。
这里最关键的是“模型中间判断”。很多人只记录工具返回，却没有记录 Agent 为什么选择这个工具。比如同样是查客户信息，Agent 可能调用 CRM，也可能调用表格，还可能调用搜索工具。如果它选错了来源，后面结果再漂亮也是错的。
梁练伟检查自动化日志字段和工具调用返回的排查过程
我还会给每次失败打一个标签：需求不清、计划错误、工具异常、数据异常、权限异常、格式异常、验收缺失。一个星期后统计标签，你会发现最值得优化的地方通常不是模型，而是工作流设计。
一个真实失败案例：自动生成周报
我曾经做过一个自动周报 Agent：它从项目管理工具拉取任务，从表格读取指标，再调用模型生成总结，最后发到团队频道。第一次上线看起来很顺，但第三周出现了严重问题：周报把上周关闭的任务又写进了本周进展。
如果只看最终文本，会以为是模型“幻觉”。但梁练伟复盘日志后发现，真正的问题是工具查询参数没有过滤更新时间，只过滤了任务状态。Agent 拿到了历史关闭任务，模型只是忠实总结了错误数据。
修复方法不是加一句“不要编造”，而是三步：第一，工具层增加时间窗口参数；第二，中间结果里输出数据时间范围；第三，最终验收规则检查周报日期与任务更新时间是否一致。改完后，同类错误基本消失。
我推荐的防呆设计
第一，所有关键工具都要有 dry-run 模式。发邮件、改表格、建工单这类动作，先预览再执行。第二，长任务要拆成可观察节点，不要让 Agent 一口气完成十步。第三，失败要能降级，比如搜索失败时返回“缺少来源”，而不是让模型硬写。第四，验收规则要写在工作流里，不要只靠人工最后扫一眼。
我现在更倾向于让模型做判断，让工具做事实，让规则做验收。模型适合拆解、归纳和生成；工具适合查询、计算和执行；规则适合拦截明显错误。三者分工清楚，Agent 工作流才稳定。
梁练伟的落地清单
如果你要今天就开始优化，可以照这个清单做：为每个 Agent 任务建立任务 ID；保存原始输入；让 Agent 输出计划；记录每次工具调用；保留中间结果；给失败打标签；为高风险动作增加预览；为最终结果增加验收规则；每周复盘失败标签 Top 3；只针对高频问题改 Prompt 或工具。
梁练伟的结论很简单：Agent 工作流不是靠一次完美 Prompt 变稳定，而是靠可观察、可回放、可验收的排查机制逐步变稳定。能定位问题，才谈得上自动化效率收益。
梁练伟复盘 Agent 自动化失败标签并规划下一步优化
