Antigravity 远程服务器 AI对话提示 Retry 的解决
- 内容介绍
- 文章标签
- 相关推荐
下面是已经在佬友配置好翻墙的基础上进行的: 【方案】解决Antigravity连接远程服务器无法AI对话（无sudo权限）
从昨晚开始远程登录上ssh的对话后就一直提示：Our servers are experiencing high traffic right now, please try again in a minute.
版本到最新1.22.2后，本地可以正常使用，远程还是不行，让opus 4.6排除了下问题，下面是他的回答：
在本地抓包 / 看进程（Local）： 本地同时跑着两三个 language_server 进程。关键在这里：部分进程指向的是测试/开发通道 daily-cloudcode-pa.googleapis.com，而另一些默默负责对话或核心功能的进程指向的是正式生产通道 cloudcode-pa.googleapis.com。所以本地用起来稳如老狗。
在远程服务器看进程（Remote）： 当 VS Code 客户端向远程推送运行参数时，默认把所有的 language_server 统统定死了走开发通道： --cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com。由于 Daily/Canary 通道本来容量就很小，全球那么多白嫖党和测试者在挤，它不限流谁限流。
Opus的解决方法：
既然问题出在由本地远程拉起的启动参数上，没法直接改 VS Code 插件源码，就在服务器端做一个替换壳（Wrapper）。
当 VS Code 想要拉起 language_server_linux_x64 时，先由我们的壳接管，对传进来的参数动一下手脚，把里面所有的 daily- 强行删掉，然后再转交给真正的程序去运行。
进入你的远程服务器（已经装好并运行过该插件），找到插件本体的目录。 一般在 ~/.antigravity-server/bin/[版本号]/extensions/antigravity/bin/ 或者 VS Code server 对应的 ~/.vscode-server/ 下。
执行下面的 Shell 动作（把原可执行文件备份为 .bak ，放入 Wrapper），改完之后断开远程连接重连一下就行了：
# 找到插件的 bin 目录
AGDIR=$(ls -td ~/.antigravity-server/bin/*/extensions/antigravity/bin/ | head -1)
cd "$AGDIR"
# 备份原始可执行文件
cp language_server_linux_x64 language_server_linux_x64.bak
# 写入 wrapper 脚本
cat > language_server_linux_x64 << 'EOF'
#!/usr/bin/env bash
# 把参数里的 daily 通道替换成生产通道
ARGS=()
for arg in "$@"; do
ARGS+=("${arg//daily-cloudcode-pa.googleapis.com/cloudcode-pa.googleapis.com}")
done
# 启动真正的程序（如果你的服务器需要走代理，在这里套一层）
# 不需要代理的情况：
exec "$0.bak" "${ARGS[@]}"
# 需要透明代理的情况（比如用 graftcp）：
# exec /path/to/graftcp "$0.bak" "${ARGS[@]}"
EOF
chmod +x language_server_linux_x64
```bash
网友解答：
--【壹】--：
（帖子已被作者删除）
--【贰】--：
（帖子已被作者删除）
--【叁】--：
已被封号，小心点，临时紧急用下可以，长期用会被识别为反代
--【肆】--：
不管怎么说，管用。看看能用多久。这也算反代。也没办法了。
--【伍】--：
（帖子已被作者删除）
--【陆】--：
我给佬友们试试水，先试几天，看看有没有问题
--【柒】--：
小心一点，这种方法可能会被标记为反代而打入反滥用（当然也不确定
正好佬友帮我试试水（bushi
下面是已经在佬友配置好翻墙的基础上进行的: 【方案】解决Antigravity连接远程服务器无法AI对话（无sudo权限）
从昨晚开始远程登录上ssh的对话后就一直提示：Our servers are experiencing high traffic right now, please try again in a minute.
版本到最新1.22.2后，本地可以正常使用，远程还是不行，让opus 4.6排除了下问题，下面是他的回答：
在本地抓包 / 看进程（Local）： 本地同时跑着两三个 language_server 进程。关键在这里：部分进程指向的是测试/开发通道 daily-cloudcode-pa.googleapis.com，而另一些默默负责对话或核心功能的进程指向的是正式生产通道 cloudcode-pa.googleapis.com。所以本地用起来稳如老狗。
在远程服务器看进程（Remote）： 当 VS Code 客户端向远程推送运行参数时，默认把所有的 language_server 统统定死了走开发通道： --cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com。由于 Daily/Canary 通道本来容量就很小，全球那么多白嫖党和测试者在挤，它不限流谁限流。
Opus的解决方法：
既然问题出在由本地远程拉起的启动参数上，没法直接改 VS Code 插件源码，就在服务器端做一个替换壳（Wrapper）。
当 VS Code 想要拉起 language_server_linux_x64 时，先由我们的壳接管，对传进来的参数动一下手脚，把里面所有的 daily- 强行删掉，然后再转交给真正的程序去运行。
进入你的远程服务器（已经装好并运行过该插件），找到插件本体的目录。 一般在 ~/.antigravity-server/bin/[版本号]/extensions/antigravity/bin/ 或者 VS Code server 对应的 ~/.vscode-server/ 下。
执行下面的 Shell 动作（把原可执行文件备份为 .bak ，放入 Wrapper），改完之后断开远程连接重连一下就行了：
# 找到插件的 bin 目录
AGDIR=$(ls -td ~/.antigravity-server/bin/*/extensions/antigravity/bin/ | head -1)
cd "$AGDIR"
# 备份原始可执行文件
cp language_server_linux_x64 language_server_linux_x64.bak
# 写入 wrapper 脚本
cat > language_server_linux_x64 << 'EOF'
#!/usr/bin/env bash
# 把参数里的 daily 通道替换成生产通道
ARGS=()
for arg in "$@"; do
ARGS+=("${arg//daily-cloudcode-pa.googleapis.com/cloudcode-pa.googleapis.com}")
done
# 启动真正的程序（如果你的服务器需要走代理，在这里套一层）
# 不需要代理的情况：
exec "$0.bak" "${ARGS[@]}"
# 需要透明代理的情况（比如用 graftcp）：
# exec /path/to/graftcp "$0.bak" "${ARGS[@]}"
EOF
chmod +x language_server_linux_x64
```bash
网友解答：
--【壹】--：
（帖子已被作者删除）
--【贰】--：
（帖子已被作者删除）
--【叁】--：
已被封号，小心点，临时紧急用下可以，长期用会被识别为反代
--【肆】--：
不管怎么说，管用。看看能用多久。这也算反代。也没办法了。
--【伍】--：
（帖子已被作者删除）
--【陆】--：
我给佬友们试试水，先试几天，看看有没有问题
--【柒】--：
小心一点，这种方法可能会被标记为反代而打入反滥用（当然也不确定
正好佬友帮我试试水（bushi