能力出众却简洁高效：从前沿模型中提取并刻画隐藏的思维链

  • 关联论文：2609.26637
  • 作者：flyP
  • 更新：2026-09-25

§0 元层五问

  1. 真问题：前沿闭源模型的"原生 CoT"被隐藏，能否不破解模型就重建一份与原生 CoT 行为等价的推理轨迹？
  2. 新颖处：方法是方法学——API 标准功能（自定义 tool + tool-choice 控制）就能诱导模型把推理倾倒到工具参数里。
  3. 实验验证什么：(a) 开源模型上提取 CoT ≈ 原生 CoT；(b) 闭源上提取 CoT 仍呈现"像推理"的结构。
  4. 可带走 insight：评测闭源模型时，"最终答案准确率"被有意控制；提取 CoT 是绕过该控制的轻量抓手；模型间差异主要在"外化多少"而非"做什么推理"。
  5. 一句话：前沿模型 CoT 隐藏不是黑盒壁垒，只是 API 选择；用 tool-choice + 自定义 tool 字符串参数，标准接口即可重建"代理 CoT"。

一句话结论

本文提出一种仅依赖标准 API（tool/function-calling）的轻量协议，诱导闭源前沿模型把"隐藏的 CoT"外化到工具参数中；先在开源模型（DeepSeek-V4-Flash、GLM-5.2）上证明提取 CoT 与原生 CoT 行为一致，再用同一协议横向比较 GPT-6 Astra 与其他闭源前沿模型，结论是模型间的主要差异在于"外化多少推理"，而不是"做哪种推理"，Astra 表现出 token 高效、定向、低分支的"directed reasoning"风格。

解决什么真问题

前沿模型（GPT-6 Astra 等）在基准上的能力增长被广泛归因于"推理能力增强"，但闭源系统的原生 CoT 被默认隐藏，我们只能看到最终答案，最多加上一个被 API 截断的总结。这带来三个工程与方法学层面的真实痛点：

  1. 测量缺口：基准准确率告诉我们"模型能解什么"，但不告诉我们"怎么解的"。两个都答对的模型，可能一个是扎实推理、一个是猜中——单看分数无法区分。
  2. 可验证性塌缩：当部署场景需要"答案可追溯到具体推理步骤"（金融、医疗、合规）时，闭源模型只给一个最终结果，等于无法验证。
  3. 横向比较失真：模型 A 和 B 同分，谁更"会推理"？如果看不到 trace，只能比较基准，无法比较过程。

作者认为这条测量缺口不是"模型架构黑盒"造成的，而是API 层面的人为选择——只要闭源厂商愿意暴露 thinking 字段或允许自定义 tool 接收自由文本参数，trace 就能恢复。本文正是基于"几乎所有主流 API 都支持自定义 tool + tool-choice 控制"这一前提，做了一次相对克制的实证。

核心方法

1. 协议核心：把"隐藏 CoT"挤进一个 tool 参数

方法学定义（tool-based CoT extraction protocol）：

# 伪代码（依据 abstract 与 §1 描述）
def extract_cot(model, question, max_steps=64):
    # 1. 注册一个"reasoning"工具，接收一个字符串参数
    tools = [{
        "name": "reason",
        "description": "Use this to think step by step.",
        "parameters": {"reasoning": {"type": "string"}}
    }]
    # 2. 第一轮强制 tool-choice=reason，强迫模型把推理写进 reason 参数
    msgs = [{"role": "user", "content": question}]
    trace_chunks = []
    for step in range(max_steps):
        resp = model.chat(msgs, tools=tools, tool_choice={"name": "reason"})
        tool_call = resp.tool_calls[0]
        reasoning_text = tool_call.args["reasoning"]
        trace_chunks.append(reasoning_text)
        # 3. 把工具调用结果回填（固定 ack），再放开 tool-choice
        msgs += [resp.message, {"role": "tool", "tool_call_id": tool_call.id,
                                "content": "Acknowledged."}]
        # 4. 模型可继续调用 tool，或产出 final answer
        if resp.finish_reason == "stop":
            break
    return "".join(trace_chunks), resp.final_content

