公众号名称：Datawhale

作者名称：王大鹏

发布时间：2026-06-25 22:05

Datawhale干货

作者：王大鹏，Datawhale成员

上一篇我们从控制论的视角拆解了 Loop Engineering 的结构。这篇动手——用 Claude Code 跑一个真实的 loop，看看”设计循环”这件事在实践中到底长什么样。

Claude Code 里 agent 被”唤醒”的几种方式

动手之前先对齐一个认知。很多人听到 Loop Engineering 会以为它只是 /loop 这一个命令。但在 Claude Code 里，agent 的自动化触发有好几种形态，它们共同构成了 Loop Engineering 的设计空间：

你可以用 /loop 让 agent 按时间表重复执行——每 5 分钟检查一次部署状态，每天早上 10 点审查 PR。你也可以用 /goal 设定一个目标，agent 持续工作直到达标或卡住——所有测试通过、构建成功、PR 就绪。你还可以配置 hooks，让特定事件确定性地触发脚本——agent 编辑了文件就自动跑 lint，一轮结束前自动验证构建。再进一步，主 agent 可以 spawn 子 agent 并行执行拆分后的任务，每个子 agent 带着自己的 goal 做验证循环。当你不确定拆分成什么类型的子agent什么时候拆分时，也可以用workflow来让LLM决定子agent的组合方式。

实际工作流里这些形态会组合使用。比如 How I AI 播客里演示的一个例子：一个 scheduled loop 每周五触发，主 agent 分析本周 PR 并识别缺失的 skill，然后 spawn 多个子 agent，每个子 agent 用 goal loop 验证一个 skill 是否真正可用。

本文聚焦在最基础的那一种——Scheduled loop（/loop），用一个完整的实践案例从设计到运行跑通。

场景：监控竞品公众号文章更新

一个关注 AI Agent 方向的公众号，有几个同领域的号想持续追踪，不是刷到了才被动看，而是有更新就知道。

没有 loop 时的做法是：想起来了就打开微信看看、或者用 RSS 工具扫一遍（微信公众号还需要额外转成RSS）。问题是被动靠推荐的触发不太靠谱，会错过一些时效性强的内容。

用 cron 脚本也能做。写个 Python 定时跑，抓到新文章存下来。但 cron 脚本是死的——公众号内容常常需要cookie token，过期了它就静默失败，你第二天才发现少了一天的数据，有些后知后觉。

用 loop 要做的事情是：让 agent 定时醒来、自己判断状态、自己决定做什么——正常就同步，异常就即时报告，而不是无脑执行然后挂掉。

工具准备

抓取用的是 wx-mp-rss-core，一个基于微信公众平台 API 的文章获取工具。它需要扫码登录拿到 token，token 会过期（通常能用3天）。

监控对象：Datawhale等两个 AI 方向的公众号。

cd /path/to/wx-mp-rss-core
# 扫码登录，token 写入 wx_token.json
python3 examples/login_example.py

登录后 wx_token.json 里有两样东西：token（拼在 API URL 里的参数）和 cookies。

设计 loop prompt

在 Claude Code 交互模式里输入：

/loop 30m 你是一个公众号文章同步 agent。工作目录是当前目录。
每次被唤醒时执行以下决策流程：
1. 读取 sync_state.json 检查上次状态
- 如果上次是 token_expired：先测试 token 是否恢复，未恢复则报告"仍在等待扫码"并退出本轮
- 如果上次是 success：继续正常同步
2. 用 wx_token.json 凭证请求两个公众号的最新文章：
- Datawhale (fakeid: MzIyNjM2MzQyNg==)
- 精神抖擞王大鹏 (fakeid: MzI5MjQzOTY3OA==)
3. 对比 sync_state.json 的 known_articles，识别新增文章
4. 根据结果决策：
- API 返回 ret=200003/invalid session → 状态改为 token_expired，通知用户扫码，不重试
- 有新文章 → 更新 sync_state.json，输出新文章标题
- 无新文章 → 简短报告"无更新"
5. 更新 sync_state.json（含 status, last_check_time, known_articles, check_count）

输入回车。Claude Code 立刻做了两件事：

1. 创建了一个 cron job（*/30 * * * *），每 30 分钟触发一次

2. 立刻执行第一轮

▲ /loop 命令输入后 Claude Code 创建 cron 调度并立即执行第一轮

第一轮：正常同步

第一次执行时，agent 做了这些：

✓ 读取 sync_state.json → 状态 success，继续
✓ 请求 Datawhale API → ret:0，成功
✓ 请求 精神抖擞王大鹏 API → ret:0，成功
✓ 对比 known_articles → 发现 2 篇新文章
✓ 更新 sync_state.json

输出：

