李奕风

AI 应用创业｜独立开发🧑‍💻｜终身学习✍️｜热爱分享❤️｜欢迎关注交流

[李奕风 @CedarWithCode]

更新一下，这个方案多人使用一个号也不会被封号，可以作为新型中转站的方案基础

[李奕风 @CedarWithCode]

团队用 Claude Code，真的没必要再租一堆 Mac mini 了。

一个开源方案：Magpie + Coder，让 Claude Code 运行在海外服务器上，开发者在本地依然拥有接近原生的开发体验。

最近一直在思考一个问题：

Claude Code 已经成为��多开发者日常工作中不可缺少的工具，但当使用场景从一个人变成一个团队时，事情就开始复杂了。

个人使用很简单，安装 Claude Code，登录账号，打开终端就能开始工作。

但如果是一个 5 人、10 人，甚至几十人的开发团队呢？

你很快就会遇到一堆现实问题：

每个人都需要稳定的 Claude Code 运行环境
不希望团队成员混用 API Key、账号和配置
不希望所有人的请求、日志都经过一个共享中转站
希望开发环境统一，方便部署、管理和维护
又不希望开发者牺牲熟悉的 VS Code、终端和本地开发体验

于是，一些团队开始租赁海外 Mac mini，或者购买多台设备，远程登录使用 Claude Code。

这确实是一种方案。

但仔细想想：我们真正需要的是 Mac mini，还是一个能够稳定运行 Claude Code 的远程开发环境？

如果只是为了远程运行 Claude Code，为什么一定需要 macOS？

为什么不能直接用海外 Linux 服务器？

为什么不能像云开发环境一样，为每个开发者分配一个独立的 Workspace？

这正是 magpie-workspace 想解决的问题。

01｜传统共享中转方案，问题不只是稳定性

很多团队最初会搭建一个统一的 API 中转服务，让所有开发者通过同一个入口访问模型。

看起来管理方便，但随着使用人数增加，问题也逐渐暴露。

第一，凭据混用。

多个开发者共享一套配置、凭据甚至账号，权限边界变得模糊。

第二，请求与日志混杂。

不同开发者的会话、请求记录和使用情况可能集中在同一套系统里。对于包含私有代码的 AI 编程工具来说，这不是一个可以忽略的问题。

第三，资源互相影响。

一个开发者的大量请求，可能影响其他人的正常工作。统一中转节点出现问��，也可能导致整个团队无法使用。

第四，身份和环境边界不清晰。

账号、客户端、运行环境、请求出口之间缺少明确的一一对应关系，不利于管理、审计和故障排查。

而且需要注意：把多个账号放到同一个中转平台，并不意味着它们就拥有了真正独立的运行环境。

问题的核心在于：

传统共享中转站解决的是“如何转发请求”，却没有真正解决“如何为每个开发者提供独立的 Claude Code 工作环境”。

02｜换个思路：不要共享中转站，直接给每个人一个 Workspace

项目地址：

https://t.co/cOQOiPwrT4

magpie-workspace 采用了一个非常直接的架构：

Coder + Docker + Magpie + Claude Code

这几个组件各司其职。

Coder：负责管理远程开发环境。

为团队成员创建、启动和管理 Workspace，提供浏览器、终端和 VS Code Remote-SSH 等接入方式。

Docker：负责环境隔离。

每个开发��拥有自己的容器、工作目录、Home 目录和持久化存储。

Magpie：负责模型网关。

每个 Workspace 内运行独立的 Magpie Gateway，拥有自己的 Provider 配置、凭据和 Gateway Key，不需要共享一个中央 Magpie 网关。

Claude Code：真正执行 AI 编程任务。

它不是在开发者本地运行，而是直接运行在远程 Workspace 中。

整个请求链路变成：

本地 VS Code / 浏览器 / 终端

↓

Coder Workspace（海外 Linux 服务器）

↓

Claude Code

↓

当前 Workspace 独立的 Magpie Gateway

↓

上游模型 Provider

注意这里最关键的区别：

Claude Code 和 Magpie 都运行在远程服务器上，模型请求也从远程环境发起。

开发者本地电脑只负责连接、编辑和交互。

这和在本地安装 Claude Code、然后把 API 地址改成远程中转站，是两种完全不同的架构。

03｜远程运行，不意味着牺牲本地开发体验

很多人不愿意使用远程开发环境，其实不是因为远程服务器不好，而是远程桌面往往不好用。

延迟、复制粘贴、编辑器体验、文件同步……这些都会影响实际开发效率。

magpie-workspace 通过 Coder 提供多种使用方式。

喜欢 VS Code？

直接通过 Remote-SSH 连接 Workspace，在本地 VS Code 中打开远程项目。

喜欢终端？

使用 Coder Web Terminal 或 coder ssh，就能进入自己的开发环境。

需要浏览器操作？

Workspace 还内置 Chromium、noVNC 和剪贴板桥接。

需要处理本地文件？

可以使用 Coder 文件同步、rsync、scp，或者项目提供的可选 Mutagen 同步方案。

最终的体验是：

人在本地，编辑器在本地，终端交互在本地；代码执行、Claude Code 和模型请求运行在远程服务器。

当然，远程开发仍然依赖网络质量，不可能保证所有操作都与真正的本地执行完全一致。

但对于以 VS Code、终端、Git 和 Claude Code 为核心的开发工作流，这是一种非常值得考虑的方式。

04｜为什么说它更适合团队？

我认为这个方案最有价值的地方，不是把 Claude Code 放到了服务器上。

而是把原本零散的个人使用方式，变成了一套可以统一交付和管理的开发基础设施。

① 每人独立环境

开发���拥有自己的 Docker Workspace、Claude 配置和文件目录。

一个人的配置变更，不必影响其他人。

② 每人独立 Magpie 网关

各自维护 Provider 配置和凭据，避免所有人共用一个网关及其日志、配置与密钥。

③ 不需要一人一台 Mac mini

可以在一台具备足够资源的 Linux 服务器上运行多个 Workspace，并根据团队实际需求扩容。

