Antigravity报错Agent terminated due to error的排查与解决指南

最近用 Antigravity 跑一个多文件联动的自动重构任务跑到一半任务面板突然冒出一行红色错误提示Agent terminated due to error You can prompt the model to try again or start a new agent.说实话看到 You can prompt the model to try again 这种提示我第一反应是有点恼火——它等于什么都没说。我点了重试任务运行几分钟后又挂再重试还是挂而且每次都在差不多的位置中断。后来我把 Antigravity 的日志、网络链路、项目环境和上下文长度全部过了一遍才彻底定位到根因。如果你也遇到同一个报错别急着删掉项目重来。这个错误只说明一件事Agent 在执行过程中失去了继续运行的必要条件。这篇文章会把我的排查路径、定位方法和最终解决方案完整写出来按顺序走一遍大概率能救回你的任务。1. 先从报错本身看懂 Agent 的运行机制1.1 这个提示通常在什么场景下出现Antigravity 本质上是一个接入了大模型的 AI 编程工作台Agent 模式下它会自己读项目文件、改代码、执行命令、查看运行结果再根据结果继续下一步。前台是你在编辑窗口里看到的对话与文件变更后台其实是一场“模型反复调用 本地环境执行”的循环。只要循环里任何一环断了Agent 就会终止。我遇到的这个报错在下面几类场景里出现频率最高长时间跑自动化重构、批量改文件、跨模块迁移这类任务Agent 动作很多一次任务可能持续十几分钟甚至更久。Agent 在调用外部命令时卡住比如npm install、git rebase、pytest这类耗时命令命令没结束Agent 一直在等结果等超时。项目体量大相关文件多Agent 每次读取的内容已经把上下文窗口塞得很满越往后越容易失稳。网络链路出现抖动或者模型服务端响应超时前端没有收到预期返回就会顺手判个 terminated。在这些场景里“模型能力不够”其实很少见真正常见的反而是外部条件变化。所以排查思路不要一开始就怀疑 Agent 的模型水平而是先围绕“执行环境是否还健康”来做判断。1.2 错误信息逐句拆解到底谁把 Agent 终止了把这条报错拆开看信息量其实不小。第一句 Agent terminated due to error主谓结构很清楚Agent 被终止了原因是 error。但它没有说是哪一步的 error是模型返回异常还是本地命令失败又或者是工具链调用超时这些情况在界面上都只对应同一句提示所以必须靠日志才能区分。第二句 You can prompt the model to try again or start a new agent这是 Antigravity 给的两条后续路径一个是让当前 Agent 重试一个是新开一个 Agent。注意它这里用的词是 start a new agent不是 continue the conversation说明官方也默认当前 Agent 的现场可能已经不可靠了比起死磕现场重新开 Agent 并带上必要上下文往往是更省力的选择。还有一个小细节错误信息里没有附带具体的错误码或错误原因这一点很坑。别的工具一般会给个 stack trace 或 error codeAntigravity 这里就是一句话等于把排查成本都丢给了用户。所以后面我才会强调第一步永远是去翻 Agent 日志而不是反复点重试。2. 我排查后整理出的四类问题根因2.1 网络链路不稳定Agent 和模型服务端之间的对话中断Agent 任务和普通问答不一样普通问答只需要一次请求断了再发一次就行。但 Agent 任务是一次长会话中间会穿插大量工具调用每调一次工具模型就要重新看一次结果。整个链路对网络的连续性要求很高哪怕中间只断几秒后台模型请求超时任务就很容易被判失败。我那次任务就出现过这样的情况Agent 在改完一个文件之后等待模型返回下一步指令结果等了很久没反应然后直接 terminated。后来看网络监控当时的出口网络确实有短暂波动但波动幅度很小普通浏览网页根本感受不到只有这种长连接、高频率请求的场景才会暴露出来。这里要特别提醒如果你在公司网络、共用网关或者有严格防火墙规则的环境下使用 Antigravity长任务中断的概率会明显变高。很多情况下不是 Antigravity 的问题而是中间某一层设备把长连接断掉了。排查时可以这样确认报错时间点前后其他需要持续联网的服务是否也出现了卡顿或断开。如果答案是肯定的那就先处理网络稳定性再去折腾工具配置。2.2 上下文超限模型“聊断了线”另一个高频原因是上下文超限。很多项目刚上手时不大但 Agent 跑着跑着每轮都要读文件、看 diff、回顾之前的决策历史消息越来越多。当上下文接近模型窗口上限时模型服务端会直接拒绝新的请求或者返回一个格式异常的结果前端拿到的不是正常响应就会把 Agent 终止。我遇到过一种很典型的表现任务跑到后半程Agent 开始反复修改同一个函数但每次改完都说“我看到了问题现在修复”然后下一次又重头分析一遍。这个现象基本就是上下文太满、模型开始“丢失”早期信息的信号。这时候如果不干预接下来大概率就是 terminat ed due to error。判断上下文是否超限可以从几个地方看任务界面里有没有上下文占用比例的显示Agent 每次回复的内容是否开始重复前面的分析或者任务中途是否出现过明显变慢、响应延迟变高。如果命中其中一两个就要考虑拆任务了而不是继续硬跑。2.3 项目环境和命令执行异常第三类原因出在本地环境。Agent 在替你执行命令时如果遇到权限不足、依赖缺失、端口被占用、文件被锁定这类情况命令会以非零状态退出。Antigravity 内部的执行器在捕获到异常退出后有可能直接中止整个 Agent 链条。举个例子。有一次我在跑一个自动化脚本Agent 需要往某个目录写入临时文件但该目录的权限是只读的执行写入时报了 permission denied。这个报错本身并不致命但 Agent 的错误恢复能力有限它尝试了一次重试还是失败最后就终止了。所以如果你的任务涉及系统目录、受保护路径、特殊权限文件一定要提前确认当前用户对这些位置有足够权限。另外项目里的长驻进程、调试端口、数据库连接也可能成为罪魁祸首。Agent 执行测试时如果端口被占用启动失败报错信息不直观Agent 自己往往也意识不到是环境问题只会反复重试直到超时终止。遇到这类情况手动在终端里复现一遍 Agent 执行的命令通常比看界面提示更有效。2.4 账号登录态与会话过期这一点很容易被忽略。Antigravity 这类工具普遍采用云端账号体系本地工具通过登录态来换取模型服务访问权。如果登录态过期了界面可能不会立刻弹窗提示因为你打开软件时是正常的但跑到某个节点要重新换取令牌时就会发现凭证失效请求被服务端拒绝Agent 就会在一次失败后被终止。我自己曾连续踩过两次一次是隔了一晚上第二天直接继续昨天的任务跑了五分钟就报错另一次是切换了系统网络环境之后登录态校验异常。排查方法很简单——到设置或账号页面看登录状态是否正常或者干脆退出登录再重新登录一次。如果你同时开了多个 Antigravity 实例也要留意不同实例之间的会话是否冲突多开状态下我遇到过旧实例的会话覆盖新实例的问题。3. 完整排查流程从报错到恢复的逐个排除3.1 第一步打开日志看 Agent 最后一次做了什么拿到报错后我第一件事不是点重试而是打开任务日志。Antigravity 的任务详情页里通常能看到每一步动作的记录包括读取了哪些文件、执行了什么命令、命令的退出码是多少。如果日志里能看到最后一步是“执行某个命令”然后戛然而止那大概率就是命令执行阶段出了问题如果最后一步是“等待模型响应”之后报错那重点看网络和模型通道。如果界面日志不够细还可以看本地落盘日志。Antigravity 的日志目录一般在用户目录下的.antigravity/logs或者系统日志目录里各平台路径会略有不同。在终端里用tail -f盯住日志文件然后重新触发一次任务复现报错能看到的细节比界面上多得多。这一步能帮你把问题归入“模型链路问题”“命令执行问题”还是“会话问题”避免后续瞎猜。这里有个经验之谈看到 terminated 并不可怕可怕的是在不知道最后动作的情况下去重试。每一次重试都会重新消耗上下文和请求额度如果根因是环境问题重试多少次都没用只会把现场搞得更乱。3.2 第二步用最小请求验证模型链路是否正常定位到大概方向后第二步是验证模型链路通不通。我用的方法是新建一个空白会话发一条很简单的消息比如“请只回复 hello”看模型能否正常返回。如果这么简单的请求都失败或者长时间无响应说明模型链路肯定有问题如果最小请求正常问题就出在原来任务本身的复杂度上。还有一种情况是最小请求正常但一旦让 Agent 开始读项目文件、执行命令就立刻报错。这种时候问题多半在项目侧比如某个文件编码异常、目录结构太过复杂、或者有循环依赖导致 Agent 反复解析。我建议把项目切成一个最小可复现目录把无关文件移出去再让 Agent 跑一个简单任务如果不再报错就慢慢加文件直到复现为止。这是最笨但最可靠的方法。一个小技巧验证模型链路前先看一下 Antigravity 的版本是不是最新的。旧版本在某些模型接口调整后会存在兼容问题表现也是 Agent 跑到一半终止。把工具更新到最新版再跑一轮能排除掉一部分产品层面的 bug。3.3 第三步刷新登录态清理残留会话模型链路没问题的话登录态就是下一个排查点。操作上很简单退出当前账号重启 Antigravity再重新登录。重新登录后老会话里的令牌通常会刷新之前因为凭证过期导致的请求失败大概率会被解决。我自己的习惯是长任务开始前先看一眼账号状态如果是周期较长的任务比如跨天干脆设置一个任务中途的检查点不要一口气让 Agent 跑到底免得跑了大半后因为会话过期全部白费。另外如果你开了多个设备同步注意一下不同设备上的会话是否互相干扰我之前在笔记本和桌面端同时登录出现过一边退出导致另一边会话失效的情况。清理残留会话也很重要。Antigravity 的历史任务会保存很多上下文数据如果同一个项目下有大量残留 Agent 会话新任务在初始化时可能会扫描到这些旧数据拖慢启动速度甚至在极端情况下引起异常。我每隔一段时间就会清理不再需要的旧会话只保留最近几个活跃的这个习惯帮我少踩了不少坑。3.4 第四步拆分任务缩减单次上下文如果以上都排除了问题还剩一种可能任务本身太大Agent 一次处理不了。解决办法就是拆分。把原来一个大的重构任务拆成几个阶段每个阶段单独开一个 Agent 会话前一个阶段结束后把关键结论写成文档或 README下一个阶段基于这个文档继续。这和微服务拆分的思路一样——每个 Agent 只干一件事上下文干净失败影响范围也小。拆分任务时我会在提示词里明确告诉 Agent 它只负责哪个模块、不需要看哪些目录。这样能减少 Agent 无谓的探索也降低上下文压力。比如“只处理 src/utils 目录下的文件不要读取 node_modules 和 test 目录”指令越明确Agent 越不容易跑偏。还有一个实用技巧在长任务进行中如果发现 Agent 开始重复分析同一个问题及时打断并让它“基于已经改完的内容直接说出下一步”。这种主动干预能防止上下文继续膨胀也能把 Agent 从“反复横跳”的状态里拉出来。4. 任务恢复的两种实操姿势4.1 直接让当前 Agent 重试什么情况下值得点界面上的 try again 并不是完全没用但它适用的场景很有限。我总结下来只有两种情况值得点一种是错误发生时 Agent 没做任何实质改动任务状态还是完整的重试只是重新发起一次请求另一种是错误原因明显是暂时性的比如模型服务端超时过几秒服务恢复后重试就能接上。反之如果 Agent 在终止前已经改了好几个文件、执行了一系列命令那我一般不直接重试。因为你不知道它终止在哪一步有一些改动可能已经落盘但没告诉你有问题贸然重试可能导致重复改动或者状态冲突。这种时候查看当前工作区的 diff 比点重试更有用。让我判断是否重试的另一个参考是错误发生的位置离任务起点有多远。刚跑两步就挂了重试代价低试试无妨跑到后半段挂了重试很可能还会挂在同一个地方不如直接开新会话。4.2 新建 Agent 并携带关键上下文更稳的选择大多数情况下新建 Agent 是更稳妥的恢复方式。但要注意新建不是从零开始而是要把上一个 Agent 已经取得的关键结论带过去。我通常的做法是先让上一个 Agent 在终止前把阶段性成果输出成一个文档然后新 Agent 的提示词里写明“请先读这个文档再继续做某件事”。如果你没有让它输出中间结论那就自己从对话历史里摘出关键信息。比如已经改了哪几个文件、改了什么逻辑、下一步打算干什么。把这些整理成 5 到 10 条要点粘到新会话里。这样新 Agent 不需要重新扫描全部代码也能快速接上进度。另外新会话建立后我会把项目目录中 Agent 不需要关心的部分在提示词里明确排除避免新 Agent 一上来就把整个项目读一遍。这一招对大型项目尤其有效能显著降低上下文占用和首次响应时间。5. 常见问题速查表与我的避坑心得5.1 快速定位表按现象找解决办法错误现象优先排查方向建议动作任务运行十几分钟后固定位置报错上下文超限、项目某文件异常拆分任务精简上下文检查最后读的文件Agent 执行命令后马上终止命令权限不足、环境依赖缺失手动在终端复现命令看退出码最小请求都无响应模型链路异常、工具版本过旧更新 Antigravity重启后测试跨天继续旧任务时报错登录态过期退出重新登录刷新会话网络抖动期间反复终止网络链路不稳定稳定网络后重试尽量避开高峰时段多个实例同时打开时报错会话冲突关掉多余实例只保留一个工作台这张表基本覆盖了我遇到过的绝大多数情况。你可以先按“错误现象”锁定一行再按“建议动作”操作大多数时候能在 10 分钟内恢复任务不用把整个流程都走一遍。5.2 几条经验能避一个是一个第一长任务一定要有中间产出。不要让 Agent 闷头跑完整个任务再汇报而是要求它每完成一个阶段就输出一段小结或者把关键改动写入 CHANGELOG。这样即使中途报错你手里也有完整的进展记录新开 Agent 时能迅速接上。第二不要同时让 Antigravity 干太多并行任务。有人喜欢开个 Agent 改前端开另一个 Agent 改后端本意是提高效率但实际结果是两个 Agent 同时读写同一份代码冲突时互相覆盖报错概率成倍上升。我后来强制自己同一个项目同一时间只跑一个 Agent遇到长任务就耐心等整体效率反而更高。第三善用“暂停”而不是“终止”。如果我预计要离开一会儿会先把任务暂停而不是让它继续跑。暂停后的任务恢复时上下文还保留着比 terminated 之后重建现场要省事得多。实在需要离开又不想暂停的至少确认任务路径上不会有什么意外。第四养成看日志的习惯。无论这次问题是怎么解决的事后把日志导出看一眼记录一下报错前后的关键事件。积累几次之后你会发现自己对 Antigravity 的行为模式越来越熟悉很多报错一眼就能定位到原因。这个 Agent terminated due to error 的问题困扰了我大概一周中间也一度想过是不是工具本身太不稳定后来才发现多数时候是我自己没把任务环境和上下文管理好。工具本来就有它自己的能力边界学会顺着它的机制去设计任务报错自然就少了。如果你也正在被这个提示折磨按上面的顺序排一圈应该很快能找到答案。