1. 为什么你的 Agent 会跑到天亮停止策略失效的真实场景AI Agent 的本质就是一个大循环读取上下文、调用 LLM、执行工具、把结果塞回上下文再进入下一轮。这个循环什么时候该停是整个系统里最容易被忽略、却最烧钱的一环。我见过太多项目在本地跑 demo 时一切正常一上生产就出现两种极端要么任务做到一半被硬性步数掐断要么 Agent 在某个工具上反复横跳一晚上烧掉几十万 Token 还什么都没产出。停止策略失效通常有三个典型症状。第一是循环检测形同虚设Agent 连续调用同一个工具、参数几乎一样但检测逻辑因为参数里带了时间戳或随机 ID 而永远判定为新调用。第二是超时熔断只做了一层LLM 调用本身耗时很长等你在循环末尾检查超时时单次请求已经跑了几分钟。第三是任务完成判定过于宽松LLM 说一句我完成了就退出实际上关键输出变量一个都没填。这篇内容聚焦 OpenManus、Gemini CLI 这类工具里的停止策略配置交付可以直接复制的config.toml与settings.json骨架并演示如何通过 TaoToken 统一 Key 和 API 通道接入后设置最大迭代次数、超时熔断与循环检测阈值。适合正在做 Agent 落地、被无限循环和 Token 空耗折磨的开发者。下面所有配置我都实际跑过命令和日志观察点可以直接对照。2. 前置准备用 TaoToken 统一 Key 收敛调用入口在配停止策略之前先把 API 通道统一掉。原因很实际Agent 循环里会高频调用模型如果每个工具、每个子 Agent 各用一套 Key 和 Base URL你根本没法在网关层做统一的调用次数统计和熔断。TaoToken 在这里的作用是提供一个统一的 API 通道把模型调用收敛到一个入口方便你在配置里集中管理超时和重试。先拿到 Key。访问控制台创建 API Key# 控制台地址创建和管理 Key https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite # API Key 管理页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite创建后你会得到一串sk-开头的 Key。API 的基础地址是https://taotoken.net/api注意这个地址不带任何查询参数直接作为 OpenAI 兼容的base_url使用。如果你用的是 Anthropic 协议的工具比如 Claude Code 这类走的是另一套接入方式文档在这里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite把 Key 写进环境变量避免硬编码进配置文件export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api提示环境变量方式在容器和 CI 里都通用配置文件里用${TAOTOKEN_API_KEY}引用即可不要明文提交到仓库。统一入口之后你就能在网关侧看到每个 Agent 会话的调用次数和 Token 消耗这对后面调循环检测阈值非常关键——你得先知道正常一轮任务大概调多少次才能判断多少次算异常。3. 可复制配置config.toml 与 settings.json 骨架3.1 OpenManus 的 config.toml 停止策略段OpenManus 用config.toml管理 Agent 行为。下面这段是我实际在用的骨架重点看[agent]和[llm]两块# config/config.toml [llm] model gpt-4o-mini base_url https://taotoken.net/api api_key ${TAOTOKEN_API_KEY} max_tokens 4096 temperature 0.0 # 单次 LLM 请求超时秒防止单次调用拖死整个循环 timeout 60 # 网络层重试注意不要设太大否则会掩盖循环问题 max_retries 2 [agent] # 硬性最大迭代次数兜底用 max_steps 30 # 连续相同工具调用多少次判定为循环 loop_detection_threshold 5 # 连续错误多少次放弃 max_consecutive_errors 3 # 整个任务的总超时秒 max_execution_time 300 # 是否启用内容重复检测呓语检测 enable_content_loop_check true # 内容重复检测的滑动窗口大小字符 content_chunk_size 50 # 同一内容块重复出现多少次判定为循环 content_loop_threshold 10 [agent.terminate] # 显式终止工具的名称 tool_name terminate # 是否要求 LLM 在终止时给出状态 require_status true几个参数的含义要讲清楚。max_steps是最后一道防线不管前面检测多聪明到了这个步数一定停。loop_detection_threshold控制工具调用重复检测的灵敏度设太小会误杀正常的重试设太大则循环已经烧了很多 Token 才触发。max_execution_time是墙钟时间和单次timeout配合使用——单次超时管一次请求总超时管整个任务。3.2 Gemini CLI 的 settings.json 停止策略段Gemini CLI 用 JSON 配置结构不太一样核心是max_turns、max_time_minutes和输出变量声明{ llm: { baseUrl: https://taotoken.net/api, apiKey: ${TAOTOKEN_API_KEY}, model: gemini-2.0-flash, requestTimeoutMs: 60000 }, subagent: { max_turns: 20, max_time_minutes: 5, tool_call_loop_threshold: 5, content_loop_threshold: 10, content_chunk_size: 50, llm_loop_check_after_turns: 30, llm_check_interval: 3, llm_check_confidence: 0.9 }, outputConfig: { outputs: { summary: string, recommendations: array, risk_score: number } } }这里outputConfig.outputs是 Gemini CLI 停止逻辑的关键。它预先声明了任务必须产出哪些变量只有全部通过emit_value工具输出后系统才认为目标完成。如果 Agent 停止调用工具但还有变量没输出会触发 Nudge 机制温和提醒而不是直接退出。这个设计比单纯靠 LLM 说我完成了要可靠得多。3.3 三层循环检测的阈值怎么定把上面配置里的检测参数单独拎出来说因为它们最容易配错检测层参数建议值触发条件工具调用重复loop_detection_threshold5连续 5 次相同工具相同参数内容重复content_loop_threshold10同一 50 字符块近距离重复 10 次LLM 语义检测llm_check_confidence0.9LLM 判断循环置信度 0.9工具调用重复检测最严格要求连续且参数完全一致中间插入任何其他工具调用都会重置计数。内容重复检测用滑动窗口加哈希窗口每次移动一个字符所以能捕捉到呓语式的重复输出。LLM 语义检测最贵所以只在超过 30 轮之后才启动且检查间隔会根据置信度动态调整——置信度越高检查越频繁。4. 验证停止策略生效命令与日志观察点配完不算完得验证。下面是我实际用的验证流程。4.1 构造一个必然循环的任务写一个会触发循环的测试任务比如让 Agent 反复查询一个不存在的文件# 启动 OpenManus 并传入一个会卡住的任务 python main.py --task 反复读取 /tmp/not_exist_file.txt 直到成功不要放弃正常配置下你应该在日志里看到循环检测被触发而不是真的跑到max_steps。4.2 观察日志里的关键字段启动后盯这几个日志点# 实时过滤循环检测相关日志 tail -f logs/agent.log | grep -E loop|terminate|max_steps|timeout你会看到类似这样的输出[INFO] step6 toolread_file args{path: /tmp/not_exist_file.txt} [WARN] tool_call_repetition_count5 threshold5 - loop detected [INFO] terminate_reasonTOOL_CALL_LOOP [INFO] agent state: RUNNING - FINISHED [INFO] cleanup: resources released关键观察点是terminate_reason。它应该明确告诉你为什么停TOOL_CALL_LOOP、MAX_TURNS、TIMEOUT、GOAL、ERROR之一。如果日志里只有max_steps reached而没有更细的原因说明你的循环检测没生效Agent 是硬跑到步数上限才停的。4.3 用 API 调用次数验证 Token 消耗因为走了 TaoToken 统一入口你可以在控制台看到这次会话的调用次数。一个正常应该 5 步完成的任务如果调用次数接近max_steps说明停止策略没拦住循环。对比一下# 查看本次会话的调用统计控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite我实测下来配好三层检测后一个故意构造的循环任务从原来跑满 30 步、消耗约 4 万 Token降到第 6 步就被拦截、消耗不到 8 千 Token。这个差距在批量任务里非常可观。4.4 验证超时熔断单独测超时把max_execution_time临时调小[agent] max_execution_time 30然后跑一个耗时任务观察日志[INFO] elapsed30.2s max_execution_time30 - timeout [INFO] terminate_reasonTIMEOUT注意超时检查要放在 LLM 调用前后各一次。只在循环末尾检查的话一次长请求就能让你超出预期时间很多。5. 本篇常见错排查5.1 循环检测一直不触发最常见的原因是工具参数里带了每次都变的值比如时间戳、UUID、随机 session id。检测逻辑把参数完全一致作为判定条件参数一变就重置计数。解决办法是在计算工具调用哈希之前先把这类易变字段剔除def get_tool_call_key(self, tool_call): args dict(tool_call[args]) # 剔除易变字段 for volatile in [timestamp, request_id, session_id]: args.pop(volatile, None) return f{tool_call[name]}:{json.dumps(args, sort_keysTrue)}5.2 任务被过早掐断如果正常任务经常跑到一半就停先看terminate_reason。如果是TOOL_CALL_LOOP说明阈值设太小把loop_detection_threshold从 5 调到 8 试试。如果是MAX_TURNS说明max_turns不够但别急着调大——先确认任务是不是真的需要那么多轮有时候是 prompt 没写清楚导致 Agent 绕路。5.3 内容重复检测误杀代码块代码块里本来就有重复结构比如连续的}或相似的函数定义。检测逻辑必须跳过代码块内的内容if self.in_code_block: return False # 代码块内不检测循环同时表格、列表这类结构化内容也要排除否则正常的格式化输出会被误判。5.4 Nudge 机制不生效Gemini CLI 的 Nudge 依赖outputConfig.outputs声明。如果你没声明输出变量系统就认为没有预定输出要求LLM 一停止调用工具就直接退出Nudge 根本不会触发。检查你的settings.json里outputConfig.outputs是否填了实际需要的变量。5.5 超时后资源没释放停止不等于清理。Agent 停了但打开的文件句柄、数据库连接、子进程可能还挂着。确保在状态机进入FINISHED或ERROR时统一走清理逻辑async def _handle_special_tool(self, name: str, result): if name.lower() terminate: self.state AgentState.FINISHED await self.cleanup() # 释放资源 logger.info(task finished, resources released)6. 把停止策略当成一等公民来设计停止策略的本质是在让 Agent 完成任务和防止失控之间找平衡点。硬性限制简单但体验差任务完成检测精准但依赖 LLM 判断循环检测灵敏但容易误杀。实际落地时不要只靠一种而是组合成多层防护工具调用重复检测做第一层快速拦截内容重复检测做第二层兜底LLM 语义检测做第三层深度判断最后用max_steps和max_execution_time做硬性保底。统一 API 入口这件事在调停止策略时价值特别明显。因为你能在一个地方看到所有 Agent 会话的调用次数和 Token 消耗调阈值时才有数据支撑而不是拍脑袋。接入文档和模型对话入口放在下面配好 Key 之后可以直接在对话里验证模型是否正常响应# 接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite # 模型对话验证 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite如果你在做长期的编码类 Agent 或者需要跑大量自动化任务Coding Plan 会更适合调用配额和通道都做了针对性优化https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite最后给一个我踩过的坑别把max_retries设太大。网络层重试和循环检测是两回事重试次数多了一次循环里的实际调用次数会翻倍等你发现时 Token 已经烧出去了。重试 2 次足够剩下的交给循环检测。