Dify、Coze 与可视化编排

📅 发布于 2026-07-06

低代码 Agent 构建平台的两种路线

13.1 代码框架 vs 低代码平台

前面几章学的 LangGraph、AutoGen、CrewAI 都是代码框架——灵活但门槛高。不是所有团队都有工程师来写代码。低代码平台让非技术人员也能搭建 Agent：

代码框架

• LangGraph / AutoGen / CrewAI
• 完全灵活，可定制一切
• 需要 Python 工程能力
• 适合：复杂定制、生产级
• 部署：自己搭服务

低代码平台

• Dify / Coze / FastGPT
• 拖拽搭建，可视化配置
• 无需写代码
• 适合：快速原型、中小团队
• 部署：平台托管或自部署

13.2 Dify：开源 LLMOps 平台

Dify 是国内最火的开源 LLMOps 平台。它不仅是一个 Agent 构建工具，更是一个完整的 LLM 应用生命周期管理平台。

Dify 的核心能力

Prompt 工程：可视化 Prompt 编辑器，支持变量模板、版本管理、A/B 测试。

RAG 管道：内置完整的 RAG 流程：文档上传→分块→向量化→检索→生成。零配置可用。

Agent 构建：可视化编排 Agent 工作流，支持 ReAct、Function Calling、自定义工具。

模型管理：统一管理多个 LLM（OpenAI/Claude/通义千问等），一键切换。

监控分析：日志追踪、Token 统计、用户反馈收集、性能监控。

API 发布：一键发布为 API，支持 WebApp、API、Webhook 多种接入方式。

Dify 的应用类型

类型	说明	适用场景
Chatbot	对话型应用，多轮对话	客服、助手
Text Generator	单次生成，输入→输出	翻译、摘要、改写
Agent	自主 Agent，可调用工具	复杂任务、多步推理
Workflow	可视化工作流编排	固定流程自动化

13.3 Coze：字节跳动的 Bot 工厂

Coze（扣子） 是字节跳动推出的 AI Bot 构建平台。与 Dify 的"开发者工具"定位不同，Coze 更偏向"人人可用"：

Coze 的特色

零门槛：完全无代码，对话式配置 Bot。选模型、写 Prompt、加插件即可发布。

插件生态：内置 100+ 插件（搜索、画图、新闻等），也支持自定义插件。

多端发布：一键发布到飞书、微信公众号、抖音等平台。自带 Web 和 API。

工作流编排：可视化工作流，拖拽节点编排复杂逻辑。支持条件分支、循环。

Coze 的 Bot 结构

Coze Bot 配置结构
{
  "bot": {
    "name": "旅游规划助手",
    "description": "帮用户规划旅行行程",
    "model": "doubao-pro",          // 选择模型
    "prompt": "你是一个旅游规划专家...",
    "plugins": [                     // 插件
      "search",           // 搜索
      "weather",          // 天气
      "map"               // 地图
    ],
    "knowledge": [                   // 知识库
      { "type": "file", "file_id": "xxx" },
      { "type": "url", "url": "https://..." }
    ],
    "variables": [                   // 变量
      { "name": "budget", "type": "number" }
    ],
    "workflow": "workflow_id_xxx",   // 工作流
    "channels": [                    // 发布渠道
      "web", "feishu", "wechat"
    ]
  }
}

13.4 Dify vs Coze vs 代码框架

三种路线全面对比

对比项	代码框架 (LangGraph等)	Dify	Coze
技术门槛	高（需Python）	中（了解概念）	低（零代码）
灵活性	最高	中高	中
部署方式	自己部署	自部署/云服务	云服务（SaaS）
数据安全	完全自控	自部署可控	平台托管
开发速度	慢（天/周）	中（小时）	快（分钟）
成本	开发成本高	开源免费	免费+增值
适用团队	工程团队	技术团队	业务团队

选型建议：

• 要完全定制、数据敏感 → 代码框架
• 要快速搭建、可自部署 → Dify
• 要最快上线、面向消费者 → Coze

13.5 Dify 实战：工作流编排全流程

