Dify Agent教程：不用写太多代码，搭建一个可用的业务Agent | 跨境AI入门指南

摘要： 用Dify搭业务Agent

关键词： Dify Agent、Dify工作流、AI业务Agent、RAG知识库、跨境电商AI、客服Agent、Listing Agent、广告周报Agent

系列定位： AI Agent完整教程，第 12 篇

核心观点： Dify 的价值不是让运营同学“随便拖几个节点就全自动”，而是把已经验证过的业务 SOP、知识库、提示词、工具和人工确认点，做成可重复运行、可测试、可发布、可监控的 AI 工作流。

很多跨境团队第一次接触 Dify，会很兴奋。

不用写太多代码。

可以接模型。

可以做知识库。

可以拖工作流。

可以发布成网页。

可以通过 API 接到其他系统。

看起来很适合运营团队。

于是第一个需求通常会变成：

“我们能不能做一个全自动运营 Agent？”

这句话听上去很大，实际很危险。

因为 Dify 降低的是搭建门槛，不是业务复杂度。

如果你的客服 SOP 混乱，Dify 不会自动让客服回复变靠谱。

如果你的产品资料没有版本，Dify 不会自动知道哪个参数是最新。

如果你的广告规则没有阈值，Dify 不会自动知道该否词还是加预算。

如果你没有人工确认点，Dify 工作流跑得越顺，风险越大。

Dify 适合把清楚的流程变成可重复的 Agent，不适合把混乱的流程变成全自动。

这篇文章不做功能罗列。

我们用跨境卖家最常见的客服 FAQ、Listing 初稿、广告周报三个场景，讲清楚怎么从 0 搭一个能用、能测、能上线试点的 Dify 业务 Agent。

先讲清楚：Dify 适合什么，不适合什么

Dify 官网把自己定位为 Agentic Workflow Builder，用于开发、部署和管理 autonomous agents、RAG pipelines 和 agentic workflows。

Dify 文档里也把应用发布方式分成 Web App、API、Embed、MCP Server 等；知识库文档说明，Knowledge 可以把团队自己的数据作为上下文，让应用基于 RAG 减少幻觉。

这些能力对卖家很有用。

但你要先搞清楚它适合的任务类型。

适合 Dify 的任务

第一，流程相对固定。

比如客服 FAQ 草稿：

输入买家问题。

判断问题类型。

检索产品 FAQ 和售后 SOP。

生成英文回复草稿。

标注是否需要人工升级。

第二，需要知识库。

比如 Listing 初稿：

必须查产品参数、品牌语气、禁用词、关键词清单。

不能只靠模型自由发挥。

第三，需要运营能维护。

比如广告周报：

运营可以调整阈值、提示词、输出模板，而不是每次找工程师改代码。

第四，输出先做草稿或建议。

比如：

客服回复草稿。
Listing 改版建议。
广告异常清单。
竞品复盘摘要。

不适合第一阶段交给 Dify 的任务

不要第一版就做：

自动调广告预算。
自动改价。
自动上传 Listing。
自动发客服消息。
自动处理退款。
自动写入 ERP 或店铺后台。

这些不是“Dify 能不能接 API”的问题。

是权限、日志、审批、回滚和责任问题。

Dify 文档的 Tool Node 和 HTTP Request Node 都说明工作流可以连接外部服务和 API，这意味着它能取数，也可能能执行动作。

对卖家来说，能执行不等于应该执行。

第一版业务 Agent，建议只做到：

读取资料。

生成建议。

输出待确认动作。

人工确认后再由人执行。

Dify 里的几个核心概念，用卖家语言理解

1. User Input 节点：把任务入口设计清楚

Dify 的 User Input 节点用于定义用户运行应用时要填写什么。文档说明，每个输入字段会成为下游节点可以引用的变量。

卖家可以理解成：

这是 Agent 的工单表单。

如果入口乱，后面都乱。

客服 Agent 的输入不要只写一个“大文本框”。

至少要有：

marketplace。
product_line。
sku。
buyer_question。
issue_type。
order_status。
language。
urgency。

Listing Agent 的输入至少要有：

sku。
marketplace。
product_specs。
keyword_list。
competitor_insights。
brand_tone。
forbidden_claims。

