TL;DR：
OpenRouter 上线
openrouter:shell服务端工具与 Files API（beta）：不再绑定某一家模型的代码执行能力，任何支持工具调用的模型都可以在托管 Linux 容器中执行命令。执行环境被平台化，智能体的"手和脚"第一次变成了标准配置。
这一步改变了什么：从"模型的附加功能"到"平台的公共设施"
过去两年，代码执行能力的供给是碎片化的：各家模型厂商有自己的代码解释器，开发者自建方案散落在无数 SDK 里。换模型就要换执行环境，多模型智能体框架的很大一部分工程量花在适配这些私有实现上。OpenRouter 的做法是把执行环境从模型侧剥离：平台上任何支持工具调用的模型——无论开源还是闭源——调用同一个标准化的 shell 工具，背后是统一托管的 Linux 容器。
对多模型工作流，这直接简化了架构：路由层换模型，工具层不用动。配套的 Files API 补上最后一块——文件上传、生命周期管理与执行环境打通，"跑一段代码并持久化产物"成为完整闭环。
商业视角：路由器的护城河升级
OpenRouter 的起点是模型路由（比价与容灾），但路由层的天花板很低——价差套利的空间会随市场透明化消失。加上执行环境后，它提供的是"模型无关的智能体运行时"，卡位深了一层：一旦团队的工具链建立在平台的 shell/Files 标准上，迁移成本就不再是换个 API key 那么简单。官方同步给出的定价、容器网络策略与文件生命周期细节，说明这是有完整商业化设计的功能，而非演示性 beta。
展望
值得跟踪两点：容器网络策略的演进（沙箱能否访问外网，决定了它可承接的任务类型），以及定价曲线的走向。如果"模型无关执行环境"成为独立品类，各大模型网关大概率跟进——执行环境的标准化之争，本质是智能体时代的云之争。