Proactive Tasks

核心定位

Proactive Tasks 是一套从被动到主动的Agent任务管理系统，核心目标是将AI助手从"等待指令"转变为"自主推进目标"的合作伙伴。

核心用法

系统通过四级架构实现自主工作：

1. 目标管理：将长期项目分解为可执行任务，支持优先级、依赖关系和上下文描述
2. 心跳驱动：每30分钟触发检查，自动获取最高优先级任务并执行15-20分钟工作
3. 状态追踪：任务状态包括pending/in_progress/blocked/needs_input/completed/cancelled，配合进度百分比和时间记录
4. 主动通信：完成任务、遇到阻塞或发现重要信息时主动通知人类，避免无效打扰

显著优点

• 生产级可靠性：WAL预写日志、SESSION-STATE实时状态、工作缓冲区和自愈健康检查四层防护，确保上下文截断时不丢数据
• 真正自主：无需人类持续 prompting，Agent可在后台持续推进目标
• 防误报机制：VBR（Verify Before Report）协议强制端到端验证后才标记完成，避免"写了代码=功能可用"的幻觉
• 模式分离：区分交互式（systemEvent）和自主式（agentTurn）两种操作模式，避免后台任务干扰主会话

潜在局限

• 需要基础设施：必须配置心跳系统（cron或定时触发），对非技术用户有门槛
• 上下文消耗：自主工作会占用token预算，需权衡自动化收益与成本
• 错误累积风险：长期自主运行可能产生偏离原始目标的"幻觉任务"，需定期人工审查
• 复杂依赖处理：多任务依赖链在上下文截断后可能状态不一致，依赖WAL恢复

适合人群

• 需要AI长期持续工作的研究者、开发者、项目经理
• 愿意配置技术基础设施（心跳系统）的进阶用户
• 有明确长期目标（数周至数月）且希望减少人工协调成本的场景

常规风险

| 风险类型 | 说明 | 缓解措施 |

|---------|------|---------|

| 数据丢失 | 上下文截断导致任务状态丢失 | WAL日志+SESSION-STATE双保险 |

| 虚假完成 | Agent报告完成但未实际验证 | 强制执行VBR协议 |

| 任务漂移 | 自主执行偏离原始目标 | 定期health-check + 人类审查 |

| 消息过载 | 过于频繁的主动更新 | 明确的通信准则（仅重要里程碑） |

| 权限越界 | 自主执行未授权操作 | 心跳系统隔离+明确操作边界 |

该系统适合追求高自主性AI协作的技术用户，但需投入配置成本并建立定期审查机制。

核心定位

proactive-tasks 是一套面向AI代理的生产级任务管理框架，核心使命是打破"等待指令→执行→等待"的传统交互模式，让AI成为能够自主推进长期目标的主动型合作伙伴。

核心功能架构

1. 目标-任务分层体系

• Goal（目标层）：定义长期项目或方向，如"构建本地语音助手替代Alexa"
• Task（任务层）：拆解为15-60分钟可完成的原子单元，支持依赖关系、优先级、状态流转
• 状态机设计：pending → in_progress → completed/blocked/needs_input/cancelled，确保执行路径清晰

2. 双模式自主运行

| 模式 | 触发方式 | 适用场景 | 上下文隔离 |

|------|---------|---------|-----------|

| Interactive | 用户请求、手动触发 | 需决策的交互式工作 | 继承主会话 |

| Autonomous | 心跳轮询（推荐30分钟） | 定时检查、报告生成、清理任务 | 隔离agentTurn |

3. 生产级可靠性（Phase 2核心）

• WAL协议：关键操作先写memory/WAL-YYYY-MM-DD.log，再更新数据，防上下文截断丢失
• SESSION-STATE.md：作为"工作内存"，每次操作后自动更新，断点后秒级恢复
• Working Buffer：60%-100%上下文危险区自动追加日志，支持事后审计
• Self-Healing Health Check：自动检测并修复5类数据异常（孤儿任务、状态冲突、时间异常等）
• Compaction Recovery Protocol：上下文截断后的四步恢复流程（Buffer → Session-State → WAL → Task Data）
• VBR（Verify Before Report）：标记完成前必须端到端验证，杜绝"代码写完=任务完成"的虚假报告

显著优点

• 零依赖安全：纯Python标准库（json/argparse/pathlib等），无第三方包，供应链攻击面为零
• 断点续作能力：上下文压缩、会话重启后，通过多层恢复机制确保工作连续性
• 反脆弱设计：WAL+Buffer+Health Check形成冗余保护，即使AI操作出错也能自愈
• 智能消息策略：区分"必报"（完成、阻塞、重要发现）与"禁报"（例行进度），避免信息过载
• VFM/ADL约束：功能演进必须通过价值评估（≥60分）和架构阶梯审查，拒绝"为复杂而复杂"

潜在局限

• 无原生协作：当前为单用户/单代理设计，多人间任务分配需外部协调
• 时间估算依赖诚实：log-time需AI自主记录，缺乏强制校验机制
• 心跳需外部触发：依赖用户配置cron或调度系统，非开箱即用
• 可视化缺失：纯CLI界面，无Web面板或图形化看板

适用人群

• 长期项目协作者：需要AI在数天/数周内持续跟进复杂目标
• 异步工作流用户：无法实时在线，希望AI在离线期间自主推进并汇总进展
• 断点敏感场景：频繁遇到上下文长度限制，需要可靠恢复机制
• 安全优先环境：拒绝任何外部依赖，要求完全本地可控的任务系统

常规风险

• 数据持久化路径：默认写入data/tasks.json及memory/、SESSION-STATE.md等，需确保路径可写且不冲突
• 时间记录准确性：依赖AI自我报告，可能存在主观偏差
• VBR执行质量：虽机制存在，但最终验证仍依赖AI自律，极端情况下可能出现未经验证的虚假完成
• cron配置误用：文档中的示例需用户自行评估安全性，不应直接复制到生产环境

技术亮点

User request → WAL log → Update data → Update SESSION-STATE → Append to buffer
     ↓              ↓            ↓                ↓                    ↓
Context cut? → Read WAL → Verify data → Check SESSION-STATE → Review buffer

这套四层防护体系使proactive-tasks成为目前开源领域罕见的、为"AI自主运行+上下文不稳定"场景专门设计的任务管理系统。