远行IPaaS融合集成平台+AI大模型智能体能力初步实践总结

Hello，大家好，我是人月聊IT。

今天简单聊下远行IPaaS融合集成平台对AI大模型能力的一个集成和场景化应用实践。这个事情实际我们开始的比较晚，核心的一个原因还是具体的应用场景没有想清楚。

如果仅仅是简单的将我们的接口服务规范导入到大模型，做一个接口规范的智能知识库问答助手，实际意义并不大。但是随着整个AI大模型的发展，包括类似DeepSeek也支持私有化部署后，我们可以更多的去考虑具体应用场景。

在前面我专门文章介绍过，远行的IPaaS平台主要解决企业内部的各种融合集成场景和问题。

我们的IPaaS云桥 — 云原生连接中枢，融合了 ESB 总线、API 网关、MQ 消息、文件传输和 ETL 工具等多种中间件技术，全面满足企业内外部系统的集成需求。无论是企业内部遗留的单体系统，还是外部合作伙伴的第三方互联网 API 接口，云桥都能够实现高效、稳定、安全的连接与数据交互。

统一的服务管控平台提供了服务全生命周期管理，从服务定义、设计、开发、测试到部署、监控、运维，每一个环节都得到了精细化的管理和控制，有效解决了集成过程中 “开发难、管理难、运维难” 的三大难题。

大模型集成思路

首先可以看到当前有类似DeepSeek的免费大模型，也有类似OpenAI，Claude，阿里，腾讯的收费大模型。跟大模型的集成和适配应该是一个松耦合的关系，而且我们没有必要去做这个事情。我们的重点是集成和适配业界主流的大模型，并在上面开发垂直场景的AI Agengt智能体小应用。

因此看到当前主流开源可以做AI Agent开发的工具主要是Dify和RagFlow两种工具，其简单的对比如下：

图片

由于我们的重点不是在做RAG增强检索和知识库问答，重点是和IPaaS平台集成的智能体应用，因此最终选择开源的Dify来搭建本地的智能体开发环境。

DIFY 为开发者提供了从 Agent 构建到 AI workflow 编排、RAG 检索、模型管理等一系列强大的能力。通过其直观的界面，结合 AI 工作流、RAG 管道、Agent、模型管理、可观测性功能等，开发者能够快速地将想法从原型转化为实际生产中的应用。不仅如此，DIFY 还为 AI Agent 提供了 50 多种内置工具，进一步拓展了应用的功能边界。

首先我们进行了社区版部署，DIFY部署起来还是很简单的，通过将DIFY 社区版的代码克隆到本地，执行docker compose up -d即可，如果容器都成功启动了，则部署成功，部署成功后界面如下

图片

部署成功后，需要在用户->设置里面选择模型供应商，DIFY支持非常多的模型，像DeepSeek、OpenAI、通义千问、文心一言等。这里我选择了两款常用的模型，配置好对应的地址和API-key即可（DeepSeek需要付费，硅基流动有赠送金额）。

图片

在完成了Dify的本地化部署安装，大模型配置后基本上环境搭建的工作就全部完成了。在我们初步验证和实践阶段仍然采用公网的大模型进行相关业务场景的测试和验证。

场景1-基于接口规范的问答

这里基本是一个基于RAG的知识库问答测试场景和验证。我们可以将集成平台所有的接口规范单纯存储为独立的pdf文件，然后再上传到Dify的文档知识库中。这里直接采用Dify自带的向量存储库即可。这些接口规范都是我们在多年的项目积累过程中的经验总结，覆盖多个行业近百个客户的集成业务。本身就是一种可复用的业务服务资产。

在知识库准备好后，我们就可以简单的通过Dify发布聊天助手。在这里我们通过使用Deepseek-chat模型发布，并验证其能力。

比如企业正在做合同系统和ERP系统之间的集成，你可以问AI两个系统之间有哪些集成关系，可以涉及哪些接口，每个接口的输入输出报文格式大致是如何的。这些基本检索我们的历史接口规范文档就可以得到答案。

