Gemini、Opus、GPT 多模型协作实践与 Antigravity 报错排查
把 Gemini、Opus、GPT 放在同一个任务里互相评审，效果到底如何？本文整理一次真实的多模型协作观察：三个模型各自擅长什么、为什么 Gemini 显得格外亢奋，以及 Antigravity 中反复出现「Agent terminated due to error」时的排查顺序与可落地的分工流程。
让几个大模型对同一个任务互相评审、彼此挑错，已经成了一种常见用法。实际跑起来会发现，模型之间确实存在风格差异：有的擅长铺开知识面，有的擅长把方案拆成能执行的步骤，还有的话很多但偶尔冒出别人没想到的角度。真正影响体验的往往不是模型能力，而是协作到一半时客户端突然中断。
一个典型场景是这样的：同一份任务同时交给 Gemini、Opus 和 GPT，让三方互相点评，结果讨论质量还不错，但 Gemini 所在的 Antigravity 客户端频繁弹出「Agent terminated due to error / You can prompt the model to try again or start a new conversation if the error persists」，整个流程被迫反复重来。下面把这两个问题分开说。
三个模型在协作中的典型表现
从多次互评的输出来看，三者的差异大致可以这样归纳（具体表现和版本强相关，模型迭代很快，以下只是使用体感，不是基准测试结论）：
| 角色 | 常见表现 | 适合放在哪一环 |
|---|---|---|
| Opus | 知识面广、论证完整，倾向先把方向讲清楚，再谈细节 | 方案评审、风险梳理、边界条件检查 |
| GPT | 偏向落地，输出计划、步骤、代码和验收标准 | 任务拆解、实现、写测试 |
| Gemini | 输出活跃，喜欢总结协作氛围，但时常提出另外两个都没提到的角度 | 头脑风暴、找新视角 |
有意思的是互评时的措辞倾向：Opus 倾向于肯定对方的执行力，GPT 常常认可方向但强调不能照搬，Gemini 则容易写成「真是一场完美的三方协作」这种带抬头和落款的信。这不是能力问题，更多是对齐策略带来的表达风格——模型被训练得更愿意给出正向、热情、结构化的社交式回答。
问题在于，这类内容会稀释信息密度。多模型协作的成本本来就高，如果一轮输出里有一半在互相夸奖，实际收益会被摊薄。所以不要把「谁更礼貌」当成判断依据，只看它有没有给出新的、可验证的信息。
「Agent terminated due to error」到底是什么
这句提示是客户端 Agent 循环中断后的通用兜底文案，本身不包含原因。它只说明这一轮 agent 没能正常跑完，可能发生在连接、上下文、工具调用、配额任何一环。常见触发点按出现频率排列：
- 网络链路不稳：流式响应被中途切断、长连接被代理重置，最容易表现为「跑着跑着没了」。
- 上下文过长：多模型互评会把前面所有输出都堆进上下文，几轮之后长度迅速膨胀。有人提到该客户端的上下文限制偏小，也有说官方会翻倍，这类数字随版本变化很快，请以官方最新文档为准。接近或超出上限时，客户端可能直接终止而不是优雅降级。
- 工具调用失败：Agent 执行文件读写、搜索、终端命令时某一步超时，或返回了无法解析的结构。
- 限流与配额：短时间内高频重试、并发多个会话，容易撞到限制。
- 客户端自身缺陷：特定版本、特定操作组合下的 bug，换版本或换客户端就消失。
排查顺序（从低成本到高成本）
- 开新会话重试一次。如果新会话能正常跑，基本可以确定是上下文或历史状态的问题，而不是账号或网络。
- 缩小输入。把整份日志、整个文件全文换成关键片段，去掉无关的历史讨论，只保留任务目标、约束、验收标准。
- 测链路质量。把命令里的地址换成你实际访问的服务域名，观察 DNS、连接、TLS、首字节各阶段耗时：
curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n' https://your-endpoint
如果首字节耗时波动很大，或者隔一段时间就失败，问题多半在网络上，换线路或换更稳定的出口再试。代理节点频繁切换、会改写流量的中间层，都是常见诱因。 4. 减少并行工具调用。一次只让 agent 做一个动作，确认是哪一步失败。 5. 更新客户端，再查一下是不是已知问题；换一个同类任务跑，判断是特定操作触发还是全局性中断。 6. 换执行环境。如果任务是长时间连续跑的（比如整晚挂着做代码重构或多轮评审），本地机器休眠、Wi-Fi 掉线、代理进程重启都会打断 agent 循环。这种情况下把任务放到一台长期在线的远程机器上执行是可选做法之一，例如整台 Mac mini 放在新加坡机房、按月租用、远程连接的方案，网络出口相对固定，适合需要长时间保持会话的 agent 任务。但它只解决「运行环境不稳定」这一类原因，上下文超限、客户端 bug 换机器也没用。
把「交火」做成可复用的流程
与其让三个模型自由聊天，不如按阶段分工。一个比较省成本的排班方式：
| 阶段 | 目标 | 建议做法 |
|---|---|---|
| 发散 | 拿到尽可能多的角度 | 各模型独立产出，不给彼此的输出，避免被带偏 |
| 对齐 | 统一数据口径、约束、验收标准 | 人工或单模型汇总，写死输入定义和边界 |
| 互评 | 找漏洞和分歧 | 只交换结论和假设，不交换全文 |
| 执行 | 产出代码与文档 | 选偏执行的那个当主力，其余只做 review |
| 收尾 | 整理成可交付文档 | 用输出最「接地气」的模型统一文风 |
配套的提示词约束很关键，可以直接写进系统提示：
- 不要复述他人已说过的内容，不要评价协作过程本身；
- 只输出三类内容：新增信息、明确分歧、需要验证的假设；
- 用固定小节省略客套，例如「结论 / 依据 / 风险 / 待验证」。
另外，互评轮次不要贪多。两到三轮之后边际收益明显下降，而 token 成本线性上升，更麻烦的是模型之间会互相强化同一套错误前提，越聊越自信。
分歧与取舍
关于 Gemini 的定位，看法差别很大。一种观点是它只适合当气氛组，上下文偏短、容易一本正经地编，放在主力位置不靠谱；另一种观点是它确实聪明、有闪光点，只是不适合压最终责任。比较稳妥的折中是把两者结合：发散阶段用它找角度，事实核验和最终交付不交给它。有人的工作流是头脑风暴用多个模型，主力产出交给执行力强的，写文档收尾交给文字最落地的那个，这个思路值得借鉴。
几条通用注意事项：
- 任何模型给出的 API 参数、版本号、价格、配额都不要直接采信，一律回官方文档核对，尤其是「某某限制只有 16K」这类说法，版本一变就失效。
- 多个模型同时给出相同结论，并不等于结论正确，可能只是共享了同一段错误上下文。
- 报错信息里的「重试」只是缓解，连续重试失败时应该停下来定位原因，而不是继续消耗配额。
- 客户端稳定性与模型能力是两件事，评价一个工具前先分清是壳的问题还是模型的问题。
小结
多模型协作的收益来自视角差异，成本来自上下文膨胀和无效社交式输出。把流程拆成发散、对齐、互评、执行、收尾五段，每段指定一个主责模型，再用提示词压掉客套话，就能把大部分「热闹但没用」的部分砍掉。至于 Agent terminated due to error，先按「新会话 → 缩输入 → 测链路 → 减工具调用 → 换版本 → 换运行环境」的顺序排查，多数情况能在前三步定位到原因。
