deep-research

深度研究

创建高保真研究报告，并严格控制格式、映射证据、管理来源以及进行多轮综合。

架构：主 Agent + 子 Agent

Lead Agent (coordinator — minimizes raw search context)
  |
  P0: Environment + source policy setup
  |
  P1: Question and claim map (decision questions, evidence routes, stop rules)
  |
  Dispatch ──→ Subagent A ──→ writes task-a.md ──┐
           ──→ Subagent B ──→ writes task-b.md ──┤ (parallel)
           ──→ Subagent C ──→ writes task-c.md ──┘
  |                                               |
  |     research-notes/  <────────────────────────┘
  |
  P2: Dispatch + investigate → evidence packets
  P3: Citation registry + source governance
  P4: Evidence-mapped outline with counter-evidence and unknowns
  P5: Draft from evidence packets; reopen decisive originals
  P6: Counter-review (claims, confidence, alternatives)
  P7: Verify → asset check and catalog registration

上下文纪律： 将原始搜索结果中的噪声留在任务工作区中。向主 Agent 传递证据包，其中包含定位信息和简短的来源摘录。笔记用于辅助定位，并非权威依据：对于报告中每个关键论点、存在冲突的论点，以及使用的精确数字、日期或引文，主 Agent 都必须打开原始来源核查。

运行与资源约定——每次调用均适用

进行外部检索前，请阅读 research-asset-contract.md。为单路线和多路线研究创建或恢复持久化项目研究。搜索其中明确列出的既有研究目录，打开相关的早期原始来源，并记录复用、调整或舍弃的决定。在 study.json 中拟定决策问题，以及提供方 × 实际模式路线。编写一个准确的 dispatch_context，其中包含用户提供的种子 URL、具名实体，以及查询所需的已验证代码或其他标识符。每条路线的提示词中都必须包含此字符串；research_assets.py start 会拒绝缺少该字符串的情况。在外部分发前，将用户指定的种子文章或文档作为原始来源存档；如果提供方无法读取该 URL，请遵循提供方交接流程。仅仅因为协调器能看到用户提供的链接或本地文件，并不意味着模型工作区也能看到。然后运行 provider_runs.py plan。将用户要求的每种模式都保留在计划中；对于无法增加价值、不可用或缺少付费授权的路线，记录有理有据的 deferred 事件。即使报告由直接网页搜索和内部子 Agent 汇编而成，也仍然需要一条直接来源路线和同样的存档。

新研究使用 schema 2 的请求模式约定：存档原始请求和已接受的工作流，独立于执行路线解读所需模式，并将每种模式映射到相应路线。未请求任何模式时，明确声明模式清单为空是有效的；缺少此约定则无效。plan 会拒绝未映射的路线或映射不匹配的路线。请根据原始请求检查清单：字段和哈希无法证明语义完整性。schema-1 存档仍可读取，但请求覆盖情况未知；不要为了填补这一缺口而重启旧任务。

收集提供方报告前，请加载 report-file-collection.md。请使用可用的文件或下载渠道，而非剪贴板。schema-2 提交和历史导入必须包含未更改的实际模式观察回执；预先准备的提示词不需要回执。延后处理的路线及其原因必须保持可见。最终检查或注册时，对于不确定的结果或旧版请求覆盖情况，必须明确提供 --bounded-reason；保留该原因，但不得声称已完全完成。目录搜索会返回当前已注册的详情和记录的覆盖情况，并不代表已完成完整性检查；请遵循研究资源约定。

