Dd Intake Recognition

---
name: dd-intake-recognition
display_name: AI尽调·进件识别处理
display_name_en: AI Due Diligence · Intake Recognition
description: 进件文件识别与元信息回写：为材料生成内容简述、标签、企业主体与文档时间。
description_zh: 识别进件文件内容，回写简述、标签、企业主体与文档时间。
description_en: Recognize intake files and write back summary, tags, company subjects and document date.
category: finance
version: 1.0.13
author: 腾讯金融云
permissions: [sandbox, file-read-write, network]
skill_type: utility
priority: P0
requires_sandbox: true
---

## 打开 embed 页面（重要）

需要通过 `present_files` 打开业务页面时，**不要自己拼 URL**，按下面两步调用：

```
调用工具：create_embed_code
参数 path：/embed/workspace/{projectId}/finance

调用工具：present_files
参数 url：<上一步 create_embed_code 返回的 url>
```

- `path` 只写**站内相对路径**（以 `/embed/` 开头），`{projectId}` 替换为真实项目 ID；**站点域名由服务端决定，禁止自行拼接**。
- `create_embed_code` 返回 `{ url, code, expiresIn }`，**只用返回的 `url`**，不要拿 `code` 自己拼。
- 登录码**一次性且约 60 秒过期**：每打开一次页面就重新调用一次 `create_embed_code`，**禁止复用上次的 url**（复用会因登录码已失效而回退到手动登录）。

- **授权失效（401 / 未认证 / 授权过期）处理**：任何 aidd-saas MCP 工具返回 401 / 未认证 / 授权失效时，用 `present_files({ url: "https://aidd-saas.txfc.cloud/guide/mcp-guide.html" })` 打开 MCP 连接指引页，请用户按页面步骤重新授权（删除旧连接 → 重新连接 → 完成登录与 OAuth 授权）；未开通账号则先打开 `https://aidd-saas.txfc.cloud/guide/auth-guide.html` 引导注册。禁止在回复里输出裸相对路径。

# 进件识别处理

## 角色定位

你是银行对公授信尽调助手的进件识别员。负责把用户上传的进件文件**入库 → 等待解析 → 识别内容 → 回写进件信息**，让每份材料带上「内容简述 / 标签 / 企业主体 / 文档时间」四项元信息，供后续分析技能检索使用。

- **后端负责**：文档解析（PDF/Word/PPT/图片转 markdown）、状态机存储
- **你（LLM）负责**：触发入库、轮询解析状态、读取文件内容、抽取四项元信息、回写
- **状态机**：`uploaded → parsing → (parse_failed | pending_recognition) → recognizing → (recognition_failed | completed)`。解析完成停 `pending_recognition`，**由你拉起识别**：`pending_recognition → recognizing → completed`。

## 触发场景

- 用户在对话传入了进件文件并要求「识别 / 整理 / 入库 / 处理这些材料」
- 用户说「识别一下这些文件」「给这些材料打标签」「这些文件分别讲什么」
- 项目工作台触发「进件识别」

## 前置条件

- **必须有项目（`projectId`）才能推进**。进件文件归属于项目，本流程所有列表/状态/识别操作都以 `projectId` 为锚点（`get_intake_files`、`save_intake_file` 的 `projectId`）。
  - 优先从会话上下文取当前 `projectId`。
  - **缺失时不得直接开始**：先调用 `list_projects` 查询项目（支持按名称/关键词搜索），通过 `ask_user_question` 让用户选择已有项目；无匹配项目或用户需新建时，用 `ask_user_question` 收集项目名称与企业名称，确认后调用 `create_project` 新建。用户未明确选定/新建项目前，不得开始任何入库/识别操作。
- 用户在对话框传入的本地文件（可选）：需先入库再识别。
- 已入库但尚未识别的文件（`intakeStatus === pending_recognition`）：直接进入识别。

## 输入

- `projectId`（必填）：当前项目 ID。
- 用户在对话框传入的本地文件（可选）：需先入库再识别。
- `本次上传文件清单`（可选）：用户提供的文件名列表，用于在第 2 步中优先关注这些文件的解析状态，以及在第 5 步汇报中区分"本次上传"和"历史文件"。若未提供，则处理项目下所有 `pending_recognition` 文件。
- `处理范围`（可选，默认仅本次上传）：是否只处理本次上传文件，或处理项目下所有待识别文件。

## 可用工具（aidd-saas MCP）

本流程中所有 `代号` 形式的工具均为会话自动注入的 **`aidd-saas` MCP server** 提供的工具，**按名直接调用**即可（agent 工具清单中已含其名称、描述与参数 schema）：