前面几节介绍了 Dify 和 Coze 的核心概念与对比，但真正上手搭建一个完整的 Agent 应用时，需要理解具体的操作步骤和配置细节。本节将以一个智能客服 Bot 为例，从知识库创建到 Chatflow 编排，再到 API 集成，完整走通 Dify 的开发全流程。

步骤一：创建知识库

在 Dify 控制台中，首先需要创建一个知识库（Knowledge Base），上传企业的 FAQ 文档、产品手册、服务条款等资料。Dify 会自动完成文档分块（Chunking）、向量化（Embedding）和索引构建。你可以选择不同的分块策略：按段落分块、按固定长度分块、或按自定义分隔符分块。对于客服场景，建议按段落分块，并设置 200-500 Token 的重叠区域，确保上下文完整性。

步骤二：编排 Chatflow

创建一个 Chatflow 类型的应用，进入可视化编排画布。一个典型的客服 Chatflow 包含以下节点：Start 节点接收用户输入 → Knowledge Retrieval 节点检索知识库 → LLM 节点结合检索结果生成回答 → Answer 节点输出响应。你还可以在中间插入条件分支节点，根据用户问题的类别路由到不同的处理流程。

Dify Chatflow 工作流编排示意图

Dify Chatflow 编排流程：知识库 + 条件分支 + LLM 生成

流程步骤：Start（用户输入）→ 知识库检索（Knowledge Retrieval）→ 条件分支（命中/未命中）→ LLM 结合上下文生成回答（命中时）或 兜底回复转人工（未命中时）→ 输出

虚线动画表示数据流向 — Start → 知识检索 → 条件路由 → LLM 生成 → 输出

步骤三：DSL 文件配置

Dify 支持将应用配置导出为 DSL（Domain Specific Language）文件，这是一种 YAML 格式的配置文件，描述了整个工作流的节点、边、变量和功能设置。DSL 文件可以用于版本管理、团队协作和迁移部署。以下是一个客服 Bot 的完整 DSL 配置示例：

# Dify DSL 配置文件（YAML 格式）
app:
  description: 客服问答 Bot
  icon: 🤖
  mode: advanced-chat
  name: customer-service-bot
  use_icon_as_answer_icon: false
kind: app
version: 0.1.0
workflow:
  conversation_variables: []
  environment_variables: []
  features:
    file_upload:
      allowed_file_extensions: [.pdf, .txt, .md]
      enabled: false
      fileUploadConfig:
        audio_file_size_limit: 50
        batch_count_limit: 5
        file_size_limit: 15
        image_file_size_limit: 10
        video_file_size_limit: 100
    opening_statement: 你好，我是智能客服。
    retriever_resource:
      enabled: true
    sensitive_word_avoidance:
      enabled: false
    speech_to_text:
      enabled: false
    suggested_questions: []
    suggested_questions_after_answer:
      enabled: true
    text_to_speech:
      enabled: false
  graph:
    edges:
      - data:
          sourceType: start
          targetType: knowledge-retrieval
        id: edge-001
        source: start
        target: knowledge_001
        type: custom
      - data:
          sourceType: knowledge-retrieval
          targetType: llm
        id: edge-002
        source: knowledge_001
        target: llm_001
        type: custom
    nodes:
      - data:
          type: start
          variables: []
        id: start
        type: custom
      - data:
          dataset_ids: ["dataset-xxx"]
          retrieval_mode: semantic
          top_k: 3
          type: knowledge-retrieval
        id: knowledge_001
        type: custom
      - data:
          prompt_template:
            - role: system
              text: 你是专业客服，基于以下知识库内容回答用户问题。如果知识库中没有相关信息，请如实告知。
          model:
            provider: openai
            name: gpt-4o-mini
            mode: chat
          type: llm
        id: llm_001
        type: custom

步骤四：API 集成

配置完成后，点击「发布」按钮即可将应用发布为 API。Dify 提供 RESTful API 接口，支持流式（SSE）和阻塞式两种响应模式。以下是使用 Python 调用 Dify API 的完整代码示例，包含流式响应处理和错误处理逻辑：

