Dify Plugin Daemon

Dify 生态中用 Go 写的插件守护进程，负责插件生命周期、进程管理、流式通信、Redis 协调与 serverless runtime；与 [[dify-source-reading|Dify 源码阅读]] 配套，是「Go 做稳定运行时协调」的范例。

#type / resource #status / growing #tech / dev / backend #resource / go

[!info] related notes

所属 MOC：源码阅读 MOC

兄弟仓库（Python+React 主体）：Dify 源码阅读

Go 工程风格参照：Ardan Labs Service

BodySense 对照：Go consultation API 的稳定 API / 并发 / 长连接 / 运行时协调

Dify Plugin Daemon

这是什么

Dify 生态里的 Go 守护进程，职责是与 Python AI 生态解耦的「运行时协调层」：

管理插件生命周期、进程；
处理流式通信（HTTP / TCP / stdin-stdout）；
通过 Redis 协调；
提供 serverless runtime；
用 uv 管理插件所需的 Python 环境。

它证明了「Go 做稳定 API、并发、长连接、运行时协调；Python 做模型、Agent、RAG」这种分工可以被真实产品落地。

在你三层参考架构里的位置

用户定位：React + Go + Python 三栈分工里，Go 那一层的范例。对应 BodySense 应让 Go 承担的「稳定 API / 并发 / 长连接 / 运行时协调」角色。与 ardanlabs-service 的 Go 工程风格可对照读。

版本快照

项	值
分支	`main`
commit	`6fde0a7fbdf8`（2026-08-07）
抓取日期	2026-08-11
语言	Go `1.26`（`go.mod`：`module github.com/langgenius/dify-plugin-daemon`，`go 1.26`）
运行时	用 `uv` 管理插件 Python 环境

仓库鸟瞰：顶层目录结构

dify-plugin-daemon/
├── cmd/                     # 入口：server / slim / commandline / codegen / license / tests
├── internal/                # 内部实现（不对外）
│   ├── cluster/             # 集群协调
│   ├── core/                # 核心：插件运行、调度
│   ├── db/                  # 元数据存储
│   ├── server/              # 服务装配与路由
│   ├── service/             # 业务服务
│   ├── storage/             # 存储
│   ├── tasks/               # 后台任务
│   └── types/               # 内部类型
├── pkg/                     # 可复用包
│   ├── bundle_packager/     # 插件包打包
│   ├── entities/            # 实体定义
│   ├── manifest/            # 插件 manifest 解析
│   ├── plugin_packager/     # 插件打包
│   ├── routine/             # 协程/运行时原语
│   ├── slim/                # slim 运行时
│   ├── utils/  validators/  license/
├── docker/                  # local.dockerfile / serverless.dockerfile
├── docs/                    # claude/ runtime/ 说明
├── integration/             # 集成测试（db / docker / plugin）
├── entrypoint.sh  go.mod  go.sum

顶层边界职责

顶层目录	回答什么问题	备注
`cmd/server/`	进程怎么起来	多个二进制入口
`internal/core/`	插件怎么被运行与调度	核心
`internal/cluster/`	多节点如何协调	Redis 协调在此
`pkg/manifest/` + `pkg/plugin_packager/`	插件如何定义与打包	契约设计
`pkg/routine/`	运行时并发原语	Go 并发模型落点
`internal/server/`	对外通信（HTTP/TCP）	与 Python 插件 runtime 对接

分层与依赖方向

flowchart TB
    CMD[cmd/server] --> SRV[internal/server]
    SRV --> CORE[internal/core 调度]
    CORE --> CLUSTER[internal/cluster Redis协调]
    CORE --> ROUTINE[pkg/routine 并发]
    CORE --> PKG[pkg/ manifest·packager·entities]
    CORE --> PY[Python 插件 runtime 通过 uv 拉起]

关键入口与调用链

入口	路径	说明
服务入口	`cmd/server/`	守护进程启动
核心调度	`internal/core/`	插件运行与生命周期
集群协调	`internal/cluster/`	Redis 协调、节点发现
契约	`pkg/manifest/`	插件 manifest 解析与校验

阅读路线

README.md 先看它如何用 uv 拉起 Python 插件环境（部署拓扑）
cmd/server/ → internal/server/ 看对外通信通道（HTTP / TCP / stdin-stdout）
internal/core/ 看插件生命周期与调度
internal/cluster/ 看 Redis 协调
pkg/routine/ 看并发原语

深挖一条线：一个插件从注册到被调用（Go 视角）

选「插件被加载、由 Go 拉起 Python 环境、最终被 Dify 调用执行」作为主线——它把 Go 的「稳定 API / 并发 / 长连接 / 运行时协调」职责落到一个具体对象生命周期上，正好对照 BodySense 的 Go consultation API 应扮演的角色。

cmd/server/                       守护进程启动
  → internal/server/              监听对外通道（HTTP / TCP）
  → internal/core/                插件生命周期：load → validate → spawn
       → pkg/manifest/            解析并校验插件 manifest（契约）
       → 用 uv 创建 Python 环境    拉起 Python 插件 runtime
            → 通信：stdin-stdout / TCP（待 README 确认）
       → internal/cluster/        Redis 协调、节点发现
       → pkg/routine/             并发原语（一个插件一次调用的协程模型）
  → Python 插件 runtime 执行 → 结果经通道回传 Go → 回传 Dify

跟读要点：

pkg/manifest/ 看插件「契约」如何被定义与校验（对照 BodySense 的插件/工具 schema）
internal/core/ 看生命周期状态机：一个插件从注册到就绪到被调用到卸载
internal/server/ 看 Go 与 Python 插件 runtime 之间的通信通道（HTTP / TCP / stdin-stdout，待验证）
internal/cluster/ 看多节点如何用 Redis 协调（Go 并发 + 分布式协调的落点）
pkg/routine/ 看并发原语，理解「一个插件一次调用」在 Go 里怎么被调度

自检：Go 在这里到底协调了什么、Python 只负责什么？BodySense 是否值得引入类似的「运行时协调层」隔离 Python LangGraph runtime？

值得偷师 / 不建议照抄

做法	评价	我的判断
Go 管进程/并发/长连接，Python 管模型	强	BodySense Go consultation API 可借鉴
`uv` 在 Go 侧管理 Python 环境	强	跨语言运行时协调的务实方案
`internal/` 与 `pkg/` 清晰分隔	强	Go 惯用布局
插件/多租户复杂度	弱	当前不需要，不抄

我的疑问与待验证

Go daemon 与 Python 插件 runtime 之间具体走 HTTP / TCP / stdin-stdout 哪几种？README.md 应能给权威答案（用户引用过其说明）。
BodySense 的 Go consultation API 是否值得引入类似的「运行时协调层」来隔离 Python LangGraph runtime？

Dify Plugin Daemon

Dify Plugin Daemon

这是什么

在你三层参考架构里的位置

版本快照

仓库鸟瞰：顶层目录结构

顶层边界职责

分层与依赖方向

关键入口与调用链

阅读路线

深挖一条线：一个插件从注册到被调用（Go 视角）

值得偷师 / 不建议照抄

我的疑问与待验证

沉淀出的笔记

相关链接 / 官方入口

入口	地址
仓库	https://github.com/langgenius/dify-plugin-daemon
说明	https://github.com/langgenius/dify-plugin-daemon/blob/main/README.md