输入变量越清楚，后续检索和生成越稳定。

2. Knowledge：让 Agent 先查资料

Dify Knowledge 文档说，知识库是你自己的数据集合，可以集成到 AI 应用里，通过 RAG 让 LLM 使用你的自定义知识作为额外事实来源。

卖家可以理解成：

这是团队资料库。

但不是网盘。

你要按业务分层：

产品事实库。
售后 SOP 库。
品牌和禁用词库。
Listing 规范库。
广告复盘库。
竞品观察库。

知识库不是越大越好。

真正要做的是：

文档有版本。
文档有负责人。
文档有适用站点。
文档有适用 SKU 或产品线。
旧版资料不进默认检索。

Dify 知识库文档也提到可以管理内容、测试和验证检索、用 metadata 增强检索。

这对跨境团队很关键。

比如你问美国站售后政策，就不应该检索到德国站规则。

3. Knowledge Retrieval 节点：把知识库接进流程

Dify Knowledge Retrieval 节点可以从知识库检索和问题相关的内容。文档里提到可以启用 metadata filtering，用来限制检索到特定文档，提高检索精准度。

卖家可以理解成：

这是让 Agent 查资料的一步。

比如客服 Agent：

输入里有 marketplace = US，sku = KS-001。

检索时就应该优先过滤：

marketplace = US。
product_line = 对应产品线。
status = active。

不要让它全库乱搜。

4. LLM 节点：负责理解和生成

Dify LLM 节点文档说明，它会调用语言模型处理文本、图片和文档，支持结构化输出、上下文管理和多模态输入。

卖家可以理解成：

这是“写答案”和“做判断”的节点。

但 LLM 节点不应该负责所有事。

比如：

字段清洗用 Code 或规则节点。
固定格式用 Template 节点。
知识检索用 Knowledge Retrieval。
外部服务调用用 Tool 或 HTTP Request。

不要把所有逻辑都塞进一个大提示词。

5. Tool / HTTP Request 节点：连接外部服务

Dify Tool Node 文档说明，工具节点可以让工作流连接外部服务和 API，获取实时数据或执行内容处理。HTTP Request 节点可以连接外部 API 和 Web 服务，支持获取数据、发送 webhook、上传文件或集成服务。

卖家可以理解成：

这是把外部数据接进 Agent 的水龙头。

可以用来：

查内部 SKU 信息。
查库存状态。
调用关键词数据。
读取价格监控。
拉取订单状态。

但要设置边界：

第一阶段只读。

不写入。

不改价。

不调预算。

不发消息。

6. IF/ELSE、Template、Output、Answer：让流程可控

Dify 快速入门文档展示了用 IF/ELSE 做输入校验，用 Template 节点做稳定格式化，用 Output 或 Answer 返回结果。

卖家可以理解成：

这不是装饰。

这是业务流程的护栏。

比如：

如果缺 SKU，停止。

如果找不到产品资料，停止。

如果问题涉及退款，升级人工。

如果涉及差评暗示，升级人工。

如果广告建议涉及预算，输出待确认，不执行。

三个适合第一批上线的 Dify Agent

1. 客服 FAQ Agent

目标：

生成客服回复草稿，不自动发送。

输入：

buyer_question。
sku。
marketplace。
issue_type。
order_status。
language。

知识库：

产品 FAQ。
说明书。
售后 SOP。
退换货规则。
禁止回复清单。
升级人工规则。

流程：

User Input 收集问题和 SKU。
IF/ELSE 检查必填字段。
Knowledge Retrieval 按站点、SKU、问题类型检索资料。
LLM 节点生成回复草稿。
LLM 或规则节点判断是否需要人工升级。
Template 节点格式化输出。
Answer 节点返回给客服主管。

输出：

问题分类。
中文处理建议。
英文回复草稿。
引用资料。
风险提示。
是否升级人工。

边界：

不自动发送。
不承诺超出 SOP 的赔偿。
不引导评价。
不处理客户隐私。

2. Listing 初稿 Agent

目标：

生成 Listing 草稿和图片文案建议，不自动上传后台。

输入：

sku。
marketplace。
product_specs。
keyword_list。
competitor_review_summary。
brand_tone。
forbidden_claims。

知识库：

产品事实库。
品牌语气库。
禁用词库。
Listing SOP。
历史优秀 Listing。

流程：

检查产品参数是否完整。
检索产品事实和品牌规则。
提取关键词意图。
生成标题、五点、描述、图片文案。
风险检查：参数、认证、商标、过度承诺。
输出草稿和待确认项。

输出：

标题草稿。
五点草稿。
图片脚本。
QA 建议。
Search Terms 建议。
风险项。
人工确认清单。

边界：

不编造产品参数。
不照抄竞品文案。
不自动上传。
合规表达必须人工确认。

3. 广告周报 Agent

目标：

把导出的广告报表变成异常清单和人工确认动作。

输入：

广告 CSV 或表格摘要。
目标 ACOS。
库存状态。
促销日历。
上周调整记录。

知识库：

广告命名规则。
目标 ACOS 规则。
否词 SOP。
预算调整边界。
历史复盘。

流程：

User Input 上传报表和阈值。
Code 节点或 LLM 节点检查字段。
计算 CTR、CPC、CVR、ACOS。
判断高花费无转化、低曝光高转化、预算不足、异常上升。
LLM 节点解释可能原因。
Template 输出周报。
Output 返回待确认动作清单。

输出：

数据事实。
原因推断。
建议动作。
待确认清单。
缺失数据。

边界：

不自动调预算。
不自动否词。
不直接写入广告后台。
不把单周数据当长期趋势。

更明确地说，第一版 Dify 业务 Agent 的红线是：不自动调广告预算、不自动发送客服消息、不处理未脱敏客户隐私，所有可能影响资金、账号、买家承诺和后台数据的动作都必须人工确认。

重点示例：客服 FAQ Agent 怎么搭

下面用客服 FAQ Agent 讲完整流程。

第一步：先定义业务目标

不要写：

“做一个客服 Agent。”

要写：

“做一个美国站客服回复草稿 Agent。它根据买家问题、SKU、产品 FAQ、售后 SOP，生成英文回复草稿，并标注引用来源和是否需要人工升级。第一版只覆盖安装、配件、物流、质量、退款咨询五类问题，不自动发送消息。”

这个描述里有 6 个关键信息：

站点。
使用者。
数据来源。
输出。
覆盖范围。
禁止动作。

第二步：准备知识库

客服知识库不要一上来全量导入。

第一版只准备：

1 条产品线。
1 个站点。
20 个高频 FAQ。
1 份退换货 SOP。
1 份禁止回复清单。
10 条优秀历史回复。

每个文档建议加 metadata：

字段	示例
document_type	faq / sop / manual / forbidden_reply
marketplace	US
product_line	kitchen_storage
sku	KS-001
status	active
version	v2026-07
owner	support_team
sensitivity	internal

这样 Knowledge Retrieval 才能按站点和产品线过滤。

第三步：设计输入变量

User Input 建议设置：

变量	类型	必填	用途
marketplace	Select	是	检索站点规则
sku	Short Text	是	定位产品
issue_type	Select	是	路由问题类型
buyer_question	Paragraph	是	用户原始问题
order_status	Select	否	辅助判断售后边界
language	Select	是	输出语言
allow_compensation	Checkbox	否	是否允许生成补偿建议

注意：

不要让客服自由粘贴客户姓名、地址、电话。

如果确实需要订单状态，用“已发货/运输中/已签收/未知”这类枚举，不要上传完整订单信息。

第四步：做输入检查

用 IF/ELSE 或 LLM 节点先检查：

sku 是否为空。
buyer_question 是否为空。
issue_type 是否明确。
marketplace 是否支持。

如果缺字段，直接返回：

“资料不足，请补充 SKU / 问题类型 / 买家问题。”

不要让它缺资料还硬写。

第五步：知识库检索

Knowledge Retrieval 里配置：

查询变量：buyer_question。
知识库：客服 FAQ、售后 SOP、产品说明书、禁止回复清单。
metadata filtering：marketplace、sku、product_line、status。
开启引用或在输出里要求引用文档。

检索后，建议让一个 LLM 节点先做“证据检查”：

它只回答：

找到了哪些资料。
哪些资料支持回复。
哪些资料缺失。
是否需要人工升级。

不要直接生成回复。

第六步：生成客服草稿

LLM 节点提示词可以这样写：

你是亚马逊美国站客服回复助理。

你的任务是根据买家问题和检索到的知识库资料，生成英文回复草稿。

输入：
- 买家问题：{{buyer_question}}
- 问题类型：{{issue_type}}
- 订单状态：{{order_status}}
- 检索资料：{{knowledge_context}}

输出结构：
1. 问题分类。
2. 处理建议。
3. 英文回复草稿。
4. 引用资料。
5. 是否需要人工升级。
6. 禁止或风险表达。

要求：
- 只基于检索资料回答，不要编造政策。
- 不承诺超出 SOP 的退款、补发、补偿。
- 不引导买家修改或留下评价。
- 如果资料不足，明确说需要人工确认。
- 如果涉及差评暗示、法律投诉、安全事故、退款争议，标记为人工升级。

第七步：格式化输出

Template 节点可以把结果固定成：

## 问题分类
{{category}}

## 英文回复草稿
{{reply_en}}

## 内部处理建议
{{internal_note}}

## 引用资料
{{citations}}

## 风险提示
{{risk_flags}}

## 是否需要人工升级
{{escalate}}

用 Template 节点的好处是格式稳定。

Dify 快速入门文档也提到，固定格式用 Template 节点比让 LLM 每次自由排版更稳定，而且不消耗额外 token。

第八步：测试历史样本

上线前至少测试 30 条历史客服问题。

分成：

10 条安装问题。
5 条配件问题。
5 条物流问题。
5 条质量问题。
5 条退款或敏感问题。

每条看：

是否检索到正确资料。
是否引用正确 SOP。
是否编造赔偿。
是否该升级时升级。
英文语气是否合适。

Dify 工作流设计原则

1. 一个节点只做一件事

不要一个 LLM 节点同时做：

判断问题类型。
检索资料。
写回复。
做风险审核。
格式化输出。

拆开更好调试。

2. 能用规则的，不要交给模型

比如：

字段是否为空。
ACOS 公式。
SKU 是否匹配。
标题长度。
禁用词命中。

这些用规则、Code 节点或 Template 更稳。

模型负责理解和生成，不负责所有判断。

3. 高风险动作必须停下来

只要涉及：

退款。
补发。
差评。
广告预算。
改价。
上传 Listing。
客户隐私。

就输出“待人工确认”。

4. 每个节点都要能解释

运营团队要看得懂：

这个节点输入什么。
输出什么。
为什么失败。
出错怎么改。

否则可视化只是画布好看，实际不可维护。

5. 先做 Chatflow，再做复杂 Workflow

客服问答类适合 Chatflow。

批量处理、表格分析、报告生成，更适合 Workflow。

不要所有任务都做成开放聊天。

很多运营任务需要固定输入和固定输出，Workflow 更稳。

第一周落地 SOP

第 1 天：选低风险场景

从下面三选一：

客服 FAQ 草稿。
Listing 初稿。
广告周报摘要。

不要选自动执行动作。

第 2 天：准备资料

只准备一个产品线、一个站点。

资料包括：

产品资料。
SOP。
禁用词。
历史样本。
输出模板。

清理：

客户姓名。
电话。
邮箱。
地址。
seller ID。
API key。

第 3 天：做知识库

上传资料。

加 metadata。

测试检索。

不要急着搭 Agent。

先问 20 个测试问题，看能不能检索到正确资料。

第 4 天：搭最小工作流

只做：

输入。
检索。
生成。
风险提示。
输出。

不要接 API。

不要接店铺后台。

第 5 天：跑历史样本

用 20-30 条真实历史样本。

记录错误：

检索错。
资料缺。
回复过度。
格式不稳。
升级判断错。

第 6 天：加规则和人工确认

把常见错误写进：

IF/ELSE。
metadata filter。
LLM 提示词。
风险节点。
输出模板。

第 7 天：发布试点

用 Dify Web App 给小范围团队试用。

Dify Publish 文档说明，应用可以发布成 Web App、API、Embed、MCP Server 等。第一版建议先用 Web App 小范围试用，不要一上来通过 API 接生产系统。

可复制提示词：设计 Dify 业务 Agent

你是我的 Dify 业务 Agent 架构顾问。

