一场 InterMIND 会议由什么构成

几乎所有产品都建立在同一套默认技术栈之上,也就是人人都会选用的那些大型专有 SaaS。它们是阻力最小的路径。而在您的会议数据真正所在的每一层,我们都选了另一条路:我们自己的代码,或是可以自行托管的开源软件。

这篇文章是 一场 InterMIND 会议究竟在哪里运行 的姊妹篇。那一篇梳理的是地理分布,即每项服务在哪里执行、有哪些数据经过它。本文回答安全团队接下来会问的问题:这套系统由什么构成,我们能否阅读、审计和替换它?

不谈它在哪里运行,只谈它由什么构成,逐层说明。

默认选项及其代价

每个产品都是一系列选择的叠加。对大多数产品而言,其中多数选择是按默认方式做出的:Google Analytics、Firebase、Google Translate API、Auth0、React。它们是阻力最小的路径,对多数团队来说,这样选也合理。代价是,每一个选择都会让您技术栈的一部分依赖于某个供应商:您无法阅读它,无法审计它,不重写就无法离开它。

在您的会议数据真正所在的每一层,我们都做了不同的选择:我们自己的代码,或是可以自行托管的开源软件。 对于不接触您会议内容的层,我们保持务实,并如实说明。以下是完整的全貌。

主干:引擎是我们自己的代码,而非第三方的

先从最重要的一层说起,因为您的大部分会议内容都经过它。实时传输和语音/聊天翻译都运行在 mind-sdk + Mind API 之上,这是我们自己的引擎,部署在法国 OVH。 构建翻译会议的默认做法,是把实时通信 SaaS(LiveKit)与翻译 API(DeepL、Google)拼接起来;在实时链路中,这两者我们都不用。实时链路里没有任何第三方翻译模型。(我们确实使用 DeepL,但仅用于投放到聊天中的文档,而非实时语音/聊天链路;详见运行时地图。关于管线机制,我们在 四条翻译管线详解 中讲过。)

运行时地图里没有提到的是:您的会议所运行的 SDK 是基于 BSD 3-Clause 许可的开源软件。mind-sdk 客户端公开于 gitlab.com/mindlabs/api/sdk,版权归 MindMeeting OÜ 所有,这是我们位于爱沙尼亚的知识产权实体。它与 api.mind.com 上的 Mind API 通信,该 API 由我们自己运营,部署在法国 OVH。

这不是“只能看、不能动”的源码可见式安排。BSD 3-Clause 是一种宽松的、经 OSI 批准的许可。您的安全团队可以克隆该 SDK,读懂您的音频和文本是如何被采集、分帧和流式传输的,并对照自身要求审计这一集成。它所连接的服务端引擎是我们自己的,而不是第三方的黑盒。面向有需要的租户、可完全自行托管的引擎已在我们的路线图上,但目前尚未提供。一旦发布,我们会第一时间更新本文。

逐层对照:默认选项与我们的选择

这张表贯穿着两条主线。开源用于处理您数据的工具,使其可以被审计,原则上也可以自行托管。开放标准(Postgres、S3 API、OIDC)用于我们所依赖的基础设施,使任何环节都不会被锁定在某一家供应商的定价或合规立场上。Postgres 可以迁移到任何 Postgres 主机;存储可以迁移到任何 S3 存储;身份验证可以与您已在使用的身份提供方联合。最后一行遵循的是第三条轴线:持有客户记录的 CRM 是注册于欧盟的(Pipedrive,爱沙尼亚),而非美国销售平台。它不是开源的,但也不受美国司法管辖。

其中几项值得多说几句。PostHog 是开源且可自行托管的;我们运行在 PostHog 的欧盟云上,并通过我们自己的源站以第一方方式代理,这样事件不会被广告拦截器悄悄丢弃,同时也不会经过第三方分析域名。身份验证从不交给介于您与您的会话之间的第三方认证 SaaS:我们自己运行 OIDC 流程,并与您现有的 Google 或 Microsoft 身份联合。每个页面上的字体都由我们自己的域名提供;Google Fonts 在我们的代码库中唯一出现的地方是一个离线的品牌素材脚本,从不出现在您的用户所加载的应用中。

