目标模式与收尾

长任务最常见的失败方式不是答错，而是过早停下：模型说「基本做完了」，测试却从没跑过。mu 有好几样东西对付这个问题，都建立在同一份记录上：你真正要的是什么，也就是任务帧。

任务帧

任务帧记着目标、你的硬约束（你的原话，以及你在哪里说的）、当前子目标和验收条件。验收条件也是模型逐项勾掉的待办清单。

你发的每条消息都判定一次（task.frame）：新任务、新的硬约束、一次纠正、新的子目标，还是没有变化。只有发生变化时，才让模型重写任务帧，所以一句「谢谢」什么也不花。/frame 显示当前的任务帧。它跟着对话树走：分叉或回退之后，那个分支的任务帧会回来。

目标模式

/goal packages/api 的测试全部通过，并且 README 写明了新参数

代理立刻开始，一直干到条件成立。只输入 /goal 会显示目标、它的状态、上一次检查的理由和下一步；没有目标时，会问你要一个条件。/goal clear 结束目标。在桌面端，从发送框设定目标；目标栏显示它的状态。

每次代理想停下，都会有一个模型读证据并决定：达成、继续（带一个具体的下一步），还是需要你。证据包括：目标、还没完成的验收条件、改过之后还没检查的文件、最后一次测试、构建或 lint 的运行及结果、这次运行做了什么，以及收尾的那条消息。事实胜过说法：只要还有没完成的验收条件或没验证的改动，结论就一定是「还没有」，不管收尾消息怎么说。只有负责检查的模型没给出答案时，才由 Jev（goal.met）回答。

在下面这些情况下，它会自己停下，并告诉你原因：

暂停之后，你的下一条消息会让目标接着进行。重新打开的会话会把正在运行的目标带回来，但处于暂停状态，不会直接运行。

每一轮结束时的检查

没有目标时，每一轮仍然有这些检查：

• 完成核对（turn.completion）。模型说做完了时，mu 会问有没有什么验证过它。没有的话，提醒一次去检查，比如跑一下测试。
• 半路停下（turn.continue）。一次运行以「接下来我跑一下测试」结束却没去做，或者对你已经要它做的事还在问要不要动手，就会被送回去接着做，每条消息最多两次。难以撤销或超出这台机器的步骤，比如推送、发布、删除或付款，从不会这样推着去做。

跑偏和死路

• 跑偏监测（turn.drift）。每六次工具调用，mu 检查一次工作是否还在为目标服务。另一种失败是原地打转，由规则来抓：最近八次调用里，同一个调用出现三次。
• 判断回退（turn.rewind）。代理原地打转，或者一条命令一直失败时，判定器会问这条路是不是死路。只有确定是死路、又没有进展时，才会提议回到这一轮的检查点，并附上一条说明：试过什么、为什么放弃。提议会等你两分钟；你不回答，运行就继续。它从不自己回退。

手动回退

/checkpoints 列出当前分支的快照，最新的在前：编号、回合、时间、之后改了多少个文件。/rewind 退回到最新的一个，/rewind 3 退回到 3 号；它先显示哪些文件会被放回、删除或恢复，再问你要退回文件、对话，还是两者都退回。/rewind undo 撤销一次回退。更多见权限与安全。