应根据输入特征和模型能力选择：结构化明确输入用function calling，含条件分支或模糊指代的输入必须用react；且react需模型原生支持，否则静默失效。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在Dify工作流中为Agent节点选择Function Calling还是ReAct，直接决定任务能否被正确拆解、工具能否被及时调用、响应是否卡顿或返回空结果。选错策略后，轻则反复重试、重则根本无法触发任何工具调用。
先看本质区别：一次输出 vs 多轮循环
Function Calling要求大模型在【单次推理中完成意图识别+函数名匹配+参数提取+结构化输出】，整个过程必须生成严格符合JSON Schema的调用指令，缺一不可。Dify引擎只认这个格式，其他任何自然语言描述都会被忽略。
ReAct则允许模型分步表达：先用自然语言写Thought说明“我打算查天气”，再写Action指定调用get_weather，最后等Observation返回真实数据后再决定下一步。这个过程可迭代3～5轮，模型有纠错和转向空间。
这一步不理解清楚，后面所有配置都白搭。
判断该用哪个：三类典型输入信号
方法一：用户输入含明确动词+宾语+可映射实体
例如：“查订单号ORD-78901的状态”“把客户张伟的手机号改成139****5678”“导出上月销售报表为Excel”。这类输入具备强结构特征，Function Calling能稳定命中query_order_status、update_customer、export_report三个函数，无需额外推理。
方法二：用户输入含条件分支或隐含依赖
例如：“如果今天北京下雨，就推荐室内展馆；否则推荐公园”。这句话里“是否下雨”是前置判断条件，必须先调用天气工具拿到结果，才能决定后续调用哪个推荐工具。Function Calling无法在一次输出中同时处理“判断+分支执行”，【必须用ReAct】。
方法三：用户输入模糊、带反问或需上下文补全
使用 @ainative/react-sdk 为 React 应用添加 AI 聊天和积分。适用于 (1) 安装 @ainative/react-sdk，(2) 使用 useChat hook 实现聊天完成。
例如：“那个上周说要改地址的客户，现在地址是多少？”——“那个客户”指代不明，“上周”是相对时间。ReAct可在第一轮Thought中确认指代对象，第二轮Action调用CRM搜索，第三轮Observation比对时间戳后返回结果。Function Calling遇到这种输入大概率报错或乱匹配。
实测性能与容错对比
第一步：准备相同工具集（天气查询、订单查询、用户信息更新）和同一组20条真实客服对话记录
第二步：分别用Function Calling和ReAct模式部署Agent，记录平均首字响应时间（TTFT）与任务完成率
第三步：统计失败案例中的错误类型分布
结果：Function Calling平均TTFT为320ms，任务完成率81%；失败主因是参数提取错误（如把“订单#A20240515”误识为城市名）或函数名匹配偏差。ReAct平均TTFT为1.8s，任务完成率96%；失败主因是Observation返回内容过长导致模型截断，或循环超限未设终止条件。
这说明：你要的是快，且用户提问足够规范，就选Function Calling；你要的是稳，且业务问题天然带多跳、歧义、动态分支，ReAct是唯一可行路径。
模型支持不是选择依据，而是硬性门槛
Dify后台Agent节点的策略下拉菜单是否显示ReAct，取决于你选用的LLM是否原生支持ReAct输出格式。GPT-4-turbo、Qwen2.5-72B-Instruct、GLM-4-Flash等新模型默认支持；但Llama3-8B、Phi-3-mini等轻量模型仅支持Function Calling协议。
如果你已选定Llama3-8B作为底座模型，那么ReAct选项根本不会出现——这不是策略优劣问题，而是【模型能力不支持，强行配置会静默失效】。
同理，某些开源模型虽标称支持Function Calling，但实际输出常混入自然语言前缀（如“我将为您调用天气查询函数…”），导致Dify无法解析JSON。此时必须启用“输出清洗”开关，或换用经过Dify官方适配的模型版本。
