北京
给模型加一个工具，它就能自己写脚本、自己运行、自己读回结果。不用装环境，不用自己搭服务器。OpenRouter 把这套能力命名为 openrouter:shell，9 月 16 日上线。
接入方式简单到有点反直觉——在 Responses API 请求里加一个工具声明就行，参数里指定引擎为 openrouter。模型拿到这个工具后，会自己写脚本、执行、再把输出读回来。整个过程对调用方来说，只是多了一段 JSON。
它到底解决了什么问题
过去想让模型跑代码，路径通常是这样的：自己准备一台机器，装好运行时，配好隔离，再写一层调度把模型的输出喂进去、把结果捞出来。这套东西不难，但很烦，而且每换一个模型就要重新确认一遍兼容性。
openrouter:shell 把这一整段收进了平台侧。托管的是 Linux 容器，模型在容器里跑代码，调用方不需要安装任何东西，也不需要托管任何东西。这句话是官方给出的原话，也是这次发布最核心的卖点。
对做 Agent 的团队来说，这意味着工具链里少了一个自建模块。以前"让模型执行代码"是一个需要单独排期的工程任务，现在它变成了一个请求参数。
三个值得注意的细节
- 覆盖范围是 OpenRouter 上的任意模型，不是某一家独享。这意味着同一套调用方式可以横跨不同厂商的模型。
- 入口是 Responses API，不是另起一套 SDK。已有的调用结构不用推倒重来。
- 工具类型直接写成 openrouter:shell，引擎参数填 openrouter，命名上把平台身份嵌进了工具标识里。
这三点放在一起看，指向的是同一件事：把"代码执行"从应用层的能力，下沉成平台层的基础设施。谁调用、调用哪个模型，都不影响这个工具的存在方式。
为什么这件事值得关注
模型能跑代码，和模型能方便地跑代码，是两回事。前者是能力问题，后者是工程问题。过去一年里，大量 Agent 产品的卡点不在模型聪不聪明，而在外围这套执行环境搭得顺不顺。
OpenRouter 的定位一直是模型聚合层，这次它把手伸向了执行层。一个工具声明就能让任意模型获得代码执行能力，等于把原本分散在各家应用里的重复建设，收拢到了统一入口。
对开发者来说，短期收益是省掉自建沙箱的工时；长期看，当执行环境变成平台标配，模型之间的比较维度也会跟着变——不再只是谁答得好，还包括谁能在这个环境里把活干完。
目前公开的信息就这些：一个工具类型，一个参数，一个托管 Linux 容器。没有定价细节，没有容器规格，也没有并发限制的说明。想试的人，现在就可以在 Responses API 请求里加上那段声明。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
