LLM Agent死循环卡死：Tool Calling无限重试与确定性状态机防线

原创于 2026-08-03 15:57:41 发布 · 242 阅读

2 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

LLM Agent死循环卡死：Tool Calling无限重试与确定性状态机防线

1. 生产事故报警：后台 Agent 协程卡死，单次请求触发 200 次 Tool Calling

上周二线上告警群发来急报：处理自动化数据分析的后台 Agent 节点内存与 CPU 持续居高不下，服务响应延迟急剧飙升。

调出日志一看令人震惊：一个简单的“查询近七日订单”任务，LLM Agent 在调用 Tool Calling 时由于工具返回了包含特殊字符的异常字符串，导致大语言模型未能成功识别结果。原本预期模型在收到错误提示后会向用户报错或要求重新输入，但非确定性的 LLM 却陷入了狂躁状态：它不断尝试重新生成相同的 Tool Call 请求，后端 Worker 傻傻地执行，执行完模型又报错，形成了一个无休止的死循环！

单次 Request 在短短几分钟内触发了超过 200 次工具调用，不仅迅速耗尽了 API Rate Limit 限额，还导致后台 Goroutine 协程大量挂起塞爆了内存缓冲区。值班运维工程师在跳板机上输入 top -hp 查看，发现后台执行线程已经将协程池全部占满。

flowchart TD
    Req[用户 Task 请求] --> Agent[LLM Agent 思考]
    Agent --> ToolCall[Tool Calling 产生异常格式]
    ToolCall -->|无轮次限制| RetryLoop[死循环: 失败 ➔ 重试 ➔ 再次失败]
    RetryLoop -->|爆 Token | Billing[耗尽 API 额度 & 卡死协程]
    Agent -->|加入状态机防线| FSM{MaxSteps 轮次 & 幂等 Hash 校验}
    FSM -->|超限| FastFail[Fast-Fail 截断降级]

2. 根因剖析：过度信任模型的自主闭环，缺失确定性工程闸门

深挖代码实现发现，早期开发为了图省事，给 Agent 写了一个简单的 for 循环：

// 危险示范：缺乏状态机轮次上限与幂等校验
for {
    resp := llm.Chat(history)
    if resp.HasToolCall() {
        result := executeTool(resp.Tool)
        history.Append(result)
    } else {
        break // 依靠模型自己决定何时退出
    }
}

这种设计完全把控制权交给了具有非确定性（Nondeterminism）的大模型。在真实生产工程中，大语言模型的概率输出绝不可作为控制流的绝对依赖。一旦模型输出不符合预期，或者工具返回了模型无法理解的错误提示，resp.HasToolCall() 就会永远成立，导致代码直接陷入无限死循环。

此外，由于没有设置单次任务的全局 Context 超时限定，后台协程会一直挂起占用系统资源。在高并发流量冲刷下，这些死锁的协程会逐渐耗尽 Worker 线程池，最终拉垮整个 Agent 微服务集群。我们发现该故障导致当天的 OpenAI/Claude API 费用暴增了近 400 美金，给团队带来了直接的财务经济损失。

3. 防线重构：确定性状态机（FSM）与 Tool Call 幂等 Hash 校验

治理非确定性 LLM 的核心原则是：用确定性的软件工程体系（状态机、轮次硬限制、幂等 Hash 校验）为模型画出绝对安全边界。大模型可以负责概率性的语义理解，但流程推进必须由外部确定性代码锁死。

我们制定了两步重构防线：第一步是在 Agent 外层封装带有硬性轮次上限 MaxSteps 的有限状态机（FSM），强制拦截超限死循环；第二步是对每次工具调用的名称与入参计算 SHA256 幂等 Hash 值，一旦检测到连续多次触发完全相同的工具与参数，立即判定模型陷入逻辑死锁并触发 Fast-Fail 截断降级。

重构后的确定性 Agent 执行器代码如下：

package main

import (
	"context"
	"crypto/sha256"
	"encoding/hex"
	"errors"
	"fmt"
	"time"
)

