本文适用对象：中级水平
目标：能识别AI应用场景，更好的让Dify融入公司系统环境。
上一篇我们聊了Agent和Workflow如何选择的问题，这属于AI应用内部的架构问题。但现实情况是，公司往往不是一穷二白，只有Dify系统。
那如何让基于Dify的AI应用，能更好地融合到公司其他的信息系统中呢？
今天就让我们一起来探讨，系统间集成架构方面的话题。
01.
DIFY的服务模式
当我们考虑Dify的AI应用如何与现有系统做整合的时候，就需要先搞清楚Dify的开放能力。
- API集成模式 ：
将Dify的工作流作为完整的功能模块，对外暴露为API。其它系统通过API端点，进行POST请求后使用其功能，该模式耦合性高。
2. MCP集成模式 ：
通过暴露为MCP协议的工具，使其成为其他系统的工具调用。可以独立于三方系统之外，并且能统一升级管理。
3. 触发器模式 ：
通过定时器或者webhook的方式，唤醒工作流。该模式耦合性最低。
由此可以看出，Dify能作为单独的系统来服务，也可以作为别的系统的后台来提供支撑。
关键是选择合适的架构来设计自己的应用。
02.
适用场景分析
最简单的使用场景当然是Dify作为一个整体，使用自己的前后端功能。
从前端页面进去，进行AI应用的设计开发，然后直接发布为有前端交互入口的网页应用。该场景不需要依赖其他系统，也不用跟其他系统集成。
第二种场景是，不想改变现有的应用，只是想升级其中核心模块，将其改造成以AI方式工作。这时将Dify作为核心模型的提供商，开放API之后，让原有的应用通过API接口，来实现系统的整合和升级。对应上面图API集成模式。
第三种场景，把Dify的应用作为MCP工具，使得其他系统或者个人助理类产品，通过SSE或者Streamable的方式，变为大模型能使用的能力。对应上面图MCP集成模式。
而最后一种场景则是将Dify视为数据处理或者服务中心。通过定时或者其他系统触发的方式，来驱动Dify的工作流开始工作，以达到周期性或者按需执行的目的。对应上面图触发器模式。
03.
触发器的使用
触发器是最近Dify才发布的新功能。以前如果需要让Dify的应用定时执行，需要从第三方应用，设定一个定时任务，然后按时去请求API来实现。有点割裂，比较麻烦，不便于统一管理。而有了这个功能，现在直接就可以在workflow设计的时候，就前置一个trigger节点，来做同样的事情。
现在当创建工作流应用时，首先会弹出模式让你选择是使用原来的用户输入方式，还是触发器模式。
可以看到触发器类型内置的有定时器和webhook两种。还可以通过第三方的工具，来做更精确的触发对接，如GMail邮件触发，或者飞书通知触发等。
定时器，可以使用Cron表达式，如果你以前做过，那就太对味了，这个表达式可以实现非常复杂的定时执行能力。或者你只是新手，那就用可视化的方式做配置。
如果使用webhook的方式，则需要配置webhook的HTTP方法和URL路径，然后下面是请求头和请求体的设置。比如，麦金叔这里设置了，使用POST方法请求触发，请求体按JSON方式，放在Payload里面。参数是{"question":""}的格式。
配置好了之后，可以用postman这种工具来测试是否能行。对应上面的请求设置，如下图
如果执行成功，会得到返回消息
{"status":"success","message":"Webhook processed successfully"}。
同时，我们也注意到了，触发器只能触发工作流，并不能像API请求一样得到工作流执行的输出。这也是你在设计系统架构的时候，需要考虑的事情。
更多案例的拆解，麦金叔会在后续文章中陆续介绍。另外，经过大半年的努力，本人新书《Dify企业AI应用实战》也完稿了，如果能对大家的工作有帮助，那也算很有成就的一件事。
总结
今天学习了Dify的AI应用的几种集成的模式，重点介绍了触发器这种新的使用方式。
当你在设计AI项目时，能想起麦金叔今天介绍的大概，那一定能事半功倍。为了将来能快速方便的找到系列文章，不妨先关注，收藏一波。
如果你对AI的发展感兴趣，欢迎一键三连。有任何问题可以添加小助手（二维码在往期文章），我们共同探讨。