MonkeyCode本地部署后怎么远程用？从模型配置、VS Code到9999公网访问

MonkeyCode本地部署后怎么远程用？从模型配置、VS Code到9999公网访问

前言

本地AI代码助手真正用起来以后，最容易遇到的不是"不会写代码"，而是服务只能待在局域网里：办公室装了一套，回家打不开；想让同事试用，又得先处理端口、账号和访问入口。MonkeyCode这类团队AI开发平台，本来就涉及模型、成员和开发环境管理，如果只停在本机或内网，很多协作场景很难继续往下走。

这次我按照一套较早版本的 MonkeyCode 部署流程，从Linux环境开始安装服务，把管理端口设为9999，继续配置对话模型、代码补全模型和VS Code客户端，再实际让AI生成一个五子棋页面。

本地链路跑通以后，再给9999增加外部访问入口和固定二级子域名。

不过这篇会特别强调版本背景：MonkeyCode现在的官方主线已经明显转向在线AI开发平台、云端开发环境和团队任务协作，当前官方自托管安装命令、硬件建议以及"本地IDE/代码补全"能力都和这套旧流程不同，今天重新部署时不能机械照抄。

这类文章如果只写"公网能打开"其实意义不大，真正要看的，是本地后台、模型配置、IDE插件和远程入口能不能接成一条完整链。尤其MonkeyCode现在已经换了产品主线，更需要把"这次实际跑通过什么"和"今天官方推荐什么"分开，避免读者照着旧命令部署却以为是当前最新版。

1 先看清这套MonkeyCode属于哪一代产品形态

这套部署记录里的MonkeyCode具备：

• 本地Web管理后台；
• 模型管理；
• 成员管理；
• VS Code客户端；
• 对话模型；
• 代码补全模型；
• 对话记录；
• 自托管9999端口。

这和现在官方主线展示的MonkeyCode已经有明显差别。

当前官方主线更强调：

• 在线AI开发平台；
• 独立开发环境；
• AI任务管理；
• Git / PR / Issue协作；
• 多模型Agent；
• 企业私有化部署。

所以读这篇时，最重要的前提是：

把它当成一套较早版本的真实部署记录。

不是今天所有MonkeyCode版本都完全照此工作。

2 当前官方自托管资源要求也已经提高

这套记录里给出的要求是：

• Linux；
• x86_64；
• Docker 20.10.14+；
• Docker Compose 2.0.0+；
• 推荐1核 / 4GB / 20GB；
• 最低1核 / 2GB / 5GB。

但当前官方主线对自托管的建议已经变成：

• MonkeyCode控制台至少2C / 4GB / 40GB；
• 开发环境宿主机至少8C / 16GB / 100GB。

这说明产品本身已经演进。

所以老环境能够跑起来，不代表今天部署当前版仍然适合按1核/2GB去规划。

3 安装脚本也已经发生变化

这套记录使用：

bash -c "$(curl -fsSLk https://release.baizhi.cloud/monkeycode/manager.sh)"

这个脚本来自：

release.baizhi.cloud/monkeycode/manager.sh

属于当时的安装入口。

当前官方README给出的联网安装方式已经变成新的安装地址。

因此这条代码按实操记录保留。

但今天重新部署时，应该先看当前官方README，再决定是否继续使用老脚本。

4 远程脚本直接执行，先确认来源

这种：

curl | bash

方式确实方便。

但它代表：

把远程下载到的脚本直接交给shell执行。

如果是在生产服务器上长期部署，更稳妥的是先确认：

• 下载域名；
• 脚本内容；
• 安装目录；
• 创建了哪些服务；
• Docker配置；
• 防火墙和端口变化。

不要把"一键安装"理解成"完全不需要审查"。

5 安装时把Web端口设为9999

安装流程：

这里把端口设置为：

9999

安装完成：

然后可以通过安装结果提供的地址进入管理页面：

这一步真正完成的是：

Linux服务器 → MonkeyCode Web后台 → 9999

后面的模型、成员和VS Code客户端都依赖这套后台。

6 登录以后先配置AI模型

进入模型管理：

选择添加对话模型：

打开文档：

然后进入模型平台：

创建API凭据：

