让模型学会列清单 —— 规划和持久化

第四篇：让模型学会列清单 —— 规划和持久化

模型不是鱼，它的记忆不止 7 秒——但也没长到能记住 100 轮对话里的所有事。

那个经典的翻车现场

你：“帮我重构这个模块，分三步：第一步提取接口，第二步实现新逻辑，第三步迁移测试。”

模型：“好的，我来处理！”

第 5 轮对话后，模型突然开始写一个完全不相干的文件……它迷路了。

这不是模型笨。这是缺少短期记忆管理。最初的计划被挤到了不知道哪个角落。

s03 的解法：TodoManager + Nag Reminder

classTodoManager:def__init__(self):self.items=[]defupdate(self,items:list)->str:...defrender(self)->str:lines=[]foriteminself.items:marker={"pending":"[ ]","in_progress":"[>]","completed":"[x]"}[item["status"]]lines.append(f"{marker}#{item['id']}:{item['text']}")...return"\n".join(lines)

渲染出来：

[>] #1: 提取数据访问接口 [x] #2: 实现新的 Repository 类 [ ] #3: 迁移测试用例 (1/3 completed)

更有意思的是Nag Reminder——模型每 3 轮没用 todo 工具，就塞一条提醒：

rounds_since_todo=0ifused_todoelserounds_since_todo+1ifrounds_since_todo>=3:results.append({"type":"text","text":"<reminder>Update your todos.</reminder>"})

你不是强制模型做什么，你是给它一个信号，让它自己意识到该更新计划了。

s07 的进化：从 TODO 到持久化任务

s07 把 TODO 从内存列表升级为磁盘上的 JSON 文件：

{"id":1,"subject":"Extract database interface","status":"completed","blockedBy":[],"owner":""}

为什么要持久化？因为上下文压缩（s06）随时可能把你的对话变成一个摘要。如果任务只存在于 messages 里，一压缩就没了。

任务系统还加了依赖图：

[x] #1: 提取数据访问接口 [>] #2: 实现新的 Repository 类 [ ] #3: 迁移测试用例 (blocked by: [2])

规划工具的关键设计原则

Harness 提供结构化的状态管理。模型提供决策。两者各司其职。

坏的做法：框架强定 workflow，模型只是管道里的一环。
好的做法：提供状态管理工具，让模型自己规划。

又回到了那个核心思想：模型是司机。

从 TODO List 到任务板的进化链

s03: TodoManager（内存列表） s07: TaskManager（JSON 文件，依赖图） s11: 自主认领 + 任务板 s12: 任务 + Worktree 绑定（控制平面和执行平面分离）

下一篇：Subagent —— 进程隔离就是上下文隔离