# Dify API 调用（Python 流式响应）
import requests
import json

DIFY_API = "https://api.dify.ai/v1"
API_KEY = "app-xxx"

headers = {
    "Authorization": f"Bearer {API_KEY}",
    "Content-Type": "application/json"
}

def chat(query, conversation_id="", user="user-001"):
    """调用 Dify Chatflow API，流式返回"""
    response = requests.post(
        f"{DIFY_API}/chat-messages",
        headers=headers,
        json={
            "inputs": {},
            "query": query,
            "response_mode": "streaming",
            "conversation_id": conversation_id,
            "user": user
        },
        stream=True,
        timeout=60
    )
    if response.status_code != 200:
        raise Exception(f"API 错误: {response.status_code} - {response.text}")
    full_answer = ""
    for line in response.iter_lines():
        if not line:
            continue
        data = line.decode("utf-8").lstrip("data: ")
        if data and data != "[DONE]":
            event = json.loads(data)
            if event.get("event") == "message":
                chunk = event.get("answer", "")
                full_answer += chunk
                print(chunk, end="", flush=True)
    return full_answer

if __name__ == "__main__":
    result = chat("如何使用 Dify 搭建客服机器人?")
    print(f"\n\n完整回复: {result}")

13.6 Coze 实战：Bot 开发与多 Agent 编排

Coze 作为字节跳动的 Bot 工厂，在多端发布和插件生态方面有独特优势。本节将详细介绍如何在 Coze 上创建一个功能完整的 Bot，包括插件配置、工作流编排，以及使用 Coze 的多 Agent 模式实现复杂的协作场景。

Bot 创建与插件配置

在 Coze 平台上创建 Bot 只需要四个步骤：第一步，点击「创建 Bot」，填写名称和描述；第二步，选择底层模型（如豆包 Pro、GPT-4o 等）；第三步，编写 System Prompt 定义 Bot 的人设和能力边界；第四步，添加插件和知识库。Coze 的插件市场提供了搜索、天气、新闻、画图、代码执行等 100+ 开箱即用的插件，勾选即可启用，无需编写任何代码。

Coze 的三层架构

理解 Coze Bot 的运行机制，需要把握其三层架构设计。触发层负责接收用户消息、定时任务和 Webhook 回调；决策层由 LLM 节点承担意图识别和路由选择的职责；执行层则包含插件调用、工作流执行、知识库检索和多 Agent 协作。这种分层设计使得每个层级可以独立配置和扩展。

Coze Bot 三层架构示意

Coze Bot 三层架构:
┌─────────────────────────────────────┐
│  触发层 (Trigger)                    │  用户消息、定时任务、Webhook
├─────────────────────────────────────┤
│  决策层 (Decision - LLM 节点)        │  意图识别 + 路由选择
│  ┌─────────┐  ┌──────────┐          │
│  │ 意图分类 │→│ 路由策略   │          │
│  └─────────┘  └──────────┘          │
├─────────────────────────────────────┤
│  执行层 (Execution)                  │
│  ┌──────┐ ┌────────┐ ┌───────────┐  │
│  │ 插件  │ │ 工作流  │ │ 知识库检索 │  │
│  └──────┘ └────────┘ └───────────┘  │
│  ┌──────────────────────────────┐   │
│  │  多 Agent 协作 (Multi-Agent)  │   │
│  └──────────────────────────────┘   │
└─────────────────────────────────────┘

# 路由示例: 根据意图分发到不同 Agent
routes:
  - intent: "技术问题"
    agent: "tech-support-agent"
    plugins: ["search", "code_runner"]
  - intent: "售后投诉"
    agent: "service-agent"
    plugins: ["ticket_system", "crm"]
  - intent: "产品咨询"
    agent: "sales-agent"
    plugins: ["product_catalog", "price_calculator"]

Coze 插件调用链路图

Coze 插件调用链路：用户消息 → LLM 决策 → 插件并行执行 → 结果聚合 → 多端输出

