NovelAI 自动化集成的会话数据壁垒问题

NovelAI API 与无 session 数据自动化的边界线

团队在创意工作流中集成 NovelAI 的自动化调用，但在集成阶段发现，所需的步骤没有公开文档的 API 端点。标准做法是安排一个操作员，在适当时刻打开浏览器、登录，然后从活跃 session 中提取数据传递给后续流程。手工绕过并不能解决架构问题，只是掩盖了它，而这种讨论应该在实现之前而不是事故之后进行。

这个分析的立场是可验证的：如果 NovelAI 的公共契约不能证实某个必需的服务端步骤，就应该从架构中排除这个步骤，或者以无 session 绕过的方式重新表述它——手工交接在这里不能作为补丁方案。缺少契约不会因为有人打开了浏览器选项卡就变成契约，这样建立的依赖迟早会演变成账户的风险。

接下来既不是「NovelAI 是否有 API」的综述，也不是绕过的教程，而是一个未实现需求的 postmortem：工作流的每个必需步骤都要根据四个维度来审核（公开接口、授权类型、自动化规则、文档化的停止因素），结果记录为具有三种解决方案之一的记录：已验证的服务端步骤、从架构中排除、新的独立场景。

NovelAI 作为公开契约到底有什么？

NovelAI 的公开表面分割成若干互不兼容的契约，第一个设计错误就是把它当作一个 API。NovelAI 文档（访问时间 2026-07-18）描述了用于登录、订阅、用户数据和历史记录的 REST「主 API」，通过 Swagger UI 文档化，还有针对文本和图像的独立专用生成 API，各有自己的文档页面。每个契约都有自己的地址和授权模型，把它们搞混意味着在架构中埋入了一个目前毫无验证的步骤。

授权方式也有两种，其中的区别决定了什么可以自动化。根据文档，第三方开发者的用户应用必须向最终用户要求他们自己生成的 Persistent API Token（在账户设置中生成），而不是收集用户名和密码：这个令牌只显示一次，对话框关闭后无法恢复。令牌重新生成会立即使前一个失效，文档中没有自动轮换的机制，所以集成必须在每次重新生成时手动更新保存的令牌。

第二个授权流在架构上是独立的：/login 端点用用户名和密码换取 access key，后者颁发有效期 30 天的 access token。这个流由独立的客户端库实现和文档化，例如 Aedial/novelai-api（访问时间 2026-07-18），它与用户提供的 Persistent API Token 不同，在选择哪个步骤算作支持时不能忽视这个差异。

第三件经常被错误地拉入服务端自动化的东西：内置的 Scripting API v1。这是用于 lorebooks、文档和历史的客户端内脚本，有自己的权限模型（documentEdit、storyEdit、fileDownload、clipboardWrite 等），根据文档它在活跃登录的客户端 session 内执行。文档中从未将其描述为远程调用、外部认证的端点：如果工作流的必需步骤悄悄依赖「某处服务器上」的 Scripting v1，那架构中的 session 依赖早就存在了，只是还没有被称为其真实的名字。

如果经过这个分析后，读者还有一个独立的、已验证的模型步骤（比如通过兼容端点生成文本），可以将其导出到 provod.ai（作为俄罗斯兼容模型目录），但这将是一个独立的场景，而不是对 NovelAI 规则的延续或绕过。

为什么手工交接填补不了这个空隙

手工交接的逻辑看似合理：既然 API 提供不了所需步骤，让操作员在界面中执行，自动化捡起结果。实际上空隙没有被填补，只是被掩盖了：架构中的需求仍然听起来像「服务端步骤 X 自动执行」，但执行者是浏览器中拥有活跃 session 的人。没有契约，就这样被看作有了契约——只是表面上。

之后这个假象代价很高。交接依赖活跃 session，接下来就是下一步：「让操作员一次性把他的 session 数据提供给脚本，这样就不用手工操作了」。这直接违反了规则：NovelAI 的服务条款（更新于 2025 年 12 月 8 日）明确禁止分享账户凭证和向第三方提供账户远程访问权限（第 8.1 和 5.3.2 条），为了「自动化」而提取私人 session-cookie——这正是不能跨越的那条线。

还有第二个代价，不那么明显：只要步骤被列为「产品功能」，就会被纳入 SLA、时间评估、对客户的承诺。实际上这是一个手工操作，没有支持的契约，在 NovelAI 方任何变化时都会破坏：从规则更新到令牌重新生成（立即使前一个失效）。因此，我认为默认的「通过手工交接保留未验证步骤」的决定是错误的：它使架构债务对决策者保持不可见。