确认：

复制Key：

这里必须提醒：

API Key属于敏感凭据。

公开文章里的截图如果包含完整Key，应该先打码。

真实Key如果已经公开，最稳妥的是立刻撤销并重新生成。

7 让MonkeyCode读取模型列表

把API Key填回模型配置页：

获取模型列表：

选择模型：

保存以后：

这样对话模型就已经可用。

这里能够证明的是：

MonkeyCode后台已经成功连接到模型API。

不是：

模型运行在MonkeyCode服务器本地。

8 代码补全模型再单独配置

继续添加代码补全模型：

选择对应模型：

完成：

这也是这套较早版本形态里比较有代表性的能力：

对话模型和代码补全模型分开配置。

但当前MonkeyCode官方主线已经不再把"本地IDE代码补全"作为核心能力对外展示。

所以这一步要保留在版本背景里理解。

9 成员管理决定谁能进入这套服务

进入成员管理：

邀请新用户：

用户注册：

到这里，MonkeyCode已经不是一个单人本地工具。

它开始涉及：

• 用户账户；
• 模型调用额度；
• 成员权限；
• 对话记录；
• 项目和代码访问。

所以后面如果再做公网访问，不能只盯着9999端口。

账号权限同样重要。

10 下载并安装VS Code客户端

下载客户端：

在VS Code中进入扩展安装：

选择下载好的文件：

安装完成：

然后使用前面创建的账号登录：

继续：

做到这里，可以确认：

VS Code插件 → MonkeyCode后台 → 模型服务

已经接起来。

11 实际让AI生成一个五子棋

输入需求：

生成代码：

打开页面：

小游戏能够运行以后，这一步比单纯"插件登录成功"更有价值。

因为它证明：

• VS Code插件可用；
• AI请求能够发出去；
• 模型有返回；
• 代码写入项目；
• 页面能够正常运行。

12 "生成很快"只是一次体验，不是性能结论

源步骤里写：

代码生成得很快。

这只能代表：

• 当时模型；
• 当时网络；
• 当时任务规模；
• 当时API服务

下的体验。

真实速度会受到：

• 模型；
• API队列；
• 网络；
• Prompt复杂度；
• 项目规模

影响。

所以不适合扩大成：

所有代码都能秒生成。

13 回后台还能看到对话记录

重新回到MonkeyCode：

这里可以看到前面输入的命令和会话记录。

这说明：

IDE端和服务端后台之间存在统一管理关系。

但也意味着：

对话内容、Prompt、代码相关信息都属于需要保护的数据。

14 这套旧版流程和当前MonkeyCode主线为什么差别这么大

当前官方MonkeyCode已经更强调：

• AI Agent任务；
• 云端开发环境；
• Git协作；
• 自动PR / MR；
• 项目与需求管理；
• 手机端持续执行任务。

而当前官方对比表里：

• 本地IDE：不再作为主线能力；
• 代码补全：不再作为主线能力。

所以这篇不能写成：

今天MonkeyCode就是一个国产版Cursor。

更准确的是：

这套记录展示的是MonkeyCode较早阶段的一种本地服务 + IDE插件形态。

15 当前官方自托管入口也已经更新

当前官方README提供的是新的联网安装方式，并且资源要求更高。

因此今天如果是第一次部署MonkeyCode：

优先跟随当前官方自托管文档。

如果维护的是这套已经运行的老环境：

再继续参考本文的：

• 9999；
• 模型配置；
• VS Code；
• 成员管理；
• 远程访问。

这两种情况要区分开。

16 本地服务跑通以后，再考虑公网

到这里已经完成：

• MonkeyCode安装；
• 9999后台；
• 模型API；
• 对话模型；
• 补全模型；
• 成员账号；
• VS Code；
• 五子棋生成；
• 对话记录。

如果只在公司内网或家庭网络使用，到这里已经够用。

后面的步骤只解决：

人在外面怎么打开9999。

17 安装cpolar

执行：

sudo curl https://get.cpolar.sh | sh

安装完成以后检查：

sudo systemctl status cpolar

然后进入：

服务器IP:9200

后面的网络入口都在这里配置。

18 给9999创建随机公网地址

配置：