研究期间，保留未经编辑的提供方输出、每个已打开的原始来源，以及提供方提供的每个来源 URL，并记录其状态和来源信息。将报告中的论点关联到获准使用的原始来源；模型报告只能用于定位候选证据。将报告标记为完整前，运行 provider_runs.py validate、research_assets.py check，并注册该研究以供后续发现。只有引文、却没有研究、来源和论点记录的答案，不符合此 Skill 的要求。本地脚本只负责记录和检查文件，不会调用提供方，也不授权付费工作。 在发送可能自行选择数据插件的 Work/Agent 任务前，请检查相关插件目录，确认是否按调用收取额度或费用。账户已登录且请求使用某个数据源，并不意味着支出上限不受限制。如果自主任务可以调用按量计费的插件，且无法在每次调用前暂停，而该任务又没有针对这些插件的明确支出授权，请暂缓使用这条路径，或改用可先审批具体调用的方案。即使有预算，提示词也不是技术层面的费用上限：如果自主任务无法强制执行上限，就使用可控的方案。为便于追溯，请在提供商提示词中注明授权限额，然后在执行后查看原始工具日志；如果发生了超出限额的收费，请记录实际用量并告知用户。不要为了弥补覆盖缺口而再次进行付费调用。

模式选择

开始前确定研究模式：

维度	选项
主题模式	企业研究（公司／企业）或通用研究（行业／政策／技术）
深度模式	标准（包含多个决策问题或存在争议的证据）或轻量（一个范围明确的问题，且证据面较小）
提供商模式	明确指定单一路径，或提供商 × 模式方案。保留用户要求或项目接受的所有模式，将其标记为已选择或有理由地暂缓；在能实质性检验决策时，选择其他独立路径

• 企业研究模式：以问题为导向的公司研究，仅在有助于回答决策时选择可选分析框架
• 通用研究模式：采用标准 P0-P7 研究流程，并实施来源治理
• 深度选择：依据尚未解决问题的数量及其重要性，而非提示词长度、任务数量或目标字数
• 提供商选择：当用户说“按我们的方法”或调用具名研究流程时，查阅用户既定的工作流。只有在新增模型报告能提供独特的证据路径、结构化工具访问或有意义的质疑时，它才有价值。检查每个提供商的可用性、隐私边界和付费授权；不要悄悄将用户要求的多种模式缩减为仅使用直接来源的报告。不要默认运行所有可用路径，也不要硬编码供应商名单。

来源治理（V6）

来源访问类型

按访问权限对每个来源分类：

访问类型	定义	示例	使用规则
public	无需身份验证，任何外部研究人员均可访问	公开网站、新闻文章、WHOIS（未启用隐私保护）、学术论文	✅ 始终允许
semi-public	需要注册或访问受限	LinkedIn 个人资料、Crunchbase 基础版、行业报告（免费版）	✅ 允许，但需披露
exclusive-user-provided	用户付费订阅、私有 API、专有数据库	Crunchbase Pro、PitchBook、私有数据源、内部数据库	✅ 第三方研究允许使用
authorized-first-party	经用户授权，涉及其所在组织、交易或工作的记录	合同、发票、CRM 记录、会议记录	✅ 可用于确立内部业务事实；须标明来源

第一方来源边界： 经用户授权的记录可用于确立组织做了什么、达成了什么协议、支付了什么、交付了什么或观察到了什么。这些记录不算是对市场地位、客户评价、法规遵从情况或第三方主张的独立外部验证。绝不要将内部记录标为外部发现。

✅ 独家信息优势：你应该：

• 使用用户的 Crunchbase Pro 研究竞争对手
• 使用用户的专有数据库进行市场研究
• 使用用户的私有 API 进行投资分析
• 利用用户提供的任何独家来源开展第三方研究

来源类型标签

每个来源还必须标注：

标签	定义	示例
official	一手来源、官方文档	公司 SEC 文件、政府报告、官方博客
academic	经同行评审的研究	期刊文章、会议论文、学位论文
secondary-industry	专业分析	行业报告、分析师报道、行业出版物
journalism	新闻报道	信誉良好的媒体、调查性新闻
community	用户生成的内容	论坛、评论、社交媒体、问答网站
other	未分类或混合来源	聚合网站、未经核实的来源

