郭宇 guoyu.eth (@turingou) “说起来，我也把个人账号绑定到 X MCP 上了，我现在这条内容就是通过 Codex 发出的。” — TopicDigg

说起来，我也把个人账号绑定到 X MCP 上了，我现在这条内容就是通过 Codex 发出的。 我刚才一直在思考，刚接入 X MCP 的时候，这种 OAuth 2.0 的授权方式对于 Agent 来说，到底是不是一个比较友好的方式？目前看起来，这还是比较像一个中间阶段。 比如我刚才吐槽说，推特没有专门为 Agent 授权做一个 X App： 1. 首先，你需要自己去注册一个 Developer 账户，在下面创建一个 Stage 或者 Production 的 App。 2. 拿到对应的 App ID 和 App Secret 之后，你才可以自己创建一个 MCP 服务器去提供登录。 3. 拿到登录链接后，登录完它会跳转到 localhost:8080，这有点匪夷所思，是因为：你需要手动把 localhost:8080 的 URL 粘贴给你的 Agent，让它分析出对应的 code。然后它会拿 code 去换取 API Key，最后用于 MCP 认证。 agent 的配置文件其实是静态的，而且 Agent 可能在任何地方触发这个行为，这就意味着没有一个真正的、可以定义的 URL 来处理这件事。对于桌面 Agent，他们一般的做法有两种：1. 本地起一个端口的服务，用来监听这件事，2. 或者跳到官网，上面有一个触发机制，可以触发本地 Agent 的行为，然后再跳回来。推特用 OAuth 2.0 这种方式去做 workaround，你当然可以自己修改这个 URL。 比如说，你可以把 localhost 改成其他的 url，比如跳转到 wanman。wanman 够识别这个 code 并交换之后，也可以把 wanman 的 agent 接入到 X 的 MCP 上，这也是可以的。 其实我觉得这个问题背后的本质问题，是我们不知道 Agent 在哪里。 一个需要 Workspace、需要具体计算空间的 Agent，它可能在任何地方。这个“任何地方”有很多可能性： 1. 它可以藏在一个网络服务之下的沙盒里，比如 wanman 下 2. 它可以是你的一个电脑 3. 在未来，它甚至可能是一个手机或者是移动计算设备 所以我觉得，为了定位它的位置，肯定会有一种中间层服务来做这件事情。 这个中间层服务可以让任何位置的 Agent，都能够比较简单地接入到任何的网络服务当中。当然，现在可能 80% 的网络服务还没有提供 MCP，更别提 Codex Plugin 和生成式 UI 了。 现在有相当多的产品都在抢占 Agent 或者 Agent 的代理工作这一环节，但我好像没有看到有人在做类似的中间服务？