背景：源码审计卡在“出不出内网”
团队做 Python 代码审计和补丁修复时，真正麻烦的不是模型会不会写补丁，而是源码不能随便出内网。中等仓库的审计任务会把文件内容、调用链、测试输出一起塞进上下文，云端 Token 消耗和泄露面同时放大。谷歌在 Antigravity SDK 里给了一种拆法：高层规划留在云端，代码密集型执行压到本地。其演示针对三个存在漏洞的 Python 模块，约 3400 个 Token 中只有 95 个用于云端规划，97.2% 在本地消耗，并且没有源代码上传到云端（InfoQ 中文报道）。这不是“本地模型替代云模型”，而是把职责切开。
方案：架构师在云，构建者在本地的取舍
Antigravity SDK 的核心是“架构师—构建者”模式。架构师在云端，只看任务描述和文件名，不看源码，负责拆解依赖、架构约束和实施计划；构建者在本地并行执行漏洞复现、补丁生成、补丁审查、回归测试。纯云端方案的问题是源码和测试输出必须出网，隐私边界靠脱敏和合同，工程上不好控；纯本地方案的问题是高阶规划和跨文件推理吃模型能力，全压本地会把硬件门槛变成瓶颈。
谷歌初步实现通过 LiteRT 运行 Gemma 4 26B A4B，也支持通过 LocalOpenAIAgentConfig 接 OpenAI 兼容的本地推理服务，例如 Ollama、LM Studio、vLLM。关键取舍很直接：本地模型能力上限、24GB+ 显存或统一内存门槛、云端只拿元信息时的规划质量。还要分清 Antigravity SDK 与 Antigravity IDE：前者用于编程式构建代理，后者是共享底层代理基础设施的集成开发环境。
实现要点：先切边界，再配本地端点
落地时先把本地推理服务起成 OpenAI 兼容端点，再在 SDK 里把云端架构师和本地构建者分开配置。公开资料没有展开完整字段，下面给的是按 LocalOpenAIAgentConfig 语义写的配置骨架；字段名以实际 SDK 类型定义为准，但边界别改：云端不读源码，本地只拿任务包。
architect:
runtime: cloud
model: <云端规划模型>
input: [task_description, file_manifest]
source_access: false
builders:
- runtime: local
backend: openai_compatible
base_url: ${LOCAL_BASE_URL}
model: ${LOCAL_MODEL}
memory: 24GB+
tasks: [reproduce_bug, propose_patch, review_patch, run_regression]
git ls-files '*.py' > file_manifest.txt
export LOCAL_BASE_URL="http://<本地推理服务地址>/v1"
export LOCAL_MODEL="<Gemma 4 26B A4B 或兼容模型>"
curl -s "$LOCAL_BASE_URL/models"
把 file_manifest.txt 和任务描述交给云端架构师，源码只留给本地构建者；回归测试也在本地跑。这样云端拿到的是“改哪个文件、做什么任务”，不是文件内容。
效果：Token 账和隐私边界一起看
按同一审计任务做对照，不把未公开的延迟和费用写成结论：
| 观测项 | 纯云端编排 | 混合编排（谷歌演示） | | 源码上传 | 需要 | 无 | | 云端 Token | 未给出 | 95 | | 本地 Token 占比 | 无 | 97.2% | | 总 Token | 未给出 | 约 3400 | | 本地硬件门槛 | 无 | 24GB+ |
这组数据说明两件事：云端只承担少量规划 Token，代码密集型阶段留在本地；源码不上传后，隐私边界从“相信对方”变成“架构上不传”。但社区质疑也要听：97.2% 的 Token 在本地，不等于在你的硬件上更快或更便宜。补丁接受率、运行时间、能耗和云 Token 占比要一起测，24GB+ 显存或统一内存也是实际门槛。
复盘：最贵的教训是别把 Token 占比当收益
最贵的教训是不要把本地 Token 占比当成投入产出。Token 只说明调用位置，不说明补丁质量；本地模型补丁接受率低，返工会吃掉收益。另一个坑是架构师看不到源码，任务描述和文件名就是接口契约，文件名混乱会让规划失真。24GB+ 门槛还会筛掉一批开发机，团队要先盘点硬件再推广。
还能怎么改：按敏感度路由，公开依赖和测试脚本可上云，业务源码留本地；给构建者补上补丁接受率、回归通过率、运行时间、能耗等指标；高难任务保留云端兜底，但只传脱敏后的错误摘要和接口签名。最后，把 SDK 和 IDE 分清楚：要编程式搭代理用 SDK，不要拿 IDE 的体验当 SDK 能力。