| name | patent-panorama-insights-stats |
| description | 用于专利全景项目的环节2。它消费 patent-panorama-insights-search(环节1)产出的已验证 `search_config.json`、`candidate_pool.csv` 和 `core_recall.csv`,生成全景统计(趋势、申请人格局、技术构成、竞品画像)、按分支组织的核心专利索引(默认采信环节1召回排序,仅在必要时做有边界的兜底核查)和价值信号交叉挖掘文件。所有统计直接从检索式聚合,不需要逐件专利标引。 |
patent-panorama-insights-stats — 全景统计与价值信号层(环节2)
我是环节 2/4 · 格局统计(patent-panorama-insights-stats)。 我吃环节 1 的 search_config.json + candidate_pool.csv + core_recall.csv,产出 panorama_stats.json + value_signals.json + patent_index.core.json/.csv + chart_data.json + panorama_stats_report.html(数据快照报告),交给环节 3(patent-panorama-insights-tag)和环节 4(patent-panorama-insights-report)。
目标
专利全景流水线的环节2。本层是基于检索式聚合的层。由于 /59100a 和 /3fd502 统计工具可以直接从检索式聚合,环节2不需要逐件专利标引;只要环节1交付已验证检索式和候选池,就能运行。
它回答:
- 该领域规模多大、分布在哪、趋势如何?
- 主要玩家是谁、规模如何、趋势如何?
- 技术构成和竞品结构如何?
- 每个分支的核心专利有哪些——按分支组织,默认基于环节1召回信号分层,只在优先分支过薄时核查。
- 每个候选的价值信号集中在哪里——高前向引用 × 大同族 × 有效法律状态 × 竞品集中度。
输出是给**环节3(patent-panorama-insights-tag)和环节4(patent-panorama-insights-report)**使用的统计 + 价值契约。
使用时机
/patent-panorama-insights-search 已产出 search_config.json + candidate_pool.csv + core_recall.csv 之后。
- 单独使用:用户已有已验证检索式,希望直接获得全景统计 + 核心索引,不做标引。
- 在
/patent-panorama-insights-tag(taxonomy 推荐)和 /patent-panorama-insights-report(报告生成)之前。
输入契约(来自环节1 / patent-panorama-insights-search)
| File | Used for |
|---|
search_config.json | 分支检索式(A6 四段)、恒定主题锚点、范围包络(司法辖区 / 日期口径 / 同族计数) |
candidate_pool.csv | pn 列表,仅供 pn 对照(精简后只含 pn, branch_rule_hits,不含 metadata)。S1–S3 统计全部对检索式在线聚合,不读此文件。S4 enrichment 直接调 /1458a4 bibliography,不 join 此文件。 |
core_recall.csv | 按分支组织的 refered_rank / famn_rank 召回清单(branch_id, patent_id, pn, recall_source, raw_rank,每分支约 top 10)——默认写入 patent_index.core.*;逐件核查只作为有边界的兜底 |
如果任何输入缺失,停止并要求用户先运行 /patent-panorama-insights-search。不要在这里重新推导检索式。
输出契约(给环节3 / 环节4)
| File | Content |
|---|
panorama_stats.json | trend / applicant_rank / technology_constitute / tech_applicant_dist + 每个竞品画像 |
assignee_normalization.json | 别名 / 子公司归并决策,to_confirm 标记 |
patent_index.core.json / .csv | 按分支组织的核心专利——每条 23 字段(22 + branch_id);默认采信环节1召回排序,仅在优先分支过薄时兜底核查 |
value_signals.json | 候选级价值交叉得分;复用 S4 事实 + 分支级 portfolio_value 与 most_asserted,不重新查询 |
chart_data.json | 所有聚合表,已适配图表,供环节4报告生成 |
panorama_stats_report.html | 自包含统计仪表盘 HTML(数据快照报告)——从已落盘的 panorama_stats.json + chart_data.json + patent_index.core.* + value_signals.json + search_config.json 渲染 S1–S5。可独立交付。不同于环节4的分析洞察报告(report.html) |
report_manifest.json (extended) | 继承环节1 manifest;增加环节2文件索引、MCP 来源、数据截止日期 |
默认设置(继承环节1,重述)
| Dimension | Default |
|---|
| Technology stats counting | 简单同族层级(每族一条) |
| Market / legal stats counting | 公开文本层级(所有单件公开文本) |
| Date basis | 市场/法律用公开日(pbdt);技术趋势用最早优先权日——与 search_config.json 声明保持一致 |
| Analysis mode | 竞品 vs. 行业(Mode C)——从 run_config.json 读取 |
| Core patent signal | 前向引用 × 同族广度 × 有效法律状态 |
| Excluded | 正式 FTO、侵权、SEP 必要性、有效性、新颖性、创造性意见 |
首选 MCP 栈
| Capability | Preferred MCP / tools | Fallback |
|---|
| 行业趋势 / 司法辖区 | /59100a/mcp trend, search_patents_statistics, rec_office, get_rec_office_year | /3fd502/mcp trends |
| 申请人格局 | /59100a/mcp applicant_rank, applicant_trend | /3fd502/mcp applicant_ranking, /33072f/mcp search_patent_field(field=ASSIGNEE) |
| 技术构成 | /59100a/mcp technology_constitute, tech_applicant_dist, applicant_technology_analysis | search_config.json 分支检索式的规则命中量 |
| 图表洞察 | /3fd502/mcp trends, technology_effect_distribution, most_cited, portfolio_value | 从 chart_data.json 本地生成图表 |
| 核心召回核查 | /1458a4/mcp forward_citation, family, get_patent_legal_status, bibliography | /958a46/mcp 单件专利简报 |
| 资产流(可选) | /1458a4/mcp transfer_data, license_data, award_data | — |
除非当前 key 的 tools/list 成功,否则默认不要使用 /v1/ip/patent-landscape/mcp 或 /v1/ip/insights-report/mcp。
S1:行业全景统计
回答问题: 该领域规模多大,趋势往哪个方向,分布在哪里?
调用:
- 对完整检索式调用
/59100a trend 或 search_patents_statistics(field=APPLICATION_YEAR) → 年度趋势。
/59100a rec_office 和 get_rec_office_year → 司法辖区/受理局分布及年度拆分。
/3fd502 trends 作为图表友好的对比视图。
- 从
core_recall.csv top 记录抽取 30–50 件样本调用 /1458a4 get_patent_legal_status(不是从 candidate_pool.csv,因为池不再携带 metadata)→ 估算 active / pending / lapsed 比例。
输出到 panorama_stats.json + chart_data.json:
- 年度公开趋势(族级;最近 2 年注明公开滞后)。
- 司法辖区/受理局分布(文本级)。
- 法律状态分布估算,并注明样本量。
S2:申请人格局
回答问题: 主要玩家是谁,相对规模如何,各自趋势如何?
调用:
- 完整检索式 →
/59100a applicant_rank → top 申请人及数量。
/59100a applicant_trend 获取 top 玩家趋势。
- 兜底:
/33072f search_patent_field(field=ASSIGNEE, limit=30)。
- 对每个指定竞品:核查其是否出现;记录排名和数量。如缺失或异常偏低 → 标记为别名检查问题。
申请人归一化 → assignee_normalization.json:
- 关系明确时,将子公司归并到母公司。
- 不确定子公司标记为
to_confirm——不要静默合并。
输出:归一化 top 申请人排名(族级)、突出指定竞品、标注别名问题。
S3:技术构成 + 竞品画像
回答问题: 该领域技术结构是什么;对每个指定竞品,规模、分支、市场、趋势和最具影响力专利如何?
S3a — 技术构成(全领域)
/59100a technology_constitute → 官方 IPC / 技术类别基线。
/59100a tech_applicant_dist 或 applicant_technology_analysis → 申请人 × 技术结构。
- 分支命中量:用
/59100a search_patents_statistics 跑每条 search_config.json 分支检索式。标注为规则命中近似,重复计数——环节3标引会产出验证后的分支标签。
S3b — 竞品画像(仅 Mode B/C)
对每个指定竞品运行,并建立交叉矩阵。
- 为每家公司构建/记录申请人别名检索式。
/59100a applicant_trend 或限定申请人的 search_patents_statistics → 总量 + 趋势。
- 对申请人限定调用
/59100a rec_office → 司法辖区分布。
/59100a applicant_technology_analysis 或限定分支检索式 → 分支分布。
- 限定近 3 年 → 近期焦点;与全周期组合对比。
- 对申请人限定调用
/59100a refered_rank 或 /3fd502 most_cited → 高被引专利。
交叉输出到 panorama_stats.json + chart_data.json:
- 竞品 × 分支矩阵(适配热力图)。
- 竞品 × 司法辖区矩阵。
- 每个玩家近 3 年焦点变化。
- 每个竞品 top 3–5 高被引专利(PN、标题、引用数)。
S4:核心专利索引——按分支组织、数据驱动核查
回答问题: 每个技术分支中,哪些专利是该分支核心——已由环节1排序、分层,并只在必要时核查?
输入:core_recall.csv——环节1的按分支组织召回清单(branch_id, patent_id, pn, recall_source, raw_rank,每分支约 top 10)。这些是 Patsnap 预计算的 refered_rank / famn_rank 排序,不是需要批量核查的原始 ID。
设计决策(2026-05-31,精简版): 环节1 的 candidate_pool.csv 现在只含 pn + branch_rule_hits,不含 metadata。S4 的可展示字段 enrichment 改为直接对 core_recall 中的 pn 按需调用 /1458a4 bibliography,而不是 join pool。核心专利总量通常 ≤ branch_count × 10(约 30–100 件),调用量可控,且只拉核心件不拉全池。
决策(2026-05-31):默认采信环节1分支排序,按需兜底,绝不逐件全核查。 旧做法会对每个候选串行调用 4–5 个 /1458a4 工具,返回值在上下文中累积,容易撑爆 200K 窗口。新做法:环节1给的就是智慧芽算好的现成排序,默认直接采信落盘;逐件 /1458a4 核查只在“分支凑不满 10 篇且是优先分支”时作为兜底触发,且全局封顶 TOP-N = 50 次核查调用。
默认路径(不逐件核查)
- 读取
core_recall.csv,按 branch_id 分组。完整核心索引 = 每个分支按 raw_rank 取前约 10 → 总数约 branch_count × 10。该数量不封顶,因为采信环节1排序不消耗核查预算。
- 通过批量 bibliography 补充可展示字段——不是 join candidate_pool。 对
core_recall.csv 中的核心 pn,按分支一批调用 /1458a4 bibliography。拉取 title / abstract / assignee / ipc / publication_date / priority_date / jurisdiction。只保留写入磁盘的字段,不在上下文累积完整响应。每批 ≤20 个 pn;每批后写盘;上下文只保留 enriched X/N。
- 基于环节1召回信号 + join 结果分层,不做逐件 MCP:
recall_source = both(高被引且大同族)→ core_tier1。
recall_source = refered_rank 或 famn_rank 单独出现且位于分支前半 → core_tier2。
- 其余 →
core_tier3。
- 这是信号分层,标注为“recall-signal tier, not legal-verified”。
- 立即写入
patent_index.core.json / .csv。对话中每分支只保留一行:branch B3: 10 core, tier 2/5/3。
兜底核查(数据驱动、有边界——TOP-N = 50 调用)
仅当优先分支(用户在 run_config.json 标记,或 S3 中 top-volume 分支)召回 < 10 个同族时触发。只对这些分支:
- 对缺口候选运行
/1458a4 forward_citation + family + get_patent_legal_status + bibliography,确认较低排名 ID 是否符合条件,并补齐 candidate_pool.csv 中未找到的 ID。
- 全流程逐件核查调用总数硬上限 ≤50(
TOP-N = 50)。这是调用预算上限,不是输出上限;落盘核心索引可以超过 50 条(按 branch_count × 10),只限制核查调用。如果预算耗尽,在 manifest 记录 verification_budget_exhausted,不得静默继续调用。
- 批量 ≤20,每批后写盘,上下文只保留
verified X/N, tier a/b/c。 不要让带摘要、引用清单和同族成员的核查记录积累在对话里。
- 对已核查记录,用法律核查规则升级分层:
- Tier 1: 高引用且同族广度 ≥3 个主要司法辖区且法律状态有效。
- Tier 2: 三项中任两项。Tier 3: 三项中任一项。
- 如果核心索引超过约 120 条且用户要求完整重核查,在隔离子代理中运行 S4 兜底,避免逐件 payload 进入主上下文。
输出
patent_index.core.json / .csv——每个分支核心候选一条,23 字段(22 + branch_id):
record_id, branch_id, patent_id, publication_number, title, normalized_assignee, original_assignee,
publication_date, priority_date, jurisdiction, legal_status, family_size, citation_count,
score, tier, abstract, ai_summary(由摘要机器生成),
technical_problem, technical_solution, technical_effect, recommendation_reason(空——人工/环节3评审),
review_status(recall_signal / verified / needs_review), source_run_id。
- 默认采信路径下
review_status = recall_signal;兜底核查为 verified;摘要不可用(如部分 EP 专利)为 needs_review——不得编造缺失字段。
- 默认路径下
family_size / citation_count / legal_status 为 null(未核查),只对 verified 记录填写——不得从召回信号编造。
- 记录按
branch_id 分组,使环节3推荐包和环节4分支演进叙事直接对齐。
S5:价值信号交叉挖掘(复用 S4 事实——不重新查询)
回答问题: 每个核心候选的价值信号集中在哪里?
范围是候选级,按 branch_id 组织。本步骤不再次调用 /1458a4。 所需逐件事实——引用、同族广度、法律状态——已在 S4 中解析并写入 patent_index.core.*。S5 读取这些已落盘事实,只添加下方低成本分支级信号。(分支级“价值热点”聚合不在这里做——环节4会从候选分数聚合护城河主题。)
| Signal | Source | Re-query? | Label as |
|---|
| High forward-citation | 复用 patent_index.core.*(S4)中的 citation_count | no | influence signal |
| Wide family | 复用 patent_index.core.*(S4)中的 family_size | no | global-protection proxy |
| Active legal status | 复用 patent_index.core.*(S4)中的 legal_status;默认采信路径用 both/refered/famn 召回信号做代理 | no | status signal |
| Competitor concentration | 读取 S3 的竞品 × 分支矩阵——哪个指定竞品集群拥有该候选分支 | no(S3 已计算) | who-owns-this-cluster signal |
分支级增强(低成本,按分支,不逐件循环):
/3fd502 portfolio_value 对每条分支检索式一次(不是每件专利)→ 作为分支级组合价值信号,盖到该分支所有候选上。标注为信号,不是结论。
/3fd502 most_asserted(或 most_cited 兜底)对每个分支一次 → 诉讼/主张强度信号。标注为诉讼暴露信号,不是法律结论。
调用量:S5 的逐件部分 零 MCP 调用(完全复用 S4 落盘);只新增 /3fd502 的 portfolio_value + most_asserted 各按分支数次调用(branch-level,不逐件)。这是 S5 不再二次膨胀的关键。
评分:
- 将每项信号在候选集内归一化到 0–1,再合成为
value_score(记录所用权重)。
- 每个候选记录触发的信号和贡献事实。若某个逐件事实为
null(默认采信路径、未核查),使用召回信号做代理,并将证据标为 recall_proxy,而不是 verified。
输出:value_signals.json——每个核心候选一条:
patent_id, pn, branch_id, citation_signal, family_signal, legal_signal, competitor_concentration_signal,
portfolio_value_signal(分支级), most_asserted_signal(分支级), value_score, signals_fired[], evidence{}(每项标 verified 或 recall_proxy)。
S6:资产流信号(可选)
回答问题: top 候选是否存在明显转让、许可或奖项?
仅当用户要求资产情报,或 S4 发现感兴趣竞品的高层级候选时运行。
对 Tier-1 候选调用 /1458a4 transfer_data, license_data, award_data。仅作为信号说明输出——不作法律结论。
S7:统计仪表盘 HTML(panorama_stats_report.html)
回答问题: 分析师能否在不等待环节4的情况下,交付一个好看、直观、可离线打开的 S1–S5 快照?
这是数据快照报告,不同于环节4的分析洞察报告。它可视化“数到了什么、聚合了什么”,而不是“解释出了什么”。页眉必须带一句说明:"统计快照(数据视图);分析结论与演进/护城河解读见 环节4 洞察报告。"
数据来源(不新增 MCP)
完全从已落盘文件渲染——panorama_stats.json + chart_data.json + patent_index.core.* + value_signals.json + search_config.json。S7 不新增 MCP 调用。
章节(依数据而定;v0.2 样例使用 8 个)
默认章节:概览 / 检索质量 / 产业格局 / 申请人格局 / 技术分支 / 竞品矩阵 / 核心召回 / 方法边界。运行有确认的下一步范围时,可包含 Layer 2 proposal 区块;数据缺失或有意压缩时,不强制固定章节数。
样式契约
单文件、自包含、无外部 CDN/D3、离线可打开。CSS 变量、字体、组件与环节4 report.html 保持一致,避免两套色板漂移。样式原则以 skill/patent-panorama-insights/references/report-visual-style.md 为准;当前视觉证明为 examples/大模型联盟专利洞察/outputs/panorama_stats_report.html。
- CSS
:root 变量(逐字照抄现有报告):
--bg:#ffffff; --bg-soft:#f7f9fc; --bg-mid:#eef2f8; --accent:#1d4ed8; --accent2:#0891b2; --accent3:#059669; --gold:#d97706; --red:#dc2626; --text-primary:#111827; --text-secondary:#374151; --text-muted:#6b7280; --border:#e5e7eb; --card-bg:#ffffff; --card-bg2:#f9fafb; --tier2-bg:rgba(29,78,216,0.05); --tier3-bg:rgba(217,119,6,0.05);
- 字体:
'Segoe UI', -apple-system, BlinkMacSystemFont, 'PingFang SC', 'Microsoft YaHei', sans-serif;html font-size 13px。
- 组件:
.report-header(双语标题 + tag-line + meta-row)、.kpi-strip / .kpi-card(4 列:候选池规模 / 申请人数 / 核心专利数 / 时间跨度)、.section / .section-header(双语 section 标题)、tier chip(tier1=accent / tier2=accent2 / tier3=gold)。
- 图表: 优先用 HTML/CSS/SVG 静态结构渲染;如确需交互,JS 必须内联且可降级。禁止外部 D3/CDN 依赖。
- 数据注入: 从已落盘 JSON/CSV 预聚合后写入 HTML,不读外部文件。
输出
panorama_stats_report.html——自包含统计仪表盘。落盘后在对话里只留一行 panorama_stats_report.html written (N sections, N charts),不回贴 HTML 内容。
阶段性输出
S1–S5 完成后(可选 S6,随后 S7 渲染 panorama_stats_report.html),展示完整全景摘要 + Layer-2 范围建议。
## 环节2 Panorama Summary
### Scope (from search_config.json)
[key parameters summarized inline]
### Industry Stats (S1)
- Total candidate pool: [N families / M publications]
- Annual trend: [growing / stable / declining since YYYY]
- Top jurisdictions: [...]
- Legal status estimate: [X% active, Y% pending, Z% lapsed] (sample N=__)
### Assignee Landscape (S2)
- Top 5 players: [...]
- Named competitors ranked: [...]
- Alias issues flagged: [...]
### Technology Constitution + Competitor Portraits (S3)
- Top branches by volume: [...] (rule-hit approximation)
- Fastest-growing branches (recent 3 yrs): [...]
- Per-competitor: [total, top branches, top markets, recent shift, top cited patent]
### Core Patent Index (S4)
- Organized by branch: [B1: N core, B2: N core, ...] (≈ branch_count × 10)
- Tier 1 (Core): [N] · Tier 2 (Strong): [N] · Tier 3 (Watch): [N]
- Verification: [採信 环节1 recall signals by default; fallback-verified X patents across Y priority branches, TOP-N budget used Z/50]
- See patent_index.core.json / .csv
### Value Signals (S5)
- Highest-value candidates: [top patents by value_score]
- Signal mix: [how many candidates fired all 4 signals]
### 环节3 Proposal
| Item | Proposal |
|---|---|
| Candidate pool for tagging | [N patents, from which branches/players] |
| Suggested tagging depth | Light (abstract) / Standard (abstract+claims) / Deep (full text) |
| Priority branches | [...] |
| Priority competitors | [...] |
Confirm 环节3 scope or adjust.
MCP 工具参考
| Tool | MCP Server | Used In |
|---|
trend, search_patents_statistics, rec_office, get_rec_office_year | /59100a/mcp | S1 |
applicant_rank, applicant_trend | /59100a/mcp | S2, S3b |
technology_constitute, tech_applicant_dist, applicant_technology_analysis | /59100a/mcp | S3 |
refered_rank, famn_rank | /59100a/mcp | S3b(限定申请人)。核心召回已在 core_recall.csv 中——S4 默认不重新调用这些工具 |
trends, technology_effect_distribution, most_cited, portfolio_value, most_asserted | /3fd502/mcp | S1, S3b;S5 的 portfolio_value + most_asserted 按分支运行(不是按专利) |
forward_citation, family, get_patent_legal_status, bibliography | /1458a4/mcp | S4 仅兜底(优先分支 < 10 个同族;TOP-N ≤ 50 调用)。S5 复用 S4 落盘事实,不重新查询 |
transfer_data, license_data, award_data | /1458a4/mcp | S6(可选) |
| (无——纯渲染) | — | S7 从已落盘文件渲染 panorama_stats_report.html,不调用 MCP |
search_patent_field | /33072f/mcp | S1–S3 兜底 |
证据和语言规则
- 分支计数来自规则命中检索式:表述为“规则命中近似,重复计数”。
- 引用次数:表述为“前向引用信号,不是法律或质量结论”。
- 同族广度:表述为“全球保护代理指标——实际权利要求范围需要法律审查”。
- 法律状态:表述为“简单状态信号——执行决策前需法务确认”。
value_score:表述为“综合信号分,不是估值——权重记录在 value_signals.json”。
- 竞品方向预测:使用“专利信号提示……”而不是“该公司将……”。
- 所有发现都要追溯到具体 MCP 调用、日期和检索式,并记录在运行日志中。
下一步 → 环节 3/4 · 标引推荐(patent-panorama-insights-tag)
环节2 统计与价值产物就绪后,路由到 04_skill_draft/patent-panorama-insights-tag/SKILL.md:
- Checkpoint 的环节3 Proposal 经用户确认后 → 读取
patent-panorama-insights-tag/SKILL.md,把 panorama_stats.json + patent_index.core.* + value_signals.json 作为输入交付。
- patent-panorama-insights-tag 据此推荐技术分解表 + 关键技术问题 + 推荐专利包,逐条标引交客户 SaaS 工具。
- 报告层 patent-panorama-insights-report(环节4)同时吃环节2的
panorama_stats.json + value_signals.json + chart_data.json。
使用前配置
本 Skill 依赖智慧芽开放平台 MCP 服务: