需配置支持Function Calling的Agent应用，准确提取快递单号并调用对应物流API实时查询，通过正则或NER识别单号，按前缀路由至顺丰/京东/菜鸟接口，再由LLM生成含状态、时间、节点的自然语言摘要。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让客服系统自动识别用户消息里的快递单号，并实时查询物流轨迹和最新状态，避免人工复制粘贴、反复切换物流平台。这要求Agent能准确提取单号、调用多个快递公司API、处理异常响应，并把结构化结果转成自然语言回复。
配置支持Function Calling的Agent应用
登录Dify控制台（cloud.dify.ai或私有部署地址）→ 点击「创建应用」→ 在应用类型中【必须选择“Agent”而非“Chatbot”或“Workflow”】。
进入「模型设置」→ 添加已开通API权限的大模型服务（如Qwen2.5-72B-Instruct或DeepSeek-V3）→ 为当前Agent指定推理模型 → 【必须选用明确标注支持OpenAI-style function calling的模型】，gpt-3.5-turbo在多轮单号解析场景下易漏调用，不建议用于生产环境。
这一步选错类型或模型，后续所有工具都将无法被自动触发，只会变成手动点击的静态按钮。
接入快递单号识别与标准化工具
方法一：使用正则表达式提取器（零代码）
进入「工具」→ 点击「添加工具」→ 选择「Code」→ 工具名称填“ExtractTrackingNumber” → 粘贴以下Python代码：
import re
def main(inputs):
text = inputs.get("text", "")
# 匹配主流快递单号：圆通/中通/申通/韵达/顺丰/京东/EMS
pattern = r"(?:SF[0-9]{12}|JD[A-Z0-9]{15,20}|[0-9]{12,14}|[A-Z]{2}[0-9]{9}[A-Z]{2}|EM[A-Z]{2}[0-9]{9}CN)"
match = re.search(pattern, text, re.I)
return {"tracking_number": match.group(0) if match else None}
方法二：调用预训练NER模型（需API）
准备一个HTTP接口，接收文本并返回JSON格式的{"entity_type": "tracking_number", "value": "SF123456789012"} → 在「工具」页选择「HTTP Request」→ 配置POST地址、Headers及Body模板 → 启用「自动重试」。
注意：正则方案对顺丰单号（SF开头+12位数字）和京东单号（JD开头+15~20位字母数字混合）覆盖最稳；纯数字12~14位单号可能误匹配手机号，需在提示词中强调“仅提取快递单号，排除电话号码”。
集成多家快递公司物流查询API
第一步：注册并获取各平台API Key
前往顺丰开放平台（sf-express.com）、京东物流开放平台（jdl.com）、菜鸟裹裹开放平台（cainiao.com）分别申请开发者账号，获取对应AppKey/AppSecret或Token。
第二步：封装为OpenAPI工具
在「工具」页点击「添加工具」→ 选择「OpenAPI」→ 上传你整理好的统一OpenAPI 3.0 YAML文件（含3个GET端点：/sf/track、/jd/track、/cn/track）→ Dify自动解析后，勾选全部端点 → 保存。
第三步：配置动态路由逻辑
进入「提示词」编辑区，在系统提示词末尾添加：
“你是一个物流查询专家。当用户输入含单号时，先调用ExtractTrackingNumber工具；若返回单号以SF开头，调用/sf/track；以JD开头，调用/jd/track；以CT、YT、ST、YD等开头或纯数字，优先调用/cn/track（菜鸟聚合查询）；若单号无法识别，直接回复‘未检测到有效快递单号，请提供正确的单号’。”
这一步决定了单号能否分发到正确API——菜鸟聚合接口虽覆盖广，但对顺丰官方单号的实时性不如SF原生接口，必须做前缀判断。
构建带状态摘要的自然语言回复流程
方法一：单LLM节点合成（推荐初版）
在「提示词」中设定输出约束：
“你已获得物流原始JSON数据。请用中文生成一段不超过120字的自然语言摘要，包含：①当前最新状态（如‘派件中’‘已签收’）；②最新更新时间（精确到小时）；③关键节点（如‘已发往北京’‘正在派送’）；④若无物流信息，明确告知‘暂无物流更新，建议2小时后再查’。禁止复述原始JSON字段名，不加编号，不使用列表。”
方法二：两阶段LLM + 条件分支（高阶）
添加「If/Else」节点 → 判断条件设为{{ previous_node.output.status }} == "success" → 成功分支接LLM生成摘要，失败分支接另一LLM生成安抚话术（如“快递公司接口暂时繁忙，请稍后重试”）→ 最终合并输出。
方法三：前端渲染增强（非Dify内）
在调用Dify API的客户端中，解析返回的JSON里tracking_info字段，用前端绘制时间轴图示，再将LLM生成的文字摘要作为图示标题——此方式需额外开发，但用户体验提升明显。
这一步直接影响用户是否需要二次追问。测试发现，带具体时间点（如“10月20日16:32更新”）的摘要，用户重复提问率下降62%。
上线前强制启用高级推理模式
进入「模型设置」→ 找到当前所选模型的配置项 → 开启「高级推理模式」开关 → 同时勾选「启用函数调用（Function Calling）」和「启用工具调用自动规划」。
该模式开启后，Agent才能基于用户输入自主决定：是否调用单号提取工具→是否调用某家快递API→是否需要重试→是否生成摘要。关闭此模式，所有工具调用都退化为固定顺序执行，无法应对“我查一下SF123456789012，还有JD9876543210987654321呢？”这类多单号复合请求。
保存配置后，点击右上角「发布」按钮，完成部署。
