登录态与签名机制#

Loomy 的客户端通信并非标准的 RESTful API，而是基于自定义的加密协议。项目维护者在 GitHub 仓库的文档中明确指出，网关通过模拟登录态，实现了 RSA 与 HMAC 签名机制 [S8]。这意味着，开发者无需在本地安装臃肿的 Loomy 客户端，只需在网关端配置账号密码（或短信验证码），即可完成身份认证。

模型映射与倍率控制#

为了适配主流的 AI 工具链，loomy2api 实现了模型名称的映射与倍率控制。上游提供的模型包括 Spark-X、GLM-5.3-Flash、Qwen 系列等，网关直接透传模型 ID，但在实际调用时，根据模型类型应用了不同的倍率策略 [S7]。

根据项目文档，不同模型的倍率差异显著：Spark-X 的倍率仅为 0.1，而 Qwen-3.8-Max 的倍率高达 12.0。这种设计反映了上游不同模型组间的成本差异。在实际工程中，开发者需要根据业务对成本与质量的平衡，选择合适的模型 ID 进行调用。

设备标识隔离#

在多账号场景下，loomy2api 引入了“设备标识隔离”机制。每个账号在首次登录时会随机生成一套独立的设备标识（devid / 校园设备号）并绑定。后续续期时复用该标识，避免所有账号对外宣称属于同一台设备 [S7]。

工程结论：虽然设备标识隔离减少了账号间的关联风险，但项目作者在文档中明确警示，这并非防封保证。上游风控系统真正关注的通常是出口 IP，而非设备指纹。因此，多账号池的稳定性高度依赖于 IP 资源的多样性。

多账号路由策略#

面对多个 Loomy 账号，网关需要智能地分配请求。loomy2api 提供了三种路由策略：

1. 按积分余额：优先使用余额充足的账号，适合成本敏感型场景。
2. 轮询：均匀分配请求，避免单一账号负载过高。
3. LRU（最近最少使用）：根据账号的活跃度动态调整，适合长期运行的 Agent 任务。

自动续期机制#

Loomy 的登录态有效期通常为 14 天。loomy2api 内置了自动续期逻辑，当检测到登录态即将过期时，会自动使用账号密码重新登录并刷新令牌。这一机制使得网关可以作为长期运行的微服务，无需人工干预 [S7]。

可复现的部署清单#

以下是基于 Docker 的标准部署流程，可直接复现 [S8]：

1
# 1. 克隆仓库并进入目录
2
git clone https://github.com/Patrick130306/loomy2api.git
3
cd loomy2api
4

5
# 2. 准备配置文件
6
cp accounts.example.json data/accounts.json
7
cp config.example.json data/config.json
8

9
# 3. 启动服务
10
docker compose up -d --build

验证与控制面板#

服务启动后，默认监听端口为 17890。开发者可以通过访问 http://127.0.0.1:17890/panel 打开 Web 控制面板。该面板提供了可视化的账号管理功能，包括查看每个账号的实时余额、登录态剩余天数、已用积分以及冷却状态 [S7]。

Anthropic 协议兼容#

除了 OpenAI 兼容接口，loomy2api 还实现了 Anthropic 的 /v1/messages 接口。这意味着，像 Claude Code 这样的工具可以直接通过设置 ANTHROPIC_BASE_URL 来调用 Loomy 的积分额度，无需额外的适配层 [S7]。

上游的静默回退#

在测试中发现，上游服务对不认识的模型名称会进行静默回退。例如，当请求 gpt-4o-mini 时，上游返回 200 状态码，但实际响应中的 model 字段被替换为 deepseek-v4-flash-0731 [S7]。这表明，网关不能简单地通过模型名称进行映射，必须严格使用上游支持的模型 ID，并在响应中检查 model 字段以确认实际调用的模型。

网络异常处理#

项目在 CI 环境中发现了一个关键 Bug：刷额度的函数仅捕获了自定义异常，未能处理底层的 socket 或 DNS 异常。这导致在断网环境下，执行 loomy2api accounts 命令会直接崩溃 [S7]。虽然该 Bug 已修复，但这提示用户在部署网关时，必须确保网络连接的稳定性，否则服务可能无法正常恢复。

合规与免责#

项目明确声明仅供研究与自用，严禁滥用、转售或公开服务压垮上游 [S7]。由于该网关涉及对官方客户端协议的逆向工程，存在一定的合规风险。开发者应仅将其用于个人学习与测试，切勿用于商业用途。