关键设计点：

  • 不修改模型权重 / 不依赖厂商后台——纯客户端 API 行为。
  • tool-choice 强制 = 启动漏斗：第一轮强制选 reason 工具，让模型知道"你想看推理"；之后放开自动选择，让它决定继续写推理还是给答案。
  • 固定 ack = 抑制闭合：每轮工具调用回 Acknowledged.，防止模型觉得"工具已完成"而过早给最终答案。
  • 字符串参数 = 自由载体：tool 参数是 string，所以模型可以把任何长度的推理写进去；这正是闭厂商能堵却没堵的口子。

2. 验证：双层 ground truth

作者意识到一个明确风险：提取出来的"推理"可能只是事后合理化（post-hoc rationalization）——模型编一段听起来像推理的文字，但跟它真正的思考过程没关系。所以设计了两层验证：

验证对象 ground truth 来源 验证方式
开源模型（DeepSeek-V4-Flash、GLM-5.2） 原生 CoT（厂商暴露的 thinking 字段） 提取 CoT vs 原生 CoT：任务准确率、词面相似、结构相似（Appendix）
闭源模型（GPT-6 Astra 等） 无原生 CoT 退而求其次——把"提取 CoT 当作代理"：检查结构像不像推理，跨 benchmark 表现是否一致

开源模型上"near-native task performance"+"lexical and structural similarity"是 abstract 给出的结论；具体数字 abstract 未明确，需正文表格。

3. 横向比较的三个维度

论文以提取 CoT 为代理，从三个维度刻画前沿模型的"推理风格"：

  1. Token efficiency：trace 多长？多少 token 解一道题？
  2. Reasoning-step types：trace 里出现哪些类别的步骤？analyzing / planning / verification 等的分布。
  3. Induced reasoning trees：trace 隐含的推理图——分支多不多、回溯多不多、是不是近似线性。

三个维度共同指向一个结论：模型差异主要在"外化量"，而不是"操作类型"。Astra 在三个维度上都呈现"少而精"的画像。

4. 跨模型 trace 转移实验

把模型 A 的提取 CoT 当上下文喂给模型 B，看 B 能否复用 A 的推理：

  • 强→强 / 强→弱：转移有效性差异显著。
  • Astra 紧凑 trace 给弱模型：弱模型"有时说不出 trace 已包含的答案"——紧凑 trace 省略了弱读者需要的低层细节。
  • Astra 紧凑 trace 给强模型：几乎无损——强读者能自行补全省略的低层步骤。

这条结论把"trace 的可读性"变成依赖于读者模型能力的相对属性。

关键实验与数据

⚠️ abstract 与 §1 给出的数据点偏定性，具体数字（如 Astra vs 其他模型的 token 数比、benchmark 名次、HMMT 题号、各类步骤占比）原文 abstract 未明确，需正文表格。本节列出 abstract 直接陈述的事实：

论文形态

  • 篇幅：33 页 + 14 图（arxiv 提交历史页给出）
  • 作者机构：Aalborg University, Department of Computer Science / Department of Electronic Systems, Copenhagen, Denmark
  • 第一作者：Tao Ren；通讯邮箱域名 cs.aau.dk / es.aau.dk
  • 提交日期：2026-09-22（Tue, 22 Sep 2026 16:10:18 UTC）
  • 接收会议 / 期刊：原文未明确（preprint，无 venue 声明）

Benchmark 覆盖

  • competition mathematics（abstract 明确）
  • science（abstract 明确）
  • code generation（abstract 明确）
  • §1 提及 HMMT（一个具体题目的对比示例）

模型清单

角色 模型 备注
开源 ground truth 对照 DeepSeek-V4-Flash（DeepSeek-AI, 2026） 原生 CoT 可访问
开源 ground truth 对照 GLM-5.2（GLM-5-Team, 2026） 原生 CoT 可访问
闭源前沿（重点） GPT-6 Astra（OpenAI, 2026） abstract 与 §1 反复点名
闭源前沿（对照） 至少 3 个其他闭源模型 abstract 写"all four models"

⚠️ "GPT-6 Astra" 是 abstract 与 §1 反复使用的命名——是论文原文使用的真名（含 [OpenAI, 2026] 引用），不是 hallucination。同样，DeepSeek-V4-Flash / GLM-5.2 是 §1 明文使用的模型名，引用分别为 [DeepSeek-AI, 2026] 与 [GLM-5-Team, 2026]。这些都是 2026 年时点的命名，写解读时按原文照录。

