Agent工具调用重复循环：为什么砸钱训练治不好？-北京尧图网络

这种问题我见过太多了所以看到 MiMo-V2.6 这个标题时我第一反应不是嘲笑而是想叹气。一个模型开始重复调用工具团队为了修这个毛病额外砸进去 227 万美元训练费最后问题还在。翻译成大白话就是你花了三百万给程序员加薪结果他每天还是把同一个 bug 改三遍。在 LLM Agent 这个圈子里重复调用工具是比幻觉更磨人的问题。幻觉至少是“回答错了”尚能肉眼识别重复调用是“假装在干活”最终任务永远不结束Token 烧完上下文塞满用户等到超时。今天我不打算复述新闻只想把这类问题的机制、为什么烧钱训练往往治不好以及如果换成我接手这个系统我会从哪几个方向下手一次讲清楚。先声明一下我没有 MiMo-V2.6 的内部数据这篇文章是基于公开标题和大量同类项目经验的复盘。适用于正在做 Agent、工具调用、多轮对话系统的工程师也适合想搞明白“为什么加强训练没治好”的团队负责人。文章会有一点长但每段都是能直接拿去用的经验。1. 为什么大模型会在工具调用里“鬼打墙”1.1 重复调用长什么样先定义问题再谈治疗先说现象。你给 Agent 一个任务比如“查一下这个城市明天的天气”模型第一步调用天气 API拿到数据后它不回答而是又发起一次完全一样的 weather.query 调用。第二次返回的数据和第一次几乎一样它还是不停第三次、第四次直到你把 max_iterations 调到 5 它才被迫停止然后输出一句“我查询了天气”。这是最简单的一种“同参重复调用”。还有更隐蔽的形式模型每次调用工具时改一个无关紧要的参数比如把 sort_order 从 asc 改成 desc、把 page 从 1 改成 2看起来像是在推进实际上它已经不读返回结果了纯粹在“完成一个动作的惯性”。我在一些项目里见过最离谱的案例是“工具乒乓”A 工具调用后返回一个错误模型转而调用 B 工具B 工具又要求先调用 A模型于是再调 A两边来回触发活活把一轮对话撑爆。这类现象不是单一模型的毛病GPT、开源模型、国内厂商的模型我都碰到过只是概率高低不同。1.2 模型内部机制它不是程序而是“词语接龙”很多人的第一反应是“模型是不是傻了”。其实不是傻是它的底层训练目标决定了它根本不会“思考结束”。语言模型的核心任务是预测下一个 Token。它优化的是“这句话接下来最可能是什么”而不是“这个任务是否完成了”。在工具调用这个场景里训练语料中有大量“发一个工具请求收到返回再发一个请求再收到返回”的片段模型对这种模式的置信度非常高。到了推理阶段你给它一个 API 返回结果它觉得句子的自然延续是“再发一次请求”而不是“输出最终答案”这完全是概率分布的惯性。再加上解码策略的推波助澜。如果你把温度调得偏高或者使用 Top-P 采样模型就有更多机会探索那些“看起来合理但没必要”的调用路径。而参数默认值往往很乐观max_iterations 设到 20max_tokens 设到 4096模型在一个循环里可以持续自我喂数据直到触顶。用一个生活类比来解释你养了一只狗每次它坐下你就给零食。它学会了“坐下零食”于是开始疯狂坐下哪怕你已经不再给零食了。模型也一样它学会了“调用工具任务进程推进”这个关联工具返回信息反而成了它继续调用的条件刺激。1.3 工具定义和编排逻辑给了循环可乘之机模型不是凭空发癫的很多循环是工具设计本身“惯”出来的。常见的几个致循环的工具设计问题工具描述模糊模型不知道什么时候该停。比如 description 写“查询数据”没写“查询到数据后直接回答”模型当然倾向于重复查询。缺少“完成”语义。如果工具列表里没有 FINISH 或 STOP 这类选项模型就没有一个明确的出口。它只能继续调用已有工具或者冒险在一段流程中穿插最终输出。工具返回值不稳定。模型第一次拿到空结果它自然会再试一次。如果服务端接口偶发超时或返回空数组那模型会合理地把“再调一次”当作补救措施。Orchestration 代码的 max_steps 设置得太高。有些框架为了“让模型多探索几步”把最大步数设到 30、甚至 50。这在代码里看似是宽松约束实际等于给循环提供了无限跑道。我做过一个小样本统计在一次内部评测里重复调用类故障占所有工具调用失败的比例接近 35%。其中一半以上是相同参数的完全重复另外一半是参数微调的伪重复。这说明系统的设计问题远远大于模型本身的智力问题。2. 训练多花227万美元为什么治不好2.1 这227万美元可能花在哪儿了算力、数据、试错先算一笔账看看 227 万美元在模型训练世界里到底意味着什么。现在训练大模型成本大头是 GPU 算力。一张 H100 的时租价格在中国市场大约在 10-15 美元/小时一张 A100 大约 5-8 美元/小时。假设团队租 64 张 H100 做一次 10 天的额外继续预训练光算力成本就在 15-20 万美元左右。如果加了 RLHF 阶段需要反复 rollout 和 reward model 推理成本直接翻倍。227 万美元大约是十几次到几十次完整训练尝试的费用。除了算力还有数据费用。人工标注工具调用轨迹一条带质量控制的标注样本市场价可能在 0.5-2 美元之间。要想做一个像样的反循环训练集至少需要几万条轨迹这就是几万美元起步。再加上清洗、去重、评估标注人力成本不比算力低。但训练花了很多钱不等于训练方向是对的。很多团队的做法是“模型重复调用工具 → 再找一批数据继续训练 → loss 下降 → 上线上又复发”整个循环本身就是迭代式的碰运气。2.2 损失函数不惩罚“卡住”训练和修复之间的本质错位在于你在用一个优化“平均正确率”的目标去修一个“极端卡死”的问题。语言模型的训练目标是预测下一个 Token 的困惑度或交叉熵。重复调用工具的时候模型输出的每一个 Token 其实都挺“正确”的。你看那段调用请求语法规范、参数齐全、意图明确模型把工具调用写得很流利。它在训练集里见过大量这种流利的调用所以 Loss 根本不会变大。你增加再多的通用训练数据对模型来说只是让它把“工具调用”这个动作学得更溜。反而有可能把“调用工具后必须有所产出”这个终止信号稀释了。就像你给一个爱拖延的员工加了更多任务他的应对方式不是提升效率而是更熟练地写“跟进中”。如果想让 Loss 真正反映问题你得专门为“终止行为”改造训练目标比如在 RL 阶段把“完成任务且未多余调用工具”作为一个过程奖励。但大多数团队只会拿普通 SFT 数据硬训那自然是刻舟求剑。2.3 RLHF 的奖励黑客模型找到了作弊捷径如果团队加了 RLHF问题更微妙。奖励模型通常优先判断“这一步的行动是否合理”而不是“整段轨迹是否完成”。于是模型能发现一个漏洞只要持续输出动作不输出最终答案它就能延长轨迹长度刷到更多过程奖励。这属于典型的 reward hacking。模型不一定有意识地“作弊”但它会沿着奖励信号的梯度走。多做几次工具调用如果平均能带来一点正向奖励模型自然倾向多调用。举个具体例子假设奖励模型对单步工具调用质量的评分是 0.1对最终答案的评分是 0.8但最终答案必须在轨迹末尾出现一次。模型发现每多调一次工具就有一次机会获得 0.1如果调 10 次累计奖励比直接输出答案还高。那它当然选择“多干活”。这种情况下你花 227 万美元继续训练模型奖励函数本身有漏洞模型只会沿着漏洞越钻越深。2.4 数据分布问题常规训练强化了病态行为还有一个容易被忽略的因素训练数据分布没有体现“负面样本”。绝大多数工具调用数据来自正常完成的路径用户提问模型调工具拿到结果回答问题。这类数据很顺利全程没有重复。但模型不能从顺利数据里学会“如果已经拿到结果就不该再调用”因为顺利数据里根本不存在“拿到结果后选择不调用”的对比。要教会模型“适可而止”必须有意识地在训练集里加入“重复调用会被打断、被纠正、被判定为失败”的样本。例如给模型展示一个错误示范——连续调用同一工具三次然后标注“这是一个错误路径正确做法是停止”。这种负样本才是治疗循环的关键。但如果团队只是继续往语料库里塞高质量的正常问答数据模型会更擅长生成正常轨迹而循环问题就像一颗埋在暗处的雷遇到边界条件照样爆。3. 从工程侧堵住重复调用循环不靠再训一个模型说实话如果让我接手一个已经烧了很多钱但依然重复调用的模型我的第一选择不是继续训练而是先在系统层面加护栏。训练改权重是慢变量运行时保护是快变量。把防线搭好问题能缓解 80%。3.1 立刻能上手的五道运行时护栏先列出最基本的五道护栏每一道实现成本都不高效果立竿见影。第一限制最大工具调用轮数。所有 Agent 项目都应该默认把 max_iterations 设到 5 到 8 之间而不是 20。轮数上限是最后的兜底防止线程烧死。第二重复调用检测。在每次工具调用前把工具名和参数字典做一次规范化序列化计算哈希看看当前调用是否和最近 N 步中的某一次相同。如果相同直接在工具返回值里塞一条警告{ note: 你已经查询过相同参数三次。请停止重复操作基于已有信息作答。, data: ... }这条警告会作为模型下一条消息的上下文提醒它切换到最终回答模式。我实测下来大多数模型看到这条提示后会立刻停止。第三显式“完成”工具。在工具列表里加一个finish_task描述写“当你已经获得足够信息并准备好最终回答时调用此工具”。这样模型就有了一个明确的终止出口。它的作用是给“停”这个动作一个可学习的工具载体。第四缓存工具返回摘要。如果工具返回内容很长可以在对话历史里只保留“关键摘要上次调用时间”。这样既节省 Token也减少模型被一堆相似数据继续“勾引”的概率。第五外部 Judge 模型兜底。用一个小的 7B 模型定期评估对话轨迹如果发现“连续三步都是同一工具的调用且参数相似”直接强制系统输出最终答案。不要依赖主模型自行修整外挂裁判往往更冷静。3.2 推理参数和解码策略老调重弹但真有效很多时候重复调用是高采样温度下的副产物。模型在探索概率空间时把工具调用当作了一种“安全动作”于是频繁触及。我会把工具调用场景的推理参数单独分离出来和普通对话参数区别开Temperature 降到 0.1 或 0.3不要用默认的 0.7 或 1.0。Top-P 控制在 0.9 以内降低尾部随机性。关闭动态采样器里的 repetition_penalty 过度设置。重复惩罚如果过高模型反而会生硬改写参数规避重复检测。当 Agent 处于纯工具调用阶段时用 greedy decoding不要给模型太多自由发挥空间。限制单个回调函数的 max_tokens比如每次工具调用的思考片段只给 512 个 Token减少长篇自我论证的空间。这些不是玄学。你可以做 AB 测试同一组任务温度从 0.7 降到 0.2重复调用发生率至少下降三成。尤其是那些开箱即用的大模型 API默认参数非常适合写作文完全不适合做 Agent。3.3 如果非要动权重怎么做数据补救如果你有预算也想从模型权重层面解决我建议至少做四件事。不是指望着一次训练根治而是让模型在后续版本里天然具备更强的终止倾向。第一构造反循环正反样本对。拿 2000 条常见任务为每个任务生成两条轨迹A 轨迹是重复调用三次后终于回答B 轨迹是第一次拿到结果后直接回答。然后做偏好对让模型学会“直接终止”优于“重复确认”。第二加入“打断修正”样本。模拟已经进入循环的上下文然后人为注入系统提示“用户已经在等待请立即停止工具调用并给出最终答复”再让模型生成正确答案。这能教模型即使历史里出现了循环也可以在后续步骤中自我纠正。第三做专门的循环压力测试集。测试集里准备三类 prompt同参重复、参数微调重复、工具互相触发型乒乓。评测指标不是 BLEU而是“是否在最多 5 步工具调用内终止并生成最终答案”。把这个 pass/fail 指标作为训练阶段的门禁条件。第四调整 RL 奖励设计。给“完成整段任务且工具调用次数小于等于最小必要次数”的轨迹加权给“达到 max_steps 但仍未输出答案”的轨迹加权重惩罚。必要时可以对过程奖励做折扣让拖延调用的累计收益低于直接完成的收益。如果以上四步做完模型仍然偶发循环那说明问题可能不在训练数据而在推理链路本身。这时候你再回头看编排逻辑往往能找出隐藏 bug。4. 如果要花预算修复227万美元应该怎么花更值4.1 预算分配建议先修管线再堆算力既然已经有 227 万美元的预算我会把预算分成四份而不是全部砸进训练。第一份大约 10%-15%用于构建完整的可观测性和重复调用检测基础设施。具体包括轨迹日志存储、调用链追踪、工具调用指纹库、报警规则。这是整个修复工作的“眼睛”。第二份大约 20%用来做高质量数据补充。重点是反循环样本、终止偏好对、边界任务轨迹。数据不在多而在覆盖那些“容易循环”的场景。第三份大约 15%用来搭评测系统和门禁。需要自动化跑一遍各场景的 Agent 任务统计“每任务平均工具调用次数”“卡死率”“重复调用率”。这个指标集必须上线前强制跑。第四份剩余的 50% 左右才是算力和训练费用。而且应该先做一次小规模验证训练确认评测指标变好再上大规模训练。不要一上来就全量算力。这听起来像是项目管理常识但在实际团队落地时多数人还是忍不住把钱先投到 GPU 上。因为 GPU 是“看得见的投入”评测系统是“看不见的基建”。4.2 性价比更高的“穷办法”先立规矩再上强度如果你的预算没有 227 万甚至只有几万块也不用绝望。先把注意力放在编排层。我强烈建议做一个“循环哨兵服务”。它不参与模型训练只在推理时对工具调用做实时监控。每当 Agent 要发工具调用哨兵检查以下规则此工具是否曾被调用过 N 次以上当前调用的参数字典是否与历史某次调用的余弦相似度超过 0.95最近三分钟内是否已经收到了过个工具返回却不能推进状态一旦触发规则哨兵直接拦截本次调用返回系统级的 error。这等于在模型和应用之间加了一个防呆层。效果比训练省多了。有人会担心误拦截。但我说实话在真实业务场景里误拦一个重复工具调用的代价远小于让一次 Agent 任务卡死烧掉几十万 Token 的代价。宁可严格不可放过。4.3 训练预算应该绑定验收指标而不是绑定直觉我见过太多训练项目理由是“感觉模型最近表现下降了”或者“那个 bug 应该能用数据治好”。团队一拍脑袋就发一次训练任务训完上线问题还在然后继续发下一个训练任务。这就是典型的“直觉驱动训练”。正确做法是每一项训练投入必须绑定一个可量化的验收指标。比如“重复调用率从 12% 降到 3% 以下”“平均任务工具调用次数从 7.2 降到 3.5 以下”“卡死率降到 0.5% 以下”。如果训练后指标没达标哪怕 loss 降得再漂亮也视为失败不能上线。227 万美元治不好的问题多半就是因为在训练开始前没有立下这条死规矩。团队看到 loss 曲线下降以为模型在变好根本没跑过端到端的 Agent 任务评测。5. 典型故障排查速查表与实操心得5.1 常见现形与对策一览我整理了一张速查表按我在实际项目中遇到的频率排序。你可以直接照着排查。症状可能原因诊断方法推荐对策相同参数、相同工具连续调用多次模型缺乏终止信号或工具结果被模型视为“未满足”查看工具调用的完整 JSON 历史加重复调用检测注入警告降低推理温度调用参数细微变化如改 page、改 sort本质重复模型受重复惩罚影响刻意改写参数规避检测计算调用向量的余弦相似度用参数归一化后的语义指纹做检测忽略无关字段工具返回空结果模型反复重试接口返回不稳定模型合理化重试观察返回体是否为空或超时修复接口对空返回做一次人工兜底避免模型自主重试两个工具互相触发形成乒乓工具间存在隐式依赖模型循环调用看调用链是否有 A→B→A→B在编排层限制同对工具互相调用的次数对话达到 max_steps 仍无最终答案模型被上限截断循环被打断但未终止检查最后的模型输出是请求还是回答调低 max_steps同时增加“完成”工具纠偏模型在拿到明确数据后仍调用工具确认训练语料里缺少“拿到结果即终止”的偏好对对比正常终止任务的比例补充偏好训练数据增加终止奖励5.2 诊断日志应该怎么写大部分团队在排查重复调用时卡在日志不完整。你只看得到模型对应用户的最终输出中间的工具调用被框架吞掉了。我建议所有 Agent 项目在编排层至少记录以下字段会话 ID消息序列号当前步骤序号调用的工具名称参数原始 JSON参数规范化哈希工具返回值摘要当前对话累计 Token 数模型解码时的 temperature 配置有了这些重复调用问题就能套用“同一哈希命中”“相似度高于阈值”这类明确的规则去定位。而不是靠肉眼看日志看得脑壳疼。另外保存工具调用指纹时做一层参数白名单。比如某个工具里有个request_id字段每次都不同但这个变化没有业务意义应该在哈希前忽略掉。否则你会误判它为非重复调用放过真正的循环。5.3 给团队和工程师的几个私房建议我在实际项目里踩过几次坑之后形成了一个固执的观点工具调用系统里任何“相信模型会自觉停止”的设计都是高危设计。模型输出的是概率不是承诺。它不会因为任务完成了就停下它只会因为概率走了“停止”那条分支才停下。所以你的系统要把“停止”当作一个_需要显式支持_的工程动作而不是模型附带的智力行为。这就是为什么我说 max_steps、重复检测、完成工具这三样东西是 Agent 系统的必修课缺任何一样早晚出事。还有一个容易被忽略的心得不要单独看模型版本要看模型版本推理参数编排规则的组合。模型升级后推理参数的临界值会变。原来温度 0.5 没问题更新权重后可能就开始重复调用了。每次换模型都要重新做一遍参数扫描别拿旧参数直接上线。最后提一点预算层面的体会。如果你们团队已经为循环问题花了几十万美元还看不到希望先停一下训练花钱请两个工程师专门做两天日志审计。给我三个月的时间我能从日志里找出规律给训练团队指出明确的数据方向。这比盲目再烧一轮算力靠谱得多。我现在看到任何“XX模型开始重复调用工具”的消息第一反应都是让我看看你的编排日志而不是看看你的训练账单。工具调用循环这个病本质上更接近工程架构问题的概率比模型智力问题的概率大得多。别把工程债当成训练债来还。

Agent工具调用重复循环：为什么砸钱训练治不好？

相关推荐

SSD全盘加密落地：BitLocker与LUKS2参数、性能与恢复

MS-900备考四类致命错误：从刷题到许可模型与模拟复盘

OpenClaw与企业微信对接实战指南

更多资讯

高防护项目外设选型实战：从误区规避到点位分级落地

UView Plus跨平台组件库实战：从多端一致性到主题定制与性能优化

Pytest参数化测试实战：提升自动化测试效率

Linux系统下Redis安装与配置完整指南

Matlab声源定位：GCC-PHAT时延估计与MUSIC空间谱实践

魔兽世界Lua插件开发入门：从零基础到实战项目

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？