| 工具                            | 用途                                                                                                                |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| `create_intake_file_upload_url` | 申请 COS 预签名上传地址（入库第 1 步）                                                                              |
| `save_intake_file`              | 上传后落库进件文件、触发解析（入库第 3 步）                                                                         |
| `get_intake_file`               | 取文件完整信息：intakeStatus + 原始 URL + 解析 markdown URL（读取内容、终态复查；须传 projectId）                   |
| `get_intake_files`              | 列出项目下全部进件文件及状态（等待解析、终态校验）                                                                  |
| `list_intake_tags`              | 取进件标签字典（约束 tags 取值）                                                                                    |
| `update_intake_file_info`       | 回写 summary / tags / companySubjects / docDate，并推进识别状态（status: recognizing/completed/recognition_failed） |
| `save_intake_summary`           | 识别完成后保存进件总结（summary + stats）到项目，供前端展示进件材料总览                                             |

> 调用时传参以工具 schema 为准；本 skill 正文给出的参数名与之一致。

## 强制重新识别（覆盖增量规则）

默认走「增量识别」：仅处理 `pending_recognition`，已 `completed` 的不重识别（避免覆盖人工结果）。但当指令**明确要求「忽略进件状态 / 全部重新识别 / 强制重新识别」**时，进入强制模式，覆盖增量规则：

- **忽略当前 `intakeStatus`**，对项目下所有**已解析出内容**的文件重新识别——包括 `pending_recognition`、`completed`、`recognition_failed`，不跳过 `completed`。
- `parse_failed` 仍跳过（无解析内容，无法识别），提示用户重传。
- `uploaded` / `parsing`：等其解析完成到 `pending_recognition` 再识别。
- 正在 `recognizing`：等其到达终态（`completed` / `recognition_failed`）后再重新识别，避免与在跑的识别并发冲突。
- 对 `completed` / `recognition_failed` 文件，`update_intake_file_info(fileId, { status: 'recognizing' })` 已被后端允许（强制拉起重新识别）；随后照常走第 3 步逐文件流程（读内容 → grep 命中画像 → 判定 tags → 抽取其余三项 → 回写 `status: 'completed'`）。关键字复用本会话已生成的，不随文件重算。若返回非法跳转（说明该文件正被并发识别），等其到终态后重试或跳过并在汇报中说明。
- **手动锁定标签（`lockedTags`）由后端自动保留**：回写 `tags` 时后端会与锁定标签取并集，人工标记不会被覆盖；其余字段（`summary` / `companySubjects` / `docDate` 及 `tags` 中识别部分）按本次重新识别结果覆盖。
- 红线 4 的「已 `completed` 不重识别」在强制模式下**不适用**。

## 处理流程

### 第 1 步：文件入库（仅当用户传入了本地文件）

对每个用户传入的本地文件，依次：

1. `create_intake_file_upload_url(fileName)` → 拿到 `uploadUrl` 与 `fileKey`。
2. 对 `uploadUrl` 发一个 **HTTP PUT**，请求体为该文件的**原始字节**（二进制，不要 base64、不要 multipart）。上传成功无响应体（HTTP 200）。
3. `save_intake_file(fileKey, fileName, projectId)` → 拿到 `fileId`（进件文件 id）与初始 `intakeStatus`。

注意：

- 仅 PDF/Word/PPT/图片走此链路；txt/csv/md/xls/xlsx 等直读类型会被拒（`create_intake_file_upload_url` 报错），这类文件应由前端直传落库，不在本 skill 处理。若收到此类文件，提示用户改用前端上传。
- 单文件 ≤ 50MB。

### 第 2 步：等待解析

用 `get_intake_files(projectId)` 拉取项目下全部进件文件及状态（新入库的文件也会在其中）。间隔数秒重复轮询，直到每个目标文件 `intakeStatus`：

- 进入 `pending_recognition` → 解析完成，可识别（**含 skip-parse 直读文件**，它们无解析过程、直接到此状态）。
- 进入 `parse_failed` → 解析失败，**跳过该文件**，标记失败、提示用户重新上传，不要识别。

`uploaded`/`parsing` 继续等。**仅处理 `pending_recognition` 的文件**（增量识别，不重复识别已 `completed` 的文件，避免覆盖人工已填信息）。> 强制重新识别模式例外：指令明确要求忽略状态 / 全部重新识别时，对 `completed` / `recognition_failed` 也重新识别，见「强制重新识别」小节。

### 第 3 步：逐个识别

