用了差不多一个半月的 Antigravity我以为自己已经把它的脾气摸得差不多了。上周让它帮我优化一个 pandas 数据处理的脚本跑到一半会话窗口顶部毫无预兆地冒出一行红字Agent terminated due to error下面还跟着一句You can prompt the model to try again or start a new conversation if the error persists。我下意识点了重试结果连续两次都在相近的位置中断。后来经过一整轮控制变量排查终于定位到了触发条件也总结出一套能稳定绕开这个报错的用法。这篇文章就是完整的踩坑与解决记录给同样在用 Antigravity 写项目、被这个错误卡住的朋友做个参考。1. 报错出现的完整背景我在Antigravity里到底干了什么1.1 我的项目场景与交给Agent的原始任务当时我手头是一个偏本地的数据处理小服务Python 3.11技术栈主要是 FastAPI pandas openpyxl。目录结构不算复杂核心是这几个文件scripts/process_data.py业务主脚本负责读 Excel、清洗、聚合、导出tests/test_process.py基于 pytest 的回归测试requirements.txt依赖清单我在 Antigravity 的对话面板里给 Agent 下达了一个看起来非常正常的整合型任务原话大致是这样的帮我优化 scripts/process_data.py主要是把 pandas 的逐行处理改成向量化降低内存占用。 改完之后跑 tests/test_process.py 确认结果保持一致。 最后把 requirements.txt 里用不到的依赖清理一下。三个子任务优化、验证、清理依赖。从“人”的角度看这没什么问题就像让同事“顺便把工位收拾一下”。但在 Agent 的执行模型里这个 Prompt 已经隐含了很大的自由裁量权尤其是最后那个“清理依赖”直接指向删除型操作。后面我会详细说这一步恰恰是问题爆发的核心导火索。1.2 报错现场与完整提示文本Agent 一开始跑得很正常读文件、改代码、装依赖、跑 pytest过程大概持续了几分钟。就在它执行到“清理依赖”相关步骤时对话框上方突然出现了一行红色的错误状态Agent 的执行状态从 running 直接切成了 error。完整提示是这个样子Agent terminated due to error You can prompt the model to try again or start a new conversation if the error persists.标题里写的 “or star” 是复制时被截断了完整的措辞应该是or start a new conversation if the error persists。最有价值的信息往往不在红字本身而在红字背后的日志里。我点开错误区域附近的 agent logs 入口看到 Antigravity 把它整个执行过程存成了类似工具调用链的记录每一步模型发起了什么动作、工具返回了什么结果、下一步又基于这个结果做了什么事。日志中最后一条有效记录停留在一条和包管理相关的操作上再往后没有正常的“模型决策”直接就是错误状态。这个现象非常关键它说明 Agent 并不是在执行代码时被 Python 异常打断而是在“工具调用链”的某一次衔接处被框架强制熔断了。这两种报错的性质完全不同排查方向也完全不同。1.3 为什么我说“已解决”很多朋友看到“已解决”三个字会期待一个开关或者一句配置就能彻底屏蔽报错。但我这里说的已解决指的是我搞清楚了这个错误到底在什么条件下必然出现、什么条件下可以稳定绕开并且在后续两周的高强度使用中几乎不再被它中断。更直白一点Agent terminated due to error不是某一行代码的 bug它更像一个“熔断保护”。你没法让熔断器永远不跳闸但你可以让自己不要反复触碰那些让它跳闸的条件。理解这一点比抄到任何一条配置命令都重要。2. 第一轮排查Prompt触发安全标记还是上下文超出窗口2.1 先看子错误invalid prompt 与 usage policy 的指纹Antigravity 这类 AI IDE 和普通聊天工具不太一样它不只会把你的输入发送到模型还会在内部继续“自问自答”地生成下一轮工具调用计划。也就是说真正发给模型的 prompt 不只是你在对话框里打的那段话还包括系统给你的项目塞的上下文、文件内容摘要、工具返回结果以及模型自己生成的上一步动作描述。在多次重试的过程中我偶尔会在日志里看到这样一条标记invalid prompt: your prompt was flagged as potentially violating our usage policy.这条消息不是网络层拦截而是应用层的内容安全过滤在起作用。它意味着某一轮内部生成的消息被判定为“触发使用政策警告”于是这一次模型调用被认定无效整个 Agent 执行循环只能异常终止页面最终就呈现出Agent terminated due to error。我当时 Prompt 里最容易触发这个过滤器的句子是“把 requirements.txt 里用不到的依赖清理一下”。在模型的语义理解中“清理”“删除”“自动移除”这些动词叠加在一起会被安全策略判定为具有一定破坏性的操作从而在生成具体删除指令时提高拦截概率。这不一定每次都会发生但只要触发Agent 的整个链路都会受到影响。注意不是说“清理依赖”本身违规。这是正常的开发操作而是 IDE 的内容安全过滤策略在无法判断意图边界时会倾向于保守处理宁可让 Agent 停下也不让它带着模糊授权去执行删除类操作。2.2 再看长度prompt is too long 的临界点除了内容安全标记另一个高频嫌疑是上下文长度。很多人在 Antigravity 里遇到这个报错第一反应都是“是不是我的 prompt 写得太长了”但实际上这里的“太长”不是指你输入框里那几十行字而是 Agent 的“全部记忆”太长。Agent 每执行一步工具调用工具返回的内容都会追加到会话上下文中。比如pip install的下载日志、pytest 的测试输出、git diff的改动内容这些都会成为后续模型调用的一部分。换句话说即便你只在对话框里发了一句“继续”模型收到的东西也可能是几千行。我拿了一个不太恰当的比喻来描述这个状态你让一个厨师做菜一开始只是点了几个菜后厨却把整个菜单、所有食材进货单、历次试菜评分全部塞到他面前。等他做到第三道菜时案板上已经堆满了纸想不犯错都难。我在日志里看到的情况也是这样Agent 在执行测试阶段时pytest 输出少说也有一两百行紧接着又尝试分析 requirements.txt 的依赖关系整个累计上下文已经到了一个相当可观的长度。如果中间再有任何一个工具返回一个超大 JSON很快就能顶到上下文窗口的上限。2.3 排查手段把Agent对话拆成三个独立会话做对照定位问题不能靠猜。我把 Agent 的对话拆成几个独立会话做了四组控制变量实验实验组会话状态下达的 Prompt结果1保留原会话直接点重试原任务“优化测试清理”偶发中断且中断位置不固定2新开会话完整复述原任务原任务“优化测试清理”推进得更远但在“清理依赖”附近中断3新开会话只发优化子任务“优化 process_data.py 的逐行处理”稳定通过4新开会话改写清理描述“分析依赖引用列出疑似未使用的依赖并等我确认”稳定通过这个表格基本就是我的破案结论。第 1 组和第 2 组说明问题不完全是“旧会话历史太多”因为新会话也会挂第 2 组和第 3 组对比说明“任务范围太大、子任务太多”会显著提高出错率第 2 组和第 4 组对比说明“删除/清理”类的措辞比“列出/等待确认”更危险。所以最终排除了单一因素既不是代码本身的问题也不是单纯“会话太旧”而是“大任务 自动删除授权 长执行链”三者叠加共同把这个报错引爆了。热词里频繁出现的invalid prompt和prompt is too long恰好是这三个因素里的两个典型证据。3. 深层原因Agent执行链路里的“终止判定”是怎么被触发的3.1 Agent的工作循环与正常结束条件要理解这个报错必须理解 AI IDE 里 Agent 的执行循环。Antigravity 的 Agent 本质是一个“观察-行动-结果”循环模型接收当前的完整上下文包括用户指令、项目状态、之前工具返回的结果模型决定下一步动作比如读取文件、执行命令、修改代码工具运行并返回结果模型基于新结果再次做决策这个循环会一直持续直到模型生成一个“任务完成”的信号比如“我已经完成了所有修改并通过测试”。在正常运行情况下Agent 会给自己一个收尾总结然后整个状态变成 completed。但如果循环中某一步出了问题模型输出无法被解析、工具调用超时、命令返回异常代码且无法自动恢复、或者某一轮内部消息被内容安全过滤拦截Agent 就无法进入“任务完成”的正常出口。此时上层框架会强制终止整个执行循环并在界面上显示Agent terminated due to error。这个设计本身是有道理的它防止模型在一个越来越混乱的状态中无限循环下去也算是一种保护机制。但对于使用者来说提示信息过于笼统根本看不出是哪一环节出了问题。3.2 我在日志里看到的真实断裂点我后来反复翻日志试图还原那次报错的最后一帧。日志里的执行顺序大致是这样的读取scripts/process_data.py的代码生成优化后的代码写入文件执行pytest tests/test_process.py验证改动读取requirements.txt执行依赖分析命令准备识别未使用的包状态变为 error第 5 步到第 6 步之间没有正常的模型决策记录。从日志能看到 Agent 已经产生了“接下来要处理依赖卸载”的意图但在生成具体的卸载动作之前上下文里插入了一条被标记为无效的消息。接着整个执行状态被终止。我判断真实断裂点是模型在“计划删除某个依赖”与“内容安全过滤”之间撞上了。它可能生成了一个形如pip uninstall some-package的内部工具调用意图而这一意图触发了安全策略的保守判断于是整轮调用被拒Agent 无法继续。此外之前 pytest 和依赖分析产生的大量日志让上下文已经处于比较拥挤的状态进一步放大了出错的概率。所以不是某一行命令写错了而是“长上下文 删除型操作”同时命中。3.3 重试 vs 新会话官方提示的意图Antigravity 在错误提示里给了两条路try again和start a new conversation。这两条路背后的意图是完全不同的。try again适合瞬时故障。比如某一次工具调用因为网络抖动超时、或者模型输出解析失败这种问题在当前会话内重新让模型走一遍决策通常能顺利绕开。start a new conversation适合状态污染。如果上下文里已经堆积了大量无用的工具输出或者某几轮消息被安全过滤标记过继续在当前会话里重试只会让模型背着越来越重的包袱跑路不如直接开新会话。我用一个开车导航的类比来理解try again就像导航带你走错一个路口后重新规划路线只要地图数据没问题大概率能绕回来start a new conversation就像地图数据已经错乱、导航乱报这时候最理智的做法是关掉导航重新设置目的地。所以当你连续重试两三次仍然失败时别执着于“继续盘问同一个 Agent”果断开启新会话。我见过太多人被困在同一个报错里反复点重试纯粹是在消耗时间和 token。4. 三个能落地的修复方案与验证结果4.1 方案一缩小任务粒度用计划模式替代一次性大指令我的第一个改动是把“一个 Prompt 包办三个阶段”的做法彻底废掉。现在的习惯是每个 Prompt 只让 Agent 做一件足够小的事并且在涉及多阶段任务时明确要求它先出计划、再执行。改造后的任务下发方式是这样的请先分析 scripts/process_data.py 的当前实现列出你认为内存占用最高的 3 个点。 不要修改代码只输出分析和建议。等它给出分析后我再发下一条指令根据你刚才的分析开始优化第一个优化点。改完不要跑测试先让我看 diff。每一步都有明确边界每一步的上下文都被控制在一个相对干净的范围内。即使某一步出错损失也小最多重新执行一个子步骤。这个改动的核心逻辑是让 Agent 的上下文窗口保持在一个“健康水位”。它不需要记住“我刚刚装了哪些依赖、测试输出有多少行、改了几个文件”只需要聚焦当前这一步。上下文短模型决策就更稳定也就更不容易触发整体熔断。4.2 方案二重写Prompt避开内容审核误伤与歧义表达第二个改动是重写 Prompt 中所有涉及“删除”“清理”“自动完成”的表述。这里的关键不是不用中文或英文的问题而是语义边界要足够清晰。我举一个修改前后的真实对比修改前I want you to clean up the unused dependencies and remove all unnecessary files automatically.修改后List the dependencies that appear to be unused based on the current codebase. Wait for my confirmation, then show me the exact command to remove them.第一版其实是我很早期的 Prompt 风格看起来简洁直接但在安全过滤器和 Agent 的意图理解里都过于“粗放”。“clean up”“remove automatically”这类组合很容易被判定为破坏性操作的高风险意图。第二版把任务切成了两段第一步只是“列出”是只读操作第二步“等确认后显示命令”把最终决定权交回给我。这样既避开了安全过滤的误伤也让 Agent 不需要自己拍板去执行高风险动作出错概率明显下降。如果你确实希望 Agent 能自动执行删除类操作也可以在权限设置里为某个工具打开允许执行并在 Prompt 里明确说“我已经开启自动执行权限你可以直接卸载 xxx”。这里的重点是让“意图”和“授权”保持一致避免模型在“想做但不确定是否被允许”的状态下产生奇怪的决策。4.3 方案三给Agent限制权限与清理会话记忆第三个改动是重新配置了 Antigravity 里的工具执行权限并养成了“长任务分段开新会话”的习惯。在 Antigravity 的权限设置里通常可以给不同类型的工具设置允许、禁止、或每次询问。我现在的设置是文件读写允许终端命令执行默认询问包管理 / 依赖安装 / 删除类操作必须询问网络请求类必须询问这样设置有两个好处。一方面Agent 在执行高风险动作前会停下等我确认这给了我一个天然检查点另一方面强制“询问”本身会打断长执行链变相控制了上下文长度让它不会一条路跑到黑。同时我规定自己每完成一个阶段任务就开新会话。新会话虽然丢失了“记忆”但 Antigravity 可以通过项目文件来弥补。我把项目的关键信息写进了项目根目录的说明文件比如整体架构、常用命令、测试方式、注意事项。新会话的 Agent 启动时会自动读取它这样我根本不用靠旧会话的几百行历史去让它“回忆”项目背景。此外命令输出瘦身也很有用。比如安装依赖时让它用静默模式跑测试时只显示失败摘要或者把完整输出重定向到文件而不是全部塞回上下文。这对于防止上下文爆炸非常重要。pip install -q pandas pytest tests/test_process.py -q --tbshort 21 | tail -504.4 验证连续跑三次压力任务的对比结果方案都改完之后我重新拿同一个项目做了验证。所谓“压力任务”是连续让 Agent 完成“读文件、优化代码、跑测试、清理依赖”整条链路并且故意不让它分阶段汇报模拟之前出错的场景。结果如下执行方式第一次第二次第三次成功率一次性大指令 自动执行中断于“清理依赖”附近中断于“测试”阶段完成1/3拆四步 手动确认 无自动删除指令完成完成完成3/3这个对比足够说明问题。拆步骤、改 Prompt、限制权限这三件事组合在一起虽然不是百分之百保证永不报错但已经把中断率从三分之二压到了零连续多次长任务都没再遇到Agent terminated due to error。我要强调的是这不是一个严格基准测试只是日常开发中的经验观察。但它至少证明了一件事这个报错大概率不是 Antigravity 的随机抽风而是和你的任务组织方式强相关。5. 怎样减少Antigravity里同类中断我的日常预防策略5.1 任务拆解与验收节点设计我现在的每一条 Agent 任务都会尽量遵循同一个模板目标、范围、验收标准、确认时机。请完成以下任务分阶段执行每一阶段结束后停一下等我确认 1. 分析 scripts/process_data.py指出最耗内存的三个位置 2. 针对其中一个位置给出优化后的代码并展示改动 3. 运行 pytest 并报告结果 约束不要删除任何文件不要修改 requirements.txt这个模板的好处是目标明确不会让 Agent 自由发挥出“清理依赖”这种额外动作范围受限明确写出不做什么每个阶段都有验收节点我可以随时叫停上下文被阶段性截断模型不需要背负太多历史如果你是一个团队的负责人也可以把类似的约束写到团队的 Agent 协作规范里让每个人都按这个习惯使用 AI IDE。这样不仅报错变少代码 review 也会轻松很多。5.2 敏感操作主动改为手动确认很多人觉得Agent terminated due to error只是个烦人的提示但其实它更多时候是一张“安全网”。如果 Agent 在模糊授权下真的执行了删除操作而你的代码没有版本管理那损失就不是“多试几次”能弥补的了。我现在对删除、安装、重启服务、改配置这类操作一律保持手动确认。多一次点击看起来低效但它带来的稳定性和安全性远超那一点点摩擦成本。如果你恰恰需要 Agent 自动完成整个部署流程那也请先在权限设置里明确放行对应的工具和命令而不是让它在一个“默认禁止但模型没意识到被禁止”的状态下强行推进。模糊授权是 Agent 执行链最常见的断裂来源明确授权则能让它走得更顺畅。5.3 日志回看、会话健康度自查与兜底最后分享几个“自查动作”方便大家在遇到报错时不用像我当初那样从头猜到尾看到Agent terminated due to error先别急着重试。点开错误附近的 logs / session 入口看最后几条工具调用记录。如果最后一条是某个命令输出检查输出是不是特别长。若是考虑下次让 Agent 加-q或者21 | tail -N截断输出。如果日志中出现类似invalid prompt或flagged的关键字优先改写 Prompt 中涉及删除、清理、自动执行的措辞。如果几轮日志都正常、没有明显异常输出就把问题定位到“上下文过长”直接开新会话把当前目标重新描述一遍再继续。每次让 Agent 做重大修改前先确保代码在版本管理里处于可回滚状态。你可以让它先打个 tag或者自己手动 commit 一版。这个习惯能在 Agent 改出问题时让你一键回到稳定状态而不是困在报错里进退两难。我在实际使用中最大的体会是AI 编程工具的好处是它真的很能干活但它对“指令边界”的要求比人更高。你把任务拆清楚、把删改类动作管好、把上下文保持干净它就很少给你摆出那张红色的错误脸。如果你手里的 Antigravity 也时不时弹出这段提示先别急着怀疑模型能力从 Prompt 和会话状态入手排查大概率能找到和你情况对应的解法。