当然，服务器仍然需要计算资源、存储和运维投入，但不再需要为了远程 Claude Code 环境而依赖 Mac mini。

④ 环境可以标准化

通过 Docker 镜像和 Coder 模板管理基础环境。

新成员入职，不必从零搭建整套开发工具链。

⑤ 开发工具不需要被替换

团队仍然可以继续使用熟悉的 VS Code、终端和 Git 工作流。

⑥ 自托管，架构更可控

Coder 控制面、Workspace、Magpie 网关都可以部署在自己管理的服务器上。

可以根据团队需求配置访问权限、持久化存储、资源限制及网络策略。

05｜特别需要说明：隔离环境不等于防封号

这里也必须讲清楚一个容易被误解的问题。

这个项目提供的是 运行环境隔离、凭��隔离和网关隔离，并不是所谓的“防封号神器”。

每个 Workspace 有独立 Magpie 网关，不代表默认就拥有独立公网出口 IP。

如果多个 Workspace 部署在同一台服务器上，而且没有单独配置出口网络，它们仍然可能使用同一个公网 IP。

同样，容器隔离也不意味着底层宿主机被攻破后，各个 Workspace 依然绝对安全。

更重要的是，这个方案不应该被用于共享个人订阅账号、转售访问权限或者绕过 Provider 的使用限制。

推荐的模式仍然是：

每个开发者使用自己的合法账号和凭据，运行在自己独立的 Workspace 内，并遵守对应服务的条款。

这才是它面向团队场景的长期价值。

06｜部署其实并不复杂

magpie-workspace 已经提供了 Docker Compose、Makefile 和 Coder Workspace 模板。

基本流程是：

准备一台 Linux 服务器，安装 Docker Engine 和 Docker Compose。
克隆 magpie-workspace 项目，配置环境变量。
通过 make up 和 make admin 启动 Coder 并初始化管理员。
构建 Workspace 镜像，推送 Coder 模板。
为团队成员创建账号和独立 Workspace。
每个人在自己的 Magpie 中��置 Provider，然后使用 Claude Code。

项目默认每个 Workspace 分配 1 CPU / 2 GiB 内存，可根据需求调整。

生产环境建议配置域名、HTTPS、访问控制以及必要的安全措施。

完整部署文档在 GitHub README 中。

07｜最后，为什么我认为这个方案值得关注？

过去大家讨论团队如何使用 Claude Code，往往围绕几个方向：

购买或者租赁 Mac mini、搭建共享 API 中转平台、在个人电脑上配置不同代理，或者为每个人单独准备一套复杂的环境。

但对于实际需要管理多个开发者的团队来说，可能更合理的方向是：

把 Claude Code 当作开发基础设施的一部分，而不只是每个人电脑上的一个 CLI 工具。

开发者需要的是顺手的开发体验。

团队管理者需要的是隔离、可维护、可扩展的环境。

Magpie + Coder 刚好提供了一个相对轻量的开源实现思路：

让 Claude Code 在远程服务器运行，让开发者继续在熟悉的工具里写代码，让每个人的运行环境和网关配置保持独立。

不必为了远程运行 Claude Code 再租一堆 Mac mini，也不必把所有人的请求都塞进同��个共享中转站。

如果你正在为团队部署 Claude Code，或者在研究如何把 AI Coding 工具变成团队基础设施，可以看看这个项目。

🔗 GitHub：https://t.co/cOQOiPwrT4

开源，支持自托管，MIT License。

如果觉得这个方向有价值，欢迎给项目一个 ⭐ Star，也欢迎提出 Issue、分享实际���署经验。

未来团队使用 AI Coding 工具，或许不应该是“每人配置一台机器”，而是“每人拥有一个随时可用的云端 AI 开发工作区”。

#ClaudeCode #Magpie #Coder #OpenSource #AICoding #DevTools
团队用 Claude Code，真的没必要再租一堆 Mac mini 了。

一个开源方案：Magpie + Coder，让 Claude Code 运行在海外服务器上，开发者在本地依然拥有接近原生的开发体验。

最近一直在思考一个问题：

Claude Code 已经成为很多开发者日常工作中不可缺少的工具，但当使用场景从一个人变成一个团队时，事情就开始复杂了。

个人使用很简单，安装 Claude Code，登录账号，打开终端就能开始工作。

但如果是一个 5 人、10 人，甚至几十人的开发团队呢？

你很快就会遇到一堆现实问题：

每个人都需要稳定的 Claude Code 运行环境
不希望团队成员混用 API Key、账号和配置
不希望所有人的请求、日志都经过一个共享中转站
希望开发环境统一，方便部署、管理和维护
又不希望开发者牺牲熟悉的 VS Code、终端和本地开发体验

于是，一些团队开始租赁海外 Mac mini，或者购买多台设备，远程登录使用 Claude Code。

这确实是一种方案。

但仔细想想：我们真正需要的是 Mac mini，还是一个能够稳定运行 Claude Code 的远程开发环境？

如果只是为了远程运行 Claude Code，为什么一定需要 macOS？

为什么不能直接用海外 Linux 服务器？

为什么不能像云开发环境一样，为每个开发者分配一个独立的 Workspace？

这正是 magpie-workspace 想解决的问题。

01｜传统共享中转方案，问题不只是稳定性

很多团队最初会搭建一个统一的 API 中转服务，让所有开发者通过同一个入口访问模型。

看起来管理方便，但随着使用人数增加，问题也逐渐暴露。

第一，凭据混用。

多个开发者共享一套配置、凭据甚至账号，权限边界变得模糊。

第二，请求与日志混杂。

不同开发者的会话、请求记录和使用情况可能集中在同一套系统里。对于包含私有代码的 AI 编程工具来说，这不是一个可以忽略的问题。

第三，资源互相影响。

一个开发者的大量请求，可能影响其他人的正常工作。统一中转节点出现问题，也可能导致整个团队无法使用。

第四，身份和环境边界不清晰。

账号、客户端、运行环境、请求出口之间缺少明确的一一对应关系，不利于管理、审计和故障排查。

而且需要注意：把多个账号放到同一个中转平台，并不意味着它们就拥有了真正独立的运行环境。