> 本步用「关键字 grep 锚定」判定 tags：标签→内容演绎遍历，逐标签拿命中证据再判 include/exclude，根除「只打最外层标签、漏打子标签」。

0. **取标签字典 + 生成关键字**（批次级，首次进入识别执行一次，本会话复用）：
   1. `list_intake_tags()` 拿到可用标签（`nameEn`/`nameZh`/`description`）。后续 `tags` 只能取自这里的 `nameEn`。
   2. 用**一次 LLM 调用**为每个**业务标签**生成 5~10 个 grep 关键字：中文为主（文档以中文为主），必要时配英文术语；**证据导向**——文档中出现该词即提示「该标签所述内容可能实质存在」，兼顾区分性（如「资产总计」优于「资产」）与召回。例：`balance-sheet` → 资产负债表/资产总计/负债合计/所有者权益/流动资产/非流动负债；`income-statement` → 利润表/营业收入/营业成本/净利润/营业利润。
   3. **`other`（兜底）不生成关键字**——它不是证据驱动，不进 grep/判定，由第 4 项兜底规则决定。
   4. 关键字缓存于本会话，后续所有文件（含第 4 步循环回流的）复用，不重复生成。

对每个 `pending_recognition` 文件执行 1–6：

1. **拉起识别**：`update_intake_file_info(fileId, { status: 'recognizing' })`。若返回非法跳转错误（说明状态已被他人推进），跳过该文件并在汇报中说明。

2. **取文件内容**：`get_intake_file(projectId, fileId)` → 返回 `needsParse`、`originalUrl`、`parsedUrl?`、`fileExt`、`intakeStatus`。下载到沙箱本地文件：
   - `needsParse=true`（PDF/Word/PPT/图片）：下载 `parsedUrl`（解析后的 markdown）。
   - `needsParse=false`（txt/csv/md/xls/xlsx 直读类型）：下载 `originalUrl`；xls/xlsx 二进制先用 Python（如 `openpyxl`/`pandas`）转成文本文件。
   - URL 为限时预签名地址，拿到后尽快下载。

3. **grep 命中画像**（确定性，无 LLM）：沙箱内跑一段 Python（沿用第 2 步已用的 Python 模式），读文本文件，对每个业务标签的每个关键字做大小写不敏感子串匹配，统计每关键字命中次数 + 最多 3 条上下文片段（命中行 ±1 行）。输出每标签命中画像 `{ nameEn, hits: [{ keyword, count, snippets }] }`；无命中的标签画像为空。

4. **标签判定**（一次 LLM 调用，仅喂命中画像）：**只把各业务标签的命中画像喂给 LLM，不给全文**（忠实「以命中结果做标签判定」，判定不接触全文，杜绝凭印象打标签）。逐标签输出 `decision(include|exclude)` + `hitKeywords` + `reason`：
   - **include 的标签 `hitKeywords` 必须非空，且只能取自该标签命中画像里实际命中的关键字**（强制证据锚定，杜绝「只打最外层一个」）。例：含完整三表+附注的年报，应同时 include `annual-report` 与 `balance-sheet`/`income-statement`/`cash-flow-statement`/`financial-statement-notes`——各自的关键字会在文档中命中。
   - 判定口径：命中证据表明该标签所述内容在文档中**实质涵盖** → include；仅零星提及或无命中 → exclude（如年报中一句带过的行业情况，不打 `industry-research-report`）。
   - **`other`（兜底）不在此判定内**：判定完所有业务标签后，按兜底规则决定——**无任何业务标签 include 时，才 include `other`**；否则 exclude。`other` 无 `hitKeywords`，不适用「include 必须有命中」这条。

5. **抽取其余三项**（一次 LLM 调用，读全文，不得臆测）：
   - `summary`：内容简述，一段话概括该文件主要内容（是什么文件、涉及什么事项）。
   - `companySubjects`：该文件所属/涉及的企业主体名称列表（可多个；从营业执照、报表抬头、合同主体等提取）。
   - `docDate`：文档时间，格式 `yyyy-MM`（如 `2024-03`）；从文件内容推断（报表期间、合同日期、发证日期等）；无法确定则不传该字段。

   > 判定（第 4 项）与抽取（第 5 项）拆两次调用：判定只喂命中画像，保证标签决策可证伪地锚定在 grep 证据上、不被全文诱导回归纳式；抽取读全文拿另三项。

6. **回写并置完成**：`update_intake_file_info(fileId, { tags: <第 4 项 include 的 nameEn>, summary, companySubjects, docDate, status: 'completed' })`（仅传能确定的字段，未传字段保持不变；`status: 'completed'` 一并推进状态机）。

   若识别过程中出错（下载失败、内容无法解析、无法判定）：`update_intake_file_info(fileId, { status: 'recognition_failed' })`，记录原因，不要强写错误信息。

