News Hacker|极客洞察

607 20 小时前 discuss.ai.google.dev
😡Google 因 OpenClaw 利用 Antigravity OAuth 封禁 Pro/Ultra 订阅用户,触发零预警与定价/隐私争议
付钱买订阅却被永久封号,这算客户关怀吗?

🎯 讨论背景

OpenClaw(一个开源 agent/集成项目)被发现以 Antigravity(Google 的 Gemini IDE/订阅端点)的 OAuth 凭证或模拟调用访问后端资源,Google 称大量异常用量与恶意流量导致服务退化,因而限制了 Antigravity/Gemini CLI 的访问。争议核心在于:订阅是 first‑party 客户端优化并被部分补贴(依赖 prompt caching、配额设计),而第三方工具打破了该经济模型;Google 的零容忍与无预警永久或长期封禁、客服不可达,以及对主账号潜在连带风险,激起大量用户和开发者不满。讨论同时涉及技术检测(调用模式、cache hit 率、调用序列)、商业定价(subscription vs PAYGO API)与更大的监管/反垄断议题(例如欧盟的 DSA),并推动部分人考虑隔离账号、付费 API 或自托管开源模型作为替代。

📌 讨论焦点

Google 的理由:滥用、恶意流量与资源保护

Google 宣称大量恶意或非预期的流量通过 Antigravity 后端被第三方工具消耗,严重降级了对正规用户的服务质量,官方内部有人表示必须快速切断这些流量以保护有限容量。评论里也指出订阅往往被补贴,first‑party 客户端通过 prompt caching 等优化显著降低成本,而第三方绕开官方客户端会以更低代价烧掉大量 token,加剧后台压力。另有安全维度:凭证外泄或被冒用(token exfiltration / impersonation)会扩大滥用范围,使得自动化检测与强制措施在工程上具有紧迫性。社区中支持这一理由的观点以降低系统滥用与保护普通订阅用户为核心论据。

[来源1] [来源2] [来源3] [来源4]

处罚过重与客户支持失败

大量评论认为 Google 的执行过于激烈:用户在没有充足事先警告、分级惩罚或可行申诉渠道的情况下被“永久”剥夺 Antigravity/Gemini CLI 的访问权,甚至封禁决定措辞为“zero tolerance”。被禁用户还抱怨在账号受限期间仍被收费、官方沟通混乱、客服难以触达,造成极强的信任与恐惧效应,很多人担心主 Google 账号或长期积累的数据会因此受影响。多数意见主张应采用递进式措施(警告→限流→暂停→最终封禁)并为付费用户提供人工复核与退款/计费替代方案,而不是直接零容忍永久封禁。

[来源1] [来源2] [来源3] [来源4] [来源5]

OpenClaw 的技术实现与 OAuth 冒用

技术细节讨论集中在 OpenClaw 如何利用或复用 Antigravity 的 OAuth 流程:有证据显示 OpenClaw 在授权时弹出的是“Sign in with Google Antigravity”的窗口并取得返回的 token,或直接使用 Antigravity 的 client_id/重定向来冒充官方客户端。桌面类公用客户端采用 PKCE 等公开流程使得 client secret 无法保护本地凭证,导致令牌在客户端被截取与重用变得可行。Google 方面据称通过调用模式、流量与低 cache‑hit 行为等启发式规则识别异常,但这些检测也可能带来误判与解释困难。

[来源1] [来源2] [来源3] [来源4]

订阅 vs API 的商业与技术差异(补贴、prompt caching)

讨论强调 Pro/Ultra 等订阅并非等同于按量 API:厂商以低价或补贴订阅换取使用数据与用户留存,官方客户端可通过 prompt caching、统一提示和 UX 设计显著降低每次推理成本。第三方工具常生成高基数、低重复性的上下文(例如加上时间戳或每次不同的系统 prompt),造成缓存命中率下降、缓存抖动(cache thrashing),从而把单用户成本放大到数倍甚至 10x 以上。因此厂商将订阅限定为“仅用于官方客户端”,并将自动化、高吞吐量场景导向按量付费 API,用户批评在价格与限额透明度上存在缺陷。

[来源1] [来源2] [来源3] [来源4]

用户对策与替代路径(隔离账号、自托管或换供应商)

面对封禁与不透明的客服流程,评论里常见的用户对策包括:用独立测试账号隔离风险、用 Google Takeout 备份数据,以及尽量用官方 API keys/按量计费而非用订阅 OAuth 令牌绕道。长期看,很多开发者提到转向 OpenAI、Anthropic、国产开源模型(如 Kimi、Minimax)或自托管开源权重以避免被大平台的政策一刀切影响。也有人建议寻求法律或监管途径(例如 DSA 或小额诉讼)对抗平台滥用权力,但短期内迁移与自托管是更现实的逃逸路径。

[来源1] [来源2] [来源3] [来源4]

监管、反垄断与长期市场影响

部分评论将此事上升为平台力量与反竞争问题,认为把补贴流量限定给 first‑party 客户端是生态锁定(walled garden)策略的一部分,可能触及反垄断与监管关注。讨论提到欧盟 DSA/法律干预以及拆分巨头的呼声,担忧长期会把开发者和用户推向更开放或更廉价的替代品,改变市场格局。评论者还指出短期强硬策略会带来声誉损害和 Streisand 效应,反而可能促成更多用户离开并扶持开源生态。

[来源1] [来源2] [来源3]

📚 术语解释

OAuth: 一种开放授权协议(OAuth),用于用户授权第三方应用代表其访问服务的令牌机制。讨论中关键点在于 OpenClaw/第三方通过 OAuth 获取或复用 Antigravity 的 access token 来调用后端,从而绕过官方按量计费的 API 途径。

Antigravity: Antigravity:Google 提供的第一方 IDE/客户端与订阅端点(绑定 Gemini 模型的消费入口),厂商为其用户在官方客户端上补贴配额与优化。厂商把 Antigravity 视为专属通道,禁止用其订阅令牌为外部工具提供无限制服务。

OpenClaw: OpenClaw:一个开源的 agent/集成项目(用于把 LLM 当作个人助理或自动化 agent),争议在于部分实现利用 Antigravity/Gemini 的 OAuth 令牌或模拟调用以绕开按量 API 计费并大幅增加后端调用量。

Gemini CLI: Gemini CLI:Google 提供的命令行客户端,用于在本地/脚本中访问 Gemini 模型。官方渠道与直接调用私有端点在授权、配额与可观测性上有所不同,厂商允许通过 CLI 的受控途径但反对被第三方滥用 OAuth 令牌直接调用内部 API。

prompt caching: Prompt caching:服务端对常见 prompt + 上下文结果的缓存优化,可显著降低重复推理成本。first‑party 客户端广泛利用此优化,第三方工具若频繁变更上下文会导致缓存命中率下降、成本非线性上升。

Agent SDK / agentic IDE: 指用于构建自治 agent 的 SDK 或 IDE(例如 Claude Code 的 Agent SDK),这类工具把 LLM 作为可编排执行引擎,若用订阅 OAuth 在第三方场景大量自动化调用,会触及订阅用途与定价的边界。

429(rate limit): HTTP 429:Too Many Requests 的状态码,代表被限流或速率限制。评论中多次提到 Pro/Ultra 用户在高负载或低优先级时遭遇 429,作为容量不足或后端限流的证据。