Legal Search Engine

---
name: legal-search-engine
description: Execute the multi-layer legal retrieval pipeline once a scenario is identified - extract legal facts, locate the legal issue, judge source effectiveness hierarchy, generate dynamic search strategy with statutory hierarchy scanning and comprehensive retrieval methodology, then filter and rank results with effectiveness verification and applicability validation in a feedback loop. Use this skill to perform actual statute retrieval through available legal databases, MCP/skills, official sources, or public web sources without exposing tool selection to users.
---

# 法律检索 · 多层法规检索引擎

> 这是法律检索专家的**法规检索核心执行引擎**，承接「场景识别」输出的检索任务单，把它跑成一份按效力层级有序、已核验时效的法规检索结果。五步串成一条带反馈闭环的流水线，融合法源位阶系统扫描、全面检索法、法条适用性验证等深度方法论。

## 执行流水线（务必按序）

```
①事实提炼 → ②问题定位 → ③对象与效力判定 → ④策略生成+位阶扫描+检索 → ⑤效力验证+适用性验证+过滤排序
                                                ↑________________反馈循环________________|
```

### 第 1 步 · 法律事实提炼
从用户描述中剥离情绪与无关细节，提取：主体身份、法律行为、法律关系、损害结果、争议焦点、证据类型、发生时间、涉及地域，输出结构化事实清单。详见 `references/retrieval-capability-chain.md` 能力 2。

### 第 2 步 · 法律问题定位
将事实清单映射为：一级部门法 → 二级细分领域 → 三级具体法律制度；明确检索目标是找法条/找判例/找监管规则；标记需排除的无关领域。

**问题转化（日常描述→法律概念）**：

| 用户日常描述 | 可能对应的法律概念 | 需进一步确认 |
|------------|-----------------|-------------|
| "公司老板把钱转走了" | 股东抽逃出资/关联交易损害公司利益/职务侵占 | 转走的是出资款还是经营资金？ |
| "对方不给钱" | 拒绝履行合同义务/侵权损害赔偿/不当得利返还 | 双方有无合同？ |
| "他骗我签的合同" | 欺诈（民事可撤销）/合同诈骗（刑事） | 欺诈手段？金额？ |

当识别出多个可能的法律概念时，每个概念都应生成独立的检索关键词组。

### 第 3 步 · 检索对象识别与效力层级判定
确定本次要检索哪几类资料（法律渊源/司法文书/非法律渊源），并按 `references/effectiveness-hierarchy.md` 的效力排序规则准备好层级框架。

### 第 4 步 · 动态检索策略生成 + 位阶扫描 + 执行检索

#### 4.1 法源位阶扫描检索

按位阶体系自上而下扫描，确保各核心层级法规无明显空白：

```
宪法
 └── 法律（全国人大及其常委会制定）
      └── 行政法规（国务院制定）
           ├── 地方性法规（省/市人大制定）
           ├── 部门规章（国务院各部委制定）
           └── 司法解释（最高法/最高检制定）
                └── 其他规范性文件（指导意见、会议纪要、批复等）
```

每轮检索结束后，对照位阶树检查——哪些层级已覆盖、哪些层级空白。空白层级是下一轮检索的方向。

#### 4.2 全面检索法：己方·对方·多路径

从用户诉求反推需要查找的法条，按三层展开：

**第一层：约定权利** — 合同/协议条款对应的法条
**第二层：法定权利** — 法律直接赋予的权利保护条款
**第三层：救济权利** — 侵权责任、不当得利返还、无因管理

**对抗视角**：在检索己方请求权法条的同时，也检索对方可能的抗辩依据：

| 己方主张方向 | 对方可能的抗辩方向 | 也需检索的法条 |
|------------|-----------------|-------------|
| 违约责任 | 不可抗力/情势变更/对方违约在先 | 免责条款、抗辩权条款 |
| 侵权赔偿 | 过错相抵/受害人故意/第三人原因 | 减免责任条款 |
| 劳动权益 | 严重违纪/不胜任/客观情况变化 | 用人单位合法解除条款 |

**请求权竞合处理**：各请求权对应的法条都要检索，在输出时标注各路径的差异（举证难度、赔偿范围、时效期间等）。

#### 4.3 构造检索式 + 调用工具

0. **重量级任务先建核验任务目录**：若任务单写【输出档位：重量】或【核验工作台：必用】，在第一轮检索前先运行 `legal-verify init --query "用户原始问题" --title "报告标题" --out "output/报告.html"`，记录返回的 `taskDir`。后续每批 WebSearch/WebFetch/MCP/法宝检索结果都必须写成 `retrieval-batch-XXX.json` 并 capture 到该 `taskDir`，不得先检索完再凭上下文补来源。
1. **前置知识推荐**：先凭专业知识推荐最可能命中的核心法律文件及条款（给用户一个快速锚点）。
2. **构造检索式**：核心词 + 法律术语组合、同义词扩展、时间/地域限定、案由筛选。
3. **调用检索工具实际检索**（见下方「检索工具调用」）。
4. **检索即持久化（强制）**：每调用一批检索/读取工具后，立即把该批结果整理成 `retrieval-batch-XXX.json`，运行 `legal-verify capture --task <taskDir> --input retrieval-batch-XXX.json --provider <来源>`。资料不能只留在上下文里；必须同时进入任务级 `raw-search/` 与（有正文时）`sources/index` 段落库。若搜索结果只有标题/摘要，先 capture 留痕，再继续读取网页/文档全文并再次 capture；只有段落库里的正文才能支撑后续核验关联。
5. **全文完整性验收（强制）**：每轮 capture 后运行 `legal-verify audit-sources --task <taskDir>`。如果生成的 `source-fulltext-queue.json` 有 blocker，说明可能只保存了搜索工具 observation 片段或截断正文，必须先用 WebFetch/官方库/MCP detail 工具补取全文，再进入输出或核验。

#### 4.4 法言法语映射（检索前必做）

用户的口语化命题词在法条和裁判文书里常常根本不出现。检索前必须现做一张映射，把"法条原文用语"和"裁判常用表述"都当作一等检索词：

| 口语词 | 法条原文用语（必查） | 裁判常用表述（必查） |
|------|--------------------|--------------------|
| 防沉迷 | 未要求未成年人以真实身份信息注册并登录网络游戏 | 实名认证/时间管理/消费管理 |
| 大数据杀熟 | 利用算法对交易条件实行不合理的差别待遇 | 差异化定价/价格歧视 |
| 自动续费 | 未以显著方式提请注意续费条款 | 默认勾选/不当扣费/格式条款 |

> 任何检索都必须先为本案命题词现做这张映射。

#### 4.5 多轮检索执行

- **目的驱动**：每轮必须有明确的、与前轮不同的检索角度
- **轮次随噪音自适应**：默认 2–4 轮，以"结果质量达标"为唯一停止条件
- **0 命中 = 放宽信号**：按以下顺序逐步放宽——拆掉最窄限定词→换法定/裁判表述→放宽地域/时间→换下一个检索角度
- **size 自适应**：默认 10；高噪音时提到 20–30
- **从案例中提取法条线索**：从已知案例的"本院认为"部分提取法条号，回法规库做精准检索

**轮间评估三问**：
1. 位阶覆盖：法源位阶各核心层级是否有明显空白？
2. 问题回答：找到的法规能否回答用户的核心法律问题？
3. 对抗覆盖：己方和对方的法条依据是否都有覆盖？

### 第 5 步 · 效力验证 + 适用性验证 + 过滤排序

#### 5.1 效力验证（强制步骤）

对每条法规确认其效力状态：

| 效力状态 | 含义 | 处理规则 |
|---------|------|---------|
| **现行有效** | 正常生效且未被修改或废止 | 可直接引用 |
| **已修改** | 已被修正/修订，有新版本 | 必须引用最新版本条文 |
| **部分失效** | 部分条款被废止或修改 | 逐条确认引用条款是否仍有效 |
| **已废止** | 已被明确废止 | 不得作为现行依据引用，标注替代法规 |
| **已过期** | 已超过有效期限 | 不得引用 |
| **尚未生效** | 已公布但未到生效日期 | 标注生效日期 |
| **效力存疑** | 效力状态无法确定 | 标注存疑原因，建议人工核实 |

**效力审查流程**：
1. 有效性审查：发布机关是否有立法权限？是否已被废止或修改？
2. 适用性审查：对人/对事/对地是否在适用范围内？
3. 时间审查：法律事实发生时间与法规生效/失效时间的关系
4. 位阶审查：确认法规效力层级，存在冲突进入冲突解决

**冲突解决**：

| 冲突情形 | 解决规则 | 法律依据 |
|---------|---------|---------|
| 不同位阶 | 上位法优先 | 《立法法》第87-89条 |
| 同位阶新法 vs 旧法 | 新法优先 | 《立法法》第92条 |
| 同位阶特别法 vs 一般法 | 特别法优先 | 《立法法》第92条 |
| 新的一般法 vs 旧的特别法 | 标注争议，建议人工判断 | 《立法法》第94条 |

