2026-01-19

发布时间 :
  1. 01月19日
    1. 一、今日完成情况
    2. 二、今日感悟
    3. 三、备注
    4. 四、AI工作流
      1. 1、dify和n8n对比
      2. 2、n8n要素–数据库：Supabase
      3. 3、n8n可以实现功能
    5. 五、Docker空间清理方法
    6. 六、Supabase数据库连接n8n工作流简单上手
      1. 1、目标梳理
      2. 2、项目开展：
        1. a、数据库代码配置
        2. b、创建密钥
        3. c、工作流测试
        4. d、问题列举
    7. 七、dify配置
      1. 1. 设置与模型供应商 (Settings & Model Provider) —— 工厂的动力源
      2. 2. 知识库 (Knowledge) —— 工厂的档案室 (RAG)
        1. 1. 知识库上传与限制
        2. 2. API 批量上传报错 (400)

01月19日

一、今日完成情况

  • n8n工作流初上手，分解一下上手任务 + 云端数据库简单跑项目快速上手 –完成
    • librechat 和 WeChat冗余的Docker数据进行清理，电脑内存不够的解决方法就是多清理，养成好习惯
    • 完成数据写入的工作流，接下来访问数据库是一个可以上手的新项目，都跑通了之后，就可以实现云端数据库了。
    • 导出一下问题笔记，防止未来配置再次报错。
  • 记忆承载、求实处、圆方你怎么看文章批量拉取，并且导入数据库 –已完成
  • 关注某科技大佬YouTube账号 https://www.youtube.com/watch?v=VyR8nqD3sQ8 英语听视频太慢了，搞个工作流把稿子弄下来，直接配合翻译软件看。

二、今日感悟

  • 核心业务数据​：
    • 两种AI流方案全部体验，未来都要好好上手，顺便学习云端AI数据库和向量数据库的配置。
    • 微信公众号批量导出并且保存，未来可以服务于我的知识库检索
  • ​今日工作总结：​
    • 今天一直在配置，如果熟练的话，工作流是非常快的，只是今天碰到很多低级的错误
  • ​明日工作计划：
    • n8n和dify进阶项目尝试，关于数据类型和模块工作内容都上手
    • mac运行项目的时候内存占用过多了，本来电脑有90GB，现在只有60GB了，要思考一下释放内存的问题。
  • ​今日学习成长：​
    • 唯手熟尔，慢慢来

三、备注

  • 无

四、AI工作流

1、dify和n8n对比

特性 n8n (自动化平台) Dify (LLMOps/AI 应用平台)
本质 iPaaS（集成平台即服务） LLMOps（大模型运营平台）
口号 连接万物，自动化一切。 快速构建、运营生成式 AI 应用。
侧重点 多系统联动。比如：收到邮件 $\to$ 存入数据库 $\to$ 发送通知。 AI 深度应用。比如：复杂提示词、知识库检索 (RAG)、智能体。
对国内支持 较弱，主要适配海外 SaaS（Slack/Notion）。 极强，原生支持所有国内主流模型和知识库处理。

n8n侧重于自动化办公，充当外交部长，设想这样的场景：

“我每天想自动抓取 B 站某个博主的视频标题，存到我的表格里，然后发个微信提醒我。” —— 重点在数据流转，AI 只是辅助。

dify侧重于内部联动，本地办公：

“我想把我的 Obsidian 笔记做成一个私有知识库，我问它问题，它要根据我的笔记回答我。” —— 重点在 AI 理解和知识库。

每日知识点：

  • n8n： 整个 n8n 的后端和节点开发都是用 TypeScript 写的（因为它足够稳定）。
  • LangChain.js： 你关注的 LangChain，其 JS 版本其实是用 TS 写的。
  • Model Context Protocol (MCP)： 你最近研究的 MCP，其官方提供的 SDK 大多也是 TS 优先。

现在的前端和后端开发（Node.js）已经形成了一个共识：“不写 TypeScript 的项目由于维护困难，通常活不长久。”

编译过程： 代码写的时候是 TS → 运行前需要一个“翻译”过程（编译） → 变成普通的 JS → 机器才能运行。

2、n8n要素–数据库：Supabase

举例：一个谷歌的云端数据库项目，就需要我把云端存储的文件向量化，保存到向量数据库当中，可是我如果没有向量数据库，就只能保存在本地的Docker上了，这样非常麻烦。

