用LangChain写Agent做多步任务，总是卡在工具调用上，求指点

试试把工具参数schema写死并加校验，模型乱填直接打回重试，比调prompt稳多了。

换结构化输出试试，参数映射让模型自己填容易串。连续调用断掉可能是上下文太长，精简下工具描述。

参数串位这个我也踩过，后来把每个工具的schema写得特别死，参数名和描述都带上示例，情况好很多。连续调用后突然空响应，大概率是对话历史里塞了太多工具返回的原始JSON，模型上下文被撑乱了，试试在中间加一层结果摘要再喂回去。框架方面可以看看LangGraph，它把多步流程显式画成图，比纯AgentExecutor好调试，能直接看到卡在哪一步。

我后来直接用OpenAI function calling重写了，LangChain那层反而容易乱传参。

我也踩过这个坑，后来发现很多时候不是模型笨，而是工具描述写得太模糊了。你把每个tool的docstring当成给新人的交接文档来写，参数含义、取值范围、什么时候该调、什么时候不该调都交代清楚，参数串味的情况会少一大截。另外LangChain的AgentExecutor在多轮之后确实容易崩，可以试试把中间步骤的scratchpad打出来看看，很多时候是某个工具的返回内容太长或者格式太乱，把后面的推理带偏了。我现在更倾向用结构化输出加自己写调度循环，虽然土一点但可控性强，出问题能一眼定位到是哪一步。还有个小技巧是在prompt里明确要求模型先输出思考再输出工具名和参数，顺序固定下来后稳定性会好一些。你那个“Invalid response”大概率是解析器没匹配上模型的输出格式，可以换个更宽松的parser或者加个重试兜底。

参数搞混这种情况我也遇到过，后来发现把每个工具的入参schema写清楚、加上字段描述和示例，比单纯调prompt管用多了。连续调用后突然空输出，多半是历史消息里塞了太多中间步骤，建议每轮把工具返回结果精简一下，别全量堆进上下文。另外可以试试把max_iterations设小一点，配合langsmith看trace，能很快定位是哪一步崩的。框架的话LangGraph对这种多步编排确实更稳，值得花点时间换过去。

学到了，感谢分享！

这个思路不错，收藏了。

参数搞混这个事我也遇到过，后来发现是工具描述写得太模糊，模型分不清哪个字段属于哪个工具，把每个参数的description写具体点会好很多。连续调用后报Invalid response，大概率是中间某步工具返回了空结果或者格式不对，模型接不下去就崩了，建议在工具函数里加个兜底返回。多步任务其实可以试试把流程拆成显式的状态机，别全指望模型自己记上下文，LangGraph在这方面比裸Agent稳一些。

参数搞混这事儿太常见了，本质上是模型对工具schema的理解不够稳，尤其两个工具的参数名有语义重叠的时候。我之前也踩过类似的坑，后来发现光调temperature基本没用，那玩意儿主要影响采样随机性，跟工具选择的对错关系不大。比较有效的做法是把每个工具的description写得特别具体，参数名也改得更区分度高一点，比如别用笼统的city，改成weather_city和restaurant_city，模型犯错的概率会明显降下来。至于连续调用几次后突然空输出报Invalid response，大概率是对话历史里混进了格式不对的tool message，或者某次工具返回了空结果导致后面拼不上，建议把每步的原始message打出来看看到底断在哪。max_iterations调大只是给它更多机会，但如果是schema层面的问题，给再多轮也白搭。框架方面其实可以看看LangGraph，它把多步流程显式画成图之后，调试起来比黑盒agent清楚太多了，哪里断了直接定位。

这个思路不错，收藏了。