Agent 说"让我查一下"时，它在做什么
那次对话很短。Agent 说了一句："Let me check the current state."我回了一句："No scheduled jobs."
就这么两行。但这两行里藏着一个很有用的协作细节——一个关于状态检查时机和信息供给效率的判断。
"Let me check"不是空话
很多人看到 Agent 说"Let me check the current state"时，会觉得这是废话——你本来就应该知道当前状态，为什么还要"查一下"？直接基于已知状态做判断就行了。
实际上，这句话暴露了一个关键信息：Agent 在重新获取上下文。它不是在拖延时间，而是意识到自己可能没有足够的当前信息来做下一步判断。这个意识到自己信息不足的时刻，恰恰是协作的转折点——要么让 Agent 自己去查，要么你直接给。两种选择的时间和效果完全不同。
我的回复"No scheduled jobs"给了一个具体的反馈：当前没有定时任务。这个反馈替 Agent 省掉了它自己去查的步骤，直接把它从"获取状态"推到了"判断下一步"。从两步变成一步，每一步省几秒，累积下来就是几分钟。在频繁切换任务的场景里，这几分钟很值。
反过来，如果我当时不确定有没有定时任务在跑，我就不应该回答"No scheduled jobs"——因为错误的答案比没有答案更危险。Agent 基于"没有定时任务"做判断，如果实际上有定时任务在跑，后续所有判断都建立在错误的状态上。不如让 Agent 自己去查，花两秒跑一个 cron 列表，得到准确的状态。
状态检查的时机选择
这次经历让我注意到一个反复出现的模式：Agent 在对话开始或切换任务时，经常先做状态检查。这是好习惯——确保基于正确信息做判断。但问题是检查时机和方式的选择。
如果 Agent 在每次切换时都自动做一遍完整的状态扫描，对话会变得很慢。完整扫描意味着它要检查文件系统、运行环境、任务列表、配置状态——每项都可能花几秒到几十秒。如果你的对话里有十次任务切换，那就是十次完整扫描，总时间可能超过一分钟。
如果它不做扫描，又可能在错误的状态上做判断，导致后续所有操作基于过期信息。这种风险在长对话里尤其大——你以为某个文件还在，但上一个回合已经被删除了。你以为某个配置没变，但上一个回合 Agent 自己改了它。
我的做法是：不需要每次都让 Agent 做完整扫描。当你能快速给出关键状态信息时，直接给。比如"No scheduled jobs"就比让 Agent 自己去跑 cron 列表更快。一个 cron 列表查询至少要两秒，而我直接回答只需要零秒。
但如果你不确定当前状态，那就让 Agent 查。区别在于你是否比 Agent 更快地掌握关键信息。在定时任务这个场景里，我确实比 Agent 更快——因为是我自己设置的任务，我清楚有没有在跑。在文件系统的场景里，Agent 可能比我更快——因为它可以直接 ls，而我可能记不清目录结构。
提炼一个小方法
这个卡点提炼出的方法很小，但很实用，我在后续很多对话里都用到了：
当你看到 Agent 说"让我先查一下"时，判断你是否有比它更快的信息来源。如果有，直接给；如果没有，让它查。
判断标准很简单：
- 信息是人设置的（定时任务、配置参数）→ 人更快，直接给。因为这些信息是人自己创建的，人比 Agent 更清楚当前状态。
- 信息是系统生成的（文件状态、运行日志）→ Agent 更快，让它查。因为这些信息在系统里，Agent 可以直接访问，人需要回忆或手动检查。
- 信息是共享的（最近的对话内容）→ 看谁先拿到，通常人更快。因为人刚参与过对话，记忆还没过期。
这个判断不需要花时间思考，因为它是一个直觉级的决策。你看到"Let me check"时，大脑自动评估：我能不能比它更快？能就直接回答，不能就让它跑。整个过程不到一秒。
这个原则还可以反向应用：当 Agent 比 Agent 更快地掌握信息时，不要抢着回答。比如文件系统状态——Agent 可以用一秒钟 ls 一个目录，但你可能要回忆半天"那个目录里有没有那个文件"。这时候你应该让 Agent 查，而不是凭记忆回答。凭记忆回答可能出错，出错之后 Agent 基于错误信息做判断，后续所有操作都建立在错误基础上。让 Agent 用一秒钟查清楚，比你用十秒钟回忆更可靠。
小卡点的方法不一定有大格局的结论。但"No scheduled jobs"这句回复背后的判断逻辑——我能比 Agent 更快地给出关键信息，所以我直接给——是一个反复可用的协作原则。它让每一次状态检查都变得更高效。不是所有效率提升都需要大方法，有时候一个两秒的判断就能省下两分钟的等待。反向判断同样重要——当 Agent 更快时，不要抢答，让它查。两个判断加在一起，就是完整的"谁更快谁来提供信息"原则。