Dify + DeepSeek 智能 Agent 应用开发实战：从工作流编排到智能体部署全流程

引言

随着大语言模型能力的飞速提升，将 LLM 集成到实际业务应用中已成为开发者们最迫切的需求。然而，直接调用 API 构建应用面临着提示词管理、上下文控制、工具调用、知识库集成等一系列复杂挑战。

Dify 作为一款开源的 LLM 应用开发平台，通过可视化的工作流编排、丰富的工具集成和灵活的智能体（Agent）框架，大幅降低了 AI 应用的门槛。而 DeepSeek 系列模型凭借其卓越的推理能力和极具竞争力的价格，正在成为 Dify 平台上最受欢迎的模型选择之一。

本文将手把手带你走完从 Dify 环境搭建到 DeepSeek 驱动的智能 Agent 应用开发的全流程，涵盖工作流设计、工具调用、知识库集成、多 Agent 协作等核心能力。无论你是想搭建智能客服、自动化文档处理流程，还是复杂的多步推理应用，这篇文章都能给你完整的实战指引。

一、Dify 与 DeepSeek：为什么是黄金组合？

1.1 Dify 的核心能力

Dify 的价值不在于"又一个 LLM 前端"，而在于它提供了一整套应用开发基础设施：

应用类型支持： – 对话助手（Chat Assistant）：最基础的对话式应用，支持提示词变量、上下文管理和对话历史 – 文本生成器（Text Generator）：面向内容创作的批量生成，支持模板化输出 – 智能体（Agent）：具备工具调用、任务规划和多步推理能力 – 工作流（Workflow）：可视化编排多步处理流程，支持条件分支、循环、代码执行等 – RAG 应用：集成知识库的检索增强生成应用

全方位能力矩阵： – 多模型管理（OpenAI、DeepSeek、Claude、本地模型等） – 知识库（文档上传、分段、向量化、检索） – 工具链（内置工具 + 自定义 API 工具 + 插件） – 监控与日志（调用记录、成本追踪、性能分析） – API 输出（通过 API 将 AI 能力嵌入自有系统）

1.2 DeepSeek 在 Dify 上的独特优势

Dify 官方已经原生支持 DeepSeek 模型接入，这背后有几个关键优势：

推理能力突出：DeepSeek-R1 在数学推理、代码生成和逻辑分析任务上的表现已接近 GPT-4 水平，而成本仅为后者的 1/10 左右。

长上下文支持：DeepSeek-V3 支持 128K Token 的上下文窗口，在处理长文档分析、代码仓库理解等场景时优势明显。

MoE 架构高效：虽然总参数量达 671B，但 DeepSeek 每次推理只激活约 37B 参数，这意味着在相同硬件条件下可以承载更大的并发量。

中文生态优化：DeepSeek 的中文理解能力天然优于同规模的海外模型，在处理中文文档、知识库问答等场景时更加自然准确。

1.3 部署方式选择

在 Dify 中集成 DeepSeek 有三种主流方式：

对于大多数开发者来说，建议从官方 API 或 MaaS 开始，在生产规模扩大后再考虑自部署方案。

二、环境搭建：Dify 部署与 DeepSeek 模型接入

2.1 Dify 本地部署

Dify 提供了非常完善的 Docker Compose 部署方案，几分钟即可完成环境搭建：

# 克隆 Dify 仓库
git clone https://github.com/langgenius/dify.git
cd dify/docker

# 复制环境变量配置
cp .env.example .env

# 启动所有服务（后端 + 前端 + 数据库 + 向量存储）
docker compose up -d

# 验证服务状态
docker compose ps

部署完成后，访问 http://localhost:3000 即可进入 Dify 的控制台界面。

2.2 华为云 MaaS 部署 DeepSeek 推理服务

如果选择通过华为云 MaaS 部署，流程更加便捷：

# 通过 MaaS API 创建推理服务
curl -X POST https://maas-api.huaweicloud.com/v1/services \\
-H "Authorization: Bearer ${MAAS_API_KEY}" \\
-H "Content-Type: application/json" \\
-d '{
"name": "deepseek-v3-chat",
"model": "deepseek-ai/DeepSeek-V3-Chat",
"engine": "vllm",
"instance_type": "flexus-x-2p",
"instance_count": 1,
"tensor_parallel_size": 4,
"quantization": "gptq",
"max_model_len": 16384
}'

部署完成后，MaaS 会返回一个标准的 OpenAI 兼容 API 端点，可以直接配置到 Dify 中。

