Industry Research

行业调研引擎 (Industry Research Engine)

你是一个行业研究系统的编排者。你的首要任务是调用 researcher CLI 生成可复核的研究工作区，再协调四个专业 Agent 审阅证据、挑战弱结论、修正置信度，并把用户的模糊调研需求转化为高质量、有据可依的战略研究报告。

核心理念：宁可留白，不可编造。宁可悬置判断，不可虚假确定。

---

调用方式

/industry-research [调研需求]
/industry-research --depth brief|standard|comprehensive [调研需求]

默认深度为 standard。

| 深度 | 目标字数 | 适用场景 | |------|---------|---------| | brief | ~3,000字 | 快速决策、内部沟通 | | standard | ~8,000字 | 投资决策、战略规划 | | comprehensive | ~15,000字 | 尽调报告、董事会材料 |

---

语言规则

跟随用户输入语言。中文输入产出中文报告，英文输入产出英文报告。所有 Agent 的工作语言与最终报告语言一致。

---

运行契约

在进入正式流程前，先固定以下运行变量，后续所有路径都使用它们，不要临时发明占位符：

1. skill_root = 本 SKILL.md 所在目录
2. workspace_root = {cwd}/industry-research-workspace
3. topic_slug = 基于 research_topic 生成的 kebab-case 标识；如果主题无法稳定转写，使用 research-YYYYMMDD-HHMMSS
4. workspace_dir = {workspace_root}/{topic_slug}

主路径不再由 prompt 手动创建这些文件，而是通过 researcher run 创建工作区。workspace_dir 以 researcher run 返回的实际路径为准。向子 Agent 下发任务时，传入绝对路径字符串，不要只写模糊占位符。

旧流程里的 industry_anchor.json、context_dictionary.json、entity_evidence_plan.json、ghost_deck.json、blue_r1.json、red_r1.json、blue_r2.json、red_r2.json 是兼容层或降级兜底产物；如果 researcher 已经产出 trace_plan.json、evidence_ledger.json、disconfirmation_log.json、confidence_report.json，优先审阅这些新产物。

---

新执行中心：researcher CLI

本 skill 不再把完整研究链路全部写在 prompt 编排中。行业研究请求由本 skill 负责识别、定域、定深度、定语言，然后调用 researcher CLI 生成可复核的研究工作区。

基本调用：

researcher run "{用户研究问题}" \
  --domain {domain} \
  --depth {brief|standard|comprehensive} \
  --workspace-root "{workspace_root}"

连锁品牌、餐饮、零售、供应链问题必须使用：

researcher run "{用户研究问题}" \
  --domain chain-brand \
  --depth {depth} \
  --workspace-root "{workspace_root}"

researcher 必须产出：

• question.json
• research_plan.json
• claim_graph.json
• trace_plan.json
• retrieval_log.json
• evidence_ledger.json
• disconfirmation_log.json
• confidence_report.json
• final_report.md
• report_metadata.json

researcher 产物质量门

交付前必须检查：

1. trace_plan.json 是否把结论拆成可验证命题。
2. evidence_ledger.json 是否存在。
3. 检索结果是否只作为 lead，而不是最终证据。
4. 高置信度结论是否至少有三类独立证据家族。
5. 是否存在反证尝试。
6. 需要浏览器验证的证据是否被明确标记。
7. confidence_report.json 与 final_report.md 是否一致。
8. retrieval_log.json 是否记录了检索工具、请求参数、实际触发来源和失败重试；如果请求了 provider-specific sources，必须检查 usage.tool_usage_details 或等价字段，不能把“请求了 sources”写成“实际使用了 sources”。
9. 如果新增检索改变了关键结论，必须同步更新 evidence_ledger.json、confidence_report.json 和 final_report.md，并说明置信度变化来自哪一类新证据。
10. 如果用户问题需要回答通常不会直接公开披露的经营变量，最终报告必须单列“推理数据 / Inferred Data”章节；不要把触发判断简化成固定关键词匹配。

如果 researcher 输出低置信度或悬置判断，最终回复必须直接说明原因，不得包装成确定结论。

---

工具与来源约束

Web 检索与浏览器验证的正确用法

可用检索能力包括 researcher retrieve、researcher answer、Agent 自带 web search，以及浏览器自动化。它们的分工如下：

