主动任务

一个任务管理系统，将被动响应的助手转变为主动协作的伙伴，能够围绕共同目标自主工作。

核心理念

这项技能让你不再被动等待人类指示，而是能够：

• 追踪目标并将其分解为可执行任务
• 在心跳周期内处理任务
• 向人类发送进度更新，并在受阻时请求协助
• 持续推进长期目标

快速入门

创建目标

当人类提及目标或项目时：

python3 scripts/task_manager.py add-goal "Build voice assistant hardware" \
  --priority high \
  --context "Replace Alexa with custom solution using local models"

分解为具体任务

python3 scripts/task_manager.py add-task "Build voice assistant hardware" \
  "Research voice-to-text models" \
  --priority high

python3 scripts/task_manager.py add-task "Build voice assistant hardware" \
  "Compare Raspberry Pi vs other hardware options" \
  --depends-on "Research voice-to-text models"

心跳周期执行

检查待办事项：

python3 scripts/task_manager.py next-task

系统将返回可处理的最高优先级任务（需满足无未解决依赖、未被阻塞的条件）

完成任务

python3 scripts/task_manager.py complete-task <task-id> \
  --notes "Researched Whisper, Coqui, vosk. Whisper.cpp looks best for Pi."

与人类通讯

当完成重要事项或遇到阻碍时：

python3 scripts/task_manager.py mark-needs-input <task-id> \
  --reason "Need budget approval for hardware purchase"

随即向人类发送更新信息或咨询问题

第二阶段：生产就绪架构

Proactive Tasks v1.2.0 包含了来自真实智能体使用场景的、经过实战检验的模式，旨在防止数据丢失、应对上下文截断，并在自主操作下保持可靠性。

1. WAL 协议（预写式日志）

问题：智能体写入内存文件后，上下文被截断。所做的更改随之消失。

解决方案：在对任务数据进行修改之前，先将关键更改记录到memory/WAL-YYYY-MM-DD.log文件中。

工作原理：

• 每次标记进度、记录时间或状态变更时，都会首先创建一个 WAL 条目。
• 如果在操作过程中上下文被截断，WAL 会保存相关细节。
• 在压缩（或类似操作）之后，可以读取 WAL 来恢复当时正在进行的操作。

记录的事件：

• 进度变更：任务进度更新（0-100%）
• 时间日志：任务实际耗时
• 状态变更：任务状态转换（受阻、完成等）
• 健康检查：自我修复操作

自动启用- 无需配置。WAL文件创建于memory/目录。

2. SESSION-STATE.md（活动工作内存）

核心理念：聊天记录是缓冲区，而非存储。SESSION-STATE.md是您的"RAM"——唯一可靠保存任务细节的地方。

每次任务操作自动更新：

## Current Task
- **ID:** task_abc123
- **Title:** Research voice models
- **Status:** in_progress
- **Progress:** 75%
- **Time:** 45 min actual / 60 min estimate (25% faster)

## Next Action
Complete research, document findings in notes, mark complete.

此举的重要性：上下文压缩后，您只需阅读SESSION-STATE.md即可立即掌握：

• 正在处理的任务
• 当前进度
• 后续步骤

3. 工作缓冲区（危险区域防护机制）

现存问题：当上下文使用率在60%到100%之间时，您就进入了"危险区域"——压缩随时可能发生。

解决方案：自动将所有任务更新追加到working-buffer.md文件中。

工作原理：

# Every progress update, time log, or status change appends:
- PROGRESS_CHANGE (2026-02-12T10:30:00Z): task_abc123 → 75%
- TIME_LOG (2026-02-12T10:35:00Z): task_abc123 → +15 min
- STATUS_CHANGE (2026-02-12T10:40:00Z): task_abc123 → completed

压缩发生后：读取working-buffer.md文件，即可准确查看危险区域内发生的情况。

手动刷新： python3 scripts/task_manager.py flush-buffer将缓冲区内容复制到每日记忆文件中。

4. 自我修复健康检查

智能代理会犯错。任务数据可能随时间推移而损坏。健康检查命令可检测并自动修复常见问题：

python3 scripts/task_manager.py health-check

检测5类问题：

1. 孤立重复任务- 无父级目标
2. 不可能状态- 状态=已完成但进度<100%
3. 缺少时间戳- 已完成任务缺少完成时间
4. 时间异常- 实际耗时 >> 预估耗时（标记供审核，不自动修复）
5. 未来日期完成的任务- 带有未来时间戳的已完成任务

自动修复4个安全类别（时间异常仅标记供人工审核）

何时运行：

• 在心跳期间（每隔几天）
• 从上下文截断恢复后
• 当任务数据看起来不一致时

生产可靠性

这四种模式共同作用，创建了一个健壮的系统：

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

