GitHub Spark 已于 8 月 31 日关闭：应用还能访问，llm() 为什么早就失效

GitHub Spark 已于 8 月 31 日关闭：应用还能访问，llm() 为什么早就失效

GitHub Spark 在 8 月 31 日结束现有工作台访问。GitHub 早在 8 月 4 日停止接收新用户和创建新应用，并要求现有用户在截止日前通过 Create repository 导出代码。容易混淆的一点是：已经部署的 Spark 应用在产品关闭后仍会运行，工作台关闭不等于所有线上 URL 同时失效。

AI 功能却有另一条时间线。[GitHub 官方公告](https://github.blog/changelog/2026-08-04-upcoming-deprecation-of-github-spark-on-github-com/)说明，Spark 的 llm() 函数依赖 GitHub Models 推理服务，而该服务已在 7 月 30 日退役。应用页面可能正常打开，表单和存储也能工作，但凡执行到 llm()，模型调用就已经失败。

先判断应用坏在工作台还是推理端

排查时不要只测试首页。打开导出的仓库，搜索 llm()、模型名称和相关错误处理，列出每一个 AI 入口；再用真实请求验证生成、流式返回、超时和错误提示。没有使用 llm() 的 Spark 应用不受 GitHub Models 退役影响，数据库、认证或部署故障应按原链路调查。

如果截止日前已经创建仓库，要确认最后一次修改是否完整同步，环境变量、数据库结构和部署设置是否另有保存。官方通知只承诺已部署应用继续工作，没有承诺 8 月 31 日后仍能进入工作台编辑或导出。未完成导出的用户应查阅账户页面并联系 GitHub 支持，不要根据旧截图假定入口仍在。

线上应用仍能访问也不代表可以原样放着。缺少源代码、依赖不可更新、密钥无法轮换，都会让一个暂时在线的 Demo 变成不可维护服务。先备份代码和配置，再记录当前域名、认证、数据导出和回滚方式，才能决定迁移还是有序下线。

替换 llm() 需要补齐一整段服务端链路

GitHub 要求受影响应用改用自己的推理提供方，并自行管理 API Key 和计费。迁移不只是把函数名换成 HTTP 请求：模型服务应放在后端调用，Key 存入服务端 Secret，浏览器不能直接拿到凭据；请求还要设置超时、限额、最大输出和内容大小，防止公开页面被滥用。

如果新接口兼容 OpenAI Chat Completions，也要逐项核对 system 消息、流式事件、工具调用、JSON 输出和错误码。Spark 原来的封装可能隐藏了这些差异。可以参照 [OpenAI 兼容应用迁移指南](/articles/migrate-openai-compatible-app-to-anyais)做固定样本回放，并把旧输出与新模型结果放在同一套验收表里。

计费边界也会改变。原先由产品套餐隐藏的推理成本，现在落到开发者账户；公开应用需要用户级配额、总预算、异常用量告警和停用开关。[API Key 泄漏检测实践](/articles/ai-api-key-secret-scanning-prefix-checksum-security)适合加入导出仓库的 CI，避免把本地配置一起提交。

模型替换完成后再迁移产品外壳

最稳妥的顺序是先让 AI 调用从 Spark 专用函数脱离，保持现有页面和数据结构不变；新推理链路通过验收后，再决定是否迁移前端、认证与数据库。一次同时更换全部组件，出错时很难判断是模型、网络、数据还是界面造成。

模型选择应按任务分层。简单摘要可以用低成本模型，代码生成和复杂推理使用更强模型，超时后再按明确规则回退。涉及事实、金额或安全操作的输出，用另一模型或确定性规则复核关键字段。统一日志至少记录模型、版本、Token、延迟、失败码和用户任务，便于对账与复盘。

AnyAIS 可为迁出的 Spark 应用提供统一模型 API，让应用通过一个服务端入口接入 Claude、GLM、DeepSeek 等模型，并保留后续切换空间。真正需要优先抢救的仍是代码、数据和密钥控制权，模型网关解决的是迁出后的长期接入问题。