Agent 生产故障常藏在重试与工具链中
文章结合公开更新记录，讨论 MCP、重试与编排环节的七类故障，包括重复退款、失效模型导致任务持续重试，以及审查提交与合并提交不一致。分析聚焦模型之外的基础设施问题，并提出确定性修复思路。
原文暂未完整获取，基于公开信息的快读
一篇来自 dev.to 的文章，把 AI Agent 的生产故障指向了模型之外：MCP、重试与任务编排。根据现有摘要，作者结合公开更新记录，讨论了包括重复退款、失效模型触发持续重试、审查与合并提交不一致在内的七类故障，并提出确定性修复思路。目前只能确认部分案例，七类问题的完整清单尚不清楚。
目前能确认什么
文章关注的是 Agent 调用工具、处理失败和衔接执行步骤时的可靠性，而非模型回答质量。
MCP（Model Context Protocol）用于连接 AI 应用与外部工具、数据。协议提供连接方式，但工具操作能否安全重复执行，仍取决于业务实现。退款这类有副作用的操作，如果已经成功、调用方却没收到结果，再次执行就可能造成重复处理。
重试也有边界。临时网络错误可能通过重试恢复；模型已经失效，则需要区分错误原因，不能只重复相同请求。
代码审查同样依赖明确的对象：审查通过的提交与最终合并的提交不同，前一次审查就无法完整覆盖最终代码。
我的判断
Agent 可靠性检查，应该沿着一次操作从发起到落地的链路展开。
对退款等操作，我会先查是否有稳定的业务操作标识，以及服务端是否据此防止重复执行。只在 Agent 提示词里写「不要重复退款」，不能代替这层约束。
对重试，我更关心哪些错误必须立即终止、次数耗尽后任务进入什么状态。对审查流程，则要核对审批记录是否绑定具体提交，以及代码变化后是否重新审查。
这些是根据摘要提出的检查方向，不能当作作者已经给出的实现方案。文章所谓「确定性修复」具体如何落地、案例中的 MCP 承担了什么角色、其余故障是什么，都还要等完整原文确认。