## 上市合规申报节点跟踪 {.case data-case-id="078"} | 字段 | 值 | | --- | --- | | 案例编号 | `078` | | 行业 / 部门 | 金融 / 法务 | | 角色 | 董秘 | | 难度 | `复杂` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取合规申报日历） | 上市进程里错过一个法定披露/申报节点就是监管事故。目标：定时让获授权 Agent 经 App/Extension 读取合规申报日历，逐个跟踪申报与披露节点，按"按期推进、临期、逾期未完成、节点日期缺失、日历不可达"分别处理。红线：法定披露/申报节点临期或逾期未完成的一律强制升级董秘与外部顾问人工确认，绝不自动跳过、绝不自动提交。最小披露：未公开的财务数据与申报材料内容绝不进入任何回执，只显节点名与状态；内部审议材料只到"已提交/待审议"状态级。 - **覆盖**：定时读取合规申报日历、逐节点跟踪、按期发回执（只显节点名与状态）、临期与逾期未完成强制升级人工确认、日期缺失单列由人补全、日历不可达按取数失败告警升级。 - **不覆盖**：自动提交任何申报或披露文件、自动改节点日期、代替董秘或外部顾问做合规判断。 - **假设**：有一个经授权能读取合规申报日历的 Agent（通过 App/Extension）；日历含节点名、类型、法定日期与当前状态；日期仅用日历字段，缺失单列不猜。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每日定时（含节假日，法定节点不看工作日）由获授权的跟踪 Agent 经 App/Extension 读取合规申报日历，App/Extension 在日历侧只放行白名单字段——节点名、节点类型、法定日期、当前状态、最近更新时间，未公开的财务数据与申报材料内容在源头即被过滤，绝不进入 Agent 消息、运行记录与任何回执；内部审议材料只到"已提交/待审议"状态级。对申报、披露、审议类节点逐个跟踪。 跟踪 Agent 回传 JSON：{window: 统计窗口, as_of_at: 平台调度器签发的基准时刻（调用输入原样回传）, nodes: [{node_name: 节点名, node_type: 枚举(申报|披露|审议), legal_date: 日期|缺失, date_missing: 布尔, status: 枚举(已完成|进行中|未开始), updated_at: 时间戳}], source_ok: 布尔, fields_missing: [枚举(合规日历)], audit_ts: 时间戳}。状态矩阵：source_ok 与 audit_ts 始终必填；source_ok=false 时 fields_missing 必为 [合规日历]，window、as_of_at、nodes 禁止出现；source_ok=true 时 fields_missing 必为空，window、as_of_at、nodes 必填，nodes 每个元素的 node_name、node_type、date_missing、status、updated_at 必填；date_missing=false 当且仅当 legal_date 存在，date_missing=true 当且仅当 legal_date 缺失，status 在两种日期状态下都独立必填。**临期当且仅当** date_missing=false、node_type∈{申报,披露}、status≠已完成，且按调用输入时区计算 `0 <= legal_date - as_of_at < 7天`；审议节点永不归入临期，日期已过的负差值也不冒充临期。仅接受这些组合；其余 callback 一律拒绝，原 Effect 保持 awaiting。 触发：定时（计划）发起调用，平台调度器签发 as_of_at 并作为调用输入带入，同时带入董秘频道、外部顾问频道、审批人与跟踪 Agent、值班频道（值班频道作为调用输入提供，用于失败升级）。 结果分流（按优先级从高到低依次判断，先判红线再判其余）： 逾期未完成（红线）：仅法定披露/申报节点 status≠已完成且 `legal_date - as_of_at < 0` 时成立，强制升级但不称为"临期"。 临期（红线）：仅法定披露/申报节点满足 status≠已完成且 `0 <= legal_date - as_of_at < 7天` 时成立，一律强制升级，绝不自动跳过、绝不自动提交——最高优先级，命中即短路，不会落到"按期推进"路径；审议节点与负差值不冒充临期，升级内容只含节点名、类型、法定日期与当前状态。 按期推进：节点按期完成或时间充裕，发节点状态回执（只显节点名与状态），留审计时间戳。 节点日期缺失·待确认：日历中节点缺法定日期，单列一张待补全清单发给董秘，由人补全日历后下次调用生效，本次不猜日期、不推进度。 本期无到期节点（查询成功但日历在窗口内无任何申报/披露节点）：发一条"本期无到期节点"汇总回执并留时间戳，不静默结束。 取数失败（合规申报日历系统不可达、数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）；不当作"本期无到期节点"，也不当作按期推进。 审批：临期或逾期未完成升级均串行经两道人工确认——先董秘确认，再外部顾问确认，两道均为二值确认或驳回（不设自动超时，无默认通过/否决），两道都确认后才生成应对安排（只列待办选项，由人执行）；任一道驳回则失败结束并留审计。 异常：跟踪 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）并保留待发内容供人工补发。 完成：临期/逾期升级、按期回执、日期缺失清单、零结果回执、取数失败升级，各自留审计时间戳后结束。 ``` ![案例 078 上市合规申报节点跟踪：定时读取合规日历；临期 iff 为申报或披露、未完成且 0 小于等于 legal_date 减 as_of_at 小于 7 天，负差值单列为逾期未完成而不冒充临期，审议节点不进这两条红线。临期或逾期均强制升级董秘与外部顾问人工确认，按期推进发状态回执，日期缺失单列待补全，本期无到期节点发零结果，日历不可达走取数失败；未公开数据不进入回执](../../../media/cases/fig-case-078-01-flow.svg){#fig-case-078-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见，五类结果都有可见回执： 1. **定时触发**：计划到点（每日，含节假日）发起调用，带入董秘频道、外部顾问频道、审批人与跟踪 Agent。 2. **跟踪申报节点**：获授权 Agent 经 App/Extension 在日历侧白名单化读取合规申报日历，逐节点回传节点名、类型、法定日期、状态与更新时间（财务数据与材料内容在源头被过滤）；回传缺任一必填字段视为不合结构，停在原等待点，等其重新提交，不自动重跑。 3. **五路分流（先判红线）**： - **逾期未完成（红线）**：申报或披露节点未完成且日期差为负，强制升级，但不计入临期。 - **临期（红线）**：仅当节点类型为申报或披露、状态未完成，且 `0 <= legal_date - as_of_at < 7天` 时成立；命中后强制升级并串行经董秘与外部顾问两道二值确认。审议节点或负差值不算临期，任一道驳回则失败结束；绝不自动跳过或自动提交。 - **按期推进**：发节点状态回执，只显节点名与状态，留审计时间戳。 - **节点日期缺失**：单列待补全清单发给董秘，由人补全日历后下次调用生效，不猜日期。 - **本期无到期节点**：查询成功但窗口内为空，发零结果回执并留时间戳，不静默结束。 4. **取数失败**：日历系统不可达或陈旧，告警留审计，按重试上限重试，仍失败升级值班频道（作为调用输入提供）。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时跟踪 + 红线强制升级 + 五路分流"流程——它知道"跟踪节点"需要一个发消息并等待回调的 Agent 环节、"先判逾期与临期红线再分流"需要一个红线优先的条件路由、"人工确认"需要一个审批环节、"回执与升级"各需要一个发消息环节。 - **临期节点被状态标注或类型掩盖**：临期 iff 固定为 `node_type∈{申报,披露} && status≠已完成 && 0<=legal_date-as_of_at<7天`；命中一律强制人工确认。负差值单列为逾期未完成并同样升级，审议节点与日期缺失不进入这两类。 - **日历系统不可达、数据陈旧**：不当作"本期无到期节点"或按期推进，而是告警失败、留审计时间戳，按重试上限重试；仍失败升级值班频道。 - **节点日期缺失**：Agent 不从历史周期推算法定日期，单列待补全清单由董秘补全，本次不猜日期。 - **负责人驳回升级**：失败结束并留审计；要重新处理就再发起一次确认，没有"AI 自动跳过"。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **本期无到期节点**：仍发零结果回执并留时间戳，让"没消息"变成可核验的记录。 - **跟踪 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其重新提交，不自动重跑。 - **长时间无人审批**：审批不设自动超时，流程停在等待状态，绝不"超时默认通过"。若需响应时限，由另一条定时 Workflow 扫出超时项并通知董秘。 临期或逾期未完成红线命中后串行经两道人工确认：第一道董秘确认，第二道外部顾问确认，两道均为二值（确认或驳回，不设自动超时，无默认通过/否决），任一道驳回则失败结束留审计。确认时两道审批人看到的都是节点名、类型、法定日期与当前状态。两道都确认后只生成待办选项清单，由人执行申报与披露动作。 本工作流对合规申报日历的读取由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统，也绝不向监管系统提交任何文件。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段（原值不进入以上任何一层），可回溯个人或敏感资产的字段在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录——App/Extension 在日历侧只放行节点名、类型、法定日期与状态，未公开财务数据与申报材料内容一律过滤。董秘频道、外部顾问频道与值班频道作为调用输入提供；日历系统的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。日历不可达或陈旧属于取数失败，走失败回执与升级。 - **回放集与基准**：取最近一个申报周期 40 个节点（含按期、临期、逾期未完成、日期缺失、审议样本）回放，基准为既定分类与升级清单。 - **红线防线**：逐节点回放 node_type、status 与日期差的笛卡尔组合；仅 `申报/披露 × 未完成 × 0<=差值<7天` 标临期，负差值标逾期未完成且两者 100% 当日升级；审议、已完成或差值 ≥ 7 天误入临期的 0 例，负差值误标临期的 0 例；自动跳过与提交 0 例。 - **字段纪律**：日历提供日期时 100% 原样带出；缺失时 100% 单列待补全，不出现猜测的日期。 - **最小披露**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（原值不进入以上任何一层），并按 10% 抽查四层实际记录；未公开财务数据与材料内容在回执与通知中出现 0 次；审议节点 100% 只到"已提交/待审议"状态级。 - **双确认**：临期与逾期未完成升级 100% 串行经董秘确认与外部顾问确认两道审批，任一道驳回 100% 失败结束留审计，无跳过第二道的 0 例外。 - **结果可见**：五类结果 100% 各有可见回执留审计，不静默成功。 - **分母与口径**：升级及时率分母为基准临期与逾期未完成节点数；每次运行记录跟踪与升级时间戳。 ### 复用与变体 - **同构迁移**：定期报告披露日历跟踪、牌照续期跟踪、税务申报节点跟踪。 - **双签加严**：披露节点临期须董秘与外部顾问双确认。 - **写回日历**：确认后加一个 Agent 环节，把安排状态写回合规日历（只写状态）；写回须是获授权 Agent 经 App/Extension 的幂等动作（业务键=节点名+平台在安排登记时签发的版本令牌+期望状态+目标日历），Agent 只能原样回传版本令牌；响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。