前面两篇我们讲了两个问题•ReAct 是什么•ReAct 和 Workflow 怎么选。简单说ReAct 适合处理那种不确定的探索任务。比如查一个接口为什么 500。比如分析一次退款为什么失败。它不是提前写死步骤而是先判断 - 调工具 - 看结果 - 再判断这个模式听起来挺自然。但它也会带来一个很现实的问题如果 Agent 一直判断、一直调用工具、一直看结果会不会停不下来会。而且真实项目里这个问题一点都不玄。它更像后端系统里常见的死循环、重试风暴、状态机卡住。所以这篇只讲一个问题ReAct Agent 怎么避免一直循环先给一个粗糙但好记的版本探索可以但必须有边界。这句话先记住。图ReAct 可以循环探索但外层必须有最大步数、超时、重复检测和危险动作确认这些边界。01Agent 为什么会一直循环先看一个简单例子。用户问我昨天退款失败了你帮我看看为什么。Agent 可能先查订单。订单没问题。于是查退款流水。退款流水里只写了FAILED没有详细错误码。这时候 Agent 可能继续想信息还不够我再查支付渠道。查支付渠道以后结果也很模糊状态异常请稍后重试。于是它又想信息还是不够我再查订单。如果系统没有限制它可能就开始转圈查订单 - 查退款流水 - 查支付渠道 - 再查订单 - 再查退款流水 - 再查支付渠道从模型视角看它不是故意捣乱。它只是一直觉得我还缺一点信息。但从后端视角看这已经是问题了。因为每一次工具调用都有成本。每一次接口请求都有延迟。如果工具还会写数据那风险就更大。所以做 ReAct Agent第一个意识是不能只设计“怎么继续”还要设计“怎么停”。02第一条边界最多走几步最直接的办法就是限制最大步数。比如最多调用 5 次工具 最多执行 8 个 ReAct 步骤 最多运行 30 秒这听起来很粗暴。但非常有用。就像后端接口要有超时。任务队列要有最大重试次数。Agent 也一样。不能让它无限跑。比如分析退款失败原因可以先定一个边界最多查 5 步 1. 查订单 2. 查退款流水 3. 查支付渠道 4. 查错误码说明 5. 查最近一次操作日志如果 5 步之后还没有结论就不要继续硬查了。这时候更合理的回答是我查到了订单和退款流水但目前错误信息不够明确建议转人工或补充退款流水里的详细错误码。这比继续转圈靠谱得多。很多时候Agent 停下来不是失败。它是在承认当前信息不够我不能继续编。03第二条边界不要重复查同一件事只限制步数还不够。因为 Agent 可能 5 步里有 4 步都在查同一个东西。比如get_order(A001) get_order(A001) get_order(A001) get_order(A001)这种就很浪费。所以系统最好记录工具调用历史。至少要知道•调了哪个工具•参数是什么•返回结果是什么•这次调用有没有提供新信息。如果同一个工具、同一组参数、返回也差不多那就没必要重复查。比如get_order(order_id A001)已经返回订单状态 paid未退款未开票那下一步就不应该还是查同一个订单。除非有明确理由。比如用户刚刚修改了订单信息或者订单系统提示状态可能延迟。否则就应该换方向。可以简单记成重复调用同一个工具必须有新的理由。没有理由就停下来或者换工具。04第三条边界工具结果要说清楚很多循环不是模型自己绕晕了。而是工具返回太模糊。比如工具只返回{ status: failed }这个结果对 Agent 来说很难判断下一步。它不知道失败原因是什么。也不知道要不要重试。更不知道该问用户还是该查别的工具。这时候它就容易继续乱查。更好的工具返回应该更结构化一点{ ok: false, error_code: REFUND_CHANNEL_TIMEOUT, message: 支付渠道退款接口超时, retryable: true, next_hint: check_refund_channel_status }这样 Agent 至少知道几件事•这次调用失败了•失败原因是渠道超时•这个失败可能可以重试•下一步可以查渠道状态。工具返回越清楚Agent 越不容易乱转。所以 ReAct Agent 的稳定性不只是提示词问题。工具设计也很关键。工具别只告诉它失败了。最好告诉它为什么失败、能不能重试、下一步建议看哪里。05第四条边界不确定时问用户有些信息不是工具能查到的。比如用户说帮我看看部署为什么失败。Agent 查日志以后发现缺少环境变量 DATABASE_URL这时候它不应该继续乱查一堆系统。它应该问用户这个服务的 DATABASE_URL 是不是还没有配置或者直接给出下一步需要先补充 DATABASE_URL再重新部署。很多 Agent 循环本质上是因为它不愿意承认这个问题需要用户补信息。但真实项目里问用户不是丢人。这是正常的交互。尤其是下面这些情况•用户给的信息不完整•工具查不到关键字段•多个原因都可能成立•继续查会浪费很多成本•下一步动作有风险。这时候就应该停下来问。不要为了显得自动化硬撑着继续查。自动化不是把所有事情都做完。自动化也包括在合适的时候停下来。06第五条边界危险动作前必须停还有一类情况更重要。那就是危险动作。比如•发起退款•删除数据•修改权限•扣库存•发送邮件•创建正式工单•触发付款。这些动作不能让 ReAct 一路自动做下去。查问题可以交给 ReAct。但真正执行危险动作前最好回到 Workflow。比如退款场景里ReAct 分析失败原因 - 判断可以重新发起退款 - 回到 Workflow - 展示影响 - 用户确认 - 后端校验权限和幂等 - 执行退款这就是上一篇讲的组合。外层 Workflow 控制边界。内层 ReAct 做探索。不要让 Agent 因为“它觉得可以”就直接执行不可逆动作。这不是智能。这是把事故入口打开了。07我现在怎么记我现在会把 ReAct Agent 想成一个实习生在排查问题。你可以让他自己查日志、查监控、查订单、查错误码。但你不会让他无限查下去。你会给他边界最多查几步。 不要重复查同一个东西。 查不到就说查不到。 信息不够就问人。 危险动作前必须确认。这套边界放到 Agent 里也一样。所以 ReAct 不是让模型完全自由发挥。ReAct 更像是在受控边界里让模型做有限探索。这句话很重要。没有边界ReAct 很容易变成乱转。有了边界ReAct 才像一个能用的工程能力。写在最后ReAct Agent 会循环并不奇怪。因为它本来就是靠循环推进任务的。真正要解决的不是“不要循环”。而是什么时候继续循环什么时候必须停下来。从后端视角看至少要有几类边界•最大步数•最大耗时•重复工具调用检测•结构化工具结果•失败次数限制•用户补充信息•危险动作确认。这些东西听起来不如“智能体”三个字酷。但它们决定了 Agent 能不能真的上线。其实这里还有几个问题值得思考•多步工具调用的日志应该怎么存•Agent 的工具描述到底要写多细•怎么判断一次 Observation 有没有提供新信息•ReAct 失败后要不要自动重试•危险动作前的人类确认应该怎么设计学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】