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

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 工程化的三条铁律