前言
在构建基于大语言模型（LLM）的自动化运维（AIOps）Agent 时，我们往往沉迷于 Prompt Engineering 的精妙和工具调用的灵活性。然而，在生产环境中，一个看似完美的 ReAct（Reasoning + Acting）Agent 可能会因为一个微小的逻辑漏洞，陷入无限循环的"鬼打墙"，不仅消耗大量 Token，更导致服务超时不可用。
本文将以一个真实的私有云产品部署诊断 Agent 为例，深度复盘一次典型的死循环事故，剖析其根因，并给出从 Prompt 设计到架构优化的系统性解决方案。
1. 事故现场：停滞的诊断机器人
背景
我们开发了一个名为 DiagnoseBot 的 Agent，用于对私有云平台（onTianji）上的服务部署失败进行初筛诊断。它的任务是根据 SR（Service Role）的状态，按步骤检查环境、资源、日志，最终输出结构化报告。
现象
在一次针对 emergency 服务的诊断任务中，Agent 在执行了约 80 秒后超时失败。查看日志发现，Agent 在最后阶段陷入了疯狂的重复调用：
[Step N] Call: get_hosts -> Result: [host1, host2, host3]
[Step N+1] Call: check_state -> Result: {"is_final": false}
[Step N+2] Call: get_hosts -> Result: [host1, host2, host3] <-- 重复！
[Step N+3] Call: check_state -> Result: {"is_final": false} <-- 重复！
... (循环持续直到超时)尽管 Prompt 中明确规定了严格的诊断流程（Step 1 -> Step 2 -> Step 3），但 Agent 却在"检查环境"和"检查终态"之间无限徘徊，从未进入核心的日志分析环节，或者在进入后无法退出。
2. 根因深挖：为什么 ReAct 会"失忆"？
通过深入分析对话历史（Conversation History）和工具返回值，我们定位到了三个核心问题。
2.1 "空结果"引发的语义歧义
这是最直接的导火索。当 Agent 终于调用 analyze_docker_log 时，工具返回了：
{
"component_status": null,
"log_type": null,
"full_result": {}
}问题分析：
- 对于人类开发者 ：空对象
{}意味着"没发现错误"或"日志为空"。 - 对于 LLM ：这是一个中性且模糊的信号。
-
- Prompt 规定："如果 Docker 日志未发现问题，继续分析"。
- 但是，
null和{}并没有明确告诉 LLM "这一步已完成，请执行下一步"。 - LLM 产生了一种不确定性："这个结果是正常的吗？还是工具出错了？既然没报错，是不是环境还没准备好？"
出于"保守"和"求证"的本能，LLM 选择回退到它最确信的基础检查步骤（get_hosts），试图通过刷新上下文来确认环境状态，从而导致了循环。
2.2 ReAct 模式的"无状态"缺陷
ReAct 模式的核心是 Thought -> Action -> Observation 的循环。它依赖 LLM 的短期记忆（Context Window）来维持流程。
缺陷暴露：
- 缺乏显式状态机：Prompt 虽然用自然语言描述了流程（Step 1, Step 2...），但这只是"建议"，而非"代码约束"。
- 注意力分散：随着对话历史变长，LLM 对早期指令（"按顺序执行"）的关注度下降。当遇到模糊观测值（空日志）时，它更容易受到近期高频出现的模式（如反复检查状态）的影响，而不是遵循初始的全局计划。
- 没有"已执行"标记 ：Agent 不知道
check_state已经在 3 步前执行过了。在它的视角里，每一次调用都是新的决策。
2.3 工具设计的"被动性"
我们的工具设计遵循了"最小信息原则"，只返回原始数据。但在 Agent 场景中，工具不仅是数据的提供者，更是指令的传递者。
- 错误设计 ：
analyze_docker_log返回空结果，让 Agent 自己去猜下一步。 - 正确设计 ：工具应返回带有行动建议的结构化数据，或者直接由 Orchestrator 控制流程跳转。
3. 破局之道：四层防御体系
为了解决这个问题，我们实施了从提示词到架构的四层优化方案。
第一层：Prompt 工程优化（增加思维链约束）
在 System Prompt 中引入显式的状态追踪 和防重机制。
修改前：
"如果 Docker 日志未发现问题，继续分析自定义日志。"
修改后：
"你必须维护一个内部状态列表 executed_steps。
- 每次调用工具前，检查该工具是否已在当前诊断会话中执行过。如果执行过且结果无变化，严禁再次调用。
- 当
analyze_docker_log返回空结果或无异常时，视为'Docker 日志检查通过'，必须 立即调用analyze_xxx_log。 - 在 Thought 中明确写出：'Docker 日志无异常，根据流程第 5 步，接下来检查自定义日志'。"
第二层：工具返回值增强（语义明确化）
改造工具接口，使其返回值具备指导性。
优化后的 analyze_docker_log返回示例：
{
"status": "clean",
"message": "Docker日志中未发现堆栈异常或依赖错误。",
"suggestion": "proceed_to_xxx_log", // 明确指引下一步
"data": {}
}这样，LLM 即使"失忆"，也能从最新的 Observation 中读到 suggestion，从而被强行拉回正确的流程轨道。
第三层：架构升级（从 ReAct 到 Graph/State Machine）
对于流程固定、逻辑严谨的运维场景，纯 ReAct 并非最佳选择。我们引入了 LangGraph 或类似的状态图架构。
架构示意：
在这种架构下，节点之间的跳转是硬编码的。AnalyzeDocker 节点执行完后，无论结果如何，都会根据预设条件流向 AnalyzeCustom 或 ReportError，彻底杜绝了"回退到 CheckEnv"的可能性。
第四层：框架层兜底（去重与熔断）
在 Agent 框架层面添加安全网：
-
动作去重（Action Deduplication） ：记录最近
步的工具调用签名（Function Name + Args）。如果检测到重复调用，直接拦截并注入一条系统消息："警告：检测到重复操作，请跳过此步骤并执行流程中的下一项。" -
最大迭代限制 ：设置合理的
max_iterations（如 15 次）。一旦超限，强制终止并返回"诊断超时，需人工介入"，避免资源浪费。
4. 经验总结与建议
✅ Do's
- 工具即指令：让工具返回值包含"下一步建议"或"状态标识"，减少 LLM 的推理负担。
- 流程固化：对于线性、强逻辑的业务流程，优先使用 State Machine 或 Graph 架构，而非纯自由的 ReAct。
- 显式记忆：在 Prompt 中要求 Agent 维护"已执行步骤列表"，并在每次 Thought 中更新它。
❌ Don'ts
- 不要依赖 LLM 的"自觉"：不要假设 LLM 会记住复杂的自然语言流程步骤，它会遗忘、会幻觉、会偷懒。
- 不要返回模糊的空值 ：
null、{}、""是 Agent 的敌人。务必赋予它们明确的业务含义。 - 不要忽视重试成本：在私有云或高延迟环境下，一次死循环可能消耗数百美元的 Token 和数分钟的计算资源。
结语
Agent 的开发不仅仅是 Prompt 的调试，更是确定性工程 与概率性模型的博弈。通过引入状态管理、优化工具语义以及架构层面的约束，我们可以将 ReAct Agent 从"随性的聊天者"转变为"可靠的执行者"。
希望这篇踩坑记录能为正在构建 AIOps Agent 的你提供一些参考。欢迎在评论区分享你遇到的 Agent 死循环案例！