#### 5.2 法条适用性验证

效力验证通过后，检验法条能否真正适用于本案事实：

1. **拆解法条构成要件** — 将法条拆分为若干构成要件
2. **事实逐项对照** — 将案件事实逐一对应到各构成要件
3. **缺口分析** — 全部满足则纳入输出；部分不明标注待确认；明确不满足则移除或标注"不适用"；边界情况保留并标注争议

#### 5.3 结果过滤与排序

- **相关性过滤**：只留与"争议焦点 + 法律关系"直接相关的
- **时效性过滤**：剔除/标注已废止失效
- **权威度排序**：法律→行政法规→部门规章/强制性标准→司法判例
- **质量反馈**：若结果过多/过少/相关性低，回到第 4 步调整检索式重新检索
- **核验反馈**：若核验工作台返回 `health.gates` 包含 `weak_or_unverified_ratio_too_high`、`association_rate_too_low` 或 `source_fulltext_required`，必须回到第 4 步动态检索策略，围绕队列中的法规名、条号、案号和原句关键词补检；补到全文后 capture/audit，再 repair-apply。

## 检索能力选择（内部规则，不向用户透传）

> **核心边界**：内部必须明确判断并调用专业法律数据库 / MCP / Skill；禁止的只是把“是否连接、是否安装、为何兜底”说给用户。不要因为用户可见输出要克制，就把内部执行路径写得模糊。

### 0. 静默前置判断（每次检索前必须做）

在开始 Web 检索前，先检查本轮会话可用工具/技能/连接器，按以下顺序选择。检查结果只进入执行决策，不进入用户回复、进度说明、报告标题或免责声明。

**专业库前置 Gate（硬规则）**：不得直接调用 WebSearch/WebFetch 作为首轮检索。必须先完成一次专业库发现与调用尝试：
- 先用工具发现能力按精确名称查找北大法宝工具（例如 `ToolSearch` 的 `tool_names`）：`mcp__pkulaw__mcp-law-search-service/search_article`、`mcp__pkulaw__mcp-law-search-service/get_article`、`mcp__pkulaw__mcp-law/get_law_list`、`mcp__pkulaw__mcp-case-search-service/search_case`、`mcp__pkulaw__mcp-case/get_case_list`。
- 若精确名称未返回，再用关键词发现：`北大法宝 pkulaw 法律检索 search_article get_article search_case get_law_list`、`华宇元典 yuandian 法律案例检索`。
- 只要发现上述专业库工具，就必须先用其完成至少一轮法规/案例检索；不得因为当前显式工具列表里没有预加载 schema 就判定不可用。
- 只有在专业库工具未发现、调用失败、无结果，或需要补充最新公开文件时，才允许进入官方网页/公开 Web 检索。

1. **北大法宝 / pkulaw（优先级最高）**
   - 若可用 `pkulaw` Skill，先加载并按其说明执行。
   - 若可用 `mcp__pkulaw*` 工具，法规检索优先使用：
     - `mcp__pkulaw__mcp-law-search-service/search_article`：语义检索相关法条，入参 `{ "text": "检索文本" }`。
     - `mcp__pkulaw__mcp-law-search-service/get_article`：按法规名和条号取原文，入参 `{ "title": "法规全称", "number": "第X条" }`。
     - `mcp__pkulaw__mcp-law/get_law_list`：按标题/正文关键词查法规列表，入参可用 `{ "title": "法规名关键词", "fulltext": "正文关键词" }`。
   - 类案检索优先使用：
     - `mcp__pkulaw__mcp-case-search-service/search_case`：语义检索司法案例，入参 `{ "text": "检索文本" }`。
     - `mcp__pkulaw__mcp-case/get_case_list`：按标题/正文关键词查案例列表，入参可用 `{ "title": "标题关键词", "fulltext": "正文关键词" }`。
2. **华宇元典 / yuandian-mcp**
   - 若工具列表或连接器中存在 `yuandian-mcp`、`mcp__yuandian*`、`mcp__yuandian-mcp*` 或同名法律检索 Skill，应优先用于案例、裁判规则、法规/司法文件补充检索。
   - 若具体工具名需发现，内部先做工具/技能发现，再按发现到的 schema 调用；不要向用户说明发现过程。
