---

框架简述

最近一直在做大语言模型应用方向的项目，使用了 Dify 这个开源项目。Dify 是一个开源的端到端 LLM 应用平台，支持多种外置工具的集成。主要开发 LLM 对话/流应用，相对来说是一个低代码的、易上手框架。

其主要开发方式是绘制流程图进行低代码的工作，如果需要更为复杂的处理逻辑，则可以通过 代码执行(在流内执行一些简单的代码) 或是 外部工具(外部运行 Web 服务，Dify 内部作为“工具”进行 HTTP 请求) 实现。

这两者的主要区别在于：代码执行 节点只能进行受限的操作，是位于沙盒环境的，大部分底层操作都无法执行（常见的包括系统级别操作、文件系统操作、网络操作均被禁止），并且三方库包需要额外安装（安装到每个沙盒实例，即使节点不需要也是安装的），相对来说只适合执行一些无需三方库的简单操作（例如 JSON 解析）。

文章基于的 Dify 版本是 0.15.3 (截至撰稿已经出到了 1.1.0，需要注意版本 0 和版本 1 在工具架构上有较大改变，1.0以后的版本不能参考本篇)。

本文问题

不多废话，一句话解决：

外部端点定义

@PostMapping("/upload")
public ResponseEntity<Response> handlepload(@RequestParam("file") MultipartFile file) {
    // 业务逻辑
}

工具 OpenApi Schema

  // 省去前后内容
  "paths": {
    "/excel/upload": {
      "post": {
        "operationId": "上传文件",
        "requestBody": {
          "content": {
            "multipart/form-data; boundary=----WebKitFormBoundarysdhuifwRS:": {
              "schema": {
                "type": "object",
                "properties": {
                  "file": {
                    "type": "string",
                    "format": "binary",
                    "required": true,
                  }
                }
              }
            }
          }
        },
        "responses": {
          "200": {
            "description": "处理成功",
            "content": {
              "application/json": {
                "schema": {
                  "$ref": "#/components/schemas/GenerateResponse"
                }
              }
            }
          },
          "400": {
            "description": "文件格式错误或为空"
          },
          "500": {
            "description": "处理失败"
          }
        }
      }
    },
  }

注意 OpenApi 定义的请求体部分："multipart/form-data; boundary=----WebKitFormBoundarysdhuifwRS:" 这个键，通常来说定义应该是 "multipart/form-data"，boundary 边界应由请求工具库（httpx或其他）生成，但在 Dify 工具中必须手动指定边界，否则会发出一个无 boundary 的请求。