Chatflow Invoker更新：让Dify支持跨平台Agent调用

Chatflow Invoker发布以来，收到了不少用户的关注与反馈，说明该插件在实际使用中确实解决了部分痛点问题。感谢所有提供意见的用户，这些反馈为后续版本的优化提供了重要参考。

今天正式推出 Chatflow Invoker v0.0.4版本，带来了多项重要更新功能。下面一起看看这次的更新有哪些内容吧。

0.1 支持节点报错信息回显

新版本支持了Chatflow的报错回显，方便定位问题。

0.2 支持非流式输出

支持了非流式方式输出，可以通过stream_output来获取流式输出结果，text字段获取非流式输出结果。

0.3 支持会话记忆功能

为了在 Dify 中实现多轮会话的记忆保持，在后续对话中需要传入同一个 conversation_id。需要注意的是，这个 conversation_id 并不能自行生成，而必须使用首次调用会话时由 Dify 返回的值。

因此，要实现记忆功能，就需要在本地维护一份 conversation_id 的映射关系。

由于 Dify 插件机制的生命周期限制，无法依赖类变量来持久保存数据，所以必须选择一个可长期存储的介质。

在查阅 Dify 的插件文档时，发现Dify提供了用于存储键值数据的接口，可以满足这一需求：

https://docs.dify.ai/zh-hans/plugins/schema-definition/persistent-storage

在进一步分析源码的过程中，发现官方接口文档存在一定的缺漏。除了文档中列出的方法外，其实还提供了一个用于判断指定键（key）是否存在的接口。

.venv/Lib/site-packages/dify_plugin/invocations/storage.py

梳理一下维护conversation_id的整体流程如下：

这里搞一个简单的验证测试（注意要在被调用的Chatflow中开启记忆功能）

把Keep Conversation这里设置为True，然后进行多次会话

从第二次的返回中可以看到，我们已经实现了上下文对话记忆的功能。

0.4 支持跨平台Agent调用

在 Multi‑Agent 的开发过程中，你是否遇到过这些问题：

1. Dify 的编排功能虽然能满足大多数场景，但在某些特殊情况下，你必须用代码 SDK 来开发 Agent。那么这些定制化的 Agent 该如何在 Dify 中对接调用？
2. 在团队分工合作时，不同人可能使用不同的平台或框架来实现 Agent，那又该如何在 Dify 上进行统一的管理？

如果不需要流式输出，其实可以让对方提供一个API接口，Dify侧直接通过 HTTP请求节点 进行调用，或者将 Agent 发布为 MCP 工具后录入Dify。但这样的问题是会失去流式输出的效果，对于控制台对话等需要即时响应的场景，会明显影响用户体验。

为了解决这一痛点，我开发了一个通用的流式接口调用工具。无论是模型、Agent、Workflow 还是 Chatflow，无论它诞生于哪个平台、采用哪种 SDK，只要它提供流式输出接口，就能无缝接入 Dify，同时保留流式输出的效果，实现 Dify 对所有 Agent 的 统一管理与调用。

其中比较推荐的方式是在Agent侧提供一个OpenAI格式的接口，工具里已经内置好了OpenAI格式的调用模板。

0.4.1 Dify调用OpenAI格式的Agent

在这里我模拟了一个用LangGraph开发的Agent，同时让Cursor帮我实现了一个OpenAI格式的流式接口。

将URL填入，其余地方不用修改，保存并执行。

可以看到已经成功调用了LangGraph的Agent，并且同时支持流式输出。

0.4.2 Dify调用百炼Agent

并不局限于OpenAI，对非OpenAI格式的流式输出Agent，插件也可以兼容。

以百炼为例，演示如何对接一种新的输出格式的Agent

这里在百炼上开发了一个简单的应用，除了query，还接收一个name参数。

根据百炼的文档，我们找到流式输出的curl命令：https://help.aliyun.com/zh/model-studio/invoke-workflow-application

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

