我一开始以为 tmeet 是个”本地的 MCP 客户端”。

越用越觉得不对劲。如果它是客户端，那服务端在哪？我是不是还得再装点什么、再配个 server？这个疑问卡了我一段时间——直到我干脆去把它的真身翻出来看了一眼。

结论先给，一句话：

tmeet 不是 MCP 客户端，而是一个由 WorkBuddy 托管的本地 MCP Server。它用 SSE（Server-Sent Events）跟 WorkBuddy 通信，内部再用 OAuth 桥接腾讯会议云端的 REST API。

方向正好搞反了。下面是我怎么确认的，以及搞清楚这件事到底值多少。

一、证据：直接看二进制里有什么

不猜，直接检视二进制文件里的字符串。

• sse：出现 88 处
• mcp：出现 8 处
• initialize：出现 12 处

initialize 是 MCP 握手的第一步，sse 是传输层。一个纯粹的”客户端”不需要在自己身上实现这套握手响应。这三个关键字摆在一起，答案基本就明确了。

它长在这个路径下：

~/.workbuddy/binaries/node/cli-connector-packages/lib/node_modules/@tencentcloud/tmeet

形态是 CLI 包装 @tencentcloud/tmeet 加上一个原生二进制 dist/tmeet-macOS-AppleSilicon。

一个被平台放在固定目录、由平台拉起来的可执行文件——这就是”托管”两个字的实指。

二、结构：一共三层，别只看中间那层

我原来的混乱，本质是把三层协议栈压成了一层看。摊开就清楚了：

层	两端	协议
上层	Agent ⇄ WorkBuddy	MCP
中层	WorkBuddy ⇄ tmeet	MCP over SSE
下层	tmeet ⇄ 腾讯会议云端	HTTPS + OAuth2

关键在于：MCP 只覆盖上面两层，最下面一层根本不是 MCP，是普通的 HTTPS + OAuth2。

也就是说，tmeet 干的是翻译的活——上面对 WorkBuddy 说 MCP，下面对腾讯会议说 REST。

我之前的困惑就来自这儿：我看到它在跟腾讯会议云端通信，就下意识觉得”它是个客户端”。它确实是客户端，但那是对腾讯会议而言的。对 WorkBuddy 而言，它是服务端。同一个组件在不同的层上，角色是相反的——只看一层，必然会看错。

三、分工：谁是 client，谁是 server

角色一分开，“我还要不要再装点什么”这个问题就自动消失了。

WorkBuddy = MCP Host / Client

• 管连接器的生命周期：启动、停止
• 管授权：扫码换 token，维护 refresh_token
• 把连接器暴露出来的 tools 交给 Agent 去调

tmeet = 本地 MCP Server

• 以托管二进制的形式存在
• 对上暴露 tools，对下把请求翻译成腾讯会议 API 调用

你可能会想：那我还需要做什么？

答案是——不需要做什么。只要连接器状态是 connected，Agent 就能直接调会议查询、创建、修改、取消、转写拉取（transcript-get）、AI 智能纪要这些 tools。

你不用自己写 MCP client，也不用管 OAuth 的任何细节。

分不清 client 和 server 的代价不是理解上的不精确，而是实打实的时间浪费：你会一直在”我是不是还缺装一个什么东西”这件事上白折腾，明明路已经通了。

更隐蔽的一层代价是，你会不敢用。心里觉得”这个还没配完整”，于是本来一句话能调的能力，你绕回去手动操作。工具装好了却不敢用，比没装还亏。

四、顺带搞清一个入口差异，很多人卡在这

搞明白架构之后，我回头看连接器配置页，发现一个体感上非常容易踩的差别——预置连接器和自定义 MCP，生效逻辑根本不一样。

类型	配置路径	生效方式
预置连接器 （tmeet / wecom / 腾讯文档）	侧边栏「专家·技能·连接器」→「连接器」→ 添加 → 扫码授权	平台托管生命周期，显示 connected 就能直接调
自定义 MCP	连接器页右上「自定义连接器」→「MCP 服务管理」→「配置 MCP」（等价于 ~/.workbuddy/mcp.json）→ 保存	保存后不会自动生效，必须回列表手动点「信任」→「连接」，绿色才算通

这里最坑的一条，我单独拎出来：

自定义 MCP 保存 ≠ 生效。必须手动点「信任」。

如果是红色，就依次查：node / npx 是否可用 → JSON 格式对不对 → 网络通不通 → 凭证有没有过期。按这个顺序查，基本不会跑偏。

预置连接器之所以不用这一步，正是因为它的生命周期本来就由平台托管——这又绕回了前面那个结论。角色搞清楚了，这些看起来零散的操作差异，其实都是同一件事的推论。

可复用的一条经验

遇到搞不清的组件，先问它是 server 还是 client，别急着问它怎么配。

角色定位错了，后面所有的配置动作都会朝错误方向使劲——你会去找一个根本不存在的服务端，会去写一份根本不需要的配置。

而确认角色的成本，有时候低到只是去二进制里数几个关键字出现了多少次。花十分钟看清结构，胜过花三小时试错。