我们务实的地方:坦率说明

我们不会假装整个技术栈都是自己手写的,或者都不属于美国公司。事实并非如此,声称如此的文章也会被我们自己的运行时地图所反驳。

基础管线包括托管与 SSR(Vercel)、会议服务器的计算资源(Fly.io)、支付(Stripe)和事务性邮件(Resend),它们运行在注册于美国的 SaaS 上。Stripe 和 Resend 处理账单和邀请,从不接触会议内容。Vercel 和 Fly 是租用的计算资源:运行在上面的是我们自己的代码。Fly 上的会议服务器确实会处理实时会话以及我们的摘要所读取的转录文本,但那是我们的代码运行在它们的机器上,而不是由某个供应商的产品来摄取您的会议。所有这些在运行时都在欧盟境内执行(详见 运行时地图)。

这是一个经过考虑、边界清晰的取舍:数据平面自有并采用开源;控制平面则使用现有最好的 SaaS。把它说出来才是关键,如果例外不与成绩一并摆在桌面上,“主权”这个词就没有多少意义。

AI 环节与已上线的方案

语言模型环节,包括 AI 摘要(主题、决定、action items)、文档摘要、AI 笔记编辑器的生成式操作、Ask AI 和 Mia,都运行在贵组织所选的 AI 网关上:默认是欧盟 Data Zone 中的 Azure OpenAI,也可以选择欧盟多区域端点上的 Vertex AI 或法兰克福的 Amazon Bedrock,均部署在我们自己的租户中,零数据留存,也不会用客户内容训练模型。或者使用您自己的 OpenAI 兼容端点,让模型保留在您所控制的基础设施上。会后总结和编辑器中的翻译操作走的是翻译通道,而非语言模型。实时语音、聊天、笔记和文档从一开始就没有接触过通用大语言模型。

这一层的实际情况就是:模型是专有的,其供应商是在欧盟区域运营的美国公司,与上文的基础管线属于同一种取舍,我们把它写在旁边,而不是藏起来。我们没有自建自托管模型,取而代之的是让您有选择权:组织可以完全关闭 AI(转录和翻译照常工作),也可以把每一项 AI 功能指向自己的端点,例如自己数据中心里的 vLLM,或在自己租户中的部署,这使这一层与数据平面的其余部分一样,处于开放且可自行托管的轴线上。我们公开的翻译基准由 LLM 评审(Gemini,以 Claude 作为备选)基于固定的 FLORES-200 参考句子打分,从不使用任何人的会议内容。

为什么这不只关乎我们

这并不是为了工程本身而做的工程。以这种方式构建技术栈的理由,体现在合同中属于您的一侧:

1. 可审计的。 您的会议所运行的 SDK 是开源代码,您的安全团队可以阅读;其背后的引擎是我们自己的,而不是第三方的黑盒。
2. 可迁移。 每个数据层都采用开放标准,即 Postgres、S3、OIDC,因此没有专有锁定。能够迁移的东西不会被绑定在单一供应商身上。
3. 可自行托管。 开放标准的数据层,即 Postgres、S3、OIDC,已经可以运行在您所控制的基础设施上;对于有需要的租户,完全自托管的翻译引擎已在路线图上。

以上是 2026-06-07 的情况。技术栈发生变化时,我们会更新本文,比如更换供应商、重建某一层、替换摘要模型。当前配置可在我们公开的 vercel.json、nuxt.config.ts 以及上文链接的 BSD-3-Clause mind-sdk 代码仓库中验证,这是可验证的。

如果这里的某一层看起来有误,或者您的安全评审需要这张地图没有给出的答案,请写信告诉我们。我们宁可由我们补上遗漏的细节,也不愿让您在代码审计中才发现。

来源:mind-sdk 代码仓库(BSD-3-Clause)、FLORES-200;技术栈事实已对照已部署的配置(vercel.json、nuxt.config.ts)和已上线的代码核实,核实时间为 2026 年 8 月。