覆盖度诊断： 跟踪来源数量、域名、来源类型构成和集中度，以揭示覆盖不足。不得仅根据这些总量判定研究通过或不通过。应评估每个决策问题和关键主张是否有适用的证据支持、是否搜寻了反面证据，以及是否明确说明了尚存的未知事项。

AS_OF 日期政策

在 P0 明确设定 AS_OF 日期。对于所有时效性主张：

• 每条引文都附上来源发布日期
• 如果来源超出相关时效范围，则降低置信度
• 为每类主张定义时效范围，并标记超出范围的材料；统一的年龄阈值只能用于诊断

P0：环境与政策设置

开始前检查能力：

检查项	要求	缺失时的影响
所需证据渠道可用	必需	缩小范围，或停止并将受影响的问题标记为未知
可检索原始来源	关键主张所必需	不得将摘要／片段提升为最终证据
可调度子 Agent	优先	降级为顺序执行
文件系统可写	完成任务所必需	内存笔记可支持部分调查；报告归档缺口，并将研究标记为未完成

设置政策变量：

• AS_OF：当天日期（YYYY-MM-DD）——时效性主题必填
• MODE：Standard（默认）或 Lightweight，根据问题地图说明理由
• SOURCE_TYPE_POLICY：强制使用 official/academic/secondary/journalism/community/other 标签
• COUNTER_REVIEW_PLAN：哪些证据会推翻每项暂定结论

设置提供方模式前，先搜索研究资源目录。较早的模型摘要仅是线索；重新打开其来源并检查时效性后再复用。

报告：[P0 complete] Subagent: {yes/no}. Mode: {standard/lightweight}. AS_OF: {YYYY-MM-DD}.

研究特定公司时，使用专门的工作流，按问题分流证据。将六个维度视为覆盖度地图，而非必须采用的报告大纲。

企业工作流概览

Enterprise Research Progress:
- [ ] E1: Intake — confirm company entity, research depth, format contract
- [ ] E2: Question-led evidence collection across relevant dimensions
  - [ ] D1: Company fundamentals (entity, founding, funding, ownership)
  - [ ] D2: Business & products (segments, products, revenue structure)
  - [ ] D3: Competitive position (industry rank, competitors, barriers)
  - [ ] D4: Financial & operations (3-year financials, efficiency metrics)
  - [ ] D5: Recent developments (6-month events, strategic signals)
  - [ ] D6: Internal/proprietary sources (or note limitation)
- [ ] E3: Optional analysis framework selected for the decision (or none)
- [ ] E4: Claim/evidence/unknown checks at each stage transition
- [ ] E5: Draft in the user's requested structure
- [ ] E6: Counter-review and verification (same as general P6–P7)
- [ ] E7: Present draft for human review and iterate

P1：研究任务板

继续处理已有问题时，首先根据 增量跟进恢复其有依据的结论、已解决的问题、更正内容、尚未解答的问题和重新开启条件。 仅向执行者提供一份先前报告，并不能证明这些状态已得到延续。

每项研究都使用通用的提供方执行契约： 一份问题映射、准确的提示词，以及每个提供方 × 实际模式各自独立的 lane_id，其中包括在使用时的直接原始来源路线。在分派前运行 provider_runs.py plan。当选定两个或更多提供方／模式路线时，先于分流加载 parallel-provider-ops.md，并与独立 Agent 协调可用的提供方、浏览器／应用、检索和验证 Skills。 每个控制界面指定一名负责人，并将该负责人的 UI 操作串行化。不要在此 Skill 中实现提供方调用，也不要假定提供方名单固定。 尽早提交耗时较长的异步任务，并将每项原始结果分别归入其对应路线； 通过已有来源恢复进行中的任务，而不是重复启动需要付费的工作。实际分派前，按照授权规则解析并读取每条路线当前的执行器 Skill； 本地规划器不会调用任何提供方。提供方的报告是 P3 的输入，而非经过独立核验的来源。不要根据模型名称或报告长度推断普通聊天使用了原生 Deep Research；应核实实际的 UI 或 API 路线。综合时应依据底层原始来源和决策价值，而不是对模型报告进行投票。

