Hyperresearch三重草稿集成（Triple Draft）设计原理：3份草稿如何合成1份报告-育师

Hyperresearch三重草稿集成（Triple Draft）设计原理：3份草稿如何合成1份报告

【免费下载链接】hyperresearchAgent-driven research knowledge base. Agents collect, search, and synthesize web research into a persistent, searchable wiki.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperresearch

Hyperresearch 三重草稿集成（Triple Draft）是这个开源 Agent 研究知识库中最巧妙的工程设计：它不直接写一份研究报告，而是让 3 个并行子代理各写一份不同角度的草稿，再由专门的"合成器"把 3 份草稿融合成 1 份经过对抗审计的最终报告。这套机制让它在 DeepResearch-Bench 深度研究排行榜上取得领先。本文带你完整看懂它的设计原理。

为什么一个 Agent 写 1 份草稿不够？

想象你让一个人"一口气"写出 5000 字的研究报告：他会先入为主，写到哪里算哪里，观点单一、视角固定。Hyperresearch 的早期版本（V7）就吃过这个亏——编排器在长对话中被"上下文压缩"冲掉了三重草稿的流程，最后只写了单份草稿，报告质量明显下滑。

V8 的解法很直白：与其让一个"疲惫的大脑"写 1 份报告，不如让 3 个"新鲜的大脑"各写 1 份，再由 1 个专职合成器做最后的融合。

第一步：给 3 份草稿分配 3 个不同视角

这是三重草稿集成的灵魂。如果 3 份草稿写的是同一个论证，那等于浪费。所以 hyperresearch-10-triple-draft.md 明确规定：

有争议的话题：

草稿 A —— 最强论题派：采纳证据最充分的一方，强力论证
草稿 B —— 强攻反方派：认真对待最强反方观点，为少数派辩护
草稿 C —— 综合调和派：论证双方各对一半，重点写"边界条件"——在什么情况下哪一方的论证成立

无争议的话题（综述、对比、收集类）：

草稿 A：追求广度，覆盖所有要点
草稿 B：追求深度，深挖 3-4 个最重要的要点
草稿 C：面向实践者，围绕可操作的建议组织内容

3 个视角会被写入运行日志文件draft-angles.md，确保有据可查。

第二步：每份草稿配一份专属"阅读清单"

这是最容易被忽视、却最关键的一步：每个写草稿的子代理不自己决定读什么，而是由主编排器提前选好 20-50 篇仓库笔记（must_read_note_ids）交给它。

这样做的两个好处：

消除浪费：子代理不需要在知识库里反复翻找，拿到清单直接精读
强制差异化：给每份草稿喂不同的证据基础——

草稿 A 优先拿支持主流证据方向的来源
草稿 B 优先拿少数派观点和方法论批判的来源
草稿 C 优先拿含边界条件、比较分析、应用案例的来源

允许重叠（核心笔记可以三份都有），但每份清单都有 5-15 篇是它独有的。清单会分别落盘为draft-a-source-list.md、draft-b-source-list.md、draft-c-source-list.md。

第三步：一条消息并行启动 3 个写作者

3 份草稿由 3 个hyperresearch-draft-orchestrator子代理在同一条消息中并行启动——这是真并行，不是排队。每个子代理拿到：

原始研究问题（逐字引用，不可改写）
自己的draft_id（a / b / c）
自己的视角描述和专属阅读清单
输出格式（short/structured/argumentative）和引用风格

子代理的铁律是：清单上的每篇笔记都必须读完才能动笔，禁止自己去仓库里漫游，也禁止抓取新来源。三份草稿最终分别写入draft-a.md、draft-b.md、draft-c.md。如果某份缺失或过短，只会单独重跑那一份，绝不会带着少于 3 份草稿进入下一步。

💡 轻量档（light tier）是唯一例外：简单问题直接写单份草稿到最终报告，跳过三重草稿，30 分钟左右出结果。三重草稿只在full档强制执行——它被写进了不可违反的管线不变量里。

第四步：合成器如何把 3 份草稿变成 1 份报告

合成工作由 hyperresearch-11-synthesize.md 定义的 Step 11 完成，分五个阶段：

阶段	做什么	产物
11.1 通读	完整读完 3 份草稿 + 各子代理的回报摘要	—
11.2 冲突抽查	草稿间有事实矛盾时，编排器回查原始来源，逐条裁决	`synthesis-conflicts.md`
11.3 合成计划	定核心论题、选 3-7 个最强论证点、每节承诺引用哪份草稿	`synthesis-plan.md`
11.4 合成大纲	每个 H2 章节 1-2 句说明这里放什么证据和论证	`synthesis-outline.md`
11.6 双遍写作	合成器子代理两遍写完最终报告	`final_report.md`

两个精妙的设计决策值得展开：

为什么编排器自己不写最终报告？因为它已经跑了 30 多分钟、上下文塞满了 20 万 token 的陈旧调度逻辑，此时写 5000-10000 字报告是全管线认知负荷最高的动作。所以合成器是一个全新会话的子代理，工具锁定为只读+写入（Read + Write）——它心无旁骛，只能专注于写报告本身。

为什么是"两遍写"而不是"一遍写完"？第一遍产出粗糙的整合稿，第二遍专职清理：统一文风、删冗余、控篇幅。第二遍必须比第一遍短，否则视为出错。而且合成器被明确要求**"不得整段粘贴草稿原文，要用自己的声音重新合成"**——3 份草稿是原料，不是拼贴素材。

三重草稿集成带来了什么效果？

效果可以直接看数据：Hyperresearch 在 DeepResearch-Bench RACE 总体排行榜上以 57.8 分位居榜首，领先于 Grep Deep Research（56.2）、Gemini 2.5 Pro Deep Research（49.7）和 OpenAI Deep Research（46.5）。

这背后是三重草稿集成与整条 16 步管线的协同：草稿 12 之后还有 4 个对抗性批评者并行攻击报告、引用核查、精修等层层把关。而 V8 架构把每个步骤拆成独立的技能文件、在需要时"新鲜加载"，正是为了保证三重草稿这一步永远不会被长对话悄悄丢掉——官方在 hyperresearch.md 中记录的对比很说明问题：完整跑满管线的运行得分 55.9，退化成单草稿的运行只有 52.6。

三重草稿相关的参数（如draft_count: 3、各档位的must_read篇数区间）统一收敛在 profiles.py 中，子代理的生成模板与校验逻辑在 hooks.py 中，完整流程入口是 README.md。想看看这套流水线产出什么样的报告，可以读 example-reports/rl-exploration-trajectory-planning.md——那份 58.3 分的样张就是由 3 份角度草稿合成而来的。