给 Dify 贡献一个开源插件:解决多 Agent 协作统一入口的问题

AI 智能体定制开发 / 落地咨询 ｜ 微信 zhaochanggeng_sz ｜ 手机 13632907315

一、读完你能拿走什么

先说背景，不铺垫。

我在项目里需要一个能力：让一个 Dify 工作流调用另一个 Dify 应用，并把对方的回答边生成边透传出来。

第一反应是找现成的。插件市场翻了，GitHub 搜了，社区帖也看了——找了一圈，没有。

于是我自己写了一个：400 行代码、8 个文件、15.9 KB，只依赖 dify_plugin 和 httpx。写完我想，这个问题这么具体、又这么普遍，需要它的人应该不止我一个，那就开源出来（MIT），谁需要谁拿走。

项目名 stream-proxy，仓库：fhqtayvw/dify-plugin-stream-proxy。

读完你能拿走两样东西：

1. 为什么 Dify 会缺这一环，它给用户造成的是什么体感；
2. 自己写的时候踩到的 4 个坑，其中240 秒读超时官方文档里几乎查不到。

二、缺的是哪一环：用户盯着白屏的那 30 秒

场景是用 Dify 搭「路由应用」（也叫统一入口，多 Agent 协作的典型形态）：一个应用识别用户意图，再分发给背后的多个专家应用。

卡在分发这一步：Dify 内置的 HTTP 请求节点打的是外部接口，而平台没有受支持的方式，让一个工作流调用另一个 Dify 应用并流式透传。

于是路由只能这么干：发请求 → 干等专家应用全部跑完 → 把整段回答一次性吐出来。

用户的体感是：

• 提问之后界面一片空白；
• 应用生成 30 秒，用户就盯白屏 30 秒；
• 打字机效果消失，用户以为系统挂了。

用一句话总结：一个「实时」的 AI 应用，退化成了「点提交、转圈、出结果」的老式网页。

我要的就是这一环——消费子应用的 SSE 流，收到一片就转发一片：

不流式：  [==== 等待 30s ====][整段回答] 流式：    [字][字][字][字][字][字][字]...

看到这里如果觉得有用，顺手点个「在看」；这类 Dify 实战我每周写三篇，想持续看的可以关注我。

三、给老板的一页纸摘要

如果你的技术负责人把这篇转给你，看这一段就够：

一句话：花的是 1 天接入时间，换的是「AI 应用看起来是不是实时」。

四、自己写的时候踩到的 4 个坑，第 1 个几乎没人写过

坑 1：240 秒那堵墙

Dify 的 plugin daemon 对非 LLM 的反向调用有一条写死的读取时限，从请求发起算起：

DIFY_BACKWARDS_INVOCATION_READ_TIMEOUT   # 默认 240000 ms

到点后响应体会被直接关闭，抛出 use of closed network connection。

这个报错极具误导性——看起来像网络问题，实际是平台层的超时。

插件的处理不是抛异常，而是吞掉它，用手上已累积到的内容正常收尾。理由有两条：

1. 超时触发时，子应用的回答通常已经全量流出，只是流尾被掐；
2. 更关键——异常一旦抛出，工具节点会 FAIL，那么路由里写会话变量的下游节点就不会执行，下一轮会复用过期的 conversation_id，产生更隐蔽的 bug。

所以：吞掉异常不是偷懒，是为了保住会话状态。

坑 2：零输出时，用户看到白屏连「出错了」都不知道

子应用 FAILED，或流在第一个文本到达前就断了，这两种情况下一个 message 事件都没有：工具输出是空字符串，用户看到一片空白。

解法是严格的零输出兜底：只在零输出时补一句人话，已经流出内容的一律不动。这里有个刻意的克制——没把「截断提示」也加进去，因为已流出的内容仍有价值。

坑 3：不需要目标应用的 API Key

反直觉但重要：插件走的是平台内部反向调用，不是外部 HTTP，所以不需要目标应用的 Service API key，只要 app_id。代价是目标应用必须和调用方在同一个 Dify 实例内。

清理开源代码时，我还删掉了一个声明为「必填」却从未被代码读取的 api_key 参数——它只会让 LLM 每轮传一个被丢弃的值。

坑 4：Dify 的 i18n 只认 4 种语言

插件 SDK 里的 I18nObject 是严格四字段模型：zh_Hans / pt_BR / ja_JP / en_US。写第 5 种（比如 fr_FR）不会报错，会被静默丢弃。 我原本打算堆 20 个 locale，翻了 SDK 源码后收手。

另一个坑：工具运行时拿不到用户的 locale，语言只能做成配置项。

五、最后说一句

开源它的理由很朴素：我需要它，却找不到现成的；写完之后我觉得，需要它的人不会只有我一个。

它解决的问题很具体——「应用调应用，而且流式」。Dify 把工作流、知识库、智能体都做得很完整，唯独这一环空着。

建议收藏这篇：下次接路由应用前，按「填 app_id → 流式消费 → 零输出兜底 → 240 秒超时」检查一遍。

如果你身边有人用 Dify 搭路由应用，把这篇转给他，可能比你用上更有价值。插件刚发 v0.2.0，目前 star 是 0——不是它不好用，是只有真正撞上这个需求的人才会搜到。如果你撞上了，欢迎来提 Issue；如果它替你省了时间，一个 star 就是对我最实在的反馈。

关注我，每周三篇 AI 落地实战。 这个号只写我跑通过的东西：Dify 插件与应用架构、AI 智能体的工程决策、私有化部署的选型与成本。关注之后，这三类内容你能持续拿到，也方便回看历史。

关于作者

图灵学徒，24 年软件开发与团队管理经验，曾任职头部企业技术管理岗位，长期深耕工业互联网与 AI 工程化，专注企业智能体落地与制造业数智化。

这个公众号记录一个 24 年老兵 All in AI 创业的实战、思考与踩坑。如果你在探索：企业里的 AI 智能体怎么搭、私有化部署怎么落地、业务系统怎么和模型结合——欢迎加我微信交流。

微信号：zhaochanggeng_sz（添加请备注「公众号」，我会优先通过）

手机：13632907315