问题的核心在于：

传统共享中转站解决的是“如何转发请求”，却没有真正解决“如何为每个开发者提供独立的 Claude Code 工作环境”。

02｜换个思路：不要共享��转站，直接给每个人一个 Workspace

项目地址：

https://t.co/cOQOiPwrT4

magpie-workspace 采用了一个非常直接的架构：

Coder + Docker + Magpie + Claude Code

这几个组件各司其职。

Coder：负责管理远程开发环境。

为团队成员创建、启动和管理 Workspace，提供浏览器、终端和 VS Code Remote-SSH 等接入方式。

Docker：负责环境隔离。

每个开发者拥有自己的容器、工作目录、Home 目录和持久化存储。

Magpie：负责模型网关。

每个 Workspace 内运行独立的 Magpie Gateway，拥有自己的 Provider 配置、凭据和 Gateway Key，不需要共享一个中央 Magpie 网关。

Claude Code：真正执行 AI 编程任务。

它不是在开发者本地运行，而是直接运行在远程 Workspace 中。

整个请求链路变成：

本地 VS Code / 浏览器 / 终端

↓

Coder Workspace（海外 Linux 服务器）

↓

Claude Code

↓

当前 Workspace 独立的 Magpie Gateway

↓

上游模型 Provider

注意这里最关键的区别：

Claude Code 和 Magpie 都运行在远程服务器上，模型请求也从远程环境发起。

开发者本地电脑只负责连接、编辑和交互。

这和在本地安装 Claude Code、然后把 API 地址改成远程中转站，是两种完全不同的架构。

03｜远程运行，不意味着牺牲本地开发体验

很多人不愿意使用远程开发环境，其实不是因为远程服务器不好，而是远程桌面往往不好用。

延迟、复制粘贴、编辑器体验、文件同步……这些都会影响实际开发效率。

magpie-workspace 通过 Coder 提供多种使用方式。

喜欢 VS Code？

直接通过 Remote-SSH 连接 Workspace，在本地 VS Code 中打开远程项目。

喜欢终端？

使用 Coder Web Terminal 或 coder ssh，就能进入自己的开发环境。

需要浏览器操作？

Workspace 还内置 Chromium、noVNC 和剪贴板桥接。

需要���理本地文件？

可以使用 Coder 文件同步、rsync、scp，或者项目提供的可选 Mutagen 同步方案。

最终的体验是：

人在本地，编辑器在本地，终端交互在本地；代码执行、Claude Code 和模型请求运行在远程服务器。

当然，远程开发仍然依赖网络质量，不可能保证所有操作都与真正的本地执行完全一致。

但对于以 VS Code、终端、Git 和 Claude Code 为核心的开发工作流，这是一种非常值得考虑的方式。

04｜为什么说它更适合团队？

我认为这个方案最有价值的地方，不是把 Claude Code 放到了服务器上。

而是把原本零散的个人使用方式，变成了一套可以统一交付和管理的开发基础设施。

① 每人独立环境

开发者拥有自己的 Docker Workspace、Claude 配置和文件目录。

一个人的配置变更，不必影响其他人。

② 每人独立 Magpie 网关

各自维护 Provider 配置和凭据，避���所有人共用一个网关及其日志、配置与密钥。

③ 不需要一人一台 Mac mini

可以在一台具备足够资源的 Linux 服务器上运行多个 Workspace，并根据团队实际需求扩容。

当然，服务器仍然需要计算资源、存储和运维投入，但不再需要为了远程 Claude Code 环境而依赖 Mac mini。

④ 环境可以标准化

通过 Docker 镜像和 Coder 模板管理基础环境。

新成员入职，不必从零搭建整套开发工具链。

⑤ 开发工具不需要被替换

团队仍然可以继续使用熟悉的 VS Code、终端和 Git 工作流。

⑥ 自托管，架构更可控

Coder 控制面、Workspace、Magpie 网关都可以部署在自己管理的服务器上。

可以根据团队需求配置访问权限、持久化存储、资源限制及网络策略。

05｜特别需要说明：隔离环境不等于防封号

这里也必须讲清楚一个容易被误解的问题。

这个项目提供的是 运行环境隔离、凭据隔离和网关隔离，并不是所谓的“防封号神器”。

每个 Workspace 有独立 Magpie 网关，不代表默认就拥有独立公网出口 IP。

如果多个 Workspace 部署在同一台服务器上，而且没有单独配置出口网络，它们仍然可能使用同一个公网 IP。

同样，容器隔离也不意味着底层宿主机被攻破后，各个 Workspace 依然绝对安全。

更重要的是，这个方案不应该被用于共享个人订阅账号、转售访问权限或者绕过 Provider 的使用限制。

推荐的模式仍然是：

每个开发者使用自己的合法账号和凭据，运行在自己独立的 Workspace 内，并遵守对应服务的条款。

这才是它面向团队场景的长期价值。

06｜部署其实并不复杂

magpie-workspace 已经提供了 Docker Compose、Makefile 和 Coder Workspace 模板。

基本流程是：

准备一台 Linux 服务器，安装 Docker Engine 和 Docker Compose。
克隆 magpie-workspace 项目，配置环境变量。
通过 make up 和 make admin 启动 Coder 并初始化管理员。
构建 Workspace 镜像，推送 Coder 模板。
为团队成员创建账号和独立 Workspace。
每个人在自己的 Magpie 中配置 Provider，然后使用 Claude Code。

项目默认每个 Workspace 分配 1 CPU / 2 GiB 内存，可根据需求调整。

生产环境建议配置域名、HTTPS、访问控制以及必要的安全措施。

完整部署文档在 GitHub README 中。

07｜最后，为什么我认为这个方案值得关注？

过去大家讨论团队如何使用 Claude Code，往往围绕几个方向：

购买或者租赁 Mac mini、搭建共享 API 中转平台、在个人电脑上配置不同代理，或者为每个人单独准备一套复杂的环境。

但对于实际需要管理多个开发者的团队来说，可能更合理的方向是：

把 Claude Code 当作开发基础设施的一部分，而不只是每个人电脑上的一个 CLI 工具。