所以我需要学习一个中介，就是用户端和代码AI端的中间数据库来管理，也是我接下俩需要开的新坑，为什么我要开这个坑？

你现在有三个身份，Supabase 完美粘合了这三者：

  1. 作为 n8n 自动化玩家：

    • 痛点： 原生 PostgreSQL 只有数据库端口（5432），n8n 虽然能连，但有时候不够灵活。
    • Supabase 优势： 它会自动为你的数据库生成 RESTful API。这意味着你在 n8n 里既可以用 Postgres 节点（走数据库协议），也可以用 HTTP Request 节点（走 API 协议）来操作数据。这种灵活性是原生 Postgres 不具备的。

  2. 作为 Java 初学者：

    • Supabase 提供了标准的连接字符串（Connection String）。
    • 当你在 Java 代码里写 DriverManager.getConnection("jdbc:postgresql://...") 时，Java 根本不知道（也不在乎）对面是 Supabase 还是阿里云 RDS。
    • 结论： 你完全可以用 Java 标准的方式去连 Supabase，你学的 Java 数据库代码一行都不用改。

  3. 作为 AI 知识库构建者：

    • 就像之前提到的，Supabase 内置的 pgvector 让它可以直接存向量。如果你用原生 Postgres，你需要自己去编译安装这个插件，对于新手来说极其痛苦（涉及 Linux 编译环境）。Supabase 一键开启，帮你省去了环境配置的坑。

所以这个项目应该是属于当前行业内最热门，也是企业级使用的数据库项目，同时也满足我个人的AI学习和工具自动化的需求，以上三点解决了我的动机问题，接下里就是方法问题。

3、n8n可以实现功能

  • AI 辅助工作流：
    • 内容生成与摘要：结合 LLM（如您提到的 DeepSeek、GPT 等），n8n 可以自动生成文章摘要、邮件草稿、社交媒体帖子等。
    • 数据分析与洞察：将收集到的数据通过 n8n 发送给 AI 进行分析，提取趋势、模式或生成报告。
    • 智能客服与问答：构建基于知识库的智能问答系统，n8n 可以作为后端，处理用户请求，调用 AI 和知识库进行回复。
  • 自动化信息收集：
    • RSS Feed 聚合与处理：自动抓取您关注的博客、新闻网站的 RSS Feed，提取文章标题、链接、摘要等信息，并根据关键词进行筛选。
    • 社交媒体监控：设置 n8n 监控 Twitter、Reddit 等平台，当出现您关注的关键词、用户或话题时，自动通知您或将信息保存到数据库。

所以说，只要是实现一个对外交互的效果，面向社交媒体。下面我将看看dify可以如何对内优化我的工作模式。

五、Docker空间清理方法

列举出所有镜像：

docker images

删除不再被任何容器使用的镜像

# 删除 wechat-article-exporter 镜像
docker rmi ghcr.io/wechat-article/wechat-article-exporter:latest

# 删除 nginx 镜像
docker rmi nginx:alpine

清理悬空卷：

docker volume prune

然后再次需要重新构建即可。

关闭所有已经打开的项目：

docker stop $(docker ps -q)

六、Supabase数据库连接n8n工作流简单上手

1、目标梳理

长远来看，我将要实现这样的效果，就是实现云端AI问答数据库系统，而AI数据库是需要把文字内容（json、markdown、HTML）进行向量化的，向量化之后的内容是一定要存储在数据库当中的。

而我们平时云盘的设计，不是针对AI的向量存储，而是普通的文件存储，所以我将要设计一下系统，主要是三层。

存储层：存储文件，可能有几百G的各种离散文件。

向量层：向量数据库，也是设计在云端，用来存储我需要解析的云端文档。

本地层：我本地运行AI工作流，分别和向量层、中间层访问，AI可以读取向量层的数据帮我解决问题，AI工作流也可以帮我采集数据，写入存取层。

云端服务：

  • 触发器 (Trigger)： n8n 监听 Google Drive 的特定文件夹。一旦你往里面拖入 PDF/Word/Markdown，流程自动开始。
  • 下载与读取 (Download & Read)： n8n 使用 Google Drive 节点下载文件，并通过 Text Parser 节点提取其中的纯文本内容。
  • 切片 (Chunking)： 使用 n8n 的 Text Splitter，把几万字的长文切成一段段 500-1000 字的小块（为了符合 AI 的上下文窗口限制）。
  • 向量化 (Embedding)： （关键步骤） n8n 调用 Embedding API（如 OpenAI 或 DeepSeek 的 embedding 模型），把这些文字块转换成一串数字（向量）。
  • 存入向量库 (Upsert)： 将这些向量存入 Pinecone / Qdrant / Supabase（这些都有免费的云端层，不需要占用你的本地存储）。

