长任务实时进度通信规范

规范长任务通信流程的工作指南，通过可配置心跳机制确保用户实时掌握进度，消除等待焦虑，提升交互透明度与信任度。

基本信息

• 技能名称?let-me-know
• 中文名称?长任务实时进度通信规范
• 作者?fogyoy
• 分类?其他
• 版本?未标注
• 标签?productivity, automation, customer-support, development-engineering, operations, project-program-management

使用方法

使用说明
核心用法
该 Skill 定义了一套标准化的长任务通信协议，适用于任何预计执行时间超过 2-3 分钟的 Agent 任务。其核心工作流程包含三个关键环节： 预飞通知 （在任务启动前明确告知用户任务内容、预计耗时及通信规则）、 心跳更新 （通过可配置的时间间隔，默认每 5 分钟发送一次包含实时进展的动态进度报告）以及 完结通知 （任务成功或失败时立即推送结果摘要）。实现上优先推荐"原地心跳"模式，即在长任务执行线程内通过循环休眠实现进度推送，避免创建额外的定时任务；仅在必须脱离当前执行流时才启用 Cron 心跳，并严格要求在任务结束时清理定时器，防止消息刷屏。
显著优点
首先， 极致的透明度设计 彻底消除了用户面对"黑盒"长时间等待的焦虑感，通过明确的预期管理和持续的进度同步建立信任。其次， 灵活的interval配置 允许根据任务特性调整心跳频率（如编译任务可设为 10 分钟，AI 生成任务可设为 2 分钟），兼顾信息时效性与打扰控制。再者， 双模式实现策略 （原地循环 vs Cron 任务）既保证了简单场景的易用性，又满足了复杂异步流程的需求。此外，文档对 异常处理的完整性考虑 （失败时立即停止心跳、Cron 清理失败的重试机制）体现了生产环境的健壮性思维。
潜在局限
作为纯文档型 Skill，其本质是一份 行为规范而非可执行代码 ，实际的通知功能（如 message send 的具体实现、Cron 调度能力）完全依赖底层 Agent 平台的支持，存在平台兼容性问题。若 Agent 平台未实现 Cron 管理或消息推送接口，该规范将无法落地。此外，心跳机制本身存在 设置悖论 ：间隔过短会增加系统负载并可能打扰用户，间隔过长则失去"缓解焦虑"的意义，需要使用者具备场景判断经验。对于极长任务（如数小时的模型训练），固定间隔的心跳可能不如里程碑式汇报高效。
适合群体
该 Skill 特别适合 构建 AI Agent 的开发者 和 需要编排复杂工作流的技术团队 ，尤其是涉及代码构建、批量数据处理、AI 内容生成、自动化测试等耗时操作的场景。对于 客服型 Agent 或 个人助手类应用 ，该规范能显著提升用户体验。同时， 运维人员 和 项目经理 也可借鉴此模式设计人机协作流程，确保长时间运行的后台任务对用户可见、可控。
使用风险
主要风险集中在 Cron 心跳的资源管理 上：若任务异常退出或网络超时导致 Cron 清理失败，可能产生"孤儿心跳"持续发送无效消息，虽然文档提供了指数退避重试和延迟清理的兜底方案，但仍需监控。其次是 平台性能风险 ，频繁的状态读取（每次心跳前需查询进度日志）可能对 I/O 造成压力。此外， 消息过载风险 不容忽视，若用户同时触发多个长任务且均采用默认 5 分钟间隔，可能收到过多心跳消息。建议在实际部署时结合具体平台的限速策略和用户的免打扰设置进行适配。