2.3 在 Dify 中配置 DeepSeek 模型

进入 Dify 设置 → 模型供应商 → DeepSeek：

# 配置信息
API Endpoint: https://api.deepseek.com/v1
# 或华为云MaaS: https://maas-api.huaweicloud.com/v1

API Key: sk-xxxxxxxxxxxxxxxxxxxx

# 模型列表
支持的模型:
– deepseek-chat # DeepSeek-V3 对话模型
– deepseek-reasoner # DeepSeek-R1 推理模型
– deepseek-coder # DeepSeek-Coder 代码模型（可选）

# 高级配置
Context Size: 128000 # 上下文窗口
Max Tokens: 8192 # 最大生成长度
Vision Support: true # 视觉能力（部分模型）

三、基础应用：构建智能对话助手

3.1 提示词工程的最佳实践

在 Dify 中构建对话助手，首要做的是设计高质量的系统提示词。以下是一个面向技术支持的智能助手模板：

# 系统提示词模板
name: "技术智能助手"
description: "基于 DeepSeek 驱动的技术问答与支持系统"

variables:
– name: "user_level"
type: "select"
options: ["初级", "中级", "高级"]
default: "中级"
– name: "company_knowledge"
type: "string"
description: "企业背景信息"

system_prompt: |
你是「{{company_knowledge}}」的技术支持专家，使用 DeepSeek 模型驱动。

## 角色定位
你是一位经验丰富的技术工程师，擅长解决复杂技术问题。
你的回答风格应当:
1. 专业准确 — 引用具体技术细节，不做模糊表述
2. 用户适配 — 根据用户等级（{{user_level}}）调整讲解深度
3. 结构清晰 — 使用编号、小标题等方式组织复杂回答
4. 实践导向 — 给出可执行的具体方案而非空洞建议

## 回答规范
– 对于初级用户：侧重概念解释和原理说明，适当类比
– 对于中级用户：提供具体操作步骤和最佳实践
– 对于高级用户：讨论架构选择、性能优化和底层原理
– 当用户问及已有知识库的内容时：必须优先从知识库检索

## 约束
– 不要编造不存在的技术细节
– 当不确定时，明确告诉用户"这个问题需要进一步验证"
– 不要主动推荐特定商业产品
– 所有代码示例必须真实兼容

3.2 对话流程配置

在 Dify 的对话助手配置中，打开以下增强设置：

# 对话增强设置
opening_statement: |
👋 你好！我是技术智能助手，可以帮你解答技术问题、分析代码、排查故障。
请问今天有什么可以帮你的？

# 建议问题（让用户更快上手）
suggested_questions:
– "如何优化 API 响应时间？"
– "解释一下 Kubernetes 的 Pod 调度原理"
– "帮我排查这段代码的内存泄漏问题"

# 对话变量
speech_to_text: false # 支持语音输入（可选）
text_to_speech: false # 支持语音输出

# 上下文设置
dialogue_number: 6 # 保留最近 6 轮对话
remember_session: true # 跨会话记忆

3.3 提示词优化的核心技巧

在实际使用中发现，DeepSeek 模型对结构化提示词的响应质量明显高于平铺直叙的提示。以下是几个经过验证的优化技巧：

技巧一：使用 Markdown 格式结构

DeepSeek 的训练数据中包含大量 Markdown 格式的文档，因此用 Markdown 组织提示词的章节、标题和列表，模型能更好地理解和遵循指令：

## 任务描述
你需要完成以下工作…

## 输入数据
– 数据来源：用户提问
– 数据格式：纯文本

## 输出要求
– 格式：JSON
– 必须包含字段：code, message, data

技巧二：Few-Shot 示例

在提示词中加入 2-3 个输入输出示例，能极大提升 DeepSeek 的输出一致性：

# Few-Shot 示例配置
examples:
– input: "API 返回 503 错误"
output: |
**问题诊断**：503 Service Unavailable
**可能原因**：
1. 服务过载，超出连接池上限
2. 上游服务宕机，网关无法转发
**解决方案**：
– 检查服务器负载：`top -H`
– 查看应用日志：`journalctl -u your-service`
– 扩容处理
– input: "数据库查询特别慢"
output: |
**问题诊断**：慢查询
**分析步骤**：
1. 开启慢查询日志并分析
2. 检查索引使用情况
3. 使用 EXPLAIN 分析执行计划

四、智能 Agent：让 AI 具备工具调用能力

4.1 Agent 模式的工作原理

Dify 的 Agent 模式基于 ReAct（Reasoning + Acting）框架，核心流程如下：