结果：即使在上下文截断期间，您也永远不会丢失工作。系统能够自我修复并自主保持一致性。

5. 压缩恢复协议

触发条件：会话开始时带有<summary>标签，或者被问到“我们刚才说到哪了？”或“继续”。

问题：上下文被截断了。你不记得正在处理什么任务。

恢复步骤（按顺序）：

1. 第一步：读取working-buffer.md- 原始危险区对话记录

   # Check if buffer exists and has recent content
   cat working-buffer.md
   

2. 第二步：读取SESSION-STATE.md- 活动任务状态

   # Get current task context
   cat SESSION-STATE.md
   

3. 第三步：读取当天的WAL日志

   # See what operations happened
   cat memory/WAL-$(date +%Y-%m-%d).log | tail -20
   

4. 第四步：根据SESSION-STATE中的任务ID检查任务数据

   python3 scripts/task_manager.py list-tasks "Goal Title"
   

5. 提取与更新：如有需要，将重要上下文从缓冲区提取到SESSION-STATE中

6. 呈现恢复信息：“已从压缩中恢复。上一个任务：[标题]。进度：[%]。下一步操作：[需要做什么]。继续吗？”

不要问“我们刚才在讨论什么？”- 缓冲区和SESSION-STATE里确实有答案。

6. 报告前验证（VBR）

法则："代码存在" ≠ "功能有效"。未经端到端验证，切勿报告任务完成。

触发条件：即将标记一项任务为已完成或说"完成"时：

1. 停下- 先别标记完成
2. 测试- 实际运行/从用户角度验证结果
3. 验证- 检查实际效果，不仅仅是输出
4. 记录- 将验证详情添加到任务备注中
5. 然后- 有把握地标记为完成

示例：

❌错误示范："已添加健康检查命令。任务完成！" ✅正确示范："已添加健康检查。测试中... 检测到4个问题，自动修复了3个。已在损坏的测试数据上验证。任务完成！"

❌错误示例："已实现会话状态更新。完成！" ✅正确示例："已实现会话状态。使用标记进度、记录时间、标记受阻等功能进行了测试——均能正确更新。完成！"

这为何重要：智能体常基于“我编写了代码”而非“我验证了其有效性”来报告完成情况。基于验证的报告能防止错误完成并建立信任。

主动思维

核心问题：不要问“我应该做什么？”，而要问“什么能真正帮助我的用户，而他们自己还未想到要提出？”

自主任务处理

在心跳间隔期间，您有机会取得实际进展：

1. 检查下一项任务- 当前最高优先级的工作是什么？
2. 取得进展- 自主地为此工作10-15分钟
3. 更新状态- 诚实地追踪进度、时间和阻碍因素
4. 在重要时刻传递信息- 完成情况、阻碍因素、新发现（而非例行进度汇报）

转变在于：从等待指示 → 在共同目标上自主稳步推进

何时需要联系

在以下情况请务必联系你的对接人：

• ✅ 任务完成时（特别是当它能解除其他工作的阻碍时）
• ✅ 遇到阻碍需要输入/决策时
• ✅ 发现对方应当知晓的重要信息时
• ✅ 需要澄清要求时

请勿用以下信息刷屏：

• ❌ 例行进度更新（例如“目前完成50%...”）
• ❌ 每个微小子任务的完成情况
• ❌ 对方未询问的事项（除非确实具有重要价值）

目标是：成为主动推进事务的合作伙伴，而非需要不断确认的唠叨助手

任务状态

自主操作（第二阶段）

双模式架构

Proactive Tasks 支持两种不同的操作模式：

关键设计：避免中断

不要使用系统事件处理后台工作。当定时任务在主会话期间触发时，提示会被排队，工作不会执行。解决方法是：

• 使用心跳轮询（每30分钟）进行交互式检查和工作
• 使用隔离代理轮询（定时任务子进程）处理纯计算工作

这确保后台任务永远不会中断您的主要对话。

参见HEARTBEAT-CONFIG.md获取完整的自主操作模式，包括：

• 心跳设置（推荐用于大多数工作）
• 独立的定时任务模式（用于生成速度报告、清理等）
• 每种模式的适用场景
• 应避免的反模式

心跳集成

为了实现自主、主动的工作方式，你需要建立一个心跳系统。它会提示你定期检查任务并处理它们。

快速设置：请参阅HEARTBEAT-CONFIG.md以获取完整的设置说明和模式。

简而言之：

1. 创建一个定时任务，每30分钟向你发送一次心跳消息
2. 将主动任务检查添加到你的HEARTBEAT.md
3. 你将自动检查任务并处理它们，而无需等待提示

心跳消息模板

你的定时任务应每30分钟发送以下消息：