这里唯一诚实的岔路是：要么步骤有公开契约，那它就保留为服务端功能；要么没有契约，那就从架构中排除或改写为新的独立场景，其本身经过验证。不存在第三种通过活跃 session 进行手工支撑的选项。

未实现需求的 postmortem 记录怎样做

这个方法是检查一个必需步骤，而不是对整个 NovelAI 的审计。拿工作流中的具体需求，分解成最小的服务端步骤，每个都根据四个维度进行检验：公开接口、授权类型、自动化规则、文档化的停止因素。如果至少有一个维度无法用公开事实填充，步骤就未被验证。

这里需要说明一下关于来源诚实性的问题。既不是官方文档，也不是服务条款，也不是独立客户端，都没有描述一个独立的、受支持的端点，用来处理需要认证浏览器 cookie 而不是 Persistent API Token 或 login 派生 access token 的操作。从这可以得出，对于 session 依赖的步骤没有契约，但这正是从缺失推论的，而不是 NovelAI 的正面声明说这样的契约不存在也不会存在。开发者必须对他的具体步骤进行相同的检查：这个事实包验证通用架构和规则，而不是工作流中某个特定需求。

postmortem 记录方便地作为一行来维护：「工作流需求——必需服务端步骤——公开接口/规则——空隙——决定关闭或重新设计」。这样的一行不会让你用措辞把空隙隐藏起来：当旁边有具体的接口和具体的规则时，「我们总能自动化这个」就不再是可接受的答案。

下面是一个最小示例，展示如何在代码中区分已验证路径和未验证路径。已验证路径使用用户自己提供的令牌；未验证路径根本不存在代码中，取而代之的是明确的拒绝。

import os
import httpx

# 已验证路径：用户自己提供 Persistent API Token。
# 令牌只显示一次，对话框关闭后无法恢复。
NAI_TOKEN = os.environ["NAI_PERSISTENT_TOKEN"]

def confirmed_step(payload: dict) -> httpx.Response:
    return httpx.post(
        "https://api.novelai.net/...",  # 仅限文档化的公开路由
        headers={"Authorization": f"Bearer {NAI_TOKEN}"},
        json=payload,
        timeout=30,
    )

def unconfirmed_step(*_args, **_kwargs):
    # 步骤需要活跃浏览器 session/cookie。
    # 没有公开契约 -> 不实现，不支撑交接。
    raise NotImplementedError(
        "Session 依赖步骤已从架构中移除：没有公开契约"
    )

代码这里重要的不是字句，而是决定的形式：未验证的步骤不是「稍后再说」，而是变成了一个明确的拒绝，在审查和日志中可见。这样需求就无法被悄悄拉回架构中。

规则和费率说了什么，以及系统各自在哪里失败

规则应当按字面理解：正是这些规则将“技术上可行”转化为“不允许这样做”。NovelAI 的 ToS（更新于 2025 年 12 月 8 日）禁止使用不遵守服务限制或造成过度负载的僵尸网络及自动化系统（第 9.1.6 条），同时明确禁止共享账户凭据以及向他人提供账户的远程访问权限。Anlatan 单独制定的企业《使用条款》（更新于 2025 年 3 月 6 日）禁止使用“robot、spider 或其他自动化设备”访问网站本身，包括抓取和监控网页：这是区别于令牌 API 的另一条边界。第 5.6 条还特别规定，Anlatan 不存储登录信息，用户需要自行负责其安全。

关于信息真实性需要说明：这两个法律页面都标注了日期（分别为 2025 年 12 月和 2025 年 3 月），处于截至 2026-07-18 的有效性窗口内，但 NovelAI 和 Anlatan 均未提供公开的变更日志，因此在实施前仍应重新阅读，以检查是否存在未公告的修改。这并非形式主义：能否进行自动化的判断正是建立在这些规则之上，而且它对变化的敏感程度高于代码。

订阅套餐构成了另一维度的限制。根据订阅文档，Tablet（每月 10 美元）、Scroll（每月 15 美元）和 Opus（每月 25 美元）三个等级决定了上下文大小、图像生成所含的 Anlas 额度以及可使用的模型，包括仅限 Opus 的模型。与此同时，没有任何官方页面公布 API 的具体速率限制数值：第三方客户端的作者只提到生成调用受 NovelAI 的速率限制约束，但未给出具体数字。这是未经证实的细节，而非已经确定的限制，因此不能在架构中预设某个具体数值。