流程说明：用户消息 → Coze LLM（意图识别 + 路由）→ 并行执行搜索插件、天气插件、知识库检索、工作流执行 → 结果聚合生成回复 → 多端输出（Web、飞书、微信）

多 Agent 编排（Multi-Agent 模式）

Coze 的多 Agent 模式允许在一个 Bot 内部编排多个子 Agent，每个子 Agent 负责特定领域的任务。主 Agent 充当路由器角色，根据用户意图将请求分发给最合适的子 Agent。例如，一个企业级客服 Bot 可以包含技术支持 Agent、售后服务 Agent 和产品咨询 Agent，各子 Agent 拥有独立的 Prompt、插件和知识库，协同提供全方位服务。这种模式比单一 Agent 更精准，因为每个子 Agent 只需要关注自己的专业领域，Prompt 更聚焦，检索范围更小，回答质量更高。

# Coze 多 Agent 路由配置（伪代码）
# Coze Multi-Agent 路由配置
multi_agent:
  mode: "router"           # 路由模式
  router_model: "doubao-pro"  # 路由决策用的模型
  agents:
    - name: "tech-support"
      description: "处理技术问题、Bug 反馈、使用指导"
      model: "doubao-pro"
      prompt: "你是技术支持专家，擅长排查和解决技术问题..."
      plugins: ["search", "code_runner", "doc_search"]
      knowledge: ["tech-faq", "api-docs"]

    - name: "after-sales"
      description: "处理退换货、投诉、物流查询"
      model: "doubao-pro"
      prompt: "你是售后客服专家，耐心处理用户售后问题..."
      plugins: ["order_query", "logistics_track", "ticket_create"]
      knowledge: ["return-policy", "shipping-guide"]

    - name: "sales"
      description: "产品咨询、价格报价、优惠推荐"
      model: "doubao-pro"
      prompt: "你是销售顾问，热情介绍产品特点和优势..."
      plugins: ["product_catalog", "price_calc", "coupon_check"]
      knowledge: ["product-info", "promotion"]

  fallback: "通用回复: 抱歉，我无法处理此类问题，已为您转接人工客服。"

13.7 Dify vs Coze vs n8n 三方对比

在低代码自动化平台领域，除了 Dify 和 Coze 之外，n8n 也是一个经常被提及的工具。n8n 是一个开源的工作流自动化平台，虽然不是专门为 AI Agent 设计，但通过集成 LLM 节点也可以实现 Agent 工作流。三者各有定位和优势，理解它们的差异对于技术选型至关重要。

Dify vs Coze vs n8n 全面对比

对比维度	Dify	Coze	n8n
开源/闭源	开源 (Apache 2.0)	闭源 SaaS	开源 (Fair-code)
部署方式	Docker / 云服务	仅云服务	Docker / npm / 云服务
核心定位	LLMOps 平台	Bot 工厂	通用自动化平台
计费模式	开源免费 + 云服务按量	免费 + 增值功能	自部署免费 + 云服务按工作流
扩展性	自定义工具 + 插件	自定义插件 + API	自定义节点 + Webhook
学习曲线	中等（需理解 LLM 概念）	低（零代码）	中高（需理解自动化概念）
AI 原生支持	原生 AI 平台	原生 AI 平台	通过集成节点支持
适用企业类型	技术型中小团队	业务型任何团队	运维/集成团队

平台选型决策图

决策流程：

1. 需要搭建 AI Agent？（开始选型）
2. 数据需要自部署？
   • 是 → 团队有工程师？
     • 是 → Dify（自部署 + AI 原生）
     • 否 → n8n（通用自动化）
   • 否 → 需要多端发布？
     • 是 → Coze（零代码 + 多端）
     • 否 → Dify 云（快速上手）

决策路径：数据自控需求 → 团队技术能力 → 多端发布需求 → 最终选型

适用企业类型分析：

• Dify：适合有技术背景的中小团队，尤其是对数据安全有要求的金融、医疗、政务等行业的自建 AI 应用场景。
• Coze：适合业务驱动的团队和面向 C 端用户的产品，特别是需要快速在飞书、微信、抖音等社交平台发布 Bot 的运营和客服场景。
• n8n：适合有自动化需求的运维和集成团队，尤其是需要在 AI 之外还要对接 CRM、ERP、数据库等传统系统的复杂集成场景。n8n 的优势在于通用性，但 AI 能力不如前两者原生。

