第 5 步，共 6 步

从 agent 外面看进度

任务做完了，和卡住不动，在一个安静的聊天窗里长得一样。把进度记在 agent 写不到的地方：文件、时间，或者一块看板。

发生了什么

不这么做要付什么

开一个长任务，一小时后回来，聊天窗跟刚才一模一样。没有报错，没有进度，没有答案。任务在第二十分钟就停了。一小时没了，活也本来就不会来。

同样的安静也会盖住一次真正的成功，于是你学会去打断本来没事的活。两种情况下你都在猜，而猜才是贵的那部分。

这样做

1. 开始之前先把交付物写下来。一个有名有姓的文件，落在指定的文件夹里，大小是你愿意收的。「做完」必须能从外面核对。
2. 要一份过程日志。「每做完一步，往 logs/progress.md 追加一行，带上时间。」日志是个文件，你不用问就能看。
3. 看文件的修改时间，不看聊天窗。查输出文件夹的修改时间。任务跑着，工作区十分钟没有变化，就当它卡住了。
4. 提前定好「算卡住」的规矩。你在等的活，十分钟；本来就该跑很久的，给更多。阈值写下来，免得决定是在你烦的时候做的。
5. 打断的时候问状态，不要重启。「报状态：第几步，卡在什么上，继续还是停？」重启会把已经做对的那部分丢掉。
6. 同时跑好几个，就用一块看板。一个任务一行，一个进度值，更新它的不是 agent 自己打的字。Brake Board 就是为这件事做的。

检查清单

• 交付物写明了，含文件夹和预期大小。
• agent 边做边往 logs/progress.md 写。
• 卡住阈值在任务开始前就写下了。
• 不碰 agent 也能查到最后的修改时间。
• 第一动作是问状态，不是重启。

常见错误

• 问「进展怎么样」。答案是拿困住的那个上下文生成的。「快好了」不是证据。
• 只在最后看一次。早早就卡住的活，和一路跑到底的活，终点一样：没有文件。差别只能从日志里看出来。
• 一个大任务包办一切。一个请求里二十步，进度只有一个值：零，或者完成。拆成五段，就能看见它停在哪儿。
• 不问，直接重启。重启再加上丢掉已完成的活，是应对卡住最贵的一种反应。

这一步需要什么

这一步的工具是 Brake Board。它在开发中，还没对试用者开放；候补页面写清了它现在停在哪一步。