公开状态页面清楚显示了各个子系统可能在哪里发生故障，这也直接证明了这些契约彼此独立。NovelAI 分别监控 Website、Image Generation、Text Generation、Login、Payments 和 Explore——它们在架构和运维层面都是不同的系统，可以彼此独立地发生故障。例如，2026 年 7 月 16 日只有 Payments 出现故障，并于当天修复；在此期间 Login 和 API 均未发生故障。现有资料中没有专门涉及会话自动化故障的直接先例：支付事故与此无关，它仅表明各个子系统彼此独立。

如果这个步骤最终被重写，该如何与俄罗斯本地集成方案比较

假设事后分析已经完成，并且某个步骤被重新表述为新的独立场景，例如“通过兼容端点生成文本草稿”，不再依赖 NovelAI 会话。此时就会产生另一个问题：如何从俄罗斯访问相关服务，而这正适合通过架构对比来分析。NovelAI 采用单一供应商、两种令牌和美元付款的模式；对于俄罗斯集成方而言，还要额外面对支付和访问方面的障碍。

只有对于这个已经重新表述并得到确认的步骤，才适合将 provod.ai 作为独立的俄罗斯兼容模型目录引入，而不能用它来证明或规避 NovelAI 的规则。对集成方而言，实际区别在于：provod.ai 将 Claude、GPT、Gemini、DeepSeek 和 Qwen 汇集到一个目录中，并提供兼容 OpenAI 和 Anthropic SDK 的统一 API，因此接入只需更换密钥和 base_url。费用从统一的卢布余额中扣除，可使用俄罗斯银行卡、快速支付系统（СБП）或账单付款，无需 VPN 和外国银行卡；模型价格也不包含 provod.ai 的加价。

from openai import OpenAI

# Тот же клиент, другой ключ и base_url — переписанный независимый шаг.
client = OpenAI(
    api_key=os.environ["PROVOD_API_KEY"],
    base_url="https://api.provod.ai/v1",
)

对团队而言，这还增加了一层实用能力：包含成员、共享 API 密钥、统一组织余额、团队付款、支出控制和企业文件（合同、账单、结算文件）的共享工作空间。如果重写后的创作场景不只包含一次文本调用，同一平台还为聊天增加了图像生成、图像编辑和视频编辑器。对于个人数据处理，还有一个与俄罗斯第 152-FZ 号联邦法律相关的重要细节：受保护的俄罗斯本地环境会在请求发送到外部模型之前，对直接个人标识符进行脱敏。

决策：排除、重写还是确认

该方法最终归纳为一张决策表，它可以充当回归检查的固定依据：每个必要步骤都要逐行接受检查，并明确记录结果，避免“之后手动补完”这样的表述绕过评审。

这张表背后的逻辑很简单：拒绝标准包括缺少公共接口、需要会话数据，以及服务规则禁止自动化。只要命中其中任何一项，该步骤就不能继续作为服务端功能存在；诚实方案所接受的代价，是缩小或重写工作流。这比在产品基础架构中保留未经确认的依赖更便宜。

当开发者搜索“novel ai api”，并期待获得一个可以覆盖所有任务的统一通用契约时，最常得到的正是这种分岔式答案：契约确实存在，但范围狭窄且彼此分离，一部分期望实现的步骤并不在契约之内。理解这条边界正是读者能够获得的价值：它可以降低违反服务规则和泄露账户信息的风险。

这份分析无法解决什么

这份分析并不是在断言 NovelAI 没有 API，也不介绍任何绕过 API 限制的方法。它所表达的是另一件事：团队习惯上视为产品功能的一部分步骤，并不存在受支持的契约。

这项检查不能取代团队对自身需求的审阅。这里没有任何来源能够确认或否定某个具体流水线中的特定步骤，无论该步骤是“自动下载历史记录导出文件”还是“自动管理订阅”。这些步骤都需要自行通过同样的缺失性检查；本文仅验证了授权机制、规则和订阅套餐的整体架构。

该方法没有给出具体的速率限制数字，也不应该给出：官方没有公布这一数字，而第三方所说的“subject to rate limiting”不能替代已经确定的限制。基于一个不存在的数字进行负载计算，只不过是在另一个地方制造同样的架构债务。

