# CoMi如何集成第三方智能平台？
# 前言
此类三方集成需求建议由客开顾问、技术顾问分析评估。
这里涉及大量AI相关专业术语（语言模型、向量知识库、Agent、OpenAI、Function calling、Mcp、RAG、Dify、FastGPT），如不熟悉，请先结合网上资料和开放平台-AI技术基础概念赋能 (opens new window) 进行深入学习，否则很难推进综合评估！
本文仅是实验性质研究，方案仅供参考，抛砖引玉，离真正生产上线还会有一定距离。
# 用户需求
客户已经有自己的智能平台/智能体/Agent，已经完成了大量知识建设，想通过协同CoMi做门户入口，在协同/CoMi应用中提问能调用第三方智能体获得答案。
# 需求评估步骤
第一步，需要客户提供第三方智能平台的集成方案/集成接口，给出集成的代码示例。
第二步，根据CoMi自身接入能力，评估集成方案。
第三步，方案评估、实验落地。
# 第一步：获得第三方集成资料
第一步，需要客户提供第三方智能平台的集成方案/集成接口，给出集成的代码示例。
接口方案有很多种，不同厂商提供的方案不同，比较常见的比如：
- 三方自研开放接口，一般是HTTP API，比如Dify
- 三方自研开放WebUI，直接提供智能问答交互页面，比如Dify
- 遵守大模型OpenAI API接口标准，这种是通用的HTTP Restful接口，比如FastGPT
- 提供MCP server接口，这种也是智能体开发的一种接口标准
# 第二步：分析CoMi自身能力
第二步，我们需要了解CoMi其自身能力，尤其是后台CoMiBuilder接入第三方能力：
CoMi第1种能力： CoMiBuilder的OpenAI API接入能力：
CoMi依赖大模型进行智能分析，而接入的模型需要遵守OpenAI API接口规范，这是模型比较通用的标准。
只要第三方提供OpenAI接口信息，CoMi即可将其当作大模型接入并使用。
CoMi第2种能力： CoMiBuilder的工具接入能力，目前支持Api接口和Mcp接口：
Api接口：即主流的HTTP请求接口，支持接入get、post、put、delete类型，如果开发常用的postman工具能调通，则也可被comi所用
Mcp接口：这是智能领域的一种开放通信协议，第三方可提供Mcp Server，而Comi可作为Mcp client接入
注意： CoMi需要LLM大语言模型进行智能分析，并且还需要模型具备Function calling能力，才能智能驱动CoMi调用Api或Mcp接口
CoMi第3种能力： CoMiBuilder的向量库接入能力：
向量库是检索增强生成技术RAG的核心元素之一，智能体依赖向量库数据进行语义检索获取相关性数据，从而进一步提升问题回复准确率。
目前CoMi支持将文本文件分块并向量化存储，预计未来很快会支持通过开放接口形式导入向量库数据。
# 第三步：方案落地
将第一、二步结合，选择最优方案。建议优先通过实施配置完成，只有CoMi接入能力不足再进行二次开发。
场景一，第三方自研HTTP API。一般这种场景推荐两种集成思路：
- 第一种：在CoMiBuilder工具管理中，将第三方自研HTTP API录入成工具，随后在CoMi的Agent中引用工具即可。这种方式是利用大模型Functioncalling能力引导Agent自动调用第三方API，是一种很不错的接入方法。
- 第二种：二次开发，直接客开，在协同OA侧编写可视化问答WebUI页面，远程调用第三方HTTP API。只有第一种方式确实不满足的时候，采用此方法。
场景二，第三方开放WebUI。 这种场景通常是第三方提供一个URL地址，访问这个地址就是问答页面。这种场景有多种集成思路：
- 第一种：关联系统配置：管理员在OA的【关联应用】-【关联系统】中配置第三方URL地址（支持内网/外网地址）
- 第二种：二次开发，在协同内通过二次开发手段嵌入第三方智能问答页面
场景三，第三方开放OpenAI API接口。
在第三方的OpenAI接口信息正确的前提下，在CoMiBuilder侧直接将第三方配置成一个LLM大语言模型，然后配置的智能应用选择这个第三方模型，随后用户使用这个智能应用时，用户问题最终调用的是第三方智能体回复。
场景四，第三方开放MCP接口。这种情况下，解决方案实际上与场景一的第一种解决方案相同：
在CoMiBuilder工具管理中，将第三方自研HTTP API录入成工具（工具类型选择MCP），随后在CoMi的Agent中引用工具即可。这种方式是利用大模型Functioncalling能力引导Agent自动调用第三方MCP，是一种很不错的接入方法。
# 需求实践案例
# 实践环境
协同A8集团版V10.0（内部开发狗）
CoMi新一代智能体平台V1.1版本
Dify 0.15.8社区版本地化部署
FastGPT私有化部署环境
阿里云百炼-通义千问大模型
# 场景一实践：第三方自研API
参考【方案落地】章节，第三方自研HTTP API集成有两种方案：本章节提供第一种配置工具的解决方案；第二种二次开发由专业客开评估给解决方案。
实践案例： Dify 是一款开源的大语言模型(LLM) 应用开发平台，部分企业初期建设智能应用时喜欢选择Dify。
使用Dify制作的智能体应用提供了“访问API”的接入方法，但是Dify的API是自研的（Dify的对话接口 /v1/chat-messages 并非openAI标准）。
前提要求： 此方案依赖大模型的Functioncalling能力，不支持function call的模型无法调用工具，自然无法使用本方案！
实施方案：
1）获得Dify侧对应智能体的API接口参数，比如文档中的curl示例及api_key，然后在CoMi服务器上执行curl，测试是否能从Dify侧获得消息。
基于Dify的API接口说明，去掉response_mode流式回复（改默认阻塞式回复）以及 files上传文件参数，在服务器上执行请求后能获得来自Dify的响应，只是Dify的answer返回信息是 Unicode 字符编码，大模型认识就行。
2）到CoMiBuilder后台页面，工具下新建自定义工具，将上一步测试获取的Dify参数录入到CoMi工具中：
将Dify API请求参数录入到CoMi中（此步操作一般由客开技术人员完成）：
header传参内容：
3）CoMiBuilder工具参数下“调试”请求，如果请求结果能返回信息，则说明工具测试通过：
4）CoMiBuilder Agent中引用工具，并测试结果，如果看到如下结果则说明接入成功：
5）Agent完成后，到应用页签新建一个CoMi应用（关联上一步设计的Agent），最后发布给用户使用即可。
运行逻辑总结： 此方案利用了大模型的function calling能力决策使用什么API接口，再由Agent主动调用第三方API获得相关性答案，最后再由大模型进行汇总分析给出最终结果。
[用户] → [CoMi Agent] → [Dify API] → [CoMi Agent] → [用户]
↓ ↑ ↓ ↑
[ LLM模型 ] [ LLM模型 ]
LLM模型意图识别 LLM模型汇总分析
# 场景二实践：第三方WebUI
参考【方案落地】章节，第三方开放WebUI也有多种集成方案：本章节分享通过关联系统无代码直接集成的思路；另一种按用户需求定制开发接入由客开评估。
实践案例： Dify 是一款开源的大语言模型(LLM) 应用开发平台，部分企业初期建设智能应用时喜欢选择Dify。
使用Dify制作的智能体应用提供了“开放WebUI问答URL地址”的接入方法，只要获得Dify智能应用的URL，系统即可直接使用。
实施方案：
1）获得Dify侧对应智能体的访问地址，Dify“发布”方式中明确给出了访问智能问答页面的地址，拿着这个URL即可在协同侧集成：
2）协同OA系统管理员-关联系统管理-新建一个外部系统，将CoMi相关信息配置进去，关联系统支持第三方以“菜单”、“空间”、“栏目”的形式被接入，按需配置并授权使用用户即可：
3）如关联系统设置成菜单，被授权用户在个人空间就能看到第三方的智能体页面并且使用：
注意：若OA使用HTTPS，第三方地址也需使用HTTPS（甚至最好同域名），否则可能会遇到跨域问题（这点开发和运维应该清楚）。
# 场景三实践：第三方开放OpenAI
参考【方案落地】章节，第三方开放OpenAI API接口，意味着我们可以将第三方智能体当作一个大语言模型接入并使用。
实践案例一： FastGPT是一个企业级 AI Agent 搭建平台，在知识库问答领域表现较好。
目前开放平台首页的“CoMi一搜”就是基于FastGPT后台引擎运行维护，使用效果出众。
不过知道开放平台的主要是客开和运维，尚未覆盖全公司，为了提升“CoMi一搜”的使用量，我们考虑将FastGPT知识库集成到公司系统，让大家在公司系统CoMi也可以使用“CoMi一搜”。
FastGPT智能体发布渠道支持多种模式：
- 免登录窗口：等同于场景二，开放智能问答的URL，可通过关联系统直接接入
- API访问：通过查看文档，发现FastGPT提供的是OpenAI的API，理论上可以将其当作一个大模型看待
FastGPT关于API访问的说明文档，可以看出接口 /v1/chat/completions 疑似遵守了OpenAI的接口规范：
实施方案：
1）首先要确定FastGPT是否遵守OpenAI接口：
通过FastGPT智能体-发布渠道-API访问-新建按钮创建新的Key：
组装OpenAI接口的CURL命令，然后在CoMi服务器向FastGPT智能体发送请求，如果能获得结果则说明遵守OpenAI接口：
2）CoMiBuilder管理员后台-模型-新建模型，将FastGPT参数当作LLM模型录入：
3）CoMiBuilder管理员后台-应用-新建应用，不用任何Agent，直接大模型兜底选择上一步录入的FastGPT模型：
4）应用授权给具体用户后，协同系统-CoMi智能门户能看到“CoMi一搜”，提问也能获得FastGPT知识库的答案，配置成功！
运行逻辑总结： 此方案利用了FastGPT智能体OpenAI接口特性，将其直接当作一个LLM大语言模型看待，而且是包含企业内部知识的大模型。 其运行逻辑很简单：用户提问，CoMi直接将问题转给FastGPT获得答案：
[用户] → [CoMi Agent] → [ LLM模型（FastGPT OpenAI）] → [CoMi Agent] → [用户]
↓ ↑
FastGPT: [Agent]→[向量库]→[LLM模型]→[Agent]
实践案例二： Dify没有提供OpenAI接口，无法像FastGPT那样直接当模型接入，但是GitHub的开源项目Dify2OpenAI (opens new window)提供了对应适配，可以将其当作桥接器接入。 最终运行模式为：[CoMi接入模型] → [Dify2OpenAi GateWay] → [Dify Agent] 。
经过测试实践发现，使用DifyOpenAI做Gateway，也可以将Dify的智能体当作OpenAI规范的大模型接入：
实践案例三： Coze扣子没有提供OpenAI接口，需要借助 GitHub的开源项目one-api (opens new window) 提供对应的适配。
# 场景四实践：第三方开放Mcp
参考【方案落地】章节，第三方开放MCP接口，这种情况下可以在CoMi中将第三方Mcp当作工具接入使用。
实践案例： 当前暂未找到智能体直接开放Mcp的案例，不过我们可以找一个在线可用的Mcp Server做功能测试验证，比如百度千帆的MCP服务-百度AI搜索 (opens new window)！
按官方手册获取MCP Server URL和API Key：
直接访问大概如下效果，说明参数正确：
前提要求： 此方案依赖大模型的Functioncalling能力，不支持function call的模型无法调用工具，自然无法使用本方案！
实施方案：
1）CoMiBuilder后台-工具-新建工具-选择Mcp接口，然后将第三方Mcp服务的信息录入进去保存：
注：Mcp也不是100%兼容，实测一些三方Mcp服务在CoMi下不一定能用，多换几个测试测试
2）CoMiBuilder后台-Agent-新建Agent-引用上一步创建的Mcp工具，然后测试功能是否可用：
运行逻辑总结： 此方案利用了大模型的function calling能力决策使用什么API接口，再由Comi Agent作为Mcp client端主动调用第三方Mcp Server获得相关性答案，最后再由大模型进行汇总分析给出最终结果。
[用户] → [CoMi Agent] → [Mcp Server] → [CoMi Agent] → [用户]
↓ ↑ ↓ ↑
[ LLM模型 ] [ LLM模型 ]
LLM模型意图识别 LLM模型汇总分析
# 总结
1、新兴技术总会冒出很多新的术语，AI也一样，我们要做的无非是去学习拥抱它，（售前、客户经理、交付）应人人掌握基础，只有知其然知其所以然，才能在项目前、中、后期游刃有余。
2、掌握理论基础后，一定要去实践：本地部署一个CoMi（使用开发狗）就能研究测试CoMiBuilder；体验一下网上著名的AI智能平台，其Agent搭建原理大同小异。
3、不要固化概念，过去我们会认为模型就是纯LLM基座模型，OpenAI API连的就是大模型，现在“变天”了，万物皆可OpenAI API，你甚至会发现CoMi服务本身也是一个OpenAPI，后面可玩的东西很多！
4、从目前CoMi 1.1来看，麻雀虽小五脏俱全，使用过程中肯定会有些许问题，合理去规避或修复就行。
5、智能体建设实施配置只是第一步，后续Agent优化、知识库的调优才是任重而道远。
快速跳转