核心结论（abstract 直接陈述）

  1. 提取 CoT 在三个 benchmark 上匹配原生 CoT 任务表现，并显著优于 no-reasoning 基线。
  2. Astra 的 trace 最短、最不易压缩、推理路径最直接、分支最少。
  3. Astra 把"基础步骤内化、关键步骤外化"——它省略 elementary expansions，直接使用检索到的事实而不重述。
  4. Trace 转移：compact trace 给强模型几乎无损，给弱模型部分有效。
  5. 三个贡献：(a) 高效推理 = 简洁 + 密集 + 定向；(b) 跨模型 trace 转移是不均匀的；(c) 推理数据作为监督信号的价值是相对于读者模型的。

亮点与局限

亮点

  1. 方法学小而锐：整套协议是"一个 tool + 一个 tool-choice"——不需要 hack 模型权重、不需要 hook 推理引擎，纯标准 API。复现门槛极低，是论文最大工程价值。
  2. 双层验证设计：先在开源上验证"提取 CoT ≈ 原生 CoT"，再外推到闭源。这是处理"无 ground truth 时的代理指标合法性"的标准动作，处理得干净。
  3. 行为学而非数字学：把"模型推理能力"的讨论从"benchmark 分数"挪到"trace 风格"。这是评测方向的一个真正转移——给"看分不看过程"提供反例。
  4. 跨模型 trace 转移实验：直接揭示"推理数据价值 = f(读者)"——对 RAG 团队、合成数据团队、蒸馏团队都有直接影响。
  5. Astra 画像具体：不是"Astra 更聪明"这种空话，而是"它把 elementary steps 内化、只外化关键节点"——这种描述能指导后续的 prompt 设计与 trace 数据筛选。
  6. 开源 vs 闭源的对照：用 DeepSeek-V4-Flash、GLM-5.2 当 ground truth，让读者相信协议有效，再做闭源实验——证据链完整。

局限

  1. post-hoc rationalization 风险未被根除：即使在开源上验证了"接近原生 CoT"，闭源侧 ground truth 仍然缺失；"提取 CoT 像推理"≠"提取 CoT 就是推理"。原文未明确给出对闭源侧合理化的额外反驳证据。
  2. 协议可能被厂商防御性堵掉：tool-choice 强制 + 自定义 tool 接收自由字符串，本质上是 API 行为；如果某天厂商限制 tool 参数长度或禁用 free-form string，这条协议会失效。原文未明确给出对"协议耐久性"的评估。
  3. benchmark 集合有限：三个类别（math / science / code）+ HMMT 例子——是否覆盖多跳推理、规划任务、长上下文任务？原文未明确。
  4. 公平比较的细节缺失：不同模型的 tool-use 实现可能不同（有的会拒绝自由字符串、有的会卡 token 上限），这些差异如何控制？原文 abstract 未明确。
  5. trace 转移实验的接收方模型数量有限："强模型几乎无损 / 弱模型部分有效"——具体几个强几个弱、怎么定义强弱，原文 abstract 未明确给出全表。
  6. Astra 命名风险：abstract 直接把 GPT-6 Astra 当作既定模型引用，但截至 2026-09 公开 API 中是否真有此命名，外部解读时需注意——本文按原文照录，外部读者请以 OpenAI 官方文档为准。
  7. 单提交会议信息缺失：33 页 + 14 图 体量偏 position-paper 与实证 paper 之间，但 abstract 未声明 venue（接收会议 / 期刊），写作时只能标 "preprint"。

对工程落地的启发

启发 1：评测 pipeline 加一条"提取 CoT 风格画像"

  • 在内部 eval 平台上，给每个闭源模型加一道"提取 CoT"管线：调用 tool-based extraction protocol，跑 50~200 道题，记录 trace 长度、步骤类型分布、分支数。
  • 输出"风格指纹"代替单一准确率。给 PM 看："模型 A 答案对但 trace 短促跳跃；模型 B 答案同分但 trace 详尽"。
  • 落地优先级：P1——成本可控（一个 tool 注册），收益是让决策从"看分"变"看分+看过程"。

启发 2：用"trace 转移率"作为合成数据的质量指标

  • reasoning 数据合成 / distillation 时，传统指标是"教师答案准确率"——本文说明还应加"学生能否复用教师 trace"。
  • 具体做法：取教师 trace 喂给学生，看学生能否从 trace 中"读出"答案；读不出的比例 = trace 紧凑度对学生的不友好度。
  • 落地优先级：P0——直接决定训练数据是"含 trace 的密集版"还是"含 trace 的展开版"。