将任务分解为决策问题。只有在不同证据路线或专业知识能让研究更清晰时，才创建任务。

每项任务分配都包括：

• 专家角色：专业角色设定（例如“政策史学家”“生态系统绘图师”）
• 目标：一句话概述调查目标
• 查询：2–3 条预先规划的搜索查询
• 深度：DEEP（获取 2–3 篇完整文章）或 SCAN（摘要片段即可）
• 输出：研究笔记文件的路径
• 并行组：A 组（独立）或 B 组（依赖 A 组）
• 决策问题：此任务旨在帮助回答的确切问题
• 关键主张：可能改变结论的暂定主张
• 反证：哪些内容会削弱或推翻各项主张
• 证据路线：哪些来源所有者或记录系统能够实际查明该事实
• 停止规则：何种情况算作已回答、遭到反驳或仍未知

任务分解规则

1. 每项任务只涵盖一个由某位专家负责的连贯子主题
2. A 组任务在逻辑上必须相互独立；来源独立性应根据底层证据、所有权和动机评估，而不是按领域数量判断
3. 每个并行组最多 3 项任务（并发限制）
4. 每项任务都必须标明时效性主张、拟查找的反证以及预期的引文时效风险

企业研究整合

在企业研究模式下，应将问题映射到相关维度，而不是自动创建全部六项任务：

• 任务 A：公司基本情况（实体、成立时间、融资、所有权）
• 任务 B：业务与产品（业务板块、产品、收入结构）
• 任务 C：竞争地位（行业排名、竞争对手、壁垒）
• 任务 D：财务与运营（3 年财务数据、效率指标）
• 任务 E：近期进展（近 6 个月的事件、战略信号）
• 任务 F：获授权的一手记录（可用于回答业务事实时；绝不计作外部佐证）

报告：[P1 complete] {N} tasks in {M} groups. Dispatching Group A.

---

企业研究模式（专业化流程）

研究特定公司时，针对每个决策问题，沿相关企业维度开展研究。利用这些维度寻找缺失的证据路径；不要默认遍历全部六个维度或添加量化框架。

E1：接收

与上文 P0/P1 相同，另外：

• 确认所研究的确切法律实体（母公司还是子公司）
• 根据决策问题、证据难度和所需输出选择研究深度；页数仅作为规划诊断指标
• 确定任何具体的比较对象（基准公司）

P2：分派 + 调查

子 Agent 使用 references/subagent_prompt.md 执行任务，并按照 references/research_notes_format.md 输出证据包。

使用子 Agent（Claude Code / Cowork / DeerFlow）

1. 并行分派 A 组任务（最多同时处理 3 个）
2. 每个子 Agent 搜索、获取并标注来源类型
3. 每条来源记录都包含 Source-Type 和 As Of
4. 等待 A 组完成
5. 分派 B 组（可读取 A 组的笔记）

子 Agent 输出要求

每个 task-{id}.md 都必须包含：

• 问题状态：已回答 / 存在矛盾 / 未知，并说明用于停止调查的证据
• 来源部分：来自实际检索结果的稳定定位信息，包括来源类型、可访问性、日期和来源族标识
• 主张—证据表：主张、证据摘录/定位信息、范围、置信度，以及是否打开过原始来源
• 反向证据与未知项：调查了什么、发现了什么，以及仍有哪些问题尚未解决

不使用子 Agent（降级模式）

主 Agent 依次执行任务，分别扮演各专业角色。将原始搜索噪声保留在最终证据包之外；需要保证可复现性时，保留查询日志。

企业研究：六维度信息收集

请遵循 references/enterprise_research_methodology.md，其中包括：

