结论先说：NanoClaw 能做的不是「确定性工作流编排」，而是「把自然语言判断接进消息渠道」的自动化。它有三条可落地的自动化主线——定时任务（到点跑一段 prompt）、多 Agent 协作（多个互相隔离、可互发消息的 agent group）、WhatsApp 作为控制台（手机离线也能收发）。三者共同的硬边界是：没有独立的调度守护进程、官方明确「没有 swarm engine」、也没有环路保护与并发上限。凡是需要可审计、可回放、步骤完全确定的流程，用 n8n / Zapier / Make 更合适；需要自然语言理解、跨工具临时判断、以消息为交互界面的场景，才轮到 NanoClaw；两者并用是常见形态。
这句定位不是营销话术，而是官方设计的结果。想先补产品全景，可看 NanoClaw 是什么；正如 NanoClaw 官网 的自述，它主打「one process and a handful of files」，目标是不用读懂半个仓库就能自行改造（来源：仓库 README）。本文只讲「机制 → 边界 → 选型」三件事，不复述站内 NanoClaw 核心功能 已覆盖的功能清单。
先说结论：哪类自动化该交给 NanoClaw
| 你的自动化需求 | 建议方案 | 理由 |
|---|---|---|
| 固定步骤、需审计与回放（对账、ETL、工单流转） | n8n / Zapier / Make | 确定性编排，可审计、可回放、沙箱化 |
| 到点跑一段带判断的 prompt（日报、巡检、提醒） | NanoClaw 定时任务 | 频率上限明确，退避与自动暂停机制齐全 |
| 多个角色协作、需要自然语言路由 | NanoClaw 多 Agent | 没有编排引擎，但有隔离 + create_agent + 投递边三原语 |
| 以聊天为操作台、手机端随时指挥 | NanoClaw + WhatsApp | 多设备 API，手机可离线 |
| 既要确定性又要 LLM 判断 | 两者并用 | 用 n8n 编排骨架，调用 NanoClaw 做判断节点 |
（第三方对比把这条分野概括为：确定性编排工具「deterministic, auditable, sandboxed」，Agent 类工具「LLM-driven and less predictable」，来源：clawdocs comparison。）
主线一：定时任务（Scheduled Tasks）
没有调度守护进程：任务就是收件箱里的一行
NanoClaw 没有独立的调度器进程。官方定义是「Scheduled tasks run an agent prompt at a future time or on a recurring cron schedule」，但其实现模型很朴素：任务是某个独立会话的 messages_in 表里的一行，kind='task'，带一个 process_after 时间戳，由主机扫描处理。主机对全部会话约 60 秒扫一轮（找到期任务、检测卡死、投递、生成下一次 recurrence）；有活跃容器的会话约 1 秒一轮，空闲容器最多保温 30 分钟（来源：scheduled-tasks guide、architecture）。
循环任务不是「循环」，而是「克隆」：一次执行完成后，插入携带同一 series_id 的新待执行行（来源：architecture）。每个任务归属一个 agent group，并在自己的 system session 中运行，与普通聊天分离。精度是约一分钟级的重同步，不是严格延迟保证，不要拿它做秒级精度的事。
两种计划类型：cron 循环与一次性
- cron 循环用
--recurrence，按 NanoClaw 安装时区求值；分组可用ncl groups config update <group> --timezone ...覆盖，无需重启。 - 一次性用
--process-after（ISO 8601 时间戳或本地时间，同样按安装时区解释），与--recurrence互斥；--recurrence null可把循环任务转成一次性。
ncl tasks create --group <agent-group-id> \ --name "weekday briefing" \ --recurrence "0 9 * * 1-5" \ --prompt "Prepare the weekday briefing and send it to telegram"（来源：scheduled-tasks guide、docs/scheduled-tasks.md）
脚本闸门：不唤醒模型的高频轮询
**脚本闸门（script gate）**是常被忽略的一环：在唤醒 Agent 之前先跑一段 Bash 脚本，由脚本决定要不要真的调用模型。脚本最后一行 stdout 必须是 JSON：
{"wakeAgent": false}—— 不调模型，直接结束（记为成功，不触发退避）；{"wakeAgent": true, "data": {...}}—— 唤醒 Agent，并把data追加进 prompt。
约束：只能用 Bash、30 秒超时、输出上限 1 MB、决策 JSON 必须在最后一行。它适合「高频轮询、但绝大多数时候无事发生」的场景——false 的决策不消耗 token（来源：docs/scheduled-tasks.md）。
三条硬限制
- 频率上限：未带闸门的循环任务，若 24 小时内触发超过 4 次会被拒绝。带闸门的任务可以更频繁；另有显式覆盖开关
--dangerously-override-recurrence-limit。 - 失败退避：超时、非零退出、缺失决策或 JSON 非法都算失败，连续失败会把下一次循环推迟 2、4、8、16、32、60 分钟。
- 自动暂停：连续 8 次失败后任务被自动暂停并记录原因，修复后用
ncl tasks resume恢复。
（来源：docs/scheduled-tasks.md、scheduled-tasks guide）
投递目标与管理命令
定时任务没有绑定任何聊天（「A scheduled task has no chat attached to it」），所以 prompt 必须自己写清投递目标，例如「发送到 telegram」。每次运行建议追加 work-log。管理命令为 list / get / update / pause / resume / run / cancel / delete，都可带 --group；cancel 结束系列但保留历史，delete 会连会话、邮箱历史、附件、日志一并删除。注意：模板自带的任务创建时是暂停状态，需要手动 resume（来源：docs/scheduled-tasks.md）。
主线二：多 Agent 协作（Agent 集群 / 团队）
官方立场：没有 swarm engine，只有三个原语
先纠正一个常见误解：NanoClaw 没有独立的集群编排引擎，官方文档直言「no swarm engine」。所谓「Agent 集群 / 多助手团队」，是由三个原语搭出来的：隔离（每个 agent group 完全隔离）、创建（create_agent）、通信（投递边）（来源：multi-agent-swarm）。
隔离与创建：create_agent 做了什么
隔离开到容器级：每个 Agent 有自己的容器、工作区、记忆，不共享状态，彼此之间「can only message each other」。
创建由 Agent 自己发起——调用 create_agent MCP 工具，传入 name 与作为 instructions 的角色文本。这调用是 fire-and-forget，之后宿主会：
- 插入
agent_groups行（folder = 归一化名称，重名加数字后缀）； - 脚手架
groups/<name>/； - 把指令写入新 Agent 的
instructions.prepend.md（spawn 时合成进它的CLAUDE.md）； - 新增一条继承创建者 provider 的
container_configs行； - 插入两条投递边，使关系「bidirectional from birth」。
关键细节：在新 Agent 收到第一条消息前，它的容器不会被启动（来源：multi-agent-swarm）。
通信与权限：无行不投递
Agent 之间的消息就是「queue rows」，走与 WhatsApp 消息完全相同的 SQLite 收发管道，只有 channel_type 不同（agent vs 平台）。权限由 agent_destinations 的行决定——「No row, no delivery」，宿主会拒绝未授权的发送。渠道与 Agent 共用命名空间，给某个 Agent 发消息就是 send_message 且 to 填它的名字。回程精确到会话：每条被路由的消息盖上发送方的 source_session_id，回复回到发起该次交流的父会话。
能否自由创建新 Agent，取决于调用分组的 cli_scope：向导创建的第一个 Agent 受信（cli_scope: global）可以直接创建；其他分组（如默认的 group）会触发排队审批卡，只有提升为 --cli-scope global 并重启后才能自由创建。此外可用 ncl policies set --from <source> --to <target> --approver <user> 把某条边上的所有消息挂起等人工批准——策略是有向的、仅运维可改，prompt injection 改不动（来源：multi-agent-swarm）。
三种典型拓扑
- 研究助手：接问题 → 搜网 → 带来源汇报；
- worker / manager / supervisor 三件套：worker 干活、manager 追踪在制并催办、supervisor 接你的 DM 并可主动 ping、用
ask_user_question弹按钮； - 按线程开会话：在 Discord / Slack 上用
--session-mode per-thread --threads true。
清理用 ncl groups delete --id <agent-id> 在单个事务里级联 sessions、双向 destination 行、待批审批、接线、成员关系、容器配置；但它不会杀掉正在运行的容器，也不删除 groups/<folder>/ 与 data/v2-sessions/<group-id>/。巡检整个团队就是查数据行：ncl groups list、ncl destinations list、ncl sessions list、docker ps --filter label=nanoclaw-install。
四个必须知道的坑
- 无环路保护：没有节流、没有跳数上限、没有环检测。两个互回的 Agent 会无限 ping-pong 烧 API 额度——必须自己写停止条件或加消息策略。
- 无广播：一条消息只有一个目标，扇出要逐个调用。
- 无并发上限：
MAX_CONCURRENT_CONTAINERS在 v2 已被彻底移除，宽团队＝每个活跃 Agent 一个容器，需按主机规格自行评估。 - 审批门：非受信分组创建 Agent 会卡在人工审批，自动化链路要提前规划。
（来源：multi-agent-swarm）
主线三：WhatsApp 作为控制台
多设备接入：手机可以离线
WhatsApp 接入走 multi-device API，连接独立于手机——手机可以离线，NanoClaw 仍能收发。它既可作主渠道，也可与 Telegram / Slack / Discord 并存作副渠道。鉴权三选一：浏览器二维码、终端 ASCII 二维码、或在「Link a Device」里输入的数字配对码。凭证本地存于 store/auth/，重启后存活，「reconnects automatically without needing to re-scan or re-pair」（来源：whatsapp skill）。
绑定与专用号：三种 wiring
每条绑定各配一个未知发件人策略与会话模式，三种绑定方式是：自聊天、联系人 DM（<phone>@s.whatsapp.net）、群组（<id>@g.us）。安装时会问号码是共享还是助手专用；专用号设 ASSISTANT_HAS_OWN_NUMBER=true。群组会自动发现并同步进数据库，聊天经 /manage-channels 或 /setup 挂到 agent group（来源：whatsapp skill）。
运维现实：三个会绊倒你的细节
- 二维码约 60 秒过期，会重新生成——配对要手快。
- 同一号码同一时间只能有一个活跃会话，否则报
Conflict——通常意味着别处的 WhatsApp Web 会话顶掉了当前会话。 - 限流比 Telegram / Discord 更严，很长的 Agent 回复会被拆成多条消息发出。
掉线会每几秒重试，会话永久失效则需重跑接入技能（来源：whatsapp skill）。
选型对照：NanoClaw vs n8n / Zapier
| 维度 | n8n / Zapier / Make | NanoClaw |
|---|---|---|
| 编排确定性 | 确定性、可审计、可回放、沙箱化 | LLM 驱动、灵活但可预测性低 |
| 触发模型 | 触发器 + 显式步骤 | cron / 一次性任务 + 脚本闸门 |
| 多角色协作 | 靠子流程与分支 | 靠隔离的 agent group + 投递边 |
| 交互界面 | 多为后台/表单 | 消息优先（WhatsApp / Telegram / Slack / Discord） |
| 失败处理 | 重试、错误分支 | 指数退避 + 连续失败自动暂停 |
| 成本结构 | 订阅/按任务 | 本体 MIT 免费，模型费单独计费 |
如果你需要的是「流程可审计、结果可回放、步骤完全确定」，选 n8n / Zapier；如果你需要的是「读懂自然语言、跨工具做判断、在聊天里指挥」，选 NanoClaw。站内另有一篇 同类方案对比 横向展开，可配合阅读。
成本与额度
NanoClaw 软件本体是 MIT 许可、免费。模型调用费用由所选 provider 单独计费，账单与 NanoClaw 分离（官方原话「Account billing is separate from NanoClaw」）。默认走 Anthropic 官方 Claude Agent SDK，也可用 /add-codex、/add-opencode、/add-ollama-provider 换成其它 provider 或本地模型。具体金额请以 provider 官方定价页为准，本文不列数字（来源：docs.nanoclaw.dev、README）。
版本提示：v1 与 v2 不要混用数字
网上关于 NanoClaw 的不少文章索引的是 v1。v2 在运行时、渠道、任务存储、并发上限上差异很大：v1 的单 store/messages.db、文件 IPC、MAX_CONCURRENT_CONTAINERS（默认 5）、groups/{channel}_{name}/ 约定，在 v2 已不存在（仓库 docs/reference/SPEC.md 顶部标注为 Historical v1 spec）。v2 的运行时是 Bun + Claude Agent SDK，渠道与 Agent 共用消息管道，并发上限被移除。看到「默认并发 5」「Node 20+」这类数字时，先确认它标的是哪个版本；本文所有数字均已标明为 v2（来源：SPEC.md、package.json）。
常见问题（FAQ）
- NanoClaw 有内置的定时任务调度器吗？ —— 没有独立守护进程；任务是收件箱里带
process_after的行，由主机约 60 秒扫描触发。 - 定时任务最短能多频繁地跑？ —— 无脚本闸门的循环任务默认每天最多 4 次，超过需挂闸门或显式覆盖；闸门决策为 false 时不消耗 token。
- 任务失败会怎样？ —— 按 2/4/8/16/32/60 分钟退避；连续 8 次失败自动暂停，修好后用
ncl tasks resume恢复。 - 「Agent 集群」是内置的集群编排吗？ —— 不是。官方明确没有 swarm engine，多 Agent 由「独立隔离的 agent group +
create_agent+ 消息投递」三个原语搭出。 - 两个 Agent 会不会互相无限对话？ —— 会。无环路保护、无跳数上限、无节流，必须自己写停止条件或加消息策略。
- Agent 之间怎么授权通信？ —— 靠
agent_destinations投递边，没有对应行宿主就拒绝投递；新 Agent 创建时默认与创建者双向可达。 - WhatsApp 必须让手机一直在线吗？ —— 不必，走多设备 API，手机离线也能收发。
- 同一个号码能挂几个 NanoClaw 实例？ —— 同一时间只能有一个活跃会话，否则报
Conflict。 - 用 NanoClaw 做自动化要花钱吗？ —— 软件本体 MIT 免费，模型调用费由所选 provider 单独计费。
- NanoClaw 和 n8n/Zapier 该怎么选？ —— 需要可审计、可回放、步骤确定的流程用 n8n/Zapier；需要自然语言理解、跨工具判断、消息优先交互的用 NanoClaw；两者并用也很常见。
想继续深入，可在 使用指南 栏目查看更多教程。
参考来源
- NanoClaw 官方仓库（权威）：https://github.com/nanocoai/nanoclaw
- 当前版本与 Node 要求：https://github.com/nanocoai/nanoclaw/blob/main/package.json
- 定时任务官方指南：https://docs.nanoclaw.dev/guides/scheduled-tasks
- 定时任务仓库文档（脚本闸门/退避/管理命令）：https://github.com/nanocoai/nanoclaw/blob/main/docs/scheduled-tasks.md
- 多 Agent 官方指南：https://docs.nanoclaw.dev/guides/multi-agent-swarm
- 架构（实体模型、收件箱/发件箱、扫描节奏）：https://docs.nanoclaw.dev/concepts/architecture
- WhatsApp 技能页：https://nanoclaw.dev/skills/whatsapp
- 官方文档首页（成本与额度分离）：https://docs.nanoclaw.dev/
- 确定性 vs LLM 驱动对比框架（第三方）：https://raw.githubusercontent.com/clawdocs/clawdocs.github.io/gh-pages/docs/reference/comparison.md