任务规划器

缘起

去年读了不少关于 Agent 规划的论文，发现自己处于一种危险的状态：每个概念都「看懂了」，但没有一个真正属于我。判断的办法只有一个——亲手把它做出来。于是这个项目的目标从一开始就不是发布，而是搞清楚：规划到底难在哪里。

问题

给定一个多步骤任务（比如「整理本学期的课程笔记并生成索引」），规划器需要把它分解成可执行的步骤、在执行中发现计划的错误、并决定何时修订计划。听起来是工程问题，做起来全是认知问题：什么算「一步」？计划错了多少才值得推翻？

尝试与失败

第一版把计划做成静态的树，执行器严格按树行事。它在演示用例上工作得很好，在真实任务上活不过三步——现实世界的反馈会立刻让树过时。第二版走向另一个极端：完全没有显式计划，每一步都重新决策。它灵活，但会绕圈子，且无法向我解释它打算做什么。

「两次失败夹出了真正的问题：计划的价值不在于被执行，而在于让偏离变得可以察觉。」

这是我目前最重要的收获，它来自代码，而不是论文。

目前的设计

第三版把计划当作一份「会过期的备忘录」：执行器每一步都对照备忘录检查偏离程度，小偏离就地修正，大偏离触发重新规划。重新规划的频率成了一个可观测的指标——它意外地比成功率更能反映任务的真实难度。

还没想清楚的

如何让规划器对「自己不知道的事」保持诚实。目前它在信息不足时倾向于编造一个步骤，而不是承认需要先去查证。这大概会是下一篇笔记的主题。