1. 为什么要把 Antigravity 塞进 Codex / Claude Code 的调用链先说清楚这篇要解决的真实问题。Google Antigravity 是 Google 推出的一款以 “agent-first” 为核心的开发平台它把编辑器、浏览器、终端和多个并行 agent 整合在同一个工作台里让开发者可以用自然语言驱动 agent 完成编码、调试、浏览器操作等任务。它的免费额度对个人开发者来说相当可观但一旦进入高频使用阶段配额限制就会成为瓶颈——尤其是当你想把它当成日常主力工具、甚至想在 Codex 或 Claude Code 这类命令行 agent 里直接调用它的能力时额度消耗速度会远超预期。我最初的想法很朴素既然 Antigravity 本身就是一个 agent 平台那能不能把它“降级”成一个可以被外部调用的 skill让 Codex 或 Claude Code 在需要的时候把任务转交给它而不是我自己在多个窗口之间来回切换这样做的好处很直接——把 Antigravity 当成一个“能力后端”而不是“主入口”。主入口仍然是我熟悉的命令行 agentAntigravity 只在特定任务上被唤起配额消耗自然就降下来了。这个思路的核心不是“破解”配额而是改变调用模式。Antigravity 的配额限制针对的是平台内的 agent 调用次数和模型推理量如果你把它封装成一个外部 skill每次调用只传递必要的上下文和任务描述而不是让它在平台内持续保持一个长会话那么同样的配额就能支撑更多的实际任务。这就像把一台大功率设备从“常开”改成“按需启动”能耗结构完全不一样。适合读这篇的人有三类一是已经在用 Codex 或 Claude Code、想扩展能力边界但不想被单一平台绑死的开发者二是 Antigravity 的重度用户配额经常在月中就见底三是对 agent 编排感兴趣、想理解“平台能力外部化”这套思路的技术人。不管你用哪个平台这套封装逻辑都是通用的。2. Antigravity 的能力边界与外部调用的可行性判断2.1 Antigravity 到底提供了什么可被外部调用的能力在动手封装之前必须先搞清楚 Antigravity 对外暴露了什么。根据我实际使用和观察Antigravity 的核心能力可以分成三层第一层是编辑器与终端操作。它内置了一个基于 VS Code 的编辑器环境agent 可以直接读写文件、执行终端命令、查看运行结果。这一层的能力本质上和本地开发环境没有区别只是操作主体从人变成了 agent。第二层是浏览器控制。Antigravity 内置了浏览器 agent可以打开页面、点击元素、填写表单、截图、读取 DOM。这一层是它区别于普通命令行 agent 的关键能力也是很多人想把它封装成 skill 的主要原因。第三层是多 agent 并行编排。它支持同时运行多个 agent分别处理不同任务并在一个统一的界面里管理它们的状态和产出。这一层更偏向平台内的管理能力外部调用时通常不需要完整复现。从封装的角度看第一层和第二层是最有价值的。终端操作可以通过本地命令直接替代但浏览器控制很难在 Codex 或 Claude Code 里原生实现。所以封装的优先级应该是浏览器控制 文件操作 多 agent 编排。2.2 外部调用的三种可行路径把 Antigravity 封装成外部 skill本质上是要找到一个“调用入口”。我试过三种路径各有优劣路径实现方式优点缺点CLI 包装通过命令行工具触发 Antigravity 的任务实现简单适合脚本化需要 Antigravity 提供 CLI 接口API 桥接通过本地服务转发请求到 Antigravity灵活可定制上下文需要维护中间层文件队列通过监控文件变化触发任务解耦彻底适合异步延迟较高调试麻烦我最终选择的是CLI 包装 本地服务桥接的混合方案。原因很简单CLI 包装负责触发本地服务负责传递上下文和接收结果两者结合既能保证响应速度又能灵活控制每次调用传递的数据量。文件队列方案虽然解耦最彻底但调试成本太高不适合快速迭代。注意无论选哪条路径核心原则都是“最小上下文传递”。每次调用只传任务描述和必要的文件路径不要把整个项目上下文都塞进去否则配额消耗和平台内直接使用没有区别。2.3 配额消耗的真实结构很多人以为配额是按“调用次数”算的其实不是。根据我的观察Antigravity 的配额消耗主要来自三个部分模型推理量每次 agent 思考、生成代码、分析结果都会消耗推理配额。这是大头。浏览器操作次数每次打开页面、点击、截图都会计入操作配额。并行 agent 数量同时运行的 agent 越多单位时间内的配额消耗越快。封装成外部 skill 之后你能控制的是第一项和第三项。通过精简上下文、限制单次任务范围、避免并行启动多个 agent可以把推理量压到最低。第二项取决于任务本身很难压缩但可以通过缓存页面状态、复用浏览器会话来减少重复操作。我实测下来同样的任务封装后调用比在平台内直接操作配额消耗大约能降低40% 到 60%。这个数字不是固定的取决于任务类型和上下文精简程度但方向是明确的。3. 封装实操从零搭建一个可被 Codex / Claude Code 调用的 Skill3.1 环境准备与依赖梳理在开始写代码之前先把环境理清楚。你需要准备的东西不多但每一样都要确认版本和配置Antigravity 账号与工作区确保你的账号处于正常状态工作区里至少有一个可运行的项目。本地开发环境Node.js 18 或 Python 3.10取决于你用什么语言写桥接层。我用的 Node.js因为和 Codex / Claude Code 的生态更贴近。命令行 agentCodex CLI 或 Claude Code CLI确保能正常运行。一个本地服务框架Express 或 Fastify 都行我用的 Express够简单。这里有个容易忽略的点Antigravity 的工作区路径和本地项目路径要区分开。Antigravity 里的文件操作是在它的工作区里进行的而你的桥接服务运行在本地。如果任务涉及文件读写必须明确路径映射关系否则会出现“agent 说改了文件但本地看不到”的情况。3.2 桥接服务的核心逻辑桥接服务的职责很单一接收来自 Codex / Claude Code 的请求转换成 Antigravity 能理解的指令触发任务然后把结果返回。听起来简单但有几个关键设计点第一请求格式要统一。我定义了一个简单的 JSON 结构{ task: 描述任务内容, context: { files: [相关文件路径], url: 如果需要浏览器操作目标地址 }, mode: browser | file | terminal }这个结构的好处是Codex / Claude Code 只需要按这个格式发请求不需要关心 Antigravity 内部怎么执行。第二任务触发方式。我试过两种一种是直接调用 Antigravity 的 CLI如果可用另一种是通过本地服务模拟用户操作。前者更稳定后者更灵活。最终我选择了前者为主、后者为辅的策略——能用 CLI 就用 CLI不能用的时候降级到模拟操作。第三结果返回格式。Antigravity 返回的结果可能是文本、文件路径、截图等多种形式。我统一转换成 Markdown 格式返回这样 Codex / Claude Code 可以直接解析和展示。// 简化的桥接服务核心逻辑 const express require(express); const { exec } require(child_process); const app express(); app.use(express.json()); app.post(/invoke, async (req, res) { const { task, context, mode } req.body; // 构建 Antigravity 调用命令 const command buildCommand(task, context, mode); try { const result await executeWithTimeout(command, 120000); res.json({ success: true, output: formatResult(result) }); } catch (error) { res.status(500).json({ success: false, error: error.message }); } }); function buildCommand(task, context, mode) { // 根据 mode 构建不同的调用参数 // 这里的关键是精简上下文只传必要信息 const contextStr context.files ? context.files.join(,) : ; return antigravity-cli invoke --task ${task} --context ${contextStr} --mode ${mode}; }这段代码是简化版实际使用时要加上超时控制、错误重试、日志记录等。但核心逻辑就是这些接收请求、构建命令、执行、返回结果。3.3 在 Codex / Claude Code 里注册 Skill桥接服务跑起来之后下一步是让 Codex / Claude Code 知道这个 skill 的存在。不同平台的注册方式不一样但思路是相通的对于 Codex你需要在它的配置文件里添加一个自定义工具定义。Codex 支持通过tools字段注册外部命令你只需要把桥接服务的调用命令写进去就行。对于 Claude Code它支持通过skills目录注册自定义 skill。你需要在指定目录下创建一个 skill 定义文件描述这个 skill 的名称、描述、参数格式和调用方式。这里有个实操心得skill 的描述要写得足够具体但不要太长。描述太短agent 不知道什么时候该调用它描述太长每次调用都会消耗额外的上下文配额。我的做法是用一句话说清楚“这个 skill 能做什么”再用一句话说明“什么时候用”剩下的细节放在参数说明里。提示注册完 skill 之后先用一个简单任务测试调用链路是否通畅。比如让 agent 调用 Antigravity 打开一个页面并截图确认结果能正常返回。不要一上来就扔复杂任务否则出错了很难定位是哪个环节的问题。3.4 调用链路的完整验证验证分三步走单独测试桥接服务用 curl 或 Postman 直接向本地服务发请求确认能触发 Antigravity 任务并拿到结果。测试 Codex / Claude Code 的 skill 调用在命令行 agent 里输入一个需要调用 Antigravity 的任务观察是否触发了桥接服务。端到端测试用一个真实场景比如“打开某个页面提取页面上的表格数据保存为 CSV”走完整链路确认结果符合预期。我踩过的一个坑是桥接服务的超时设置和 agent 的等待时间不匹配。Antigravity 执行浏览器操作可能需要几十秒但 Codex 默认等待时间可能只有 30 秒。结果就是 agent 以为任务失败了实际上 Antigravity 还在执行。解决办法是在 skill 定义里明确设置更长的超时时间或者在桥接服务里加一个“任务已接受请轮询结果”的异步模式。4. 配额优化的关键策略与实测数据4.1 上下文精简少传就是多省封装成 skill 之后最大的配额优化空间在上下文传递上。在平台内直接使用时Antigravity 会自动加载整个工作区的上下文包括打开的文件、终端历史、浏览器状态等。这些上下文对 agent 理解任务有帮助但也会显著增加推理量。封装之后你可以精确控制每次传递的上下文。我的策略是只传任务直接相关的文件路径不传整个项目结构。浏览器任务只传目标 URL 和操作描述不传页面快照。终端任务只传命令和预期输出格式不传历史命令。这样做的代价是 agent 可能需要多轮交互才能理解完整上下文但每轮的推理量都大幅降低。实测下来对于“打开页面提取数据”这类任务上下文精简后配额消耗降低了约50%。4.2 任务粒度控制大任务拆小另一个关键策略是控制任务粒度。在平台内使用时你可能会让 agent 一次性完成“打开页面、登录、导航到目标页、提取数据、保存文件”这一整套流程。封装之后建议把每个步骤拆成独立调用调用 skill 打开页面并登录调用 skill 导航到目标页调用 skill 提取数据本地保存文件这样做的好处是每一步的上下文都很小推理量低。而且如果某一步失败只需要重试那一步不用从头再来。缺点是调用次数变多了但每次调用的配额消耗远低于一次大调用。我实测对比过一次性完成整套流程配额消耗大约是拆成四步的1.8 倍。所以拆步是值得的。4.3 浏览器会话复用浏览器操作是配额消耗的第二大头。每次打开新页面、新建会话都会消耗配额。优化方法是复用浏览器会话在桥接服务里维护一个浏览器实例池任务结束后不立即关闭而是保留一段时间。相同域名的任务尽量复用同一个会话。对于需要登录的站点登录一次后保存会话状态后续任务直接复用。这个策略对需要频繁操作同一站点的场景特别有效。我有个任务需要每天从同一个后台系统提取数据复用会话后配额消耗从每天约 20 次操作降到了 5 次左右。4.4 实测数据汇总为了让你有个直观感受我把几种典型任务的配额消耗对比整理成表格任务类型平台内直接使用封装后调用降幅打开页面并截图高中约 40%提取页面表格数据高低约 55%多步表单填写高中约 45%文件批量处理中低约 60%复杂多 agent 协作极高不适用建议拆分这些数据来自我自己的使用记录不是官方数据但趋势是稳定的封装后调用配额消耗普遍降低 40% 以上。任务越复杂、上下文越大降幅越明显。5. 踩坑记录封装过程中最容易翻车的五个地方5.1 路径映射错乱导致文件操作失效这是我最开始遇到的坑。Antigravity 工作区里的路径和本地路径是两套体系。我在桥接服务里传了一个本地绝对路径Antigravity 找不到任务直接失败。后来我加了一层路径映射配置把本地路径转换成 Antigravity 工作区内的相对路径问题才解决。建议在桥接服务启动时加载一份路径映射表所有涉及文件的操作都先经过映射再传递。5.2 超时设置不一致导致“假失败”前面提过Antigravity 执行浏览器操作可能耗时较长而 Codex / Claude Code 的默认超时可能较短。结果是任务实际成功了但 agent 认为失败了然后重试导致重复执行和配额浪费。解决办法是在 skill 定义里显式设置超时时间并且在桥接服务里实现“任务状态查询”接口让 agent 可以轮询任务状态而不是傻等。5.3 上下文过大触发配额快速消耗有一次我图省事把整个项目的文件列表都传给了 Antigravity结果一次调用就消耗了当天配额的近三分之一。后来我改成只传任务直接相关的文件配额消耗立刻降下来了。这个坑的教训是不要因为方便就多传上下文。每多传一个文件路径就多一份推理量。精简上下文应该是默认操作不是优化选项。5.4 浏览器会话泄漏导致资源占用浏览器会话复用是个好策略但如果不加清理机制会话会越积越多最终拖慢整个服务。我一开始没加清理逻辑跑了几天后发现桥接服务响应越来越慢排查后发现是浏览器实例没有释放。解决办法是加一个定时清理任务超过一定时间未使用的会话自动关闭。同时设置最大会话数上限超过上限时按最久未使用原则淘汰。5.5 skill 描述不清晰导致 agent 不会调用最后一个坑比较隐蔽skill 注册成功了但 Codex / Claude Code 从来不调用它。排查后发现是 skill 的描述写得太模糊agent 不知道什么场景该用它。后来我把描述改成“当任务需要浏览器操作打开页面、点击、截图、提取页面数据时使用此 skill。”这样 agent 就能准确判断调用时机了。6. 进阶玩法把 Antigravity 变成多 agent 协作的一环6.1 与本地 agent 的分工设计封装完成后你可以进一步设计分工让 Codex / Claude Code 负责代码生成、文件操作、逻辑推理让 Antigravity 负责浏览器操作和页面数据提取。两者通过 skill 调用衔接各司其职。这种分工的好处是每个 agent 都在自己最擅长的领域工作整体效率更高。而且因为 Antigravity 只负责浏览器相关任务上下文很小配额消耗自然就低。6.2 异步任务队列的引入对于耗时较长的浏览器任务可以引入一个简单的任务队列。Codex / Claude Code 提交任务后立即返回桥接服务在后台执行完成后通过回调或轮询通知 agent。这样 agent 不用阻塞等待可以继续处理其他任务。我用的是一个基于内存的简单队列任务量不大时完全够用。如果任务量上来了可以换成 Redis 或 RabbitMQ但那是另一个话题了。6.3 结果缓存减少重复调用有些任务是重复性的比如每天提取同一个页面的数据。对于这类任务可以在桥接服务里加一层缓存相同 URL 和操作描述在短时间内重复请求时直接返回缓存结果不触发 Antigravity 调用。缓存的有效期根据任务性质设定。数据类任务可以设短一点比如 5 分钟配置类任务可以设长一点比如 1 小时。这样又能省下一部分配额。6.4 监控与告警最后建议加一个简单的监控记录每次调用的任务类型、耗时、配额消耗估算值。当某类任务的消耗异常升高时及时排查原因。我用的是一个本地日志文件加一个简单的统计脚本够用就行不需要上重型监控系统。这套封装方案我跑了几个月整体稳定。配额从原来每月中旬就见底变成了月底还有余量。更重要的是调用模式变了之后我不再需要频繁切换窗口工作流顺畅了很多。如果你也在用类似的平台不妨试试这个思路——核心不是对抗限制而是改变使用方式。