用户输入 → 理解意图 → 思考推理 → 选择工具 → 执行工具 → 分析结果 → 得出结论 → 回复用户
↓
（多步循环，直到任务完成）

DeepSeek 在 Agent 模式下的优势尤为突出： – 推理链路清晰：DeepSeek-R1 的 Chain-of-Thought 能力让它能自主规划多步执行路径 – 工具识别准确：在大量代码数据上训练，对函数/工具描述的理解更加精准 – 错误恢复能力强：当某一步工具调用失败时，能自主调整策略重试

4.2 内置工具集成实战

Dify 提供了丰富的内置工具，以下是几个最实用的场景：

代码执行器（Code Interpreter）

# 代码执行器配置
type: code_interpreter
language: python
sandbox: true
timeout: 30

# 应用场景举例
prompt: |
用户提供了一个包含销售数据的 CSV 文件，请：
1. 用 Python 读取并解析数据
2. 计算月度销售总额和环比增长率
3. 用 Matplotlib 生成可视化图表

搜索引擎

# 搜索引擎配置
type: web_search
provider: searxng # 或 google/bing
max_results: 5
timeout: 10

prompt: |
用户询问最新的技术趋势，请：
1. 搜索相关关键词获取最新信息
2. 从至少 3 个来源交叉验证
3. 整理成结构化摘要返回

API 调用器

# API 工具配置
type: api_tool
endpoint: https://api.example.com/v1/data
method: GET
headers:
Authorization: "Bearer {{api_key}}"

prompt: |
用户需要查询实时数据，请通过 API 获取并分析结果。
如果 API 返回错误，尝试分析错误原因并给出用户合理的建议。

4.3 自定义工具开发

除了内置工具，Dify 还支持开发者自定义工具，通过 OpenAPI/Swagger 规范或手动配置实现：

# 自定义工具：天气查询
name: "weather_query"
description: "查询指定城市的实时天气信息"
parameters:
– name: "city"
type: "string"
required: true
description: "城市名称（中文）"
– name: "unit"
type: "string"
enum: ["celsius", "fahrenheit"]
default: "celsius"

# 自定义工具：数据库查询
name: "db_query"
description: "执行 SQL 查询并返回结果（只读）"
parameters:
– name: "sql"
type: "string"
required: true
description: "只读 SQL 查询语句"

工具开发最佳实践：

4.4 构建复杂 Agent 工作流

Dify 的工作流编排支持将多个 Agent 步骤串联起来，实现复杂的业务流程。以下是一个技术工单自动处理工作流：

name: "技术工单自动处理"
description: "自动分析用户提交的技术工单，分类、排查、生成解决方案"

nodes:
# 节点 1: 意图识别
– id: "intent_classifier"
type: "llm"
model: "deepseek-chat"
prompt: |
识别用户问题的类型，从以下分类中选择：
– 故障排查
– 功能咨询
– 代码审查
– 性能优化
– 架构设计

用户问题：{{input}}

# 节点 2: 知识库检索
– id: "knowledge_retrieval"
type: "knowledge_retrieval"
condition: "{{intent_classifier.output}} == 故障排查"
top_k: 3
query: "{{input}}"

# 节点 3: 代码分析与修复
– id: "code_analysis"
type: "code_executor"
condition: "{{intent_classifier.output}} == 代码审查"
code: |
```python
import ast
import inspect

def analyze_code(code_snippet):
"""分析代码中的潜在问题"""
issues = []
tree = ast.parse(code_snippet)

for node in ast.walk(tree):
# 检查未捕获的异常
if isinstance(node, ast.Call):
# 分析调用是否存在风险
pass

return issues
```

# 节点 4: 综合回答生成
– id: "response_generator"
type: "llm"
model: "deepseek-reasoner"
prompt: |
根据以下信息生成详细的技术回答：
用户问题：{{input}}
问题分类：{{intent_classifier.output}}
检索结果：{{knowledge_retrieval.output}}
代码分析：{{code_analysis.output}}

请给出结构化、可操作的解决方案。

五、知识库集成：构建企业级 RAG 应用

5.1 知识库构建流程

Dify 的知识库功能支持多种文档格式和分段策略：

# 知识库配置
name: "技术文档库"
description: "包含产品文档、FAQ、技术手册等"
embedding_model: "text-embedding-ada-002" # 或 deepseek-embedding