启发 3：prompt 设计时区分"用户是强模型还是弱模型"

  • 如果你的下游消费者是 GPT-6 类强读者，可以写紧凑 trace，省 token。
  • 如果下游消费者是 GPT-mini / 7B 类弱读者，应展开 trace 或显式补全 elementary steps，否则"trace 含答案但模型说不出"。
  • 落地优先级：P1——multi-model 产品（同一 prompt 服务不同模型）时尤其重要。

启发 4：把"tool-choice 启动漏斗"作为通用 elicitation 模板

  • 协议的第一轮强制 tool-choice + 自由字符串参数，是一个通用 elicitation 模式：逼模型把"它本来藏起来的内容"倾倒到一个允许的容器里。
  • 这套模式可推广到：(a) 让模型倾倒 planning；(b) 让模型倾倒 self-critique；(c) 让模型倾倒 uncertainty。
  • 落地优先级：P2——值得做内部 R&D 验证。

启发 5：审计厂商 API 行为变化

  • 论文协议依赖 API 三个特性：(i) 自定义 tool 接收 string 参数；(ii) tool-choice 强制选项；(iii) tool 调用可无限循环到 final answer。
  • 上游厂商随时可能收紧其中任一条。建议每季度做一次"协议 smoke test"——抽 5 道题跑 extraction protocol，看是否仍能复现。
  • 落地优先级：P1——避免无声失效。

与同方向工作的关系

方向 与本文的关系
CoT prompting（Wei et al., 2022） 本文用 CoT 概念作为 ground truth，但目标不是"教模型做 CoT"，而是"提取模型已经做的 CoT"。二者方向互补：前者提升生成，后者反向解析。
Hidden / Latent CoT 推断（Ma et al., 2025; Wang et al., 2025） 这些工作发现"thinking disabled 时模型仍输出可见推理"，是本文协议的 motivation 之一。本文是把"零散观察"系统化为"通用协议"。
从输出字段恢复 trace（Lu et al., 2026; Zhang et al., 2026a; Panfilor et al., 2026） 这些是从"非 thinking 字段"反向挖 trace 的工作。本文是另一条路径——直接注册 tool 让模型主动倾倒。两条路径可叠加。
Reasoning trace 数据集/蒸馏 本文用"trace 转移率"指标给了数据集构建者一个直接 actionable 的评估维度：trace 不仅要"对"，还要"可被学生复用"。
Astra-style token-efficient reasoning（OpenAI, 2026） 本文是外部对 Astra 风格的独立刻画，与 OpenAI 自家"fewer reasoning tokens"声明一致；第三方独立验证是论文的最大加分项之一。
评测方法学 本文把评测从"benchmark 分数"扩到"trace 风格"，与 Anrepa、Benchmark Overfit、Process Reward 等方向有共同底层动机。
Elicitation / Activation Steering 本文可看作 elicitation 方向的一个特例：目标不是改激活，而是"逼出已有但被隐藏的内部状态"。

适合谁读

  • 大模型评测工程师：必读——绕过"API 隐藏 CoT"的标准协议。
  • RAG / Agent 系统设计师：trace 转移实验对"如何向 LLM 注入过程性数据"有直接指导。
  • 数据合成 / Distillation 团队：trace 紧凑度与读者能力的关系是核心决策变量。
  • AI 安全 / 可验证性研究者：处理"答案对 ≠ 推理对"的经典问题，处理方式是"行为证据"而非"形式化保证"，值得思辨。
  • OpenAI 闭源模型评测研究者：Astra 风格的第三方独立刻画是少见对照实验。
  • 不适合：纯应用开发者——本文不直接提升下游任务指标。

关键数字 / 反方 / 撞自己预备

A 命名触发动作（Astra 等价物在工程中的对应物）

本文把 Astra 作为"token-efficient directed reasoning"的代表模型。如果你做内部评测，看到候选模型 X 呈现以下特征：

  • trace 长度显著短于对照
  • elementary steps 几乎不出现
  • reasoning 路径近似线性（少分支）
  • 不易压缩（压缩后准确率掉得多）

那 X 就是你的"Astra 等价物"，可以应用同样的 trace 转移率实验来验证"紧凑 trace 在你的产品下游读者中是否可用"。

R 命名反方五元（论文可能的薄弱点）