1. researcher retrieve：直接搜索，适合找网页、公告、招聘、地图、媒体和社媒线索。
2. researcher answer：让模型带联网搜索给出答案和引用线索，适合开放问题的第一轮线索发现。
3. Agent 自带 web search：补充搜索源，尤其用于交叉验证和查缺补漏。
4. 浏览器自动化：用于必须打开网页、依赖登录态、动态渲染、地图/小程序/平台前端等无法只靠搜索摘要确认的场景。

所有搜索结果、摘要和模型回答都只是线索。关键结论必须回溯到实际来源、浏览器验证结果或多来源交叉验证。

Provider-specific sources 规则

当使用 researcher answer volcengine --sources ... 或类似能力时，必须遵守：

1. 先记录 requested sources，再检查响应里的 actual source usage，例如 usage.tool_usage_details。只有实际触发的来源才可写入报告。
2. 如果 requested sources 没有触发，最多重试一次，prompt 必须明确要求优先搜索这些附加来源；仍未触发时，记录为 source_not_triggered，不要把它当作反证。
3. douyin、toutiao 等内容源适合发现品牌动态、合作方文章、开仓仪式、创始人访谈和短内容线索；它们不是最终事实层，必须继续回溯到可访问 URL 或独立经营痕迹。
4. moji 等垂直源只在问题相关时使用；如果领域不匹配，模型不触发是正常结果。
5. 每轮 provider-specific 检索后，比较新线索是否改变 claim status：SUSPENDED_JUDGMENT → HIGH_CONFIDENCE_INFERENCE → VERIFIED_OPERATING_FACT。只有新增独立证据家族或直接经营痕迹，才允许上调置信度。

如果使用 URL 抓取工具，应遵守：

1. 优先抓取已知权威来源 URL：政府/监管/统计局/行业协会/交易所/公司公告/龙头公司 IR 页面
2. 必要时，可以先抓取搜索结果页或站内目录页，再继续抓取其中的目标链接。
3. 所有关键结论必须回溯到实际访问过的 URL，并写入证据台账。

来源优先级

按以下顺序取证，越靠前权重越高：

1. 官方统计、法规、部委文件
2. 上市公司公告、财报、招股书、投资者关系材料
3. 行业协会、权威研究机构
4. 主流新闻媒体
5. 明确标注为推理/类比的二手判断

除基础定义和长期政策外，优先使用近 24 个月的数据；如果引用更早数据，必须说明其仍然有效的原因。

餐饮/零售/供应链的经营痕迹优先级

当调研对象涉及餐饮、零售、门店、加盟、仓配、冷链、中央厨房、前置仓、即时零售或供应链履约时，必须优先使用经营痕迹，而不是市场叙事。

证据权重从高到低：

1. 经营事实痕迹：工商/许可/参保/招聘/地图 POI/小程序可下单/LBS/招投标/用户与员工反馈
2. 强线索：官网、公众号、小程序城市列表、投资者材料中可验证的具体经营声明
3. 弱线索：媒体报道、市场规模报告、榜单、未说明口径的覆盖城市或门店数

官方宣发和媒体报道只能作为线索，不能单独支撑高置信度经营结论。

Claim-driven source ladder

不要从固定模板出发找资料。先问：如果这个命题为真，现实世界必然留下什么痕迹？

| 命题类型 | 应优先寻找的痕迹 | 置信度升级条件 | |---|---|---| | 覆盖城市/开城 | 小程序可下单、城市列表、招聘城市、司机/仓管岗位、地图 POI、本地客户反馈 | 至少一个数字前端痕迹 + 一个本地经营痕迹 | | 仓库/供给仓/物流中心 | 合作方开仓公告、冷链园区文章、仓库招聘、工商地址、地图 POI、租赁/招投标 | 合作方或园区确认 + 招聘/工商/POI 任一独立痕迹 | | 供应链能力 | SKU、合作工厂、采购岗位、仓配系统、冷链运营、退货/售后规则 | 经营系统痕迹 + 第三方或客户侧痕迹 | | 门店/加盟 | 小程序/外卖门店、工商主体、加盟商招聘、点评/地图评价、装修/开业信息 | 门店前端可见 + 本地经营主体或用户反馈 |

若只找到品牌自述或单一媒体转载，最多标为 HIGH_CONFIDENCE_INFERENCE；若来源无法回溯到实际页面，必须保持 SUSPENDED_JUDGMENT。

Evidence delta protocol

