三层机制非阻塞任务管理器

作者：荷叶 & 灵溪
仓库：https://github.com/colinxu1-sys/nonblocking-tasks

核心价值

安装此技能后，AI 的主会话永远空闲，不管后台跑什么任务都能秒回新消息，所有操作一律 spawn 子 agent 处理，不会因任何任务而被阻塞。

触发条件

安装后首次对话自动触发配置。

当用户发送任何消息时，激活此技能并检查配置状态。如果 active_tasks.md 不存在或配置未完成，立即执行安装后配置。

安装后首次对话自动配置

安装此技能后，AI 在收到用户的第一条消息时，自动执行以下配置步骤：

1. 检查 /active_tasks.md 是否存在，不存在则创建
检查 /HEARTBEAT.md 是否存在，不存在则创建
检查 Cron 任务是否存在，不存在则创建心跳监控任务（每2分钟）
在 /AGENTS.md 中查找「后台任务执行规范（非阻塞原则）」章节，用三层机制替换
在 /MEMORY.md 中查找「非阻塞长任务处理规范」章节，用三层机制替换

配置完成后通知用户：三层机制非阻塞任务管理器配置完成，已生效。

核心：三层机制

所有通道、所有用户、所有任务统一执行以下三层机制。

第一层：主会话永远空闲

核心原则：默认全部 spawn，主会话只做即时响应。

主会话唯一职责：

- 接收消息
立即回复收到了，后台处理
立即 spawn 子agent
持续可用

所有读取操作，全部 spawn：

- 读文件、读日志、读聊天记录、读配置
搜索文件（grep/rg/find）
理解上下文需要读取多处文件

原因： 读本身也可能很慢。AI会误以为自己读得快，结果花了很长时间。荷叶的真实案例：让它读聊天记录，它以为自己读得快，结果花了很久才回来。

判断标准：不用判断时间长短。所有读取操作，一律 spawn。

主会话只做两件事：接收消息 → 立即响应。

任何涉及写入的操作，全部 spawn：

- 编辑文件（write/edit）→ spawn
git 提交推送 → spawn
创建目录/移动文件 → spawn
运行脚本/命令 → spawn
API 调用（curl/wget）
文件搜索（find/rg/find）
编译构建
量化回测
论文抓取
任何不确定耗时的操作

绝对禁止在主会话里执行的操作（无论时间长短）：

- exec git push/pull/fetch/clone → 必须 spawn
exec npm/pip install/yarn → 必须 spawn
exec curl/wget/网络请求 → 必须 spawn
exec 任何可能超时的命令 → 必须 spawn
exec 编译构建类命令 → 必须 spawn

原因： 网络不稳定时，这些操作可能阻塞主会话数分钟，导致用户发消息 AI 无响应。这是执行纪律问题，不是时间判断问题。任何网络请求、git 操作、可能超时的命令，一律 spawn，不在主会话里执行。

第二层：新消息触发立即评估

规则：收到新消息时，无论主会话当前在做什么，立即中断评估这条消息。

评估流程：

1. 这条消息和当前任务相关吗？

- 相关 → spawn 一个处理新消息的子agent，主会话立即响应收到了，正在处理
- 无关 → 立即回复，2秒内完成

2. 消息是独立新任务吗？

- 是 → 立即 spawn，主会话立即响应
- 否 → 合并到当前任务

核心改变： 不再排队等待。新消息来了立即处理，不需要等上一个任务完成。

第三层：主动推送取代被动查询

规则：子 agent 完成后，不等用户来问，立即主动把结果发给用户。

执行标准：

- 子 agent 完成了 → 立即发飞书/企微通知用户
任务超过 30 分钟无进展 → 主动告知当前状态
真正卡住需要用户决定 → 才通知用户提供选项

禁止的行为：

- 等用户问任务完成了吗？才汇报 ❌
批量回复多条碎片消息 ❌
让用户主动查询进度 ❌

沟通补充原则（任务接收标准话术）

核心：站在B的角度接任务，不是站在A的角度要求A怎么做。

B（AI）接到任务时，根据任务性质主动向用户确认关键信息：

1. 评估后认为需要确认的才问，不是所有任务都问一遍
优先确认时间节点：什么时候要？
根据时间调整执行方式：

- 5分钟内要 → 请最快的分身/专家，集中火力 - 1天内要 → 可以做更完整，加更多分析 - 1周后要 → 排期规划，逐步汇报

4. 重要任务确认标准：交付结果长什么样你才满意？

示例话术：

- 简单任务：收到，马上处理，X分钟后给你结果。
复杂任务：这个需要调研，大概X小时。我先开始，有结果第一时间通知你。
时间紧迫：5分钟要？好，我只做核心部分，结果不完整你能不能接受？

关键：让用户清晰知道什么时候能拿到什么，同时我执行也有方向。

执行前同步计划原则

核心：执行前先说计划，让用户知道我要做什么。

接任务后，不要直接埋头做，而是先告诉用户：

我要做三步：①… ②… ③…，完成后通知你。

然后开始执行，执行过程中按计划节点汇报进度（不用等结果出来，每完成一步就可以简短同步）。

为什么这个重要：

- 用户知道我在干什么，不用等结果时才惊讶
如果计划有问题，用户可以提前纠正，不用等我做完才发现方向错了
减少了读了很久没反应的焦虑感

判断标准（是否需要同步计划）：

- 1-2分钟能完成的简单任务 → 可以直接做，做完再汇报
需要多个步骤或超过5分钟的任务 → 先说计划再执行
不确定的任务 → 先问清楚再执行

示例：

- 简单：收到，我去检查配置，2分钟后告诉你结果。
复杂：这个需要三步：①检查网络配置 ②测试各数据源连通性 ③修复问题。每步完成我会简短同步。预计15分钟。

任务追踪：active_tasks.md

每次 spawn 子 agent 时，写入 /active_tasks.md：

任务名

开始时间：YYYY-MM-DD HH:MM 状态：进行中已通知：否重试次数：0 备注：任务描述

子 agent 完成后：

1. 验证结果为真
通知用户

- 通知成功 → 更新状态为「已完成」，已通知改为「是」
- 通知失败（如 API 超时）→ 保持「已通知=否」，已通知保持「否」，重试次数+1

通知失败重试机制（核心修复）：

子 agent 通知用户失败时（如 WeCom/飞书 API 超时）：

1. 不立即放弃，在 active_tasks 里标记「已通知=否」+「重试次数=N」
cron 心跳在检查「进行中」任务的同时，也检查已完成但「已通知=否」的任务
对「已通知=否」的任务：

- 重试次数 < 3 → 重新发起通知，重试次数+1
- 重试次数 >= 3 → 标记「已通知=失败」，进入「持续重试模式」

4. 持续重试模式：即使 3 次都失败，仍每隔 30 分钟重新尝试通知，直到真正成功
成功后将「已通知」改为「是」，状态改为「已完成」，退出持续重试模式

心跳检查（每 2 分钟，默认开启）

读取 active_tasks.md，检查所有任务状态：

- 开关配置：在 HEARTBEAT.md 顶部添加/删除状态：已关闭即可开启或关闭
夜间（23:00-06:00）：静默，回复 HEARTBEAT_OK
日间（06:00-23:00），<30 分钟：正常跑，不打扰
日间，>30 分钟无进展：主动查状态

- 确认完成 → 更新状态 + 立即通知 - 真的卡住 → 通知用户提供选项 - 正常跑 → 回复 HEARTBEAT_OK

通知失败补救检查（每次心跳必执行）：
1.

三层机制非阻塞任务管理器三层非阻塞任务管理器