3. **其他用户配置的法律专业库、团队知识库或自有 Skill/MCP**
   - 例如团队法务知识库、法规库、案例库、合规规则库。只要能返回可核验正文或明确来源，即可作为正文依据。
4. **官方权威网页来源**
   - 如中国人大网、中国政府网、中央网信办、最高人民法院、最高人民检察院、国务院部门官网等。专业库不可用、专业库结果不足或需补充最新信息时使用。
5. **公开 Web 检索**
   - 用于发现法规/案例/处罚文号/政策文件线索，再尽量回到专业库、官方来源或完整可核验正文。

### 用户可见约束

- 不要向用户说明哪个数据库、MCP、Skill 已连接或未连接。
- 不要说“由于 XX 未接入，我改用 Web 搜索”。
- 不要把工具名称、检索轮次、关键词、连接状态写进正文、进度说明、报告标题或免责声明。
- 若确实无法取得可核验来源，只说明“未检索到可核验依据”，不要暴露内部工具状态。

### 调用原则

- **专业库可用时不得跳过**：法条/案例/效力状态/来源原文应优先从北大法宝、华宇元典等专业库或用户自有法律库取得；Web 只能作为补充或在专业库不可用/不足时兜底。若界面或连接器状态显示北大法宝已开启，而实际输出出现首轮“网页搜索”，视为流程错误，必须回到专业库前置 Gate。
- **法条核验类（A1/A2/A3）**：优先取法规原文、条号、公布/施行日期和效力状态，逐字核对。
- **事实关联/适用汇总（B1/B3）**：先圈定可能适用的法律文件，再取准条文原文和效力状态。
- **合规汇编（B2）**：跨效力层级穷尽检索法律、行政法规、部门规章、司法解释、规范性文件与监管规则。
- 任何正文依据都必须来自真实检索返回；模型先验只能用于生成检索方向，不能作为正文依据。

## 公开来源与专业来源隔离（强制）

> **报告正文每一条法条，都必须来自可核验来源的真实返回。公开网页取得的官方原文可以作为正文依据；普通网页线索须尽量回到官方原文、专业数据库或完整可核验文本后再引用。**

公开检索的内部用途：

1. **发现锚点**：从公开信息中提取企业名、案号、处罚文号、法条号、法规全称。
2. **回到权威文本**：用锚点检索官方原文、专业数据库详情或完整可核验文本。
3. **引用可核验文本**：取得完整条文、案例或监管文件正文后才写入报告。
4. **隔离未充分核验线索**：无法取得完整可核验文本的内容，不作为正文结论依据；如必须提示，仅在"建议人工复核事项"中抽象说明需要进一步核验，不暴露工具状态。

## 行政执法类检索的特殊路径

行政处罚/监管执法类案件须注意：

- **"非诉行政执行"是其主要存在形式**，须主动、优先、反复检索
- **case-type 词与命题特有词解耦**：把"非诉行政行为申请执行"等类型词单独与行业词交叉
- **关键认知**：大量行政处罚以缴罚款告终不进入诉讼，但这**不等于"库里没有对题类案"**——进入司法程序的主要是非诉执行

## 兜底与补充源

当多轮检索后结果仍不足时：

1. 检索权威微信公众号文章，从中提取法规线索，回法规库做精准检索
2. 补充法律信息源（会议纪要、部委规范性文件、行业标准、地方司法文件等），在输出中必须标注效力层级
3. 对所有补充源同样执行 `legal-verify capture`：Web、官方网页、MCP、用户自有 Skill 返回结果都按统一字段清洗为 `title/sourceType/provider/status/url/content/metadata`，段落化后再参与核验；不得让补充检索只存在于 agent 上下文。

## 关键约束

- **逐字核对**：凡引用法条原文，必须与官方原文、专业数据库版本或其他可核验文本逐字核对
- **时效优先**：任何条文都要带现行效力状态标注
- **不越权下结论**：本 skill 只负责"检索到准确依据"，最终格式化交给「场景化输出适配」skill
- **核验交接**：若任务单标记【核验工作台：必用】，检索结果必须已通过 `legal-verify capture` 或 `legal-verify persist` 保留来源原文和段落索引，并通过 `audit-sources` 无 blocker；不能只保留摘要、搜索 observation 或上下文记忆
- **重量档强制交接**：凡重量级任务，不得只输出摘要后结束

## References

- `references/retrieval-capability-chain.md` — 能力 2-6 详解
- `references/effectiveness-hierarchy.md` — 法律效力层级与资料类型规则