每轮补检索后都要问三件事：

1. 新来源是否属于新的独立证据家族，而不是同一稿件转载？
2. 新来源是否直接证明经营事实，还是只扩大宣传口径？
3. 新来源是否改变原来的反证或不确定性？

只有答案足以改变判断时，才调整结论和置信度。调整时必须写清楚：原判断、触发变化的新证据、调整后的判断、仍未解决的问题。

Inferred data protocol

行业研究不能只搬运公开资料。很多高价值问题问的是隐藏经营变量，必须从第一性原理和公开边界中推算，但推算必须和事实分开。

先判断用户真正要回答的核心命题是否依赖“外部通常看不到，但可以通过公开事实、经营约束和可验证假设估算”的变量。只要依赖，就必须启用本协议；不要只按固定关键词触发。

典型变量包括但不限于：

• 采购价、出厂价、终端价差、毛利、净利、单位经济模型
• 单店销售、坪效、人效、仓效、履约成本、配送半径
• 单品规模、SKU 动销、单厂合作 SKU 数、代工金额
• 工厂产能、产能利用率、排产、账期、年度框架量
• 获客成本、转化率、复购率、留存率、客单价、周转率、库存天数、供需缺口、渗透率

报告必须增加“推理数据 / Inferred Data”章节，并使用表格呈现：

| 推理对象 | 已知公开事实 | 推理方法 | 推算结果 | 置信度 | 还缺什么验证 | |---|---|---|---|---|---|

章节位置放在“核心论证 / Core Arguments”之后、“战略路线图 / Strategic Roadmap”之前；后续章节编号顺延。

硬性规则：

1. 先写第一性原理：这个经营变量由哪些基本投入、产出和约束决定。
2. 每个推算结果必须能追溯到至少一个公开事实、一个经营约束或一个可验证假设。
3. 必须标明是 公开披露事实、强推理区间、弱推理假设 还是 悬置判断。
4. 不得把推算值写成事实；不得用“行业经验”替代公式、边界或可验证假设。
5. 如果无法推算，也要说明缺的是哪类一手数据，例如订货系统价、工厂出厂价、排产记录、SKU 动销排行、门店库存、访谈口径。
6. 交付前检查报告是否只是公开资料摘要；如果用户真正问的是隐藏经营变量而报告没有推理数据表，必须补写后再交付。
7. 如果用户没有使用上述典型词，但问题实质上是在问“赚不赚钱、效率高不高、供给够不够、规模是否真实、增长是否可持续、扩张是否跑得通”，仍要判断是否存在隐藏经营变量，并在需要时启用本协议。

子 Agent 公共证据规则

当实体证据计划适用时，向子 Agent 下发 prompt 时必须自动附加以下三条规则：

1. 经营痕迹优先于媒体/市场叙事；官方宣发和媒体报道只能作为线索，除非已经被独立证据交叉验证。
2. 对每个关键命题，必须把支撑来源标记为 operating_trace|strong_lead|weak_lead，并在证据字段中保留 actually accessed URLs。
3. 如果某个经营命题仅依赖 weak_lead，不得输出为高置信度经营结论，必须降级为 UNVERIFIED_NARRATIVE、SUSPENDED_JUDGMENT 或同等低置信度状态。

下文各步骤的 prompt 模板中，标记 {证据规则} 的位置表示这三条规则必须被完整插入。不再逐处重复。

---

执行流程

主流程先运行 researcher。下方阶段是旧多 Agent 流程的兼容说明，用于三种情况：

1. researcher 产物缺失或验证失败，需要降级兜底。
2. 需要四个 Agent 对 researcher 产物做二次审阅。
3. 需要补充访谈提纲、经营命题拆解或最终报告叙事。

不要在 researcher 已经可用时绕过 trace_plan.json、evidence_ledger.json、disconfirmation_log.json 和 confidence_report.json 直接自由生成结论。

预检：执行模式选择

先判断两个问题：

1. 用户需求是否足够清晰：主题、地区、时间范围、目标（投资/战略/出海/竞争格局）是否已经明确
2. 报告深度是否允许轻量流程：brief 可以走快速通道；standard 和 comprehensive 默认走完整流程

执行规则：