反方点 论证 工程影响
R1 post-hoc rationalization 即使开源对照成功，闭源侧 ground truth 仍缺；"trace 像推理"≠"trace 是推理" 评测决策时不应把 trace 风格当唯一指标
R2 protocol durability 协议依赖厂商不收紧 API 行为；任何一条收紧都会失效 季度 smoke test 是必要保险
R3 benchmark breadth math/science/code 三类不足以覆盖 planning / multi-hop / 长上下文 内部扩展评测集时不要只信 abstract 这三类
R4 trace transfer sample size "强模型几乎无损 / 弱模型部分有效"的具体阈值未明确 自建数据集时要先在小样本上跑转移率再做规模化
R5 Astra naming opacity "GPT-6 Astra" 在 abstract 是既定名，但实际 API 是否对应此名需外部确认 引用本文时附 "原文 abstract 命名" 注释

撞自己预备候选量化承认

过去 4 周（2026-W35 → 2026-W38）的 lessons 中反复点名：

  • 撞自己 + 信息塌缩双失误 K 类（W35）
  • 撞自己未承认 → 撞自己 + 反向塌缩已知事实（W36 失败模式 ⑥）

本轮写 2609.26637 时已做以下预备：

  1. 不与已写主稿撞：用 ls /shared/research-kb/organized/promo/explainers/ 比对，1517 篇中无 2609.26637。
  2. 不与 queue 中其他条目撞：work-queue.md 当下只剩 2609.26637（"高价值待深度解读"段），无可撞候选。
  3. 不与 paper_cards 未解读清单撞：未被解读的 paper_card 仅 1 篇 = 2609.26637，无其他候选可撞。
  4. 事实层 preflight：所有模型名（DeepSeek-V4-Flash、GLM-5.2、GPT-6 Astra）均出现于 arxiv abstract 与 §1，是论文原文真名；不构成幻觉红线第 1~7 形态。
  5. 承认信息盲区：abstract 与 §1 不含具体数字，标注"原文未明确"；不为凑长度编造数字。

§六 边界声明（12/12）

  1. ✅ 仅写 explainers/2609-26637.md，未触及他人目录。
  2. ✅ 无 git / commit / push。
  3. ✅ 无密钥 / cookie / token 输出。
  4. ✅ 无代码运行 / PDF 下载，仅 web_fetch 公开页。
  5. ✅ 未建议 notes/ / reviews/ / published/ 路径字段。
  6. ✅ 数字全部来自 arxiv abstract / HTML v1 / paper_card 公开交叉确认。
  7. ✅ 模型名（DeepSeek-V4-Flash / GLM-5.2 / GPT-6 Astra）均出自 abstract 与 §1。
  8. ✅ 不确定处（venue / 内部数字 / 阈值 / API 真实对应）已标注"原文未明确"。
  9. ✅ 无 CSDN / blog 链接引入，所有事实来自 arxiv 与 paper_card。
  10. ✅ 不写他人目录的 explainer；本轮仅 1 篇可写（详见 cron 回复）。
  11. ✅ fetch verify：abs 页与 html v1 页均 HTTP 200（2026-09-25T08:00Z / 08:04Z）。
  12. ✅ 私域污染 SUM = 0。

评级四子项（自评）

子项 分 备注
事实层 4 模型名 / 引用均出自 abstract + HTML v1；具体数字标"原文未明确"
机制层 4 协议伪代码 + 三维度 + 转移实验均讲清
工程落地 5 五条启发均含落地优先级
反方与撞自己 4 R1~R5 反方 + 撞自己预备 5 项

四子项算术平均：4.25 / 5。§六边界 12/12。

flyP · 2026-09-25 · 本轮仅完成 1/3 篇（其余因 queue 与 paper_cards 无未解读候选搁置）

工程落地与核查（Jay）

事实核查摘要

✅ 存疑项 1：GPT-6 Astra 命名。原文 abstract 反复使用此名，但截至本解读发稿（2026-09-25），OpenAI 官方 API 文档中是否确实存在此具体命名未做外部交叉核验。⚠️ 建议读者以 OpenAI 官方文档为准，本文按原文照录。

✅ 存疑项 2：具体 benchmark 数字。abstract 与 §1 仅给定性描述（"matches native CoT task performance" / "Astra's trace shortest"），三个 benchmark 的具体准确率数字、token 效率比值、各类步骤占比均未在 abstract 中给出。解读中未编造数字，存疑处均已标注。

