长任务执行到一半，用户常会补充条件、撤销旧要求、把一项偏好提升为硬约束，或者直接换目标。系统若只是把新消息追加到上下文，模型就要每轮重新猜测哪些话仍然有效。早期产物可能继续引用已经撤销的需求，后台子任务也可能在旧目标上完成后回流。问题的核心是目标状态没有被显式维护。
可以把目标写成带版本的约束集合 ，每条新消息先解析为事件，再由归约函数更新状态：
事件可能新增、替换、撤销或条件化一条约束。更新完成后，系统还要找出依赖旧版本的计划、异步任务和产物，分别决定保留、重算或作废。版本号解决「它依据哪一版目标」，依赖关系解决「目标变化会污染哪些后继」。
1. 消息怎样变成目标状态
自然语言中的「然后」「顺便」「算了」并没有固定操作码。同一句补充在不同上下文里可能是并列要求，也可能覆盖原要求。因此解析器要保留来源文本和置信度，状态层再执行受约束更新。遇到冲突时，最近消息也不总能无条件获胜：权限、安全边界和已确认的不可逆操作具有更高优先级；某些修改只作用于一个子任务，不能覆盖全局目标。
演化意图的状态代数结合 Evolving User Intent 一类评测，把增加、更新、撤销、条件化和冲突写成可测试的状态转移。重点不在记住全部对话，而在得到一份能解释「当前究竟要什么」的有效目标，并能从事件日志复算同一结果。
2. 目标必须传播到计划和验收
状态更新若只停在一张表里，执行仍会沿旧路线继续。目标版本要进入计划节点、工具调用、子任务和验收器。异步结果返回时，系统检查它的输入指纹与当前目标是否一致；不一致的结果可以作为参考证据，却不能直接晋升为完成状态。计划重算也不等于全盘推倒，未受影响且已经验证的工作应当保留。
任务栈与验收器编译进一步处理目标切换、父子任务、授权与偏好的分离，并说明怎样把自然语言要求编译成可执行验收条件。读完这条路线，应该能设计三层测试：消息能否被正确解析，事件能否折叠成正确目标，目标变化能否真正取消旧动作并改变最终验收。
3. 为什么摘要无法独自解决意图演化
摘要可以把最新要求写得很短，却通常不保存约束之间的作用域和依赖。例如用户说「图片修复可以继续，正文改写停下」，一句「停止修改」若失去对象，就可能取消全部任务；一句「继续处理图片」若失去此前的文件范围，也可能扩大权限。显式状态会把动作、对象、条件和来源分开保存。摘要仍可作为模型的可读视图，但状态更新应由事件和规则决定。这样即使上下文被压缩、子任务延迟返回或会话重新开始，系统仍能回答哪条要求有效、它覆盖谁、哪些工作因目标更新而失效。