14.4 常见误区与注意事项

面向经管学生、研究者与从业者的 AI 智能体设计教材

14.4 配图

/loop 语法简单，但使用时容易踩坑。以下是初学者最常遇到的几个误区。

误区一：把 /loop 当生产级调度系统

/loop 的定位是轻量守望者——适合短期监控、周期巡检、夜间跑批。它不是 crontab 的替代品，也不是 Airflow 或 Celery 这类生产调度系统的竞争者。

区分标准很明确：

需求	适合用 /loop	应该用其他方案
监控今晚的部署状态	✅
每天定时采集一周的宏观数据	✅
生产环境 7×24 小时监控		✅
跨团队共享的定时报表		✅

如果任务需要持久化、高可用、跨重启，应该使用 Claude Code Desktop 的 scheduled tasks、GitHub Actions cron trigger，或者传统的服务端调度系统。

定位口诀

/loop 是开发桌面上的闹钟，不是机房里的调度中心。用它做「今天盯一下」的事，不要指望它「永远帮你盯着」。

误区二：忘记会话级限制

这是最常见的翻车场景：花时间配好了 5 个 /loop 任务，然后关掉终端去开会。回来后发现所有任务都消失了。

/loop 的所有任务绑定当前终端 session。终端关闭、Claude Code 重启、电脑休眠后唤醒，任务都会消失。没有自动恢复机制。

应对办法：

• 把 /loop 命令记录在项目的 CLAUDE.md 或 README 中，下次启动时可以快速重新设置
• 对长期需要运行的任务，改用持久化方案
• 使用 tmux 保持终端 session 不中断（关闭笔记本盖子时 tmux session 仍然存活，前提是电脑没有进入休眠）

误区三：间隔设置过短导致 token 浪费

每次 /loop 触发时，Claude 都会消耗 token：读取上下文、执行任务、生成输出。如果把间隔设为 1 分钟，但任务本身只需要每小时检查一次，你就会白白消耗 60 倍的 token。

token 成本提醒

/loop 的每次轮询都产生 API 调用费用。设置间隔前，先问自己：这个任务多久检查一次才有意义？基金净值通常每日更新一次，设置 1 分钟轮询没有意义。宏观数据可能每小时更新，设置 5 分钟轮询也是浪费。间隔应该匹配数据源的更新频率。

间隔设置参考：

场景	建议间隔
部署状态检查	5-10 分钟
PR / CI 状态巡检	15-30 分钟
基金净值监控	1 小时
宏观数据采集	2-4 小时
每日汇总报告	24 小时

误区四：不配合权限模式使用

/loop 执行的任务可能涉及文件读写、命令执行等操作。如果 Claude Code 运行在默认的 Normal Mode 下，每次操作都需要用户手动确认权限弹窗——但用户可能已经离开了。

解决办法有两种：

1. Auto-Accept Mode：按 Shift+Tab 切换到自动接受模式，Claude 不再弹出权限确认
2. 预授权命令：在 ~/.claude/settings.json 中提前授权已知安全的操作

{
  "permissions": {
    "allow": [
      "Read(data/**)",
      "Write(output/**)",
      "Bash(python scripts/fetch_data.py)"
    ]
  }
}

预授权比全局跳过权限更安全：只放行明确需要的操作，其他操作仍然需要确认。

误区五：忽略抖动机制

/loop 的循环任务有最多 10%（上限 15 分钟）的随机延迟。设置 /loop 1h 并不意味着严格每 60 分钟触发一次，实际触发时间可能在 60-66 分钟之间浮动。一次性提醒也有最多 90 秒的偏移。

这个抖动是系统设计，目的是避免大量定时任务同时触发造成拥堵。对大多数监控和采集任务来说，几分钟的偏移不影响使用。但如果你的场景要求精确到分钟级的定时触发（比如在收盘前 1 分钟执行操作），/loop 不适合。