在云产品智能诊断场景里ReAct 很强但也很容易“想太多、做太久、停不下”。尤其当诊断对象是 K8s、ECS、负载均衡、数据库、配置中心这类强依赖外部状态的系统时模型经常会在同一个观察—推理—行动闭环里反复绕圈查了同一个日志、读了同一段事件、得到了几乎没变化的结果然后继续得出相似结论最终进入死循环。这时候单纯依赖 prompt 里的一句“请避免重复”通常不够。更稳妥的方式是在 ReAct 外围加一层Harness它负责统计近期执行轨迹、识别循环模式、触发干预策略并在必要时中止或切换执行路径。ReAct 负责推理Harness 负责监控和打断Verifier 负责验收。同时还要补充一点如果某些场景本身是固定流程且步骤明确、依赖稳定那就不一定适合交给 ReAct 动态编排应该由工程系统自己按固定流程编排执行。也就是说能流程化的就流程化能确定性的就不要让模型自由发挥。一、云产品智能诊断里ReAct 为什么容易死循环云诊断和普通问答不一样它不是“答对就行”而是要在大量噪声信息中持续收敛根因。这类任务有几个典型特征输入不完整往往只有一条告警或一段报错信息分散在日志、指标、事件、配置、发布记录里证据之间可能互相矛盾最终结论必须能被验证中途状态还会变化比如实例重启、Pod 重建、流量切换在这种情况下ReAct 很容易出现以下问题1一直在同一条假设上打转比如看到ImagePullBackOff模型不断检查镜像、仓库、secret、deployment diff但结果其实已经证明镜像 tag 写错了却没有明确终止条件继续查下去就会重复。2工具调用没有新信息模型会反复调用同一个检查工具参数也几乎一致但观察值没有变化。3上下文越来越长历史日志、事件和推理都堆在上下文里模型开始依赖旧判断导致错误被放大。4模型自己不知道已经循环了ReAct 的循环本身是“合理的”因为它每一轮都在根据观察继续推理但如果缺少外部约束它就可能永远不结束。二、Harness 在哪里介入Harness 不是简单“再加一个提示词”而是一个外部控制层。它把“模型是否在循环里”这件事做成一个工程问题而不是让模型自我判断。Harness 的核心职责包括统计近期执行轨迹识别重复工具调用识别重复观察结果识别重复结论文本判断是否进入死循环注入干预 prompt限制工具压缩上下文中止执行切换策略交给 Verifier 验收三、架构时序这张架构图展示了 ReAct 死循环的工程化解决方案ReAct 负责推理和工具调用Harness 负责统计近期执行并判断是否进入循环必要时通过 prompt 干预、工具限制或终止执行来打断回路Verifier 则负责最终验收。这张时序图说明了 Harness 如何在每轮执行前后介入先统计近期轨迹判断是否出现重复模式若命中循环风险则注入干预若未命中则允许继续执行并在状态外化后进入终态验证。四、云产品智能诊断案例Pod 启动失败导致 ReAct 反复打转下面用一个最常见的 K8s 场景来说明。场景现象某个 Deployment 更新后Pod 一直处于ImagePullBackOff执行kubectl get pods看到my-app-5d7d978fb9-2fj5m 0/1 ImagePullBackOff 0 2m这说明 Pod 在拉镜像阶段就失败了。如果没有 HarnessReAct 可能怎么循环第 1 轮观察PodImagePullBackOff推理可能是镜像不存在行动查镜像 tag第 2 轮观察镜像 tag 不匹配推理可能是仓库认证失败行动查imagePullSecret第 3 轮观察secret 正常推理可能是仓库网络问题行动查仓库连通性第 4 轮观察连通性正常推理可能是 deployment 配置错了行动查部署 diff第 5 轮观察diff 显示镜像 tag 的确写错了推理问题已定位但模型仍继续想确认更多证据行动重复查镜像、重复查事件……这时如果没有外部约束ReAct 很容易继续绕圈明明已经足够收敛却迟迟不退出。有 Harness 介入后流程会怎样变化第 1 轮规划ReAct 先生成诊断路径查镜像引用查 Pod 事件查imagePullSecret查部署 diff第 2 轮执行与统计Harness 记录每次工具调用和观察结果发现check_image_reference已调用过query_pod_events已调用过inspect_image_pull_secret已调用过get_deployment_diff已调用过第 3 轮循环检测Loop Detector 判断连续 3 轮观察变化很小同一个工具调用重复出现结论和上一轮高度相似于是 Harness 触发干预。第 4 轮干预Intervention Controller 可以做这些事注入 prompt“你已经检查过镜像、事件和 secret请切换到终态判断不要重复相同工具。”压缩上下文只保留关键证据例如image_tag v2.0、image_exists false限制工具临时禁用已经重复调用的工具直接终止如果已经达到阈值升级人工第 5 轮Verifier 验收如果修复后 Pod 变为Runningreadiness probe 通过任务结束。如果没有通过进入下一轮诊断但不会再无限重复同一路径。五、固定流程场景不要强行交给 ReAct 动态编排还有一种情况要特别说明如果某些场景本身是固定流程、步骤明确、依赖稳定那就不应该让 ReAct 动态编排应该由工程系统自己按固定流程执行。比如固定的巡检流程固定的上线前校验流程固定的告警分级流程固定的修复脚本执行流程这类场景的特点是步骤已知顺序明确条件稳定不需要模型自由判断太多这种情况下最好的做法不是让 ReAct 自己决定下一步而是直接由编排引擎、工作流引擎或脚本流程来控制执行顺序。ReAct 更适合处理不确定、信息不完整、需要动态判断的情况固定流程交给固定编排效率更高风险更小也更容易审计。六、ReAct 死循环排查清单下面这部分可以直接作为公众号正文里的实操清单。1先确认是不是真的进入死循环观察是否存在以下特征同一个工具反复调用同一组观察结果重复出现模型输出高度相似token 消耗持续上升但状态没有变化一直没有进入完成或失败退出2检查终止条件是否清晰最常见的问题是没有明确的结束标准。排查点是否只靠模型自己判断完成是否有外部验收条件是否有明确的成功标志是否有失败退出条件修复建议增加max_iterations增加completion_promise增加外部验证例如测试通过、状态变更、目标文件生成3检查是否存在状态更新触发自身再次更新很多死循环本质上是当前步骤更新了某个状态这个状态又反过来触发了同一个步骤。修复建议用ref保存不应触发重渲染的状态对对象/数组做稳定化处理避免在 effect 内直接修改触发源状态把“计算下一步”和“写回状态”分离4检查工具调用是否缺少去重和幂等修复建议对工具调用做 request hash 去重相同输入在短时间内直接复用结果给工具调用加幂等键对重复调用直接返回上次结果5检查观察结果是否真的有变化修复建议提升工具输出质量让工具返回更结构化的信息加入更多上下文维度必要时做降级直接转人工6检查模型是否在“自我确认”修复建议要求每一轮必须产出“新证据”或“新动作”如果没有新信息禁止继续同一路径对重复结论做拦截7检查上下文是否过长导致失焦修复建议做上下文摘要只保留关键证据把状态外化到文件或数据库让下一轮只读摘要不读全量历史8检查是否缺少最大迭代次数修复建议必须设置max_iterations超限后自动退出并升级人工记录失败原因而不是继续空转9检查是否该切换到别的模式如果任务具备以下特点结果可验证需要长期执行有明确终态需要强制推进那就不要只靠 ReAct应该切到Claude Code 式 Agent LoopHarness 驱动的执行循环状态外化 验证机制七、Harness 在工程上如何打断循环1执行前统计近期轨迹Harness 会观察最近 N 轮的工具调用返回结果观察摘要结论文本如果发现同一工具重复调用同一参数 hash 反复出现同一观察重复 2~3 轮结论没有新增证据就判定为循环风险。2执行中注入干预当 Harness 判断进入循环时可以做几种干预注入新的 prompt要求切换诊断路径压缩上下文只保留关键证据禁止继续调用同一个工具切换到更保守的策略直接中止并升级人工3执行后验收是否真的收敛即便 ReAct 产生了“看起来合理”的结论也不能直接结束。Harness 会把结果送到 Verifier检查目标状态是否真的改变。没有通过验收就继续下一轮而不是让模型自己宣布结束。八、工程落地建议1ReAct 层只负责规划不要让它承担终态判定。2Harness 层负责循环监控这是防死循环的关键。3状态一定要外化把调用历史、观察结果、去重键、失败原因全部写到文件或数据库里。4Verifier 必须独立不要把“是否完成”交给模型主观判断。5对重复调用做硬约束对已经命中过的工具、参数、观察结果做强制去重和限流。6固定流程交给编排系统如果是已知步骤、已知顺序、已知条件的固定流程不要强行交给 ReAct 动态编排直接由工作流或脚本执行更稳。九、总结ReAct 死循环本质上是推理闭环没有被外部约束切断。在云产品智能诊断里这个问题尤其常见因为任务本身就依赖外部系统状态天然容易反复验证、反复推理、反复确认。真正有效的解决方案不是让模型“更聪明一点”而是把系统做成一个工程闭环ReAct负责找方向Harness负责监控和打断循环State Store负责记录与恢复Verifier负责终态验收固定流程则交给工程编排系统