> For AI agents: the complete documentation index is available at https://docs.danqiuos.com/llms.txt, the full documentation bundle is available at https://docs.danqiuos.com/llms-full.txt.

# 计划任务与事件触发

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

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

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

## 写清时间与事件契约

| 配置项  | 需要回答的问题            |
| ---- | ------------------ |
| 触发条件 | 按什么频率、时区或事件启动？     |
| 执行责任 | 由哪个员工执行哪项技能？       |
| 输入条件 | 数据是否已准备好，事件包含什么字段？ |
| 输出位置 | 结果写到业务表、任务还是文件？    |
| 通知对象 | 如何解析接收人，是否完成渠道绑定？  |
| 失败处理 | 谁接收异常，何时可以重试？      |

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

## 计划任务与 Calendar Sources

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

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

## Webhook 与邮件入站

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

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

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

## 示例：每日经营简报

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

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

## 边界与验收

计划任务与消息投递是两种能力，Webhook 也只是入口，不等于完整业务流程。对外发送或高风险写入仍需遵循 [人工确认与权限](https://docs.danqiuos.com/platform/security.md) 规则。

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