面试八股

Q：低代码 Agent 平台和代码框架各自的优势和劣势？

A： 代码框架（LangGraph/AutoGen）：优势=完全灵活、可定制一切、数据自控。劣势=门槛高、开发慢。 低代码平台（Dify/Coze）：优势=快速搭建、零代码/低代码、非技术人员可用。劣势=灵活性受限、平台依赖。

决策原则：复杂定制选代码框架，快速验证选低代码平台。

Q：Dify 的四种应用类型分别是什么？

A： Chatbot：对话型应用，多轮对话。适合客服、助手。 Text Generator：单次生成，输入→输出。适合翻译、摘要。 Agent：自主 Agent，可调用工具，多步推理。适合复杂任务。 Workflow：可视化工作流编排，固定流程自动化。适合自动化管道。

Q：Dify 和 Coze 的核心区别？

A： Dify：开源、可自部署、面向技术团队。定位是 LLMOps 平台，覆盖从开发到部署到监控的全生命周期。数据安全可控。 Coze：字节跳动 SaaS 平台、零代码、面向业务团队。定位是 Bot 工厂，一键发布到多端（飞书/微信/抖音）。开发最快但数据在平台。

要自部署和数据可控选 Dify，要最快上线选 Coze。

Q：什么场景适合用 Dify 而不是代码框架？

A： 适合 Dify 的场景：快速原型验证（小时级上线 vs 天级开发）；团队没有专职 Python 工程师；需要完整的 LLMOps（监控、日志、版本管理）；需要非技术人员参与 Agent 配置；需要快速切换不同 LLM 模型。

不适合 Dify 的场景：需要深度定制 Agent 行为、需要人工干预机制、需要复杂的图结构流程控制。

Q：Coze 的插件机制和传统 Function Calling 有什么区别？

A： Function Calling：开发者定义 JSON Schema，LLM 输出调用，框架执行。需要写代码。 Coze 插件：平台预置 100+ 插件（搜索、天气、画图等），在界面上勾选即可。也支持自定义插件（通过 API 描述自动生成）。

本质上都是 LLM 决定调用什么、框架执行。区别在于 Coze 把工具的创建和使用都可视化了，降低了门槛。

Q：Dify 和 Coze 的核心区别是什么？如何选型？

A： Dify 是开源 LLMOps 平台，支持 Docker 自部署，数据完全可控，面向有技术背景的团队。它覆盖了从 Prompt 工程到模型管理、从 RAG 管道到监控分析的完整生命周期。 Coze 是字节跳动的闭源 SaaS Bot 工厂，零代码配置，内置 100+ 插件，一键发布到飞书/微信/抖音等多端，面向业务团队。

选型原则：需要数据自控和自部署选 Dify；需要最快上线和多端发布选 Coze。如果是金融、医疗等合规要求高的行业，Dify 自部署是唯一选择。如果是运营活动、C 端客服等快速验证场景，Coze 更合适。

Q：Dify 的 Chatflow 和 Workflow 模式有什么区别？

A： Chatflow（高级对话模式）：支持多轮对话，维护会话上下文，适合需要交互式对话的场景如客服 Bot、助手。每个节点可以访问对话历史，支持在对话中动态调整流程。拥有开场白、推荐问题、语音转文字等对话增强功能。 Workflow（工作流模式）：单次执行，输入→处理→输出，不维护对话状态。适合固定流程的自动化任务如文档处理、数据抽取、批量翻译。每个请求独立执行，不依赖历史交互。

决策依据：需要多轮交互和上下文记忆选 Chatflow；一次性处理任务选 Workflow。

Q：Coze 的插件机制是怎么工作的？