开发��需要的是顺手的开发体验。

团队管理者需要的是隔离、可维护、可扩展的环境。

Magpie + Coder 刚好提供了一个相对轻量的开源实现思路：

让 Claude Code 在远程服务器运行，让开发者继续在熟悉的工具里写代码，让每个人的运行环境和网关配置保持独立。

不必为了远程运行 Claude Code 再租一堆 Mac mini，也不必把所有人的请求都塞进同一个共享中转站。

如果你正在为团队部署 Claude Code，或者在研究如何把 AI Coding 工具变成团队基础设施，可以看看这个项目。

🔗 GitHub：https://t.co/cOQOiPwrT4

开源，支持自托管，MIT License。

如果觉得这个方向有价值，欢迎给项目一个 ⭐ Star，也欢迎提出 Issue、分享实际部署经验。

未来团队使用 AI Coding 工具，或许不应该是“每人配置一台机器”，而是“每人拥有一个随时可用的云端 AI 开发工作区”。

#ClaudeCode #Magpie #Coder #OpenSource #AICoding #DevTools

[李奕风 @CedarWithCode]

怎么避免封号，封了30+账号总结的经验。

什么住宅IP、支付等烂大街的教程我就不说了。着重说在开通账号后再怎么进一步防止被封号。

很多人不知道：Claude Code 可能通过独立连接发送遥测、错误报告和远程配置请求，通过大数据分析来监测你是否在中国大陆。

如果你使用 Claude Code + VPN ，建议额外做好以下隐私配置👇

① 关闭 Claude Code 遥测

在 ~/.claude/settings.json 添加：

{
"env": {
"DISABLE_TELEMETRY": "1",
"DISABLE_ERROR_REPORTING": "1",
"DISABLE_NON_ESSENTIAL_MODEL_CALLS": "1"
}
}

② 使用 VPN 软件屏蔽遥测域名
Clash / Surge / Quantumult X 可根据规则格式配置：
DOMAIN,https://t.co/JHvDfMs7is,REJECT
DOMAIN,https://t.co/APY6uvmXuB,REJECT
这些是社区分析中出现过的 Datadog 遥测端点。

③ 避免 DNS 和直连流量��漏
开启 VPN 的 TUN / 全局流量接管，当VPN节点不稳时，直接reject 所有https://t.co/JPPfFBqTot https://t.co/4FnYSfgJXe https://t.co/KkB162cfZg的请求。

检查 DNS 是否经过 VPN。

监控 Claude Code 是否绕过代理直连 Anthropic。

#ClaudeCode #Claude #AI编程 #隐私保护 #Clash #Surge

[李奕风 @CedarWithCode]

@dotey 别太乐观。
AI 主要加速【发现 + 临床前】这一段（占全周期前端一小部分）；对临床试验、监管审批、规模化生产、人体真实响应这些刚性环节只能小幅优化、不能根本性压缩。
整体全周期一般只能省 2～4 年，而不是把 10 年变成 2 年。

[李奕风 @CedarWithCode]

不用租新加坡 Mac mini，一台 VPS 就能搭建自己的 专属claude中转站。

在家、办公室或出差时，都可以从当前电脑远程连接 VPS，继续使用 Claude Code 等开发工具。

先说原理

当前使用的电脑
└─ Claude Code / Codex + 本地 Magpie
↓ SSH 隧道或 HTTPS
VPS 上的 Magpie 网关
↓
Claude 或其他模型服务商

代码和开发工具运行在当前电脑上；VPS 上的 Magpie 保存模型服务配置，并将模型请求转发给服务商。
换一台电脑时，连接同一个 VPS 网关即可。下面介绍两种连接方式：
SSH 隧道：不用配置域名，使用时保持 SSH 连接。
公网 HTTPS：配置域名后，可以直接连接，不用一直开着 SSH。
先说清楚账号风险：VPS 可以改变模型请求的网络出口，但不能保证 Claude 账号不会被封。浏览器登录授权也可能使用当前电脑的网络环境。请确认你的账号、地区和使用方式符合服务商要求。
一、准备
你需要：

一台带公网 IP 的 Linux VPS

VPS 上安装 Docker 和 OpenSSL

能通过 SSH 登录 VPS
当前电脑安装 Magpie 和需要使用的开发工具

模型服务商的 API Key，或 Magpie 支持的订阅账号

如果��择公网 HTTPS 方式，还需要一个可以解析到 VPS 的域名。

二、在 VPS 上启动 Magpie

SSH 登录 VPS，执行：

docker run -d --name magpie --restart unless-stopped \
-p 127.0.0.1:3425:3425 \
-p 127.0.0.1:3430:3430 \
-e MAGPIE_WEB_KEY="$(openssl rand -hex 16)" \
-v magpie-config:/config \
https://t.co/Ta8NY2ddQz web --addr 0.0.0.0:3430 --no-open
两个端口只绑定 VPS 本机：
3425：模型网关
3430：管理页面
账号、密钥和配置保存在 Docker 卷 magpie-config 中。

查看管理页面地址：

docker logs magpie

找到类似下面的地址：

http://127.0.0.1:3430/?k=...

其中的 k 是管理页面密钥，不要分享或公开截图。
三、打开管理页面，配置模型
在自己的电脑上执行，将 user@VPS_IP 替换为实际 SSH 登录信息：
ssh -N -L 3430:127.0.0.1:3430 user@VPS_IP
保持终端运行，然后在这台电脑的浏览器打开第二步日志中的完整地址：
http://127.0.0.1:3430/?k=你的管理密钥
进入 VPS 上的 Magpie 管理页面后：
打开 Providers → Add provider。

选择模型服务商，填写 API Key；或者选择 Magpie 支持的订阅账号，按页面提示登录。

打开 Gateway → Gateway keys，为当前电脑创建一个网关密钥。
Gateway key 是远程电脑连接 Magpie 的密钥，与模型服务商的 API Key 不同。

如果订阅登录结束后，浏览器跳到 localhost 并显示页面无法打开，按 Magpie 的提示，将浏览器地址栏中的完整回调地址粘贴到 Callback URL。回调地址包含授权信息，不要分享。

