我已经掌握了足够的资料。论文全文已阅读，维基基准也已建立（OMC wiki 中没有匹配记录；paper-wiki 中已收录 CosyVoice3、VoxCPM2、CapTalk）。现在开始撰写审稿报告。

Paper Review: Harness TTS: Towards Context-Aware Expressive Speech Synthesis with Harness Layer

论文类型: 系统型

该论文在现有 TTS 引擎（CosyVoice3、VoxCPM2）外层包装一个轻量级 “Harness” 控制层，由离线 prompt tool registry + 在线 LLM planner（Qwen3-4B）+ 优先级 observation schema 组成，将风格控制重构为闭集 tool routing。核心交付物是一个工程集成 pipeline + 路由/合成双任务评测。属于系统型论文。

公理审查结果

公理一：对象公理

• 判定: ⚠️
• 依据: 对象”上下文感知的 expressive TTS for voice assistants”是真实存在的工程需求——zero-shot TTS 依赖固定 prompt、instruct TTS 在模糊指令下不稳定，这些都是公认问题。但论文把对象从”任意风格生成”窄化为”从一个预注册、单说话人、25–42 个 prompt的闭集里选一个”，这是显著的范畴收窄。论文自己承认 “the key challenge shifts from generating arbitrary styles to reliably matching contextual requirements with available expressive resources”——即放弃开放风格空间换取稳定性。voice assistant 场景是真实的，但 “context-aware” 的外延（user profile / scenario / ambient / implicit / explicit 五层）在实验中只有 explicit 子集被充分验证；implicit 子集 43% Top-1，说明”上下文感知”能力本身很弱。问题真实但被重新定义为更易解的版本。
• Wiki 证据: OMC wiki 无 “expressive TTS style control” 相关记录；paper-wiki 收录 CosyVoice3（含 CV3-Eval benchmark）和 CapTalk（含 dialogue CoT 控制），说明该领域已被多角度研究，本文对象非新任务，但”prompt-tool routing”这一重构角度未见先例。
• 分数: 5

公理二：识别公理

• 判定: ⚠️
• 依据: 路由任务设了 keyword 和 retrieval 两类 baseline，合成任务只设 “Instruct”（指令直驱 TTS）一个对照条件。关键缺失：(1) 没有 “random prompt” 或 “default prompt” 的最简 baseline——即从 registry 随机/默认选 tool 与 Harness 对比，无法说明 planner 选择本身贡献多少；(2) 没有 oracle upper bound（直接用 teacher Gemini-2.5-Pro 的选择喂 TTS），无法判断 4B planner 距离天花板多远；(3) 合成 win rate 用 Gemini-3.1-Pro 做 judge，而 planner 训练标签和 routing teacher 都来自 Gemini 家族，judge 与 teacher 同族——存在识别污染。CoT vs no-CoT 的 ablation 存在且有效，但这是推理策略消融，不是模块必要性消融（observation schema 五层、双 annotation 结构、两类 tool 的必要性均未消融）。
• Wiki 证据: OMC wiki 无 “TTS baseline ablation” 记录；paper-wiki 中 CosyVoice3 报告了 DiffRO 后训练和多规模 scaling，是更强 backbone 对比项，本文未将其作为公平比较锚点（虽用作 executor，但未对比 CosyVoice3 自身 instruct 模式 vs Harness 时的 backbone 内部消融）。
• 分数: 4

公理三：独立性公理

• 判定: ❌
• 依据: 闭环污染严重：(1) Test data 全部由 Gemini-2.5-Pro 生成（routing 三子集各 210 样本，合成 135 样本），论文 §6 明确承认 “all test data are generated by LLMs rather than collected from real-world user logs”；(2) Routing 的 ground-truth label 也由 Gemini-2.5-Pro 作为 teacher 产生，metric 前缀 “T-“ 即 teacher-alignment，而非人类标签——学生模型 Qwen3-4B 的”准确率”本质是”与 Gemini-2.5-Pro 的一致率”，不是任务正确率；(3) 合成 win rate 的 judge 是 Gemini-3.1-Pro，与 teacher/数据生成器同族。训练目标、数据筛选、评测 label、win-rate judge 四重来自同一 Gemini 闭环，核心结论（routing 准确率 + win rate 提升）全部依赖该闭环。论文 §6 仅把此列为 limitation 而非 fatal，但按公理三这是 fatal 级循环论证。无任何独立人类标注或独立 judge 锚点。
• Wiki 证据: OMC wiki 无 judge 独立性记录；paper-wiki 中 CapTalk 明确包含 “human evaluation for single-utterance speech” 作为独立锚点，对比之下本文缺失人类评测。
• 分数: 2

公理四：压缩公理

• 判定: ⚠️
• 依据: 方法本质是三件已有事情的拼装：(a) prompt library / voice cloning registry（zero-shot TTS 标配）、(b) LLM-as-router / tool-use planning（agent 领域标准）、(c) 优先级 schema（规则系统常识）。”Harness layer” 命名借自 [21] harness engineering，是外部化 orchestration 的再包装，论文未提出新机制解释为什么这种特定闭集结构比开放指令空间更优——只给出”constrained decision space enhances stability”的常识性论证。优先级 5→1 的层级是简单规则，非学习得到。价值在于 问题重构（把开放风格生成降为闭集 routing），这是合理的工程压缩，但缺少理论或经验压缩（无 scaling law、无 trade-off 曲线、无可迁移失败模式）。42 个 tool 的 registry 规模选择无任何依据。
• Wiki 证据: OMC wiki 无 “harness engineering” 或 “tool routing” 记录；paper-wiki 未收录 [21] arXiv:2604.08224，无法确认 harness engineering 概念是否本文首次迁移到 TTS。
• 分数: 5