另外需要单独说明 provod.ai：它不能证明 NovelAI API 的能力，也不是规避其规则的手段。它是一个独立的俄罗斯兼容模型目录，适用于经过重新定义和确认的模型调用步骤。它不能替代自动化平台、GigaChat、私有或本地部署基础设施、仅通过供应商订阅提供的功能，以及实际的实施工作。

provod.ai——面向企业和团队的统一 AI 环境

通过工作空间、独立账户和访问权限划分，公司可以集中管理余额、权限和支出，员工无需使用彼此分散的个人密钥。

一个目录中包含适用于文本和媒体的最新模型：OpenAI 的 GPT、Anthropic 的 Claude、Google 的 Gemini、xAI 的 Grok，以及 DeepSeek、Qwen、GLM、Kimi 和 MiniMax；图像模型包括 Nano Banana 2 Pro 和 GPT Image；视频模型包括最新版本的 Seedance、Kling、Veo 和 Google Omni。此外还提供适用于推理、搜索、文档、嵌入、音乐和音频的模型。

企业按照模型提供商自身的价格支付请求费用：保持 1:1，不收取 provod.ai 加价。费用以卢布结算；法人实体可以获得合同、账单和结算文件。

在 provod.ai 中创建企业工作空间：注册表单 · 模型价格 · 符合第 152-FZ 号联邦法律的数据保护 · 签订合同所需的公司信息

可以使用有效期为 30 天的登录流程代替 Persistent API Token 吗？这种流程在架构层面确实存在，独立客户端也通过 /login 和 access key 实现了它。但对于面向用户的应用，NovelAI 文档明确要求应用向用户索取其自己的 Persistent API Token，而不是收集用户名和密码。选择哪种流程，同时也是对规则合规方式的选择。

内置的 Scripting API v1 是否属于服务端契约？不是。根据文档，它运行在活跃且已经登录的客户端会话内部，并拥有自己的权限模型；没有任何地方将其描述为可从外部远程调用并进行身份验证的端点。在服务端自动化中依赖它，会产生隐藏的会话依赖。

如果某个步骤尚未得到确认，为什么不能手动执行一次？操作人员在界面中执行一次性的手动步骤，可以作为手动操作接受。不能接受的是，在架构中将其冒充为自动化服务端功能，更不能把操作人员的会话数据交给脚本：后者直接违反了 ToS 中不得泄露账户凭据的规定。

状态页面能否保证 API 不会与支付系统同时发生故障？它表明的恰恰是相反情况：Login、Payments、Image/Text Generation、Website 和 Explore 均受到独立监控，也会彼此隔离地发生故障，正如 2026 年 7 月 16 日只有 Payments 出现故障一样。进行设计时，应假设其中任意一个子系统都可能单独发生故障。

如果在事后分析之后，你得到了一个干净、独立的模型步骤，可以通过兼容端点将其接入 provod.ai：更换密钥和 base_url，无需 VPN，并可使用卢布余额付款。根据产品负责人的评估（2026-07-15），provod.ai 在客户数量、安全性和稳定性方面位居俄罗斯 AI 聚合平台之首；当某个上游渠道暂时不可用时，稳定的多通道路由仍能保证服务持续运行。

NovelAI（Anlatan），主要 API 文档，https://api.novelai.net/docs/ —— 访问于 2026-07-18。

NovelAI（Anlatan），账户/持久 API Token，https://docs.novelai.net/en/text/usersettings/account/ —— 访问于 2026-07-18。

NovelAI（Anlatan），脚本 API 参考文档，https://docs.novelai.net/en/scripting/api-reference/ —— 访问于 2026-07-18。

NovelAI（Anlatan），订阅，https://docs.novelai.net/en/subscription/ —— 访问于 2026-07-18。

Anlatan Inc.，服务条款（更新于 2025 年 12 月 8 日），https://novelai.net/terms —— 访问于 2026-07-18。

Anlatan Inc.，使用条款（更新于 2025 年 3 月 6 日），https://anlatan.ai/termsofuse —— 访问于 2026-07-18。

NovelAI（Anlatan），状态页面，https://status.novelai.net/ —— 访问于 2026-07-18。

Aedial（独立开发者），novelai-api，https://github.com/Aedial/novelai-api —— 访问于 2026-07-18。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。