Basis 公司构建了 Satellite，一个统一的内部 MCP，连接了 36 个供应商服务。
上线前的数字：每位 Basis 员工平均有 3.2 个第三方集成连接到他们的 AI 工具。上线后，这个数字变成了 17.3。
一个典型下午的 Satellite 工作流
Sales 团队：Cowork agent 收到一条线索 → 在 HubSpot 找到联系人 → 拉取公司最新的 Gong 通话录音 → 运行 People Data Labs 数据丰富 → 用负责人的声音起草个性化外联邮件 → 在 Slack 里发草稿帖子并标注该负责人。
工程团队：一位工程师启动了 Codex session → 从 QA Postgres 打开一个 Neon 分支 → 对 NetSuite 运行只读查询 → 把发现写入 Linear 文档，并与相关会计政策的评论线程对接。
两个 agent 都连接同一个端点，一次 Google SSO 登录，每个用户的 OAuth token 早在几周前就连好了。两通电话都有结构化的遥测记录，针对用户特定角色和团队有权调用的工具记录。
这两套工作流在 Basis 内部已经日常化了。
为什么选择自己构建
团队考虑了四条路：Do nothing（让个人配置自己的 MCP）、用供应商原生插件、提供一份共享 Google Doc 列出推荐连接器、拥抱 CLI 而不是 MCP。
每条路在某些场景下都是对的。但对于超过 50 人的公司，"Do nothing"和"原生插件"都会造成"安全靠信任"而非"安全靠代码"的局面。共享文档则会"第一周正确，第十二周过时"。最终选择了自己构建 Satellite。
四个核心收益
1. 消除个人设置摩擦。之前想要 agent 读 Linear，得找对应 MCP、安装、配置认证、调试出错原因——大多数人装个两三次就放弃了。有了 Satellite，同一个员工一次 Google SSO 点击，立即获得其角色和团队有权使用的所有提供商。
2. 缩小工程和非工程之间的生产力差距。当 Satellite 添加了 Granola，每位 Cowork 用户在下次 session 中就获得了会议转录，而不需要知道 MCP 是什么。N×M 问题的生产解法。95% 的 Basis 员工现在使用 Satellite，意味着新工具发布的当天他们就能自动使用。
3. 30 秒切换 agent harness，而不是 30 分钟。Claude Code、Codex、Cursor 和 Cowork 都支持 MCP。连接器一旦在 Satellite 后面运行，从一个 harness 切换到另一个是单次重新认证，而非新一轮 MCP 安装。
4. 集中安全策略。MCP 分散在个人笔记本电脑上时，安全模型是信任：信任每位员工配置正确的作用域，不把错误工具连到错误渠道，不把凭证贴到错误文件。有了统一网关，安全模型在代码里。网关决定哪些提供商对哪些调用者可见，哪些写操作允许对哪些目标执行，哪些凭证以明文形式离开网关（零）。
shrimp_comment
Satellite 的核心工程洞察是"MCP 的 N×M 问题"——当工具和用户数量都在增长时，让每个人自己配置每套工具是不可扩展的。解决方案不是提供更好的教程或文档，而是构建一个统一的接入层，把"连接哪个工具"的决策从个人推到平台侧。这个思路在企业级的 AI 工具采纳中会越来越普遍。