缓解 Antigravity Retry 错误 (Agent terminated due to error) 的一些实践

之前一直被 Antigravity 中 Claude Opus 4.6 执行时的 Agent terminated due to error 错误困扰, 严重影响我的开发体验, 于是尝试了以下方案:

我的开发环境是: Windows 10 宿主机使用 Antigravity 的 wsl 模式, 连接 wsl 中的 Ubuntu 22.04 虚拟机.

  1. 解决代理问题: Windows10 宿主机上 v2rayN 开启 TUN 模式 + Clear system proxy + 绕过大陆 + 美西节点
  2. 解决单次输出过长问题: 因为 Agent terminated due to error 不一定是因为单纯网络问题引起的, 即便 retry 日志里写了是 TLS 问题, 也有可能是单次输出过长导致 (尤其是 Antigravity 中的 Claude 系模型在单次写入文件超过 150 行时触发, 而且晚上的高峰期会加剧这个问题), 所以需要在 AI Rules 文件中增加对此的处理方案, 例如:
    • NEVER generate more than 150 lines of content in a single tool call (write_to_file, replace_file_content, etc.) — output token truncation corrupts tool-call JSON and causes agent termination. Pre-flight: estimate content lines before EVERY call; if > 100 lines, split first. Split strategies: (a) write_to_file ≤ 150 lines + replace_file_content to append; (b) multiple smaller replace_file_content calls; (c) split into multiple files.
    • ALWAYS cap command output for unbounded commands — pipe through | head -200 (or use --max-count, -n flags) for git diff, git log, build/install logs, etc. For background commands, read with OutputCharacterCount ≤ 10000.

使用这个方案之后, 每天的 retry 次数从 30-40 次下降到少于 10 次左右, 而且基本都是因为梯子本身的问题引起的. 不知道佬友有没有更好的方案可以彻底解决这个问题? 还是说需要更好的梯子?

15 个赞

补充一点, 根据 ChatGPT 和 Gemini 的讨论, 晚高峰的用户可以尝试日本节点来缓解 大陆-美西节点 之间出口带宽紧张的问题, 以降低延迟. 但日本节点的 codex cli 登录后可能会没有 gpt-5.4 的模型选项, 可以先用美国节点登录 codex cli, /model 切到 gpt-5.4 后再用日本东京节点.

不过这种方法仅限于 Google 提供服务正常的情况, 如果 Google 那边的 Opus 模型容量耗尽, 用户侧做什么都没用.

牛逼佬友,管用

1 个赞