近一年，前沿商业大模型已成为科研人员日常工作的核心生产力工具，被广泛用于文献综述、论文写作、代码调试、数据分析等场景。
中科院体系内部署的磐石 100模型，基于 DeepSeek-R1 (671B 版本) 与 Qwen3 (8B/32B 版本) 微调，上下文长度限制为 32k 词元。同期商业模型的上下文长度已达 1024k 词元，相差约 32 倍。
本报告通过 3 项 Benchmark 实测（数学推理、代码调试、引用核查），客观对比五家大模型（Claude Opus 4.7、DeepSeek V4 Pro、MiMo V2.5 Pro、Kimi K2.6、磐石 100）实际表现。每个模型独立运行 20 次（数学 18 次 + 代码 1 次 + 引用 1 次），所有运行均可复现——原始输出、评分标准与验证脚本均已公开（见 01 / 02 / 03 详细报告）。
三项 Benchmark 均通过 Claude Code (CC) 命令行工具 (claude -p) 与模型交互。CC 按 Anthropic tool-use 协议管理 agent loop，提供 Read / Edit / Bash / WebSearch 等工具。各模型的接入方式如下：
| 模型 | 调用端点 | 01 数学推理 | 02 代码调试 / 03 引用核查 |
|---|---|---|---|
| opus | Anthropic 官方 API (OAuth Max) | CC 单轮 工具启用 · 3 次独立采样 |
CC agent loop 沙盒隔离 · Read/Edit/Bash/WebSearch |
| deepseek | DeepSeek Anthropic 兼容端点 api.deepseek.com/anthropic |
CC 单轮 工具启用 · 3 次独立采样 |
CC agent loop 沙盒隔离 · Read/Edit/Bash/WebSearch |
| mimo | Xiaomi MiMo Anthropic 兼容端点 token-plan-cn.xiaomimimo.com/anthropic |
CC 单轮 工具启用 · 3 次独立采样 |
CC agent loop 沙盒隔离 · Read/Edit/Bash/WebSearch |
| kimi | Moonshot Kimi Anthropic 兼容端点 api.moonshot.cn/anthropic |
CC 单轮 工具启用 · 3 次独立采样 |
CC agent loop 沙盒隔离 · Read/Edit/Bash/WebSearch |
| 磐石100 | cstcloud OpenAI 兼容端点 uni-api.cstcloud.cn/v1 |
HTTP 流式单轮 无工具 · 3 次独立采样 |
CC agent loop 沙盒隔离 · 工具描述已注入但模型未执行 |
CC 接入方式：opus 使用 claude -p --model claude-opus-4-7 直接调用 Anthropic 官方 OAuth Max 订阅；deepseek 通过设置环境变量 ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic 将 CC 底层端点指向 DeepSeek 的 Anthropic 兼容 API；MiMo 同理指向 Xiaomi 端点 (mimo-v2.5-pro)；kimi 同理指向 Moonshot 端点 (kimi-k2.6)；磐石100 同理指向 cstcloud 端点 (S1-Base-Ultra)。所有调用参数、原始输出与运行脚本均保存在本项目仓库中，可重跑验证。
| Benchmark | 任务 | 评分规则 | 采样 |
|---|---|---|---|
| 01 · 数学推理 | 6 道数学题（代数不等式 · 解析几何 · 数论 · 组合计数 · 微积分极限 · 条件概率） 难度：清北强基笔试 ~ Putnam 中段 |
每题 10 分。最终答案错误即 0 分；答案正确 + 推导思路正确即 10 分。 | 每模型每题 3 次独立调用 |
| 02 · 代码调试 | 含 5 处 Bug 的量子谐振子仿真项目 需在沙盒中定位修复全部 Bug 并通过物理验证 |
每 Bug 修复+findings 描述 1.5 × 5 = 7.5 · 无 warning/error 1.0 · 4 项物理判据各 0.375 = 1.5 · 满分 10 | 每模型 1 次 agent 运行 |
| 03 · 引用核查 | LaTeX 论文含 23 条引用（8 处注入错误） 需作为审稿人逐条检索验证真实性与一致性 |
TP 识别 0.625 × 8 = 5 · 正确分类 0.625 × 8 = 5 · 假阳性每条 −0.5 · 下限 0 | 每模型 1 次 agent 运行 |
所有评分基准公开在 solutions/ 目录下，包含正确答案和自动验证脚本。Benchmark 运行脚本 run_benchmark.py、run_codedebug.py、run_citation.py 可在相同环境下重跑验证。原始输出保存在 opus-answer/、deepseek-answer/、mimo-answer/、kimi-answer/、panshi100-answer/ 目录。
磐石 100 是中科院自动化研究所等单位联合研发的科学领域大模型体系，2026 年 4 月正式亮相。底座为磐石·科学基础大模型（S1-Base），提供 8B / 32B / 671B 三种参数规模。
根据 Hugging Face 官方模型卡，S1-Base-671B 训练自 DeepSeek-R1-671B，S1-Base-8B 与 S1-Base-32B 分别训练自 Qwen3-8B 与 Qwen3-32B。微调使用了 1.7 亿篇科学论文与数百万条高质量科学推理数据。所有版本上下文长度统一为 32k 词元。模型以 Apache 2.0 协议开源。
DeepSeek V4 Pro 由杭州深度求索公司研发，2026 年发布。采用异构混合专家（MoE）架构，总参数 1.6 万亿，预训练数据 33 万亿词元。支持三档推理模式。上下文长度 1024k 词元，最大单次输出 38.4 万词元。API 国内可直接调用，标价：输入 ¥3 / 百万词元，输出 ¥6 / 百万词元。
Claude Opus 4.7 由美国 Anthropic 公司研发，2026 年发布，是国际公认在编程、长文档分析、复杂推理等任务上的第一梯队模型。上下文长度 1024k 词元，最大单次输出 12.8 万词元。API 仅以美元计价，折合人民币输入约 ¥36 / 百万词元，输出约 ¥180 / 百万词元。
MiMo V2.5 Pro 由小米 AI 团队研发，2025 年末发布。为纯文本大语言模型，上下文长度 1024k 词元，支持工具调用与 agent 工作流。通过 Token Plan 订阅制提供服务，国内可直接访问（token-plan-cn.xiaomimimo.com）。在本次实测中通过 Anthropic 兼容端点接入 Claude Code，以与其模型完全一致的方式执行所有 Benchmark。
Kimi K2.6 由北京月之暗面科技有限公司（Moonshot AI）研发，2026 年发布。为多模态大语言模型（支持文本与视觉输入），上下文长度 262k 词元，支持工具调用与 agent 工作流。通过 Moonshot Anthropic 兼容端点（api.moonshot.cn/anthropic）提供服务，国内可直接访问。本次实测通过 Anthropic 兼容端点接入 Claude Code，完成全部三项 Benchmark。
| 维度 | 磐石 100 (S1-671B) | DeepSeek V4 Pro | Claude Opus 4.7 | MiMo V2.5 Pro | Kimi K2.6 |
|---|---|---|---|---|---|
| 研发方 | 中科院自动化所等 | 深度求索（杭州） | Anthropic（美国） | 小米（北京） | 月之暗面（北京） |
| 底座来源 | DeepSeek-R1 / Qwen3 微调 | 自研 V4 系列 | 自研 Opus 4 系列 | 自研 MiMo 系列 | 自研 Kimi 系列 |
| 参数规模 | 671B（总参数） | 1.6T 总 / 49B 活跃 | 未公开 | 未公开 | 未公开 |
| 上下文长度 | 32k 词元 | 1024k 词元 | 1024k 词元 | 1024k 词元 | 262k 词元 |
| 训练数据量 | 微调 1.7 亿论文 | 预训练 33T 词元 | 未公开（业界估计同量级） | 未公开 | 未公开 |
| 参考单价 输入/输出 ¥/M 词元 | — | ¥3 / ¥6 | ¥36 / ¥180 | 订阅制 | ¥6.5 / ¥27 |
| 适用场景 | 短文本简单推理 | 通用科研主力 | 高难度复杂任务 | 通用科研 · agent 工作流 | 通用科研 · agent 工作流 |
注：下文用词元（token）作为计量单位。约 1 词元 ≈ 1.5 个汉字，1024k 词元约等于 150 万字。
上下文长度不仅是"一次能装多少内容"。对科研场景而言，更关键的影响在于agentic workflow 的词元消耗是指数级的——每轮工具调用都在不断占用上下文。
| 工作模式 | 每轮消耗 | 32k 可跑轮次 | 262k 可跑轮次 | 1024k 可跑轮次 |
|---|---|---|---|---|
| 纯聊天（一问一答） | 1–3k | ~20 轮 | ~150 轮 | ~500 轮 |
| Agent 读文件 + 思考 | 3–5k | ~8 轮 | ~60 轮 | ~250 轮 |
| Agent + 工具调用 (WebSearch/Bash/Python) | 8–25k | 1–3 轮 | ~15 轮 | ~60 轮 |
纯聊天场景下 32k 词元绰绰有余——一次对话几十轮都不成问题。但一旦进入 agent 模式——读文件、分析、调用 Crossref API、阅读搜索结果、再分析——每轮轻松消耗 15–25k 词元。32k 窗口在 agent 模式下只能支撑 1–3 轮，根本跑不完一个完整的引用核查或 Bug 修复流程。
在完全相同的 prompt 和工具描述下，同一套测试框架（Claude Code，claude -p）中五个模型的表现截然不同：
| 模型 | 上下文 | 02 代码调试 turns | 03 引用核查 turns | 是否完成 agent 工作流 |
|---|---|---|---|---|
| opus | 1024k 词元 | 20 | 64 | ✓ 完整 |
| deepseek | 1024k 词元 | 21 | 65 | ✓ 完整 |
| MiMo | 1024k 词元 | ~20 | ~25 | ✓ 完整 |
| kimi | 262k 词元 | 19 | 63 | ✓ 完整 |
| 磐石100 | 32k 词元 | 1 | 1 | ✗ 首轮即止 |
磐石 100 在 02 和 03 中均为 turns=1——不是它"不想干活"，而是 32k 上下文里塞进了 system prompt + 题目 + 工具协议描述之后，已经耗尽可用空间，模型只能立刻 end_turn。这也解释了为什么磐石在 01 纯数学推理（单轮、无工具调用）中部分题目仍能得出正确答案——不是"推理能力"有断档，是"上下文容量"让 agent 模式完全无法启动。
| 科研任务 | 工作模式 所需典型轮次 |
磐石 32k | Kimi 262k | DeepSeek 1024k | Claude 1024k | MiMo 1024k |
|---|---|---|---|---|---|---|
| 改一段论文摘要 | 纯聊天，< 5 轮 | ✓ | ✓ | ✓ | ✓ | ✓ |
| 写论文 introduction | 纯聊天，10–20 轮 | 临界 | ✓ | ✓ | ✓ | ✓ |
| 单文件代码审阅 + 修改 | Agent，3–8 轮 | ✗ | ✓ | ✓ | ✓ | ✓ |
| 多文件 Bug 修复（如 02） | Agent + Bash，15–25 轮 | ✗ | ✓ | ✓ | ✓ | ✓ |
| 论文引用核查（如 03，含 WebSearch） | Agent + 搜索，30–70 轮 | ✗ | ✓ | ✓ | ✓ | ✓ |
| 三篇论文交叉对比 + 综述 | Agent + 搜索，50–150 轮 | ✗ | 临界 | ✓ | ✓ | ✓ |
| 大规模文献调研 / 代码库重构 | Agent 深度循环，200+ 轮 | ✗ | ✗ | 临界 | 临界 | 临界 |
上下文窗口决定了"能不能跑"，而速度和稳定性决定了"跑起来之后好不好用"。在 agent 工作流中，速度的差异是乘数级的——每轮慢几秒，60 轮之后就是几十分钟的差距。
| 模型 | 02 代码 Debug | 03 引用核查 | 单轮均速 (03) | 稳定性问题 |
|---|---|---|---|---|
| opus | 130.8s · 20 turns | 610.9s · 64 turns | ~9.5s/turn | 0 次 |
| deepseek | 464.5s · 21 turns | 2495.0s · 65 turns | ~38.4s/turn | 0 次 |
| mimo | 327.7s · ~20 turns | 848.8s · ~25 turns | ~34.0s/turn | 0 次 |
| kimi | 119.9s · 19 turns | 2363.5s · 63 turns | ~37.5s/turn | 2 次 |
| 磐石100 | 225.8s · 1 turn | 59.2s · 1 turn | — | 系统性 |
关键发现：
end_turn 放弃——耗时没有意义。用户等待时间被白白浪费，却得不到可用结果。这就是"慢到没法用"的本质：不只是慢，是付出等待成本后依然失败。本节通过 3 项 Benchmark 实测对比五个模型在科研任务上的表现。每项按统一标准打分（满分 10 分）。所有数据均来自真实运行，原始输出可在 01 / 02 / 03 详细报告中查看。
| 模型 | 01 · 数学推理 6题 / 满分60 |
02 · 代码 Debug 5 Bug / 满分10 |
03 · 引用核查 8 错误 / 满分10 |
加权均分 (百分制) |
|---|---|---|---|---|
| opus claude-opus-4-7 · OAuth Max | 60 / 60 | 10.0 / 10 | 5.75 / 10 | 91.5 |
| deepseek deepseek-v4-pro[1m] · DS 官方 | 60 / 60 | 10.0 / 10 | 8.5 / 10 | 97.0 |
| mimo mimo-v2.5-pro · Xiaomi Token Plan | 50 / 60 | 10.0 / 10 | 6.9 / 10 | 83.8 |
| kimi kimi-k2.6 · Moonshot API | 60 / 60 | 10.0 / 10 | 6.25 / 10 | 92.5 |
| 磐石100 S1-Base-Ultra (S1-671B) · uni-api | 25 / 60 | 0.4 / 10 | 0.0 / 10 | 25.8 |
加权说明：01 占 60% 权重（6 题 × 10 分），02、03 各占 20%（各 10 分）。注：01 数学每题独立运行 3 次（共 18 跑），下文「N 跑」指 3 次中的 N 次。
opus 在 03 中命中 6/8 错误（漏检 2 处位置错误），分类 4/8 准确（E5/E6 领域伪造未细分），1 条假阳性，得 5.75/10。
MiMo 在 01 中 Q5（极限题）三跑全错（0 分），Q2/Q6 各有一跑错误；03 中漏检 2 处位置错误，Reynolds2019 分类有偏差，得 6.9/10。
kimi 在 01 中 6 题均 10/10（best-of-3），有两跑失败（Q1 run3 reasoning截断空输出、Q4 run3 超时）但不影响得分。02 一跑 10/10。03 命中 6/8（漏检 E7/E8 位置错误），分类 4/8，0 假阳性，得 6.25/10。加权均分 92.5。
磐石 100 在三项任务中均垫底，与商业模型存在系统性差距。
详情：01 完整报告 · 02 完整报告 · 03 完整报告
题目范围：代数不等式 · 解析几何 · 数论 · 组合计数 · 微积分极限 · 条件概率。难度相当于清北强基笔试到 Putnam 中段。
评分规则：每题满分 10 分。最终答案错误即 0 分；答案正确后再加推导思路分。每模型每题独立采样 3 次。
| 模型 | 题1 代数 | 题2 几何 | 题3 数论 | 题4 组合 | 题5 极限 | 题6 概率 | 合计 / 60 |
|---|---|---|---|---|---|---|---|
| opus | 10 | 10 | 10 | 10 | 10 | 10 | 60 |
| deepseek | 10 | 10 | 10 | 10 | 10 | 10 | 60 |
| mimo | 10 | 10 | 10 | 10 | 0 | 10 | 50 |
| kimi | 10 | 10 | 10 | 10 | 10 | 10 | 60 |
| 磐石100 | 10 | 10 | 0 | 0 | 5* | 0 | 25 |
磐石 100 失分分析：题 3、4、6 均为空输出——思考阶段消耗满 8192 completion tokens（finish_reason=length），正式回答 content_len=0。
题 5 推导到二阶系数 $\pi^2/12$ 后被截断，给 5/10 部分分。
kimi 失分情况：题 1 run3 思考词元耗尽导致空输出 (finish_reason=length)，题 4 run3 超时 (exit code 0xFFFFFFFF)。其余 16/18 跑全部满分，best-of-3 全部 10/10，总计 60/60。
MiMo 失分分析：题 5（极限题）三跑全错——三次运行均未推出 $\pi^2/12$，run1 得 $(\ln2)^2/4 - \pi^2/24$，run2 得 $\pi^2/12 - (\ln2)^2/2$，run3 得 $\ln2 + \pi^2/12$，该题对该模型为系统性失败。题 2 run3 得出错误定点 $(7/4, -3\sqrt{3}/4)$，题 6 run2 错误答案为 $1/2$。opus 与 deepseek 则 6 题全对，3 次采样答案均一致。
→ 完整 6 题展开
题面
求极限 $$\lim_{n \to \infty}\ n^2 \left( \int_0^1 \frac{1}{1+x^n}\,\mathrm{d}x \;-\; 1 \;+\; \frac{\ln 2}{n} \right)$$ 的精确封闭形式。
标准答案：$\dfrac{\pi^2}{12}$
通过 $u=x^n$ 代换 + 级数展开 + Dirichlet eta 函数求值，完整推导出 $\frac{\pi^2}{12}$，并给出更高阶项 $-\frac{3\zeta(3)}{4n^3}$。
几何级数展开 + 逐项积分 + 已知交错级数 $\sum (-1)^k/k^2 = -\pi^2/12$，干净利落得到答案。
变量替换后展开到 $\dfrac{\pi^2}{12} a - \dfrac{3}{\cdots}$，在二阶系数后被长度截断，未写出最终极限结论。但 $\pi^2/12$ 已显式出现在渐近展开中，按部分分给 5/10。
任务：给定一个含 5 处 Bug 的量子谐振子仿真项目，模型需在沙盒中阅读源码、定位修复全部 Bug、运行 python main.py 无 warning/error，并满足 4 项物理判据（能量、⟨x⟩、⟨p⟩、模长）。输出 findings.md。
| 模型 | 耗时 (s) | turns | 5 处 Bug | 4 项判据 | 无 warning | 得分 / 10 |
|---|---|---|---|---|---|---|
| opus | 130.8 | 20 | 5 / 5 | 4 / 4 | ✓ | 10.0 |
| deepseek | 464.5 | 21 | 5 / 5 | 4 / 4 | ✓ | 10.0 |
| mimo | 327.7 | ~20 | 5 / 5 | 4 / 4 | ✓ | 10.0 |
| kimi | 119.9 | 19 | 5 / 5 | 4 / 4 | ✓ | 10.0 |
| 磐石100 | 225.8 | 1 | 0 / 5 | 1 / 4 | ✗ | 0.4 |
opus、deepseek、MiMo 与 kimi 的修复结果一致（verify 输出完全相同），均修对全部 5 处 Bug、4 项物理判据全部满足。
磐石 100 turns=1——模型在首轮就 end_turn，输出中包含伪 JSON tool call 但从未实际调用任何工具。
→ 完整报告
任务：作为学术审稿人复核一篇 LaTeX 论文（N-queens 统计力学）的 23 条引用。其中 8 处为人为注入的错误（2 完全捏造 + 2 字段篡改 + 2 领域伪造 + 2 位置错误），剩余 15 条为真实引用。模型需使用 WebSearch / Crossref API 等逐条验证，输出 findings.md。
| 模型 | 耗时 (s) | turns | TP 命中 / 8 | 假阳性 | 得分 / 10 |
|---|---|---|---|---|---|
| opus claude-opus-4-7 | 610.9 | 64 | 6 / 8 | 1 条 (−0.5) | 5.75 |
| deepseek deepseek-v4-pro[1m] | 2 495.0 | 65 | 8 / 8 | 3 条 (−1.5) | 8.5 |
| mimo mimo-v2.5-pro | 848.8 | ~25 | 6 / 8 | 0 条 | 6.9 |
| kimi kimi-k2.6 | 2 363.5 | 63 | 6 / 8 | 0 条 | 6.25 |
| 磐石100 S1-Base-Ultra | 59.2 | 1 | 0 / 8 | — | 0.0 |
deepseek 全部 8 处错误命中（含 4 种类型全部分类正确），3 条假阳性扣 1.5 分，得 8.5/10。
opus 64 turns 完成，命中 6/8（漏检 E7/E8 两处位置错误），E5/E6 领域伪造被笼统归入"完全捏造"未细分，1 条假阳性，得 5.75/10。
MiMo 命中 6/8（漏检 E7/E8 位置错误——在引用位置合理性上缺少逐条语义检查），Reynolds2019 分类有偏差（认为是期刊错误而非捏造，查到一篇同名 LNCS 论文），无假阳性，得 6.9/10。
kimi 命中 6/8（同 opus / MiMo，漏检 E7/E8 位置错误），E3/E4 字段篡改 + E1/E2/E5/E6 实体不存在检测准确，E5/E6 未区分"领域伪造"vs"完全捏造"，0 假阳性，得 6.25/10。
磐石 100 再次 turns=1——输出了一段伪 JSON {"tool": "Read", "params": {"file_path": "./paper.tex"}} 然后立即 end_turn，从未调用 Crossref / Google Scholar。
→ 完整报告
| Benchmark | harness | turns | 失败模式 |
|---|---|---|---|
| 01 · 数学推理 | HTTP 单轮 | — | 推理黑洞：题 3/4/6 思考阶段消耗满 8192 tokens，finish_reason=length，正式回答为空。HTTP streaming 模式下 reasoning_content 无限填充但 content 始终为空。 |
| 02 · 代码 Debug | Agent (claude -p) | 1 | 伪工具调用：CC 向模型注入了完整的 Anthropic tool-use 协议描述（含所有可用工具的函数签名）。磐石 100 输出的工具调用形如 ```json\n{"tool": "Glob", "params": {"pattern": "*.py"}}\n```——这是 markdown 代码块，不是 Anthropic 协议的 tool_use content block（后者需要 id/name/input 结构化字段）。CC 无法解析这些文本块为工具调用，模型据此幻想文件结构并编造 Bug 位置（如声称 wavefunction.py:42 有错——该文件在项目中根本不存在）。 |
| 03 · 引用核查 | Agent (claude -p) | 1 | 同 02：模型在首轮输出执行计划 + 伪 {"tool": "Read"} 文本块，随即 end_turn。从未实际调用 Crossref / WebSearch / WebFetch。tasks.json 与 findings.md 均不存在。 |
tool_use content block。作为对照：opus 与 deepseek 均收到了完全相同的工具描述，正常生成结构化 tool_use 块并完成了真实工具调用（02 中 20-21 turns、03 中 64-65 turns）。磐石 100 在两次 agent 任务中 turns=1——并非"不努力"，而是不会使用工具。finish_reason=length 且 content 字段为空。3 次独立采样中，3 次均为空输出——说明这不是随机波动，而是该模型在处理长推理链题目时的系统性问题。稳定性直接影响实际可用性——一个能在 10 分钟内稳定跑完 60+ turns agent 任务的模型，与一个思考到一半空输出、或者偶尔超时挂掉的模型，对科研工作流的信任度截然不同。
| 模型 | 01 异常 / 总运行 | 02 Agent 状态 | 03 Agent 状态 | 故障模式 |
|---|---|---|---|---|
| opus | 0 / 18 | ✓ 正常 · 20 turns | ✓ 正常 · 64 turns | 无 |
| deepseek | 0 / 18 | ✓ 正常 · 21 turns | ✓ 正常 · 65 turns | 无 |
| mimo | 0 / 18* | ✓ 正常 · ~20 turns | ✓ 正常 · ~25 turns | Q5 三跑全错（非稳定性故障） |
| kimi | 2 / 18 | ✓ 正常 · 19 turns | ✓ 正常 · 63 turns | 1 次推理耗尽（空输出）+ 1 次超时（进程被杀） |
| 磐石100 | 12 / 18 | ✗ turns=1 | ✗ turns=1 | 系统性：9 次空输出 + 1 SSL + 1 HTTP 502 + 1 截断 + 2 次 agent 首轮放弃 |
* MiMo 在 01 中 Q5 三跑全错、Q2 run3 定点错误、Q6 run2 概率错误，但这些均为答案错误（模型输出正常完成），不属于稳定性故障（空输出 / 超时 / 崩溃）。
关键观察：
solutions/math/ · solutions/code_debug/ · solutions/citation/opus-answer/ · deepseek-answer/ · mimo-answer/ · kimi-answer/ · panshi100-answer/run_benchmark.py · run_codedebug.py · run_citation.py