第 3.6.3 节：把周报、合规与流程提醒写成可校验、可复用的工程契约
周报、合规与流程提醒不能只停留在口头约定，还需要落实为字段、校验和失败处理。完成本节后，你应该能够把周报、合规与流程提醒落成字段表、校验规则、错误处理和验收样例。
实现步骤或决策流程
推荐技术流及原因
| 技术环节 | 中文解释 | 推荐原因 |
|---|---|---|
| Document Parsing（文档解析） | 从文档、邮件、表格和转写文本中提取可处理内容 | 办公输入来源复杂，必须先标准化 |
| Structured Extraction（结构化抽取） | 抽取主题、结论、待办、负责人、金额、附件、风险等字段 | 后续检查、预审和提交都依赖稳定字段 |
| Workflow（工作流） | 把摘要、检查、确认、提交、归档拆成节点 | 避免一个模型直接做所有动作 |
| Policy Check（规则检查） | 根据审批制度、字段规范和合规要求检查问题 | 适合审批预审和文档合规 |
| Tool Calling（工具调用） | 让 Agent（智能体）在授权范围内调用邮件、日历、任务或审批工具 | 连接真实办公系统，但必须限制权限 |
| Human-in-the-loop（人工参与闭环） | 高风险动作前由人确认 | 防止误发、误提交流程和越权操作 |
| Approval Gate（审批门禁） | 对提交、外发、归档等动作设置确认门槛 | 把自动化建议和正式动作隔离 |
| Audit Log（审计日志） | 记录原始输入、生成草稿、检查结果、确认人和最终动作 | 便于复盘错误和满足企业管理要求 |
| SLA（服务等级协议） | 约定提醒、处理和反馈的时限 | 适合审批催办、异常提醒和服务台场景 |
推荐这套技术流，是因为办公项目的最大风险不是模型不会写，而是系统越权。一个可靠的办公 Agent 应该先把信息整理好，再把风险检查出来，最后把决定权交还给有权限的人。
字段契约表
| 字段 | 含义 | 来源 | 必填 | 验证与兜底 |
|---|---|---|---|---|
| request_id | 办公任务编号 | 系统生成 | 是 | 用于追踪原文、草稿、确认和最终动作 |
| source_type | 输入类型，如会议、邮件、文档、审批单 | 用户选择或系统识别 | 是 | 识别不清时要求人工选择 |
| source_owner | 输入材料负责人 | 用户身份或文档属性 | 是 | 无负责人时不能执行高风险动作 |
| task_type | 任务类型，如纪要、草稿、预审、周报、合规检查 | 用户选择 | 是 | 任务类型不明时先追问 |
| extracted_items | 抽取出的主题、结论、待办、金额、附件、风险等 | 结构化抽取 | 是 | 字段缺失时进入人工补充 |
| assignee | 任务负责人或审批发起人 | 抽取结果或人工指定 | 视场景必填 | 不确定时不得自动分派 |
| due_date | 截止日期或期望完成时间 | 抽取结果或人工指定 | 视场景必填 | 相对时间需人工确认 |
| required_fields | 审批或文档必填项 | 模板和规则库 | 预审场景必填 | 缺失时输出阻断原因 |
| attachment_check | 附件完整性检查 | 审批规则和材料清单 | 预审场景必填 | 缺附件时不建议提交 |
| risk_level | 低、中、高风险等级 | 规则检查和动作类型 | 是 | 高风险必须进入人工确认 |
| draft_output | 纪要、邮件、周报或审批理由草稿 | Agent 生成 | 是 | 只能作为草稿，需可编辑 |
| policy_findings | 规则命中和问题说明 | 规则检查 | 否 | 命中严重问题时阻断提交 |
| confirmation_status | 人工确认状态 | 用户操作 | 是 | 未确认不能外发、提交或归档 |
| tool_action | 准备调用的办公工具动作 | 工作流节点 | 否 | 动作必须受权限和确认限制 |
| audit_record | 原文、草稿、修改、确认人、执行结果 | 审计日志 | 是 | 高风险动作必须保留完整记录 |
字段契约让办公 Agent 不再是一个模糊助手，而是一个可管理的流程节点。每个字段都在回答一个问题：这件事从哪里来、要做什么、谁负责、风险多大、谁确认、执行了什么。
数据准备
办公自动化项目的数据准备要围绕“输入材料、规则、权限、动作结果”四类展开。
| 数据 | 准备方法 | 用途 | 风险控制 |
|---|---|---|---|
| 原始材料 | 收集会议转写、邮件串、周报、审批单、合同和附件样例 | 结构化抽取、草稿生成 | 涉及隐私、薪酬、合同金额时先脱敏和限权 |
| 模板与格式 | 整理纪要模板、邮件模板、周报模板、审批理由模板 | 草稿生成和格式检查 | 模板版本要标注适用部门 |
| 审批规则 | 梳理必填字段、金额阈值、预算归属、附件清单、节点和例外 | Policy Check（规则检查） | 规则不清时只能提示缺口，不能判断通过 |
| 组织权限 | 标注个人、部门、项目、主管、财务和管理员权限 | Tool Calling 门禁 | 写入、发送、提交等动作必须确认 |
| 历史退回样例 | 收集被退回原因、缺失字段、错误流程和修改意见 | 验收和预审规则优化 | 不能把历史通过样例当全部规则 |
| 执行结果 | 记录任务创建、邮件发送、审批提交、失败和人工取消 | 审计、复盘 | 工具失败时保存草稿和待执行动作 |
如果客户没有成文规则，可以先做“规则访谈 + 历史样例归纳”。在规则没有被业务负责人确认前，Agent 只能做预审建议，不能声称能自动判断审批是否通过。
制作步骤
- 选择单一高频流程：先从会议纪要、邮件摘要、审批预审或周报整理中选一个。不要一开始就接入所有办公系统。
- 收集历史样例：准备真实的优秀纪要、被退回审批单、典型邮件线程、标准周报、合规问题文档。样例是验收和优化的基础。
- 定义结构化字段：把输出拆成主题、背景、结论、待办、负责人、截止时间、风险、附件、审批金额、缺失项、建议动作等字段。
- 梳理规则和模板：把审批制度、必填字段、附件要求、金额阈值、敏感词、格式规范和部门差异写成可检查规则。
- 区分风险动作：摘要、提取、草稿属于低到中风险；外发、提交、归档、分派、催办和状态变更属于高风险，需要人工确认。
- 设计人工确认界面：审核人应该能看到原文、抽取字段、草稿、命中规则、风险等级、建议动作和可编辑区域。
- 接入最小必要工具：如果需要连接邮件、日历、任务或审批系统，只开放当前流程必要动作。例如只创建草稿，不直接发送；只预填审批，不直接提交。
- 建立审计记录：记录原始材料、生成内容、人工修改、确认人、执行动作、执行时间和失败原因。审计记录不是为了复杂，而是为了出现问题时能复盘。
- 用退回案例验收：选取历史上被退回、漏附件、理由不足、格式错误、金额超限的案例，检查系统是否能提前发现。
- 根据修改痕迹优化：上线后分析人工经常改哪些字段、哪些规则误报、哪些内容需要模板调整。办公项目的长期价值来自持续降低人工改动量。