• 各维度的详细信息收集工作流（查询策略、数据字段、验证）
• 数据来源优先级矩阵（P0-P3 分级）
• 针对具体主张的佐证与冲突处理规则

核心原则：

• 以证据为依据：每项结论都必须追溯到可引用的来源
• 相互佐证：只有当第二个来源独立于同一底层披露或数据集时，才会增加可信度
• 审慎判断：明确标注推测，避免提出未经证实的主张
• 结构化呈现：通过表格、列表和层级结构呈现复杂信息

完成每个维度后，运行 L1 质量检查（见 enterprise_quality_checklist.md）。

每项任务的状态：[P2 task-{id} complete] {N} sources, {M} findings. 全部任务的状态：[P2 complete] {N} tasks done, {M} total sources. Building registry.

E3：仅在有帮助时选择分析框架

只有当用户的决策需要分析框架时，才加载 references/enterprise_analysis_frameworks.md。用 SWOT 梳理战略选项；对明确包含概率/影响输入的决策使用风险矩阵；仅当权重和评分尺度有充分依据时才进行评分。若无法避免编造条目或精度，则省略该框架。

完成分析后，运行 L2 质量检查。

E4：质量控制

根据 references/enterprise_quality_checklist.md 进行三级检查：

• L1（数据）：来源数量、归属、交叉验证、时效性
• L2（分析）：决策问题覆盖度、主张支撑情况、反向证据，以及所用框架是否适用
• L3（文档）：结构合规性、格式一致性、可读性、附录

E5：使用企业模板起草

仅当企业质量检查清单中的 7 章企业报告模板符合所要求的决策时，才使用该模板；否则，应围绕问题地图调整结构。

1. 公司概况
2. 业务与产品结构
3. 市场与竞争地位
4. 财务与运营分析
5. 风险与关注事项
6. 最新进展
7. 综合评估与结论

另附附录：数据来源索引、术语表、免责声明。

E3-E7：企业分析、起草与审查

• E3：结构化分析 — 仅当 references/enterprise_analysis_frameworks.md 中的框架有助于决策，且其输入依据可靠时，才选择该框架；否则使用主张-证据表
• E4：质量控制 — 按照 references/enterprise_quality_checklist.md 执行 L1/L2/L3 检查
• E5：起草 — 遵循选定的问题导向结构和用户的格式约定；仅当企业模板适用时才使用
• E6-E7：草稿审查与核验 — 应用 P4–P7 的证据检查，并按要求进行人工审查；是否需要额外的起草轮次，取决于尚未解决的发现

---

P3：引文登记表 + 来源治理

主 Agent 阅读所有任务说明并建立统一登记表。

将所有已打开的来源和由提供方提供的 URL 追加到研究的 source-ledger.jsonl 中，包括已拒绝和不可用的线索；如有原始字节数据，则予以保存。将每项影响决策的主张及其精确定位信息绑定到 claims.jsonl 中已批准的来源 ID。请参阅 research-asset-contract.md。下方的编号报告引文登记表仍是面向读者的映射；它不能取代持久化的来源和主张记录。

登记流程

1. 阅读每个任务文件中的主张-证据表和来源
2. 合并来源；对 URL 去重，同时将源自同一项研究、申报文件、新闻稿、数据集、访谈或赞助方的多篇出版物归为同一证据系列
3. 按首次出现顺序分配连续的 [n] 编号
4. 标注：source_type、accessibility、as_of 日期、证据系列、权威性、独立性限制和任务 ID
5. 建立主张覆盖矩阵：支持性证据、反证、是否核查了决定性原始资料，以及尚待确认事项
6. 记录排除来源及其原因。不得仅因来源未达到任意设定的评分而将其排除；应限制其可支持的主张范围

登记表输出格式

CITATION REGISTRY

Approved:
[1] Author/Org — Title | URL | Source-Type: official | Accessibility: public | Evidence-Family: filing-123 | Date: 2026-03-01 | task-a
[2] ...