本地服务

  • 你的提问： 你在 n8n 的 Chat 界面（或接入的微信/Telegram）输入问题。
  • 搜索 (Retrieval)： n8n 把你的问题也转换成向量，去云端的向量库里“搜”最相似的几段文字。
  • 生成 (Generation)： n8n 把搜到的文字片段 + 你的问题，打包发给 LLM（如 DeepSeek/GPT-4）。
  • 回复： LLM 根据你 Drive 里的资料回答你，并把答案传回给你。

一口气吃不成胖子，我的当务之急，就是快速上手这个数据库的使用，并且快速搭建n8n基础工作流的配置，两者都熟悉之后，打通双方的通讯，就算是成功。

2、项目开展：

a、数据库代码配置

使用sql语言在SQL editor当中撰写代码，创建数据表，用来存储向量数据，作为AI嵌入模型的向量数据库。

-- 1. 开启 pgvector 插件 (让 Postgres 能听懂向量)
create extension if not exists vector;

-- 2. 创建一个名为 'documents' 的表
create table documents (
  id bigserial primary key,
  content text, -- 存放原始文本
  metadata jsonb, -- 存放元数据（如来源、时间）
  embedding vector(1536) -- 存放向量数据 (注意：1536 是 OpenAI/DeepSeek-V3 的标准维度)
);

-- 3. 创建查询函数 (这是让 n8n 能调用的关键接口)
create or replace function match_documents (
  query_embedding vector(1536),
  match_threshold float,
  match_count int
)
returns table (
  id bigint,
  content text,
  metadata jsonb,
  similarity float
)
language plpgsql
as $$
begin
  return query
  select
    documents.id,
    documents.content,
    documents.metadata,
    1 - (documents.embedding <=> query_embedding) as similarity
  from documents
  where 1 - (documents.embedding <=> query_embedding) > match_threshold
  order by similarity desc
  limit match_count;
end;
$$;

如图所示，已经创建了这个名字为document的数据表。

Pasted image 20260119144523

b、创建密钥

这里有两个密钥可以选择，第一个密钥相当于酒店的“客房”，其他用户的APP可以访问，所以权限非常低。

第二个红框内的密钥优先级非常高，是管理员，所以使用红色标注，这是我链接自己本地的n8n使用的密钥。

Pasted image 20260119144910
  • 在 Supabase 点击 Project Settings (设置) -> API。
  • 复制 Project URL 和 anon / public Key。

public Key ：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6InB1bXJ6bXpucHpobXdzZWh2Z2VsIiwicm9sZSI6ImFub24iLCJpYXQiOjE3Njg3ODg1MTksImV4cCI6MjA4NDM2NDUxOX0.nDWdVv1RrOUpGohwdSoDWOHVd_elTwQkIKv82u9k-8I

Project URL： https://pumrzmznpzhmwsehvgel.supabase.co

c、工作流测试

在 n8n 创建一个新 Workflow，添加以下节点：

  1. Manual Trigger (手动触发)： 作为开始。

  2. Embeddings OpenAI (嵌入节点)：

    • 注意： 即使你用 DeepSeek，这里也通常选 OpenAI 节点（因为接口兼容），或者 n8n 如果有更新可以用通用 HTTP。
    • Model: 选择 text-embedding-3-small (或者你在 Credential 里配置 DeepSeek 的 Base URL 和 API Key)。
    • Mode: Run per item.

  3. Supabase Vector Store (关键节点)：

    • Operation: Upsert (插入或更新)。
    • Table Name: documents (刚才 SQL 建的那个表)。
    • ID Column: id。
    • Content Column: content。
    • Metadata Column: metadata。
    • Embedding Column: embedding。

n8n本地工作流访问端口：

 http://localhost:5678

AI agent配置：

如图所示，Source for Prompt (User Message)，这是 AI Agent 节点最关键的设置之一，决定了 AI 应该“听谁的话”。

Pasted image 20260119151845

选项 1：Connected Chat Trigger Node (推荐用于聊天机器人)