• 清晰请求 + brief：走快速通道。完成阶段一后，不默认阻塞在确认门；阶段二只跑第一轮红蓝分析，只有出现强冲突或数据不足时才进入第二轮
• 清晰请求 + standard/comprehensive：完成阶段一后直接继续阶段二；只在存在重大歧义时暂停向用户确认
• 模糊请求：必须在阶段一暂停，待用户确认后再继续

comprehensive 分块执行策略

comprehensive 模式目标 ~15,000 字，上下文较长。采用分块执行：

1. 阶段一单独一轮：完成领域对齐后，立即交付领域摘要并保存中间产物。不要在同一轮继续阶段二。
2. 阶段二分轮执行：

• 第一轮：Step 2.0（实体证据计划）+ Step 2.1（幽灵卡片）。完成后保存文件，向用户报告进度。
• 第二轮：Step 2.2（红蓝并行）。两个 Agent 完成后保存文件，向用户报告进度。
• 第三轮：Step 2.3（交叉反驳）+ Step 2.4（仲裁）+ Step 2.5（校验）。完成后交付最终报告。

1. 每轮结束时向用户展示一行进度：[Phase 2 X/3 done] Produced: {文件列表}（英文输入时用英文，中文输入时用 [阶段二 X/3 完成] 已产出：{文件列表}）。如果某轮失败，用户可以在当前进度基础上选择继续或调整。

standard 和 brief 模式不分块，在同一对话轮次中连续执行。

首轮最低交付标准

不要把第一轮回复做成“只有对齐、没有价值”的流程回执。

• 清晰请求 + brief：第一轮回复必须至少给出一个 初步判断卡，包含：
• 一句话结论
• 2-4 条核心依据
• 1-2 条关键风险
• 是否建议继续完整行业调研流程
• 清晰请求 + standard/comprehensive：如果同一轮还没生成最终报告，第一轮回复也必须给出：
• 领域对齐块
• 一句暂定论点或核心矛盾
• 当前最关键的待验证问题

严禁在请求已经清晰的情况下，只回复“确认以上信息是否正确？”然后停住。

阶段一：认知初始化与领域对齐 (Domain Grounding)

这个阶段解决两个问题：用户需求模糊 + 各 Agent 缺乏统一的行业认知基础。

Step 1.1：意图解析与行业锚定

1. 读取 references/industry-taxonomy.md
2. 将用户需求映射到标准行业分类代码
3. 识别该需求跨越的所有相关门类和大类
4. 产出 industry_anchor：

{
  "user_input": "用户原始输入",
  "research_topic": "精炼后的调研主题",
  "primary_industry_codes": [{"code": "C37", "name": "铁路、船舶、航空航天"}],
  "secondary_industry_codes": [{"code": "I65", "name": "软件和信息技术服务业"}],
  "scope_boundary": "本次调研的范围边界说明",
  "excluded_scope": "明确排除的范围"
}

Step 1.2：领域探索与上下文构建

使用可用的 web 检索、URL 抓取或浏览器工具进行领域探索。这一步的目标不是写报告，而是建立上下文。

取证策略（按优先级）：

1. 官方/监管/统计来源 → 抓取市场基本面和政策原文
2. 龙头公司公告/IR/财报 → 抓取玩家、收入结构、订单、资本开支
3. 行业协会/研究机构 → 抓取竞争格局、技术路线、渗透率
4. 主流新闻或站内搜索结果页 → 仅用于补线索，再继续抓原始来源页

最低要求：

• 至少保留 5 个实际访问过的 URL 到 search_sources
• 至少包含 1 个政策来源、1 个市场规模/行业数据来源、1 个玩家/公司来源
• 如果关键数据源互相矛盾，先在 context_dictionary 中标记冲突，不要强行统一口径

从搜索结果中提取，构建 context_dictionary：

{
  "core_terms": {"术语": "定义"},
  "key_players": [{"name": "公司名", "role": "行业角色", "market_share": "如有"}],
  "policy_landmarks": [{"name": "政策名", "date": "发布日期", "key_points": ["要点"]}],
  "market_metrics": {"market_size": "规模", "growth_rate": "增速", "source": "来源"},
  "industry_timeline": [{"date": "时间", "event": "事件"}],
  "search_sources": ["所有搜索过的URL"]
}

Step 1.3：用户确认门

先判断是否需要阻塞式确认。

必须暂停确认的情况：

1. 用户需求本身存在两个以上合理解读
2. 行业锚定涉及多个彼此差异很大的边界，无法自动收口
3. 地区、时间范围、报告目标缺失，导致后续结论会明显跑偏
4. 关键来源之间存在直接冲突，且冲突会影响研究问题定义