A： Coze 的插件机制分为三个层次： 预置插件：平台内置 100+ 插件（搜索、天气、新闻、画图、代码执行等），在 Bot 编辑界面勾选即可启用，无需任何配置。 自定义插件：通过上传 OpenAPI Schema 或手动填写 API 描述来创建自定义插件。Coze 会自动解析 API 接口定义，生成可被 LLM 调用的工具描述。 插件调用流程：用户消息 → LLM 意图识别 → 判断需要调用哪些插件 → 并行或串行执行插件 → 获取插件返回结果 → LLM 结合结果生成最终回复。

本质上是 Function Calling 的可视化封装，但大大降低了工具创建和管理的门槛。

Q：Dify 的知识库检索用的是什么技术？

A： Dify 的 RAG 管道包含完整的技术链路： 文档处理：支持 PDF、Word、TXT、Markdown 等格式，自动进行文本清洗和分块（Chunking）。分块策略支持按段落、按固定长度、按自定义分隔符，可设置重叠区域保持上下文完整。 向量化：使用 Embedding 模型（如 OpenAI text-embedding-3-small、bge-large-zh 等）将文本块转换为向量。 向量存储：内置向量数据库支持（Weaviate、Qdrant、Milvus、PGVector 等），也可选择 Dify 托管的内建向量库。 检索策略：支持语义检索（Semantic Search）、全文检索（Full-text Search）和混合检索（Hybrid Search）。Top-K 可配置，默认返回最相关的 3-5 个文档块。 Rerank：可选的二次排序模型对检索结果重排，提升精度。

Q：企业选型 Dify 还是 Coze？关键考量因素有哪些？

A： 企业选型需要从五个维度综合评估： 数据安全：金融、医疗、政务等合规要求高的行业必须选 Dify 自部署，数据不能出内网。Coze 数据在字节跳动云端，不适合敏感场景。 团队能力：有技术团队的选 Dify（需要理解 Docker 部署和 LLM 概念），纯业务团队选 Coze（零代码）。 发布渠道：需要飞书/微信/抖音多端发布的选 Coze，需要 API/Webhook 集成的选 Dify。 定制深度：需要自定义工具、复杂工作流、多模型切换的选 Dify，标准化场景选 Coze。 预算：Dify 自部署免费（仅服务器成本），Coze 免费版有调用量限制，企业版需付费。长期大量调用时 Dify 自部署更经济。

课后练习

第 1 题（单选）

Dify 和 Coze 的核心定位区别是？

A. Dify面向消费者，Coze面向开发者 B. Dify是开源可自部署的LLMOps平台，Coze是SaaS Bot工厂 C. Dify只支持中文，Coze只支持英文 D. 两者完全一样

答案与解析

答案： B

解析： Dify 是开源 LLMOps 平台，可自部署，面向技术团队。Coze 是字节跳动的 SaaS Bot 工厂，零代码，面向业务团队。

第 2 题（单选）

Dify 的 Workflow 应用类型适合什么场景？

A. 多轮对话客服 B. 单次翻译生成 C. 可视化固定流程自动化 D. 自主探索性任务

答案与解析

答案： C

解析： Workflow 是可视化工作流编排，适合固定流程自动化。多轮对话用 Chatbot，单次生成用 Text Generator，自主任务用 Agent。

第 3 题（单选）

以下哪个不是 Coze 的特色？

A. 零代码配置 B. 100+内置插件 C. 一键发布多端 D. 完全自部署开源

答案与解析

答案： D

解析： Coze 是 SaaS 平台，不支持自部署。Dify 才是开源可自部署的。

第 4 题（单选）

需要数据完全自控的企业应该选择？

A. Coze B. Dify 云服务版 C. 代码框架 + 自部署 Dify D. 以上都不行

答案与解析

答案： C

解析： 数据完全自控需要代码框架（完全自主）或自部署 Dify（开源可控）。Coze 和 Dify 云服务版数据都在平台。

第 5 题（单选）

一个业务团队（无工程师）想快速搭建一个客服 Bot，最适合选择？

A. LangGraph 写代码 B. AutoGen 写代码 C. Coze 零代码搭建 D. 自己从零开发

答案与解析

答案： C

