154、LangChain Agent：ReAct、Plan-Execute 模式与 Tool 的注册发现机制

154、LangChain Agent：ReAct、Plan-Execute 模式与 Tool 的注册发现机制从一次诡异的Agent死循环说起上周帮同事排查一个LangChain Agent的线上问题，场景很简单：一个客服机器人，需要根据用户问题查询订单状态、退换货政策、物流信息。Agent配置了三个Tool，按理说应该能自动选择调用。结果日志里看到Agent在“查询订单状态”和“退换货政策”之间来回跳了七八次，最后超时报错。更诡异的是，它明明已经拿到了订单状态，却还要再去查一遍政策，然后说“我需要更多信息”。我盯着日志看了半小时，发现Agent的Thought过程里写的是：“用户可能想知道退换货政策，但订单状态显示已签收，我需要确认政策是否允许退货。”——这逻辑看起来没问题啊？但问题是，它没有把“已签收”这个事实作为Observation传给下一步，而是重新去调用了订单查询Tool。这就是典型的ReAct模式下的“上下文丢失”问题。很多初学者以为Agent会自动记住所有中间结果，实际上每个Action-Observation循环都是独立的，你需要显式地把关键信息塞回给LLM的输入。这个坑我踩了不下三次，后面会详细说怎么处理。ReAct模式：不是简单的“思考-行动”循环ReAct（Reasoning + Acting）是LangChain Agent最基础的执行模式。它的核心思想是让LLM在每一步都输出一个结