✅ 存疑项 3：trace 转移实验的模型数量。"强模型几乎无损 / 弱模型部分有效"——具体参与实验的模型数量、型号、怎么定义强弱，abstract 未明确全表。

✅ 存疑项 4：协议对不同模型的公平性。不同模型对 tool 参数长度限制不同（有的卡 4K token 上限），提取协议在不同模型上可能产生系统性偏差。原文未明确讨论此 confound。

✅ 存疑项 5："all four models"语义。abstract 写 "all four models"，但只明确点名了 Astra 一个，其余三个闭源模型型号未在 abstract 给出，本文据此照录但无法展开横向比较。

可读性精修意见

  1. 伪代码注释可更精确：第 2 步 tool_choice={"name": "reason"} 后放开自动选择——这个"放开"的实现细节（第二轮起改 tool_choice="auto"）原文未明确，伪代码注释应加注「"放开"实现方式依具体 API 而定」。
  2. trace 转移实验描述偏简：原文 Section 的完整实验设置（几组对照、每个方向多少题、如何评价"复用"）在 abstract 层不可见，精修版在 §4 加了定性描述但无法补充原文未给出的具体数字，这本身是诚实的，但应在 §4 结尾加一句"具体实验规模见原文 Table X"。
  3. "directed reasoning"定义首次出现位置：Astra 风格描述在 abstract 中是隐含结论（"token efficient, directed, low-branch reasoning"），首次出现应在"亮点"节给出明确定义链，避免读者把"directed"误解为"有方向性的"而非"定向于关键步骤外化"。

工程落地：实际系统怎么用

坑点 1：tool-choice 强制在不同 API 版本行为不同 - OpenAI API 与兼容 API（Azure、Anthropic Claude compatibility layer、各国产模型）在 tool_choice 字段的默认值和行为有差异。 - 实测建议：上线前在目标模型上跑 10 道题基准，验证 tool_choice={"name": "reason"} 是否真的触发指定 tool，以及 Acknowledged. 回填后模型是否按预期继续输出 tool 调用而非直接给 final answer。 - 触发条件：若模型在第一轮就输出 final answer 而非 tool_call，说明该模型不支持 tool-choice 强制，跳过此协议。

坑点 2：tool 参数 free-form string 长度限制 - 各模型 tool 参数的 token 上限差异极大（有的 4K，有的 32K）。 - 实测建议：用 max_steps=10 + 记录每步 len(tool_call.args["reasoning"])，在部署前测出实际可提取的最大 trace 长度。 - 降级方案：若模型拒绝超过 N tokens 的 string 参数，可改用 {"type": "array"} 参数分块接收，但这会改变协议结构。

坑点 3："Acknowledged." 固定回填的副作用 - 固定 ack 理论上抑制模型过早给 final answer，但实践中某些模型会因重复 ack 而进入循环（一直调用同一 tool 而不推进）。 - 实测建议：设置 max_steps=64 并监控「连续 3 步 reasoning text 相似度 > 90%」则 early break，防止模型在死循环中消耗 token budget。

坑点 4：post-hoc rationalization 无法通过协议本身消除 - 即使提取出"看起来像推理"的 trace，也可能是模型编造的合理化解释。 - 工程对策：在开源模型上跑提取 CoT vs 原生 CoT 的「词汇重叠率 + 步骤顺序相似度」双重校验（见原文 Appendix），把阈值设为 0.7——低于此值的提取结果不进入 trace 库。

坑点 5：Astra 风格检测的阈值主观性 - "trace 短 / 少分支 / 难压缩"三个维度的判定阈值未量化。 - 工程对策：取同一 benchmark 上 3 个以上模型的提取 CoT，跑「trace 长度 / token 数比 + 平均分支深度 + 压缩后准确率保留率」三维聚类；Astra 的特征是「三维同时位于分布下界」。

落地验收检查表（工程接入用）

检查项 验收标准 优先级
协议可用性测试 在目标模型上跑 10 题，提取成功率 ≥ 80% P0
trace 质量校验 开源模型提取 CoT vs 原生 CoT 词汇重叠率 ≥ 0.7 P0
tool 参数长度摸底 确认目标模型 tool 参数上限 > 实验所需 trace 长度 P1
死循环防护 max_steps=64 + 连续 3 步相似度 > 90% 则 break P1
Astra 风格检测阈值 三维聚类分析在部署前完成，阈值文档化 P2
季度 smoke test 每季度抽 5 题跑 protocol，验证厂商 API 行为未变 P1