Dropped:
x Source | URL | Source-Type: secondary-industry | Accessibility: public | Evidence-Family: unknown | Reason: original record could not be retrieved; summary cannot carry the claim

Diagnostics: {approved}/{total}, {N} domains, {N} independent evidence families, source-type mix
Coverage: {answered}/{total questions}; {N} load-bearing claims unresolved

**关键规则：**这些 [n] 编号为最终编号。P5 只能引用“已批准”列表中的来源。已删除的来源不得再次出现。

授权的一手来源处理方式：研究用户自己的组织或资产时：

1. 对于授权原始记录直接记载的内部业务事实，使用这些记录
2. 将其标记为 authorized-first-party，并说明记录归属方
3. 仅当主张需要外部佐证时，才寻找外部来源
4. 明确说明结论属于以下哪种情况：内部已证实、已获外部佐证、存在冲突，或外部情况未知

专属来源处理方式：当用户明确提供其付费订阅或私有 API 以用于第三方研究时（例如“使用我的 Crunchbase Pro 研究竞争对手”），你应该：

1. 将其可访问性标记为“exclusive-user-provided”
2. 将其作为竞争优势加以利用
3. 在登记表中正确引用
4. 如果不存在独立的同类来源，则保留该来源有效的一手来源适用范围，并将外部主张标记为未知

报告：[P3 complete] {answered}/{total} questions answered. {N} load-bearing claims supported, {M} unresolved. Source totals are diagnostics.

处理信息黑箱

研究没有公开信息的实体时：

外部研究人员能查到的内容：

• WHOIS：隐私保护 → 没有所有者信息
• 网络搜索：没有新闻或新闻稿
• 社交媒体：没有公司主页
• 企业注册信息：没有公开 API，或需要本地访问
• 结果：完整的信息黑箱

正确回应：

Findings: NO PUBLIC INFORMATION AVAILABLE

Sources checked:
- WHOIS (public): Privacy protected [failed]
- Company registry (public): Access denied/No API [failed]
- News media: No coverage [failed]
- Corporate website: Placeholder only [minimal]

Verdict: UNABLE TO VERIFY COMPANY EXISTENCE from external perspective
Sources found: 0 (or minimal, e.g., only WHOIS showing domain exists)
Confidence: N/A - Insufficient evidence

不要：

• ❌ 将内部已确立的事实描述为已获外部独立佐证
• ❌ 仅凭域名注册就假定公司存在
• ❌ 用猜测填补缺失数据
• ❌ 在经授权的一手记录可直接证明内部业务事实时将其舍弃

应当：

• ✅ 清楚说明外部研究人员能够／无法核实哪些内容
• ✅ 将经授权的一手事实表述为内部已确立的事实，并与外部可见性分开
• ✅ 记录所有未成功的搜索尝试
• ✅ 将说法标记为 [unverified]，或完全省略
• ✅ 在证据无法回答决策问题时缩小范围或停止
• ✅ 建议直接联系以开展尽职调查

---

P4：证据映射大纲

主导 Agent 阅读证据包和登记表以拟定大纲，然后重新查看具有决定性的原始材料。

1. 识别跨任务模式
2. 按主题而非任务顺序设计章节
3. 将每个章节对应到带有来源编号的具体发现
4. 标记需要反向审查的章节
5. 对时效敏感的说法标记 AS_OF 核查
6. 将每项关键说法标记为有支持／有反驳／未知

大纲格式：

## N. {Section Title}
Sources: [1][3][7] from tasks a, b
Claims: {claim from task-a finding 3}, {claim from task-b finding 1}
Counter-claim candidates: {alternative explanations}
Recency checks: {source dates + AS_OF}
Gaps: {limited official evidence}

---

P5：根据笔记起草

按照 references/report_template_v6.md 逐节撰写，并根据用户的格式要求进行调整。