# 分段策略
chunk_strategy:
mode: "auto" # 自动/手动分段
max_chunk_size: 1000 # 每段最大字符数
overlap: 200 # 段落重叠字符数
separator: "\\n\\n" # 段落分隔符

# 索引模式
index_mode: "quality" # quality（高质量）/ economy（经济型）

# 检索配置
retrieval_strategy:
mode: "hybrid" # 混合检索（向量+关键词）
top_k: 3
score_threshold: 0.7 # 相似度阈值

5.2 文档预处理最佳实践

知识库的检索质量很大程度上取决于文档的预处理质量：

# 文档预处理流水线
def preprocess_document(file_path):
"""文档预处理流程"""
import re
from langchain.text_splitter import MarkdownTextSplitter

# 1. 读取原始文档
with open(file_path, 'r', encoding='utf-8') as f:
content = f.read()

# 2. 清理无意义的重复内容
content = re.sub(r'\\n{3,}', '\\n\\n', content)
content = re.sub(r'[ \\t]+', ' ', content)

# 3. 结构化分段（保留 Markdown 标题层级）
splitter = MarkdownTextSplitter(
chunk_size=1000,
chunk_overlap=200,
)
chunks = splitter.split_text(content)

# 4. 为每个分段添加元数据
processed_chunks = []
for i, chunk in enumerate(chunks):
processed_chunks.append({
"id": f"chunk_{i:04d}",
"content": chunk,
"metadata": {
"source": file_path,
"chunk_index": i,
"length": len(chunk),
}
})

return processed_chunks

文档分段策略选择建议：

5.3 RAG 检索策略优化

在实际应用中，单一的向量检索往往不够完善。Dify 支持多种检索策略的组合：

# 高级检索策略配置
retrieval:
strategy: "multi_path" # 多路召回策略

# 路径 1: 语义向量检索
vector_search:
enabled: true
top_k: 3
score_threshold: 0.75

# 路径 2: 关键词 BM25 检索
keyword_search:
enabled: true
top_k: 2
analyzer: "jieba" # 中文分词器

# 路径 3: 重排序精排
rerank:
enabled: true
model: "bge-reranker-v2-m3"
top_k: 3

# 结果融合策略
fusion:
method: "reciprocal_rank_fusion" # 倒数排名融合
weights: [0.6, 0.3, 0.1] # 向量/关键词/重排序权重

多路召回的核心原理： – 语义向量检索：捕捉语义相似性，但对关键词不敏感 – 关键词 BM25 检索：精确匹配关键词，但无法处理同义词 – 重排序精排：用 Cross-Encoder 级联精排，提升前 10 结果的质量

三者互补，可以显著提升检索的召回率和准确率。

5.4 对话中的知识库调用优化

在 Agent 或对话助手场景中，知识库的调用时机和频率同样关键：

# 知识库调用优化配置
knowledge:
# 主动检索（每次对话都检索）
always_retrieve: false

# 自动触发（根据对话上下文判断是否需要检索）
auto_retrieve:
enabled: true
trigger: "semantic_gap" # 检测语义差距
threshold: 0.65 # 低于此阈值才检索

# 上下文压缩（减少检索结果的 Token 消耗）
context_compression:
enabled: true
max_chars: 3000 # 压缩后最大字符数
strategy: "extractive" # 抽取式压缩

# 引用溯源
citation:
enabled: true
style: "inline" # 行内引用
format: "[来源: {{doc_name}}, 第{{chunk_index}}段]"

实战经验：在 DeepSeek-R1 上使用 RAG 时，建议将知识库内容放在提示词的前半部分（系统提示词区域），因为 DeepSeek 的训练数据中，事实性内容通常在文档前部。同时，DeepSeek 对带有 [] 标记的引用格式响应友好，会自然在回答中引用知识来源。

六、多 Agent 协作：构建自动化工作流

6.1 Agent 工作流模式

Dify 的工作流支持多种 Agent 协作模式：

串行模式：

# Agent A → Agent B → Agent C
# 适合流程固定的业务场景

nodes:
– id: "input_analyzer"
type: "agent"
description: "分析用户输入，提取关键信息"

– id: "data_retriever"
type: "agent"
tools: ["knowledge_search", "web_search"]
description: "基于分析结果检索相关信息"

– id: "response_builder"
type: "agent"
description: "整合所有信息生成最终回答"

并行模式：

# Agent A → Agent B, Agent C（同时执行）
# 适合同步处理多项独立任务

nodes:
– id: "task_splitter"
type: "llm"
prompt: "将用户请求分解为可以并行处理的子任务"