💓 Heartbeat check: Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.

添加到 HEARTBEAT.md

将此添加到你的工作空间HEARTBEAT.md会发生什么

## Proactive Tasks (Every heartbeat) 🚀

Check if there's work to do on our goals:

- [ ] Run `python3 skills/proactive-tasks/scripts/task_manager.py next-task`
- [ ] If a task is returned, work on it for up to 10-15 minutes
- [ ] Update task status when done, blocked, or needs input
- [ ] Message your human with meaningful updates (completions, blockers, discoveries)
- [ ] Don't spam - only message for significant milestones or when stuck

**Goal:** Make autonomous progress on our shared objectives without waiting for prompts.

这种转变：

Every 30 minutes:
├─ Heartbeat fires
├─ You read HEARTBEAT.md
├─ Check for next task
├─ If task found → work on it, update status, message human if needed
└─ If nothing → reply "HEARTBEAT_OK" (silent)

你从被动反应（等待指令）转变为主动进取（持续自主推进）。最佳实践

何时创建目标

长期项目（构建某个东西，学习某个主题）

• 重复性职责（监控X，维护Y）
• 探索性工作（研究Z，评估W的选项）
• 何时创建任务

将目标分解为以下特点的任务：

具体明确

• : "研究Whisper模型" 而非 "了解一下AI相关的东西"可一次完成
• : 15-60分钟的专注工作有明确的完成标准
• : 你知道何时算完成何时联系你的对接人

✅

在以下情况请务必联系：你完成了一个有意义的里程碑

• You complete a meaningful milestone
• 你需要输入/决策才能继续
• 你发现了重要信息
• 一项任务将比预期耗时更长

❌请勿频繁发送：

• 每个微小子任务的完成情况
• 常规进度更新
• 用户未询问的事项（除非相关）

管理范围蔓延

如果任务实际规模超出预期：

1. 将当前任务标记为进行中
2. 为发现的新环节创建子任务
3. 更新依赖关系
4. 继续处理可管理的小块任务

文件结构

所有数据存储于data/tasks.json：

{
  "goals": [
    {
      "id": "goal_001",
      "title": "Build voice assistant hardware",
      "priority": "high",
      "context": "Replace Alexa with custom solution",
      "created_at": "2026-02-05T05:25:00Z",
      "status": "active"
    }
  ],
  "tasks": [
    {
      "id": "task_001",
      "goal_id": "goal_001",
      "title": "Research voice-to-text models",
      "priority": "high",
      "status": "completed",
      "created_at": "2026-02-05T05:26:00Z",
      "completed_at": "2026-02-05T06:15:00Z",
      "notes": "Researched Whisper, Coqui, vosk. Whisper.cpp best for Pi."
    }
  ]
}

命令行参考

完整命令文档请参阅CLI_REFERENCE.md文件

演进与护栏

在提出新功能之前，请使用我们的VFM/ADL 评分框架对其进行评估，以确保稳定性和价值：

VFM 协议（价值频率乘数）

从四个维度进行评分：

• 高频使用（3倍权重）：此功能是否会被每日/每周使用？
• 减少故障（3倍权重）：此功能是否能防止错误或数据丢失？
• 用户负担（2倍权重）：此功能是否能显著减少人工工作？
• 自身成本（2倍权重）：此功能会增加多少维护成本/复杂性？

门槛：必须得分 ≥60 分才能继续推进。

ADL 协议（架构设计阶梯）

优先级顺序：稳定性 > 可解释性 > 可重用性 > 可扩展性 > 新颖性

禁止的演进：

• ❌ 为"显得聪明"而增加复杂性
• ❌ 无法验证的变更（无法测试是否生效）
• ❌ 为追求新颖而牺牲稳定性

黄金法则：“这是否能让未来的我以更低的成本解决更多问题？”若否，则跳过。

工作流程示例

第一天：

Human: "Let's build a custom voice assistant to replace Alexa"
Agent: *Creates goal, breaks into initial research tasks*

在心跳检测期间：

$ python3 scripts/task_manager.py next-task
→ task_001: Research voice-to-text models (priority: high)

# Agent works on it, completes research
$ python3 scripts/task_manager.py complete-task task_001 --notes "..."

智能体向人类发送消息：

“嘿！我已经完成了语音模型的研究。Whisper.cpp 看起来非常适合树莓派——本地运行、准确度高、延迟低。接下来需要我比较硬件选项吗？”

第二天：

Human: "Yeah, compare Pi 5 vs alternatives"
Agent: *Adds task, works on it during next heartbeat*

此循环持续进行——智能体在保持人类参与决策和更新的同时，持续稳定地自主推进工作。

由 Toki 构建，致力于打造主动型AI伙伴关系 🚀