使用 Claude 订阅时，VPS 容器需要 Claude Code。Magpie 会在需要时提示安装；也可以在 VPS 上执行：

docker exec -it magpie magpie claude-code install
建议每台电脑创建独立的 Gateway key，方便分别管理和撤销。
四、选择一种远程连接方式

方式 A：SSH 隧道

适合不想配置域名，或希望网关不直接暴露在公网的情况。
在当前电脑执行：
ssh -N \
-L 3425:127.0.0.1:3425 \
user@VPS_IP

��持终端运行。本地 Magpie 的远程网关地址填写：

http://127.0.0.1:3425

隧道断开后，远程模型连接也会断开；重新执行 SSH 命令即可恢复。

如果本地 3425 已被占用，可以换一个本地端口：

ssh -N \
-L 13425:127.0.0.1:3425 \
user@VPS_IP
此时网关地址改为：
http://127.0.0.1:13425

方式 B：公网 HTTPS 直接访问

适合经常在不同地点使用、不想每次建立 SSH 隧道的情况。
① 准备一个域名，例如：
https://t.co/guNxTb31St

将它的 DNS A 记录指向 VPS 公网 IP。

② 在 VPS 服务商的防火墙和系统防火墙中，允许公网访问 TCP 80、443 端口。Magpie 的 3425 和 3430 仍保持只监听本机。
③ 在 VPS 上安装 Caddy，找到并编辑 Caddyfile，加入：
https://t.co/guNxTb31St {
reverse_proxy 127.0.0.1:3425
}

把域名替换成自己的，然后按 Caddy 的安装方式启动或重载配置。

域名解析和端口配置正确时，Caddy 会自动申请并续期 HTTPS 证书。

④ 本地 Magpie 的远程网关地址填写：

https://t.co/Q3bIoZxLKg
以后使用模型网关时，不需要保持 SSH 隧道。需要修改 VPS 上的 Magpie 配置时，再按第三步通过 SSH 打开管理页面。
不要直接使用 http://VPS公网IP:3425 传输网关密钥和请求内容：HTTP 不加密。

五、在当前电脑接入远程网关

打开当前电脑上的 Magpie：

进入 Providers → Add provider。

选择 Remote magpie。

填入第四步所选方式对应的地址。

填入第三步创建的 Gateway key。

进入 Agents，为 Claude Code、Codex 等工具选择远程提供的���型。
重新启动一个开发会话。
现在，开发工具仍在本地读写项目，模型请求则通过 VPS 上的 Magpie 转发。
六、换一台电脑继续使用
例如从家里的电脑换到办公室笔记本：

在新电脑安装 Magpie 和需要使用的开发工具。

为新电脑创建独立 Gateway key。
在新电脑添加 Remote magpie，填写网关地址和密钥。
如果使用 SSH 方式，先在新电脑建立隧道；如果使用 HTTPS，直接连接域名。

为开发工具选择远程模型。

注意：Magpie 网关不会自动同步代码、编辑器或开发会话。换电脑后，需要自行通过 Git 或其他方式准备项目代码。

七、检查和安全
连接不通时，依次检查：
VPS 上执行 docker ps，确认 Magpie 正在运行。
使用 SSH 方式时，确认隧道仍然连接。
使用 HTTPS 方式时，确认域名解析、Caddy 和 80 / 443 端口正常。

出现 401 时，检查是否填入启用中的 Gateway key。

发起一次模型请求后，查看 VPS 的 Magpie Usage 页面是否出现记录。
管理页面可以查看和修改账号配置及密钥，建议只通过 SSH 或 VPN 访问。妥善保管每台设备的 Gateway key，泄露后及时撤销。
项目地址：https://t.co/WJqGz1OfiR
Docker 文档：https://t.co/RlN8sn1NL6
远程连接文档：https://t.co/XyH9Dw7iWu
Caddy 文档：https://t.co/Xv0QMZHhB2

[李奕风 @CedarWithCode]

团队用 Claude Code，真的没必要再租一堆 Mac mini 了。

一个开源方案：Magpie + Coder，让 Claude Code 运行在海外服务器上，开发者在本地依然拥有接近原生的开发体验。

最近一直在思考一个问题：

Claude Code 已经成为很多开发者日常工作中不可缺少的工具，但当使用场景从一个人变成一个团队时，事情就开始复杂了。

个人使用很简单，安装 Claude Code，登录账号，打开终端就能开始工作。

但如果是一个 5 人、10 人，甚至几十人的开发团队呢？

你很快就会遇到一堆现实问题：

每个人都需要稳定的 Claude Code 运行环境
不希望团队成��混用 API Key、账号和配置
不希望所有人的请求、日志都经过一个共享中转站
希望开发环境统一，方便部署、管理和维护
又不希望开发者牺牲熟悉的 VS Code、终端和本地开发体验

于是，一些团队开始租赁海外 Mac mini，或者购买多台设备，远程登录使用 Claude Code。

这确实是一种方案。

但仔细想想：我们真正需要的是 Mac mini，还是一个能够稳定运行 Claude Code 的远程开发环境？

如果只是为了远程运行 Claude Code，为什么一定需要 macOS？

为什么不能直接用海外 Linux 服务器？

为什么不能像云开发环境一样，为每个开发者分配一个独立的 Workspace？

这正是 magpie-workspace 想解决的问题。

01｜传统共享中转方案，问题不只是稳定性

很多团队最初会搭建一个统一的 API 中转服务，让所有开发者通过同一个入口访问模型。

看起来管理方便，但随着使用人数增加，问题也逐渐暴露。

第一，凭据混用。

多个开发者共享一套配置、凭据甚至账号，权限边界变得模糊。

第二，请求与日志混杂。

不同开发者的会话、请求记录和使用情况可能集中在同一套系统里。对于包含私有代码的 AI 编程工具来说，这不是一个可以忽略的问题。

第三，资源互相影响。

一个开发者的大量请求，可能影响其他人的正常工作。统一中转节点出现问题，也可能导致整个团队无法使用。

第四，身份和环境边界不清晰。

