摘要
2026 年 9 月 8 日（UTC），Inception Labs 正式发布 Mercury 2.5。根据官方博客，这是目前市场上能力最强的扩散式大语言模型（diffusion LLM，简称 dLLM），也是官方声称"有史以来训练过的最大扩散语言模型"。三个数字构成了这次发布的核心叙事：1,107 tokens/sec 的生成速度、260K 的上下文窗口、以及发布期 $0.04/百万输入 token 的促销价格。消息当天登上 Hacker News 热榜，并同步上架 OpenRouter（模型 ID：inception/mercury-2.5-preview）与 Baseten。
这篇文章不重复新闻稿，而是回答三个工程问题：扩散式生成到底快在哪里？1,107 tokens/sec 对 Agent 架构意味着什么样的"延迟经济学"？以及，Java 和 Python 开发者今天就能怎么把它接入生产系统。文中所有 Mercury 2.5 的数据均来自官方博客原文（链接见文末），生产案例数据为厂商披露口径，我会明确标注哪些是厂商自述、哪些需要自己实测验证。
一、事件本身：9 月 8 日发生了什么
先交叉验证一下事实源，避免单一信源偏差：
- 官方博客：Inception Labs CEO Stefano Ermon 署名发布《Introducing Mercury 2.5》，发布时间 2026 年 9 月 8 日 16:29 UTC；
- Hacker News：同日出现多个相关提交（"Mercury 2.5" 登上首页，另一条 "Inception Launches Mercury 2.5, the Next Tier of Intelligence for Diffusion LLMs" 指向 OpenRouter 模型页）；
- 分发渠道 ：OpenRouter 早在 9 月 1 日就出现了
inception/mercury-2.5-preview的预览条目，9 月 8 日正式官宣，节奏符合"先灰度、后发布"的常规打法。
官方给出的关键规格如下表（全部为厂商口径）：
| 维度 | Mercury 2.5 | 备注 |
|---|---|---|
| 智能水平 | 较 Mercury 2 提升 40% | 官方声称与 GPT-5.6 Luna (Low)、Gemini 3.5 Flash-Lite、Claude Haiku 4.5 等"成本优化型前沿模型"相当 |
| 生成速度 | 1,107 tokens/sec | 在"广泛可得的 NVIDIA GPU"上测得 |
| 上下文窗口 | 260K tokens | --- |
| 标准定价 | 0.20/M 输入，0.75/M 输出 | 发布期 8 折促销：0.04/M 输入，0.15/M 输出 |
| 能力特性 | 可调节推理（tunable reasoning）、并行工具调用（parallel tool calls）、Schema 对齐 JSON | 三项都是 Agent 场景的刚需特性 |
| 同步预告 | Mercury Voice（TTFT < 170ms）、Mercury Router（用 dLLM 做请求路由） | 均为 Preview |
值得注意的是官方在博客里透露的训练方法论：Mercury 2.5 的提升不是靠刷公开榜单，而是"用客户反馈和生产失败案例来打磨评测集、聚焦训练"。这句话对做 to B 基础设施的团队很有参考价值------生产 failure case 是最便宜的评测数据来源。
二、扩散语言模型：自回归之外的另一条生成路线
要理解 1,107 tokens/sec 为什么重要，得先花三分钟搞清楚 dLLM 和传统自回归（autoregressive，AR）模型在生成范式上的根本差异。
自回归模型（GPT、Claude、Gemini 等主流架构）逐 token 生成：预测第 1 个 token，把它拼回输入，再预测第 2 个......生成 N 个 token 需要 N 次前向传播（工程上配合 KV cache 优化，但串行本质不变）。这意味着延迟与输出长度严格线性相关，且每一次解码步的 GPU 利用率受限于访存带宽。
扩散语言模型 走的是另一条路：不逐个生成，而是从一段"噪声"（通常是全掩码或随机 token 序列）出发，通过固定轮次的迭代去噪，并行地把整个序列逐步"显影"出来。每一轮去噪都同时处理序列中的所有位置，因此总前向传播次数约等于去噪步数，而与输出长度基本解耦。
用一个直观类比：AR 像打字员，一个字一个字敲；dLLM 像照片显影，整张底片一起慢慢变清晰。显影 500 字和显影 50 字所需的"浸泡轮次"差不多，这就是 dLLM 吞吐优势的来源，也是它在"短输出、高频调用"场景下性价比爆炸的原因。
当然，范式差异也带来工程特性的差异：dLLM 的输出长度需要预先规划（分配序列槽位）、支持可调节的去噪步数来换取质量-速度平衡（Mercury 2.5 的 "tunable reasoning" 大概率就是在这一维度做文章），而这些恰恰是 Inception 从 Mercury 1 一路迭代到 2.5 所积累的工程纵深。需要强调的是："最大扩散语言模型"是厂商声称，扩散路线此前已有学术界（如 LLaDA、Dream 等掩码扩散工作）和工业界的持续探索，Mercury 系列是其中最早规模化商用的分支之一。
三、延迟经济学：为什么 1,107 tokens/sec 会改变 Agent 架构
速度本身不是卖点，速度改变架构才是。官方博客披露的三个生产案例，恰好覆盖了 Agent 系统的三类高频调用，我们把数字拆开看。
3.1 搜索 Agent 与 RAG 管道：一次交互，几十次模型调用
官方描述得很直白：一次搜索请求可能触发几十次模型调用------规划搜索、改写查询、重排结果、结构化事实、摘要来源、校验答案。如果用前沿大模型跑完整条链，延迟和成本都会失控；把链条上的"小任务"换成分布式快速模型，整条管道才能压进一次用户交互的时间预算内。博客称已有多家头部搜索基础设施公司在生产中运行 Mercury。
3.2 语音 Agent：延迟不是基础设施细节，是用户听到的停顿
语音公司 OpenCall 的数据（官方博客引用其 CEO 原话）：切换 Mercury 后，P99 响应时间从数分钟降到 1 秒，P50 从 0.4 秒降到 0.2 秒以内，中位模型响应延迟约 170ms------且这是包含推理（reasoning）在内的端到端数字。对电话客服机器人来说，200ms 和 2s 的差别就是"对话"和"对讲机"的差别。
3.3 编码子代理：上下文压缩的 82% 延迟削减
最让后端工程师有体感的是 Augment Code 的案例：他们把上下文压缩（context compaction）、模型路由、MCP 工具搜索 三类支撑性调用迁移到 Mercury，其中压缩任务的延迟从约 150 秒降到 27 秒（-82% ），成本降低 90%，质量保持不变；工具搜索摘要在 1 秒内返回。
三个案例指向同一个模式：Agent 系统里 80% 的模型调用是"短、频、快"的支撑性任务 （路由、压缩、抽取、重排、校验），它们对智能上限的要求不高，但对延迟和单价极其敏感。这正是 dLLM 的生态位------不是取代前沿模型做规划，而是把前沿模型从杂活里解放出来。Inception 同步预告的 Mercury Router 更是把这个逻辑产品化了：用一个 dLLM 来理解请求，再路由给最合适的模型（含开源与闭源）------路由器自己必须足够快，否则会变成整个链路的瓶颈。
四、Java 实战之一：Schema-aligned JSON 抽取服务
Mercury 2.5 官方支持 Schema 对齐 JSON 输出，这对企业级 Java 后端是最实用的特性------结构化抽取终于不用再写脆弱的正则解析了。下面给出一个完整可编译的发票抽取客户端。
环境要求：JDK 17+（LTS，用到 record 与 text block）、Jackson 2.17.x。Maven 依赖：
xml
<!-- pom.xml 片段：仅一个外部依赖 -->
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.17.2</version>
</dependency>
java
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;
import java.util.List;
import java.util.Map;
/**
* Mercury 2.5 Schema-aligned JSON 抽取客户端
* 环境: JDK 17+, Jackson 2.17.x
* 密钥: 从环境变量 OPENROUTER_API_KEY 读取, 严禁硬编码
*/
public class MercurySchemaClient {
private static final String API_URL = "https://openrouter.ai/api/v1/chat/completions";
private static final String MODEL = "inception/mercury-2.5-preview";
private final HttpClient http;
private final ObjectMapper mapper = new ObjectMapper();
private final String apiKey;
public MercurySchemaClient(String apiKey) {
this.apiKey = apiKey;
this.http = HttpClient.newBuilder()
.connectTimeout(Duration.ofSeconds(10))
.build();
}
/** 发票抽取: 输入原始文本, 输出严格符合 schema 的结构化对象 */
public Invoice extractInvoice(String rawText) throws Exception {
// strict 模式要求: 所有字段进 required, additionalProperties=false
String schema = """
{
"type": "object",
"additionalProperties": false,
"properties": {
"vendor": { "type": "string" },
"invoiceNo": { "type": "string" },
"amountCny": { "type": "number" },
"issueDate": { "type": "string",
"description": "ISO-8601 format, e.g. 2026-09-08" },
"lineItems": {
"type": "array",
"items": {
"type": "object",
"additionalProperties": false,
"properties": {
"name": { "type": "string" },
"qty": { "type": "integer" },
"unitPriceCny": { "type": "number" }
},
"required": ["name", "qty", "unitPriceCny"]
}
}
},
"required": ["vendor", "invoiceNo", "amountCny", "issueDate", "lineItems"]
}
""";
String requestBody = mapper.writeValueAsString(Map.of(
"model", MODEL,
"messages", List.of(
Map.of("role", "system",
"content", "你是发票解析引擎。只从给定文本中抽取字段，"
+ "禁止编造数据；缺失的字符串字段填空串，数值字段填 0。"),
Map.of("role", "user", "content", rawText)),
"response_format", Map.of(
"type", "json_schema",
"json_schema", Map.of(
"name", "invoice",
"strict", true,
"schema", mapper.readTree(schema))),
"max_tokens", 2048));
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create(API_URL))
.timeout(Duration.ofSeconds(60))
.header("Content-Type", "application/json")
.header("Authorization", "Bearer " + apiKey)
// OpenRouter 归因头(可选): 站点与应用名
.header("HTTP-Referer", "https://example.com")
.header("X-Title", "Invoice Extractor")
.POST(HttpRequest.BodyPublishers.ofString(requestBody))
.build();
HttpResponse<String> response =
http.send(request, HttpResponse.BodyHandlers.ofString());
if (response.statusCode() != 200) {
throw new IllegalStateException(
"API HTTP " + response.statusCode() + ": " + response.body());
}
JsonNode root = mapper.readTree(response.body());
String content = root.path("choices").path(0)
.path("message").path("content").asText();
// usage 用于成本核算: 对照 $0.04/$0.15 每百万 token 的发布价
JsonNode usage = root.path("usage");
System.out.printf("tokens in/out = %d / %d%n",
usage.path("prompt_tokens").asInt(),
usage.path("completion_tokens").asInt());
return mapper.readValue(content, Invoice.class);
}
/** 目标结构: 字段与 schema 一一对应, record 保证不可变 */
public record Invoice(String vendor, String invoiceNo, double amountCny,
String issueDate, List<LineItem> lineItems) {}
public record LineItem(String name, int qty, double unitPriceCny) {}
public static void main(String[] args) throws Exception {
String apiKey = System.getenv("OPENROUTER_API_KEY");
if (apiKey == null || apiKey.isBlank()) {
System.err.println("请先设置环境变量 OPENROUTER_API_KEY");
System.exit(1);
}
String raw = """
发 票
销售方: 南昌云智科技有限公司
发票号码: INV-2026-0908
开票日期: 2026年09月08日
明细:
GPU服务器租赁 x 2 台, 单价 4500.00 元
技术支持服务 x 1 项, 单价 1200.00 元
价税合计: 10200.00 元
""";
Invoice inv = new MercurySchemaClient(apiKey).extractInvoice(raw);
System.out.println(inv);
}
}三个工程要点：其一，strict: true 模式下 schema 的所有属性必须列入 required 且关闭 additionalProperties，这是 OpenAI 兼容协议对结构化输出的通用约束；其二，用 record 承接反序列化结果，编译期就锁死字段契约；其三，把 usage 打出来做成本对账------按发布价算，上面这张发票的抽取成本不到万分之一美分，这才是"高频小调用"敢放量的底气。
五、Java 实战之二：流式延迟探针，验证厂商数字
1,107 tokens/sec 是厂商在特定 GPU 上的数字，你的生产环境能跑到多少，必须自己测。下面是一个零第三方依赖的流式探针（JDK 17+），输出 TTFT（首 token 延迟）与估算吞吐：
java
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.nio.charset.StandardCharsets;
import java.time.Duration;
import java.util.stream.Stream;
/**
* 流式延迟探针: 测量 TTFT 与估算吞吐
* 环境: JDK 17+, 零第三方依赖(手写最小 SSE/JSON 解析, 生产建议换 Jackson)
*/
public class StreamingLatencyProbe {
private static final String API_URL = "https://openrouter.ai/api/v1/chat/completions";
private static final String MODEL = "inception/mercury-2.5-preview";
public static void main(String[] args) throws Exception {
String apiKey = System.getenv("OPENROUTER_API_KEY");
if (apiKey == null || apiKey.isBlank()) {
System.err.println("请先设置环境变量 OPENROUTER_API_KEY");
System.exit(1);
}
String prompt = args.length > 0 ? args[0]
: "Explain in 200 words why diffusion language models achieve high throughput.";
String body = "{"
+ "\"model\":\"" + MODEL + "\","
+ "\"stream\":true,"
+ "\"messages\":[{\"role\":\"user\",\"content\":" + jsonQuote(prompt) + "}]}";
HttpClient client = HttpClient.newBuilder()
.connectTimeout(Duration.ofSeconds(10)).build();
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create(API_URL))
.header("Content-Type", "application/json")
.header("Authorization", "Bearer " + apiKey)
.POST(HttpRequest.BodyPublishers.ofString(body))
.build();
long startNs = System.nanoTime();
long firstTokenNs = -1;
int chunks = 0;
int contentChars = 0;
HttpResponse<Stream<String>> response = client.send(request,
HttpResponse.BodyHandlers.ofLines(StandardCharsets.UTF_8));
if (response.statusCode() != 200) {
response.body().forEach(System.err::println);
throw new IllegalStateException("HTTP " + response.statusCode());
}
// SSE 协议: 每个事件一行 "data: {...}", 结束标记 "data: [DONE]"
var iterator = response.body().iterator();
while (iterator.hasNext()) {
String line = iterator.next();
if (!line.startsWith("data:")) continue;
String data = line.substring(5).trim();
if (data.equals("[DONE]")) break;
int idx = data.indexOf("\"content\":\"");
if (idx < 0) continue; // 跳过 role/delta 元数据块
if (firstTokenNs < 0) firstTokenNs = System.nanoTime();
chunks++;
contentChars += extractContent(data, idx).length();
}
long endNs = System.nanoTime();
double ttftMs = (firstTokenNs - startNs) / 1e6;
double totalMs = (endNs - startNs) / 1e6;
double genMs = (endNs - firstTokenNs) / 1e6;
// 粗估 token 数: 英文约 4 字符/token; 中文输出需按 ~1.5 字符/token 重新校准
double estTokens = contentChars / 4.0;
System.out.printf("chunks=%d est_tokens=%.0f%n", chunks, estTokens);
System.out.printf("TTFT=%.0f ms | total=%.0f ms | est_throughput=%.1f tok/s%n",
ttftMs, totalMs, genMs > 0 ? estTokens / (genMs / 1000.0) : 0.0);
}
/** 从流式块中截取 content 字段值(处理 \" \\ \n 转义, 教学级实现) */
private static String extractContent(String data, int idx) {
int start = idx + "\"content\":\"".length();
StringBuilder sb = new StringBuilder();
for (int i = start; i < data.length(); i++) {
char c = data.charAt(i);
if (c == '\\' && i + 1 < data.length()) { sb.append(data.charAt(++i)); continue; }
if (c == '"') break;
sb.append(c);
}
return sb.toString();
}
/** 任意字符串 -> JSON 字符串字面量(免依赖演示用) */
private static String jsonQuote(String s) {
StringBuilder sb = new StringBuilder("\"");
for (char c : s.toCharArray()) {
switch (c) {
case '"' -> sb.append("\\\"");
case '\\' -> sb.append("\\\\");
case '\n' -> sb.append("\\n");
default -> sb.append(c);
}
}
return sb.append('"').toString();
}
}使用建议：把探针挂进 CI 的夜间任务，对 TTFT 和吞吐做时序记录。dLLM 的延迟特征与 AR 模型不同------去噪步数固定意味着吞吐对输出长度不敏感，你很可能观察到"生成 50 token 和 500 token 的总耗时差距远小于 AR 模型"，这个特性值得写进你的容量规划模型里。
六、Python 对照：并行工具调用的完整回路
官方将 parallel tool calls 列为 Mercury 2.5 的新能力：模型可以在一轮响应中同时发起多个工具调用 ，Agent 框架批量执行后一次性回填，把原来"调一个等一个"的串行回路压缩成一轮。下面是完整示例（Python 3.10+，openai>=1.40）：
python
"""Python 对照: Mercury 2.5 并行工具调用 (openai>=1.40, Python 3.10+)"""
import json
import os
import time
from openai import OpenAI
client = OpenAI(
base_url="https://openrouter.ai/api/v1", # OpenAI 兼容网关
api_key=***"OPENROUTER_API_KEY"], # 密钥只走环境变量
default_headers={
"HTTP-Referer": "https://example.com", # OpenRouter 归因头(可选)
"X-Title": "Mercury Parallel Tools Demo",
},
)
MODEL = "inception/mercury-2.5-preview"
TOOLS = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "查询指定城市的实时天气",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"],
},
},
},
{
"type": "function",
"function": {
"name": "get_calendar",
"description": "查询指定日期的日程安排",
"parameters": {
"type": "object",
"properties": {
"date": {"type": "string", "description": "YYYY-MM-DD"}
},
"required": ["date"],
},
},
},
]
def fake_tool_call(name: str, arguments: dict) -> str:
"""本地模拟实现: 真实项目中替换为天气 API / 日历服务调用"""
if name == "get_weather":
return f"{arguments['city']}: 26°C, 多云转晴, 东南风 2 级"
if name == "get_calendar":
return f"{arguments['date']}: 10:15 晨会, 14:28 尾盘复盘"
return "unknown tool"
def main() -> None:
messages = [
{
"role": "user",
"content": "南昌今天天气怎么样？顺便看看我今天(2026-09-09)有没有安排会议。",
}
]
# 第一轮: 期望模型一次性返回 2 个并行 tool_calls
t0 = time.perf_counter()
resp = client.chat.completions.create(
model=MODEL, messages=messages, tools=TOOLS, max_tokens=1024
)
msg = resp.choices[0].message
calls = msg.tool_calls or []
print(f"第一轮耗时 {time.perf_counter() - t0:.2f}s, 并行工具调用数: {len(calls)}")
# 批量执行所有工具调用, 结果按 tool_call_id 回填
messages.append(msg)
for call in calls:
result = fake_tool_call(call.function.name, json.loads(call.function.arguments))
messages.append(
{"role": "tool", "tool_call_id": call.id, "content": result}
)
# 第二轮: 模型基于工具结果生成最终回答
t1 = time.perf_counter()
final = client.chat.completions.create(model=MODEL, messages=messages, max_tokens=1024)
print(f"第二轮耗时 {time.perf_counter() - t1:.2f}s")
print("最终回答:", final.choices[0].message.content)
print(f"usage: {final.usage.prompt_tokens} in / {final.usage.completion_tokens} out")
if __name__ == "__main__":
main()如果模型退化为串行调用（一轮只发一个 tool_call），回路也能正常工作------上面的 for 循环对 1 个或 N 个调用同样成立。这正是写好 Agent 框架的原则：按并行设计，兼容串行降级。
最小连通性测试也可以直接用 curl：
bash
# 密钥通过环境变量注入, 不要写进脚本或命令行历史
export OPENROUTER_API_KEY="<your-key>"
# 非流式最小连通测试
curl -s https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "inception/mercury-2.5-preview",
"messages": [{"role": "user", "content": "用一句话介绍扩散语言模型"}],
"max_tokens": 64
}' | head -c 800七、选型框架：dLLM 放进多模型栈的正确位置
结合官方案例与架构常识，给出一个可直接套用的决策框架：
| 任务特征 | 推荐车道 | 理由 |
|---|---|---|
| 路由、意图分类、查询改写 | dLLM（Mercury 2.5 级） | 输出短、调用频、延迟敏感 |
| 上下文压缩、会话摘要 | dLLM | Augment 实测：延迟 -82%、成本 -90% |
| 结构化抽取（发票/工单/简历） | dLLM + schema JSON | 质量够用，单价低一个数量级 |
| RAG 重排、答案校验 | dLLM | 一次交互内几十次调用的主力 |
| 复杂规划、长链推理、架构级代码生成 | 前沿模型 | 智能上限仍是 AR 前沿模型的护城河 |
| 语音对话（TTFT < 200ms 硬约束） | Mercury Voice 类专用模型 | 通用模型难以稳定满足 |
一个实用的成本心智模型：如果你的 Agent 每天跑 100 万次支撑性调用、平均每次 500 输入 + 200 输出 token，按发布价（0.04/M 输入 + 0.15/M 输出）日成本约 50；换成 3/M + 15/M 档的前沿模型则是约 4,500------90 倍差距，这就是 Augment Code "成本 -90%" 的算术来源。当然，促销价结束后要按标准价（0.20/0.75）重算，差距会缩小到约 18 倍，但依然可观。
八、冷静剂：这次发布里需要打问号的地方
如实说几个我在交叉验证时注意到的限制，避免盲目跟风：
- "与前沿模型相当"是厂商自评。官方博客列出的对标（GPT-5.6 Luna Low、Gemini 3.5 Flash-Lite、Claude Haiku 4.5）没有附第三方基准测试细节，截至本文发布时也未见独立评测机构（如 LMSYS Arena、Artificial Analysis）的完整对比数据。40% 智能提升的度量口径同样未公开。做采购决策前，务必用自己的业务评测集实测。
- 闭源、仅 API 交付。Mercury 系列不开放权重，无法私有化部署到自有 GPU（企业版提供专属容量与合规控制，但仍是托管形态）。对数据不出域有硬性要求的团队，这条路走不通。
- 发布价是临时促销。0.04/0.15 是 launch 折扣，标准价 0.20/0.75。用促销价做的 ROI 测算要留出价格回归的余量。
- 基础设施可达性。我实测其文档站（docs.inceptionlabs.ai）对部分网络环境返回 Cloudflare 403，国内直连体验需要自行验证；走 OpenRouter 网关是更稳妥的接入路径，但多一层网关就多一层延迟与计费差。
- dLLM 的生态成熟度。工具链、微调生态、社区示例远少于 AR 模型；tunable reasoning 的具体参数语义文档尚不完整（文档站访问受限），需要灰度试错。
九、总结
Mercury 2.5 的意义不在于"又一个新模型"，而在于它把扩散式生成路线第一次以完整的产品形态推到了生产级 Agent 基础设施的位置：1,107 tokens/sec 的吞吐、260K 上下文、schema 对齐 JSON、并行工具调用，加上 Augment Code 和 OpenCall 两个可查证的延迟/成本案例，构成了一个清晰的工程叙事------在多模型 Agent 栈里，为"短、频、快"的支撑性调用专门配一条 dLLM 快车道。
对 Java/Python 后端的行动建议：先用本文的探针脚本在你的网络环境实测 TTFT 与吞吐，再挑一个真实的高频小任务（压缩、抽取或路由）做 A/B，用自己的业务指标验证厂商数字。范式革命从来不是靠发布会完成的，是靠一个个被迁移的生产调用完成的。
官方还预告了"迄今最大"的下一代模型将在未来数月发布------扩散路线的军备竞赛才刚进入下半场，值得持续关注。
版权声明：本文内容为原创，基于公开资料独立撰写。文中示例代码可自由使用于学习和个人项目。转载或引用请注明出处。
参考来源：
- Introducing Mercury 2.5 --- Inception Labs 官方博客（2026-09-08，Stefano Ermon 署名）- 用于全部 Mercury 2.5 规格、定价与生产案例数据
- Hacker News: Mercury 2.5（2026-09-08，首页热帖）- 用于发布事件的社区交叉验证
- OpenRouter: inception/mercury-2.5-preview - 用于模型 ID 与分发渠道验证
- GitHub Trending（2026-09-09 抓取）- 用于当日热点全景扫描
作者：超人不会飞