如果你希望在 n8n 提供的聊天窗口里直接跟 AI 对话，请选择这一项。

  • 原理：Agent 会自动寻找上游连接的 Chat Trigger 节点，并将你在聊天框里输入的文字作为 Prompt。
  • 前提条件：你必须在画布上先放一个 Chat Trigger 节点，并把它连到 AI Agent 的左侧输入口上。

选项 2：Define below (推荐用于自动化脚本)

如果你希望 AI 处理特定的、固定的数据（比如：总结一封邮件、翻译一段抓取到的网页文字），请选择这一项。

  • 操作：选择后，下方会出现一个 Prompt (User Message) 输入框。

  • 用法：

    • 静态文本：直接输入“请帮我总结这段话”。
    • 动态表达式：点击旁边的按钮，通过 &#123;&#123; $json.field_name &#125;&#125; 引用之前节点（如读取 Google Drive 的节点）产生的数据。

AI chat模型配置选项：

Require Specific Output Format (要求特定输出格式)

  • 含义：强制 AI 按照 JSON、列表或其他特定格式返回结果，而不是随便聊天。
  • 配置建议：目前先不要开启。除非你希望 AI 返回一个专门给代码处理的数据包。

Enable Fallback Model (启用备用模型)

  • 含义：当你的主模型（比如 DeepSeek）因为额度用完或网络波动报错时，自动切换到另一个模型（比如 Gemini）继续回答，防止流程中断。
  • 配置建议：建议在正式使用时开启。连接一个不同的服务商作为备份。

Options (选项)

  • 这是用来进一步细化行为的“调味料”。常见的有：
    • System Prompt：在这里输入“你是一个私人的助手…”，这是 AI 的人设指令。
    • Max Iterations：AI 在回答前可以查工具的最大次数。

AI agent Tools选项：

Pasted image 20260119153332
选项名称 它是干什么的？ 什么时候用？
Get ranked documents from vector store 纯查询。根据你的问题，从数据库里直接抓取最相关的 $N$ 条原始数据。 当你不需要 AI，只想在流程里获得匹配的文本列表时使用。
Add documents to vector store 存入数据。将文本内容转换成向量并存入 Supabase。 必选。在你之前的“知识喂入（Input）”流程中，必须用这个模式来存入数据。
Retrieve documents for Chain/Tool as Vector Store 链式检索。为“Question and Answer Chain”等非 Agent 节点提供数据。 当你使用简单的“问答链”而不是智能 Agent 时使用。
Retrieve documents for AI Agent as Tool 智能体工具。将向量库封装成一个 Agent 可以理解并主动调用的“技能”。 你现在的需求。配置 Agent 的知识检索能力时选这个。
Update vector store documents 更新数据。根据 ID 修改已经存入的文档内容。 当你的源文件（如 Google Drive 里的文件）发生变动，需要同步更新数据库时使用。

我们这里选择智能体工作，因为最终目的是让AI可以调用访问我的向量数据库，然后选择之后，需要配置刚才的API和网址：

Pasted image 20260119153517

然后需要设置数据库访问的基础配置：

option 选项

在 n8n 的 Supabase Vector Store 节点中，当你将其配置为 AI Agent 的工具（Retrieve Documents as Tool for AI Agent） 时，底部的 Options（选项）是用来微调 AI 如何与数据库交互的“高级开关”。

  1. Query Name (查询名称)
  • 意思：这是给这个查询操作起一个名字。它主要用于在 AI Agent 的推理日志中显示。
  • 应该选什么：如果你没有特殊的多个向量库同时查询的需求，可以不添加此项。
  • 什么时候用：如果你连接了多个不同的工具，给它起个名字（如 knowledge_base_search）可以让你在调试时更清楚 AI 到底调用了哪个工具。
  1. Metadata Filter (元数据过滤器)
  • 意思：这是用来限制搜索范围的“筛选器”。例如，你的数据库里存了 100 篇文档，你只想让 AI 在“分类是 Java”的文档里找答案。
  • 应该选什么：作为刚开始配置的小白，建议暂时不要添加。
  1. Description (工具描述) —— 非常重要！
  • 建议填入：这是一个包含 Kipley 个人笔记、Java 学习记录以及自动化项目信息的知识库。当用户询问关于这些话题的问题时，请查阅此工具。
  • 逻辑：AI 大脑会阅读这段话。如果你问它“天气怎么样”，它发现描述里没写有天气信息，就不会去翻 Supabase，从而节省你的 Token。
  1. Match Count (匹配条数)：
  • 建议设置：3 到 5。
  • 解释：每次搜索给 AI 几段参考资料。给太多会消耗 Token，太少则可能回答不全。
