最近，AO 官方发布了 AO Connect 与 AOS 的一次重要更新。乍一看，这只是一个 SDK 和 CLI 的版本升级，但如果把这些改动放回 AO 的整体发展路径中看，会发现这次更新解决的并不是某个局部问题，而是一个长期存在的核心矛盾：AO 到底什么时候才能被当作一个「真正的主网系统」来使用。
在过去相当长的一段时间里，AO 更多处在一种「能演示、能实验，但不适合认真开发」的状态。开发者可以写 process，可以发 message，也能看到执行结果，但这些操作大多发生在 LegacyNet 或较为特殊的环境中。网络入口并不统一，新旧系统之间的边界也并不清晰，这导致很多人即便对 AO 的理念感兴趣，真正动手时却会犹豫 —— 不知道自己写的东西，究竟算不算跑在主网上。
这次 AO Connect 与 AOS 的更新，恰恰就是围绕这个问题展开的。
最重要的变化只有一句话：AO 主网（HyperBEAM）现在成为默认连接对象。
这意味着，从这一刻开始，AO 的默认世界已经不再是 LegacyNet，而是一个真正面向生产环境设计的主网计算网络。
这种变化的意义，其实比表面看起来要大得多。过去，主网和旧网络并存，新手往往很难分辨自己连接的到底是哪一套系统；而现在，这个选择被官方直接做掉了。只要你使用最新版本的 AO Connect 或 AOS，你默认连接的就是主网。如果你确实需要操作旧进程，才需要明确地告诉系统：我要用 legacy。网络的主次关系，在工具层面被彻底理顺。
在此基础上，AO Connect 的工作流也完成了一次关键收敛。开发者现在可以通过同一套接口，在主网上完成 process 的创建、消息的发送以及结果的获取。这听起来像一句很普通的话，但对 AO 来说，它意味着计算模型终于从概念正确走向了工程可用。你不再需要为了一次简单的交互，去理解一堆历史背景或隐藏前提，而是可以像使用一个正常的远程计算服务那样，去使用 AO。
当然，这次更新并不是毫无代价地完成的。官方也非常明确地指出了一个兼容性差异：在主网 HyperBEAM 上，某些 tag 的命名规则会被规范化处理，尤其是连续大写字母的情况。如果你的旧逻辑依赖于大小写精确匹配，那么在迁移到主网时，确实需要做一次整理。官方给出的建议也很直接：使用带中横线的 tag 命名方式，而不是依赖大小写本身来表达语义。
这个细节看似琐碎，但其实反映了 AO 正在做的一件更重要的事情——从允许任意行为的实验环境，转向行为可预期、规则明确的主网系统。 对真正想长期维护应用的人来说，这种约束反而是好消息。
从 AOS 的角度看，变化同样清晰。随着主网成为默认连接目标，AOS CLI 的行为也随之调整。如果你连接的是已有的 legacy 进程，系统会自动处理；如果你要创建新的旧版进程，则需要显式指定。这种设计思路，本质上是在推动整个生态自然向主网迁移，而不是无限期地维持双轨状态。
如果把这次更新放到 AO 更长的时间轴上来看，它更像是一次「阶段性收官」。AO 在过去一年中，完成了执行模型、调度机制、HyperBEAM 节点等一系列基础建设，而 AO Connect 与 AOS 的这次升级，则是在工具层面，把这些能力真正“交付”给了开发者。
对于开发者而言，这意味着 AO 开始具备可持续开发的前提；对于普通用户和观察者而言，这也意味着 AO 不再只是一个停留在理念层面的去中心化计算设想，而是在逐步接近一台可以被真实使用的计算网络。
