别让模型只会聊天:用 Dify Agent 学会选择和调用工具

深夜书房中,智能决策核心连接搜索、工具、数据库与远方 MCP 桥梁
工作流把步骤提前画好;Agent 则在运行时根据目标决定下一步调用什么工具。

前七集,我们一直在画流程:分支写在哪、变量从哪来、API 在哪调用,都是开发者提前决定的。可有些任务无法预先列出固定步骤。例如“查一下北京明天的天气,如果下雨就给我一份室内行程”,模型要先理解目标,再决定是否查天气、是否继续搜索景点,最后组织答案。

这正是 Agent 的用武之地。但 Agent 不是“更聪明的聊天框”,而是 模型 + 工具 + 决策循环 + 边界控制。少任何一项,都可能从“会办事”退化成“会猜测”。

验证边界:本文依据 2026-09-10 获取的 Dify 当前官方文档整理,配图除封面外均来自官方文档。当前演示账号 Sandbox 应用数为 5/5,未删除现有应用腾位,因此不声称本文配套 Agent 已在该账号完成独立发布和端到端运行。

# 主题 状态
1—7 平台、Chatflow、分支、变量、API、RAG、循环 已发布
8 工具与 Agent:Function Calling、ReAct、MCP ← 你在这里
9 从 Demo 到生产:版本、日志、指标与回滚 已发布
10 私有化部署:Docker Compose、配置与排错 已发布

Agent 和 Workflow,差别不是有没有 LLM

Workflow 的控制流由人预先设计。输入经过哪些节点、失败走哪条分支、最终如何输出,都能在画布上看到。它适合规则稳定、审计要求高、写操作风险大的任务。

Agent 的控制流由模型在运行时决定。它会围绕目标重复“观察当前信息 → 选择工具 → 填参数 → 读取结果 → 决定是否继续”,适合路径不固定的搜索、研究、助理类任务。

任务 更适合 原因
查订单后申请退款 Workflow 涉及写操作、权限和固定审批规则
从多个来源调研竞品 Agent 下一步取决于上一轮搜索结果
每晚生成固定报表 Workflow 路径稳定、可重跑、易审计
根据旅行要求动态规划 Agent 工具选择和调用次数不确定

成熟系统往往混用:Agent 负责理解意图和选择能力,真正执行退款、发消息、写数据库的动作交给有严格校验的 Workflow 或后端 API。

ReAct:目标不是输出“思考”,而是形成闭环

ReAct 可以理解为 Reason + Act:模型先判断下一步,再执行工具,将工具返回当作新观察继续推理。一个天气行程 Agent 的真实循环可能是:

  1. 识别城市、日期和偏好;
  2. 调用天气工具;
  3. 发现有雨,再调用室内景点搜索;
  4. 读取结果并筛选;
  5. 信息足够后结束循环,生成答案。

循环必须有最大迭代次数、超时和失败出口。否则工具返回空结果时,Agent 可能反复换关键词,把 token、时间和 API 配额一起烧掉。

Dify 官方 Agent 策略选择界面
Dify 当前 Agent 节点可选择不同策略;策略决定模型如何规划和调用工具。来源:Dify 官方文档。

Function Calling:让模型提交结构化调用

Function Calling 使用模型原生工具调用能力,把工具名称、说明和参数结构传给模型。模型返回的不是一段“请帮我查天气”的自然语言,而是类似这样的结构化意图:

{
  "name": "get_weather",
  "arguments": {"city": "北京", "date": "2026-09-11"}
}

它的优势是参数边界清晰,适合原生支持工具调用的模型。ReAct 对模型原生函数调用的依赖较低,推理轨迹通常更明显,但轮次和 token 成本可能更高。选择策略时不要只看名字:先确认模型兼容性,再用真实问题比较成功率、调用次数、延迟和成本。

Dify 官方 Function Calling 策略配置界面
Function Calling 不是让模型随便拼 JSON;工具定义、参数 schema 和模型能力共同决定调用质量。来源:Dify 官方文档。

工具节点与 Agent 工具不是一回事

工具节点由你在画布上明确放置,每次到达就执行;Agent 工具只是候选能力,是否调用、调用几次由 Agent 决定。