团队背景：
- 平台：[Amazon / Shopify / TikTok Shop / 其他]
- 站点：[US / UK / DE / JP / 其他]
- 类目：[填写]
- 团队角色：[客服 / Listing / 广告 / 运营 / 老板]

我要搭建的 Agent：
[填写，例如客服 FAQ 回复草稿 Agent]

目标：
[填写该 Agent 要解决的具体问题]

现有资料：
1. [资料1]
2. [资料2]
3. [资料3]

请帮我设计 Dify 方案，输出：

1. 适合做 Chatflow 还是 Workflow，原因是什么。
2. User Input 需要哪些变量，字段类型是什么。
3. 知识库应该怎么分层。
4. 每份文档需要哪些 metadata。
5. 工作流节点顺序。
6. 每个节点的输入、输出和提示词。
7. 哪些地方用规则，哪些地方用 LLM。
8. 是否需要 Tool / HTTP Request 节点。
9. 哪些动作必须人工确认。
10. 需要准备哪些历史测试样本。
11. 上线验收标准。
12. 日志和复盘怎么做。

要求：
- 不要建议第一版自动执行高风险动作。
- 资料不足时先列缺失清单。
- 所有敏感数据要脱敏。
- 输出必须适合运营团队维护。

上线前验收清单

一套 Dify 业务 Agent 能不能试点，至少看 18 条。

场景足够具体。
使用者明确。
输入变量明确。
知识库已清洗。
文档有 metadata。
检索结果能命中正确资料。
旧版资料不进默认检索。
LLM 节点提示词边界清楚。
能区分事实、推断和建议。
高风险动作输出待确认。
不自动写入后台。
不暴露客户隐私。
输出格式稳定。
通过历史样本测试。
失败时能看懂哪个节点出错。
有日志复盘流程。
有负责人维护知识库和提示词。
有下线或回退方案。

少于这些，不要说已经“上线业务 Agent”。

最多只能算内部 demo。

日志和复盘：不要只看能不能答

Dify Logs 文档说明，每次通过 Web App 或 API 的会话都会记录输入输出、时间数据和系统元数据；日志还能用于调试问题、收集用户反馈、查看 token 消耗和响应时间。

对卖家来说，日志不是后台装饰。

它是改进 Agent 的依据。

每周看 4 类问题：

1. 用户问了什么

有没有大量超出知识库范围的问题？

如果有，要补资料或改入口说明。

2. 检索错在哪里

是 metadata 不够？

是文档版本错？

是分块太粗？

是问题类型没识别？

3. 输出错在哪里

是语气不对？

是承诺过度？

是引用不足？

是建议不可执行？

4. 成本和速度是否可接受

响应慢，可能是节点太多、模型太贵、检索太宽、提示词太长。

Dify 日志里能看到 token、响应时间和错误，有助于优化。

注意：

Dify 日志可能包含完整对话和敏感信息。官方日志文档也提醒，需要实施访问控制并遵守隐私法规。

所以客服和订单相关 Agent 更要控制日志访问权限。

不要误读 Dify

第一，不用写太多代码，不等于不用设计流程。

Dify 让流程可视化，但流程本身仍然要有人设计。

第二，知识库不是网盘。

资料要清洗、标版本、做 metadata、测试检索。

第三，工作流跑通不等于结果可靠。

节点都绿了，只代表技术流程完成，不代表业务结论正确。

第四，Tool 和 HTTP Request 节点不是越多越好。

每接一个外部服务，就多一份权限、成本、错误和安全风险。

第五，Agent 节点不是万能。

Dify Agent 节点文档说明，它可以让 LLM 自主选择工具、迭代决定使用什么工具。但越自主，越需要限制工具、迭代次数、上下文和人工确认。

第六，发布不等于上线。

Dify 可以很快发布 Web App，但真正上线还需要访问控制、日志复盘、样本测试、负责人和回退方案。

结论

Dify 很适合跨境团队做第一批业务 Agent。

它让运营团队不用从零写系统，就能把知识库、提示词、工具和工作流组合成可重复的 AI 应用。

但 Dify 的正确用法不是“拖几个节点，全自动运营店铺”。

正确顺序是：

先选低风险场景。

再整理知识库。

再设计输入变量。

再搭最小流程。

再用历史样本测试。

