用LangGraph搭Agent，多工具调用时上下文老串，大家怎么解决的？

我之前也踩过这个坑，后来发现是状态管理的问题，LangGraph里不同节点的上下文得显式做隔离，不能光靠memory里那点东西。建议把每个工具的输入输出单独存到独立的state字段里，用的时候再拼装，别让它自己自由发挥。

另外你那个“顺便看下天气”其实隐含了多意图，最好在路由前加一步意图拆解，把“订会议室”和“查天气”拆成两个独立子任务，再分别走各自的工具链。不然靠模型自己判断，它确实容易把实体搞混。

我试过在工具调用前加一个校验节点，检查参数是否匹配当前工具的定义，不匹配就强制重试一次，串上下文的情况少了很多。你可以试试看，虽然不能100%解决，但至少能拦住大部分低级错误。

我也踩过这个坑，后来发现主要是prompt里没把工具边界说清楚。我现在的做法是在系统提示词里加一句“每个工具只接收与自身功能直接相关的参数”，然后给每个工具都写死字段描述，效果好了不少。

另外你可以在LangGraph里加个中间校验节点，在调用工具前检查一下当前状态里的实体是不是跟目标工具匹配，不匹配就强制清空。还有个土办法，就是给天气工具加个白名单关键词过滤，不是城市名直接拒掉。

不过说实话，这种多轮调用的上下文隔离，LangGraph本身支持得确实不够优雅，我试过用状态机的思路去管理，但写起来很繁琐。你要是找到更省事的方案，记得回来分享下。

这问题我也踩过坑，核心是LangGraph的state里工具返回值没做隔离。我后来是把每个工具的调用结果单独存一个key，比如weather_result和meeting_result，最后再让Agent统一从这些key里取数据，基本就解决了。另外你可以在工具调用前加一步意图拆分的节点，强制先识别出用户要几个动作，再分别执行。你的会议室地址被当成天气参数，大概率是工具描述写得不够具体，试试在tool的description里加上“仅用于查询天气，不接受其他信息”这类约束。

我之前也踩过这坑，后来把每个工具的输入schema写死，强制校验参数类型，串上下文的情况少了很多。

试试在工具调用前加个意图路由节点，把参数按工具schema严格校验一遍，能挡掉不少串场问题。

我都是把多步工具调用拆成子状态机，每个工具独立记忆，最后再汇总，基本没再串过。

这个问题我上周刚踩过，最后发现根子不在LangGraph本身，而是Agent的prompt里工具描述写得太模糊了。你试试把每个工具的输入schema做严格校验，比如天气查询只接受城市名+日期，会议室预订必须带时间戳和参会人列表，这样即使模型传错参数，工具层也会直接报错，不会继续往下串。另外我自己的做法是给LangGraph的每个节点加一个“意图缓存”变量，在两个工具调用之间显式传递上下文，相当于手动把用户的原话拆成两个独立子任务，而不是让模型自己拼接。还有个偏门但有效的方法：把工具调用的中间结果存到state里，然后在下一个节点的system prompt里注入“你之前已经查询过天气，现在仅处理会议室请求”，强制隔离上下文。说实话，多工具Agent串上下文大概率是模型对工具边界理解不够，你可以试试在工具描述里加反例，比如“如果用户提到会议室，绝对不要包含在天气查询参数中”。我目前用这种“工具描述+状态隔离”双保险，基本解决80%场景，但偶尔遇到用户一句带三个意图还是会抽风，估计得等GPT-5或者换更强的模型才能根治。