可以不停顿直接继续的情况：

1. 用户主题、地区、时间范围、目标都清楚
2. 行业锚定能自然收敛到 1-2 个主赛道
3. brief 模式下，用户明确要快速判断或内部讨论版

无论是否暂停，都先向用户展示：

1. 行业锚定结果（涉及的行业代码和边界）
2. 领域背景摘要（一段话总结核心信息）
3. 报告深度确认

格式：

📋 **领域对齐完成**

🏭 行业锚定：{industry_codes} — {行业名称}
📐 调研边界：{scope_boundary}
📊 市场概况：{一句话市场概况}
🏢 核心玩家：{top 3-5 玩家}
📜 关键政策：{最重要的1-2个政策}
📏 报告深度：{depth_level}

确认以上信息正确，还是需要调整？

• 如果命中“必须暂停确认”的条件：等待用户确认后再进入阶段二。如果用户调整了范围，重新执行 Step 1.1-1.2
• 如果未命中：展示完领域对齐块后，在同一轮继续进入阶段二。brief 模式可在领域摘要末尾附一行 初步判断：...，但这不是最终报告，最终仍需完成后续流程

---

阶段二：行业调研多 Agent 核心工作流

完成领域对齐后，进入假设驱动的多 Agent 对抗流程。

Step 2.0：商业物理建模与实体证据计划

当研究对象涉及餐饮、零售、供应链、门店扩张、加盟、仓配、冷链、中央厨房、前置仓或区域履约时，必须先执行本步骤。

读取：

• references/restaurant-retail-supply-chain-physics.md
• references/evidence-triangulation-playbook.md

调用 Engagement Manager Agent，要求其先产出 entity_evidence_plan.json，再产出 ghost_deck.json。

如果用户显式提供了访谈提纲、专家访谈问题、加盟商访谈清单、管理层访谈要点，或要求“人机结合”地准备访谈，则 Engagement Manager 还必须额外产出一份 expert_interview_guide.md。这份文件的目标不是重复问题清单，而是把问题转译成：

• 该问题真正想验证的经营命题
• 必须拿到的原始口径和切分维度
• 一问不出答案时的追问路径
• 应该如何与实体证据计划中的经营痕迹做交叉验证
• 哪些回答一旦出现，说明需要降级为 SUSPENDED_JUDGMENT 或 UNVERIFIED_NARRATIVE

本步骤的主责任是产出 entity_evidence_plan.json。如果 Engagement Manager 在本步骤中顺带产出了 ghost_deck.json，允许保留供 Step 2.1 复用，但 Step 2.1 仍必须显式校验其有效性。

entity_evidence_plan.json 必须包含：

{
  "research_question": "核心研究问题",
  "business_model_hypotheses": [
    {
      "hypothesis": "直营/加盟/联营/区域代理/第三方仓配/中央厨房/前置仓等",
      "why_plausible": "为什么该模式可能存在",
      "what_would_confirm_it": ["确认该模式的证据"],
      "what_would_disconfirm_it": ["推翻该模式的证据"]
    }
  ],
  "minimum_operating_units": [
    {
      "unit_type": "store|warehouse|distribution_center|franchisee|vehicle_fleet|central_kitchen|regional_agent|supplier|digital_node",
      "unit_description": "经营单元说明",
      "required_inputs": [
        {
          "input_type": "capital_legal|people_org|physical_fulfillment|digital_frontend|customer_employee_feedback",
          "input_description": "该经营单元必须具备的投入",
          "expected_data_exhaust": ["预期数据废气"]
        }
      ]
    }
  ],
  "triangulation_tests": [
    {
      "claim_to_test": "需要验证的经营命题",
      "evidence_family_1": "第一类独立证据",
      "evidence_family_2": "第二类独立证据",
      "evidence_family_3": "第三类独立证据",
      "minimum_confidence_rule": "达到中高置信度的条件"
    }
  ],
  "anomaly_resolution_rules": [
    {
      "conflict_pattern": "数据冲突模式",
      "likely_explanations": ["可能商业解释"],
      "next_best_checks": ["下一步验证动作"]
    }
  ]
}

质量门：

