复现一个小循环
Agent 调用 `search_ticket` 得到匹配工单，然后再次调用同一工具，连续十次。监控面板只显示接口成功，很容易误以为模型“不会停止”。打开完整轨迹会发现：工具返回的是 `status: ok` 和一段空的 `items`，模型没拿到需要的信息，于是不断尝试。
先查接口契约
工具名与描述是否说清用途？参数字段是否有枚举与示例？返回值是否区分“请求成功但无结果”“暂时故障”“无权限”？如果这三种情况都装进一个自由文本字段，模型很难稳定选择下一步。让工具返回结构化状态、可读原因与下一动作建议，可以减少无意义循环。
再查状态变化
写入类工具应返回对象 ID 和最终状态。若任务要求“创建后核实”，Agent 还应通过读取工具确认，不要因为写入接口返回 200 就宣布完成。对可能重复执行的动作加幂等键；若结果不确定，应先查状态再重试。否则 Agent 的连续尝试可能制造重复记录。
提示词不是万能修补
提示词可以明确成功条件、禁止无上限重试、要求缺少信息时向用户解释。但如果接口返回本身含糊，再长的规则也只是让模型猜得更复杂。排查顺序是：输入参数与工具描述、返回结构、状态保存、循环上限，最后才比较不同提示词写法。
建立一个故障回归集，包括空结果、超时、权限拒绝、部分成功和格式变化。每个样本定义正确行为：重试、换工具、询问用户或停止。真正可靠的 Agent 必须会停下来说明原因，而不只是能在理想页面上一口气走完流程。
给循环设一道保险
每个工具可定义最大连续调用次数和总任务预算。达到上限时，Agent 应总结已知事实、失败原因和用户可以补充的信息，而不是悄悄停止或编造完成。对外部写入类工具，还要区分请求超时与操作失败：超时后服务端可能已经完成动作，盲目再试会产生重复记录。
调试界面最好把“模型为什么选择工具”的简短说明、实际参数和返回状态放在同一条时间线上。开发者看到 `items: []`、权限拒绝或字段不匹配后，才能选择改接口、改路由还是改提示词。把所有问题都归因于模型随机性，会让真正的工程缺陷长期存在。
若使用 MCP 接入多个工具，仍要逐个明确每个工具的权限、参数与返回语义。协议可以统一连接方式，却不会自动消除含糊的接口设计。一个简单、稳定的工具集，通常比一长串描述相似的工具更容易让 Agent 正确选择。