梁练伟梳理 Agent 工作流输入规划工具输出四类故障
我是梁练伟，这篇想把我最近反复使用的一套 Agent 工作流故障排查方法整理出来。很多人搭智能体时，前两天觉得很顺，第三天就开始遇到幻觉、工具调用失败、结果不稳定、自动化链路断点等问题。我的经验是：不要先急着换模型，先把排查顺序固定下来。
一、先把 Agent 故障分成四类
我在做工作流自动化时，会先把问题归类，而不是直接修改 Prompt。梁练伟常用的分类是四种：输入问题、规划问题、工具问题、输出问题。
输入问题指的是资料不完整、字段不统一、上下文太长或变量为空。规划问题通常发生在 Agent 自主拆任务时，例如它跳过检查步骤，或者把搜索、计算、写作的顺序排错。工具问题包括 API 超时、权限不足、返回格式变化、网页结构更新。输出问题则是最终答案看似完整，但格式不符合后续节点要求。
这个分类的好处是，排查不会变成“感觉哪里都可能错”。我会先问：这次失败是 Agent 没读懂、没规划好、没调用成功，还是没按格式交付？只要能回答这个问题，修复成本会下降一半。
二、我的最小日志模板
梁练伟建议任何 Agent 工作流上线前，都先加一层最小日志。不是复杂监控，而是记录五个字段：任务 ID、输入摘要、Agent 计划、工具返回、最终输出。
任务 ID 用来追踪同一次运行；输入摘要用来确认变量是否为空；Agent 计划用来判断它有没有走错路线；工具返回用来排查接口和网页抓取问题；最终输出用来检查格式、事实和可执行性。
我一般不会一开始就记录全部上下文，因为日志太长会让复盘变慢。我的做法是先记录摘要，失败时再保存完整上下文。这样既能节省成本，也方便搜索历史案例。
三、排查顺序：不要从 Prompt 开始
很多人的第一反应是改 Prompt，但我不建议这样做。我的顺序是：先查输入，再查工具，再查模型规划，最后才改 Prompt。
第一步，检查输入字段。比如自动生成周报失败，我先看日期、项目名、任务列表、负责人是否都传进来了。很多所谓“模型不稳定”，其实是字段为空。
第二步，检查工具返回。搜索工具有没有拿到结果？表格节点有没有返回正确列名？自动化平台有没有报权限错误？如果工具返回本身就是错的，模型再强也只能包装错误。
第三步，检查 Agent 计划。它是否先检索再总结？是否在没有证据时直接下结论？是否把写作任务和数据清洗任务混在一起？这一步决定是否要拆成多个 Agent。
第四步，才是 Prompt 修正。我会把修正写得很具体，例如“当工具返回为空时，不要生成结论，而是输出 NEED_RETRY 并说明缺失字段”。这比加一句“请更准确”有效得多。
四、一个失败案例：自动化复盘报告跑偏
我之前做过一个自动化复盘流程：输入项目日志，Agent 自动提取问题、归因、改进动作。第一次测试看起来不错，但连续跑十次后，我发现它经常把“现象”写成“原因”。例如“需求变更频繁”被它直接写成根因，但实际根因可能是验收标准没有冻结。
梁练伟查看 Agent 编排日志进行自动化故障排查
我没有马上换模型，而是拆日志后发现，Agent 的计划里少了“证据归因”这一步。于是我把流程改成三个节点：先提取事实，再列出可能原因，最后根据证据强度排序。改完之后，报告质量明显稳定。
这里的关键不是模型能力，而是工作流结构。梁练伟一直强调，Agent 不是一个万能写手，而是一个需要被设计执行路径的协作者。
五、可直接复用的故障排查清单
如果你正在搭 Agent 工作流，可以直接用下面这份清单：
- 输入变量是否完整，有没有空字段或错字段？
- 上下文是否过长，关键信息是否被淹没？
- 工具是否成功调用，返回格式是否变化？
- Agent 是否生成了可解释的执行计划？
- 是否存在一步完成过多任务的问题？
- 输出格式是否能被下游节点读取？
- 失败时是否有重试、降级或人工确认机制？
- 日志是否能定位到具体失败节点？
- 修复后是否用同一批样本回归测试？
我建议每次只改一个变量。比如今天只改 Prompt，明天只换模型，后天只调整工具参数。否则你会不知道到底是哪一步带来了改善。
六、我的结论
梁练伟做 Agent 工作流的原则很简单：先让系统可观察，再让系统可修复，最后才追求更智能。没有日志的自动化只是碰运气，没有排查顺序的优化只是反复试错。
如果你想把 Agent 用在真实业务里，最重要的不是堆更多工具，而是建立一套稳定的故障排查机制。它能让你在模型变化、接口变化、任务变化时，依然知道问题从哪里来、该往哪里改。
梁练伟用复盘看板总结 Agent 工作流修复结果与下一步计划
