第 5 步，共 6 步
从 agent 外面看进度
任务做完了，和卡住不动，在一个安静的聊天窗里长得一样。把进度记在 agent 写不到的地方：文件、时间，或者一块看板。
它是怎么出问题的
静默卡住看起来和正在干活一模一样。转圈还在转，窗口还在，日志二十分钟前就不长个了。你没去动它，怕打断会把活毁了；一小时后回来，中间什么都没发生。
难发现的原因是：agent 不在出故障的那一刻大声报错，它是在重试循环悄悄放弃的那一刻失败。能改变这一点的，是一个不用读完整段记录就能查的信号：一个还在变大的文件、一个步骤计数、一个时间戳。
案例 · 2026-11-13
这里两条习惯都是被沉默换来的。长任务只起一次、结束读一次——之前有个会话每走一步就去查正在跑的任务，把任务本来要省的时间全花在查上了。同一天又加了「同一命令连续失败三次就停手」，因为在聊天窗口里，卡死的循环和很慢的任务长得一模一样。两条都把「好了没有」换成 agent 之外的东西：进程列表、日志文件、带时间戳的产物。
不这么做要付什么
开一个长任务，一小时后回来，聊天窗跟刚才一模一样。没有报错，没有进度，没有答案。任务在第二十分钟就停了。一小时没了，活也本来就不会来。
同样的安静也会盖住一次真正的成功，于是你学会去打断本来没事的活。两种情况下你都在猜，而猜才是贵的那部分。
这样做
- 开始之前先把交付物写下来。一个有名有姓的文件，落在指定的文件夹里，大小是你愿意收的。「做完」必须能从外面核对。
- 要一份过程日志。「每做完一步，往
logs/progress.md追加一行，带上时间。」日志是个文件，你不用问就能看。 - 看文件的修改时间，不看聊天窗。查输出文件夹的修改时间。任务跑着，工作区十分钟没有变化，就当它卡住了。
- 提前定好「算卡住」的规矩。你在等的活，十分钟；本来就该跑很久的，给更多。阈值写下来，免得决定是在你烦的时候做的。
- 打断的时候问状态，不要重启。「报状态：第几步，卡在什么上，继续还是停？」重启会把已经做对的那部分丢掉。
- 同时跑好几个，就用一块看板。一个任务一行，一个进度值，更新它的不是 agent 自己打的字。Brake Board 就是为这件事做的。
| 聊天窗里 | 实际是什么情况 |
|---|---|
| 「还在做」 | 十二分钟没写任何东西。它在等一个你根本没看见的权限确认。 |
| 一条消息都没有 | 进程已经退出了。通常无声，偶尔在屏幕上方留一行报错。 |
| 一次工具调用之后长时间没动静 | 它在循环重试同一个失败的命令。 |
| 「做完了」 | 有时候是个计划，不是结果。查文件在不在、打不打得开。 |
检查清单
常见错误
- 问「进展怎么样」。答案是拿困住的那个上下文生成的。「快好了」不是证据。
- 只在最后看一次。早早就卡住的活，和一路跑到底的活，终点一样：没有文件。差别只能从日志里看出来。
- 一个大任务包办一切。一个请求里二十步，进度只有一个值：零，或者完成。拆成五段，就能看见它停在哪儿。
- 不问，直接重启。重启再加上丢掉已完成的活，是应对卡住最贵的一种反应。
这一步需要什么
这一步的工具是 Brake Board。它在开发中，还没对试用者开放；候补页面写清了它现在停在哪一步。
加入 Board 候补名单