var (
	ErrMaxStepsExceeded  = errors.New("agent execution reached max steps limit")
	ErrDuplicateToolCall = errors.New("detected duplicate tool call loop")
)

// AgentFSM 确定性 Agent 状态机执行器
type AgentFSM struct {
	MaxSteps int
	seenHash map[string]int
}

func NewAgentFSM(maxSteps int) *AgentFSM {
	return &AgentFSM{
		MaxSteps: maxSteps,
		seenHash: make(map[string]int),
	}
}

func (f *AgentFSM) CalculateToolHash(toolName string, args string) string {
	h := sha256.New()
	h.Write([]byte(toolName + ":" + args))
	return hex.EncodeToString(h.Sum(nil))
}

func (f *AgentFSM) ExecuteWithGuard(ctx context.Context, task string) error {
	ctx, cancel := context.WithTimeout(ctx, 30*time.Second)
	defer cancel()

	for step := 1; step <= f.MaxSteps; step++ {
		select {
		case <-ctx.Done():
			return ctx.Err()
		default:
		}

		fmt.Printf("[STEP %d/%d] LLM 正在思考...
", step, f.MaxSteps)
		// 模拟 LLM 返回 Tool Call
		toolName := "query_order_db"
		args := `{"user_id": "10086"}` // 模拟重复参数

		// 校验重复 Tool Calling 死循环
		hash := f.CalculateToolHash(toolName, args)
		f.seenHash[hash]++
		if f.seenHash[hash] > 3 {
			// 连续 3 次相同工具调用，断定模型陷入循环死锁，触发 Fast-Fail
			return fmt.Errorf("%w: 工具 %s 参数 %s 连续死锁 3 次", ErrDuplicateToolCall, toolName, args)
		}

		fmt.Printf("[EXECUTE] 安全执行工具: %s
", toolName)
		time.Sleep(100 * time.Millisecond)
	}

	return ErrMaxStepsExceeded
}

func main() {
	fsm := NewAgentFSM(5)
	err := fsm.ExecuteWithGuard(context.Background(), "帮我查询用户订单")
	if err != nil {
		fmt.Printf("[GUARD ALERT] 状态机成功拦截死循环: %v
", err)
	}
}

4. 上线回归：死循环彻底拦截，API 成本下降 35%

上线该确定性防线后，我们在 Staging 环境用诱导性脏数据测试 Agent：
当模型尝试第 3 次重复调用相同的错误工具时，AgentFSM 在 0.1ms 内瞬间触发 ErrDuplicateToolCall 熔断拦截，并优雅返回降级文本，避免了无效的 API Token 消耗。

监控大盘上的 Agent 异常轮次率 降到了零，API Token 浪费减少了近 35%，彻底杜绝了后台协程卡死事故。系统在面对复杂或者畸形的输入任务时，展现出了极强的工程自愈与优雅防爆仓能力。

此外，我们还将 AgentFSM 拦截事件暴露给 Prometheus 监控系统，配置了 PromQL 告警规则：

sum(rate(agent_tool_loop_intercept_total[5m])) > 2

当 5 分钟内连续触发 2 次死循环拦截时，自动化运维机器人会立刻向飞书群推发 P2 预警，方便工程师排查具体的工具接口 Bug。

5. 避坑总结：AI Agent 工程化的三条铁律

绝对不要让大模型独掌循环控制权：必须设置 MaxSteps（如最多允许 5~8 轮）硬性物理上限，防止无限重试。
校验 Tool Call 幂等 Hash：连续相同参数的 Tool Call 超过 2~3 次，即可判断模型陷入昏厥，必须强制熔断。
全局 Context 必须挂 Timeout：任何 Agent 协程必须绑定超时 Context，防止单个非确定性任务永久占用计算资源。
多级降级预案：当 Agent 触发死锁截断时，应优雅返回缓存结果或推荐的人工客服引导，提升用户体验。

标签

#rust #github #python