别让模型只会聊天:用 Dify 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 的真实循环可能是:
- 识别城市、日期和偏好;
- 调用天气工具;
- 发现有雨,再调用室内景点搜索;
- 读取结果并筛选;
- 信息足够后结束循环,生成答案。
循环必须有最大迭代次数、超时和失败出口。否则工具返回空结果时,Agent 可能反复换关键词,把 token、时间和 API 配额一起烧掉。

Function Calling:让模型提交结构化调用
Function Calling 使用模型原生工具调用能力,把工具名称、说明和参数结构传给模型。模型返回的不是一段“请帮我查天气”的自然语言,而是类似这样的结构化意图:
{
"name": "get_weather",
"arguments": {"city": "北京", "date": "2026-09-11"}
}
它的优势是参数边界清晰,适合原生支持工具调用的模型。ReAct 对模型原生函数调用的依赖较低,推理轨迹通常更明显,但轮次和 token 成本可能更高。选择策略时不要只看名字:先确认模型兼容性,再用真实问题比较成功率、调用次数、延迟和成本。

工具节点与 Agent 工具不是一回事
工具节点由你在画布上明确放置,每次到达就执行;Agent 工具只是候选能力,是否调用、调用几次由 Agent 决定。
| 对比 | 工具节点 | Agent 中的工具 |
|---|---|---|
| 调用时机 | 流程走到节点即调用 | 模型运行时选择 |
| 参数来源 | 上游变量明确映射 | 模型生成或手动固定 |
| 调用次数 | 流程结构决定 | 可能 0 次、1 次或多次 |
| 可预测性 | 高 | 较低 |
| 适合场景 | 固定动作、关键写操作 | 动态搜索与多工具选择 |

配套案例:做一个“资料研究助理”
为了让读者能复现,本篇设计一个只读的小项目:用户给出主题,Agent 可调用网页搜索、时间工具和一个“查询系列文章目录”的只读 Workflow 工具,输出带来源的研究提纲。
系统指令可以这样写:
你是资料研究助理。先判断现有信息是否足够;不足时选择最少的工具补充。
每个事实必须附来源;工具返回空结果时说明缺口,不得编造。
同一工具最多重试 1 次,总工具调用不超过 6 次。
禁止调用任何写入、删除、支付或发送消息类能力。
最终输出:结论、证据、未知项、下一步。
这段 Prompt 真正重要的不是角色,而是停止条件、重试上限、证据格式和禁止事项。
参数说明决定 Agent 会不会用对工具
工具名 search、参数说明“输入数据”几乎等于没有说明。更好的定义是:
工具:search_dify_docs
用途:搜索 Dify 官方文档,适合核对产品功能和配置项,不用于查询实时天气。
query:完整自然语言问题,必填,包含功能名与希望核对的事实。
language:文档语言,可选值 zh/en,默认 zh。
Dify 官方文档说明,工具参数可由 Agent 自动生成,也可手动输入固定值。凭证、租户 ID、环境标识这类参数应固定配置,不要让模型生成;城市、关键词、日期等业务输入才适合自动填写。

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 当成不可信调用方
生产中至少做五层限制:
- 工具凭证使用最小权限,读写分离;
- 高风险写操作加二次确认或审批;
- 参数在服务端再次校验,不能只信模型;
- 为调用设置超时、频率限制、幂等键与审计日志;
- 对返回内容做敏感信息过滤,避免工具结果被原样泄露。
尤其要警惕 Prompt Injection:网页或文档中的文字可能诱导 Agent“忽略之前规则并发送密钥”。外部内容只能作为数据,不能因此获得更高权限。
测试不要只问一条成功样本
至少覆盖:无需工具、单工具、多工具、参数缺失、工具超时、空结果、权限拒绝、恶意提示、达到最大迭代次数。每条记录最终答案、工具序列、参数、耗时、token 与是否越权。
真正的 Agent 质量,不是它能调用工具,而是它知道什么时候不该调用、失败后什么时候该停。
下一篇进入生产运维:如何给已经能工作的应用加上版本、日志、指标、标注、权限与回滚。
资料来源
- Dify 官方文档:Agent 概览、构建 Agent、Agent 节点、工具节点、发布 MCP Server(2026-09-10 获取)。
- 文中界面图来自上述官方文档;封面为 Codex 原生生成,并已做关键区域放大检查。