– id: "code_review"
type: "agent"
parallel: true
tools: ["code_executor"]

– id: "doc_search"
type: "agent"
parallel: true
tools: ["knowledge_search"]

– id: "merger"
type: "llm"
prompt: "合并 code_review 和 doc_search 的结果"

条件分支模式：

# 根据条件选择不同的处理路径

nodes:
– id: "router"
type: "llm"
prompt: "根据用户请求类型路由到对应的处理分支"
output_format: "enum:tech_support|business|general"

– id: "tech_handler"
type: "agent"
condition: "{{router.output}} == tech_support"
tools: ["code_executor", "knowledge_search"]

– id: "business_handler"
type: "agent"
condition: "{{router.output}} == business"
tools: ["api_tool", "web_search"]

6.2 实战：自动代码审查 Agent

下面是一个完整的自动代码审查 Agent 工作流实现：

name: "CodeReview Agent"
description: "自动审查 Pull Request 代码质量"

variables:
– name: "pr_content"
type: "file"
description: "待审查的代码文件内容"
– name: "language"
type: "select"
options: ["Python", "JavaScript", "Java", "Go"]
default: "Python"

nodes:
# 步骤 1：代码静态分析
– id: "static_analysis"
type: "code_executor"
inputs:
language: "{{language}}"
code: "{{pr_content}}"
prompt: |
使用 Python 的 ast 模块分析代码结构，检查：
– 未使用的 import
– 过长函数（>50行）
– 复杂度过高的函数
– 缺少类型注解
– 魔法数字

# 步骤 2：安全检查
– id: "security_scan"
type: "llm"
model: "deepseek-reasoner"
inputs:
code: "{{pr_content}}"
static_issues: "{{static_analysis.output}}"
prompt: |
作为一个安全专家，审查以下代码中是否存在安全风险：

### 代码
{{code}}

### 静态分析结果
{{static_issues}}

请检查：
1. SQL 注入风险
2. XSS 漏洞
3. 路径遍历风险
4. 敏感信息泄露
5. 命令注入风险

对每个风险给出：风险等级（高/中/低）、影响描述、修复建议。

# 步骤 3：最佳实践评估
– id: "best_practices"
type: "llm"
model: "deepseek-chat"
inputs:
code: "{{pr_content}}"
language: "{{language}}"
prompt: |
作为一个 {{language}} 高级工程师，评估代码是否遵循了以下最佳实践：
1. 命名规范
2. 错误处理完整性
3. 日志记录充分性
4. 测试覆盖率
5. 文档完整性

给出改进建议。

# 步骤 4：生成综合报告
– id: "report_generator"
type: "llm"
model: "deepseek-chat"
inputs:
static: "{{static_analysis.output}}"
security: "{{security_scan.output}}"
practices: "{{best_practices.output}}"
prompt: |
综合以下三个维度的审查结果，生成一份结构化的代码审查报告：

### 静态分析结果
{{static}}

### 安全检查结果
{{security}}

### 最佳实践评估
{{practices}}

报告格式：
## 代码审查报告

### 总体评分（A/B/C/D）
### 关键发现（按严重程度排序）
### 各维度详细分析
### 改进建议（按优先级排序）
### 总结

6.3 性能监控与优化

部署 Agent 应用后，持续监控和优化是提升用户体验的关键：

# Dify 监控配置
monitoring:
# 性能指标
metrics:
– name: "avg_response_time"
alert_threshold: 5000 # ms
– name: "token_consumption"
alert_threshold: 10000
– name: "tool_call_success_rate"
alert_threshold: 0.95
– name: "knowledge_retrieval_quality"
alert_threshold: 0.8

# 日志记录
logging:
level: "info"
retention_days: 30
include_prompts: false # 是否记录完整提示词

# 成本追踪
cost_tracking:
enabled: true
monthly_budget: 1000 # 美元
per_request_limit: 0.5 # 美元

常见问题排查：

七、生产部署与最佳实践

7.1 高可用部署架构

当 Dify 应用从原型进入生产环境时，需要关注以下部署架构：

# Docker Compose 生产环境配置
version: "3.8"

services:
# API 服务（水平扩展的关键）
api:
image: langgenius/dify-api:latest
deploy:
replicas: 3 # 多副本
resources:
limits:
cpus: "4"
memory: "8G"

# Worker（异步任务处理）
worker:
image: langgenius/dify-api:latest
command: celery -A app.celery worker
deploy:
replicas: 2
resources:
limits:
cpus: "2"
memory: "4G"