curl --location 'https://dashscope.aliyuncs.com/api/v1/apps/YOUR_APP_ID/completion' \
--header 'X-DashScope-SSE: enable' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer $DASHSCOPE_API_KEY' \
--data '{
    "input": {
        "prompt": "你是谁？"
    },
    "parameters":  {
        "flow_stream_mode": "message_format"
    },
    "debug": {}
}'

构造对应的调用参数：

1

https://dashscope.aliyuncs.com/api/v1/apps/xxx/completion

1
2
3
4

{
    "Authorization": "Bearer sk-xxx",
    "X-DashScope-SSE": "enable"
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
    "input": {
        "prompt": "{{#sys.query#}}",
        "biz_params": {"name": "yzddmr6"}
    },
    "parameters": {
        "flow_stream_mode": "message_format"
    },
    "debug": {}
}

以及获取对应的响应示例，编写对应的的Json Path

1
2
3
4

id:1
event:result
:HTTP_STATUS/200
data:{"output":{"session_id":"0a6aff53d8e945e4900452f04d55499b","workflow_message":{"node_status":"executing","node_type":"End","node_msg_seq_id":1,"node_name":"结束","message":{"content":"我是通义千问","role":"assistant"},"node_is_completed":false,"node_id":"End_7w1V"},"finish_reason":"null"},"usage":{},"request_id":"88878d48-097f-99c3-b6b9-b76f7366da90"}

成功调用百炼应用并实现流式输出

0.5 最后

有些同学可能会问：为什么不反过来，用代码 SDK 去管理 Dify 的 Agent，而要让 Dify 来统一管理所有 Agent 呢？

原因主要有两点：

首先，在开发水平参差不齐的团队里，如果所有人都用纯代码方式开发，代码质量很容易失控——屎山叠屎山，维护成本越来越高，最终只能推倒重来。

其次，Dify 本身已经具备完善的可观测性、调试工具、问题追踪以及插件扩展能力，这些都是开箱即用的，不需要重复造轮子。同时，Dify 中的各个组件都是标准化模块，在多人协作中天然具备优势，能轻松实现统一管理、统一鉴权等功能，大幅降低协作和运维的复杂度。

现在，Dify支持了任意跨平台Agent的调用之后，可以同时兼顾开发效率与扩展性：在常规场景下，直接在 Dify 上完成开发即可；而在需要高度定制的特殊场景中，则可以使用代码 SDK 自行实现 Agent，再通过本插件接入 Dify，实现无缝整合。

最近，Dify 推出了 Knowledge Pipeline 功能，带来了更丰富、更灵活的数据处理能力，真的是越来越强大、越来越好了。作为开发者，这里也有两点期望，希望 Dify 能在未来的迭代中进一步优化：

1. 重视稳定性

Dify 对新技术和新能力的支持速度非常快，版本迭代堪比生产队的驴。但高速迭代难免会带来更多稳定性风险，因此建议在新版本发布前官方要进行充分的自动化功能回测，避免因 BUG 影响用户的业务稳定性。

其实，本次插件的更新思路很早就有了，但由于 Dify 1.8.x 版本存在较为严重的 BUG，一直无法正常使用，所以迟迟没有发布。直到 1.9.x 版本推出并确认已修复该问题，才继续完成开发并发布。因此，建议 Dify 在版本迭代时增加稳定性保障机制，同时提醒正在使用的伙伴们及时升级到最新版本。

2. 为插件开放更加灵活丰富的交互接口

Dify 的插件系统功能非常强大，但在交互灵活性上还有提升空间。以这次新增的通用Chatflow调用为例，理想状态是内置若干常用模板，同时支持用户自定义填写并保存。然而当前插件机制暂不支持 “下拉选择切换 + 保存自定义输入” 这种交互方式。

此外，Tool 类型插件 目前依然不支持 app-selector 类型，这意味着在调用本地 Chatflow 时仍需手动填写 APP ID。希望未来 Dify 能开放更灵活丰富的交互接口，让社区开发者的创造力得到最大程度发挥。

如果对插件有好的建议，欢迎留言反馈。

Github地址如下，欢迎Star：

https://github.com/yzddmr6/chatflow_invoker