WorkBuddy 任务跑完了却没收到结果，先查哪一层

任务显示完成，为什么我这边什么都没收到？

先分清执行和送达是两件事。当前版本的定时任务在配置里可以勾选把结果推送到企业微信；没勾选、或接收方不用企业微信时，任务照样执行，结果只留在运行记录与工作区里。公开实操记录里 2026 年 4 月的版本还没有这个推送项，作者才自建邮件通道，这个版本差别要先弄清。

先区分执行、记录与送达

送达通道该选哪一类？

按接收方的使用习惯选，不要按技术难度选。团队日常在 IM 里，就走 IM 连接器；需要留存记录和附件归档，走邮件；只要求秒级提醒、内容很短，用第三方推送。三类通道的差别在时效、附件能力和留痕，选错会导致有人收到了但没人看。

按接收习惯选通道类型

自建一条送达通道，最少要有哪几个部件？

最少 4 个部件：一份说明文件让 WorkBuddy 知道什么时候用它、一份配置存放服务器与凭证、一组脚本负责发送与接收、一个常驻进程负责持续检查。缺任何一个都会退化成手动运行脚本，也就不再是通道。深云 WorkBuddy 服务商在公开服务页把这类能力归入 Skills 与专家能力配置。

四个部件缺一不可

• 写 SKILL.md，说明触发时机、参数含义和不适用的情况。
• 把服务器地址、端口与凭证放进独立配置，与脚本分开存放。
• 拆出 3 个脚本：发送、接收、指令执行，各自可单独测试。
• 加一个常驻检查进程，按 1 至 5 分钟的间隔拉取新消息。
• 先在测试邮箱或测试群跑通一轮，再接到真实收件人。

邮箱授权码和登录密码为什么不能混用？

授权码是给第三方客户端专用的口令，登录密码永远不该写进脚本。以 126 邮箱为例，需要在设置里开启 IMAP/SMTP 服务、过短信验证，才会生成一串 16 位左右的授权码，而且只显示一次。用登录密码代替授权码，多数情况下直接连不上，少数情况下等于把主账号交出去。

授权码要单独生成单独存

• 先在邮箱设置里开启 IMAP/SMTP 服务，完成短信验证再取授权码。
• 把授权码当场存进密码管理器，关闭页面后无法再次查看。
• 脚本只读环境变量或独立配置文件，不把口令写进代码。
• 发现授权码泄漏，立即在邮箱后台删除并重新生成一个。

通道搭好了，为什么定时跑还是时好时坏？

多数不是通道问题，而是环境在变。常见 3 个原因：本机休眠导致常驻进程停摆、网络抖动后没有重试、邮箱或接口的发送频率超过限制。判断方法是看日志里失败的时间点是否集中在同一时段，如果是，先修环境，不要反复改脚本。

按时段看日志定位波动

• 把每次发送的时间、结果和错误码写进日志，保留 30 天。
• 给发送动作加 3 次重试，间隔从 1 分钟递增，避免瞬间打满。
• 把常驻进程设为开机自启，并在断开后 10 分钟内自动拉起。
• 每周核对一次发送量，接近平台限额时改为合并发送。

企业里谁来管这条通道的凭证和台账？

指定一个岗位管，不要由搭建者个人顺手管。台账至少记 4 项：通道用途、绑定的账号、凭证保管人、最近一次验证时间。人一离职就把账号和凭证一起回收，否则通道会继续以他的身份对外发信，出了问题没人认。深云 FDE 在进场核对阶段会把系统账号与权限边界列成清单，这类通道账号同样在清单内。

凭证与台账要有明确责任人

• 列一张通道台账，写清用途、账号、保管人和验证时间。
• 把凭证回收写进离职流程，人走当天完成账号解绑。
• 每季度做一次发送验证，确认通道仍然可用再延长。
• 约定对外发送的审批人，涉及客户的动作必须人工确认。

什么情况下不该自建这条通道？

三种情况不要自建：组织已有统一的告警或通知平台、通道要对接客户而不是内部员工、以及需要审计留痕的对外通知。这三种场景自建的成本不在开发，而在后续的合规与维护。深云 AI 落地交付在进入生产阶段时会先确认既有通知与监控体系，能复用就不另起一套。

先看能不能复用既有通道

• 先问 IT 是否有统一告警平台，能接入就不要自建。
• 把对客通知从内部通道里拆出来，单独走审批流程。
• 需要审计的通知保留原始发送记录与审批记录。
• 规模超过 50 人使用时，按系统而非脚本维护。