• 隧道名称：monkey
• 协议：HTTP
• 本地地址：9999
• 域名类型：随机域名
• 地区：China Top

创建以后查看：

再从外部设备访问：

页面能够打开以后，说明：

外部浏览器 → 公网地址 → cpolar → 9999 → MonkeyCode

网络链已经通了。

19 页面能打开，不等于适合直接发给所有人

MonkeyCode后台里可能包含：

• 模型API；
• 成员；
• 对话记录；
• 代码；
• 项目；
• 管理配置。

因此它不是普通展示页。

如果直接把管理后台公网地址发给：

• 客户；
• 陌生人；
• 临时体验者；

就需要先确认：

• 是否独立账号；
• 是否最小权限；
• 是否能看到其他成员数据；
• 是否能访问API Key；
• 是否有管理权限。

远程访问解决的是网络入口。

不是团队权限设计。

20 cpolar负责网络入口，不负责MonkeyCode权限

MonkeyCode负责：

• 用户；
• 模型；
• 代码；
• 会话；
• 管理。

cpolar负责：

• 外部设备怎么到达9999。

所以：

公网能打开 ≠ MonkeyCode后台已经适合公开。

真正团队使用时，权限和账号才是核心。

21 API Key不要因为"自托管"就忽略

即使MonkeyCode跑在自己的服务器上：

模型API仍可能来自外部平台。

API Key一旦泄露：

• 额度可能被盗用；
• 调用成本可能增加；
• 模型服务可能被滥用。

因此：

自托管后台 ≠ 所有AI数据和服务都完全本地。

要看模型到底接到哪里。

22 固定二级子域名

进入预留：

保留：

monkey

然后回到隧道列表，修改：

• 域名类型：二级子域名；
• Sub Domain：已保留名称；
• 地区：China Top。

后面的截图继续展示了更新后的固定地址访问。

23 固定地址解决的是入口稳定，不是后台安全

源步骤把固定地址写成：

永久不会变化。

长期文章更稳妥的说法是：

在账号、套餐和对应服务条件持续有效的情况下，固定二级子域名不会像随机地址那样频繁变化。

它解决的是：

• 浏览器书签稳定；
• 团队入口好记；
• 不用频繁更换URL。

它不会自动增加：

• 用户隔离；
• API Key保护；
• 操作审计；
• MFA；
• 访问审批。

24 这篇真正跑通的旧版链路

安装：

Linux → 安装脚本 → MonkeyCode → 9999

模型：

MonkeyCode → API Key → 对话/补全模型

IDE：

VS Code插件 → MonkeyCode → 模型 → 代码生成

远程：

外部浏览器 → 公网地址 → 9999 → MonkeyCode

真正完成：

• Linux部署；
• 9999；
• 模型API；
• 对话模型；
• 代码补全模型；
• 成员管理；
• VS Code插件；
• 五子棋生成；
• 对话记录；
• cpolar；
• 随机公网地址；
• 固定二级子域名。

需要特别记住：

• 这是较早版本的MonkeyCode形态；
• 当前官方主线已经变化；
• 当前自托管安装命令已经变化；
• 当前硬件建议更高；
• 当前主线不再把本地IDE/代码补全作为核心能力；
• API Key和成员权限属于敏感配置；
• 公网后台不应该无差别公开；
• 固定地址不等于安全。

总结

这套MonkeyCode实操真正跑通的，是一个"自托管后台 + 模型API + VS Code插件"的完整旧版链路：服务器负责9999管理后台，模型平台负责AI能力，VS Code插件负责把代码请求带进开发环境。

从对话模型、补全模型到五子棋页面生成，这篇比单纯展示后台更有价值，因为它至少验证了插件登录、模型请求、代码生成和服务端记录几个关键环节。

但今天再看，MonkeyCode的产品主线已经明显变化。当前官方更强调在线AI开发环境、Agent任务和Git协作，自托管资源要求和安装入口也都更新了，所以重新部署时必须先看当前官方文档。

远程部分则仍然有参考价值：9999可以通过网络入口提供给外部设备，但真正团队协作前要先做好账号、权限和API Key保护，不能把"能访问"直接等同于"适合公开给所有人"。