MCP + Function Calling：让模型自主驱动工具链完成多步推理

标签JavaMCPFunction CallingReActj-langchainToolCallAgent前置阅读Java 实现 ReAct Agent工具调用与推理循环 → Java Agent 集成 MCP 工具协议让 AI 真正驱动企业系统适合人群已了解 MCP 基础用法希望让模型原生驱动工具调用的 Java 开发者一、前两篇做了什么这篇做什么文章 08介绍了 MCP 的基础接入方式McpManager注册 HTTP 工具手动调用run()执行然后把结果拼进 Prompt。这个方式适合验证工具是否可用但调哪个工具、传什么参数是开发者决定的模型并不参与。文章 09/10介绍了AgentExecutor让模型通过 ReAct 格式的文本输出Action: xxx / Action Input: yyy来驱动工具调用适用于任意模型但本质上是在解析模型的文本内容来判断意图。本篇做的是第三种方式把 MCP 工具清单直接注册给支持Function Calling的模型模型不再输出文本格式的 Action而是输出结构化的ToolCall函数名 JSON 参数。我们只负责执行这个 ToolCall把结果写回 Prompt然后让模型继续推理。三种方式的核心区别一句话概括方式谁决定调哪个工具工具参数格式模型要求手动调用 MCP开发者任意无ReAct 文本驱动模型文本输出字符串 / JSON 文本任意Function Calling模型结构化输出标准 JSON Schema需支持 Function Calling二、场景三步连贯推理全程无人工介入本篇的场景是自动检测当前环境的公网 IP、定位城市、查询天气get_export_ip获取本机公网出口 IPget_ip_location根据 IP 查询城市、经纬度、ISP 信息get_weather_open_meteo根据经纬度查询实时天气三个工具需要按顺序调用且上一步的返回值是下一步的输入参数。用户只需说一句话Agent 自主完成全部推理和工具调用最终给出位置 天气的总结。三个工具均在mcp.config.json的default分组中声明无需改动任何代码就能被框架加载。三、核心代码逐步拆解第一步构建 Prompt 并注入工具清单// Prompt 模板系统指令明确调用顺序和输出格式BaseRunnableChatPromptValue,?promptChatPromptTemplate.fromMessages(List.of(BaseMessage.fromMessage(MessageType.SYSTEM.getCode(), 你是一名能够调用 MCP HTTP 工具的智能体需要按以下顺序完成任务 1) 调用 get_export_ip 获取公网 IP 2) 将该 IP 传给 get_ip_location获取城市、经纬度以及网络信息 3) 使用经纬度调用 get_weather_open_meteo并设置 current_weathertrue 4) 总结位置与天气只输出结论不暴露工具名称。 工具只在必要时调用每个工具最多执行一次。 ),BaseMessage.fromMessage(MessageType.HUMAN.getCode(),用户问题${input})));// manifestForInput() 把 mcp.config.json 转成模型所需的 JSON Schema 格式ListAiChatInput.TooltoolsmcpManager.manifestForInput().get(default);// 把工具清单注册给 LLM模型推理时会自动决定何时调用哪个工具ChatAliyunllmChatAliyun.builder().model(qwen3.6-plus).temperature(0f).tools(tools).build();System Prompt 明确了调用顺序这样做有两个好处减少模型漏掉关键步骤的概率也能让调试时更容易判断是哪一步出了问题。第二步循环条件——有 ToolCall 就继续intmaxIterations5;FunctionInteger,BooleanshouldContinueround-{if(roundmaxIterations){returnfalse;// 防止死循环}if(round0){returntrue;// 第一轮必须执行}// 检查上一轮 LLM 输出是否包含 ToolCallAIMessagelastAiContextBus.get().getResult(llm.getNodeId());returnlastAiinstanceofToolMessagetoolMessageCollectionUtils.isNotEmpty(toolMessage.getToolCalls());};退出条件很清晰模型不再输出 ToolCall说明它已经拿到足够信息准备给出最终回答了。第三步核心处理器——执行 ToolCall 并写回 Observation这是整个链路中最重要的一段代码TranslateHandlerObject,AIMessageexecuteMcpToolnewTranslateHandler(msg-{ChatPromptValuepromptValueContextBus.get().getResult(prompt.getNodeId());// 不是 ToolCall说明模型已在生成最终回答直接透传if(!(msginstanceofToolMessagetoolMessage)){returnmsg;}if(CollectionUtils.isEmpty(toolMessage.getToolCalls())){returntoolMessage;}// 1. 把模型的 ToolCall 请求记入对话历史模型下一轮推理时需要看到这条记录promptValue.getMessages().add(toolMessage);// 2. 解析 ToolCall拿到工具名和参数AiChatOutput.ToolCallcalltoolMessage.getToolCalls().get(0);MapString,ObjectargsparseArgs(call.getFunction().getArguments());StringtoolNamecall.getFunction().getName();// 3. 用 McpManager 执行真实 HTTP 请求System.out.println([ToolCall] toolName params - JsonUtil.toJson(args));ObjectresultmcpManager.runForInput(default,toolName,args);Stringobservationresult!null?result.toString():工具无返回内容;System.out.println([Observation] observation);// 4. 把执行结果以 ToolMessage 形式追加到对话历史供模型下一轮参考appendToolMessage(prompt,call,observation);returnContextBus.get().getResult(prompt.getNodeId());});appendToolMessage的作用是把 Observation 以标准的ToolMessage格式写回 Prompt这样模型在下一轮推理时能看到完整的我调了什么工具、得到了什么结果的上下文。第四步组装完整链路FlowInstancechainchainActor.builder().next(prompt).loop(shouldContinue,// 循环条件有 ToolCall 就继续llm,// 每轮调用 LLMchainActor.builder().next(Info.c(needsToolExecution,executeMcpTool),// 有 ToolCall → 执行工具Info.c(input-ContextBus.get().getResult(llm.getNodeId()))// 无 ToolCall → 直接透传).build()).next(newStrOutputParser()).build();ChatGenerationfinalAnswerchainActor.invoke(chain,Map.of(input,不要询问额外信息自动检测我的公网 IP推断所在城市并告知当前天气后统一回复。));System.out.println(finalAnswer.getText());整个链路的结构非常清晰Prompt → loop( LLM → [有ToolCall? 执行MCP : 透传] ) → 输出最终回答四、完整推理过程运行后控制台会打印完整的推理轨迹 MCP Function-Calling ReAct 链开始执行... [ToolCall] get_export_ip params - {} [Observation] 123.117.177.40 [ToolCall] get_ip_location params - {ip: 123.117.177.40} [Observation] {country_name:China,region_name:Beijing Shi,city:Dongcheng Qu, latitude:39.9117,longitude:116.4097,org:AS4134 Chinanet} [ToolCall] get_weather_open_meteo params - {latitude:39.9117,longitude:116.4097,current_weather:true} [Observation] {current_weather:{temperature:18.3,windspeed:6.1,weathercode:1}} 链执行完成。 最终回答 检测到你的公网 IP 位于中国北京市东城区当前温度约 18°C天气晴朗风速 6.1 km/h。模型精确执行了三次 ToolCall没有遗漏任何一步也没有多余的调用。每次 Observation 被写回 Prompt 后模型在下一轮推理中就能自动提取所需字段如 IP → 经纬度 → 天气不需要开发者做任何字段映射。五、和 ReAct 文本驱动的本质区别很多开发者会疑问AgentExecutor也能完成多步工具调用这两种方式有什么实质区别ReAct 文本驱动AgentExecutor模型输出纯文本例如Action: get_ip_location Action Input: {ip: 123.117.177.40}框架通过字符串解析提取工具名和参数本质是在读模型写的文章。Function Calling本篇模型输出结构化 JSON例如{toolCalls:[{function:{name:get_ip_location,arguments:{\ip\:\123.117.177.40\}}}]}框架直接解析 JSON工具名和参数都是强类型字段不存在格式歧义。两种方式的适用场景场景推荐方式原因模型不支持 Function CallingReAct 文本驱动唯一可用选项参数复杂嵌套 JSON、数组Function Calling结构化输出更可靠需要精确控制推理文本ReAct 文本驱动Thought 内容完全可读对接标准 MCP 工具生态Function Calling工具 Schema 天然匹配模型稳定性要求高Function Calling减少格式解析失败六、工具调用失败怎么处理生产环境中HTTP 工具调用可能因网络超时、参数错误等原因失败。框架的处理方式是将错误信息同样以 ToolMessage 形式写回 Prompt让模型感知到这次工具调用失败了然后由模型决定是重试、跳过还是向用户说明原因try{ObjectresultmcpManager.runForInput(default,toolName,args);Stringobservationresult!null?result.toString():工具无返回内容;appendToolMessage(prompt,call,observation);}catch(Exceptione){log.error(调用 MCP 工具 {} 失败: {},toolName,e.getMessage(),e);// 把错误信息写回 Prompt模型会在下一轮 Thought 中处理appendToolMessage(prompt,call,调用失败e.getMessage());}这比直接抛出异常要友好得多——模型可以在最终回答中说明天气数据获取失败已为您提供位置信息而不是让整个链路崩溃。七、总结本篇展示了一个完整的MCP Function Calling多步推理链路。与文章 08 的手动调用相比这里的工具执行顺序和参数完全由模型决定与文章 09/10 的 ReAct 文本驱动相比这里用的是模型原生的 ToolCall 输出参数解析更可靠。核心思路只有一句话把 MCP 工具清单交给模型让模型决定调什么开发者只负责执行和回写结果。如果你觉得这段循环代码仍然繁琐下一篇文章会介绍McpAgentExecutor用一行代码封装整个流程。 相关资源完整示例Article11McpReactAgent.java对应方法mcpFunctionCallingLoop()MCP 工具配置src/test/resources/mcp.config.jsonj-langchain GitHubhttps://github.com/flower-trees/j-langchainj-langchain Gitee 镜像https://gitee.com/flower-trees-z/j-langchain运行环境需配置阿里云 API Key示例模型qwen3.6-plus