一场 InterMIND 会议由什么构建而成
几乎每一款产品都构建于相同的默认技术栈之上——人人都会顺手选用的那些大型专有 SaaS。它们是阻力最小的路径。但在每一个真正承载您会议数据的层级,我们都选择了另一条路:我们自己的代码,或我们可以自行托管的开源软件。
本文是 一场 InterMIND 会议实际在哪里运行 的姊妹篇,后者描绘的是地理——每项服务在哪里执行、哪些数据经过它。本文回答的是安全团队接下来会问的问题:这东西是由什么构建的——我们能读它、审计它、替换它吗?
不是它在哪里运行——而是它由什么构成,逐层剖析。
默认选项,以及它们的代价
每个产品都是一系列选择的集合。对大多数产品而言,大多数选择都是顺着默认做出的:Google Analytics、Firebase、Google Translate API、Auth0、React。它们是阻力最小的路径,对大多数团队而言这是合理的判断。代价是:每一个都把您技术栈的一部分置于一家您无法阅读、无法审计、无法在不重写的情况下离开的供应商之后。
在每一个真正承载您会议数据的层级,我们都做出了不同的选择:我们自己的代码,或我们可以自行托管的开源软件。 在不触及您会议内容的层级,我们保持务实并明说这一点。以下是完整的图景。
中枢:引擎是我们的代码,而非第三方的
从最关键的那一层开始,因为您会议中的大部分数据都从这里流过。实时传输与语音/聊天翻译都运行在 mind-sdk + Mind API 之上——这是我们自己的引擎,部署在 OVH France 上。 构建一场翻译会议的默认方式,是把一个实时 SaaS(LiveKit)和一个翻译 API(DeepL、Google)拼接起来;而我们在实时链路中都不使用它们。链路中没有任何第三方翻译模型。(我们确实使用 DeepL——但仅用于聊天中投送的文档,而非实时语音/聊天链路;详见运行时地图。我们在 四条翻译流水线的内部机制 中详细介绍了流水线机制。)
下面这一点没有出现在运行时地图中:承载您会议的 SDK 以 BSD 3-Clause 许可证开源——mind-sdk 客户端公开发布在 gitlab.com/mindlabs/api/sdk,版权归 MindMeeting OÜ 所有,这是我们位于爱沙尼亚的知识产权实体。它与 api.mind.com 上的 Mind API 通信,后者由我们自己在 OVH France 上运行。
这不是"可看不可动"的源码可见式安排。BSD 3-Clause 是 OSI 认可的宽松型许可证。您的安全团队可以克隆 SDK,精确地阅读您的音频和文本是如何被采集、分帧和传输的,并依照您自己的要求审计该集成。它所通信的服务端引擎是我们的——不是第三方的黑盒——而面向需要它的租户的、完全可自托管的引擎已列入我们的路线图,但目前尚未提供。一旦发布,我们会立即更新本文。
逐层对比:默认方案与我们实际运行的方案
| 层级 | 通常的默认方案 | 我们运行的方案 | 这对您为何重要 |
|---|---|---|---|
| 实时 + 翻译引擎(语音 + 聊天) | LiveKit + 翻译 API(DeepL / Google) | mind-sdk(BSD-3-Clause 客户端) + 我们的 Mind API,OVH France | 最重的数据流走在我们自己的引擎上,而非第三方模型——且其客户端 SDK 开源、可审计 |
| 前端框架 | React(Meta) / Next.js | Vue + Nuxt | 由社区治理的开源软件——没有任何一家公司独占您 UI 所依赖的框架 |
| 产品分析 | Google Analytics | PostHog | 开源,欧盟云,通过我们自己的域名做第一方代理——使用数据不会流入第三方广告平台 |
| 字体 | Google Fonts CDN | 自托管(@nuxt/fonts) | 用户加载的页面不会向第三方字体服务发起回调——这是 GDPR 反复出现的合规问题,在此规避 |
| 身份认证 | Auth0 / Clerk / Firebase Auth | 自运行的 OIDC,联邦至您的 Google / Microsoft | 没有认证中间商持有您的会话——由您自带身份提供方 |
| 文档翻译 | Google Translate | DeepL(科隆) | 专精的欧盟厂商,德国本地处理 |
| 内容 / 文档 | Contentful / Sanity(无头 CMS) | Nuxt Content(git 追踪的 markdown) | 我们站点上的文字存于我们自己的代码仓库,而非厂商的数据库 |
| 应用数据库 | Firestore / DynamoDB(专有) | Postgres(部署于 Neon) | 开放标准——可移植到任意 Postgres 主机,无需重写专有查询 API |
| 对象存储 | 专有 blob API | Tigris(S3 兼容) | 开放协议——录制和导出可移植到任意 S3 存储 |
| CRM / 销售 | Salesforce / HubSpot | Pipedrive(爱沙尼亚) | 客户与交易记录存放在欧盟注册的 CRM 中,而非美国销售平台 |
上表贯穿着两条主线。在处理您数据的工具层级,选择开源——以便审计,并在原则上可自托管。在依赖基础设施的层级,选择开放标准(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 摘要(主题、决定、行动项)、会后总结和 AI 笔记编辑器——全部部署在欧盟处理方上。摘要和编辑器的生成式操作运行于托管于欧盟、零数据保留的 Mistral 之上(通过 Vercel 的 AI Gateway 接入,并锁定到 Mistral 提供方)。总结和编辑器的翻译操作运行在 OVH 上我们自己的欧盟引擎——与实时语音和聊天背后的引擎是同一个。实时语音、聊天、笔记和文档,从一开始就从未接近任何通用 LLM。
唯一仍在链路中的美国模型,用于评估我们公开的翻译基准测试——对固定的 FLORES-200 参考语句的机器翻译进行评分,从不涉及任何人的会议。
在欧盟-Mistral 这些步骤上,我们还会走得更远:一个由所有者控制的退出开关,可完全关闭摘要功能;以及一个部署在 OVH 上、自托管的开放权重摘要模型(Kimi 级别),以替换外部的 Mistral。走开放权重路线的关键不在于权重由哪家实验室训练——而在于开放权重可以运行在我们可控的基础设施上,这使其与数据平面的其余部分处于同一条"开源且可自托管"的轴线上。两者都在路线图上,尚未发布;一旦落地,我们会更新本文。
为什么这超越我们自身而重要
这不是为工程而工程。以这种方式构建技术栈的理由,会体现在合同的您这一侧:
- 可审计的。 承载您会议的 SDK 是您的安全团队可以阅读的开源代码,而其背后的引擎是我们自己的——不是第三方的黑盒。
- 可移植。 每个数据层级都采用开放标准——Postgres、S3、OIDC——意味着没有专有锁定。可迁移的部分不会绑定到单一厂商。
- 可自托管。 开放标准的数据层级——Postgres、S3、OIDC——已经运行在您可控的基础设施上;面向有此需求的租户,完全自托管的翻译引擎已列入路线图。
这是 2026-06-07 的图景。当技术栈发生变化时——更换某家厂商、重建某一层、替换摘要模型——我们会更新本文。当前配置可在我们开放的 vercel.json、nuxt.config.ts,以及上文链接的 BSD-3-Clause mind-sdk 仓库中得到验证。
如果这里的某一层看起来有误,或者您的安全审查需要本图未给出的答案,请联系我们。我们宁愿修正一处遗漏的细节,也不愿让您在代码审计中发现它。