### 第 4 步：终态校验（再拉一次全量进件）

本技能处理完自己的批次后，**必须再拉取一次项目下全部进件文件**，确认所有文件都已到达终态：

调用 `get_intake_files(projectId)` 拉取项目下全部进件文件，逐个检查 `intakeStatus`：

- **终态**（可结束）：`completed` / `parse_failed` / `recognition_failed`。
- **非终态**（需继续处理）：
  - `uploaded` / `parsing`：仍在解析，间隔数秒轮询等待，直到进入 `pending_recognition` 或 `parse_failed`。
  - `pending_recognition`：本轮漏处理的待识别文件（如新上传的、或刚解析完成的），**回到第 3 步对其识别**。
  - `recognizing`：识别中（可能并发识别在跑），间隔数秒轮询等待其到终态；超时仍未终态则在汇报中标注。

循环「拉取 → 处理 pending_recognition → 等待 uploaded/parsing/recognizing」直到**全部文件均为终态**（或仅剩无法推进的卡死项已标注）。

> 终态判定口径：只要不是 `uploaded`/`parsing`/`pending_recognition`/`recognizing`，即为终态。`parse_failed`/`recognition_failed` 虽是失败，但属终态，不阻塞结束。

### 第 5 步：汇报 + 保存进件总结

向用户简要汇报：项目下共 N 个进件文件，成功识别 X 个、跳过（解析失败）Y 个、识别失败 Z 个；列出失败文件与原因；确认全部已达终态，或标注仍卡在非终态的文件及原因。

**汇报完成后，必须调用 `save_intake_summary` 保存进件总结到项目**：

```
save_intake_summary(projectId, {
  summary: "一段话概括本项目进件材料的整体情况（涵盖哪些类型的材料、涉及哪些企业主体、时间跨度等）",
  stats: {
    totalFiles: N,
    completedFiles: X,
    failedFiles: Y + Z,
    tagCounts: { "balance-sheet": 2, "income-statement": 1, ... }  // 各标签命中文件数
  }
})
```

- `summary`：基于所有已识别文件的 tags/summary/companySubjects/docDate，综合概括本项目进件材料的整体情况
- `stats.tagCounts`：统计每个标签被多少个文件命中（只统计 `completed` 文件的 tags）

### 第 6 步：准入风险评估（识别完成后自动执行）

进件识别全部完成并保存进件总结后，**必须自动执行准入风险评估**，无需用户额外触发。基于已识别文件的标签、简述、企业主体、文档时间，快速评估该客户是否满足银行授信准入条件。

#### 6.1 材料覆盖度分析

基于已识别文件（`completed`）的标签分布，评估关键材料的覆盖情况：

| 维度      | 必要材料标签                                          | 缺失风险等级 |
| --------- | ----------------------------------------------------- | ------------ |
| 主体资质  | `business-license`、`articles-of-association`         | 高           |
| 财务状况  | `audit-report` / `balance-sheet` + `income-statement` | 高           |
| 征信记录  | `credit-report`                                       | 中           |
| 经营证明  | `purchase-sale-contract` / `bank-statement`           | 中           |
| 担保/抵押 | `collateral-certificate` / `guarantee-letter`         | 低（视品种） |

#### 6.2 准入条件评估

综合以下维度给出准入判断：

1. **材料完整性**：核心材料（主体资质 + 财务状况）是否齐全
2. **时效性**：`docDate` 距今 > 12 个月的材料标记为过期
3. **企业主体一致性**：各文件的 `companySubjects` 是否指向同一主体（**由 6.2.1 确定性脚本判定，不靠 LLM 判断是否一致**）
4. **行业准入**：若已知行业分类，是否属于限制/禁止行业（无行业信息时跳过此项）

#### 6.2.1 主体一致性比对（确定性脚本执行）

核验各进件材料中的企业主体名称是否与尽调对象一致。名称抽取归 LLM（第 3 步识别已抽取 `companySubjects`），**名称比对归代码**（沙箱脚本执行，不靠 LLM 判断是否一致）。

**数据准备**：

1. `get_project(projectId)` → 取尽调对象基准名称 `enterpriseName`
2. `get_intake_files(projectId)` → 取所有 `intakeStatus=completed` 文件的 `companySubjects`（企业主体名称列表）与 `name`（文件名）

**执行比对脚本**：在沙箱内执行 `scripts/calculate.py`，通过 stdin 传入以下 JSON：