账号、客户端、运行环境、请求出口之间缺少明确的一一对应关系，不利于管理、审计和故障排查。

而且需要注意：把多个账号放到同一个中转平台，并不意味着它们就拥有了真正独立的运行环境。

问题的核心在于：

传统共享中转站解决的是“如何转发请求”，却没有真正解决“如何为每个开发者提供独立的 Claude Code 工作环境”。

02｜换个思路：不要共享中转站，直接给每个人一个 Workspace

项目地址：

https://t.co/cOQOiPwrT4

magpie-workspace 采用了一个非常直接的架构：

Coder + Docker + Magpie + Claude Code

这几个组件各司其职。

Coder：负责管理远程开发环境。

为团队成员创建、启动和管理 Workspace，提供浏览器、终端和 VS Code Remote-SSH 等接入方式。

Docker：负责环境隔离。

每个开发者拥有自己的容器、工作目录、Home 目录和持久化存储。

Magpie：负责模型网关。

每个 Workspace 内运行独立的 Magpie Gateway，拥有自己的 Provider 配置、凭据和 Gateway Key，不需要共享一个中央 Magpie 网关。

Claude Code：真正执行 AI 编程任务。

它不是在开发者本地运行，而是直接运行在远程 Workspace 中。

整个请求链路变成：

本地 VS Code / 浏览器 / 终端

↓

Coder Workspace（海外 Linux 服务器）

↓

Claude Code

↓

当前 Workspace 独立的 Magpie Gateway

↓

上游模型 Provider

注意这里最关键的区别：

Claude Code 和 Magpie 都运行在远程服务器上，模型请求也从远程环境发起。

开发者本地电脑只负责连接、编辑和交互。

这和在本地安装 Claude Code、然后把 API 地址改成远程中转站，是两种完全不同的架构。

03｜远程运行，不意味着牺牲本地开发体验

很多人不愿意使用远程开发环境，其实不是因为远程服务器不好，而是远程桌面往往不好用。

延迟、复制粘贴、编辑器体验、文件同步……这些都会影响实际开发效率。

magpie-workspace 通过 Coder 提供多种使用方式。

喜欢 VS Code？

直接通过 Remote-SSH 连接 Workspace，在本地 VS Code 中打开远程项目。

喜欢终端？

使用 Coder Web Terminal 或 coder ssh，就能进入自己的开发环境。

需要浏览器操作？

Workspace 还内置 Chromium、noVNC 和剪贴板桥接。

需要处理本地文件？

可以使用 Coder 文件同步、rsync、scp，或者项目提供的可选 Mutagen 同步方案。

最终的体验是：

人在本地，编辑器在本地，终端交互在本地；代码执行、Claude Code 和模型请求运行在远程服务器。

当然，远程开发仍然依赖网络质量，不可能保证所有操作都与真正的本地执行完全一致。

但对于以 VS Code、终端、Git 和 Claude Code 为核心的开发工作流，这是一种非常值得考虑的方式。

04｜为什么说它更适合团队？

我认为这个方案最有价值的地方，不是把 Claude Code 放到了服务器上。

而是把原本零散的个人使用方式，变成了一套可以统一交付和管理的开发基础设施。

① 每人独立环境

开发者拥有自己的 Docker Workspace、Claude 配置和文件目录。

一个人的配置变更，不必影响其他人。

② 每人独立 Magpie 网关

各自维护 Provider 配置和凭据，避免所有人共用一个网关及其日志、配置与密钥。

③ 不需要一人一台 Mac mini

可以在一台具备足够资源的 Linux 服务器上运行多个 Workspace，并根据团队实际需求扩容。

当然，服务器仍然需要计算资源、存储和运维投入，但不再需要为了远程 Claude Code 环境而依赖 Mac mini。

④ 环境可以标准化

通过 Docker 镜像和 Coder 模板管理基础环境。

新成员入职，不必从零搭建整套开发工具链。

⑤ 开发工具不需要被替换

团队仍然可以继续使用熟悉的 VS Code、终端和 Git 工作流。

⑥ 自托管，架构更可控

Coder 控制面、Workspace、Magpie 网关都可以部署在自己管理的服务器上。

可以根据团队需求配置访问权限、持久化存储、资源限制及网络策略。

05｜特别需要说明：隔离环境不等于防封号

这里也必须讲清楚一个容易被误解的问题。

这个项目提供的是 运行环境隔离、凭据隔离和网关隔离，并不是所谓的“防封号神器”。

每个 Workspace 有独立 Magpie 网关，不代表默认就拥有独立公网出口 IP。

如果多个 Workspace 部署在同一台服务器上，而且没有单独配置出口网络，它们仍然可能使用同一个公网 IP。

同样，容器隔离也不意味着底层宿主机被攻破后，各个 Workspace 依然绝对安全。

更重要的是，这个方案不应该被用于共享个人订阅账号、转售访问权限或者绕过 Provider 的使用限制。

推荐的模式仍然是：

每个开发者使用自己的合法账号和凭据，运行在自己独立的 Workspace 内，并遵守对应服务的条款。

这才是它面向团队场景的长期价值。

06｜部署其实并不复杂

magpie-workspace 已经提供了 Docker Compose、Makefile 和 Coder Workspace 模板。

基本流程是：

准备一台 Linux 服务器，安装 Docker Engine 和 Docker Compose。
克隆 magpie-workspace 项目，配置环境变量。
通过 make up 和 make admin 启动 Coder 并初始化管理员。
构建 Workspace 镜像，推送 Coder 模板。
为团队成员创建账号和独立 Workspace。
每个人在自己的 Magpie 中配置 Provider，然后使用 Claude Code。

项目默认每个 Workspace 分配 1 CPU / 2 GiB 内存，可根据需求调整。

生产环境建议配置域名、HTTPS、访问控制以及必要的安全措施。

完整部署文档在 GitHub README 中。

07｜最后，为什么我认为这个方案值得关注？

过去大家讨论团队如何使用 Claude Code，往往围绕几个方向：

购买或者租赁 Mac mini、搭建共享 API 中转平台、在个人电脑上配置不同代理，或者为每个人单独准备一套复杂的环境。

