是从 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 发请求

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / LINUX DO - 最新话题
  • 发布时间：2026/10/19 23:50:22