#计划任务与事件触发

#让工作按时间或事件开始

数字员工除了响应对话，也可以由计划任务、Webhook 和邮件入站等入口启动工作。计划任务适合每日简报、周期巡检和定期提醒；事件触发适合表单提交、业务状态变化或客户邮件到达后的处理。

触发机制只负责启动工作。完整方案还需要指定执行员工、技能、数据来源、输出位置和失败处理。企业可以围绕自己的节奏装配这些流程，不应将“已保存触发配置”当成业务已自动完成。

#写清时间与事件契约

涉及“今天”“本周”和逾期判断的流程，应先获取目标时区的当前时间。事件入口则应检查来源可信度、字段结构与异常处理规则，避免让不完整输入直接进入敏感操作。

#计划任务与 Calendar Sources

Calendar Sources 归入计划任务，用节假日、工作日、排班或业务日历上下文决定何时执行，并不是独立的业务执行能力。需要「工作日早上发日报」时，先确认日历来源与时间规则，再绑定目标员工及简报流程。

在 team 内创建计划任务，绑定员工和任务描述，设置时间或日历条件后，先手动执行一次，再验证实际时间触发。manage_scheduled_tasks 支持管理计划任务、手动执行和查看运行记录；若选择已有会话承接结果，可用 list_digiemployee_conversations 查找目标员工会话。存在前后依赖的工作，要在流程中明确交接条件，并测试前序失败时后序如何处理。

#Webhook 与邮件入站

Webhook 接收外部事件，需约定来源、字段、目标员工和后续结果。manage_webhook_endpoints 管理事件入口；入口能接收事件后，还要验证员工读取了哪些字段、执行了什么业务动作。

邮件入站应确认入口地址、路由、正文和附件的处理方式。manage_email_ingress_addresses 管理接收邮件并触发处理的邮箱入口，不能据此推断它也能对外发送邮件。出站邮件或其他渠道通知，需要另行确认已授权的发送能力、收件人和实际送达结果。

用一封真实测试邮件或一条测试事件贯穿入口、解析、任务或数据写回及成果交付；附件要由实际接收人打开检查。缺字段、附件不可读、路由错误或重复事件应进入约定的异常处理，避免重复创建记录。工具边界见 任务与编排。

#示例：每日经营简报

先由销售与履约岗位完成业务巡检，更新停滞天数、交期风险和应收状态，再由业务管家读取这些字段生成简报。这里的顺序需要在方案中明确，不能假设两个独立计划天然存在依赖关系。

生成后，将简报归档并通过配置的渠道发送给已绑定的负责人。若接收人无法解析或消息发送失败，应记录未触达情况；员工不能仅凭报告已生成就声称负责人已收到。

#边界与验收

计划任务与消息投递是两种能力，Webhook 也只是入口，不等于完整业务流程。对外发送或高风险写入仍需遵循 人工确认与权限 规则。

上线前必须试跑，检查真实触发时间、执行记录、数据变化、生成内容和送达结果。再测试缺字段、权限不足和接收人未绑定的情况，确认异常可见。重试前应核查上次动作是否已生效，尤其是记录新增与消息发送，避免把结果未知直接当成执行失败。