为什么需要 ask_user
很多 OpenClaw 任务是在无人值守的场景下跑的：凌晨 3 点的定时发文、后台长任务、子智能体批量处理。这些场景里 AI 最怕两件事：
- 瞎猜：拿不准的选项自己拍脑袋决定，结果跑偏。
- 静默失败：遇到歧义直接跳过，你第二天才发现没做。
ask_user 就是给 AI 留的一个「出口」——当它真的拿不准、且这个决定权属于你时，抛一个结构化问题（最多 3 个、每个最多 4 个选项）过来，等你选完再继续。它不是用来问「要不要继续」这种废话的，而是用来问只有你才说得清的选择。
口诀：能自己决定的就自己决定，把结果交给你；只有你才说得清的，才用 ask_user 问。
工具长什么样
ask_user 的核心参数就三个：
| 参数 | 含义 | 约束 |
|------|------|------|
| questions | 问题数组 | 1–3 个，每个问题最多 4 个选项 |
| timeoutSeconds | 等多久 | 默认 900，限制 30–3600 |
| multiSelect | 是否多选 | 默认 false（单选） |
每个问题对象必须包含：
id：蛇形命名、字母开头的回答键，例如target_channel
header：短标签（超 12 字符会被截断）
question：一句话问题（只放问题，选项放options）
options：2–4 个选项，每项有label（推荐项放第一个并加(Recommended)）和description
一个真实可用的调用
假设你在写一个多频道群发脚本，AI 拿不准该发到哪个外部会话：
{
"questions": [
{
"id": "target_channel",
"header": "发哪",
"question": "这篇 OpenClaw 周报要发到哪个外部会话？",
"multiSelect": false,
"options": [
{"label": "技术交流群 (Recommended)", "description": "日常分享，已开启免打扰"},
{"label": "内测反馈群", "description": "只发灰度内容"},
{"label": "先不发", "description": "存草稿，等我手动确认"}
]
}
],
"timeoutSeconds": 600
}返回结果是结构化的，AI 直接读 target_channel 字段拿你的选择，不需要再解析自然语言。
三个踩坑点
1. 别拿它当进度条
ask_user 是一次阻塞等待——在它返回之前，当前任务不往下走。所以：
- 高频轮询、心跳检查这类不要问，直接做。
- 只在「不选就一定会做错」的节点问。
- 超时（默认 15 分钟）后 AI 会按 best judgment 继续，所以别把关键 irreversible 操作放在超时后自动执行——那种应该在 ask 之前就停下。
2. 选项里别塞「其他」
工具的选项上限是 4 个，且不支持自定义 free-text 选项（自由输入由通道自动附加）。如果你觉得「可能需要其他」，说明这个问题还该再收敛——先把范围想清楚，再列选项。否则用户选不到想要的，反而更烦。
3. 推荐项永远放第一个
排序有心理暗示。把最省事 / 最稳妥的选项放第一并标注 (Recommended)，用户默认就点它，减少决策成本。但不要为了「让用户快点走」而把错误的默认项标成推荐。
和 cron 任务怎么配合
这是 ask_user 最实用的场景。cron 任务大多无人值守，但有些任务在边界情况下需要人拍板。两种做法：
做法 A：任务里直接 ask（适合需要你即时决策的）
定时任务脚本跑到歧义分支，调用 ask_user 等你选。代价是任务会卡住直到你回复或超时。
做法 B：先留档，再单独问（推荐用于发文类）
1. cron 跑脚本，遇到歧义先写进 QUEUE.md（不阻塞）
2. 第二天你上线，AI 读 QUEUE.md，用 ask_user 把待决项一次性问完
3. 你选完，AI 批量执行这样凌晨的任务永远能跑完，需要人判断的留到白天集中处理，不浪费夜间的安静窗口。
小结
ask_user是「人/AI 权责边界」的工具，不是聊天框。
- 1–3 问、每问 2–4 选项、推荐项置顶、不塞「其他」。
- 无人值守任务里：能自己定的自己定，关键不可逆的停下问，边缘歧义的先留档白天问。
- 超时后不要自动执行破坏性动作。
把它用对，你的 OpenClaw 既不会因为擅自决策翻车，也不会因为拿不准而静默罢工。
扫码关注公众号，获取更多 OpenClaw 实操技巧：
