作者注：拆解 Claude 推出 NIST 橢圓曲線種子來源的過程，說明這次結論的邊界，並給出科研人員能直接複用的 3 種 AI Agent 用法、代碼與成本控制方法。
2026 年 10 月 17 日，Anthropic Frontier Red Team 發佈了一篇研究：內部研究模型在沒有任何提示的情況下，用約半小時推出了 NIST P-192、P-224、P-256、P-384、P-521 五條曲線種子的生成方式。這些種子沒有經過任何哈希算法，而是 1990 年代 C 庫自帶的 lrand48 僞隨機數生成器的輸出，初始值是 Unix 時間戳。@AnthropicAI 的官方帖只寫了一句“It is just timestamps.”，瀏覽量約 85.5 萬。
這不是密碼學破解，也不是新漏洞。 對科研人員來說，這個案例的價值在於 Claude 的工作方式：推演機制，寫腳本驗證，用統計證據排除巧合。這套流程可以直接遷移到你自己的課題。
核心價值：讀完本文，你會知道這件事證明了什麼、不證明什麼，並拿到 3 種可以馬上用的科研 AI Agent 工作流，每種都附操作步驟和可運行代碼。
Claude 解開 NIST 橢圓曲線種子之謎：核心要點
| 要點 | 說明 | 對科研人員的意義 |
|---|---|---|
| 謎題背景 | 2000 年 NIST 在 FIPS 186-2 中採納 ECDSA，曲線種子由 NSA 提供，沒有來源說明 | 26 年無人解出的問題，可以作爲檢驗 AI 推理能力的樣本 |
| 結論 | 種子來自 lrand48 輸出，用 1997 年 5 月至 1998 年 4 月之間的時間戳初始化 | 結論能被任何人復現，驗證成本很低 |
| 關鍵方法 | 推演軟件寫法，自己寫掃描器，用統計特徵定位，再恢復狀態 | 這三步可以遷移到實驗數據分析、逆向建模等任務 |
| 安全含義 | 不構成漏洞，用戶無需改配置或遷移 | 寫綜述或報告時要準確表述，不要誇大 |
| 遺留問題 | B-163 種子未解出，P-224 至 P-521 的基點 G 生成方式仍不清楚 | AI 給出的結論同樣有邊界，需要記錄未解部分 |
NIST 橢圓曲線種子之謎：這件事證明了什麼
ECDSA 標準爲每條曲線公佈了一個 seed，種子的哈希用來確定曲線係數 b。P-256 的種子是 C49D3608 86E70493 6A6678E1 139D26B7 819F7E90。由於來源一直沒有說明，社區長期擔心 NSA 可能刻意挑選了帶弱點的參數。Koblitz 與 Menezes 寫過綜述《A Riddle Wrapped in an Enigma》，Filippo Valsorda 還爲此設了 36864 美元懸賞。坊間一度流傳 Jerry Solinas 用一句玩笑話的哈希生成種子，這個說法後來被證明是錯的。
這次結論的實際作用，是增強了對這些曲線的信任。種子是用時鐘初始化的普通僞隨機數生成器跑出來的，沒有留下人爲挑選的空間，任何人都能復現。原文也提到，有少量同樣可用的候選曲線被跳過，原因未知，但數量很少，不像是刻意挑選弱曲線。懸賞獎金將捐給 Internet Security Research Group。
在論文或組會中引用這件事時，比較準確的表述是：“AI 復原了一個歷史參數的生成過程，並讓它可以被複現。”不要寫成“AI 攻破了橢圓曲線”。
Claude 推演種子的 4 個步驟拆解
這次推理沒有靠暴力猜測。整個過程是一條可以檢查的推理鏈：
- 換問題：不再猜“哪句話被哈希了”，改爲推演 1997 年寫曲線生成程序的人最可能怎麼寫代碼。結論是他們大概率直接用了 C 庫自帶的隨機數生成器。
- 寫掃描器：在已公佈的種子上逐位滑動，測試相鄰片段是否像某種 1990 年代生成器的連續輸出，一共覆蓋 34 種生成器與切片組合。
- 找統計簽名：把種子切成 32 位字後，相應位置的高位全部爲 0，隨機出現的概率約 1/5810。這符合 lrand48 只返回 48 位狀態中高 31 位的特徵。
- 恢復狀態並回推：窮舉 17 個隱藏位的 2^17 種取值，用後續的字校驗。對截斷更多的種子，用 LLL 格基約減求解。然後把狀態往回推，直到出現 srand48 的初始化形態，也就是低 16 位等於 0x330E。
推理過程中還有一個細節：模型一度懷疑自己是不是處在測試環境裏，隨後用“10 條曲線、每條 160 位全部吻合，不可能是巧合”排除了這個懷疑。這種“先質疑自己，再用證據收口”的做法，正是科研 Agent 最需要的。
科研型 AI Agent 快速上手：一個 Key 調用旗艦模型
動手之前，先把 API 調用鏈路跑通。APIYI 提供 OpenAI 兼容接口，一個 Key 可以調用 claude-opus-5-5，也可以切換到 GPT 系、Gemini 系旗艦模型做交叉驗證。
接入步驟不必在這裏重複，直接參考 API易 官方快速入門文檔：docs.apiyi.com/getting-started。按文檔在控制檯創建 Key、拿到 base_url（https://api.apiyi.com/v1），用文檔裏的示例確認鏈路暢通即可，計費方式與可用模型以控制檯爲準。
後文 3 種用法共用一個很小的封裝，保存爲 research_client.py，核心只做兩件事：按階段選模型，並累計 token 用量用於成本控制。
# research_client.py
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ["APIYI_API_KEY"], base_url="https://api.apiyi.com/v1")
CHEAP = os.environ.get("CHEAP_MODEL", "claude-opus-5-5") # 填控制檯裏的輕量模型名
FLAGSHIP = "claude-opus-5-5"
USAGE = {"prompt": 0, "completion": 0, "calls": 0}
def chat(messages, stage="draft", max_tokens=2048, temperature=0.2):
"""stage='draft' 走便宜模型；stage='verify' 走旗艦模型。"""
r = client.chat.completions.create(model=FLAGSHIP if stage == "verify" else CHEAP,
messages=messages, max_tokens=max_tokens, temperature=temperature)
USAGE["prompt"] += r.usage.prompt_tokens
USAGE["completion"] += r.usage.completion_tokens
USAGE["calls"] += 1
return r.choices[0].message.content
def ask(prompt, stage="draft", system=None, max_tokens=2048):
msgs = ([{"role": "system", "content": system}] if system else []) + [{"role": "user", "content": prompt}]
return chat(msgs, stage=stage, max_tokens=max_tokens)
def report():
print(f"累計調用 {USAGE['calls']} 次，prompt={USAGE['prompt']}，completion={USAGE['completion']}")
科研 AI Agent 成本控制：便宜模型調通，旗艦模型做關鍵驗證
科研任務往往要多輪迭代，一開始就全程使用旗艦模型，額度會消耗在格式錯誤、JSON 解析失敗這類低價值問題上。比較穩妥的做法是按階段分配模型：
| 階段 | 推薦模型 | 判斷標準 | 典型 max_tokens |
|---|---|---|---|
| 流程調試（Prompt 格式、解析、評分器） | 輕量便宜模型 | 管道能端到端跑通，沒有報錯 | 512-1024 |
| 假設生成（列舉候選機制） | 輕量模型優先，覆蓋不足時再換旗艦 | 候選列表能覆蓋你已知的主流假設 | 1024-2048 |
| 機制推演與關鍵驗證 | claude-opus-5-5 | 結論會寫進論文或決定後續實驗投入 | 2048-4096 |
| 交叉驗證 | 同一個 Key 切換另一家旗艦模型 | 兩個模型獨立給出相同結論 | 2048 |
實際操作時可以記住一條規則：腳本第一次運行用便宜模型，結論第一次落地用旗艦模型。
科研型 AI Agent 用法一：先推演機制，再驗證
這一步對應 Claude 的“換問題”：不直接猜答案，先推演產生數據的機制，再用數據檢驗。它適合以下場景：實驗數據出現異常規律、需要逆向推測歷史數據的生成過程、復現論文時找不到參數來源。
操作步驟
- 只描述現象，不給猜測：把觀測數據、已知約束和年代背景交給模型，不要寫“我覺得是 XX 導致的”，避免把模型帶偏。
- 要求列出機制和可證僞預測：每個候選機制都要附一條“如果這個機制成立，數據中應該出現什麼特徵”。
- 按驗證成本排序：讓模型按“驗證所需時間”從低到高排列，先驗證最便宜的那幾條。
- 用旗艦模型複覈排序：候選列表可以先用便宜模型生成，最終的排序和推演交給 claude-opus-5-5。
Prompt 模板
from research_client import ask, report
PROMPT = """你是一名嚴謹的研究助理。下面是一組觀測數據和背景，不包含任何關於成因的線索。
【觀測】
{observation}
【背景約束】
{context}
請完成：
1. 推演“產生這組數據的過程最可能怎麼實現”，至少列出 5 個候選機制；
2. 每個機制給出一條可證僞預測：若成立，數據中必然出現的可檢驗特徵；
3. 估計驗證每條預測的成本（低/中/高），按成本升序輸出；
4. 指出你最不確定的環節。
輸出爲 Markdown 表格 + 簡短說明。"""
draft = ask(PROMPT.format(
observation="NIST P-256 種子：C49D3608 86E70493 6A6678E1 139D26B7 819F7E90",
context="1997-1998 年由政府機構用軟件生成；官方未公佈生成方法；常見猜測爲短語哈希但未被證實",
), stage="draft")
final = ask("請審查並修正以下候選機制列表，刪除無法證僞的條目，重新排序：\n" + draft,
stage="verify", max_tokens=3000)
print(final)
report()
判斷這一步是否合格，可以看兩條標準：每個機制是否都有可證僞預測；排在第一位的驗證是否能在一小時內完成。只要有一條不滿足，就讓模型重寫。
科研型 AI Agent 用法二：讓模型寫掃描/驗證腳本
這一步對應 Claude 自己寫掃描器、覆蓋 34 種生成器與切片組合的做法。關鍵在於把“看起來像”轉換成“統計上不太可能是巧合”。參數掃描、信號檢測、搜索數據中隱藏結構等任務都可以這樣處理。
操作步驟
- 把用法一中驗證成本最低的預測交給模型，要求它寫只依賴標準庫的掃描腳本。
- 要求腳本同時跑一組隨機對照，輸出“真實數據命中率”和“隨機數據命中率”。
- 由你在本地運行腳本，模型只負責寫代碼，不負責報告結果。
- 結果顯著時，再讓旗艦模型寫更嚴格的狀態恢復或擬合腳本。
示例：復現“高位全爲 0”這類統計簽名
下面的腳本演示了這次案例中籤名的原理。lrand48 返回的是 48 位狀態的高 31 位，所以裝進 32 位字後最高位一定是 0，而真隨機數據每個字的最高位爲 0 的概率只有一半。
import os
def lrand48_stream(seed32, n):
x = (seed32 << 16) | 0x330E # srand48 初始化：低 16 位固定爲 0x330E
out = []
for _ in range(n):
x = (0x5DEECE66D * x + 0xB) % 2**48
out.append(x >> 17) # lrand48 只返回高 31 位
return out
def top_bit_zero_ratio(words):
return sum(1 for w in words if w >> 31 == 0) / len(words)
lr = lrand48_stream(870000000, 20) # 1997 年前後的某個 Unix 時間戳
rnd = [int.from_bytes(os.urandom(4), "big") for _ in range(20)]
print("lrand48 最高位爲 0 的比例：", top_bit_zero_ratio(lr)) # 恆爲 1.0
print("真隨機 最高位爲 0 的比例：", top_bit_zero_ratio(rnd)) # 約 0.5 上下波動
用官方代碼驗證最終結論
Anthropic 研究頁附帶了以 CC0 協議發佈的復現代碼。按官方說明，下面這組參數應當輸出 P-256 標準中的種子：
from datetime import datetime, timezone
def unix(when):
return int(datetime.fromisoformat(when).replace(tzinfo=timezone.utc).timestamp())
def candidate(t, n, per, shift, width):
x, out = (t << 16) | 0x330E, ""
for i in range(per * n):
x = (0x5DEECE66D * x + 0xB) % 2**48
if i >= per * (n - 1):
out += "%0*X" % (width, x >> shift)
return out
seed = candidate(unix("1997-08-16 01:52:34"), 1842, 20, 40, 2)
print(seed)
print("與標準一致：", seed == "C49D360886E704936A6678E1139D26B7819F7E90")
腳本含義是：用時間戳初始化 lrand48，每 20 次輸出組成一個 20 字節候選種子，第 1842 個候選就是標準中的種子。整個驗證在普通筆記本上一秒內就能完成。“提出假設的成本很高，驗證結論的成本很低”，是這類科研任務最理想的結構。
科研型 AI Agent 用法三：配自動評分器，迭代到分數收斂
前兩種用法依賴人來判斷結果，第三種把判斷交給程序。你寫一個評分器，模型每輪提交方案，評分器返回分數和失敗樣本，模型據此修改，直到分數不再提升。這個方法適合數據抽取規則、擬合函數形式、實驗參數搜索等有明確評價指標的任務。
操作步驟
- 先寫評分器，再找模型：評分器必須是確定性程序，不依賴模型自己打分。
- 劃分開發集與留出集：反饋只使用開發集，最後用留出集檢查是否過擬合。
- 限制提交形式：讓模型提交 JSON 或正則這類數據，避免直接執行模型生成的代碼。如果必須執行代碼，應放在沙箱中運行。
- 設置收斂條件：滿分、連續 2 輪沒有提升或達到最大輪數，三者滿足其一即停止。
- 用便宜模型調通循環，再換旗艦模型跑正式實驗。
示例：從實驗記錄抽取參數的正則迭代
import json, re
from research_client import chat, report
DEV = [
("樣品A在 350 ℃ 退火 2 小時後測得電導率 4.1 S/m。", {"temp_c": 350, "hours": 2, "cond": 4.1}),
("退火溫度 420°C，保溫 1.5 h，電導率爲 12.3 S/m。", {"temp_c": 420, "hours": 1.5, "cond": 12.3}),
("B組：300攝氏度下處理 3 小時，σ=0.85 S/m。", {"temp_c": 300, "hours": 3, "cond": 0.85}),
("在450 ℃條件下退火4h，測得電導率 20 S/m。", {"temp_c": 450, "hours": 4, "cond": 20}),
]
HOLDOUT = [
("樣品E 380 ℃ 退火 2.5 小時，電導率 7.6 S/m。", {"temp_c": 380, "hours": 2.5, "cond": 7.6}),
("C組於 500°C 保溫 0.5 h，σ = 33.1 S/m。", {"temp_c": 500, "hours": 0.5, "cond": 33.1}),
]
FIELDS = ["temp_c", "hours", "cond"]
def score(patterns, data):
hit, fails = 0, []
for idx, (text, label) in enumerate(data):
for f in FIELDS:
try:
m = re.search(patterns.get(f, "(?!)"), text)
ok = m is not None and abs(float(m.group(1)) - label[f]) < 1e-9
except (re.error, IndexError, ValueError, TypeError):
ok = False
hit += ok
if not ok:
fails.append(f"樣本{idx} 字段{f} 抽取失敗：{text}")
return hit / (len(data) * len(FIELDS)), fails
def parse_json(text):
return json.loads(text[text.find("{"): text.rfind("}") + 1])
messages = [{"role": "user", "content":
"爲下列實驗記錄寫 Python 正則，抽取 temp_c、hours、cond 三個字段，每個正則恰好一個捕獲組，捕獲純數字。"
"只輸出 JSON，例如 {\"temp_c\": \"...\", \"hours\": \"...\", \"cond\": \"...\"}，注意轉義反斜槓。\n"
+ "\n".join(t for t, _ in DEV)}]
best, stale, patterns = -1.0, 0, {}
for rnd in range(6):
reply = chat(messages, stage="draft", max_tokens=800) # 跑通後把 stage 改爲 "verify"
try:
patterns = parse_json(reply)
s, fails = score(patterns, DEV)
except (ValueError, json.JSONDecodeError):
s, fails = 0.0, ["輸出不是合法 JSON"]
print(f"第 {rnd + 1} 輪 開發集得分 {s:.2f}")
if s >= 1.0:
break
stale = stale + 1 if s <= best else 0
best = max(best, s)
if stale >= 2:
break
messages += [{"role": "assistant", "content": reply},
{"role": "user", "content": "以下抽取失敗，請修改正則後重新輸出完整 JSON：\n" + "\n".join(fails)}]
print("留出集得分：", score(patterns, HOLDOUT)[0])
report()
需要特別注意：開發集滿分而留出集明顯下降，說明模型在“背答案”。這時應該擴充開發集，而不是繼續迭代。
3 種科研 AI Agent 用法對比
| 維度 | 用法一：推演機制 | 用法二：掃描驗證腳本 | 用法三：自動評分迭代 |
|---|---|---|---|
| 對應案例環節 | 推演 1997 年程序寫法 | 34 種生成器掃描、找統計簽名 | 狀態恢復後用 10 條曲線全量校驗 |
| 適合任務 | 成因不明的異常、逆向推測 | 假設已有，需要定量檢驗 | 有明確指標的優化問題 |
| 模型職責 | 生成可證僞的候選機制 | 寫代碼，不報結果 | 反覆提交方案 |
| 人的職責 | 篩選並排序假設 | 本地運行、看對照組 | 設計評分器和留出集 |
| 旗艦模型介入點 | 最終推演與排序 | 寫複雜求解（如 LLL） | 正式實驗輪次 |
| 停止條件 | 首條驗證可在 1 小時內完成 | 與隨機對照差異顯著 | 滿分或連續 2 輪無提升 |
| 調用方式 | API易 apiyi.com 統一接口 | 同左 | 同左 |
三種用法可以串起來使用：用法一產出假設，用法二檢驗假設，用法三把驗證過的方案打磨到穩定。
爲什麼 Claude 這類科研任務必須用旗艦模型
並不是所有科研步驟都需要旗艦模型，但有一類任務換成小模型之後基本做不成。可以用下表判斷：
| 判斷標準 | 滿足時建議旗艦模型 | 原因 |
|---|---|---|
| 需要跨領域聯想 | 例如從“曲線種子”聯想到“90 年代 C 庫實現細節” | 小模型更容易停留在問題表面，比如繼續猜短語 |
| 推理鏈超過 3 步，且每步都依賴前一步 | 例如推演→掃描→簽名→狀態恢復 | 中間任何一步出錯，後面會全部偏離 |
| 需要自我質疑 | 例如懷疑“我是不是在測試環境” | 旗艦模型更可能主動尋找反例 |
| 涉及非平凡算法 | 例如 LLL 格基約減、截斷 LCG 狀態恢復 | 代碼正確率直接決定驗證是否成立 |
| 結論會進入論文或決定實驗投入 | 任何對外發布的結論 | 出錯的代價遠高於調用成本 |
反過來，格式轉換、批量摘要、調試評分器管道這類工作，用便宜模型就夠了。成本控制的核心不是少用旗艦模型，而是讓旗艦模型只出現在上表列出的位置。
常見問題 FAQ
Q1：Claude 破解了 NIST 橢圓曲線嗎？
沒有。Claude 復原的是種子的生成過程，種子來自用時間戳初始化的 lrand48。這不是新的攻擊方法，也不構成漏洞，用戶不需要修改配置或遷移。這個結論反而說明種子沒有被人爲挑選。
Q2：這個方法和傳統的暴力搜索有什麼區別？
暴力搜索是在固定的假設空間裏窮舉。Claude 先換掉了假設空間，從“哪句話被哈希”換成“用了哪種隨機數生成器”，然後才進行有限的窮舉（2^17 隱藏位）。真正決定成敗的是前一步。
Q3：這項研究是什麼時候公佈的？還有哪些沒解決？
Anthropic 研究頁和 @AnthropicAI 的帖子都發佈於 2026 年 10 月 17 日。目前 B-163 的種子還沒解出，P-224 至 P-521 的基點 G 生成方式也不清楚，另外有少量候選曲線被跳過，原因未知。
Q4：哪些科研場景適合套用這 3 種用法？
– **實驗異常溯源**：儀器數據中出現週期性僞影，用用法一推演採集軟件的實現方式。
– **復現歷史論文**：參數缺失時，用用法二掃描候選參數組合。
– **數據抽取與清洗**：用用法三加評分器，迭代出穩定的規則。
Q5：如何用一個 Key 同時調用多個旗艦模型做交叉驗證？
在 API易 apiyi.com 註冊並創建 Key，把 base_url 設爲 `https://api.apiyi.com/v1`，只需修改 `model` 參數，就能在 claude-opus-5-5 和 GPT 系、Gemini 系旗艦模型之間切換。可用模型名以控制檯列表爲準。
Q6：科研 AI Agent 有哪些已知限制？
– 模型可能編造看起來合理的機制，所以每個結論都必須有本地可運行的驗證腳本。
– 評分器迭代容易在開發集上過擬合，必須保留留出集。
– 多輪調用的成本會累積，應先用便宜模型調通流程，同時記錄 usage。計費方式在 API易 apiyi.com 控制檯可以查看。
科研型 AI Agent 核心要點 Key Takeaways
- 結論邊界：Claude 復原的是種子來源，不是密碼學漏洞，曲線可信度反而提高了。
- 關鍵一步：換掉假設空間，比在舊空間裏加大算力更有效。
- 驗證優先：模型負責寫腳本，人負責運行，一律對照隨機基線。
- 評分器閉環：確定性評分加上留出集，迭代到分數收斂就停止。
- 模型分層：便宜模型調通流程，旗艦模型只用於關鍵推演和驗證。
- 上手方式：通過 API易 apiyi.com 一個 Key 調用 claude-opus-5-5，並切換其他模型做交叉驗證。
總結
Claude 解開 NIST 橢圓曲線種子之謎，給科研人員的啓發主要有三點：
- 先推演機制：從“數據是怎麼產生的”出發，而不是直接猜答案。
- 用腳本說話：每個假設都要配可運行的驗證代碼和隨機對照。
- 評分器閉環：把判斷交給確定性程序，迭代到收斂，並用留出集檢查過擬合。
成本控制始終是前提：流程先用便宜模型跑通，涉及論文結論和複雜算法的步驟再換旗艦模型。推薦通過 API易 apiyi.com 把本文代碼完整跑一遍，先用官方復現代碼確認 P-256 種子，再把三種用法套到自己的課題上。
延伸閱讀 Related Articles
- 📘 如何用 OpenAI SDK 調用 Claude 系列模型 – 瞭解兼容接口的參數差異
- 📊 大模型 API 調用成本控制實踐 – 掌握 usage 統計與預算告警
- 🚀 多模型交叉驗證工作流搭建 – 讓不同旗艦模型互相覈對結論
📚 參考資料
- Anthropic Frontier Red Team 研究頁：ECDSA 曲線種子來源研究
- 鏈接：
www.anthropic.com/research/ecdsa-curve-origins -
說明： 一手來源，包含完整方法、遺留問題和 CC0 復現代碼
-
@AnthropicAI 官方 X 帖（2026-10-17）：“It is just timestamps.”
- 鏈接：
x.com/AnthropicAI -
說明： 官方發佈聲明，可從這裏查看社區討論
-
API易 文檔中心：OpenAI 兼容接口調用說明
- 鏈接：
docs.apiyi.com - 說明： base_url 配置、模型列表與計費說明
作者: APIYI 技術團隊
技術交流: 歡迎在評論區分享你在科研中使用 AI Agent 的做法，更多接入資料可訪問 API易 docs.apiyi.com 文檔中心
