【导航台账】制造业数据与AI践行者老蒋的技术博客全系列文章汇总持续更新 文章摘要LangChain ReAct Agent 调用多参数工具时反复报 Field required 错误排查发现完整 JSON 被嵌套塞进第一个参数字段。本文深入剖析 ReAct Agent 参数打包机制提供 args_schemaNone 绕过 Pydantic 自动校验、手动解析参数的完整落地方案彻底终结嵌套 JSON 问题。问题现象兄弟们我在Case03多工具协同Agent的开发中被同一个问题折磨了好几天。明明代码逻辑没问题工具定义也写清楚了但Agent一调用generate_work_order就报错❌ 错误: 3 validation errors for WorkOrderInput fault_code Field required [typemissing, input_value{line_name: {line_nam...gned_shift: 白班}}, input_typedict] solution Field required [typemissing, input_value{line_name: {line_nam...gned_shift: 白班}}, input_typedict] spare_parts_status Field required [typemissing, input_value{line_name: {line_nam...gned_shift: 白班}}, input_typedict]我当时的第一反应是这不科学啊……Agent生成的Action Input明明包含了所有参数{ line_name: 交互屏组装A线, fault_code: E401, solution: 重启工控机并检查USB连接线, spare_parts_status: 充足, assigned_shift: 白班 }但Pydantic告诉我fault_code、solution、spare_parts_status这三个字段缺失。仔细一看报错信息里的input_value——整个JSON被嵌套ReAct Agent 嵌套 JSON塞进了line_name字段input_value{line_name: {line_name: 交互屏组装A线, fault_code: E401, ...}}根因分析说实话Field required 报错原因让我翻来覆去查了好几天。不是代码写错了而是LangChain ReAct Agent 的“出厂设置”就是这样的。第一层ReAct Agent 不支持多参数工具LangChain 官方文档里其实藏着一句话create_react_agent创建的工具不支持多参数-。ReAct Agent 在处理工具调用时会把所有参数打包成一个JSON字符串然后整个塞进第一个字段里-。这就是为什么line_name收到的不是字符串而是一个完整的JSON对象。第二层Pydantic在校验之前就已经“阵亡”了BaseTool的args_schema在_run方法执行之前就会对输入参数进行校验-。当Agent把嵌套JSON传给工具时Pydantic看到的是{line_name: {line_name: 交互屏组装A线, fault_code: E401, ...}}它只认识line_name这个字段其他字段全被埋在了字符串内部根本解析不到。于是报错Field required。你在_run里面加再多的解析逻辑都没用。因为Pydantic在校验阶段就把路堵死了。第三层这是一个社区公认的“老大难”问题这个问题在LangChain社区里被反复讨论-。有开发者尝试过把所有字段都设为Optional然后在_run里手动处理-。也有人尝试用正则表达式自己解析。但这些方案要么不彻底要么治标不治本。解决方案别慌一招搞定它。核心思路绕过Pydantic自动校验把args_schema设为None让_run方法自己说了算。class GenerateWorkOrderTool(BaseTool): name: str generate_work_order description: str 生成智联工坊标准维修工单... args_schema: Optional[Type[BaseModel]] None # 关键关闭自动校验然后修改_run方法手动解析Agent传入的所有参数def _run(self, *args, **kwargs) - str: # 收集所有可能的输入 raw_input None if args and len(args) 0: raw_input args[0] if not raw_input: raw_input kwargs.get(line_name) or kwargs.get(input) # 解析嵌套JSON if isinstance(raw_input, str) and raw_input.strip().startswith({): try: import json, re cleaned re.sub(r^json\s*, , raw_input.strip()) cleaned re.sub(r\s*$, , cleaned) data json.loads(cleaned) # 从解析结果中提取所有字段 line_name data.get(line_name) fault_code data.get(fault_code) solution data.get(solution) spare_parts_status data.get(spare_parts_status) assigned_shift data.get(assigned_shift, 待分配) except json.JSONDecodeError: pass # 兜底默认值 fault_code fault_code or 未知 solution solution or 请参考维修手册 # ... 生成工单逻辑为什么这样做有效对比项Pydantic校验args_schema定义手动解析args_schemaNone校验时机_run执行之前_run执行之中嵌套JSON处理❌ 直接报错✅ 可以解析后再提取容错能力低严格匹配字段高可以处理各种格式灵活性低字段必须一一对应高可以从各种来源提取参数验证结果修改之后Agent的调用不再报错Action: generate_work_order Action Input: {line_name: 交互屏组装A线, fault_code: E401, ...} Observation: { order_id: WO-20260804-4164, status: 待执行, line: 交互屏组装A线, fault_code: E401, ... }工单成功生成嵌套JSON噩梦终于终结了。经验总结怕你忘了我再啰嗦一遍create_react_agent不支持多参数工具它会把所有参数打包成嵌套JSON塞进第一个字段。与其跟Pydantic死磕不如直接绕过它。落到具体操作上就是三条args_schemaNone是解药不是毒药。官方文档推荐用Pydantic做参数校验但在ReAct Agent的多参数场景下这套机制反而成了阻碍。关闭自动校验在_run里手动解析是更健壮的做法。手动解析要足够“皮实”。Agent可能传入纯净JSON、带Markdown代码块的JSON、甚至夹杂多余文字的JSON。你的解析逻辑要能覆盖这些情况而不是只处理理想格式。兜底默认值很重要。即使解析失败也要让工具有合理的默认值而不是直接崩溃。工具应该“尽量工作”而不是“完美地失败”。说白了就是一句话工具是给Agent用的不是给Pydantic看的。让工具适配Agent的行为比让Agent适配工具的校验规则更靠谱。【注意】本方案针对 ReAct Agent 多参数工具嵌套 JSON 场景并非所有场景都要关闭 Pydantic 校验。 单参数工具仍推荐使用 args_schema 做类型校验类型安全更有保障 支持结构化输出的 Agent如 OpenAI Functions Agent原生支持多参数调用无需此处理 手动解析时必须增加异常捕获与兜底逻辑避免非法输入导致工具崩溃。系列导航本文属于《数据与AI工程排坑笔记》系列上一篇智联工坊实战多工具协同Agent让AI像人类一样规划与执行复杂任务下一篇《不要让你的Agent“吊死”在一棵树上工具返回“未找到”时的容错设计》即将发布本文问题源自《智联工坊实战多工具协同Agent》实战过程完整源码及深度教程见该文链接建议收藏下次遇到Field required报错时可以先检查是否是嵌套JSON导致的问题。互动与交流你在使用LangChain ReAct Agent时有没有遇到过类似的“嵌套JSON”问题你是怎么解决的欢迎评论区吐槽咱们互相交流一下——说实话这个问题我前前后后折腾了好几天才搞明白。关于作者制造业数据与AI践行者老蒋23年IT老兵。聚焦制造业数据架构与AI融合落地。全流程实战全源码开源。 LangChain ReAct Agent 嵌套 JSON 报错？args_schema=None 解决 Field required
【导航台账】制造业数据与AI践行者老蒋的技术博客全系列文章汇总持续更新 文章摘要LangChain ReAct Agent 调用多参数工具时反复报 Field required 错误排查发现完整 JSON 被嵌套塞进第一个参数字段。本文深入剖析 ReAct Agent 参数打包机制提供 args_schemaNone 绕过 Pydantic 自动校验、手动解析参数的完整落地方案彻底终结嵌套 JSON 问题。问题现象兄弟们我在Case03多工具协同Agent的开发中被同一个问题折磨了好几天。明明代码逻辑没问题工具定义也写清楚了但Agent一调用generate_work_order就报错❌ 错误: 3 validation errors for WorkOrderInput fault_code Field required [typemissing, input_value{line_name: {line_nam...gned_shift: 白班}}, input_typedict] solution Field required [typemissing, input_value{line_name: {line_nam...gned_shift: 白班}}, input_typedict] spare_parts_status Field required [typemissing, input_value{line_name: {line_nam...gned_shift: 白班}}, input_typedict]我当时的第一反应是这不科学啊……Agent生成的Action Input明明包含了所有参数{ line_name: 交互屏组装A线, fault_code: E401, solution: 重启工控机并检查USB连接线, spare_parts_status: 充足, assigned_shift: 白班 }但Pydantic告诉我fault_code、solution、spare_parts_status这三个字段缺失。仔细一看报错信息里的input_value——整个JSON被嵌套ReAct Agent 嵌套 JSON塞进了line_name字段input_value{line_name: {line_name: 交互屏组装A线, fault_code: E401, ...}}根因分析说实话Field required 报错原因让我翻来覆去查了好几天。不是代码写错了而是LangChain ReAct Agent 的“出厂设置”就是这样的。第一层ReAct Agent 不支持多参数工具LangChain 官方文档里其实藏着一句话create_react_agent创建的工具不支持多参数-。ReAct Agent 在处理工具调用时会把所有参数打包成一个JSON字符串然后整个塞进第一个字段里-。这就是为什么line_name收到的不是字符串而是一个完整的JSON对象。第二层Pydantic在校验之前就已经“阵亡”了BaseTool的args_schema在_run方法执行之前就会对输入参数进行校验-。当Agent把嵌套JSON传给工具时Pydantic看到的是{line_name: {line_name: 交互屏组装A线, fault_code: E401, ...}}它只认识line_name这个字段其他字段全被埋在了字符串内部根本解析不到。于是报错Field required。你在_run里面加再多的解析逻辑都没用。因为Pydantic在校验阶段就把路堵死了。第三层这是一个社区公认的“老大难”问题这个问题在LangChain社区里被反复讨论-。有开发者尝试过把所有字段都设为Optional然后在_run里手动处理-。也有人尝试用正则表达式自己解析。但这些方案要么不彻底要么治标不治本。解决方案别慌一招搞定它。核心思路绕过Pydantic自动校验把args_schema设为None让_run方法自己说了算。class GenerateWorkOrderTool(BaseTool): name: str generate_work_order description: str 生成智联工坊标准维修工单... args_schema: Optional[Type[BaseModel]] None # 关键关闭自动校验然后修改_run方法手动解析Agent传入的所有参数def _run(self, *args, **kwargs) - str: # 收集所有可能的输入 raw_input None if args and len(args) 0: raw_input args[0] if not raw_input: raw_input kwargs.get(line_name) or kwargs.get(input) # 解析嵌套JSON if isinstance(raw_input, str) and raw_input.strip().startswith({): try: import json, re cleaned re.sub(r^json\s*, , raw_input.strip()) cleaned re.sub(r\s*$, , cleaned) data json.loads(cleaned) # 从解析结果中提取所有字段 line_name data.get(line_name) fault_code data.get(fault_code) solution data.get(solution) spare_parts_status data.get(spare_parts_status) assigned_shift data.get(assigned_shift, 待分配) except json.JSONDecodeError: pass # 兜底默认值 fault_code fault_code or 未知 solution solution or 请参考维修手册 # ... 生成工单逻辑为什么这样做有效对比项Pydantic校验args_schema定义手动解析args_schemaNone校验时机_run执行之前_run执行之中嵌套JSON处理❌ 直接报错✅ 可以解析后再提取容错能力低严格匹配字段高可以处理各种格式灵活性低字段必须一一对应高可以从各种来源提取参数验证结果修改之后Agent的调用不再报错Action: generate_work_order Action Input: {line_name: 交互屏组装A线, fault_code: E401, ...} Observation: { order_id: WO-20260804-4164, status: 待执行, line: 交互屏组装A线, fault_code: E401, ... }工单成功生成嵌套JSON噩梦终于终结了。经验总结怕你忘了我再啰嗦一遍create_react_agent不支持多参数工具它会把所有参数打包成嵌套JSON塞进第一个字段。与其跟Pydantic死磕不如直接绕过它。落到具体操作上就是三条args_schemaNone是解药不是毒药。官方文档推荐用Pydantic做参数校验但在ReAct Agent的多参数场景下这套机制反而成了阻碍。关闭自动校验在_run里手动解析是更健壮的做法。手动解析要足够“皮实”。Agent可能传入纯净JSON、带Markdown代码块的JSON、甚至夹杂多余文字的JSON。你的解析逻辑要能覆盖这些情况而不是只处理理想格式。兜底默认值很重要。即使解析失败也要让工具有合理的默认值而不是直接崩溃。工具应该“尽量工作”而不是“完美地失败”。说白了就是一句话工具是给Agent用的不是给Pydantic看的。让工具适配Agent的行为比让Agent适配工具的校验规则更靠谱。【注意】本方案针对 ReAct Agent 多参数工具嵌套 JSON 场景并非所有场景都要关闭 Pydantic 校验。 单参数工具仍推荐使用 args_schema 做类型校验类型安全更有保障 支持结构化输出的 Agent如 OpenAI Functions Agent原生支持多参数调用无需此处理 手动解析时必须增加异常捕获与兜底逻辑避免非法输入导致工具崩溃。系列导航本文属于《数据与AI工程排坑笔记》系列上一篇智联工坊实战多工具协同Agent让AI像人类一样规划与执行复杂任务下一篇《不要让你的Agent“吊死”在一棵树上工具返回“未找到”时的容错设计》即将发布本文问题源自《智联工坊实战多工具协同Agent》实战过程完整源码及深度教程见该文链接建议收藏下次遇到Field required报错时可以先检查是否是嵌套JSON导致的问题。互动与交流你在使用LangChain ReAct Agent时有没有遇到过类似的“嵌套JSON”问题你是怎么解决的欢迎评论区吐槽咱们互相交流一下——说实话这个问题我前前后后折腾了好几天才搞明白。关于作者制造业数据与AI践行者老蒋23年IT老兵。聚焦制造业数据架构与AI融合落地。全流程实战全源码开源。