科研 Agent 容易出问题的时刻，常发生在假设太顺的时候：claim 写得干净，检索结果有几篇支持论文，报告语气平滑，引用也齐全。页面刷新后，反例文献、负结果、降权理由，全留在临时上下文里。
用户问“这个方向能不能做”，系统回答“可以”，再附几条引用。读起来顺，复盘时却很难用。科研判断关心一条假设碰到反证后的命运：改写、搁置、降权，还是退出候选池。
Google Research 在 AI co-scientist 相关系统报告里，把科研协作拆成假设生成、反思评审、排序、演化和辩论等角色；AutoResearchBench 这类评测继续追问假设质量、证据一致性、可复核性、专家偏好、排序解释。对开发者来说，Research Agent 的输出不能只是一份报告，还要能回放判断过程。
图1：字段流转图。左侧是 Hypothesis Generator 生成多个 hypothesis_id；中间是 Evidence Retriever 分别发起 support query、challenge query、method query；右侧是 Skeptic Agent 写入 challenge_papers、reason、rank_delta；底部统一落到 Decision Log。
漂亮假设为什么会活太久
很多 Research Agent 的默认路径是“检索相关论文，然后总结共识”。相关论文天然偏向叙事。模型抓住几篇能解释问题的文章，排出一条连贯论证；反例被压缩成“仍存在争议”，负结果变成“需要进一步研究”，被淘汰假设直接消失。
工程上常见的坑很具体：假设写在段落里，证据写在引用列表里，排序写在最终回答里。三者分散以后，审计只能靠人工倒推。第 7 个假设为什么从第 2 名掉到第 5 名？哪篇 challenge paper 触发了降权？模型自己也说不清。
可以把假设当成一级对象保存。每个 hypothesis_id 至少绑定 claim、support_papers、challenge_papers、uncertain_papers、reviewer_role、rank_delta、drop_reason 和 source_id。多 Agent 辩论如果只保存赢家发言，很快会退化成提示词表演。
decision log 要能回放一次失败
下面是一个最小实现片段。字段值是模拟 schema，不代表真实检索结果，也不应伪装成真实论文引用。
{
"hypothesis_id": "H-2026-001",
"claim": "Adversarial evidence retrieval improves RAG evaluation",
"status": "dropped",
"queries": {
"support": "RAG evaluation adversarial retrieval benchmark",
"challenge": "negative results adversarial retrieval RAG",
"method": "RAG evaluation metric validity limitation"
},
"support_papers": [{
"source_id": "OpenAlex:W000000001",
"doi": "10.0000/demo.support",
"evidence_strength": "medium"
}],
"challenge_papers": [{
"source_id": "DOI:10.0000/demo.challenge",
"doi": "10.0000/demo.challenge",
"reason": "benchmark setting not comparable",
"evidence_strength": "high"
}],
"reviewer_role": "skeptic_agent",
"rank_before": 2,
"rank_after": 5,
"rank_delta": -3,
"drop_reason": "target task lacks direct evaluation evidence"
}
DOI、PMID、OpenAlex ID 很容易被低估。自然语言引用看起来够用，复核时经常出错：标题会改，预印本会更新，同名论文会混淆。医学研究还会牵涉指南、临床试验注册、药物安全数据库和人群差异。ID 字段进入日志后，才方便做去重、版本追踪和人工抽查。医疗 AI 场景里，模型只能承担证据入口、文献追踪、研究审计，不能包装成诊断或治疗建议。
Skeptic Agent 的流程可以很朴素：先找反证，再查方法学弱点，最后标记证据缺口。反证包括负结果、外部数据集失败、适用人群差异、基线不公平、统计功效不足；方法学弱点包括样本量、随机化、盲法、评估指标、数据泄漏、对照组选择；证据缺口要回答“还缺哪类论文，才配继续讨论这个假设”。
challenge query 也不能随便写。只用 “criticism of X” 会召回大量观点文和综述噪声。更可控的做法是把 claim 拆成任务、数据、指标、人群、干预方式，再分别拼接 negative result、failed replication、external validation、baseline comparison 等限定词。召回阶段宁愿保留 uncertain_papers，也别急着让模型裁决。
在证据召回节点，可以用 PubMed、OpenAlex、通用学术搜索，也可以把 超能文献 放进流程：用中文自然语言围绕同一个假设分别检索支持文献和反驳文献，并保留来源可追溯的候选文献池。召回结果仍需人工核验，它的位置是文献入口和初步组织。
图2：decision log schema 图。按 hypothesis_id 聚合 claim、queries、support_papers、challenge_papers、uncertain_papers、rank_before、rank_after、drop_reason，并突出 DOI / PMID / OpenAlex ID。
把反对票做成产品对象
前端别只给用户一个最终答案。可以做成假设卡片：左侧是 claim 和当前排名，中间分 support、challenge、uncertain 三列，右侧显示 rank timeline。每次 Skeptic Agent 加入一条 challenge paper，都触发一次状态变更：pending_review、revised、dropped、kept_with_risk。
举个模拟审计。用户问：“多 Agent 辩论能否提高科研假设质量？”系统拆出 H-001：多 Agent 辩论提升假设质量；H-002：文献证据合成降低遗漏率；H-003：自动生成假设在专家评审中优于人工基线。每个假设都生成 support query、challenge query、method query，并要求返回 ID、研究类型、任务设置、纳入状态和反驳理由。
H-001 初始排名第 2，因为几篇论文支持多 Agent 能产生更多候选假设。随后 Skeptic Agent 找到一篇评估论文，指出实验只比较“想法数量”，没有比较专家盲评下的创新性、可验证性和实验成本。Ranking Agent 不能只写“证据不足”，要记录 rank_delta: -3，并写清 drop_reason: evaluation metric measures quantity, not hypothesis quality。
| 字段 | 只输出最终报告 | 保存反对票日志 |
|---|---|---|
| 文献引用 | 自然语言引用 | DOI / PMID / OpenAlex ID |
| 反例处理 | “存在争议” | challenge_papers + reason |
| 排序变化 | 看不到 | rank_before / rank_after / rank_delta |
| 淘汰理由 | 证据不足 | 可复核 drop_reason |
| 人工复查 | 从报告倒推 | 按 hypothesis_id 回放 |
回到开头那个矛盾：Agent 没少写字，也没少引用论文，问题发生在证据检索之后、结论生成之前。challenge_papers 没有固化成字段，被降权的瞬间没有写入日志，一个漂亮假设就会在报告里一路顺行。用户拿到“可以做”的结论，却看不到它曾经输给哪些证据。
下一步可以很小：先做 50 条审计样本，每条包含一个模糊研究问题、3 个 hypothesis_id、支持文献、反驳文献、排序变化和排除理由。让系统每次生成报告前导出 decision log；再请领域用户抽查 DOI、reason 和 rank_delta 是否经得起复核。先别急着加 Agent，先让日志能被审计。
