关于整合Coze/Dify工作流作为小智插件能力的架构设计与意见征集

[Eric0308]

背景与目标
近期团队在探索如何将Coze、Dify等平台的LLM能力更灵活地整合到小智的对话系统中，目标是实现以下功能：

1. 多工作流动态调度：支持将不同Coze/Dify工作流（如八字排盘、视频生成）作为独立插件能力，由主LLM根据意图识别动态调用。
2. 异步任务处理：针对耗时任务（如生成视频），设计任务队列和异步通知机制，避免用户长时间等待。
3. 统一接口管理：将Coze/Dify降级为“工具链”，由主LLM统一调度Function Call和IoT请求，保持架构清晰。

---

当前设计方案

1. 意图识别与路由

   • 主LLM通过预注册的意图标签（如“#八字排盘”“#视频生成”）判断是否触发Coze/Dify工作流。
   • 每个工作流对应一个独立的能力插件，类似HAILM的插件化设计。

2. 异步任务流程

   graph LR  
   A[用户请求] --> B{主LLM识别为异步任务}  
   B -- 是 --> C[返回“任务已提交”并生成任务ID]  
   C --> D[后台队列处理]  
   D --> E[完成时通过推送/消息通知用户]  
   B -- 否 --> F[同步返回结果]  
   

   Loading

3. 多平台协作示例

   • 用户问：“帮我算一下生辰八字” → 主LLM识别为#八字排盘 → 调用Dify工作流A。
   • 用户问：“用今日热点生成视频” → 主LLM识别为#视频生成 → 调用Coze工作流B并异步响应。

---

需收集的意见

1. 使用场景：

   • 你希望Coze/Dify在小智中解决哪些具体问题？（如智能家居控制、个性化内容生成等）
   • 是否有现有功能无法满足的痛点？

2. 技术体验：

   • 对异步任务的通知方式偏好（应用内消息/邮件/短信等）。
   • 是否需要任务进度查询功能？

3. 协作流程：

   • 若你的团队已使用Coze/Dify，希望如何与小智现有能力结合？

---

后续计划
根据反馈优化设计，目标2周内输出详细技术方案。欢迎所有相关同事参与讨论！

---

讨论回复

• 直接回复本贴，或联系@John/@eric 单独沟通。
• 重点需求可附使用案例说明。

示例回复格式

【场景】希望用Dify实现XX功能，目前遇到XX问题。  
【建议】异步通知最好支持XX方式，因为XX。  

[liuwangbless]

感觉 直接接 dify 易用性好一些 llm 再分发增加了一些复杂度 建议保留Dify条线 不影响自己想用LLM调用Dify的用户 留着Dify是留着简单的无限扩展空间

[nef1983]

【场景】希望用Dify实现本地化的知识库+聊天助手+小智AI&ESP32结合，实现基于本地知识库的语音对话及基本的IoT功能。
目前遇到本地化调用Dify时，意图识别有问题，function_call控制Iot音量、亮度等功能不能识别。
【建议】
1、如果保留dify支持，希望能解决意图识别控制IoT音量、亮度问题
2、如果抛弃dify，希望小智自身能实现灵活配置本地化的知识库、模型、工作流（代替Dify的功能）

[tokenComment]

感觉多模态的控制可以实现，不过这个有些复杂，应该是未来的发展方向

[nathubs]

建议保留DIFI、coze做为LLM。1.虽然这几个从接口不支持Toolcalling，但可以从平台层动态扩展更多工具，如天气、时间、长期记忆、RAG等等，这些都是便于从用户的角度扩展可玩性，对用户友好;2.如果降级作为工具链，极大程度限制了这些平台的扩展功能，而写调用效率会更低更耗时

[hsguyue]

在针对ha智能家居控制部分

如果使用OpenAI Conversation，HA方面基本需求都能满足。但是意图识别准确度和延迟是个问题
使用Function Call 只支持简单的命令，需要开发的内容较多，比如代办事项、自动化意图

还是希望通过Function Call 方式，问题主要是开发部分较多，要匹配HA的大部分应用场景，但是可以一步步来

[CaixyPromise]

其实，如果用OpenAI Conversation之后，就没办法用我们开源服务端的插件功能了，可玩性大大降低。
但是用Function call的方式开发工作就很大了。

[manicwy]

DIFY和COZE按理说不应该被降级成工具来用啊，这些都是LLMops，作为中间层，是xiaozhi-server在工作流和知识库方面强有力的补充，前面挡个LLM来做任务拆解和调度，先不说国内哪些模型能胜任这个工作，就从白白增加的耗时上来看也是不划算的

[manicwy]

DIFY和COZE按理说不应该被降级成工具来用啊，这些都是LLMops，作为中间层，是xiaozhi-server在工作流和知识库方面强有力的补充，前面挡个LLM来做任务拆解和调度，先不说国内哪些模型能胜任这个工作，就从白白增加的耗时上来看也是不划算的

我的理解，楼主的意思其实想充分利用DIFY和COZE内部的多应用机制，可以在用户的对话过程中方便的在多个应用间切换使用，这个出发点是很好的，目前dify和coze存在的问题也是只能同时接入一个app实例，极大限制了它们的多应用扩展能力

首先，xiaozhi-server要能允许创建多个dify和coze的不同app实例作为LLM进行调用，通过统一的用户唯一标识去访问各个实例，这样可以在dify和coze内部打通各实例之间的数据共享

其次，在保证性能的基础上，通过主LLM充当类似DIFY中的问题分类器，去筛选使用DIFY和COZE建立的不同应用，会不会比你这个异步任务调度更简单方便点？

[zfs1223]

整合是要看具体程度。如果是再行开发，我觉得意义不是太大。建议可以区分开，这边就专门做实际应用端的就可以了，因为普通人才是最大的用户群体。整个系统不应该太过复杂。类似于只做用户的总管家，其他的活有专门的人做。针对没人做的或只有国外有的，就单独做一个。说得比较通俗，希望能懂。

[fusheng520]

我得想使用MCP服务驱动外部得技能，DIFY和COZE这个一个私有一个外部，两个侧重板块不一样，还是得保留好一点，私有化得数据安全一点，特别对私有知识库得

[slow-groovin]

现在dify/coze都支持将自己搭建的应用暴露一个mcp sse server,
可以直接copy (cheery studio, n8n, cline) 中的mcp client实现,
用户除了填写mcp server endpoint之外, 再填写一个预估耗时

1. mcp listtool 信息直接作为上下文
2. 预估耗时用来决定是否异步