再加人工确认。

最后小范围发布和看日志复盘。

Dify 的价值，是把团队已经验证过的运营经验，沉淀成可维护、可测试、可发布、可复盘的 AI 工作流。

当你把 SOP、知识库、节点、日志和人工确认点都做好，Dify 才是真正的业务 Agent 平台。

否则，它只是一个更漂亮的提示词画布。

资料来源与事实边界

本文核验日期为 2026-07-07。以下来源用于校准 Dify 的官方定位、知识库、工作流节点、Agent 节点、工具/API、发布、日志和隐私提示；跨境电商应用部分为基于卖家运营场景的业务推演和实操建议。

Dify 官网：Leading Agentic Workflow Builder。Dify 定位为开发、部署和管理 autonomous agents、RAG pipelines 和 agentic workflows 的平台。链接：https://dify.ai/
Dify Docs：30-Minute Quick Start。文档用示例说明如何创建 Workflow，并使用 User Input、Parameter Extractor、IF/ELSE、LLM、Iteration、Template、Output 等节点编排应用。链接：https://docs.dify.ai/en/quick-start
Dify Docs：Knowledge。文档说明 Knowledge 是可集成到 AI 应用中的自有数据集合，通过 RAG 为 LLM 提供领域上下文；也支持管理内容、测试检索、metadata 增强检索等。链接：https://docs.dify.ai/en/cloud/use-dify/knowledge/readme
Dify Docs：Knowledge Retrieval Node。文档说明 Knowledge Retrieval 节点用于从知识库检索相关内容，并可通过 metadata filtering 限制检索范围，提高大知识库或多场景下的精准度。链接：https://docs.dify.ai/en/cloud/use-dify/nodes/knowledge-retrieval
Dify Docs：LLM Node。文档说明 LLM 节点调用语言模型处理文本、图片和文档，支持结构化输出、上下文管理和多模态输入。链接：https://docs.dify.ai/en/cloud/use-dify/nodes/llm
Dify Docs：Agent Node。文档说明 Agent 节点让 LLM 自主控制工具，并可通过 Function Calling 或 ReAct 等策略迭代选择工具完成复杂任务，同时可设置最大迭代次数和记忆窗口。链接：https://docs.dify.ai/en/cloud/use-dify/nodes/agent
Dify Docs：Tool Node。文档说明 Tool Node 可以在 Workflow 中连接外部服务和 API，用于访问实时数据或执行内容处理。链接：https://docs.dify.ai/en/cloud/use-dify/nodes/tools
Dify Docs：HTTP Request Node。文档说明 HTTP Request 节点可以连接外部 API 和 Web 服务，用于获取数据、发送 webhook、上传文件或集成服务。链接：https://docs.dify.ai/en/cloud/use-dify/nodes/http-request
Dify Docs：Code Node。文档说明 Code 节点可执行 Python 或 JavaScript，用于复杂数据转换、计算和逻辑处理。链接：https://docs.dify.ai/en/cloud/use-dify/nodes/code
Dify Docs：User Input Node。文档说明 User Input 节点定义用户输入字段，每个字段会成为可被下游节点引用的变量。链接：https://docs.dify.ai/en/cloud/use-dify/nodes/user-input
Dify Docs：Template Node。文档说明 Template 节点使用 Jinja2 模板把多个来源的数据转换和格式化为结构化文本。链接：https://docs.dify.ai/en/cloud/use-dify/nodes/template
Dify Docs：Publish Overview。文档说明 Dify 应用可通过 Web App、API、Embed、MCP Server 等方式发布；发布会使 Web App 和 API endpoint 使用最新配置。链接：https://docs.dify.ai/en/cloud/use-dify/publish/README
Dify Docs：API。文档说明可通过 API 凭证把 Dify Workflow 集成到应用中，应用会提供与配置相关的 API 文档和示例。链接：https://docs.dify.ai/en/cloud/use-dify/publish/developing-with-apis
Dify Docs：Logs。文档说明 Web App 或 API 的会话会记录输入输出、时间数据、系统元数据、用户反馈、token 消耗和错误等；也提醒日志可能包含敏感信息，需要访问控制和隐私合规。链接：https://docs.dify.ai/en/cloud/use-dify/monitor/logs