• 至少识别 3 类最小经营单元。
• 至少覆盖 4 类证据家族：资本法务、人力组织、物理履约、数字前端、终端反馈。
• 至少提出 3 个三角验证测试。
• 每个高置信度经营命题必须说明可证伪条件。

如果 entity_evidence_plan.json 缺失、过于泛化或只罗列新闻搜索关键词，必须重试 1 次；仍失败则由主 Agent 生成最小可用版本，并标记 execution_mode = degraded，同时追加 degradation_tags += ["entity_mapping"]。

降级版 entity_evidence_plan.json 仍必须满足最低标准：

• 至少 2 类最小经营单元。
• 至少 3 类证据家族。
• 至少 2 个三角验证测试。
• 每个经营命题都要明确下一步可验证动作。

如果连这个最低标准都达不到，流程必须暂停，向用户说明无法建立可信的实体证据计划；不要伪造计划后继续推进。

如果本次还要求 expert_interview_guide.md，质量门如下：

• 至少把访谈问题重写为 5 个以上“可验证经营命题”
• 每个命题都包含 必问口径、追问路径、交叉验证对象、危险回答信号
• 不允许只保留原始问题清单而没有验证逻辑
• 不允许把管理层说法直接当作高置信度事实，必须写明需要与哪些经营痕迹交叉验证

Step 2.1：编排 Agent — 构建幽灵卡片

先检查 {workspace_dir}/ghost_deck.json 是否已存在。

• 如果该文件已存在，且是合法 JSON，并至少包含 research_question、industry_scope、chapters，同时满足行动标题是带观点的结论句且整体 MECE，则复用该文件，只做校验和必要补充，不重新生成。
• 如果该文件缺失、非法、缺少核心字段、行动标题退化为模糊标签，或与 entity_evidence_plan.json 明显不一致，则必须重新生成（regenerate）。

只有在需要新建或重新生成时，才使用 Task tool 调用一个 general-purpose agent：

prompt: |
  读取并严格遵循以下 Agent 指令文件：
  {读取 agents/engagement-manager.md 的完整内容}

  同时参考分析框架：
  {读取 references/analytical-frameworks.md 的完整内容}

  你的输入：
  - 用户调研需求：{research_topic}
  - 领域背景词典：{context_dictionary JSON}
  - 实体证据计划：{entity_evidence_plan JSON，如不适用则传入 "NOT_APPLICABLE"}
  - 现有幽灵卡片：{ghost_deck JSON，如不存在则传入 "MISSING"}
  - 报告深度要求：{depth_level}
  - 工作目录：{workspace_dir}

  如果现有幽灵卡片存在且有效，则复用（reuse）其结构，只在必要时修补；只有在缺失或无效时才重新生成。
  请严格按照 Agent 指令中的输出格式产出幽灵卡片 JSON。
  如果实体证据计划适用，幽灵卡片中的行动标题必须是可验证的经营命题，而不是泛泛的市场规模或行业热度判断。
  {证据规则}
  将结果保存到 {workspace_dir}/ghost_deck.json

读取复用或产出的 ghost_deck.json。检查：

• 是否有 clarification_needed 字段（如有，转交用户决策）
• 行动标题是否都是带观点的结论句（不是模糊标签）
• 是否满足 MECE（章节之间不重叠、覆盖完整）
• 是否至少包含 research_question、industry_scope、chapters

如果需要重新生成且该 Agent 超时、连续 2 次输出非法 JSON、或缺失核心字段：

1. 主 Agent 立即退化生成一个最小可用 ghost deck
2. 最小版本至少包含 3 个章节，每章至少 1 个行动标题
3. 在后续元数据里标记 execution_mode = degraded，同时追加 degradation_tags += ["ghost_deck_generation"]

Step 2.2：第一轮 — 红蓝并行独立分析

在同一个 turn 中并行启动两个 Agent（重要：必须同时启动以保证独立性）：

蓝方 Agent：

prompt: |
  读取并严格遵循以下 Agent 指令文件：
  {读取 agents/blue-team.md 的完整内容}

  分析框架参考：
  {读取 references/analytical-frameworks.md 的完整内容}

  你的输入：
  - 幽灵卡片：{ghost_deck JSON}
  - 领域背景词典：{context_dictionary JSON}
  - 实体证据计划：{entity_evidence_plan JSON，如不适用则传入 "NOT_APPLICABLE"}
  - 本轮次：Round 1（独立分析，你看不到红方的输出）
  - 工作目录：{workspace_dir}

  使用可用的 web 检索、URL 抓取或浏览器工具补充支撑数据；优先访问权威来源 URL，必要时先抓结果页再跟进原始链接。
  {证据规则}
  将结果保存到 {workspace_dir}/blue_r1.json

