| name | regulatory-incoming-letter |
| description | 处理监管下发函件（行政处罚通知 / 责令整改 / 监管谈话 / 程序性通知 / 专项自查工作函 / 监管问询）的全流程：录入 + 6 分法自动归类 + 任务派发 + 进度跟踪 + 上报材料汇总。本土化版的核心亮点 —— 原版 regulatory-legal 没有这条主线。用户说"我们收到 [监管单位] 一份 [函件类型]"、"监管下发了"、"工作函"、"自查通知"、"约谈"、"监管问询"、"警示函"、"行政处罚决定书"，或上传函件 PDF / 扫描件时使用。 |
| argument-hint | [函件文件路径 或 粘贴函件文本] |
/incoming-letter
- 读
$LEGAL_AGENT_PROFILE_HOME/regulatory-legal/profile.md → 公司画像、escalation_path、归口部门联系人
- 用下面的 7 阶段工作流
- 录入（OCR + 字段抽取）→ 自动归类（6 分法）→ 按类处置 → 任务派发 → 进度跟踪 → 上报材料汇总 → 闭环
- 关键截止日自动锁到监管要求回复期前的内部缓冲日期（默认 5 个工作日）
事项上下文
事项上下文：核查实务层级 profile.md 中 ## 事项工作区。如果 启用 是 ✗（企业内部法务用户默认），跳过本段 —— 技能用实务层级上下文，事项机制不可见。如果启用且没有当前事项，问："这是哪个事项？跑 regulatory-matter-workspace switch <slug> 或说切到实务层级。"
对监管下发函的特殊处理：每一份独立的监管函件都可以视作一个独立事项（特别是涉及处罚 / 约谈类高风险函件）。建议在私人执业场景下为重要函件单独建事项，企业内部法务场景下走实务层级 + 内规差异台账（gap-tracker.yaml）跟踪。
用途
中国企业内部法务最高频的工作是响应监管下发的函件 —— 这与原版的"主动监控"工作流方向相反，是本土化版的核心增量。本技能处理：
- 接收：纸质函件扫描、邮件附件、监管平台推送（如金管总局检查通报系统、网信办约谈通知等）
- 理解：抽取关键字段（来文单位、文号、要求事项、回复期限）
- 分类：按 6 分法判定函件类型，决定处置路径
- 派发：根据要求事项拆解为内部整改任务（
inspection-task），按归口部门派到具体负责人
- 跟踪：截止日三档预警（30 / 15 / 5 天，反映监管截止日的硬刚性）
- 上报：到期前自动汇总各部门提交的整改材料，生成上报草稿
- 闭环：等监管回函（通过
regulatory-reg-feed-watcher（监管动态监测）或人工录入），决定是否结案
与 regulatory-reg-feed-watcher（监管动态监测）的区别：
- 监管动态监测：主动监控 —— 抓取监管公开发布的规则、处罚通报、答记者问等
- 监管来函处置：被动响应 —— 处理监管直接发给本公司的函件（有明确受文单位 = 本公司）
监管动态监测可能会捕获到"金管总局自查工作函"等普遍性通知，如本公司也是受文单位，应转入本技能（监管来函处置）流程做完整处置。
第 1 步：录入与字段抽取
1.1 接收来源
支持三种入口：
- 文件路径：用户上传 PDF / 图片扫描件 / Word 等到工作目录或文档存储
- 粘贴文本：函件正文已 OCR / 转写好的纯文本
- 手工字段输入：监管平台推送的结构化数据，用户手工填关键字段
1.2 字段抽取（调用能力 document.extract_fields）
调用 document.extract_fields 能力抽取以下字段（必填项 ✱）：
| 字段 | 必填 | 说明 |
|---|
来文单位 ✱ | 是 | 具体监管机构名称（如"国家金融监督管理总局上海监管局"、"国家网信办网络数据管理局"），含层级（中央 / 省 / 市） |
文号 ✱ | 是 | 格式如 沪金监函〔2026〕XX 号 —— 关键追溯标识 |
收文日期 ✱ | 是 | 公司实际收到的日期（不是函件落款日期），可能差几天 |
落款日期 | 否 | 监管在函件上的落款日期 |
函件名称 ✱ | 是 | 如《关于开展消费金融业务合规自查的工作函》 |
函件类型 (初判) | 否 | 字段抽取大模型的初步判断，第 2 步会用 6 分法重新核定 |
受文单位 ✱ | 是 | 必须是本公司全称（如果不是 → 函件转错，确认后退回） |
抄送范围 | 否 | 其他抄送方（如"抄送：上海地方金融监管局") |
要求事项 ✱ | 是 | 列表，从函件正文抽取每条具体要求（如"自查放贷利率合规性、自查营销话术合规性、提交自查报告"等） |
回复期限 ✱ | 是 | 监管要求公司提交回复 / 整改报告的最晚日期。如函件用"X 日内"等相对表述，结合收文日期计算 |
是否要求书面回复 | 否 | 如"以书面形式提交"、"提交整改报告" |
是否要求面谈 / 到场 | 否 | 如"派分管负责人参加 X 月 X 日座谈" |
是否含听证 / 申辩告知 | 否 | 如有 → 触发第 4 类程序性通知 的紧急路径 |
提交方式 | 否 | 如"密码邮件至 xxx@xxx.gov.cn"、"现场提交"、"挂号信" |
执法人员 / 联系人 | 否 | 函件中署名的执法人员或具体联系人电话 |
附件清单 | 否 | 函件附带的清单、自查表等 |
抽取后必须给用户人工核对，特别是 ✱ 必填字段。在大模型抽取结果旁标 [抽取自第 X 段] 让用户能溯源核对。
1.3 抽取结果保存
抽取后落地为结构化 YAML 文件到 $LEGAL_AGENT_PROFILE_HOME/regulatory-legal/incoming-letters/<letter-id>/letter.yaml，附原始扫描件 / 文本副本到同目录。
letter-id 命名建议：YYYY-MM-DD-<监管缩写>-<文号尾号>，例如 2026-05-25-金管沪-XX。
第 2 步：自动归类（6 分法 + 子类）
按以下决策树自动归类（详细分类规则见 references/letter-classification-rules.md）：
是否含"作出行政处罚决定 / 罚款 / 没收 / 暂停业务 / 吊销许可"等表述？
├── 是 → 第 1 类 行政处罚类
└── 否
│
是否含"事先告知 / 听证通知 / 陈述申辩告知"等表述？
├── 是 → 第 4 类 程序性通知类（行政处罚法第 44-47 条）
└── 否
│
是否含"约谈 / 监管谈话 / 派负责人到场说明"等表述？
├── 是 → 第 3 类 监管谈话类
└── 否
│
是否含"现场检查 / 现场检查意见书"等表述？
├── 是 → 第 2 类（子类 2b）行政监管措施—现场检查反馈
└── 否
│
是否含"自查 / 专项整改 / 排查"等表述？
├── 是 → 第 5 类 专项自查 / 工作函类
└── 否
│
是否含"说明情况 / 反馈材料 / 提供资料"等表述？
├── 是 → 第 6 类 监管问询类
└── 否（默认）→ 第 2 类（子类 2a）行政监管措施—责令整改
归类后输出给用户人工确认（除非置信度 > 0.95）：
"根据要求事项和函件语言，初判为第 X 类（[类别名]）。处置路径：[简短说明]。
确认归类后我会触发对应处置流程。如归错，请告诉我正确类别。"
第 3 步：按类别选择处置路径
第 1 类：行政处罚类
触发动作：
-
法定时效核查（最高优先级，当天完成）：
- 行政复议申请期限：60 日（《行政复议法》第 9 条），自收到决定书之日起算
- 行政诉讼期限：6 个月（《行政诉讼法》第 46 条），自知道或者应当知道作出行政行为之日起算
- 特别注意：证监会等特别监管领域可能有更短的复议期，需对照具体法规
- 在
letter.yaml 中记录两个法定截止日：reconsider_deadline、litigation_deadline
-
法务总监 + 首席合规官紧急会签（escalation_path.重大业务影响决策）：
- 是否接受处罚？
- 是否申请行政复议？
- 是否提起行政诉讼？
- 是否进行公司内部责任追究？
-
内部整改任务派发：将处罚决定中"责令整改"部分拆解为 inspection-task
-
舆情准备：如处罚涉及公众披露（上市公司、消费者保护类），同步触发产品 / 公关部门信息披露评估
关键风险点：处罚事实的认定 + 处罚程序的合法性 + 是否有从轻 / 从重 / 不予处罚情节未被采纳 —— 这些是后续复议 / 诉讼的核心争点。
第 2 类：行政监管措施类（子类 2a 责令整改 / 2b 现场检查反馈）
触发动作：
-
时效核查：
- 多数监管措施类决定也可申请行政复议 / 诉讼，但时效与处罚相同（60 日 / 6 月）
- 警示函 / 监管意见书在部分领域被认为"不可诉"（如证券公司收到证监会警示函），但 2020 年以来司法实务有变化，建议保留复议 / 诉讼路径
-
限期整改 → 拆解为 inspection-task：
- 子类 2a（责令整改）：整改任务通常较具体，按业务部门派单
- 子类 2b（现场检查反馈）：常伴检查发现的问题清单，需逐项拆解 + 内部根因分析
-
整改报告（如要求书面回复）：
- 收文 + 缓冲 30/15/5 天三档预警
- 到期前 X 天自动汇总各部门提交材料 → 上报草稿
第 3 类：监管谈话类
触发动作：
-
派人到场的准备：
- 谁去？默认派"业务对应分管 + 法务"组合，按
escalation_path.重大业务影响决策 决定具体人选
- 准备材料：本次涉及业务的近期数据、合规自查结论、已经采取的措施
-
谈话纪要的处置：
- 谈话结束后几天内通常会有"约谈通报"或"谈话纪要"发回
- 如要求出具书面承诺 / 整改计划：拆解为
inspection-task
-
是否触发行政复议 / 诉讼：一般认为单独的监管谈话不可诉（不直接产生权利义务变动），但约谈通报如含"责令整改"等内容，按第 2 类处理
第 4 类：程序性通知类（新增，原 6 分法没有）
触发动作 —— 这是法定程序，时效极短，错过有不利后果：
-
听证申请期限：收到事先告知书之日起 3 个工作日内（行政处罚法第 47 条）。当天计算，预留 1 个工作日内部决策缓冲。
-
陈述申辩准备：
- 行政处罚法第 44 条：拟作出行政处罚决定前，应告知拟作出的内容、依据、事实
- 陈述申辩材料应当指向：事实认定有误 / 法律适用不当 / 程序违法 / 从轻减轻情节
-
escalation_path.重大业务影响决策 紧急触发：
- 是否申请听证？
- 是否提交陈述申辩？
- 谁去陈述 / 听证？
-
法务 + 外聘律师协同：建议立即启动外聘律师介入（特别是听证）
第 5 类：专项自查 / 工作函类
触发动作：
-
要求事项拆解为 inspection-task：
- 14 条自查事项 → 14 个
inspection-task
- 每条任务自动匹配归口部门（按
policy_owner 索引）
- 整改负责人按业务部门指派（
task_owner）
-
进度跟踪：30 / 15 / 5 天三档预警
-
上报材料汇总（到期前 X 天）：
- 自动收集各部门提交的自查材料
- 按监管要求格式生成上报草稿
- 走法务总监 + 首席合规官会签后由法务联系人提交
第 6 类：监管问询类
触发动作：
-
判断问询性质：
- 普通问询函（如证监会问询）—— 要求公司说明情况、提供材料
- 关注函（深沪交易所对上市公司）—— 监管关注但不必然导致后续动作
- 信息核实函（如反洗钱可疑交易核实）—— 涉具体客户 / 业务的事实问询
-
回函起草：
- 按监管问询事项逐条回应
- 涉具体客户 / 业务数据需脱敏处理
- 不要主动披露问询范围外的事项
-
是否触发后续监管动作：问询本身一般不直接产生权利义务，但回函内容会被监管援引，故回函质量决定后续走向
第 4 步：任务派发（拆解为 inspection-task）
将函件要求事项拆解为 N 条 inspection-task 类型的整改事项，写入 $LEGAL_AGENT_PROFILE_HOME/regulatory-legal/gap-tracker.yaml：
gaps:
- id: INS-001
requirement: "自查放贷利率合规性 —— 是否符合金管总局新规第 X 条"
regulation: "金管总局《关于开展消费金融业务合规自查的工作函》 沪金监函〔2026〕XX 号"
policy_affected: "消费金融业务合规手册"
gap_type: "inspection-task"
inspection_letter_id: "2026-05-25-金管沪-XX"
inspection_category: "第 5 类 专项自查"
policy_owner:
name: "王琳"
department: "法务部"
dm_id: "feishu_xxx"
task_owner:
name: "张总"
department: "业务一部"
dm_id: "feishu_yyy"
opened: 2026-05-25
due: 2026-06-19
regulatory_deadline: 2026-06-24
status: "open"
status_verified: true
notified_task_owner: false
notified_policy_owner: false
reminders_sent: []
submission_required: true
submission_received: false
submission_received_date: ""
submission_content: ""
source_tags:
- "[监管下发函]"
- "[金管总局公开栏目]"
派发后逐条预审给法务联系人审核后才发 DM（继承 regulatory-gap-surfacer（内规差异呈现）的逐条预审 + 显式批准规则）。
第 5 步：进度跟踪
复用 regulatory-gap-surfacer（内规差异呈现）的提醒机制，但 inspection-task 用三档预警（比常规内规差异更紧）：
| 距离监管截止日 | 提醒动作 |
|---|
| 30 天 | 一次预提醒给 task_owner（"监管要求 30 天后提交，开始动手"） |
| 15 天 | 二次提醒，抄送 policy_owner |
| 5 天 | 三次紧急提醒，task_owner + policy_owner + escalation_path.重大业务影响决策 |
| 已超期（监管截止日已过且未上报） | 🔴 红色告警，立即上报 escalation_path.最终决策 + 法务总监紧急会议 |
提醒发送严格走 notification.preview_and_send 能力 + 逐条预审。
第 6 步：上报材料汇总
监管截止日前 X 个工作日（默认 5 天，可在冷启动访谈中配置），自动汇总：
6.1 收集
- 遍历该
inspection_letter_id 下的所有 inspection-task
- 收集每条任务的
submission_content、submission_received_date
- 标识缺失项（仍未收到反馈的任务）
6.2 生成上报草稿
按 references/report-material-template.md（上报材料模板）中的格式生成草稿：
# [函件名称] 整改 / 自查报告
致：[来文单位]
关于：[函件名称]
文号引用：[文号]
公司名称：[本公司]
---
## 一、回应概述
本公司收到贵 [局 / 委] 于 [日期] 下发的 [函件名称]（[文号]），高度重视，
立即组织相关部门开展自查 / 整改工作。现将工作情况报告如下：
## 二、整改 / 自查事项明细
### 事项 1：[要求事项 1]
**整改情况**：
[业务部门提交的内容]
**已完成 / 进行中 / 风险接受**：[状态]
**支持材料**：[附件清单]
[逐条罗列每个 `inspection-task`]
## 三、整体结论
[整改 / 自查整体结论。如有未完成项需诚实说明，给出后续时间表]
## 四、本公司承诺
[本公司就本次自查 / 整改作出的承诺]
---
附件：
- 附件 1：[支持材料 1]
- 附件 2：[支持材料 2]
- ...
公司盖章：[公章位置]
签发人：[签字]
日期：[日期]
联系人：[姓名 + 电话]
6.3 走会签
按 escalation_path：
- 法务负责人初审
- 首席合规官（CCO）复审
- 总经理 / 法定代表人签字（如要求公章 + 法人签字）
- 法务联系人提交
6.4 提交追踪
提交后在 letter.yaml 中记录 submission_date、submission_method（密码邮件 / 现场 / 挂号信）、submission_receipt（监管收讫回执）。
第 7 步：闭环
等监管回函：
- 提交后通常 7-30 天内收到回函（监管确认收讫 / 提补充要求 / 通过验收 / 启动下一轮）
- 通过
regulatory-reg-feed-watcher（监管动态监测）监控相关监管栏目，或通过邮箱 / 收发室人工录入回函
- 回函如要求"补充材料"或"再次自查" → 进入新一轮监管来函处置流程（同一
letter-id 下加 round: 2）
- 回函如确认"通过验收 / 不再追究" → 标
letter.yaml 的 status: closed + 同步关闭关联的 inspection-task
长期未收到回函（>60 天）：
- 标
status: 待回函
- 不自动关闭，但移出活跃台账显示
- 重要函件（处罚类 / 重大整改类）保持关注，重要节点（如周年）触发"回函未到提醒"
重大动作确认环节（按函件类别分档触发）
| 当前动作 | 触发 escalation_path 字段 | 提示内容 |
|---|
| 第 1 类 行政处罚：决定是否复议 / 诉讼 | 重大业务影响决策 + 法务总监 + 首席合规官联签 | "本动作涉及处罚决定的法定救济。业务规范显示需要 [角色] 拍板。是否已上报？" |
| 第 4 类 程序性通知：决定是否申请听证 / 陈述申辩 | 重大业务影响决策（紧急） | "听证申请期限 3 个工作日。业务规范显示需要 [角色] 立即拍板。" |
| 第 1 / 2 / 3 / 5 / 6 类：提交上报材料 / 整改报告 / 回函 | 重大业务影响决策 + 会签 | "本动作进入监管档案，作为公司正式表态。业务规范显示需要 [角色 A] + [角色 B] 会签。是否完成？" |
任一类：标某 inspection-task 为风险接受 | 显著不符合项目会签 | "风险接受是有意识的合规决策。需要 [角色] 签字。是否已完成？" |
任一类：关闭整个函件（status: closed） | 首道审核（法务确认） | "确认本函件相关整改均已完成且监管已确认。是否标记为关闭？" |
未明确"是"前不触发对应动作。
输出
[工作秘密标识 —— 按 ## 谁在用这个插件 + shared/header-by-role.md 选定，通常为"内部合规分析 — 公司内部使用"]
> **⚠️ 复核提示**
> - **来源**：函件 [letter-id]（原件保存在 $LEGAL_AGENT_PROFILE_HOME/regulatory-legal/incoming-letters/[letter-id]/）
> - **分类**：第 X 类 [类别名] —— [简短依据]
> - **关键截止日**：监管要求 [日期]，内部缓冲 [日期]
> - **拆解任务**：[N] 条 `inspection-task`，[已分配 / 待分配]
> - **需要你判断的事项**：[N 项已用 `[复核]` 内联标注]
## 监管来函处置工单：[函件名称]
**来文**：[来文单位] [文号]
**收文**：[收文日期]
**函件类型**：第 X 类 [类别名]
**回复期限**：[日期]（剩 [N] 天）
### 字段抽取结果
| 字段 | 值 |
|---|---|
| 来文单位 | [...] |
| 文号 | [...] |
| 函件名称 | [...] |
| 要求事项 | [...] |
| 回复期限 | [...] |
| 抄送范围 | [...] |
| ...（其余字段） | ... |
### 6 分法归类依据
[函件文本中触发归类的关键短语 + 类别置信度]
### 处置路径
[按类别的具体动作清单，含时效 / 责任人 / 必要文档]
### `inspection-task` 拆解
| ID | 要求事项 | 归口部门 | 整改负责人 | 截止日 |
|---|---|---|---|---|
| INS-001 | [...] | [...] | [...] | [...] |
| ...（共 N 条） | | | | |
### 下一步必做
1. [紧急动作 1，如"3 个工作日内决定是否申请听证"]
2. [紧急动作 2]
3. [常规动作]
---
**下一步？选一个我来展开**：
1. **派发任务** —— 我把 [N] 条 `inspection-task` 通过 DM 通道（逐条预审）发给负责人
2. **触发会签** —— 我起草给法务总监 + 首席合规官的简报，含函件全文 + 分类依据 + 待决策点
3. **追加补充信息** —— 我注意到 [事项] 在函件中表述含糊，需要 [获取来源] 进一步确认
4. **打开任一任务详情** —— 告诉我 INS-XX，我展开任务的细节 + 起草给具体负责人的 DM
5. **生成上报材料草稿** —— 各部门反馈到位后，我按 `references/report-material-template.md`（上报材料模板）生成草稿
6. **其他** —— 告诉我
**清单之外我会问的一个问题**：[本函件中可能被遗漏但有影响的事项 —— 如"本次自查范围是否会牵出关联问题"、"抄送方上海地方金融监管局是否会单独跟进"等]
与其他技能的协作
| 上游 / 下游 | 协作方式 |
|---|
regulatory-reg-feed-watcher（监管动态监测） ← | 如果监管信息源中识别到"针对本公司"的工作函（通常通过反向匹配关注清单 + 公司全称），转入本技能处理 |
regulatory-gap-surfacer（内规差异呈现） → | inspection-task 写入 gap-tracker.yaml，复用其内规修改跟进 / 提醒 / 关闭机制 |
regulatory-policy-diff（政策比对） → | 函件中如涉及具体监管规则（如新发布的部门规章），可触发政策比对对照公司政策库分析 |
regulatory-policy-redraft（政策修订红线） → | 整改过程中如需修订内部政策，触发政策修订红线起草修订草案 |
regulatory-customize（个性化调整） → | 用户可通过个性化调整：上报材料缓冲天数、字段抽取置信度阈值、各类别的默认负责人 |
配置依赖降级
| 配置项缺失 | 行为 |
|---|
document.extract_fields 能力未配置 | 退化为纯文本输入模式（用户粘贴文本而非上传 PDF），其他流程不变 |
escalation_path 未配置 | 重大动作确认环节降级为通用提示，不路由到具体角色 |
| 政策库索引未填写归口部门 | inspection-task 派不到 task_owner，标"未跟进"，由冷启动访谈流程引导用户填 |
| 关键截止日未识别（监管函件中文表述含糊） | 停下来问用户，不擅自补 |
收尾决策树
按 profile.md 中 ## 输出 的决策树收尾。对监管下发函的特殊性：
- 决策树的"选项 2 上报 / 会签"通常是高优先 —— 监管函件多数会涉及对外提交，需要会签链
- 决策树的"选项 4 观察等待"对监管函件慎用 —— 监管截止日是硬刚性的，不响应有处罚后果
本技能不做的事
- 不起草处罚决定的复议申请书 / 诉讼起诉状（这是律师代理工作的专业内容，本技能仅触发"建议启动外聘律师"的提示）
- 不起草听证申请书 / 陈述申辩书（同上，建议外聘律师介入）
- 不判定监管处罚 / 措施的合法性（这是法律意见，需律师出具）
- 不自动提交上报材料（必须经法务负责人 + 首席合规官会签 + 法定代表人 / 法务联系人手工提交）
- 不自动监控监管回函（与
regulatory-reg-feed-watcher（监管动态监测）协作 + 人工录入兜底，不替代秘书 / 收发室）
- 不做监管沟通策略建议（如"要不要主动联系执法人员"等 —— 这是合规 / 公关策略，超出本技能范围）
详细 6 分法处置规则见 references/letter-classification-rules.md；inspection-task 模板见 references/inspection-task-template.md；上报材料模板见 references/report-material-template.md。
