## 访客预约与接待提醒 {.case data-case-id="065"} | 字段 | 值 | | --- | --- | | 案例编号 | `065` | | 行业 / 部门 | 互联网 / 行政 | | 角色 | 行政专员 | | 难度 | `入门` | | 调用来源 | `manual`（员工提交访客预约后由行政发起一次手动调用，带入预约单） | 访客到了前台才翻聊天记录找"谁约的、几点到"，接待人自己都忘了今天有客来。目标：员工提交访客预约后，行政发起一次手动调用，App/Extension 先在源头对预约单做白名单抽取与伪名化，Agent 只收到最小字段并核对完整性，关键字段齐全就生成访客提醒通知接待人与前台，到访日当天接待人和前台都能看到最小字段提醒；关键字段缺失（到访日、到访时间或接待人标识任一）就告警并通知调用方补全后新开调用，不猜。访客身份证号等敏感证件信息在源头即被令牌化，绝不进入 Agent 消息、回执与运行记录。指标：关键字段齐全的访客预约 100% 在到访日前完成提醒；接待人字段与预约单一致率 100%；任何回执含证件号的 0 例。 - **覆盖**：手动发起、App/Extension 在源头白名单化预约单、核对最小字段完整性、四项齐全生成提醒、仅访客称呼缺失时标"待确认"、关键字段缺失告警留审计并通知调用方补全后新开调用。 - **不覆盖**：自动登记门禁权限、自动通知访客本人、自动改预约时间、自动写入访客系统；也不覆盖 schedule 版每日扫当天到访列表（见"复用与变体"）。 - **假设**：预约单由 App/Extension 在调用源头抽取并伪名化，Agent 只收到到访日、到访时间、接待人内部标识、访客称呼展示引用四个白名单字段；接待人内部标识为受控令牌（权限受控且 Agent 无法反查原值；展示名仅由下游授权 App 发送时回填），访客称呼同样只以展示引用（`*_ref` 受控令牌）传递——展示名由 App/Extension 在源头按平台侧规则生成并登记，Agent 与工作流不见展示名字符串，仅发送提醒的授权 App 在发送时按引用解析回填，不外带证件或联系方式原值；访客身份证号等证件信息在源头即被令牌化，不进入工作流与日志。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：员工提交访客预约后由行政发起一次手动调用，App/Extension 先在源头把预约单抽取为四个白名单字段——到访日、到访时间、接待人内部标识（受控令牌：权限受控且 Agent 无法反查原值；展示名仅由下游授权 App 发送时回填）、访客称呼展示引用（`visitor_display_ref` 受控令牌：展示名由 App/Extension 在源头生成并登记，Agent 只见引用，不含证件号，展示名由发送提醒的授权 App 在发送时按引用解析回填），Agent 只收到这四个字段，先核对完整性，再按三类结果分流。访客身份证号等证件信息在源头即被令牌化，绝不进入 Agent 消息、回执与运行记录。 核对环节回传 JSON：{appointment_ref: 预约令牌（取自调用输入，不由 Agent 生成）, check_result: 枚举(完整|有缺项|不完整), fields_missing: [枚举(到访日|到访时间|接待人标识|访客称呼)], visit_date: 日期|缺失, visit_time: 时间|缺失, host_ref: 接待人令牌|缺失, visitor_display_ref: 访客称呼展示引用令牌|缺失, audit_ts: 时间戳}；必填/禁止条件按三状态矩阵闭合，且四个字段分别“存在当且仅当 fields_missing 不含其枚举项”：check_result=完整时四项必填且 fields_missing 必为空；check_result=有缺项时三个关键字段必填、visitor_display_ref 禁止出现且 fields_missing 必精确等于 [访客称呼]；check_result=不完整时 fields_missing 必非空且至少含到访日、到访时间、接待人标识之一，实际存在/缺失必须与枚举逐项一致，访客称呼可同时列为缺失。缺任一应必填项、出现应禁止项或状态与字段组合矛盾，视为回传不合结构。 仅接受上述状态矩阵中的组合，其余 callback 一律拒绝并保持原等待点。 触发：手动发起一次调用，调用时带入源头抽取的最小字段预约信息（预约令牌 appointment_ref 必填，访客称呼展示引用令牌为可选）、前台频道与接待人频道标识、值班频道（值班频道作为调用输入提供，用于发送失败升级）。 结果分三类处理（先判完整性，再判缺项，两类判定互斥）： 预约信息不完整（关键字段区块缺失，或到访日、到访时间、接待人标识任一关键字段缺失）：告警留审计时间戳，通知调用方补全后新开一次调用，本流程不重试、不拿不完整信息继续跑；缺什么列什么，不猜、不默认填值。 有缺项（关键字段齐全，仅访客称呼缺失）：提醒中该可选字段标"待确认"，由前台与行政人工补全，不退回、不重跑。 信息齐全：生成访客提醒，只含到访日、到访时间、接待人、访客称呼展示引用四个白名单字段，由发送提醒的授权 App 在发送时按引用解析接待人与访客称呼展示名，通知接待人与前台频道，并留审计时间戳。 审批：不涉及审批，访客提醒是低风险信息，直接触达接待人与前台。 异常：核对环节回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）并保留待发内容供人工补发。 完成：访客提醒、预约信息不完整告警各自留审计时间戳后结束。 ``` ![案例 065 访客预约与接待提醒：行政手动发起一次调用，App/Extension 在源头把预约单抽取为白名单字段（到访日/到访时间/接待人内部标识为受控令牌/访客称呼为展示引用受控令牌、展示名由发送方授权 App 按引用解析，证件号在源头令牌化），Agent 只收最小字段并先核对完整性；预约信息不完整（区块缺失或到访日、到访时间、接待人标识任一关键字段缺失）告警留审计并通知调用方补全后新开调用不重试，有缺项（关键字段齐全、仅访客称呼缺失）提醒中标待确认不退回，信息齐全生成最小字段提醒通知接待人与前台，均留审计时间戳；回传不合结构停在原等待点](../../../media/cases/fig-case-065-01-flow.svg){#fig-case-065-01 width=92%} 如上图所示，正常路径与异常同时可见，几类结果都有可见回执： 1. **手动触发**：员工提交访客预约后，行政发起一次手动调用，App/Extension 在源头把预约单抽取为到访日、到访时间、接待人内部标识（受控令牌）、访客称呼展示引用（受控令牌，展示名由发送提醒的授权 App 按引用解析回填）四个白名单字段，连同前台频道一起带入。 2. **核对完整性**：先判预约信息是否完整，再判是否仅缺访客称呼；完整态必须四项齐全，回传状态与字段矛盾时停在原等待点。 3. **三类结果分流（先判完整性，再判缺项，两类判定互斥）**： - **预约信息不完整**：关键字段区块缺失，或到访日、到访时间、接待人标识任一关键字段缺失，告警留审计时间戳，通知调用方补全后新开一次调用；本流程不重试，不拿不完整信息继续跑。 - **有缺项**：关键字段齐全、仅访客称呼缺失，提醒中该字段标"待确认"，由前台与行政人工补全，不退回、不重跑。 - **信息齐全**：生成访客提醒，只含到访日、到访时间、接待人、访客称呼展示引用四个白名单字段，由发送提醒的授权 App 按引用解析展示名后通知接待人与前台，并留审计时间戳。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动核对 + 三路分流"流程——它知道"核对预约信息"需要一个处理环节、"先判完整性再判缺项"需要一个条件路由、"提醒与回执"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **拿不完整预约信息继续跑**：这是最危险的失败方式——缺了到访时间照样发提醒，前台空等一场。靠完整性前置判断兜底：关键字段区块或到访日、到访时间、接待人标识任一缺失，一律按预约信息不完整告警留审计并通知调用方补全后新开调用，不重试、不降级继续。 - **缺到访日、到访时间或接待人标识**：不猜提交人意图、不默认填值，按预约信息不完整处理，缺什么列什么。 - **可选访客称呼缺失**：关键字段齐全、仅访客称呼缺失时，提醒中该字段标"待确认"，由前台与行政人工补全，不退回、不重跑。 - **证件信息进入 Agent 消息或回执**：靠源头白名单抽取兜底——App/Extension 只放行到访日、到访时间、接待人内部标识（受控令牌）、访客称呼展示引用（受控令牌，Agent 不见展示名字符串）四个字段，访客身份证号等证件信息在源头即被令牌化，不进入工作流与日志。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道（作为调用输入提供），并保留待发内容供人工补发。 - **核对环节回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 本案例不涉及审批。访客提醒是低风险信息，应第一时间触达接待人与前台；因此不设 `request_approval` 环节，三类结果直接出回执。仅访客称呼缺失时的"待确认"标注由前台与行政人工补全，属线下动作不经审批环节。生产环境里唯一的硬动作只有"发提醒"这一种，门禁权限登记等变更由行政线下按既有流程完成，不经本工作流。 本工作流不直接调用外部系统。预约单由 App/Extension 在调用源头抽取并伪名化，白名单字段（到访日、到访时间、接待人内部标识（受控令牌）、访客称呼展示引用（受控令牌，展示名由发送提醒的授权 App 按引用解析））与前台、接待人频道作为调用输入提供；访客系统或门禁系统如需读取，由获授权 Agent 通过 App/Extension 完成，访问凭据用 `` 占位，由 Agent 运行时从密钥引用。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段以白名单为准（仅令牌化/白名单字段，原值不进入以上任何一层），可回溯个人或敏感资产的字段在源头即被令牌化/伪名化，并按 10% 抽查四层实际记录。工作流不自动登记门禁权限、不自动写入访客系统，只编排核对、提醒与回执。 - **回放集与基准**：取最近 40 条历史访客预约（含信息齐全、有缺项、预约信息不完整样本）回放，人工基准答案为逐单核对结论与应发提醒的最小字段内容；每次回放记录核对、通知时间戳。 - **完整性防线**：基准为预约信息不完整（区块缺失或到访日、到访时间、接待人标识任一关键字段缺失）的样本 100% 在生成提醒前被拦下并告警，拿不完整信息继续跑的 0 例；关键字段齐全而访客称呼缺失的样本 100% 走"待确认"路径，不误报为不完整。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（仅令牌化/白名单字段，原值不进入以上任何一层），并按 10% 抽查四层实际记录；接待人内部标识为受控令牌，Agent 无法反查原值；访客称呼仅以展示引用令牌出现，Agent 消息与运行记录中出现访客称呼展示名字符串的 0 例（展示名只在发送提醒的授权 App 发送时按引用回填）。 - **指标**：关键字段齐全的访客预约 100% 在到访日前完成提醒；关键字段缺失样本 100% 告警新开调用，不出现猜测的到访日、到访时间或接待人；接待人字段与预约单一致率 100%，访客称呼缺失时 100% 标"待确认"。 - **最小披露**：每周抽查 5 条提醒与回执，含访客身份证号等证件信息的 0 例。 - **结果可见**：`完整`、`有缺项`、`不完整` 三态 100% 按同一 `fields_missing` 枚举矩阵落位：完整与仅缺访客称呼均产生可见提醒，后者 100% 标“待确认”；关键字段不完整 100% 告警新开调用，不出现静默成功。 ### 复用与变体 - **同构迁移**：会议室预约提醒、面试接待提醒、供应商到访登记提醒。 - **变体到定时**：把手动调用改成每日定时扫当天到访列表的 schedule 版，零结果分支"本期无访客"由此生效（发一条零结果回执不静默结束），在提示词里写明触发方式即可。 - **分级路由**：重要访客（高管陪同、监管到访）单独提醒行政负责人，普通访客只发前台。