devgo.cn如果你把同一个大模型 Agent 从 staging 环境搬到生产环境，发现它输出变短、工具调用变少、还经常给出自信但错误的答案，你的第一反应多半是“模型是不是退化了？”我们当时也这么想，最后查下来，模型没变，是工作流里 3 个不起眼的 bug 在暗中奖励它“早点收工”。
先描述一下现象。在 staging 里，我们的 n8n 编排的 Agent 流程是这样的：检索多个来源 → 对比声明 → 验证薄弱点 → 综合答案 → 输出最终结果。上了生产之后，同一个任务变成了：抓一个弱来源 → 直接写答案。最终答案看起来依然漂亮，所以人工抽查时经常蒙混过关。最危险的就是这个——坏掉的 Agent 很少看起来是坏的，它往往显得“高效”。
为什么生产环境会这样？因为生产环境有一堆 staging 隐藏起来的约束：超时时间、解析器要求、成功条件、回退分支、队列压力。这些约束构成了 Agent 生存的“盒子”，而盒子的规则比模型本身更能决定行为。一个强模型放在坏循环里，表现可能还不如一个普通模型放在干净循环里。
我们追查到了三个具体 bug：第一个是重试上限从 6 降到了 2。对简单分类任务，2 次重试够用；但对研究、调试、文档综合这类需要多步工具调用的任务，2 次重试就是个坑。一次检索结果差，加上一次工具抖动，预算就用完了。配置漂移往往很隐蔽，看起来无害，直到你的工作流依赖 search + fetch + verify 链条。
第二个 bug 更阴险：n8n 里有一个格式化分支，只要输出符合 schema 且长度超过某个最小值，就标记为成功。这等于告诉 Agent：你跳过检索深度也能过关。这无意中成了一个“浅答案奖励函数”——你明明想控制质量，却在训练 Agent 提前停止。
第三个 bug 出在 OpenAI 兼容 API 路径上：只要第一个看起来可接受的答案被接受，而且从不检查预期的工具路径是否执行，编排层就开始选“快”而不是“深”。这一点在 GPT-5.4、Claude Opus 4.6、Grok 4.20 上都一样。模型不是抽象意义上“选择偷懒”，是你的工作流在告诉它：只要足够快看起来完事，就放行。
那怎么区分是模型问题还是编排问题？最有效的信号是 stop reason（停止原因），而不是最终答案评分。对 Anthropic 系列的 Agent，要看它的 stop reason 是什么；对 OpenAI 兼容工作流，要检查预期的工具调用是否真的触发了、推理路径是否真的用了、运行结束是因为模型自己完成还是编排层觉得“够了”。如果只看最终答案，你就是在瞎调试。
我们做了对照实验：用同一个坏掉的生产脚手架跑多个模型家族。GPT-5.4 在生产 n8n 流程下表现差，但在 staging 流程下正常；Claude Opus 4.6 和 Grok 4.20 也在坏流程下变差。三个强模型在同一工作流下都变懒，那大概率是工作流的锅。这里有个简单的判断模型：如果只有一个模型退化，其它稳定，嫌疑在模型或供应商；如果所有模型在一个工作流下都退化，嫌疑在编排逻辑；如果输出在重试/超时调整后变短，那就是早期停止；如果 JSON 合法性变好但答案质量下降，那是解析器优先的奖励问题。
我们还走了一段弯路，先怀疑模型层：是不是 GPT-5.4 真退化了？是不是 Responses API 设置变了？是不是 reasoning effort 太低？是不是输出 token 限制截断了答案？这些都可能是真实故障，但不是这里的主因。真正的问题是 staging 奖励“有依据的完成”，production 奖励“格式好看的完成”。Agent 会优化你工作流奖励的东西。如果你的自动化说“差不多就行”，三个顶级模型都会表现出可疑的急于结束。
需要警惕的几类模式：解析器优先设计——如果主要目标是输出合法 JSON，很多 Agent 会先满足解析器再满足任务；直接回答的逃逸口——如果流程允许在检索或验证之前就给最终答案，那浅层完成就是必然；多步任务用极小的重试预算——全局统一重试预算可能适合分类和轻量转换，但绝对不适合代码调试、文档对比、多源综合；只评估最终消息——这个最严重，它会把跳过的工具调用、失败的搜索、解析器走捷径、提前退出、超时驱动的“伪结论”全部藏起来。我强烈认为，正是这个习惯让团队以为自己在比较模型，实际上在比较编排失误。
我们没换模型，只改了工作流。具体修复：research 类任务重试预算恢复为 6；加了一道硬性门禁——如果任务类型是 research，至少有一次检索步骤发生才能通过校验。就这么简单，质量立刻回来了。
这件事给我的启发是：生产环境里“模型变懒”多数时候是误诊。不要急着骂模型，先检查你的编排层是不是在偷偷教它放弃。任何跑 Agent 的团队，都应该把重试预算、成功条件、解析器权重和停止原因监控列入例行审计。尤其要小心那些看起来“效率高”的 Agent——它可能只是找到了你在奖励的捷径。
内容与图片版权归原作者所有 · 原文: https://dev.to/lars_winstand/we-thought-our-gpt-54-agent-got-lazier-in-production-it-was-a-3-bug-workflow-teaching-it-to-quit-1b3b