公理五：效用公理

• 判定: ⚠️
• 依据: 绝对值：routing Top-1 在 explicit 74.3% 尚可，implicit 43.0% 不可用（每 5 次选错 3 次），conflict 64.6% 勉强。合成：win rate margin 23.1–35.6pp（CosyVoice3）和 13.8–20.0pp（VoxCPM2）看起来显著，但 win rate 是相对指标，未报告绝对 Inst-following 准确率，无法判断 Harness 是否达到可用水平还是仅仅”比一个弱的 Instruct baseline 好”。UTMOSv2 提升 0.11–0.38 在 MOS 5 分制下属于小到中等。Speaker stability 在 CosyVoice3 scenario 子集 actually 输给 Instruct（90.4 vs 92.9），作者用”Instruct 指令遵循差所以 stability 虚高”来解释，这是事后合理化而非实验隔离。Latency：4B no-CoT P95 First-ID 41.2ms 确实满足实时。但所有效用结论建立在 Gemini 闭环评测上（见公理三），效力打折。baseline 覆盖不足：未对比 CapTalk、FCTalker、M²-CTTS 等直接相关 context-aware TTS 工作。
• Wiki 证据: OMC wiki 无 TTS SOTA 记录；paper-wiki 收录 CapTalk（context-aware 对话 TTS，含 CoT 规划）作为直接竞争方法未被对比；CosyVoice3 的 CV3-Eval benchmark 未被采用作为独立评测。
• 分数: 5

公理六：新颖性公理

• 判定: ⚠️
• 依据: 核心新意 = “把 TTS 风格选择重构为闭集 tool routing + LLM planner + 优先级 observation schema”。各组件单独看均非新：(1) prompt library selection：zero-shot TTS 领域常见；(2) LLM-as-planner for tool routing：agent/ tool-use 领域成熟（ReAct、Toolformer 等）；(3) 优先级冲突解决：规则系统常识。组合后的”prompt-tool routing for TTS”这一具体 instantiation 未见先例（paper-wiki 中 CapTalk 用 CoT 但仍是开放 caption 生成，非闭集 routing），属跨范式迁移而非本领域换名。但论文未证明该迁移解决了本领域真实痛点 vs 现有 instruct TTS——只显示比弱 Instruct baseline win rate 高，未对比 CapTalk 等更强同类。无新机制解释、无问题重构的理论分析。
• Wiki 证据: OMC wiki 无 “prompt tool routing” 记录；paper-wiki 中 CapTalk（CoT-based dialogue TTS, 2026）是最近的同类 context-aware 方法，时间在本文 2 个月内可视为 concurrent，不扣分，但其存在说明”LLM 规划 + TTS”并非本文独创。
• 分数: 5

公理七：可复现公理

• 判定: ⚠️
• 依据: 论文未提供代码/数据/checkpoint 链接。Tool registry（25–42 个 prompt audio + metadata）未公开。Routing 测试集由 Gemini-2.5-Pro 生成，模板”manually designed”但未公开模板。TTS executor 用 CosyVoice3 / VoxCPM2（均有 arXiv 报告但 VoxCPM2 checkpoint 开源状态不明）。Planner 用 Qwen3-4B（开源）。Judge 用 Gemini-3.1-Pro（闭源）。核心 win-rate 结论依赖闭源 Gemini judge，无独立人类锚点，复现成本高且结论可信度受限。Latency 测量硬件（RTX 5090 + vLLM）明确。
• Wiki 证据: OMC wiki 无复现性记录；paper-wiki 显示 CosyVoice3 有 arXiv 报告但未标注代码开源状态。
• 分数: 4

总评

• 科学价值: 低 — 核心结论建立在 Gemini 数据生成 + Gemini teacher label + Gemini judge 的三重闭环上，无独立人类校验，认识论效力不足。
• 方法价值: 中 — prompt-tool routing 作为 TTS 风格控制的工程重构是合理且可部署的，latency 数据支撑实时可用性，但缺最简 baseline 和 oracle 上界，无法精确归因贡献。
• 社区价值: 中 — 提出可审计、可调试的闭集控制范式对生产级 voice assistant 有实践意义；但评测闭环问题使其难以作为社区证据基础设施。

日报摘要

• Strength: 将 TTS 风格控制重构为闭集 prompt-tool routing，4B planner 在 explicit 子集达 74.3% Top-1 且 P95 First-ID 仅 41.2ms，在 CosyVoice3 上 instruction-following win rate 领先 Instruct 基线 23.1–35.6 个百分点，工程可部署性清晰。
• Weakness: 测试数据、routing ground-truth label、合成 win-rate judge 三者全部来自 Gemini 闭环且无独立人类校验，implicit 子集 Top-1 仅 43.0% 表明上下文感知能力本身薄弱，同时缺 random/oracle baseline 及对 CapTalk 等直接同类的对比，核心结论的认识论效力不足。

打分

加权总分: 4.53/10（加权分之和 42.0 / 权重之和 9.5） 最终建议: Weak Reject 3.5–5