DEMO-AGENT/docs/详细设计/7.飞书通知.md

7. 飞书通知详细设计

1. 设计目标

本步骤负责在审核任务执行完成或执行异常时，通过飞书 @ 对应处理人，并回传 Web 详情链接。

V1 当前 Demo 固定通知策略：

1. 执行完成后发送结果摘要并 @ 处理人
2. 执行异常后发送异常摘要并 @ 处理人

2. 角色信息模型

责任人信息不再只保留角色名，必须扩展为可通知实体，至少包含：

1. owner_role
2. owner_name
3. department
4. chapter_scope
5. risk_scope
6. feishu_user_id
7. feishu_open_id
8. feishu_name
9. notify_enabled

3. 输入

1. batch_id
2. conversation_id
3. product_name
4. notify_reason
5. registration_risk_report
6. registration_word_export_report
7. owner_mapping

其中 notify_reason 固定支持：

1. task_completed
2. task_failed

4. 输出对象

feishu_notification_report 至少包含：

1. batch_id
2. conversation_id
3. notify_reason
4. mentioned_users
5. message_status
6. web_detail_url
7. receipt

5. 主流程

任务完成或异常
-> 读取责任角色与飞书账号
-> 构建飞书摘要
-> 构建 @ 处理人载荷
-> 发送飞书消息
-> 写回发送回执
-> 写入处理历史和审计

6. 通知内容要求

飞书消息至少应包含：

1. 任务名称
2. 产品名称
3. 批次号
4. 结果状态
5. 风险等级或异常摘要
6. @ 处理人
7. Web 详情链接

7. 处理完成通知

触发条件：

1. 目录汇总完成
2. 风险报告完成
3. 导出状态已生成

输出重点：

1. 风险等级
2. 是否允许正式导出
3. 责任人

8. 执行异常通知

触发条件：

1. 资料解析失败
2. 规则执行失败
3. 回填导出失败
4. 外部依赖异常

输出重点：

1. 异常阶段
2. 异常摘要
3. 责任人
4. 是否建议人工介入

9. 与页面关系

9.1 审核智能体

可展示：

1. 本次是否已触发飞书通知
2. 飞书发送状态
3. 被 @ 的处理人

9.2 处理历史

可回看：

1. 通知原因
2. 接收人
3. 消息状态
4. Web 回链

10. 验收标准

1. 角色信息包含飞书账号相关字段。
2. 执行完成与执行异常两类通知链路完整。
3. 飞书消息支持直接 @ 对应处理人。
4. 通知结果可在处理历史和审计中回溯。