Agent 决策死循环的主动截断步数熔断器与上下文 Token 阈值守门员设计让自主 Agent自主智能体在没有人工干预的情况下自主运行最让人头皮发麻的场景莫过于决策死循环。一个典型的故障现象是Agent 尝试读取一个由于拼写错误而缺失的配置文件工具返回了file not found大模型在下一轮推理中换了一种文件扩展名再次调用读取工具依然失败紧接着它开始在“列目录-搜索关键字-读取文件”这个三元组里无休止地打转。短短两分钟内二十多次无意义的 Tool Call 呼啸而过上下文窗口迅速被几万个 Token 的重复报错塞满。这不仅会导致单次执行的账单瞬间飙升更致命的是模型的推理能力会随着上下文噪声的急剧堆叠而雪崩彻底陷入“越报错越乱猜、越乱猜越调用”的瘫痪泥潭。构建高可用的生产级 Agent 系统绝不能把任务终止的希望寄托在大模型自身的“良心发现”上。必须在宿主运行时层面建立硬性的外围防线步数熔断器与 Token 阈值守门员。剖析 Agent 死循环的底层诱因与表征在大模型通过 ReActReasoning Acting模式或多步骤规划解决问题时死循环主要表现为三类模式同参震荡Identical Tool Oscillation模型在连续几轮推理中使用完全相同的参数调用同一个工具。这通常发生在工具返回的信息不够明确例如仅返回空数组模型没有理解工具已经尽力误以为上一次调用没有生效。状态乒乓Ping-Pong State Loop在两个或三个工具之间往复跳转。比如执行grep找代码找不到则调用git diff依然没有线索又回退到grep陷入局部最优解出不来。上下文注意力稀释引发的决策退化当历史对话累积了大量工具调用失败的堆栈信息后模型的注意力机制被长距离的无用字符严重分散生成质量大幅下滑输出格式开始频繁出现 JSON 解析错误或空调用。因此截断机制不能等到全局 Context 超限爆掉才被动报错而必须在执行链路上部署能够感知调用特征的动态守护者。第一道防线基于调用签名哈希的步数熔断器单纯设置一个max_steps 30的硬上限是远远不够的。如果一个 Agent 在前 5 步就已经陷入了死循环让它继续空转 25 步完全是对算力和预算的浪费。我们需要一个基于滑动窗口与签名哈希的步数熔断器Circuit Breaker。它的核心逻辑是记录最近 $N$ 次工具调用的方法名与入参摘要一旦检测到重复签名达到阈值或者在小窗口内命中周期性循环立刻触发主动熔断。在 Go 1.27.1 中我们可以通过极简的签名结构体与状态机来实现这一机制package runtime import ( crypto/sha256 encoding/hex encoding/json errors fmt sync ) var ( ErrStepLimitExceeded errors.New(circuit breaker: max execution steps reached) ErrOscillationDetected errors.New(circuit breaker: repetitive tool oscillation detected) ) // CallSignature 表示一次工具调用的轻量级指纹 type CallSignature struct { ToolName string ArgHash string } // CircuitBreaker 步数与调用模式熔断器 type CircuitBreaker struct { mu sync.Mutex maxSteps int currentStep int windowSize int recentCalls []CallSignature historyCount map[CallSignature]int } func NewCircuitBreaker(maxSteps, windowSize int) *CircuitBreaker { return CircuitBreaker{ maxSteps: maxSteps, windowSize: windowSize, recentCalls: make([]CallSignature, 0, windowSize), historyCount: make(map[CallSignature]int), } } // RecordAndCheck 记录当前调用并判定是否需要熔断 func (cb *CircuitBreaker) RecordAndCheck(toolName string, args any) error { cb.mu.Lock() defer cb.mu.Unlock() cb.currentStep if cb.currentStep cb.maxSteps { return fmt.Errorf(%w: limit %d, ErrStepLimitExceeded, cb.maxSteps) } // 计算参数哈希无需完整保留入参大对象 rawBytes, _ : json.Marshal(args) hashBytes : sha256.Sum256(rawBytes) sig : CallSignature{ ToolName: toolName, ArgHash: hex.EncodeToString(hashBytes[:8]), // 截取前 8 字节作为短指纹 } // 1. 严格同参检查如果在滑动窗口内连续 3 次出现相同签名立即熔断 consecutiveCount : 0 for i : len(cb.recentCalls) - 1; i 0; i-- { if cb.recentCalls[i] sig { consecutiveCount } else { break } } if consecutiveCount 2 { // 加上当前这一次就是第 3 次 return fmt.Errorf(%w: identical call %s[%s] repeated %d times, ErrOscillationDetected, sig.ToolName, sig.ArgHash, consecutiveCount1) } // 2. 窗口频次检查维护最近调用的环形队列 if len(cb.recentCalls) cb.windowSize { oldest : cb.recentCalls[0] cb.recentCalls cb.recentCalls[1:] cb.historyCount[oldest]-- if cb.historyCount[oldest] 0 { delete(cb.historyCount, oldest) } } cb.recentCalls append(cb.recentCalls, sig) cb.historyCount[sig] // 窗口内如果某个调用占据了超过 60% 的频次说明陷入了乒乓振荡 if cb.historyCount[sig] (cb.windowSize*3)/5 cb.windowSize 5 { return fmt.Errorf(%w: dominance ratio exceeded for %s, ErrOscillationDetected, sig.ToolName) } return nil }这个熔断器的核心价值在于低延迟与早介入。一旦探测到模型在原地打转它会在第 3 次重复时直接掐断调用链不再将无效请求递交给底层工具层。第二道防线上下文 Token 阈值守门员Token Sentinel即使模型没有进入单纯的死循环工具返回的高维数据如单次read_file返回了 8000 行日志也会迅速挤占上下文。很多开发者习惯让框架在每轮请求前使用粗暴的截断这容易切断 System Prompt 里的关键指令约束或者把上一步刚拿到的一半依赖切丢。守门员Token Sentinel的设计原则是分级水位告警与策略性压实Compaction。水位线区间上下文容量占比守门员动作策略描述安全水位Green0% ~ 65%正常透传保留完整的思维链思考过程与工具原始结果告警水位Yellow65% ~ 80%渐进折叠Fold将历史工具返回的原始响应替换为摘要哈希仅保留成功/失败状态与第一行特征临界水位Orange80% ~ 90%强制语义提取触发一次轻量模型归纳将前置 N 轮对话压实为一个 System 级别的 State Snapshot熔断水位Red 90%硬性截断拒绝终止进一步的行动规划强制模型进入收尾阶段Final Answer总结当前已知事实动态压实状态机的执行流我在设计这套动态压实状态机时每次收到大模型响应或工具返回都会在推入历史前执行严格的水位仲裁[新一轮大模型响应 / 工具输出] | v [计算当前总 Token 水位] | --- 水位 65% (安全) ----- [直接追加至会话历史] ----------- [继续下一步 Tool Call] | --- 65% ~ 80% (告警) ----- [就地折叠历史 Tool Result] ---- | | --- 80% ~ 90% (临界) ----- [触发轻量模型执行状态压缩] ------ [更新上下文缓存] -- [继续执行] | --- 水位 90% (熔断) ---- [注入紧急收尾指令 / 阻断工具调用] - [调度器退出循环并落盘]整个状态仲裁的关键细节包括安全水位65%不做任何破坏性修改上下文完整透传保证多步复杂推理的连贯性。告警水位65%~80%就地遍历历史消息将执行完毕的大体积工具返回如文件树扫描结果、完整日志替换为精简摘要或哈希标记瞬间释放出宝贵空间。临界水位80%~90%唤醒轻量模型执行单轮提炼将前序多轮上下文总结为结构化的状态快照State Snapshot替换中间冗余轮次。熔断水位90%严禁发起任何新的工具调用向模型强制注入收尾指令引导其利用现有信息给出最终结论并优雅退出。在 Go 中实现守门员时我们需要结合 Tokenizer 的快速估算对消息数组进行就地过滤package runtime import ( context fmt ) type Message struct { Role string json:role Content string json:content ToolCallID string json:tool_call_id,omitempty } type TokenSentinel struct { maxAllowedTokens int tokenizer func(text string) int // 快速近似估算函数 } func NewTokenSentinel(maxTokens int, tokenizer func(string) int) *TokenSentinel { return TokenSentinel{ maxAllowedTokens: maxTokens, tokenizer: tokenizer, } } // GuardContext 评估并治理上下文消息流 func (ts *TokenSentinel) GuardContext(ctx context.Context, msgs []Message) ([]Message, error) { totalTokens : 0 for _, m : range msgs { totalTokens ts.tokenizer(m.Content) } ratio : float64(totalTokens) / float64(ts.maxAllowedTokens) // 超过 90% 警戒线强制插入熔断拦截提示 if ratio 0.90 { return nil, fmt.Errorf(token sentinel: context budget exhausted (%d/%d tokens, ratio: %.2f), totalTokens, ts.maxAllowedTokens, ratio) } // 超过 65% 阈值执行非破坏性的历史工具响应折叠 if ratio 0.65 { compacted : make([]Message, len(msgs)) copy(compacted, msgs) // 从最早的消息向后扫描对距离当前超过 4 步的老旧工具响应进行裁切 safeKeepWindow : 4 cutoffIndex : len(compacted) - safeKeepWindow for i : 0; i cutoffIndex; i { if compacted[i].Role tool len(compacted[i].Content) 200 { compacted[i].Content fmt.Sprintf([已折叠历史输出: 原始长度 %d 字符, 状态确认], len(compacted[i].Content)) } } return compacted, nil } return msgs, nil }被熔断后的“优雅降级”给模型一次体面收尾的机会很多 Agent 系统在触发熔断器后直接抛出一个硬生生的500 Internal Error给终端用户这非常破坏交互体验。对于终端用户而言即使 Agent 没有彻底完成全部子任务它在熔断前探索到的上下文、排查出的线索依然极具价值。优雅截断的标准实践分为三步阻断工具分发当熔断器判定异常后不再向下派发真实的 API 请求而是向模型返回一个定制的系统错误消息{status: CIRCUIT_BREAKER_TRIGGERED, reason: Detection of repetitive calls to grep. Do not attempt further tool calls. Summarize your current findings immediately.}剔除 Tools 声明在最后一次请求大模型生成总结时直接从请求参数中剥离所有可用工具定义Tools 数组置空。这一招极为有效彻底剥夺模型继续发起 Tool Call 的物理能力迫使它只能老老实实生成纯文本回复。输出排查报告模型在没有工具可用的约束下会将之前累积的上下文梳理成结构化报告“我已尝试查找 X但在路径 A 和 B 均未命中根据已有线索可能是配置文件尚未初始化。”生产落地的参数调优经验经过多轮复杂工程场景如自动化代码重构、多文件分析的实战压测以下配置参数在召回率与误杀率之间取得了最佳平衡MaxSteps 硬上限建议按任务复杂度分级设置。单一查询类任务设为 812 步综合重构类任务设为 2535 步。超过 40 步的 Agent其有效决策率往往不足 15%。签名哈希滑动窗口Window Size建议设为 6。窗口太小如 3容易误伤合理的重试逻辑如带退避的重试窗口过大如 15则会导致熔断反应过于迟钝。Token 警戒线留白务必为大模型的最终收尾保留至少 2048 个 Token 的净输出空间。如果一直拖到 98% 甚至 100% 才去熔断模型连生成一段“我为何卡死”的告警日志的机会都没有了。给 Agent 自由度是它的能力源泉但给 Agent 设置边界才是它能够安全落地的定海神针。步数熔断器挡住无脑自旋Token 守门员守住上下文健康度这两套基础设施就绪后Agent 才能真正从“实验室玩具”走向“无人值守的生产助手”。