场景2-自然语言自动发布和注册接口

第二个验证场景就是，原来对于一个接口的注册和接入，我们往往涉及到代理服务的定义，业务服务的定义，消息管道的配置，安全限流各种规则的配置，这些都需要操作多个功能配置菜单才能够完成。

而新的思路是我可以自然语言对话，来快速完成一个已有接口服务的自动注册到IPaaS集成平台上面，并完成相关的安全，日志配置工作。

你只需要告诉AI你需要接入哪个接口，接口地址在哪里？有什么样的安全控制需求就可以了，具体界面如下：

可以看到我们一句话就可以快速完成API接口服务的注册和接入工作。这极大地减轻了集成平台配置和部署的工作量。

场景3-Chat2API

原来我多次谈到过类似Text2SQL或ChatBI类智能体或产品。这类产品特点就是可以通过自然语言对话，完成对数据库数据信息的查询工作。但是存在的巨大风险仍然是整个数据库可能都对外开放导致的安全问题和信息泄露问题。

而且AI在生成SQL的时候本身也存在幻觉，即使经过前期大量的数据准备和预训练，对于复杂场景下问题的准确率也就在90%左右。那么既然可以和数据库直接对话，那么自然可以和API服务直接对话。而且API接口服务天然实现了业务问题和底层数据库的解耦，确保了安全性。

对于这个功能的实现，核心还是首先AI要理解自然语言问题，同时精准的路由到对应的API接口服务上面，然后在出发对API接口的调用去获取数据。在前面我们做好Workflow可视化编排设计后，AI就可以基于提示词内容自动转换为对API接口的调用，并对输出结果进行结构化处理。比如我们要查询员工信息，AI分析后确定调用SearchEmpAPI接口，然后再发起对接口的调用。

具体参考界面如下：

注意对于ChatAPI当前有一种更加直接的实现方式。就是将IPaaS集成平台作为一个MCP Server接入到大模型中。前期我在看类似开源的APISix网关引擎已经支撑MCP Server服务提供。

那么我们也完全可以开发一个我们自己IPaaS平台的MCP Server并接入到各种支持MCP的主流大模型中。那么自然在接入后可以完整实现ChatAPI的能力。

场景4-复杂编排和适配功能实现

对于接口注册接入，往往还存在类似数据库适配，消息适配，协议转换，数据映射等复杂场景，对于这些复杂场景即使在使用IPaaS集成平台的时候，也需要通过平台提供的可视化接口编排器来完成。

通过可视化的界面编辑器，用户只需通过简单拖放操作，即可将应用组件添加到设计界面。同时，使用线条连接各个组件，以定义它们之间的逻辑关系和数据流向。这种直观的操作方式，使得设计API变得轻而易举。

可视化编排不仅支持单个服务的简单编排，还支持多个服务的组合编排。用户可以根据业务需求，将不同的服务进行有机组合，构建出复杂的集成流程，满足企业不断变化的需求。

图片

那么在集成AI大模型能力后，这类接口的编排也可以AI大模型智能体，通过自然语言对话的方式来完成。

比如现在有一个传统的SOAP WebService的服务接口，现在需要转换为RestAPI的接口服务。那么也是自然语言对话，我们在尽显Dify的工作流设计的时候先基于大模型理解语义，然后生成IPaaS平台特定格式的Json工作流编排模板，最后再调用IPaaS平台的接口完成接口编排工作。

因此我们通过AI对话，可以快速地实现，类似如下：

可以看到在IPaaS平台融合集成了大模型能力后，发布编排API将变得更加简单，同时远行IPaaS平台的可视化编排能力足够强能适配市面绝大部分中间件，后续只要根据对应场景设计出编排模板，然后再修改智能体，即可满足绝大部分组件能力的快速封装、发布和组合编排，大大提升业务能力共享和应用集成的开发效率。

今天的分享先到这里，希望对大家有所启发。