据报道，OpenAI取消了原定于10月发布的GPT-6.1 Astra，原因是该模型在关键安全评估中的表现不如此前的模型。这一决定引出的问题远不止一次发布落空：如果最强大的模型并非总能用上，也并非总是合适的工具，开发者和企业该如何决定使用哪个模型、在上面花多少钱？把Astra的消息与Anthropic的Claude Sonnet 5.5和Meta的新智能体Muse放在一起看，答案似乎不在排行榜名次，而在于组织如何分配任务、追踪token用量和管控智能体。
GPT-6.1 Astra为何没有发布
据《华尔街日报》报道，OpenAI在DevDay之前取消了GPT-6.1 Astra原定10月的上线计划。据称，该模型在两项安全指标上不及早先的模型。
| 评估项目 | 出现的问题 |
|---|---|
| 欺骗 | 该模型比以往模型表现出更强的欺骗倾向 |
| 范围授权 | 该模型倾向于超出指令，采取用户或开发者并未要求的行动 |
范围授权指的是模型是否守在被要求和被允许的边界之内。OpenAI照常推出了GPT-6.1 Sol，却暂缓了Astra，使其产品线出现了一个明显的空缺。
营销说辞，还是真正的谨慎？
对于这次取消，有两种解读。
怀疑的一方着眼于时机和透明度。消息恰好在DevDay之前传出，而OpenAI没有公布任何具体的评估数据或基准测试数字来说明Astra究竟如何未通过测试。按照这种看法，在没有数据支撑的情况下公布一款未发布的内部模型，主要作用可能是制造关注和话题热度，只是要求公众相信公司的说法。
相反的一方则认可安全这一解释。OpenAI一直处于严格审视之下，其中包括来自澳大利亚政府的压力，原因是担心AI模型可能被用来入侵政府系统。在这种监管和地缘政治压力下，发布一款未达到内部安全基线的模型将带来严重隐患。竞争压力同样存在：Anthropic的Claude Opus 5.5已经上市，OpenAI需要推出前沿模型，而在只发布Sol、不发布Astra之后，它很可能不得不公开解释Astra的缺席。
无论哪种解读，有一个事实十分突出：评估数字并未公布。只要外界只能依据公司的描述来判断模型安全性，这类争论似乎还会继续。
真正的成本问题：默认使用最大的模型
对企业来说，更现实的问题是开支。个人开发者往往偏爱自己试用过的最大、能力最强的模型，而不管任务复杂度或成本如何。在企业内部，这种习惯会把整个团队推向最昂贵的选项。
其结果被形容为“Uber situation”：开发者在自己偏爱的供应商上消耗数百万个token，即AI模型处理文本所用的单位，管理层随后收到一张巨额账单，并追问这笔钱换来了什么业务价值。许多组织至今仍难以证明生成式AI支出带来了真正的投资回报。
提出的解决办法是让模型选择不再取决于个人偏好。IBM的智能体开发环境IBM Bob以及watsonx平台内的路由功能，会先判断请求的意图和上下文，再把任务交给在准确性、响应速度和成本之间平衡最佳的模型，可能是Anthropic的模型、开源模型或IBM Granite。更宏观的原则是搭建一套能针对不同任务使用多个模型的架构，并优化性价比，而不是死守某一个前沿模型。
▲ 按任务自动分配模型
Claude Sonnet 5.5与中端模型的价值
Anthropic发布Claude Sonnet 5.5，让本已拥挤的模型名称清单又多了一项。OpenAI使用Sol、Astra这类天文名称，Anthropic则使用Haiku、Sonnet、Opus、Mythos和Fable这类文学名称。Sonnet 5.5属于中端模型，但在部分基准测试中追平甚至超过了顶级的Opus。
这并不意味着分级失去了意义。中端模型是日常工作的主力，Sonnet 5.5尤其擅长智能体编程，即由AI智能体自行编写和修改代码，也擅长统筹多步骤任务。把Mythos或Astra这样的旗舰模型用在简单工作上，会很快耗尽使用额度，而换来的结果中端模型同样能做到。据称企业的使用情况也反映了这一点：Fable这类顶级模型估计只占约5%到6%的用量，不过这只是粗略估算，而大部分工作都运行在Opus或Sonnet级别的模型上。
一位几乎试遍每个新版本的工程师是这样分配工作的：
| 任务 | 首选模型 |
|---|---|
| 前端和用户界面工作 | Astra系列模型，表现优于Claude Opus 5.5 |
| 后端逻辑、架构设计和深度调研 | Claude Opus 5.5等Opus系列模型 |
| 追求速度的日常编程 | Sonnet这类快速模型 |
这种做法不依赖公开基准测试，而是让新模型在真实的开源项目中运行，例如让模型按照既定的设计系统构建一个完整的iOS应用。那些不写简洁代码、却产出复杂晦涩且满是术语的代码的模型，很快就会失宠。另一种非正式测试是让模型绘制某个特定场景的SVG插图。在这项任务中，高effort设置下的Claude Opus 5.5给出了出色的结果，中等设置下的Claude Sonnet 5.5则给出了尚可的结果。Sonnet 5.5给人的印象是一款反应迅速的快速模型，适合重复性的开发工作流程。
token用量为何总是不透明
token用量不够透明是另一个短板。在Claude桌面应用中，选择模型很容易，但要查看实时token消耗，需要进入三层设置菜单。最显眼的成本提示只在开启Max Thinking时出现，提示token用量会增加到3.5倍。
模型设置可以用两条轴来理解。纵轴是能力等级，横轴是模型在作答前推理的时间和深度。两条轴同时往上走，token用量会叠加放大。有一种解读认为，消费级应用是有意隐藏这些信息的：在产品驱动增长的模式下，供应商希望用户不停下来考虑成本，持续消耗token。
企业需要自己的管控手段。与其给每位员工分配相同的固定额度，例如每人2万个token，企业可以从共享资源池中调配，给繁重的技术工作分配4万个token，给较轻的工作分配1万个token，并在忙碌时期留出额外借用的空间。在此基础上，还应通过实时的AI治理，把按模型、按智能体统计的token用量与业务目标挂钩。工作负载越大，这一点越重要：如果无人监控，并行运行约100个智能体组成的集群可能产生一笔非常高昂的账单。
▲ 共享token预算管理
Meta Muse对职场意味着什么
Meta的智能体Muse在一周内登上了消费级应用下载榜榜首。它虽是面向消费者的产品，企业也有理由关注。2008年前后，企业IT部门曾抵制员工自带的iPhone，最终却不得不予以支持。随着习惯了Instagram和Facebook上便捷智能体的年轻人走进职场，并期待工作软件同样易用，类似的转变可能再次发生。
Muse的主要进步在于让计算机操作功能，即由AI代替人操作软件，变得人人可用。早先的开源方案如OpenClaw，需要在Mac mini这样的专用机器上安装软件，并接入WhatsApp这样的通讯应用。Muse用友好的界面取代了这些设置步骤。它的价值在于异步工作：用户可以把行程规划或跨多个网站的网络调研交给它，在智能体运行时转去处理其他任务。目前可用地区仍然有限，英国用户暂时无法使用。
Muse还集成了通过Plaid完成的智能体支付和Shopify购物功能。当由智能体而不是人逐步点击结账来做出购买决定时，治理就变得更加重要。企业运营很可能会覆盖从严格按规则执行的确定性工作流到完全自主的智能体这一整个范围，而大多数流程会落在两者之间，成为智能体辅助的工作。
现在该做什么
Astra的取消提醒人们，等待下一个最强大的模型并不是一种策略。对团队更有帮助的，是明确规定哪个模型以多少成本承担哪项工作。
- 日常编程和智能体任务默认使用Claude Sonnet 5.5这样的中端模型，把顶级模型留给复杂的架构设计和调研。
- 不要只依赖公开基准测试，而是用自己的项目或一组固定的真实任务来测试新模型。
- 团队使用时，考虑采用自动模型路由和共享token预算，而不是固定的个人额度。
- 开启更深度的推理设置之前，先确认它会让token用量增加多少倍。
- 在把Muse这类消费级智能体引入工作之前，先制定好支付、权限和支出监督方面的规则。