规则：

• 每项事实性说法都需要引用 [n]
• 数字／百分比必须标注来源
• 每节添加置信度标记：高／中／低，并说明理由
• 证据冲突时添加反方说法句
• 新来源只能通过相同的登记和核验流程加入
• 对无支持的说法使用 [unverified]

防止幻觉：

• 主导 Agent 绝不编造 URL；每个定位信息都必须来自实际检索
• 主导 Agent 绝不将笔记视为证据；对于关键说法、冲突、确切数字／日期和引文，必须重新查看原始材料
• 主导 Agent 绝不捏造数据；无支持的说法应保留为未知或予以省略

状态：[P5 in progress] {N}/{M} 个章节，约 {words} 字。

---

P6：反向审查（强制）

对每项主要结论进行反向观点核查。这些核查并不自动要求另派 Agent 或组建团队；只有在用户请求或适用的工作区指示要求时，才使用独立审查人员：

1. 结论是否可能有误？
2. 哪些高影响说法依赖于同一类证据，即使有许多域名重复这些说法？
3. 哪些说法缺少能够直接观察该事实的来源？
4. 是否将过时来源用于时效敏感的说法？
5. 仅报告有证据支持的问题；没有发现问题也是有效结果。 明确说明尚未解决的不确定性。不要捏造问题，也不要仅为凑出问题数量而重复已完成的核查。

使用反向审查团队（可选）

如需进行全面的并行审查，请使用反向审查团队：

# 1. Prepare inputs
counter-review-inputs/
  ├── draft_report.md
  ├── citation_registry.md
  ├── task-notes/
  └── p0_config.md

# 2. Dispatch to 4 specialist agents in parallel
SendMessage to: claim-validator
SendMessage to: source-diversity-checker
SendMessage to: recency-validator
SendMessage to: contradiction-finder

# 3. Wait for all specialists to complete

# 4. Send to coordinator for synthesis
SendMessage to: counter-review-coordinator
  inputs: [4 specialist reports]

# 5. Receive final P6 Counter-Review Report

详细用法请参阅 references/counter_review_team_guide.md。

手动反向审查（默认）

未选择审查团队时，请直接进行以下证据核查。如用户请求或适用的工作区指示有要求，请安排个人独立审查：

• 根据具有决定性的原始材料核实每项关键说法
• 检查佐证来源是否真正独立，且是否能够观察到相关说法
• 核实对时效敏感说法的 AS_OF 日期
• 记录相反的解读

输出

最终报告中只纳入有证据支撑的争议。仅当此类争议存在时，才使用编号条目。如果没有任何已确立的争议，请明确说明；切勿为了满足模板而填充占位性争议。单独报告未解决的不确定性，或说明不存在任何未解决的不确定性。

## 核心争议 / Key Controversies
未发现有证据支持的核心争议。
未解决的不确定性：无。

上述示例仅适用于两条陈述都得到已完成检查支持的情况；否则，请列出实际的争议或未解决的问题。

报告：[P6 complete] {N} issues found: {critical} critical, {high} high, {medium} medium.

---

P7：验证

在最终定稿前进行交叉核对：

1. 注册表交叉核对： 列出报告中的每个 [n] 与已批准注册表的对照
2. 承重性检查： 将每个决定性结论、确切数字/日期/引文以及有争议的事实追溯至原始来源
3. 抽样低影响论断： 仅将抽查用作诊断手段；一旦某项失败，就扩展到整个受影响类别
4. 验证没有已删除来源被重新引入
5. 检查关键论断的证据家族集中度

报告：[P7 complete] {N} spot-checks, {M} violations fixed.

在 P7 之后运行研究的最终资产检查和目录注册。如果某个选定通道仍然活跃，或某个来源缺少有效的原始来源/定位符，请将研究报告为不完整或有限定范围，而不是呈现为一次已完成的 Deep Research 运行。

