Agentic 工作流里，"等待"被重新定价了

Agentic 工作流里，“等待”被重新定价了

上周三下午，我让 Claude Code 重构一个数据导出模块。

指令发出去之后，终端开始跑。光标在闪，日志在滚，Agent 在一个个文件之间跳转。我盯着屏幕看了大概四十秒，然后下意识地打开了微信。

回了两条消息，刷了几条朋友圈，再切回来的时候，Agent 已经跑完了。终端里停着一大段输出，等我审。

我看着那段输出，发现自己需要重新进入状态——我让它做什么来着？哪些文件改了？改之前是什么样的？这些问题本来在我发指令的时候都很清楚，但三分钟的微信把上下文冲走了。我又花了五分钟重新读了一遍 diff，才接上之前的思路。

三分钟的等待，加五分钟的恢复。八分钟就这么没了。

那天我开始认真想一件事：在 Agentic 工作流里，“等待”到底是什么？它跟以前写代码时的等待，是同一种东西吗？

---

以前的节拍

写代码这件事，以前有一种很自然的节奏。

你想一下，敲几行，跑一下，看结果，再想一下。每个动作之间的间隔很短——几秒到几十秒。你的注意力始终在代码上，手指和大脑之间有一条热的连接。这个状态有个名字，叫心流。进入心流的前提是：反馈够快，任务够连贯，中间没有大段空白。

手写代码的节拍天然满足这些条件。IDE 的响应是毫秒级的，你打一个字符它就给你补全提示，你按一下 Run 它几秒钟就告诉你对不对。这种密集的、短间隔的反馈循环，让你可以持续几十分钟甚至几个小时保持专注。

这个节拍还有一个隐藏的好处：速度受限于你的思考速度。

听起来像是缺点。但正因为你每写一行都要想一下，你的理解和产出是同步的。你不会写出自己不理解的代码，因为每一行都是你脑子里先有了想法，手才去敲的。写完之后你对这段代码有完整的掌控感——哪里可能出问题、哪里做了妥协、哪里需要回头改——你都清楚。

这个节拍在 Agentic 工作流里被彻底打破了。

新的节拍

你发出一条指令，Agent 开始跑。

可能跑三十秒，可能跑十分钟。你不知道它什么时候结束，也不清楚它中间会做什么判断、最终改动哪些文件。你唯一能做的就是等。

这个等待跟以前的”编译等待”或者”测试等待”感觉完全不同。编译和测试的时候你知道在等什么——等一个确定性的结果。Agent 跑的时候你在等一个你自己都不完全确定会长什么样的产出。它有自主性，会在你没有明确指定的地方做出判断。

这种不确定性让等待变得焦虑。你会想打开终端看看它在干什么，看了又看不太懂（日志太多太快），看完又觉得自己在浪费时间。

于是你面对一个选择：这段等待期，你怎么用？

我观察自己和与身边朋友们的交流，看到了三种典型的反应。

有人全程盯着终端看。每一行输出都跟，虽然大部分看不出什么意义。好处是你不丢上下文——Agent 跑完的时候你知道它经历了什么，审查的时候更顺。代价是焦虑，而且时间全砸在里面了。

更多人会切出去干别的事。Agent 在跑，你去回消息、看文档、处理邮件。空闲时间不能浪费嘛。但代价就是我开头描述的那个场景：切回来的时候，你需要重新加载上下文。而人脑的上下文切换，远比你以为的贵。

还有一种看起来最聪明的做法：同时起两个甚至三个 Agent，让它们并行跑不同的模块。效率拉满——至少看起来是。

---

并行的幻觉

多 Agent 并行的问题值得展开说。

“我同时开三个 Agent”听起来很爽。一个在重构后端，一个在写前端组件，一个在跑测试修复。三路并进，效率拉满。

但你忘了一件事：Agent 可以并行，你的注意力不行。

三个 Agent 跑完之后，你面对三份需要审查的产出。每一份都需要你理解它改了什么、为什么这么改、有没有问题。如果每份都认真审，时间加起来比串行也省不了多少——审查的瓶颈始终在你的脑子，Agent 的速度再快也帮不上忙。如果为了”快”而每份只扫一眼，那你其实在用审查深度换并行宽度。

我有一次同时开了两个 Agent，一个改数据库查询逻辑，一个重构 API 层。两个都跑完了，我先审了数据库那个，花了十五分钟，改了几个地方，合并了。然后去审 API 那个——才发现它改的接口签名跟数据库那边刚合并的版本不兼容。两个 Agent 各自在自己的上下文里做了合理的决定，但它们之间没有对话。

这种冲突在串行工作流里不会发生——因为你做完一个再做下一个，后一个自然基于前一个的结果。并行把这个自然顺序打破了，冲突的成本就从零跳到了需要你手动排查和修复。

并行的上限不在 Agent 的算力，在你的注意力带宽。开三个 Agent，你的注意力就被切成三份。每一份都比你想象的薄。

等待期里真正值钱的事

那等待期到底该怎么用？

我后来慢慢摸索出了一种对自己有效的方式：把等待期当成审题时间。

Agent 在跑的时候，你手是空的，但脑子不需要空。这个窗口有一种独特的价值：你刚刚把任务想清楚、把指令写好、把上下文加载到脑子里——这些信息此刻全都是热的。

你可以利用这份”热度”做几件事。比如回头看一眼刚才给 Agent 的指令，想想有没有遗漏。你在发指令的时候往往急着开工，最容易忽略边界条件。Agent 跑起来之后，你反而有了一个冷却窗口。我有好几次是在这个窗口里想到”等一下，我忘了让它处理空列表的情况”，然后在 Agent 跑完之前就准备好了追加指令。

你也可以趁这个时间翻一下相关的文档或代码，提前了解 Agent 即将改动的区域。这样等它跑完的时候，你审查 diff 的速度会快很多——因为你已经有了预期，知道”对的”应该长什么样。带着预期去审和什么都不知道地去审，质量差别很大。

或者想一想接下来的步骤：如果这个任务跑完了，下一步是什么？需要测什么？有没有依赖关系？把这些想清楚，Agent 跑完之后你可以无缝衔接，不用再花时间规划。

这些做法都在利用你此刻最充沛的资源——对当前任务的上下文记忆。这个记忆有保质期。你切去干别的事，它就开始衰减。你刷三分钟手机，它就基本没了。

等待期最值钱的东西，是你脑子里还热着的上下文。

---

节奏感是一种新能力

以前写代码的节奏是天然的。你的手速就是节拍器——你能打多快、能想多快，就能产出多快。

Agentic 工作流把这个节拍打散了。你的工作变成了一连串判断：这个任务该串行还是并行？等待期里该盯着看还是提前想下一步？Agent 跑偏了是等它跑完还是果断杀掉重来？

这些判断没有标准答案，它们取决于任务的性质、你对代码库的熟悉程度、你当时的精力状态。但它们共同构成了一种新的工作能力：节奏感。

AI 不管你的节奏，它只管跑。你不主动掌握自己的节奏，它就替你定——而它的默认节奏永远是”越快越好”。

下次 Agent 在跑的时候，试试不切出去。就坐在那儿，想想你让它做的事情，有没有什么你忘了说的。那三分钟可能是你一天里最值钱的三分钟。