OpenRouter 官宣接入 Render Workflows：每条 prompt 独立成任务，排队、重试并扇出

北京时间 9 月 2 日凌晨 1 时 52 分，，宣布 OpenRouter 现已能在 Render Workflows 内运行：每个 prompt 成为独立的 task run（任务运行），由 Render 排队、自动重试并扇出，模型调用仍经 OpenRouter 路由。官方同步公布的给出了完整示例代码、环境变量与部署命令。

官方给这条整合的定位很直接：别再往 Web Service 里塞 LLM 批量调用。本文对机制与命令的描述均出自 OpenRouter 官方推文与文档，属发布口径，未经独立验证。

每个 prompt 一个 task run：慢调用不再阻塞整个批次

OpenRouter 在中对比了新旧两种做法：Web Service 必须为一个批次全程保持 HTTP 请求打开；Workflow 任务则在请求结束后继续运行、自行重试、每个 prompt 扇出一个 run，单个慢调用不会阻塞其余调用。

说明了算力供给：Render 为这些 run 按需供给计算资源、结束后释放，扇出不需要预置 worker pool（工作线程池）。指南把分工写得更明确：「OpenRouter 负责模型访问与路由，Render Workflows 负责这些调用周边的执行：排队、重试与并行任务运行」，数据流为 prompts → Render Workflow fan-out → OpenRouter Auto Router → answers + model IDs。

指南还提醒一个架构边界：Render Workflow 任务不暴露 HTTP 端口，面向用户的应用需要由 Render Web Service 接收请求、再触发 workflow。

路由交给 openrouter/auto，每次选择都留在 completion.model

说明了模型调用方式：每个 run 调用 Auto Router（openrouter/auto），每个结果保留 completion.model 字段，因此可以看到 OpenRouter 为每条 prompt 选了哪个模型。指南解释，Auto Router 可以为每条独立 prompt 选择不同模型，保留 completion.model 让路由决策可见；openrouter/auto-beta 是早期接入轨，新路由行为先在那里落地。

指南的示例代码展示了任务结构：内层 callOpenRouter 任务配置了 retry（maxRetries 3、waitDurationMs 1000、backoffScaling 2），外层 runPromptBatch 用 Promise.all（Node）或 asyncio.gather（Python）把每个 prompt 扇出成独立调用。Node 与 Python 均受支持，但 @openrouter/sdk 仅支持 ESM（ES 模块），CommonJS 的 require() 不可用。

从脚手架到部署：四条命令跑通一个批次

给出上手路径：脚手架与运行批次用 render workflows init --language node 和 render workflows start runPromptBatch，本地开发用 render workflows dev，部署用 render workflows create，并指向完整指南。

按指南，前提是 OpenRouter API key、Render 账户、已安装并认证的 Render CLI，以及一个可推送的 Git 仓库（GitHub、GitLab 或 Bitbucket）。环境变量包括 OPENROUTER_API_KEY、OPENROUTER_MODEL=openrouter/auto 与 OPENROUTER_APP_TITLE；若有公开应用触发该 workflow，还需设置 APP_URL 用于应用归属（app attribution）。.env 不入库，Render CLI 本地开发时自动加载。部署后可在 Render Dashboard 查看父 run、每次链式模型调用、重试、日志、结果以及每条 prompt 选中的具体模型。

指南还附带一个完整示例 Answer Arena：TypeScript 应用，组合 Render Web Service、Render Postgres、Render Workflows 与 OpenRouter，扇出模型配置、向浏览器流式返回进度，并记录模型、成本与评估结果。

Render 比 OpenRouter 早 50 分钟发声，首批回复来自两位个人用户

这次官宣从 Render 一侧先开始。于北京时间凌晨 1 时 02 分发布同一指南的简介，比 OpenRouter 的五条推文早约 50 分钟：「路由交给 OpenRouter，扇出、重试与按需算力交给 Render Workflows；每个 prompt 成为各自独立的任务，慢的那一个不会阻塞其余。」

OpenRouter 账号简介自称「LLM 的统一接口」，提供 400 多个模型（含 50 多个免费模型）。主推文发布后不到 10 分钟，两位个人用户先后回复：自称软件开发者、来自印度孟买的称「接入 Render Workflows 让批量处理干净多了，不再有慢调用把整个 Web Service 搞崩的问题」；自称简化 AI 与无代码工具的回复称这套方案「听起来很扎实」。

重试可能重复计费：官方把幂等留给用户

官方口径里有一条要用户自己处理的提醒，落在计费上。明确：如果首次请求已经成功、但任务在返回结果前失败，重试会重复产生一次计费调用，生产环境的外部副作用需要自行加幂等（idempotency）。指南的措辞更进一步：「对于带外部副作用的生成工作流，请添加应用层幂等或检查点（checkpointing）。」计费发生在模型调用层、重试发生在任务层，官方没有内置去重，幂等逻辑最终由每个工作流自己实现。