但对于实际需要管理多个开发者的团队来说，可能更合理的方向是：

把 Claude Code 当作开发基础设施的一部分，而不只是每个人电脑上的一个 CLI 工具。

开发者需要的是顺手的开发体验。

团队管理者需要的是隔离、可维护、可扩展的环境。

Magpie + Coder 刚好提供了一个相对轻量的开源实现思路：

让 Claude Code 在远程服务器运行，让开发者继续在熟悉的工具里写代码，让每个人的运行环境和网关配置保持独立。

不必为了远程运行 Claude Code 再租一堆 Mac mini，也不必把所有人的请求都塞进同一个共享中转站。

如果你正在为团队部署 Claude Code，或者在研究如何把 AI Coding 工具变成团队基础设施，可以看看这个项目。

🔗 GitHub：https://t.co/cOQOiPwrT4

开源，支持自托管，MIT License。

如果觉得这个方向有价值，欢迎给项目一个 ⭐ Star，也欢迎提出 Issue、分享实际部署经验。

未来团队使用 AI Coding 工具，或许不应该是“每人配置一台机器”，而是“每人拥有一个随时可用���云端 AI 开发工作区”。

#ClaudeCode #Magpie #Coder #OpenSource #AICoding #DevTools
团队用 Claude Code，真的没必要再租一堆 Mac mini 了。

一个开源方案：Magpie + Coder，让 Claude Code 运行在海外服务器上，开发者在本地依然拥有接近原生的开发体验。

最近一直在思考一个问题：

Claude Code 已经成为很多开发者日常工作中不可缺少的工具，但当使用场景从一个人变成一个团队时，事情就开始复杂了。

个人使用很简单，安装 Claude Code，登录账号，打开终端就能开始工作。

但如果是一个 5 人、10 人，甚至几十人的开发团队呢？

你很快就会遇到一堆现实问题：

每个人都需要稳定的 Claude Code 运行环境
不希望团队成员混用 API Key、账号和配置
不希望所有人的请求、日志都经过一个共享中转站
希望开发环境统一，方便部署、管理和维护
又不希望开发者牺牲熟悉的 VS Code、终端和本地开发体验

于是，一些团队开始租赁海外 Mac mini，或者购买多台设备，远程登录使用 Claude Code。

这确实是一种方案。

但仔细想想：我们真正需要的是 Mac mini，还是一个能够稳定运行 Claude Code 的远程开发环境？

如果只是为了远程运行 Claude Code，为什么一定需要 macOS？

为什么不能直接用海外 Linux 服务器？

为什么不能像云开发环境一样，为每个开发者分配一个独立的 Workspace？

这正是 magpie-workspace 想解决的问题。

01｜传统共享中转方案，问题不只是稳定性

很多团队最初会搭建一个统一的 API 中转服务，让所有开发者通过同一个入口访问模型。

看起来管理方便，但随着使用人数增加，问题也逐渐暴露。

第一，凭据混用。

多个开发者共享一套配置、凭据甚至账号，权限边界变得模糊。

第二，请求与日志混杂。

不同开发者的会话、���求记录和使用情况可能集中在同一套系统里。对于包含私有代码的 AI 编程工具来说，这不是一个可以忽略的问题。

第三，资源互相影响。

一个开发者的大量请求，可能影响其他人的正常工作。统一中转节点出现问题，也可能导致整个团队无法使用。

第四，身份和环境边界不清晰。

账号、客户端、运行环境、请求出口之间缺少明确的一一对应关系，不利于管理、审计和故障排查。

而且需要注意：把多个账号放到同一个中转平台，并不意味着它们就拥有了真正独立的运行环境。

问题的核心在于：

传统共享中转站解决的是“如何转发请求”，却没有真正解决“如何为每个开发者提供独立的 Claude Code 工作环境”。

02｜换个思路：不要共享中转站，直接给每个人一个 Workspace

项目地址：

https://t.co/cOQOiPwrT4

magpie-workspace 采用了一个非常直接的架构：

Coder + Docker + Magpie + Claude Code

这几个组件各司其职。

Coder：负责管理远程开发环境。

为团队成员创建、启动和管理 Workspace，提供浏览器、终端和 VS Code Remote-SSH 等接入方式。

Docker：负责环境隔离。

每个开发者拥有自己的容器、工作目录、Home 目录和持久化存储。

Magpie：负责模型网关。

每个 Workspace 内运行独立的 Magpie Gateway，拥有自己的 Provider 配置、凭据和 Gateway Key，不需要共享一个中央 Magpie 网关。

Claude Code：真正执行 AI 编程任务。

它不是在开发者本地运行，而是直接运行在远程 Workspace 中。

整个请求链路变成：

本地 VS Code / 浏览器 / 终端

↓

Coder Workspace（海外 Linux 服务器）

↓

Claude Code

↓

当前 Workspace 独立的 Magpie Gateway

↓

上游模型 Provider

注意这里最关键的区别：

Claude Code 和 Magpie 都运行在远程服务器上，模型请求也从远程环境发起。

开发者本地电脑只负责连接、编辑和交互。

这和在本地安装 Claude Code、然后把 API 地址改成远程中转站，是两种完全不同的架构。

03｜远程运行，不意味着牺牲本地开发体验

很多人不愿意使用远程开发环境，其实不是因为远程服务器不好，而是远程桌面往往不好用。

延迟、复制粘贴、编辑器体验、文件同步……这些都会影响实际开发效率。

magpie-workspace 通过 Coder 提供多种使用方式。

喜欢 VS Code？

直接通过 Remote-SSH 连接 Workspace，在本地 VS Code 中打开远程项目。

喜欢终端？

使用 Coder Web Terminal 或 coder ssh，就能进入自己的开发环境。

需要浏览器操作？

Workspace 还内置 Chromium、noVNC 和剪贴板桥接。

需要处理本地文件？

可以使用 Coder 文件同步、rsync、scp，或者项目提供的可选 Mutagen 同步方案。

最终的体验是��

人在本地，编辑器在本地，终端交互在本地；代码执行、Claude Code 和模型请求运行在远程服务器。