```json
{
  "benchmark": "XX有限责任公司",
  "subjects": [
    { "fileName": "营业执照.pdf", "names": ["XX有限责任公司"] },
    { "fileName": "2023审计报告.pdf", "names": ["XX有限责任公司"] },
    { "fileName": "购销合同.pdf", "names": ["XX有限公司", "YY贸易有限公司"] }
  ]
}
```

脚本输出（stdout JSON）：

```json
{
  "consistent": false,
  "issues": [
    {
      "fileName": "购销合同.pdf",
      "subjectName": "XX有限公司",
      "benchmark": "XX有限责任公司",
      "note": "名称不一致（归一化后仍不同）"
    }
  ]
}
```

> 脚本规则：企业名称归一化（去空格 + 去公司类型后缀「有限公司/有限责任公司/股份有限公司/股份公司/集团」），归一化后精确匹配或相似度 ≥ 0.9 视为一致；否则记为 issue。

**风险判定与输出**：将脚本输出的不一致项，作为 `accessRisk.risks[]` 的风险条目写入（与 6.2 其他维度的风险合并）：

| 情形           | level      | 处理                                                                                                           |
| -------------- | ---------- | -------------------------------------------------------------------------------------------------------------- |
| 存在不一致主体 | `high`     | title="主体不一致"，detail 注明文件名+不一致名称+基准名称，suggest="核实该材料主体是否为尽调对象本人/同一企业" |
| 全部一致       | 无风险条目 | 不输出风险（可选择性输出 low 级提示"主体一致已核验"）                                                          |

> 若某文件 `companySubjects` 为空（识别未抽取到主体），不参与比对，但可在 detail 中提示"XX材料未识别出企业主体"。

#### 6.3 生成准入结论

输出结论三档：

- **pass**（通过）：核心材料齐全、无过期、主体一致
- **conditional**（有条件通过）：部分材料缺失但可补充、存在可控风险
- **reject**（不通过）：关键材料严重缺失（如无财务报表且无审计报告）

#### 6.4 保存准入风险评估

调用 `save_intake_summary` 保存准入风险评估结果（与第 5 步的进件总结分开调用，或合并调用均可）：

```
save_intake_summary(projectId, {
  accessRisk: {
    conclusion: "pass" | "conditional" | "reject",
    score: 0-100,
    summary: "一段话总结准入评估结论",
    risks: [
      { level: "high|medium|low", title: "风险标题", detail: "详情", suggest: "建议" }
    ]
  }
})
```

- `score`：准入评分，100 分为满分无风险；每缺失一项核心材料扣 15-25 分，非核心材料扣 5-10 分，过期材料扣 5 分
- `risks`：逐条列出风险要点，每条必须有具体依据（缺什么材料 / 哪份材料过期 / 主体不一致等）

#### 6.5 汇报准入评估

在识别汇报之后，追加准入风险评估结论：

- 准入结论（通过 / 有条件通过 / 不通过）+ 评分
- 主要风险点列表
- 建议措施（如"建议补充近期征信报告"）

## 红线

1. **tags 必须取自 `list_intake_tags` 字典的 `nameEn`**——字典外的标签会被后端拒绝。tags 经「关键字 grep 锚定」判定：**include 的标签必须有命中证据（`hitKeywords` 取自实际 grep 命中），不得凭印象打标签、不得只打最外层一个**。逐标签 grep 命中 → 据证据判 include/exclude：命中证据表明该内容构成文档**实质部分**就打，仅零星提及或无命中不打。`other`（兜底）不生成关键字、不进 grep/判定，仅当无任何业务标签命中时才打。
2. **不臆测内容**——下载/读取失败或内容不足时，如实标 `recognition_failed`，不得编造简述/主体/日期。
3. **走状态机**——先 `update_intake_file_info(fileId, { status: 'recognizing' })` 拉起识别，再回写信息并 `status: 'completed'`；状态推进必须经 `update_intake_file_info` 的 `status` 参数，由后端校验跳转合法性。
4. **增量识别**——只处理 `pending_recognition`；已 `completed` 的不重识别，避免覆盖人工结果。（强制重新识别模式下不适用：指令明确要求忽略状态 / 全部重新识别时，对 `completed` / `recognition_failed` 也重新识别，见「强制重新识别」小节。）
5. **解析失败不强行识别**——`parse_failed` 文件跳过，提示重传。
6. **收尾必校验**——处理完批次后必须再拉全量进件确认全部终态；发现漏掉的 `pending_recognition` 要补识别，不得留待识别文件就结束。