是从 Grok 4.5 开始的。当时在推上看到不少关于 Grok 性能提升的讨论，感觉这次好像确实有点东西，于是就订阅了 SuperGrok。
后来老马发布了 Grok Bot，我也第一时间体验了一下。但说实话，那段时间的 Grok 4.6、4.7 有些垃圾（点名老马画大饼骗订阅），尤其是放到 Agent 这种需要连续执行任务的场景里，用起来真的挺心累的。
折腾了一阵子，直到把一周的额度用完，我就没再继续碰它了。
转折点是后来看到老马发推，Grok Bot 会根据任务难度路由不同厂商的模型，其中还包括 Claude Opus 5.5。这下我倒是来了兴趣。
毕竟对我来说，Grok Bot 最吸引人的地方并不只是 Grok 模型本身，而是它背后那套能持续执行任务、操作环境、分工协作的 Agent 系统（本质大厂维护的云端龙虾
）。如果再加上更强的模型，那可玩性就完全不一样了。
于是我重新打开那个已经被移出 Dock 栏的 Grok Bot App，更新到最新版本，开始折腾Bot 集群。
最开始的玩法其实和大多数人差不多：创建一个主 Bot，再按照不同工作类型创建一批专项 Bot。我的主 Bot 叫「黄家一号」，下面又分了技术组、办公组和媒体组。
技术组有架构师、前端工程师、后端工程师、运维工程师、逆向专家等；办公组有 Word、Excel、PPT、PDF、CAD 工程师；媒体组则有图片、视频、音频工程师，以及负责调查和信息收集的 Bot。各组还有负责协调任务的总工。
看起来倒是有点像给自己搭了家小公司，各个部门和工种都有了。
实际使用时，我主要还是跟「黄家一号」对话，把需求交给它，再由它找对应的 Bot 分工处理。当然，这只是最开始的使用方式。
给 Bot 们装上工具
分工搭好之后，下一步自然就是给这些 Bot 配工具。
最近开源社区挺火的那套 Adobe 平替工具，我也注意到了，就是 Storytold 组织下的 Craft App Suite。它不只有对应 Adobe 系列软件的项目，还有开源办公套件，其中一些支持通过 CLI 或 MCP 让 Agent 操作。
比如 FilmCraft 做视频编辑、SoundCraft 做音频编辑、PhotoCraft 做图片编辑，办公方向还有 WordCraft、DeckCraft、GridCraft 等。项目不少，感兴趣的可以直接去他们的 GitHub 主页翻。
于是我把这个活交给「黄家一号」，让它根据工具能力创建专项 Bot，再把相应的 MCP 分配过去。这样一来，办公组和媒体组就不只是一堆会聊天的 AI，而是有了各自能操作的工具。
不过，工具配好了，并不代表它们就能很好地协作。
一个挺有意思的发现：Bot 之间也需要行业标准
我最开始尝试的是让媒体总工负责统筹，把任务分配给视频工程师和音频工程师，让它们一起做个视频。
结果这两个 Bot 虽然各自都能干活，配合起来却总差点意思。音频和视频的衔接，经常得让媒体总工检查、打回、修改，折腾好几轮才能做好。
后来我想到一个问题：现实中的配音和视频制作行业已经发展那么多年了，肯定早就有成熟的流程与交付标准。既然人类团队能依靠这些标准协作，那为什么不能让 Bot 也这么干？
于是我让它们在跨工种合作时，参考行业中已有的成熟规范来对接。不能只告诉它们谁负责什么，还得让它们知道上下游应该交付什么、按什么要求交付，以及怎么验收。
折腾完这件事之后，我最大的感受是：多 Agent 不是创建一群角色，让它们互相聊天就完事了。怎么协作，可能比怎么分工更重要。
没有统一标准的时候，一个 Bot 理解错了，另一个 Bot 再去补救，最后总工还得反复打回。每次返工背后都是额外的上下文、工具调用和模型额度。能直接用现成的行业协作规范，某种程度上还能省额度。
最终还真做出来了一个视频。素材是我对象黄老师下课后拍的课堂板书照片，我把它交给媒体组，让它们根据板书制作视频。TTS 用的是小米的 MiMo，最后效果还不错。
后面我又让 Bot 帮黄老师迭代了一波上课用的 PPT。Grok Bot 还有个挺有意思的功能：可以远程看 Bot 的桌面。所以整个过程中，我还可以看着它一步一步操作、修改课件。
比如这张关于「离子反应」的化学 PPT，知识导航、重点难点和页面布局都被重新整理了一遍。看着自己创建的 Bot 在另一台电脑上慢慢把 PPT 做出来，感觉还挺新奇的。
以前用 AI 做这种事，更多是让它直接生成一个文件，再下载看看效果。现在则可以观察它实际操作，发现不合适的地方，再让它接着修改。
不过我也开始想，既然 Grok Bot 已经有云电脑、工具调用和多 Bot 协作能力，那能不能继续把 Claude 等其他 Agent 工具也放进去（关键正宗美利坚服务器避免封号）？
接下来进入正题：把 Claude Code 搬进 Grok Bot 的云电脑
前面那些 Bot 分工、MCP、视频和 PPT，其实都还只是开胃菜。
最近 Opus 5.5 在模型圈的表现相当强，而 Grok Bot 本身又有一个挺适合折腾的条件：它的执行环境是一台 Linux 云端虚拟机。我当时使用的环境大约是 16GB 内存、128GB 存储，配置还不错，也有独立的桌面环境。
这几个条件凑到一起，我就想：既然 Grok Bot 已经提供了一台能执行任务的 Linux 云电脑，而 Claude 的能力又那么强，那干脆把 Claude Code CLI 也装进去试试。
于是我订阅了玩 AI 以来的第一个 Claude 套餐。通过 Google Pay，使用招商银行 Visa 卡订阅了 Pro，然后把 Claude Code CLI 部署进 Grok Bot 的 Linux 云电脑。到我写这段经历时，已经用了大约一周，暂时还比较稳定。
这里有个坑需要注意：云电脑的所在地区，和它实际访问外部服务时的出口 IP，不一定是一回事。
Grok Bot 客户端里有一个「经此电脑转发流量」的功能。启用之后，云电脑的网络流量可能会通过本地电脑转发；关闭之后，也不能直接假设它必然会使用某个固定地区的出口 IP。我在折腾时遇到过出口被分配到大陆、香港的情况。
这对 Claude 之类有地区服务限制的产品就比较敏感。我自己的做法是关闭「经此电脑转发流量」，再单独检查和配置云电脑的网络环境。这里也提醒一下，实际可用性取决于服务支持地区、出口网络和账号政策，不能把某个网络配置当成规避账号风控的保证。
怎么远程控制那台 Linux 虚拟机？
Grok Bot 自带的桌面查看已经挺方便了，但如果想更直接地操作 Linux 环境，比如管理文件、执行命令、调试服务，我推荐一个社区开源项目：UU Remote Linux。
它是非官方的 UU 远程 Linux 被控端。安装后，可以用 Mac、Windows 或手机上的 UU 远程客户端连接 Linux，支持远程桌面、终端、文件传输等功能。装在 Grok Bot 的云电脑上还挺实用的。
不过我最近两次使用它的文件传输功能，好像都碰到了一点 Bug。毕竟是非官方实现，兼容性有问题也能理解。后面我干脆用 SSH 隧道把文件传输单独做成了 MCP，这个后面再讲。
另外，装远程控制软件意味着要给它较高的系统操作权限。云电脑里如果存着 Claude 登录信息、项目代码和其他凭证，还是得自己做好远控账号、访问权限和密钥管理。
再进一步：在 Grok Bot 里直接聊天调用 Claude
远程终端能用了，但我又在想：既然 Claude Code CLI 已经装在那台机器上，每次想用的时候，难道还要自己打开远程终端手动敲命令？
于是我让主 Bot「黄家一号」自己写了一个类似 MCP 的连接器，把 Grok Bot 的任务交给 Claude Code CLI。然后再创建一个专项 Bot，名字就叫「Claude 终端」。
这个 Bot 主要就是负责传话：我给它发消息，它通过连接器把需求转给 Claude Code CLI，再把执行结果带回来。
比如其他 Agent 完成了一个 PR，我就可以直接让「Claude 终端」去 review。截图里的例子，就是 Claude 检查了一份工作台相关的 PR，反馈了 CI 状态，并且指出写入确认流程存在的问题，让开发侧修改后再合并。
这里要区分一下，这并不是把 Claude 模型直接接入 Grok Bot 原来的模型路由，而是 Grok Bot 通过主 Bot 编写的连接器，去调用 Linux 云电脑里实际运行的 Claude Code CLI。
我还用类似思路创建了一个「Codex 终端」。这样需要的时候，可以让 Grok Bot 把任务交给另一个 Agent 工具去完成。
接入微信公众号，顺手把京东云也利用起来
之后我开始用 Grok Bot 做一些开发、创意创作和内容生产方面的实际任务。
其中一个尝试是接入自己的微信公众号。我的目标很简单：让 Bot 去 X 上找热点，选题、撰稿、生图、排版，然后把文章存进公众号草稿箱，最后我只负责审核、点发布。
这条流程后来真跑通了。从搜集信息到保存草稿，可以让 Bot 一条龙处理。当然，内容最终还是要自己检查，发布按钮也由我来点。
不过接入公众号开发者接口时遇到了一个问题：某些接口需要配置调用方 IP 白名单，而 Grok Bot 云电脑的出口 IP 并不固定。不能每次 IP 变了，都手动改白名单吧？
刚好我之前有一台低性能的京东云服务器，性能一般，但是有固定公网出口 IP。于是就让它来承担公众号相关接口的中转请求，把它的 IP 加入白名单。
生成文章、生图、排版这些活仍然由 Grok Bot 完成，京东云只负责轻量级的接口转发。这样一想，其实也挺合理：不是所有机器都得有强算力。有的机器性能不怎么样，但固定 IP、长期在线这些能力，刚好能用来解决问题。
重活一多，Grok Bot 云电脑就有些吃不消了
后来我又想让 Grok Bot 做更多事情：Android 软件编译和测试、视频渲染、Blender 建模，甚至运行一些小模型。
到这一步就发现了，原来觉得还不错的云电脑配置，干这些重活也开始捉襟见肘。尤其是 Android 模拟器、Blender 渲染和模型推理，对 CPU、内存、GPU 的要求都不低。
既然 Grok Bot 的云电脑不够用，那就把计算任务分出去。
我最先想到的是自己的本地 Mac。它本来就装着不少开发工具和创作软件，没必要在云电脑里再重复部署一套。
最开始是借助京东云做中转，把 Mac 上的一些服务封装成 MCP：
- ComfyUI MCP：调用 Mac 上部署的 ComfyUI，用 Qwen Image 等模型生图；
- Blender MCP：让 Agent 控制本地 Blender，进行建模和渲染；
- Android MCP：调用本地 Android 开发环境和模拟器，做安装、运行和测试；
- 文件相关服务：方便后续把工具生成的文件交给其他机器。
本地 MCP 的部署和开发过程，ChatGPT 也帮了我不少忙。
另外，我还在京东云上部署了 Home Assistant，接入米家，再把 HA 的功能作为 MCP 给「家庭管家」Bot 使用。
现在我可以直接在 Grok Bot 里问宿舍的温度、湿度、门锁状态，或者让它安排一个时间关闭空调。我之前就试过让它五个小时后关空调，它会通过 Home Assistant 设置自动化。
到这里，Grok Bot 已经不只是在云电脑里执行任务了。它可以操作本地 Mac 的软件，也能通过 Home Assistant 操作现实中的设备。
不过事情又开始变得有些混乱。一方面 MCP 越来越多，有些服务在京东云，有些在本地 Mac，配置、维护都不太方便；另一方面，我这台 24GB 内存的 Mac 同时跑 ComfyUI、Blender、Android 模拟器，也逐渐吃不消了。
于是我开始继续物色配置更强的 VPS。
时隔半年，再次申请甲骨文，居然一发即中
那时候刚好在推上看到一篇关于 Oracle Cloud 的帖子，让我想起来上半年申请甲骨文账号一直失败的经历。
抱着再试一次的想法，我又提交了申请，没想到这次一发即中。
顺便分享一下我这次成功时的组合：移动 5G 网络 + QQ 邮箱 + 招商银行 Visa 卡 + 国内地址（英文填写）。当然这只是我个人的注册经历，不代表照着填就一定成功，审核这件事确实有点玄学。
注册成功后，我拿到了 Oracle A1 ARM 实例，配置为 4 核 CPU + 24GB 内存 + 200GB 存储。跟之前的低配京东云比，这个配置宽裕多了。
于是我决定让 Oracle A1 承担新的核心中转、MCP 管理以及一部分编译任务，京东云则保留原先固定 IP 接口服务等工作。
Oracle A1 + MCPHub：给分散的 MCP 找个统一入口
之前最头疼的地方之一，就是服务分散在不同机器上。要是每个 Agent 都分别保存不同 MCP 的地址、密钥、连接方式，后面维护起来太麻烦。
所以我在 Oracle A1 上部署了 MCPHub，统一管理这些 MCP 服务。
目前接入的主要服务有：
mac-blender：Mac 上的 Blender，负责建模、渲染；mac-comfyui：Mac 上的 ComfyUI，负责本地生图；mac-android：Mac 上的 Android 模拟器与测试能力；android-build：Oracle A1 上的 ARM64 Android 编译服务；home-assistant：Home Assistant 和米家设备；mac-file-transfer：文件传输；fetch：网页内容获取。
我截图里的 MCPHub 一共是 7 个服务，全部在线。各个 Agent 不需要知道每台机器上到底开了哪些端口，只要通过 MCPHub 访问获准使用的工具就行。
这时候还差最后一个问题：Oracle 上的 MCPHub，究竟怎么安全地访问位于本地网络里的 Mac？
MCPHub 和 Mac 之间，我用的是 SSH 加密隧道
这一段是整套方案真正串起来的关键。
我没有让云端 Agent 直接连 Mac，也不需要把本地 MCP 服务一个个暴露到公网，而是让 Agent 统一向 Oracle 的 MCPHub 发请求，再通过 SSH 加密隧道将请求转发到 Mac 上对应的桥接服务。
实际链路可以概括为：
云端 Agent（Grok Bot / Claude Code）
│
│ MCP 请求 + 访问密钥
▼
Oracle A1 上的 MCPHub
│
│ Oracle 本机的隧道端口
▼
SSH 加密连接
│
▼
Mac 上的 MCP 桥接服务
│
├── Blender
├── ComfyUI
├── Android 模拟器
└── 文件接收服务
这样一来，三个部分的职责就很清楚了。
MCPHub 负责统一提供工具入口、管理接入和访问密钥；SSH 隧道 负责把 Oracle 与 Mac 之间的网络链路打通；Mac 上的 MCP 桥接服务 负责真正调用 Blender、ComfyUI、Android 模拟器这些工具。
从 Agent 的角度来看，它面对的是一组 MCP 工具；至于工具到底运行在 Oracle 还是我的 Mac 上，就不需要它自己去处理底层网络连接了。
而且 Mac 在本地网络后面，也不用为了提供 MCP 服务，就把一堆端口直接暴露到公网。实际部署时仍需要保护好 MCPHub 的访问密钥、SSH 凭证和工具操作权限，毕竟这些工具并不只是能读取信息，有的还可以执行代码、操作文件。
把 Android 编译放到 Oracle，文件传输也做成 MCP
A1 的资源不算少，所以除了作为 MCPHub 和隧道中转节点，我还在上面部署了 Android ARM64 编译环境，并封装成 android-build MCP。
这样就可以让 Oracle 负责一部分 APK 编译任务，Mac 上的 Android 模拟器负责实际测试，两边各干各的活。
这时文件传输的重要性就体现出来了：编译后的 APK 需要传到测试环境，模拟器测试截图、日志需要取回来，Blender 渲染图和 ComfyUI 生成的图片也得在机器之间流转。
前面说过 UU Remote Linux 的文件传输最近有点 Bug，于是我干脆利用 SSH 隧道，把文件接收与传输能力也单独封装成了 MCP。
例如 APK 编译完成后，Agent 可以把文件交给下一步测试流程；Android 模拟器上生成的截图，也可以通过相应的工具取回。文件服务还可以做 SHA-256 校验，方便确认跨机器传输后的文件是否完整。
这个地方让我感觉挺重要：多机器 Agent 协作不只是“能调用工具”就够了，工具生成的文件怎么交给下一个工具，也得考虑清楚。 不然最后还是要自己手动下载、上传、整理文件，那自动化链路就断了一截。
实际案例：Grok Bot 里的 Claude，远程操作本地 Mac 上的 Blender
前面说了这么多，最后放一个这套链路实际运行的例子。
我让部署在 Grok Bot Linux 云电脑里的 Claude Code，通过 Oracle A1 上的 MCPHub，去调用自己 Mac 上的 Blender MCP，完成一个户型建模任务。
调用链路就是：
我在 Grok Bot 客户端发消息
↓
Claude 终端 Bot
↓
主 Bot 编写的 Claude Code 连接器
↓
Claude Code CLI（Grok Bot Linux 云电脑）
↓ MCP 请求 / 鉴权
MCPHub（Oracle A1）
↓ Oracle 本机隧道端口
SSH 加密连接
↓
mac-blender MCP 桥接服务（本地 Mac）
↓
Blender 4.5 LTS 建模、渲染
↓
返回结果
Claude Code 不需要跑在 Mac 上，也不需要在 Grok Bot 那台 Linux 云电脑里重新装一套 Blender。它负责理解需求、调用 MCP 工具，真正吃计算资源的建模和渲染则在我的 Mac 上完成。
我可以在本地看着 Blender 的场景不断变化，同时另一边 Claude Code 的终端还在继续调用工具。到这里，前面那些分散的机器和服务，终于有了一个比较完整的协作方式。
下面这些就是这次户型建模和渲染出来的部分结果，包括整体户型、客厅、主卧、次卧以及厨房和卫生间。
这些效果当然还可以继续打磨，但我想展示的重点并不是 Blender 建模水平有多高，而是一个运行在 Grok Bot 云电脑里的 Agent，已经能够通过中间的 MCPHub 和 SSH 隧道，实际调用本地 Mac 的创作软件，完成任务并交付结果。
同样的方式还可以迁移到 ComfyUI、Android 编译和模拟器测试，以及以后其他适合封装成 MCP 的软件。
最后的一点感受
回头看，其实一开始并没想过要搭出这么一套东西。最开始只是创建一些 Bot，让它们分工干活。
后来觉得协作效率不高，就开始琢磨行业标准和交付规范；觉得 Grok Bot 自带模型不够合适，就把 Claude Code CLI 接进来；觉得云电脑性能不够，就把 Blender、ComfyUI、Android 模拟器放到本地 Mac；Mac 的 24GB 内存开始吃紧，就把 Android 编译拆到 Oracle A1；MCP 服务越来越乱，就用 MCPHub 统一管理；跨机器文件传输不方便，就再封装一个 MCP。
折腾的过程基本就是遇到什么问题，再去找对应的解决办法。到目前为止，这套链路用起来还是挺方便的。
如果后面还想加 GPU 资源，也可以继续研究接入其他云端算力。比如已经订阅 Google AI Pro 的用户，可以看看自己账号下可用的 Colab 计算资源和 Google Drive 存储能力，能否作为临时计算或模型文件存储节点。不过具体 GPU 可用性、运行时长和使用限制，还是得以实际权益为准，不能把它当成一台随时在线的免费 GPU 服务器。
最大的感受就是：Agent 跑在哪里，和真正执行任务的软件跑在哪里，完全可以是两回事。
Grok Bot 提供任务入口和云端环境，Claude Code 负责处理复杂任务，Oracle A1 提供 MCPHub 和部分编译资源，本地 Mac 则负责 Blender、ComfyUI 和 Android 模拟器等需要特定环境的工作。甚至原本性能一般的京东云，也能靠固定公网 IP 发挥作用。
把它们串起来之后，就不必把所有能力都塞进同一台机器里了，不说能为大家带来多少帮助，对我来说折腾本身就是享受。
我也在折腾一套个人 AI 中枢，想把 Muse、Codex、Claude、VPS 和本地执行端串起来，只是我更偏向任务调度、状态持久化和权限控制。