Pasted image 20260119154140

配置embedding的模型，使用硅基流动的中文语言嵌入模型，维度是1024，需要和数据表的维度匹配不然要报错：

Pasted image 20260119155959
  • 大脑 (AI Agent)：核心调度中心，负责接收你的指令并决定何时去翻阅资料。
  • 眼睛/耳朵 (Chat Trigger)：你对话的入口，Agent 从这里获取你的问题。
  • 逻辑/语言 (OpenAI Chat Model)：也就是你配置的硅基流动/DeepSeek，负责思考和组织语言。
  • 短期记忆 (Simple Memory)：负责记住你们刚才聊了什么，不会让你每句话都要重复背景。
  • 长期知识 (Supabase Vector Store)：你的私人图书馆。当它连接到 Agent 的 Tool 接口时，Agent 就学会了“查资料”这项技能。
  • 翻译官 (Embeddings OpenAI)：必不可少的插件，它把你的问题翻译成向量，这样才能在 Supabase 里找到匹配的知识。
Pasted image 20260119155921

以上是访问数据库的项目，可是现在我的数据库内部没有项目，所以需要进行简单的修改，利用 Supabase Vector Store 节点的“多功能性”：

切换 Action：将 Operation Mode 暂时从 Retrieve Documents 改为 Add documents to vector store

手动输入测试数据：

  • 在节点设置里找到 Document Content（或者在它左边连一个 Code 节点/Edit Fields 节点来提供数据）。
  • 填入内容：Java 是一门强类型语言，Kipley 认为学习它对理解 TypeScript 很有帮助。

Edit Fields：

基础配置：
Pasted image 20260119161847
Pasted image 20260119161804

模式 特点 适合场景
Manual Mapping (默认) 可视化填表。你可以点击 Add Field 按钮，通过图形化界面手动添加“字段名”和“值”。 最推荐小白使用。直观、不容易出错，适合手动输入少量测试数据。
JSON 代码模式。你需要写一段标准的 JSON 代码（例如 {"content": "..."}）来定义输出。 适合高级用户，或者当你需要一次性定义非常复杂、多层级的数据结构时。

第一步：配置 Edit Fields 节点

  1. 保持 Mode 为 Manual Mapping。
  2. 点击中间的红色文字 Add Field。
  3. 选择 String（字符串）类型
  4. Name 填入：content。
  5. Value 填入：你想让 AI 记住的内容（例如：Kipley 正在 MacBook 上用 Docker 跑 n8n）。
  6. 点击右上角的 Execute step。你会看到下方输出了一条包含 content 的数据。

第二步：连接并配置 Supabase 存储节点

  1. 确保你的 Supabase Vector Store 模式是 Insert Documents。
  2. 将 Edit Fields 节点的右侧连到 Supabase 节点的左侧（标注为 Document 的口）。
  3. 打开 Supabase 节点设置，在 Document Content 框中：
    • 点击旁边的 JS 或 Expression 图标。
    • 输入：&#123;&#123; $json.content &#125;&#125;。这表示“从上一个节点获取名为 content 的内容”。
Pasted image 20260119162204

这里的JSON格式可以自定义，表示写入数据库的内容，当然要符合数据表当中本来就定义的格式，点击运行之后就写入了数据表了：

Pasted image 20260119162236

现在启动，输入数据，刷新我的后台云数据库，可以发现已经把数据和向量化的文本写进去了，虽然期间我踩了很多坑，而且很多坑很可爱，一回生二回熟，下面应该会熟练很多了。

Pasted image 20260119164349
Pasted image 20260119164425
Pasted image 20260119164545

d、问题列举

问题如下：

  • Disabled 陷阱：如果节点显示 (Deactivated) 且提示 This node is disabled，说明它被禁用了。必须点击节点上方的电源图标重新激活，否则数据只是“路过”而不会被执行。

  • 维度匹配 (Dimension)：

    • BAAI/bge-m3 (硅基流动) → 1024 维度。
    • text-embedding-3-small (OpenAI) → 1536 维度。
    • 注意：SQL 建表语句中的维度必须与 Embedding 节点的模型维度严格一致。

  • 表达式映射：在存储时，Document Content 不能直接打字，必须用表达式 &#123;&#123; $json.content &#125;&#125; 引用上游数据。

  • 错误模型：触发器 → 数据库 → 数据源。这会导致数据库先运行，此时拿不到任何数据。

  • 正确模型：触发器 → 数据源 (Edit Fields/JSON) → 数据库 (Insert Mode)。

    • 核心准则：在 n8n 中，数据像水流一样从左向右流动。