解析： 无工程师的业务团队最适合 Coze——零代码、拖拽配置、一键发布。分钟级上线。

第 6 题（多选）

以下哪些是 Dify 的核心能力？（多选）

A. 可视化 Prompt 工程 B. 内置 RAG 管道 C. Agent 工作流编排 D. GPU 训练集群管理

答案与解析

答案： A, B, C

解析： Dify 核心能力包括 Prompt 工程、RAG 管道、Agent 编排、模型管理、监控分析。不提供 GPU 训练集群管理。

第 7 题（多选）

选择 Agent 构建方案时，以下匹配正确的是？（多选）

A. 要完全定制 → 代码框架（LangGraph等） B. 要快速搭建且可自部署 → Dify C. 要最快上线且面向消费者 → Coze D. 所有团队都应该用代码框架

答案与解析

答案： A, B, C

解析： 没有万能方案。要定制选代码框架，要快速自部署选 Dify，要最快上线选 Coze。根据团队和需求选择。

第 8 题（多选）

关于 Coze 的插件机制，以下说法正确的是？（多选）

A. 平台预置 100+ 插件 B. 支持自定义插件 C. 插件本质上就是 Function Calling 的可视化封装 D. 插件只能用字节跳动的模型

答案与解析

答案： A, B, C

解析： Coze 插件本质上是 Function Calling 的可视化封装。支持预置和自定义插件，不限制模型选择。

第 9 题（单选）

Dify 的 DSL 文件使用什么格式？其主要用途是什么？

A. JSON 格式，用于模型配置 B. YAML 格式，用于描述工作流配置并支持版本管理和迁移部署 C. XML 格式，用于 UI 布局定义 D. CSV 格式，用于数据导入导出

答案与解析

答案： B

解析： Dify DSL 是 YAML 格式的工作流配置文件，描述节点、边、变量和功能设置，可用于版本管理、团队协作和迁移部署。

第 10 题（单选）

在 Dify API 调用中，response_mode 设为 "streaming" 表示什么？

A. 阻塞式响应，等待完整结果后返回 B. 流式响应（SSE），逐块返回生成内容 C. 同步响应，返回 JSON 对象 D. 批量响应，一次返回多条消息

答案与解析

答案： B

解析： streaming 模式使用 Server-Sent Events (SSE) 逐块返回生成内容，用户体验更好。blocking 模式则等待完整结果后一次性返回。

第 11 题（多选）

关于 Dify 的部署方式，以下说法正确的是？（多选）

A. Dify 支持 Docker Compose 自部署 B. Dify 提供官方云服务（dify.ai） C. Dify 只能部署在 AWS 上 D. Dify 自部署版本支持自定义向量数据库（如 Milvus、Qdrant）

答案与解析

答案： A, B, D

解析： Dify 支持 Docker Compose 自部署和官方云服务。自部署版本支持多种向量数据库后端（Weaviate、Qdrant、Milvus、PGVector 等），不限于特定云平台。

第 12 题（多选）

在 Coze 中配置多 Agent 模式时，以下哪些是正确的做法？（多选）

A. 主 Agent 负责意图识别和路由分发 B. 每个子 Agent 可以拥有独立的 Prompt 和插件 C. 子 Agent 必须使用相同的模型 D. 可以设置 fallback 兜底回复处理无法识别的意图

答案与解析

答案： A, B, D

解析： Coze 多 Agent 模式中，主 Agent 充当路由器，子 Agent 拥有独立配置（Prompt、插件、知识库、模型），支持 fallback 兜底。子 Agent 可以使用不同模型。

第 13 题（多选）

关于 Dify、Coze、n8n 三者的计费模式，以下说法正确的是？（多选）

A. Dify 自部署开源免费，云服务按量计费 B. Coze 提供免费版和增值功能 C. n8n 自部署免费，云服务按工作流执行量计费 D. 三者都必须付费才能使用

答案与解析

答案： A, B, C

解析： 三者都提供免费使用途径：Dify 开源自部署免费 + 云服务按量；Coze 免费 + 增值；n8n 自部署免费 + 云服务按工作流量。并非必须付费。