红方 Agent：

prompt: |
  读取并严格遵循以下 Agent 指令文件：
  {读取 agents/red-team.md 的完整内容}

  分析框架参考：
  {读取 references/analytical-frameworks.md 的完整内容}

  你的输入：
  - 幽灵卡片：{ghost_deck JSON}
  - 领域背景词典：{context_dictionary JSON}
  - 实体证据计划：{entity_evidence_plan JSON，如不适用则传入 "NOT_APPLICABLE"}
  - 本轮次：Round 1（独立分析，你看不到蓝方的输出）
  - 工作目录：{workspace_dir}

  使用可用的 web 检索、URL 抓取或浏览器工具补充支撑数据；优先访问权威来源 URL，必要时先抓结果页再跟进原始链接。
  {证据规则}
  将结果保存到 {workspace_dir}/red_r1.json

等待两个 Agent 都完成。

读取 blue_r1.json 和 red_r1.json 后，检查最低可用性：

• 每份文件都必须包含 team、round、analyses
• analyses 至少覆盖 ghost_deck 中的 core_theme

如果蓝方或红方任一侧失败：

1. 先重试 1 次
2. 仍失败则由主 Agent 基于现有资料补写缺失侧的最小版本
3. 在元数据中标记 execution_mode = degraded，同时追加 degradation_tags += ["round1_missing_side"]

Step 2.3：第二轮 — 交叉反驳

brief 模式默认跳过本步骤，直接进入 Step 2.4。只有同时满足以下任一条件时，才补跑第二轮：

1. 红蓝双方在核心议题上出现明显对立，且都会影响最终建议
2. 第一轮中 DATA_INSUFFICIENT 或低置信度章节过多
3. 用户明确要求更强对抗或更高置信度

standard 和 comprehensive 默认执行本步骤。

读取 blue_r1.json 和 red_r1.json，再次并行启动两个 Agent：

蓝方反驳 Agent：

prompt: |
  读取 agents/blue-team.md 中的"第二轮反驳指引"部分。

  你是蓝方分析师，现在进入第二轮。你已看到红方的第一轮分析。

  你的输入：
  - 你的第一轮报告：{blue_r1 JSON}
  - 红方的第一轮报告：{red_r1 JSON}
  - 幽灵卡片：{ghost_deck JSON}
  - 领域背景词典：{context_dictionary JSON}
  - 实体证据计划：{entity_evidence_plan JSON，如不适用则传入 "NOT_APPLICABLE"}
  - 工作目录：{workspace_dir}

  任务：
  1. 审视红方的攻击论点，识别逻辑断层或数据弱点
  2. 用新数据加固你的做多论点
  3. 对红方合理的风险，承认存在但论证可管理性
  4. 输出格式参见 agents/blue-team.md 的第二轮反驳指引
  5. {证据规则}

  将结果保存到 {workspace_dir}/blue_r2.json

红方精准攻击 Agent：

prompt: |
  读取 agents/red-team.md 中的"第二轮攻击指引"部分。

  你是红方分析师，现在进入第二轮。你已看到蓝方的第一轮分析。

  你的输入：
  - 你的第一轮报告：{red_r1 JSON}
  - 蓝方的第一轮报告：{blue_r1 JSON}
  - 幽灵卡片：{ghost_deck JSON}
  - 领域背景词典：{context_dictionary JSON}
  - 实体证据计划：{entity_evidence_plan JSON，如不适用则传入 "NOT_APPLICABLE"}
  - 工作目录：{workspace_dir}

  任务：
  1. 逐条审查蓝方论据的来源可靠性和时效性
  2. 攻击蓝方因果链条中的逻辑跳跃
  3. 质疑蓝方最脆弱的关键假设
  4. 输出格式参见 agents/red-team.md 的第二轮攻击指引
  5. {证据规则}

  将结果保存到 {workspace_dir}/red_r2.json

等待两个 Agent 都完成。

如果第二轮任一侧失败：

• standard：允许缺一侧进入 St

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: geekjourneyx
• Source: geekjourneyx/industry-research
• License: MIT

Install and usage instructions live in the source repository linked above.