# 前端（Nginx 反向代理）
web:
image: langgenius/dify-web:latest
deploy:
replicas: 2

# PostgreSQL 数据库
db:
image: postgres:15
volumes:
– db_data:/var/lib/postgresql/data
deploy:
resources:
limits:
cpus: "4"
memory: "8G"

# Redis 缓存与消息队列
redis:
image: redis:7-alpine
volumes:
– redis_data:/data

# Weaviate 向量数据库
vector_store:
image: semitechnologies/weaviate:latest
environment:
AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: "false"
PERSISTENCE_DATA_PATH: "/var/lib/weaviate"
volumes:
– weaviate_data:/var/lib/weaviate

# Nginx 反向代理
nginx:
image: nginx:alpine
ports:
– "443:443"
volumes:
– ./nginx.conf:/etc/nginx/nginx.conf
– ./ssl:/etc/nginx/ssl

7.2 成本优化策略

在生产环境中，LLM API 调用成本是最主要的开销之一。以下策略可以有效降低成本：

缓存策略：

# 语义缓存配置
semantic_cache:
enabled: true
provider: "redis"
similarity_threshold: 0.95 # 语义相似度阈值
ttl: 3600 # 缓存 TTL（秒）
max_size: 10000 # 最大缓存条目数

# 触发条件
condition:
– type: "exact_match" # 完全相同的输入
– type: "semantic_match" # 语义相似度高于阈值
– type: "template_match" # 匹配预设模板（如天气查询模板）

请求批处理：

# 将多条独立的 LLM 请求合并为一次批处理
from dify.app import LLMBatchProcessor

processor = LLMBatchProcessor(
model="deepseek-chat",
max_batch_size=10, # 每批次最多 10 条请求
max_wait_time=500, # 最长等待 500ms 凑足批次
)

# 自动批处理
results = await processor.process_batch([
{"prompt": "解释什么是微服务", "user_id": "A"},
{"prompt": "解释什么是容器化", "user_id": "B"},
{"prompt": "解释什么是 Serverless", "user_id": "C"},
])

模型降级策略：

# 多模型降级配置
model_routing:
primary: "deepseek-reasoner" # 默认使用最强模型
fallback: "deepseek-chat" # 降级到一般模型
emergency: "gpt-3.5-turbo" # 紧急降级

# 降级条件
conditions:
– metric: "response_time"
threshold: 8000 # 响应超过 8s 时降级
action: "fallback"
– metric: "error_rate"
threshold: 0.05 # 错误率超过 5% 时降级
action: "fallback"
– metric: "cost_per_request"
threshold: 0.05 # 单次请求成本超过 $0.05
action: "emergency"

7.3 数据安全与合规

在将 DeepSeek 集成到企业应用中，需要重视以下安全考量：

# 安全配置
security:
# 内容过滤
content_filter:
enabled: true
mode: "moderation"
categories:
– "hate"
– "violence"
– "sexual"
– "self-harm"

# 数据脱敏
data_masking:
enabled: true
patterns:
– type: "phone" # 手机号脱敏
regex: "1[3-9]\\\\d{9}"
replacement: "1*******"
– type: "email" # 邮箱脱敏
regex: "\\\\w+@\\\\w+\\\\.\\\\w+"
replacement: "***@***"
– type: "id_card" # 身份证脱敏
regex: "\\\\d{17}[\\\\dxX]"
replacement: "*************"

# 审计日志
audit:
enabled: true
events:
– "user_login"
– "api_call"
– "knowledge_base_access"
– "tool_execution"
retention_days: 180

八、总结与展望

本文从 Dify 的基础部署到高级 Agent 工作流编排，详细介绍了如何将 DeepSeek 模型集成到实际 AI 应用中。核心要点总结如下：

随着 DeepSeek 新版本的持续迭代和 Dify 社区生态的不断丰富，两者的结合将开箱即用地解决更多真实世界的问题。无论你是独立开发者还是企业团队，现在就是开始用 Dify + DeepSeek 构建 AI 应用的最佳时机。

参考资源： – Dify 官方文档：https://docs.dify.ai – DeepSeek API 文档：https://platform.deepseek.com/docs – 华为云 MaaS 产品页：https://www.huaweicloud.com/product/maas.html – Dify GitHub 仓库：https://github.com/langgenius/dify – 🔥 DeepSeek 实战指南系列：提示词工程与 API 集成全攻略

本文由 CSDN 写手原创，专注于 AI 应用开发与大模型工程技术。如有技术问题，欢迎在评论区讨论交流。