📋 首次同步结果 — 发现 4 篇新文章
Datawhale：
1. 刚刚，全网爆火的Loop Engineering，保姆教程来了！
2. 一文搞懂！Loop Engineering的进化史和本质
精神抖擞王大鹏：
1. 从源码拆解 Claude Code 的记忆体系：它是怎么记住你说过的话的
2. Claude Code 详解：Dynamic Workflow 编排机制
Token 状态正常，sync_state.json 已初始化。后续每 30 分钟自动检查新文章。

▲ 第一轮正常同步结果：发现新文章并自动触发下一轮

状态文件更新为：

{
"status": "success",
"last_check_time": "2026-06-24T22:44:00",
"check_count": 1,
"articles_synced": 8,
"known_articles": [
"一文搞懂！Loop Engineering的进化史和本质",
"刚刚，全网爆火的Loop Engineering，保姆教程来了！",
"《Datawhale香蕉书》出版了！",
"从源码拆解 Claude Code 的记忆体系...",
"..."
]
}

到这一步，跟 cron 脚本没有本质区别。区别从第二轮开始。

第二轮：无更新时的极简响应

2 分钟后（demo 里用了 /loop 1m 加速），loop 自动触发：

✓ 读取 sync_state.json → 状态 success
✓ 请求两个公众号 → 成功
✓ 对比 known_articles → 无新增

输出只有一行：

📋 同步结果：无更新
两个公众号最新文章均已在 known_articles 中，本轮无新增。第 2 次检查完成。

状态文件只改了 check_count: 2 和 last_check_time。

这里的关键不是”它报告了无更新”——而是它知道什么时候不该做事。cron 脚本每次都全量执行完整逻辑；这个 loop 在”没有新东西”时，决策路径最短，token 消耗最低。

Token 失效：loop 和 cron 的区别

微信公众平台的 token 几小时就过期。当 token 失效时，API 返回 {"base_resp":{"ret":200003,"err_msg":"invalid session"}}。

cron 脚本遇到这个会怎样？

取决于你的错误处理写了多少。大多数人的脚本：报错 → 退出 → 日志里躺着一行 traceback → 你明天发现数据断了一天。

loop 遇到这个会怎样？

我们用 Claude Code 跑了一次 token 失效的场景。agent 的反应：

✓ 请求 API → 返回 ret=200003
✓ 判断：这不是内容问题，是凭证过期
✗ 不重试（关键决策）
✓ 更新 sync_state.json：status → "token_expired"
✓ 输出：⚠️ Token 已过期，需要重新扫码登录微信公众平台

状态文件：

{
"status": "token_expired",
"last_check_time": "2026-06-24T22:45:00",
"error_detail": "API returned ret=200003 (invalid session)",
"check_count": 1,
"known_articles": [...]
}

▲ Token 失效后 agent 的降级处理：标记状态、通知用户、下一轮自动检测恢复

下一次 loop 被唤醒时，它不会盲目重试 API。它先读状态文件，看到 token_expired，于是先做一次轻量检测（调一个简单 API 试 token 是否恢复），未恢复就直接退出：“仍在等待扫码，本轮跳过”。

当然这只是现状，你完全可以在prompt后续加上一个外部的通知机制，然后来即时的重新扫码，续上下一次loop动作。

这就是上一篇文章里说的控制器判断力：同样是”执行失败”，agent 区分了”是内容层面的问题（值得重试）“还是”基础设施层面的问题（需要人介入）“。这个判断不在调度器里，在 prompt 里。

从源码看 /loop 到底做了什么

读了 Claude Code 的源码，/loop 的机制很简单，本质就是cron+prompt。

用户输入: /loop 30m 
↓
loop.ts 解析: interval=30m → cron="*/30 * * * *"
↓
CronCreate: 创建定时任务, recurring=true
↓
立刻执行一次 prompt（不等第一个 tick）
↓
cronScheduler.ts: setInterval(check, 1000) 每秒检查
↓
到期 → onFire(prompt) → 注入消息队列 → agent 开始新 turn

就这些。没有 evaluator，没有自动判断”是否达标”的系统组件。/loop 做的事就是 定时唤醒prompt。

那”判断是否达标”、“决定继续还是停止”、“区分错误类型”这些智能从哪来？

在你设计的 prompt 里。

循环的”智能”不在基础设施里，在你写的那段 prompt 里。调度器只做一件蠢事：到时间了，把 prompt 塞给 agent。但那段 prompt 承载了一整套决策逻辑——什么条件下该做事、什么条件下该停、什么条件下该喊人。

Loop的第一步是先写skills

整个 demo 里，Claude Code 做的事情其实不复杂：调 API、比对列表、写文件。任何 Python 脚本都能做。

区别在异常处理的设计方式。

Loop prompt 的异常处理是运行时判断——agent 看到一个未预见的返回值，它能基于对上下文的理解做出合理决策，即使你没有在 prompt 里逐一列举所有错误码。

所以这是在之前的文章里说的，设计Loop首先的流程不是loop本身的六大组件，而是处理问题的那个skill，你得先有解决问题的方法。

一起“点赞”三连↓

---

内容效果不满意？点此反馈