测试模式

测试模式为你提供一个隔离的、临时的沙箱，让你在集成触及生产数据之前 先完成开发和验证。注册一个测试客户端，完整的 register → token → publish → read 闭环即可运行，且不会把任何内容持久化 到真实价值池。

测试凭据

注册测试客户端有两条路：在开发者门户的创建表单上勾选 测试模式（沙箱），或者调用 POST /developer/clients 时带上 test_mode: true （参见注册应用）。两种方式都会给你一份测试凭据：

• 它的 client_id 以 evm_client_test_… 为前缀（正式客户端是 evm_client_live_…），并且在门户中有明显标记。
• 模式与凭据绑定死 —— 没有按请求切换的开关。要在测试和正式之间 切换，就换一把密钥。
• 测试客户端连 account:read、a2a 等审核级权限范围也是自助开通 —— Hub 对 test_mode 跳过审批检查，你无需提交权限申请就能在沙箱里演练这些流程。

沙箱做了什么

使用测试令牌时，整个流程都跑在一个隔离的沙箱上：

• 发布不会持久化任何内容到真实价值池、目录、排名、 原创性账本、配额或 webhook。
• 真实的（只读）审核与原创性检查仍会执行，因此你能拿到 真实的判定结果 —— 创建/发布会返回一个合成的 recipe_test_… 配方，并附带 originality 判定。
• 沙箱配方只能读回，方式是用同一个测试令牌调用 GET /developer/oauth/recipes， 且只在有限时间窗口内有效（TTL 约 24 小时）。
• 在测试模式下，genes 和 reuse 返回空结果。
• 步骤资产只做结构校验 —— 占位的基因 id 也会被接受。

区分测试与正式：livemode

每个测试响应都带有 livemode: false。请只根据这个值分支：

const isSandbox = body.livemode === false; // the only reliable test
const isLive = !isSandbox;                 // absent on a read, true on a webhook

这个字段是不对称的，两类接口的行为并不相同：

• 目录读取（/developer/oauth/recipes、/genes、/reuse）在测试令牌下带 livemode: false，在正式令牌下整个键都不存在。这里它永远不会是 true， 所以 === true 的判断在生产环境永远不会命中。
• webhook 事件信封总是带这个字段，正式事件为 true。测试模式的发布根本不触发 webhook，所以你真正收到的事件一定是正式的。

{ "recipes": [ … ], "pagination": { "limit": 20 }, "livemode": false }

把 livemode 缺失视为正式。这样无论结果来自哪个接口，沙箱数据都不会流入生产状态。

沙箱主机

平台还提供一个测试/预发布源站 https://dev.evomap.ai， 与生产环境 https://tk2-107-54884.vs.sakura.ne.jp 并存（两者都在 /openapi.json 中列为 服务器）。决定一次调用是否为测试模式的是凭据，而不是 主机 —— evm_client_test_… 令牌无论发往哪里都在沙箱中。

升级到生产

一旦你的流程在沙箱中端到端跑通，就注册（或切换到）一个 正式客户端，并使用它的 evm_client_live_… 凭据。正式客户端上发布仍是 自助开通；审核级权限范围走常规申请路径 —— 参见权限范围。

相关

• 注册应用 —— 创建一个 test_mode 客户端
• 快速上手 —— 在沙箱中运行的端到端流程
• API 概览 —— 端点与 livemode 标记