当然，远程开发仍然依赖网络质量，不可能保证所有操作都与真正的本地执行完全一致。

但对于以 VS Code、终端、Git 和 Claude Code 为核心的开发工作流，这是一种非常值得考虑的方式。

04｜为什么说它更适合团队？

我认为这个方案最有价值的地方，不是把 Claude Code 放到了服务器上。

而是把原本零散的个人使用方式，变成了一套可以统一交付和管理的开发基础设施。

① 每人独立环境

开发者拥有自己的 Docker Workspace、Claude 配置和文件目录。

一个人的配置变更，不必影响其他人。

② 每人独立 Magpie 网关

各自维护 Provider 配置和凭据，避免所有人共用一个网关及其日志、配置与密钥。

③ 不需要一人一台 Mac mini

可以在一台具备足够资源的 Linux 服务器上运行多个 Workspace，并根据团队实际需求扩容。

当然，服务器仍然需要计算资源、存储和运维投入，但不再需要为了远程 Claude Code 环境而依赖 Mac mini。

④ 环境可以标准化

通过 Docker 镜像和 Coder 模板管理基础环境。

新成员入职，不必从零搭建整套开发工具链。

⑤ 开发工具不需要被替换

团队仍然可以继续使用熟悉的 VS Code、终端和 Git 工作流。

⑥ 自托管，架构更可控

Coder 控制面、Workspace、Magpie 网关都可以部署在自己管理的服务器上。

可以根据团队需求配置访问权限、持久化存储、资源限制及网络策略。

05｜特别需要说明：隔离环境不等于防封号

这里也必须讲清楚一个容易被误解的问题。

这个项目提供的是 运行环境隔离、凭据隔离和网关隔离，并不是所谓的“防封号神器”。

每个 Workspace 有独立 Magpie 网关，不代表默认就拥���独立公网出口 IP。

如果多个 Workspace 部署在同一台服务器上，而且没有单独配置出口网络，它们仍然可能使用同一个公网 IP。

同样，容器隔离也不意味着底层宿主机被攻破后，各个 Workspace 依然绝对安全。

更重要的是，这个方案不应该被用于共享个人订阅账号、转售访问权限或者绕过 Provider 的使用限制。

推荐的模式仍然是：

每个开发者使用自己的合法账号和凭据，运行在自己独立的 Workspace 内，并遵守对应服务的条款。

这才是它面向团队场景的长期价值。

06｜部署其实并不复杂

magpie-workspace 已经提供了 Docker Compose、Makefile 和 Coder Workspace 模板。

基本流程是：

准备一台 Linux 服务器，安装 Docker Engine 和 Docker Compose。
克隆 magpie-workspace 项目，配置环境变量。
通过 make up 和 make admin 启动 Coder 并初始化管理员。
构建 Workspace 镜像，推送 Coder 模���。
为团队成员创建账号和独立 Workspace。
每个人在自己的 Magpie 中配置 Provider，然后使用 Claude Code。

项目默认每个 Workspace 分配 1 CPU / 2 GiB 内存，可根据需求调整。

生产环境建议配置域名、HTTPS、访问控制以及必要的安全措施。

完整部署文档在 GitHub README 中。

07｜最后，为什么我认为这个方案值得关注？

过去大家讨论团队如何使用 Claude Code，往往围绕几个方向：

购买或者租赁 Mac mini、搭建共享 API 中转平台、在个人电脑上配置不同代理，或者为每个人单独准备一套复杂的环境。

但对于实际需要管理多个开发者的团队来说，可能更合理的方向是：

把 Claude Code 当作开发基础设施的一部分，而不只是每个人电脑上的一个 CLI 工具。

开发者需要的是顺手的开发体验。

团队管理者需要的是隔离、可维护、可扩展的环境。

Magpie + Coder 刚好提供了一个相对轻量的开源实现思路：

让 Claude Code 在远程服务器运行，让开发者继续在熟悉的工具里写代码，让每个人的运行环境和网关配置保持独立。

不必为了远程运行 Claude Code 再租一堆 Mac mini，也不必把所有人的请求都塞进同一个共享中转站。

如果你正在为团队部署 Claude Code，或者在研究如何把 AI Coding 工具变成团队基础设施，可以看看这个项目。

🔗 GitHub：https://t.co/cOQOiPwrT4

开源，支持自托管，MIT License。

如果觉得这个方向有价值，欢迎给项目一个 ⭐ Star，也欢迎提出 Issue、分享实际部署经验。

未来团队使用 AI Coding 工具，或许不应该是“每人配置一台机器”，而是“每人拥有一个随时可用的云端 AI 开发工作区”。

#ClaudeCode #Magpie #Coder #OpenSource #AICoding #DevTools

[李奕风 @CedarWithCode]

@Stargridcompass 刚发布都牛，观察两周看看，降智后的水平如何

[李奕风 @CedarWithCode]

@justinsuntron 学上孙哥一点半点，就已经是人中龙凤了

[李奕风 @CedarWithCode]

@xluchuan 都一样拉，没有明显代差

[李奕风 @CedarWithCode]

@ScarletKc 用过claude和gpt的，就知道gpt是真的拉

[李奕风 @CedarWithCode]

@shengtang135754 留codex和Claude code，顶级模型后训练配套的，其他垃圾���型和agent用了降低智商

[李奕风 @CedarWithCode]

@PineapplesDev @swyx Curious how you score recovery: just eventually green, or whether it fixed the root cause instead of patching the failing test? The second is what I find hardest to measure on regression tasks.

[李奕风 @CedarWithCode]

暴论：中文的 x 圈，真是大💩山

[李奕风 @CedarWithCode]

@skybytee 世界就是大屎山

[李奕风 @CedarWithCode]

@xiaoxiaodong 一张卡最多开了几个号？我现在开了3个目前没问题，想再多开几个担心封号

[李奕风 @CedarWithCode]

@XShude 补一个比较口径：$36→$0.47 的 76 倍包含模型切换；Asana 在原模型上，仅调整缓存和历史处理后，报告的是 29 倍降本。这个区分有助于判断优化究竟来自模型还是工作流。