---

输出要求

• 匹配所要求的语言和语气
• 保留英文技术术语
• 遵守报告规范和格式规则
• 包含参考文献部分或书目

参考文件

核心 V6 流水线参考

文件	加载时机
source_accessibility_policy.md	P0（关键）：来源分类规则 - 首先阅读
subagent_prompt.md	P2：向子 Agent 分派任务
research_notes_format.md	P2：子 Agent 输出格式
report_template_v6.md	P5：带置信度标记和反向评审的草稿
quality_gates.md	所有阶段：质量阈值和反幻觉检查
research-asset-contract.md	每次调用：既往研究发掘、单通道或多通道研究、来源/论断记录、最终检查和注册

通用研究参考

文件	加载时机
research_report_template.md	构建大纲和草稿结构
formatting_rules.md	强制实施章节格式和引用规则
source_quality_rubric.md	为来源评分和分类
research_plan_checklist.md	构建研究计划和查询集
completeness_review_checklist.md	审查覆盖率、引用和合规性

企业研究参考（处于企业研究模式时加载）

文件	加载时机
enterprise_research_methodology.md	六维数据收集工作流、来源优先级、交叉验证规则
enterprise_analysis_frameworks.md	SWOT 模板、竞争壁垒量化、风险矩阵、综合评分
enterprise_quality_checklist.md	L1/L2/L3 质量检查、各维度检查清单、7 章报告模板

反模式

• 未经过 P6–P7 证据核查，就将初稿视为已验证
• 没有能影响决策的证据缺口，却反复撰写完整草稿或开展并行审查
• 忽略格式约定或用户模板
• 声明没有引用，也未映射到证据表
• 混用互相矛盾的日期，却不指出差异
• 未经核实就照搬外部 AI 的输出
• 删除中间草稿或原始研究输出
• 主 Agent 将笔记视为权威依据——使用资料包进行路由，然后重新查阅关键原始资料
• 捏造 URL——只能使用实际搜索结果中的 URL
• 重新引入已弃用的来源——在 P3 中弃用的来源不得再次出现
• 时效性声明缺少 AS_OF——始终包含来源日期
• 跳过证据核查——完成 P6，只报告有依据的发现；若未确认任何问题，则允许报告零个问题。
• 夸大第一方信息的证明力——经授权的记录可以证明内部业务事实，但不能冒充外部验证
• 忽略专属来源——用户为竞争对手研究提供 Crunchbase Pro 等来源时，务必使用

下一步：验证并交付

有条件的后续移交

仅当用户要求移交，或经授权的工作流确实将研究交给另一位执行者时，才应用此规则。主 Agent 在准备接收方提示词前，先检查最新的原始请求和已接受的决策。在提示词中保留用户目标、当前阶段、已授权的交付内容、原始来源定位信息，以及下一个可证伪的探查点；并将观察结果、建议、已选约束和未经检验的假设分别标明。若没有相应权限，现有实现或先前提案不能视为已选定的约束。例如，方法研究的移交可以要求下一位执行者比较不同方法；不得暗中指示其实现现有引擎或交付完成的技能。

当需要移交会话或任务上下文时，从已安装的目录中解析当前的 handover Skill；移交产物及恢复流程仍由其负责。如果该负责人不可用，应报告这一缺口，并提供上述有明确边界的研究上下文，不得声称已执行其恢复流程。这并不授权实施或发布。主 Agent 依据原始资料判断阶段和权限；本地资产验证器检查记录完整性，而不判断接收方提示词是否保留了这些边界。

完成研究后，建议进行验证并输出：

Research report complete: [N] sources cited, [M] claims made.

Options:
A) Verify facts — run /fact-checker on the report (Recommended)
B) Create slides — pass the verified findings and citation registry to the active presentation workflow
C) Export as PDF — run /daymade-docs:pdf-creator for formal delivery
D) No thanks — the report is ready as-is