用途：在以多步骤方式处理请求时维护一份结构化、持久化的任务清单，显式跟踪进度、如实标记完成，并让计划可见。
何时使用：请求包含 3 个及以上不同步骤或动作、用户给出多个任务、工作跨越多次工具调用/文件编辑/研究阶段、计划较为复杂，或用户明确要求待办清单时，应主动使用。单一简单任务、纯对话或信息交流、可在不足 3 个简单步骤内完成、快速事实查询等场景可跳过。
数据结构：每个待办恰好含三个字符串字段：content（祈使形式，如 Run tests）、status（pending、in_progress、completed 之一）、activeForm（进行时形式，如 Running tests）。content 与 activeForm 均为必填。
主要接口：from todos import get_todos, write_todos, abandon, render。get_todos() 读取当前列表；write_todos() 一次写入整份列表并校验 schema，且最多只允许一个 in_progress；当全部完成时列表会自动清空；render() 用于显示；abandon() 丢弃剩余待办。
行为规则：同一时刻严格只允许一个 in_progress，开始任务前先将其设为 in_progress；工作真正完成时立即标记 completed，不要批处理；只有完全做完才可标记完成，若有测试失败、实现不完整或未解决错误，应保持 in_progress 并新增描述阻塞的任务；过时任务应整项移除而非标记完成；复杂任务需拆分为具体动作。
存储与限制：待办存储在 Muninn 的配置存储中，键为 active-todos（category=ops），可在同一对话的容器销毁后存活，并跨对话保留直至显式清除或全部完成时自动清空；跨对话持久化是刻意设计。已知限制：假定单一写入者，存储采用无锁的读-改-写，并发调用 write_todos() 时后写覆盖前写，不应在并发智能体中不加锁使用。列表为全局作用域而非按对话隔离；采用整表替换而非增量更新；复杂计划建议创建后向用户展示一次，之后以行内提及为主，避免频繁重渲染造成干扰。