上周四下午工作群忽然热闹起来源头是一位同事甩出来的后台截图Antigravity 的模型列表里多出了 Opus 5.5 和 Sonnet 5.5 两个新名字。版本号升级并不让人意外真正让人意外的是官方的放号策略——页面上直接写明本批次仅向受邀用户和通过验证的商业账户开放。换句话说哪怕你此刻已经登录后台大概率也只是在模型列表里多看到两行名字申请按钮依然是灰的。我这次能提前入场有一部分运气成分。五月底我为一个内部数据治理项目提交过企业级实名认证平台生成第一批白名单时把我的账号划了进去于是拿到了大约两周的评测配额。这篇文章不打算复述发布文案只想把我实际跑出来的能力边界、申请路径以及一批只有真金白银踩过才会注意到的坑原原本本写出来。不管你是正在评估要不要申请还是已经拿到配额准备接入应该都能用得上。1. “不是谁都能用”的门槛拆开看其实是三层1.1 账号资质个人账号被挡在第一道闸门我手里同时有个人账号和企业账号这次测试对两边做了对比。结论是新模型在账户级别上做了严格分层个人免费账号能做的只有一件事——在模型详情页看看能力介绍。一旦直接调用接口服务端会返回一条明确的错误提示“当前账号未获得该型号的访问权限”连计费预览都不会给。这不是往请求里加一个参数就能越过的坎它绑定的是账户的整体资质。商业账户也不是默认就能调用所有新模型。我在后台的“模型访问管理”页面里看到商业账户需要手动开启“新模型试用”开关而这个开关能否出现取决于账户所属组织有没有被纳入平台的白名单体系。如果你所在组织不在合作列表里个人开发者想以个人身份申请基本会被驳回。唯一的例外是拿到某个认证组织的后台邀请由管理员把你加进白名单否则单纯走邮件渠道基本没有受理可能。1.2 配额与计费新模型 token 不占订阅额度第二道门槛藏在计费体系里。新模型默认只开放给月付订阅用户和 API 按量付费用户纯免费额度用户无法申请到配额 token。而且订阅套餐里自带的免费额度只能用于上一代模型新模型的 token 不会计入订阅额度需要额外按 token 计费。这一点特别容易误判。平台社区里已经有不少人发帖以为升级成付费订阅就能畅用新模型结果发现账单另算。官方没有太直白地解释原因结合经验看逻辑其实很简单新模型的推理资源占用远高于上一代如果新模型 token 混进订阅额度平台侧的算力成本根本无法回收。“限量放号 独立计费”本质上是一种资源隔离手段而不是单纯的商业包装。1.3 应用场景申报写清楚用途的人通过得更快第三道门槛是配额申请表单里的“预期应用场景”一栏。我观察到一个非常明显的差异认真写业务用途的申请通过率明显高于只写“测试”“学习”的空泛描述直接留空的基本会卡在审核环节。平台需要这个信息并不完全是为了审查你的代码。新一代模型推理时要动态分配显存和集群资源官方需要用申报信息预估未来一段时间的负载同时也能过滤掉单纯“看热闹”的流量。我当时填的是“用于内部知识库的长文档解析与抽取、指令遵循类任务的批量评测”提交后不到一天就通过了。身边一位只写“体验新模型”的朋友等了四天还没动静后来补了一封说明邮件才过。所以这个栏位真的会影响审核优先级值得认真对待。2. Opus 5.5 实测长文档和复杂推理是它的主场2.1 长文档解析150 页合同一次喂进去我第一项测试直接上了硬骨头一份 150 页的采购合同转成纯文本后大约 9 万字。任务要求在同一轮回答里完成三件事——提取所有违约责任条款、标注前后矛盾的表述、按风险等级输出摘要。关键约束是不允许提前分段不允许分多次追问。Opus 5.5 在单次推理内的表现没有让我失望。它不仅能“读”完这 9 万字还能准确指出合同第三十四页和第七十八页在违约金比例上的冲突。跨页定位这件事特别考验模型的记忆与注意力分配能力。我在对照组里用上一代模型跑同一份文档它在 6 万字左右就开始丢信息到第二阶段提取风险等级时还会把“高”“中”“低”三档弄混。从实际观测看Opus 5.5 的稳定工作长度大约在 20 万 token 量级。注意我说的是稳定工作长度不是上下文窗口上限。超过这个范围后召回率会缓慢下降但不会像旧模型那样突然“失忆”。这里要补一句提醒长文本“能用”和“好用”是两回事。即使模型撑住了 20 万 token实际返回时间也很可观。我那一次完整请求大约等了四分钟。如果放在面向用户的在线功能里这个时延必须做异步化和进度提示否则前端体验会非常糟糕。2.2 多约束推理规则越多差距越明显第二个测试是带约束的多步推理。我构造了一个包含 14 条业务规则的促销判定任务规则之间互相牵连比如“订单同时满足 A、B、C且金额超过 X但收货地址在 Y 区域时判定为不符合促销条件”。这类规则很容易被模型遗漏、搞混优先级或者因为顺序错乱而产生幻觉结论。Opus 5.5 在同一次回复里完成了 7 个虚拟订单的全部判定每条都给出了逐步推导过程。坦白讲它仍然有两条判定的说理不够干净但规则引用率和最终结论一致率已经比上一代高出一截。我的判断是多约束推理才是这次升级最值得关注的战场——日常对话、文案润色看不出什么差距一旦进入规则密集的业务场景新旧模型的分水岭立刻就会出现。2.3 代码改造更擅长“在约束下改系统”我也跑了代码用例但特意没有去测“从零生成一个项目”这类标准题那更多是宣传片式的好看离真实工程比较远。我换成了一个贴近实际的题目给定一个一千行左右的小型 CRUD 项目代码要求新增一个可导出 CSV 的接口并且补上单元测试。Opus 5.5 在理解已有架构这件事上表现相当成熟。它生成的接口没有硬编码而是复用项目里已有的依赖注入风格单元测试覆盖了正常返回和参数异常两条路径。对比上一代模型最明显的差异是旧模型偏向“把代码写对”5.5 偏向“在既有约束下把系统改对”。前者单点正确就算完成后者会主动考虑模块之间的耦合与一致性。做代码库维护和迭代类任务时这个区别会被持续放大。3. Sonnet 5.5别看它是轻量模型这是另一条产品线3.1 速度和成本高频业务场景的主力拿着 Opus 5.5 的表现我最初以为 Sonnet 5.5 只会是它的“低配版”跑完才发现这两个模型在定位上是两条产品线而不是简单的性能缩水关系。Sonnet 5.5 的响应速度大约比 Opus 5.5 快三倍。在同样一次推理调用里它更适合处理那些不需要高密度思考、但需要快速返回的高频任务比如客服意图识别、资讯摘要、批量文本分类。它的 token 单价也低出一大截我在一组 500 条短文本分类测试里对比过Sonnet 5.5 的总成本约为 Opus 5.5 的 35%而分类精度只差不到两个百分点。这个结果直接决定技术选型导向如果你的工作流里有一大堆短文本、重复度高的任务把流量引到 Sonnet 5.5 上比全部塞进 Opus 5.5 合理得多。3.2 工具调用连续 50 轮稳定不出错我特别关注它在生产环境里的确定性。构造了一套工具调用场景给模型暴露查询库存、创建订单、查询物流三个函数接口要求它自主完成“查库存→下单→查物流”的完整链路。Sonnet 5.5 连续跑了 50 轮没有出现一次错误函数名、漏传参数或者用错字段的情况。坦白讲这个稳定性表现让我重新理解了它在产品矩阵里的位置对于多数执行链短、逻辑固定的自动化流程Sonnet 5.5 反而比 Opus 5.5 更适合因为延迟低、出错率低整体运维成本更小。我甚至开始考虑把一部分原本挂在 Opus 上的轻量任务迁移过来。3.3 选型参考什么任务该用哪个我给自己定的选型标准很简单任务依赖长上下文或者规则密度高需要跨段落推理选 Opus 5.5。任务重复、延迟敏感、单次 token 量小选 Sonnet 5.5。举两个实际例子。让模型逐项核对几十页财务表格这是 Opus 的活实时处理每条不超过两百字的工单分类这是 Sonnet 的活。如果拿不准就先从 Sonnet 试跑效果不行再升级到 Opus试错成本远比反过来低很多。4. 从申请到接入我走通的完整路径4.1 申请前要准备的资料如果你替公司或实验室申请先把这几样备齐企业营业执照或单位证明文件、经办人实名信息、一个真实在用的业务域名——平台会对域名做所有权校验。个人开发者则需要一份来自已认证组织的邀请授权而且必须由组织管理员在后台发起申请个人自己发邮件很难走通。我们团队在这里踩过很典型的一个坑第一次申请时填了领导姓名但领导没有做过实名验证系统直接把申请驳回。后来改成经办人本人的实名信息才顺利进入审核队列。记住表单里的身份信息必须和当前登录账户的验证信息完全一致不要想当然写负责人。4.2 提交入口与填写要点提交入口在控制台的“模型访问管理”页面。选择目标模型后表单里几个关键项我的填写思路如下填写项建议写法注意事项应用场景写具体业务如“长文档合同抽取、内部知识库问答”避免只写“测试”“学习”月调用量按当前业务真实量估算可略高预留增长空间但也别夸张到不可信计费方式勾选按量付费新模型 token 不进入订阅额度组织域名填写已验证的正式域名个人申请需附上组织邀请授权这次我的申请从提交到通过大约用了 18 小时身边有朋友等了 3 到 5 个工作日更大的组织审批可能更慢。建议把“预计三个工作日”作为排期基线不要因为申请迟迟没反应就去反复催催了也没用。4.3 拿到配额后的第一件事冒烟测试拿到配额后千万不要急着切生产流量先在一个隔离项目里做冒烟测试。我的固定顺序是新建一个专用 API 密钥方便单独统计新模型的成本。调用一次接口确认模型名能正确解析。发 5 条最短的推理请求验证延迟和计费记录。发 1 条超长输入验证超时配置和流式响应是否正常。把这一圈走完计费、网络、超时的问题基本都会在第一批请求里暴露出来。而且冒烟测试期间随时可以切回旧模型不会被新模型绑定住。5. 配额落地以后真正的坑才刚开始5.1 计费口径单价低不等于成本低新模型有一个容易被忽略的计费口径输入与输出的 token 单价差异比上一代更大长上下文输入的成本占比极为突出。我做 9 万字长文档测试时单次请求的成本大约是同 token 量短文本任务的 30 倍。这在旧模型里很少出现但在新模型里因为要一次性读完长文本输入 token 会堆得很快。如果你的业务本质上就是“处理长文档”建议策略性地做分块先把文档切成合理小节用 Sonnet 5.5 做小节预处理再用 Opus 5.5 做跨段综合。这个方案里成本与效果之间能找到一个更好的平衡点而不是把整本内容直接一次性投喂。5.2 并发与超时别拿旧参数硬套新模型新模型的响应时间明显比旧模型更长尤其是在长任务上。我第一次接入时直接沿用了旧模型默认的十秒超时配置结果长文档请求全部超时失败。改成流式响应加三分钟超时之后才稳定跑通。如果你要做批量任务还要重点关注并发限制。我实测到的新模型默认并发上限大约是旧模型的一半也就是说同一时间打进来的更多请求会被排队而不是立即执行。平台文档对这部分写得不细需要自己在压测里摸索一个合适的并发数不然线上随时可能出现请求堆积。5.3 版本号与回滚模型名别写死在代码里Antigravity 的模型名采用日期后缀机制比如opus-5.5-20250612。这样设计本意是为了支持版本回滚但很多人会把模型名作为常量直接写死在代码仓库里升级时反而被卡住。我的习惯是在配置文件里统一维护模型别名# config.py MODEL_OPUS opus-5.5-20250612 MODEL_SONNET sonnet-5.5-20250612平台更新修版或出补丁版本时只需要改配置不需要动业务代码。这个习惯看起来很小真出事故时能省下大把时间尤其是在你需要把某一条业务链路临时切回旧版本的时候。5.4 跑分数据与真实体感以业务指标为准最后说一个比较扎心的现象跑分提升明显的任务不一定是你最关心的任务。我在长文本摘要类测试里看到跑分提升了 15%但人工评审的可读性只提升了 5%而带格式约束的输出任务里跑分只提升了 8%实际格式错误率却下降了超过一半。所以官方公布的跑分只能作为入场参考。最终要不要替换现有模型必须拿自己的历史业务数据做测试集用自己的验收标准来投票。数据量不必太大但要有代表性覆盖正常、边界、异常三类输入这样的评估结果才有说服力。6. 限量放号背后是模型发布策略的变化6.1 为什么要刻意制造“稀缺”一开始我也觉得“不是谁都能用”是一种商业化包装后来从配额申请和资源调度角度重新理解才发现它本质上是一道容量分配题。新一代模型推理时的显存与算力占用明显高于上一代如果直接全员放开首批集群根本扛不住流量服务质量必然崩盘。把配额切成批次优先保护已签约客户的使用体验是运营层面的必然选择。但这不代表它没有营销成分。稀缺性客观上拉高了新模型的市场期待也给平台争取到了筛选高质量用户的窗口。对于开发者来说理解这个逻辑之后就不会把“申请不到”简单归因于自己不够格而是更理性地规划申请时间线和替代方案。6.2 开发团队如何应对“版本卡位”这次上线暴露出来一个很现实的问题如果团队每次都是等新版本发布了再来临时抱佛脚会非常被动。我建议至少做三件事第一把模型访问权限当成需要定期维护的资产。各家平台的白名单、配额、验证状态都可能变化建议建一张表定期巡检别等到真要用时才发现某个账号已经失效。第二建立模型切换开关。无论灰度还是回滚都要有独立于业务逻辑的入口保证任何版本更新都能一键切换而不是临时改代码发版。第三内部维护一套业务评测集。别看外部跑分直接用自己积累的历史数据做模型准入判断。有了这套东西新版本发布当天你就能知道该不该跟。6.3 我的判断和下一步打算接下来我会把两个点作为主线用 Opus 5.5 做强约束场景的规则引擎与长文本治理用 Sonnet 5.5 替掉现有的高频分类管线。第二批测试还在扩大样本量成本、时延、准确率这三项指标需要在真实负载下再看一轮才敢下结论。最近我在推进切换计划时反而很“慢”因为我给自己加了个硬条件每个模型都要有自己的内部评测集和回滚草案评测不过就继续原地等。这段经历让我对“限量放号”也有了新的理解——资源有上限时团队才会老老实实把模型用明白如果上来就全员开放反而容易大水漫灌上线很久都不知道效果到底好不好。