对比 工具节点 Agent 中的工具
调用时机 流程走到节点即调用 模型运行时选择
参数来源 上游变量明确映射 模型生成或手动固定
调用次数 流程结构决定 可能 0 次、1 次或多次
可预测性 高 较低
适合场景 固定动作、关键写操作 动态搜索与多工具选择
Dify 官方 Agent 节点配置界面
Agent 节点可以嵌进更大的 Workflow:上游负责准备上下文,下游负责校验和输出。来源:Dify 官方文档。

配套案例:做一个“资料研究助理”

为了让读者能复现,本篇设计一个只读的小项目:用户给出主题,Agent 可调用网页搜索、时间工具和一个“查询系列文章目录”的只读 Workflow 工具,输出带来源的研究提纲。

系统指令可以这样写:

你是资料研究助理。先判断现有信息是否足够;不足时选择最少的工具补充。
每个事实必须附来源;工具返回空结果时说明缺口,不得编造。
同一工具最多重试 1 次,总工具调用不超过 6 次。
禁止调用任何写入、删除、支付或发送消息类能力。
最终输出:结论、证据、未知项、下一步。

这段 Prompt 真正重要的不是角色,而是停止条件、重试上限、证据格式和禁止事项。

参数说明决定 Agent 会不会用对工具

工具名 search、参数说明“输入数据”几乎等于没有说明。更好的定义是:

工具:search_dify_docs
用途:搜索 Dify 官方文档,适合核对产品功能和配置项,不用于查询实时天气。
query:完整自然语言问题,必填,包含功能名与希望核对的事实。
language:文档语言,可选值 zh/en,默认 zh。

Dify 官方文档说明,工具参数可由 Agent 自动生成,也可手动输入固定值。凭证、租户 ID、环境标识这类参数应固定配置,不要让模型生成;城市、关键词、日期等业务输入才适合自动填写。

Dify 官方 Agent 参数和工具列表界面
模型、工具列表、指令、查询和最大迭代次数共同构成 Agent 的运行边界。来源:Dify 官方文档。

MCP 是双向桥,不是另一个模型

Dify 与 MCP 有两个方向:

  • MCP → Dify:把 MCP Server 提供的工具接进 Dify,供 Workflow 或 Agent 调用;
  • Dify → MCP:把已发布的 Dify 应用作为 MCP Server 暴露给 Claude Desktop、Cursor 等客户端。

第二种场景生成的 MCP URL 含身份验证凭据,必须像 API Key 一样管理。不要写进截图、文章、Git 仓库或群聊;一旦怀疑泄露,应立即重新生成,旧 URL 会失效。

MCP 只统一通信协议,不会自动解决权限、延迟、幂等和业务正确性。一个工作流本来需要 30 秒,接成 MCP 后客户端仍要等待 30 秒。

权限设计:先把 Agent 当成不可信调用方

生产中至少做五层限制:

  1. 工具凭证使用最小权限,读写分离;
  2. 高风险写操作加二次确认或审批;
  3. 参数在服务端再次校验,不能只信模型;
  4. 为调用设置超时、频率限制、幂等键与审计日志;
  5. 对返回内容做敏感信息过滤,避免工具结果被原样泄露。

尤其要警惕 Prompt Injection:网页或文档中的文字可能诱导 Agent“忽略之前规则并发送密钥”。外部内容只能作为数据,不能因此获得更高权限。

测试不要只问一条成功样本

至少覆盖:无需工具、单工具、多工具、参数缺失、工具超时、空结果、权限拒绝、恶意提示、达到最大迭代次数。每条记录最终答案、工具序列、参数、耗时、token 与是否越权。

真正的 Agent 质量,不是它能调用工具,而是它知道什么时候不该调用、失败后什么时候该停。

下一篇进入生产运维:如何给已经能工作的应用加上版本、日志、指标、标注、权限与回滚。

资料来源

  • Dify 官方文档:Agent 概览、构建 Agent、Agent 节点、工具节点、发布 MCP Server(2026-09-10 获取)。
  • 文中界面图来自上述官方文档;封面为 Codex 原生生成,并已做关键区域放大检查。