我做了 6 个 Agent5 个死在节点 3→4 那一步的失败重试上——不是 prompt 写错是没人定义清楚什么时候算失败、失败了交给谁。这篇文把 7 个根因拆透再附 5 步回归脚本复制即可用。为什么 6 个 Agent 死了 5 个跑 Agent 的真实体感第 1 个 Agent14 节点全自动化单次跑 40 分钟 →死于调试失控第 2 个 Agent4 节点超简约没考虑上下文传递 →死于效果失真第 3 个 Agent节点没问题但失败重试机制错乱 →死于雪崩重试第 4 个 Agent调试 3 周跑通了第 4 周一次数据 schema 变更全线崩 →死于回归缺失第 5 个 Agent跑通了不敢上线因为没人能解释为什么 →死于运维盲区第 6 个 Agent压缩到 6 节点 两层重试 5 步回归 →跑通上线按死法反推根因下面 7 个根因按中招频率排序全是亲手踩的坑。根因 1节点数超过 7 个不预警第 1 个 Agent 我做了 14 个节点理由是拆细一点可控结果调试一次 40 分钟。14 节点的单次跑动时间分布节点任务平均耗时1-3输入 拆题 检索3 分钟4-7生成带 4 次重试18 分钟8-11事实核查 改写 风格化12 分钟12-14分发 监控 收尾7 分钟4 个生成节点占 45% 的时间——节点越多重试路径越长雪崩概率指数级上升。后来定下规矩Agent 总节点 ≤ 7生成节点 ≤ 2。根因 2失败定义模糊第 2 个 Agent 调了 2 周调不通根因是没人定义什么算失败。我列了 4 类失败定义失败类型定义处理路径网络错误HTTP 5xx、超时、限流重试同 prompt模型错误输出 schema 不符 / 长度超限 / 关键词缺失改 prompt 重试业务错误数字对不上 / 公司名错 / 年份错转人工核查上下文错误Token 超限 / 引用断裂截断 摘要最大坑把业务错误当模型错误一直重试同一个错重试 5 次还是不通过。根因 3失败重试不分层第 3 个 Agent 失败的根因最常见也最难查重试不分层。# 反例所有错误都同 prompt 重试 5 次forattemptinrange(5):try:returncall_model(prompt)exceptExceptionase:log(e)continue# 网络错误和模型错误混在一起正确做法是两层重试defretry_two_layer(prompt,max_same2,max_new2):网络错误重试 / 模型错误改 prompt / 业务错误转人工last_errNone# 第一层同 prompt 处理瞬时错误for_inrange(max_same):try:returncall_model(prompt)except(Timeout,RateLimit)ase:# 仅瞬时错误time.sleep(2**_)last_errecontinueexceptModelErrorase:# 模型错误立即跳出last_errebreak# 第二层换 prompt 处理设计错误for_inrange(max_new):new_promptrefine(prompt,errlast_err)try:returncall_model(new_prompt)exceptModelErrorase:last_errecontinue# 业务错误 / 重试用尽 → 转人工raiseHumanReviewRequired(last_err)根因 4Token 预算没按节点算第 1 个 Agent 跑一次 8 万 token单次 0.6 元听着不贵但规模化后是隐患。我后来按节点算账节点Token 预算单次成本DeepSeek-V3输入 / 拆题5000.001 元检索 / 向量化40000.008 元生成带 1 次重试120000.024 元事实核查50000.010 元风格改写80000.016 元分发 / 收尾10000.002 元合计305000.061 元按月跑 1000 次 61 元可控。第 1 个 Agent 那种 8 万 token / 次的设计月跑 1000 次 600 元差 10 倍。根因 5上下文 schema 不校验第 4 个 Agent 跑通后第 4 周崩了根因是某个节点输出从{name: str}变成{user_name: str}下游节点直接读name拿不到值整整 200 个任务静默失败——因为没报错输出一直是空字符串。解决每个节点出口加 schema 校验schema 变了 → 立刻 fail-fast 转人工不让它静默蔓延。根因 6Token 截断策略不统一上下文超限是 Agent 失败第三大原因。三个常见错误硬截断到 N token——切断在句子中间下游读到半句话按字符数截断——中文 / 英文密度不同截断点飘忽不截断直接报超限——重试 3 次还是超限正确做法按语义边界截断段落 / 列表项 / 引用结束截断后强制加摘要节点保留关键事实。根因 7没有回归脚本第 4 个 Agent 上线 3 周后崩问题不是 prompt 错了是没人写回归脚本——每次 prompt 调整都不知道会不会影响历史 case。我现在每次 Agent 改 prompt必跑下面这套5 步回归脚本。5 步回归脚本myaifast-1101#!/bin/bash# myaifast-1101-regression.sh# 用途Agent 改 prompt 后跑这套5 步定位影响set-eecho[1/5] 抓取历史 50 条 case → /tmp/agent_cases.jsonlmyaifast-cli pull cases--limit50--out/tmp/agent_cases.jsonlecho[2/5] 用当前 prompt 重跑全部 casemyaifast-cli run-batch\--cases/tmp/agent_cases.jsonl\--prompt/tmp/current_prompt.txt\--out/tmp/run_results.jsonlecho[3/5] 与历史输出做 diff标记回归myaifast-clidiff\--history/tmp/history_results.jsonl\--current/tmp/run_results.jsonl\--threshold0.15\--out/tmp/regression_report.mdecho[4/5] 4 项关键指标校验python3 check_metrics.py /tmp/run_results.jsonlecho[5/5] 输出 PASS / FAIL 报告FAIL 则禁止上线myaifast-cli gate--report/tmp/regression_report.md5 步分别防什么抓历史 50 条 case → 防止用 AI 现编的 case 自测用当前 prompt 重跑 → 防止只在脑子里跑了一遍diff 历史输出 → 防止改了一处崩了三处4 项关键指标 → 防止输出对但效果崩PASS/FAIL 门禁 → 防止明知有问题还是上线4 项关键指标步骤 4 校验# check_metrics.pyMETRICS{schema_valid_rate:0.98,# 输出符合 schema 的比例fact_accuracy:0.95,# 数字 / 公司名 / 年份正确率length_in_range:0.90,# 字数落在目标区间token_budget:1.20,# 单次 token 不超过预算 120%}任意一项不达标 → 脚本退出非零 → CI 拒绝合并。真实跑通案例第 6 个 Agent 的配置维度第 1 个 Agent第 6 个 Agent节点数146单次耗时40 分钟6 分钟Token8000030500单次成本0.60 元0.061 元错误率35%4%上线状态弃用跑通少 8 个节点 多 2 层重试 5 步回归效果提升 9 倍成本降 90%。反共识克制一处很多人觉得Agent 失败 prompt 不够好实际跑下来 6 个 Agent 死因统计prompt 问题仅占 18%重试机制问题占 41%最大schema 校验缺失占 23%Token 截断策略占 12%上下文记忆问题占 6%重试机制是 Agent 失败的头号根因比 prompt 重要得多。先把重试范式做对再去调 prompt。Agent 调试的 3 个常见误区跑 6 个 Agent 死 5 个之外我还见过团队常踩的 3 个误区误区 1把单点跑通当Agent 跑通很多团队在第 3 节点手动跑了 10 条 case 都对就认为 Agent 跑通了。真相是 Agent 的失败往往出现在节点衔接处——上下文传递、schema 校验、Token 截断这些跨节点的逻辑单独跑没问题连起来就崩。我后来养成的习惯是永远跑完整链路不接受分段验证。误区 2把功能正确当生产可用Agent 跑通功能 ≠ 能上线生产。生产环境要面对流量峰值、Token 限速、长尾输入、数据 schema 漂移、上下游依赖变更。每个维度都可能让 Agent 静默失败。所以我加的 5 步回归脚本里第 3 步 diff 阈值设为 0.15输出差异 15%是经验值——低于这个阈值通常只是语气微调高于就要人工审查。误区 3把prompt 改完当Agent 改完改完 prompt 后回归脚本跑了 PASS就以为 Agent 升级完了。但 prompt 改了之后Token 预算、上下文截断点、缓存命中率都会变。我后来加了一个**“prompt 变更影响清单”**每次改 prompt 必过 6 项检查Token 预算是否突破上下文截断点是否需要重设缓存命中率是否会变化错误率指标是否仍达标监控告警阈值是否需要调整历史 case 是否全部回归通过我用的 Agent 健康度看板4 个指标每次 Agent 跑完一个批次我会更新 4 个核心指标连续 7 天追踪指标目标值计算方式跑通率≥ 96%一次成功 / 总任务数平均 Token≤ 预算 100%实际 token / 节点预算人工介入率≤ 5%人工接管数 / 总任务数回归通过率100%5 步回归 PASS / 总回归批次跑通率跌破 92%、人工介入率突破 8%立刻触发告警——往往是上游依赖或数据 schema 漂移必须先停再查。跑通后我做的 4 件事第 6 个 Agent 跑通后我没立即上线做了 4 件看起来多余但救命的事写操作手册——把每个节点的为什么这么做写清楚避免下一个人改错跑 50 条历史 case——验证对历史数据的兼容性不能只测新数据设监控告警——4 个核心指标看板 钉钉/Slack 告警准备回滚方案——版本快照 一键回退脚本回滚方案救过我两次第一次是上游模型 API 变更第二次是数据源 schema 改了。如果没有版本快照每次回滚要重做 prompt重做又要重跑回归——一个下午就没了。给 Agent 团队的 5 条建议跑过 6 个 Agent 之后我对团队的硬要求每次 Agent 上线必须有回归脚本不接受我觉得没问题失败重试必须分两层同 prompt 与换 prompt 路径必须分开schema 校验在每个节点出口必做防止静默失败Token 预算按节点算账不接受的我先跑跑看监控 4 个核心指标跑通率跌破 92% 立即停这 5 条是我用 5 个 Agent 死掉的代价换来的希望你少走点弯路。可复用下载包文件内容myaifast-1101-regression.sh5 步回归脚本主脚本myaifast-1101-check-metrics.py4 项关键指标校验myaifast-1101-retry-two-layer.py两层重试 Python 模板myaifast-1101-node-budget.xlsx7 节点 token 预算表myaifast-1101-failure-types.md4 类失败定义 处理路径myaifast-1101-mcp-integration.tsMCP 接入示例含错误分类myaifast-1101-case-history.jsonl50 条历史 case 样本脱敏下载https://www.myaifast.com 编号myaifast-1101。行动清单节点数 ≤ 7——超过必崩复杂度失控失败定义 4 类——网络 / 模型 / 业务 / 上下文路径必须分开重试分两层——同 prompt 处理瞬时错误换 prompt 处理设计错误按节点算 Token 预算——6 节点单次 0.06 元规模化可控5 步回归必跑——FAIL 则禁止上线别靠我觉得没问题一句结论Agent 失败的头号根因不是 prompt是失败重试范式——重试分两层 5 步回归是 Agent 跑通的最低门槛。本文工具实测环境为麦芽AImyaifast详见 https://www.myaifast.com