最小架构：

  • 大脑：AI Agent (连接 Chat Model + Memory)。
  • 技能：Supabase Vector Store (设为 Retrieve 模式)。
  • 翻译：Embeddings OpenAI (挂载在 Supabase 节点下方)。

七、dify配置

Docker拉取之后，访问如下网址即可：

 http://localhost/install

1. 设置与模型供应商 (Settings & Model Provider) —— 工厂的动力源

这是你使用 Dify 的第一步。Dify 本身不生产模型，它需要你接入模型才能运转。

  • 功能： 管理所有的大模型（LLM）、嵌入模型（Embedding，用于知识库）、重排序模型（Rerank）。

  • 如何配置：

    • 点击右上角头像 -> 设置 -> 模型供应商。
    • 核心配置： 如果你同时也部署了 Ollama 或 vLLM 等本地模型，这里需要填写连接地址。
    • Docker 用户特别提示： 在 Docker 容器内访问宿主机的服务（如本地运行的 Ollama），地址通常不能写 localhost，而要写 http://host.docker.internal:11434。

2. 知识库 (Knowledge) —— 工厂的档案室 (RAG)

这里是存放你私有数据的地方。当你需要 AI 回答“我不懂但文件里有”的问题时使用。

  • 功能： 上传文档（PDF, TXT, MD 等），Dify 会自动清洗、分段（Chunking）并建立索引。

  • 如何配置：

    • 点击顶部 “知识库” -> 创建知识库。
    • 上传文件 -> 选择分段设置（建议初学者选“自动”）-> 选择索引方式（“高质量”需要 Embedding 模型，“经济”使用关键词匹配）。
    • 宏观理解： 建好后，它只是一个数据库。你需要在“工作室”里把它关联到具体的应用上，AI 才能读取。

现在的问题是，一次只能上传四个文件，无论是什么格式的，而我批量公众号下载，是上千个文件，因此不可能使用传统手段一次一次尝试的。

方案一：化整为零法（CSV 整合）—— 强烈推荐

现在可以使用脚本的方式，把所有内容放在同一个csv文件当中，可是效果不太理想，因为这样每次我需要上传了都要重新运行一下脚本，理想当中，是把可以把文件夹当中的所有文件批量上传，因此看到下一个方案。

方案二：API 自动化法（Python 脚本）—— 一劳永逸

Pasted image 20260119195703

每个创建的知识库当中，都可以手动配置API，可以利用这个机制批量导入，写个 Python 循环，遍历本地文件夹，调用 /v1/datasets/{dataset_id}/document/create_by_file 接口。喝杯咖啡的功夫，就全部导入了，这个是我理想当中的方法。

Pasted image 20260119202702

代码文件，批量导入文件：

main 1

目前遇到的问题和解决方案如下：

1. 知识库上传与限制

  • 前端上传限制：Dify 网页端单次批量上传限制为 5 个文件，每个不超过 15MB。
  • 批量处理策略：对于上千份公众号文章，推荐将数据整合为 CSV 格式上传，或使用 Dataset API 编写 Python 脚本进行自动化批量处理。
  • 索引模式不可逆：知识库创建后，无法从“高质量模式（High Quality）”直接降级修改为“快捷模式（Economical）”，需新建知识库重新选择。

2. API 批量上传报错 (400)

  • 报错现象：上传时返回 indexing_technique is required 错误
  • 根本原因：文件名包含中文、特殊字符或过长，导致 HTTP 请求头解析异常，后续参数无法被服务器正确读取， 而且还包括数据库的配置问题，向量解析模型没有配置就无法导入，我配置好第一个文件和嵌入模型之后，就可以导入了。
  • 解决方案：在传输层使用纯 ASCII 安全文件名（如 temp.md），而在 Dify 业务层参数 name 中保留原始中文名；同时采用强制有序的 Multipart 传输。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 kipleyarch@gmail.com

浙ICP备2025181060号-2 © litearch

Built with Hexo and 3-hexo theme

Obsidian