Dify 中级实验12Agent 深度配置——如何让智能体自主调用工具Dify 实验系列 · 中级 12/20 | 实验编号DIFY-102-13基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家电商公司的运营团队想做一个「业务助手」销售问「最近订单怎么样」它去查数据运营说「把促销数据算一下」它跑分析主管说「给王经理发个会议通知」它真的把消息发出去。一开始他们以为这只是「把对话模型接进来」的事结果发现完全不是——闲聊模型只会在对话框里聊天它不会自己去查数据、不会主动调工具、更不知道什么时候该发消息。真正能干活的助手必须能自己决定做什么、用什么工具做、按什么顺序做。我们第一次接这类需求时第一反应也是「把模型换聪明点不就行了」。真正动手配起来才发现——「会聊」和「会干活」之间隔着的不是模型是工具模型再聪明手上没有工具可调也只会礼貌地说一句「我无法访问外部系统」。这不是个例。任何「用户一句话、系统要动手办事」的场景都是这个模式客服机器人要查订单状态再回复、HR 助手要查员工档案再开证明、运维助手要查服务状态再告警——「会聊」和「会干活」之间隔着工具调用这道坎。2. 场景痛点这个流程的痛点在运营团队的「业务助手」项目上体现得最直接只会聊、不会干普通对话模型对「查一下数据」只能回复「我无法访问外部系统」所有动手的活还得人去做助手形同虚设。不知道该用哪个工具就算模型能调工具面对「查订单」「算数据」「发消息」多个工具它经常用错——用代码解释器去查数据用消息工具去算数工具长期闲置或乱用。破坏性操作没有确认助手直接按指令把消息发出去了内容错了、接收人错了没有挽回余地——业务上这是事故级的问题。行为边界不可控不约束规则的话模型想怎么干就怎么干同样的指令两次执行行为不一致没法上线。本质上「助手能不能干活」不取决于模型多聪明而取决于给它挂了什么工具、定了什么规则——工具即能力边界。3. 方案为什么是 Agent 自定义工具Dify 的Agent 应用agent-chat就是为「自主调用工具干活」设计的模型 Function Calling 策略 工具列表 行为规则四件套配齐Agent 就能自己决定何时调用什么工具。而工具从哪来任何工作流发布后都可以变成自定义工具——这正是本实验的关键能力。选它的理由Function Calling 策略稳定可控相比 ReAct 的文本推理function_call 让模型直接输出结构化的函数调用工具选择更准、更省 Token工具能力可自建不用等官方插件内部系统查数据、发消息、跑报表都能通过工作流发布成工具挂给 Agent行为规则可约束pre_prompt 里写清工具选择策略和确认规则破坏性操作强制先确认把 Agent 的行为边界定死。这篇文章我们就用它搭一个「全栈业务助手」Agent 自主决定何时调用内置时间工具、代码解释器和自定义「发送消息」工具完成「查数据 → 分析 → 生成报告 → 发通知」的完整业务动作。4. 整体架构13_02工具载体workflow 模式开始to / title / content / priority模拟发送消息Code生成 MSG-xxx 消息 ID确认回复LLM一句话告知发送结果结束result / message_id / status13_01agent-chat 模式无画布节点配置 模型 策略 工具 系统提示词。链路很清晰13_02 工作流负责「把发消息这件事做成一个工具」13_01 Agent 负责「决定什么时候用这个工具」——工具与决策分离Agent 只认工具的输入输出契约工具内部怎么实现它不关心。5. 模块设计5.1 Agent 核心配置agent_modemodel_config:agent_mode:enabled:truemax_iteration:10# 太少跑不完太多浪费 Token10-15 合理strategy:function_call# function_call 更稳ReAct 更灵活tools:-enabled:trueprovider_id:timeprovider_name:timeprovider_type:builtintool_label:获取当前时间tool_name:current_timetool_parameters:{}model:completion_params:max_tokens:4000temperature:0.7top_p:0.9name:deepseek-v4-flashprovider:deepseekprompt_type:simple# agent-chat 必须 simple / advanced5.2 系统提示词pre_prompt——Agent 的行为上限pre_prompt:|你是一个全栈业务助手可以帮助用户完成以下任务 ## 可用工具 1. **数据查询** - 查询业务数据订单、用户、产品 2. **代码解释器** - 执行 Python 代码做数据分析数值计算、统计、趋势 3. **发送消息** - 发送通知消息接收人/标题/内容/优先级 4. **获取当前时间** - 获取系统当前时间内置工具 ## 行为规则 1. 分步思考确定用户需要什么 → 需要哪些工具 → 按什么顺序调用 2. 工具传递一个工具的输出可以作为下一个工具的输入 3. 确认优先对破坏性操作如发送消息先请用户确认 4. 错误处理工具返回错误则分析原因并修正参数重试连续 3 次错误停止并告知系统暂时不可用 ## 工具选择策略 1. 优先使用专用工具如数据查询而非代码解释器 2. 代码解释器只用于数值计算和数据分析 3. 发送消息前必须请用户确认 ## 输出格式 - 涉及数据分析必须展示完整分析过程最终回答结构化、清晰5.3 自定义工具13_02自定义工具的本质是 OpenAPI 规范中定义的 APIDify 会把它转成 Function Calling 的函数定义交给 LLM。开始节点四个变量-data:type:startvariables:-label:接收人required:truetype:text-inputvariable:to-label:消息标题required:truetype:text-inputvariable:title-label:消息内容required:truetype:paragraphvariable:content-label:优先级默认 normalrequired:falsetype:selectvariable:priorityoptions:[low,normal,high]代码节点模拟发送defmain(to:str,title:str,content:str,priority:str)-dict:importtime pri(priorityornormal).strip()ornormalmsg_idMSG-{}-{}.format(time.strftime(%Y%m%d%H%M%S),abs(hash(totitle))%10000)return{message_id:msg_id,status:success,send_text:已向 {} 发送消息「{}」优先级 {}{}.format(to,title,pri,content)}发布流程工作流 →发布为工具→ 在 13_01 的工具列表中挂载Agent 即可通过send_messageto/title/content/priority自主调用。6. 运行验证输入预期实测你好直接回复不调任何工具无工具调用正常闲聊现在几点了调用内置 current_time工具调用并返回当前时间给王经理发一条通知内容明早 9 点开会先请求确认 → 调 send_message → 返回 MSG-xxx三轮工具编排完整消息 ID 正确返回12345 × 67890 等于多少自动判断需要计算调代码解释器计算结果正确展示连续追问「再发一次」记忆生效复用上轮参数记忆窗口内参数延续无需重述7. 实战坑坑现象修复agent-chat 的 prompt_type 留空导入/保存报 is not a valid PromptType必须显式填simple或advancedagent-chat 用 blocking 响应模式应用不可用/调用报错agent-chat 只支持 streaming必须用 streaming工具描述写得太简略LLM 不知道何时该用工具长期闲置描述写清「做什么/何时用/参数含义」实验文档设计约束工作流没发布就去找工具Agent 工具列表里找不到 send_message先「发布为工具」再挂载改动后需重新发布实验文档设计约束破坏性操作不设确认规则一条指令就发出真实通知pre_prompt 里写「发送前请用户确认」实验文档设计约束8. 实验文档及源码获取实验文档完整操作步骤DIFY-13Agent深度配置与自定义工具.md源码一Agent 应用dify102_13_01_全栈业务助手.yml源码二自定义工具dify102_13_02_发送消息工具.yml文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 中级实验13多 Agent 协作——如何编排多个智能体分工干活 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。