Claude Code 的 /loop 定时任务，能让一个 Agent 按固定节奏自己醒过来干活。我拿它做过一件事：盯着 itwanger/PaiAgent 仓库的 open issue，每 30 分钟扫一遍，对没人回复的问题生成答案并提交评论。第一次跑通挺爽，第二天复盘才发现真正的成本在哪里——这个 loop 每一轮都要完整走一遍「读 issue 列表 → 判断哪些没回复 → 读 README 补上下文 → 生成回复 → 调 gh 提交评论」，四轮下来模型调用次数就是单次的 4 倍，八轮就是 8 倍。Prompt Engineering 时代你调好一句话就结束了，Loop Engineering 时代你要为一个会自己转的系统负责，Token 消耗是按轮次累积的，而不是按你问了几句话来算。
1. 从 Prompt 到 Loop：一个会自己转的 Issue 回复机器
1.1 这个 loop 每轮到底在做什么
先把任务说清楚。itwanger/PaiAgent 是一个工作流编排项目，仓库里有几条 open issue 一直没人回，比如 #6 问项目开发完了没、#5 问它和 PaiFlow 有什么区别、#4 问能不能二开。这些问题不复杂，但都需要结合项目 README 和仓库元信息才能答准，靠模板回复只会显得敷衍。这种「高频重复、规则明确、有明确完成标准」的活，正是 loop 该接管的场景。
一条命令就能把它挂起来：
/loop 30m 检查 itwanger/PaiAgent 仓库的 open issue，对没有回复的 issue 根据项目 README 和已有信息生成准确的回复并提交评论。已回复过的跳过，不要重复评论。
拆开看，30m 是心跳频率，中间那段自然语言是每轮的作业指导书。Agent 第一轮会调 gh issue list 拉全部 open issue，再逐个 gh issue view 看已有评论，把有 owner 回复的跳过，剩下三条标记为待处理；然后读 README 补齐上下文，逐条生成回复，最后用 gh issue comment 提交。整轮结束，30 分钟后再来一次。
1.2 Loop Engineering 的六个部件在这个场景里各占什么位置
按照 Loop Engineering 的思路，一个真正的 loop 通常由定时任务、Worktree、Skill、MCP、Sub-agent、Memory 六块拼起来。回 Issue 这个场景用到了其中四块：定时任务负责唤醒，GitHub CLI 或 GitHub MCP 负责跨系统读写，README 和仓库信息充当 Skill 提供项目知识，而「已回复过的跳过」实际上是一种最朴素的 Memory——Agent 通过检查已有评论判断自己上一轮干到哪了。
Worktree 和 Sub-agent 在这里用不上，因为不涉及并行改代码，也不需要 maker-checker 分离。但你要知道它们的存在：一旦 loop 从「回评论」升级到「顺便把 issue 里提到的 bug 修掉」，Worktree 隔离和子 Agent 写查分离就必须补上，否则文件冲突和自评自审是迟早的事。
1.3 真正让人肉疼的是轮次成本
问题就出在这里。假设每条 issue 的上下文加上 README 大约 8k token，一轮完整处理三条 issue 加上工具调用的往返，模型侧可能要跑十几次请求。你挂着 30m 的节奏，一天就是 48 轮。更糟的是，如果 Agent 每一轮都重新读一遍全部 open issue 的评论来「判断是否已回复」，那前期没回复的 issue 会一直被扫，历史越长扫得越多，而真正需要它做的活可能早就在第一轮干完了。
所以这个 loop 跑得越久，你越需要两样东西：一个能看清每轮消耗的入口，和一把能随时吊销的钥匙。这也是为什么我把它接到 TaoToken 上跑——模型调用统一从一把 Key 出去，轮次一多也不至于连账都对不上。
2. Key 前置：让每一轮 loop 的模型调用都从同一把钥匙走
2.1 创建 Key 的完整步骤
打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，登录后进入控制台。左侧找到 API Keys 入口，直接访问 https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys 也行。
点创建，给这把 Key 起个能认出来的名字，比如 claude-code-loop-issue。名字别偷懒写 test，等你手里有三五把 Key 的时候，回头看日志根本分不清哪把在跑哪个任务。创建完立刻复制，格式是 sk- 开头的一串字符，页面通常只完整显示一次，关掉就得重建。
顺手把 Base URL 记下来：https://taotoken.net/api。注意它只到 /api 为止，后面不要再手拼 /v1，客户端自己会补。
2.2 为什么 loop 场景更要管好这把 Key
单次对话的 Key 泄露了，损失是有限的；一个每 30 分钟自动跑一轮的 loop，Key 一旦写进仓库被推到公开仓库，等于把你的账单挂在墙上。所以规矩很简单：Key 只进环境变量或本地配置文件，绝不进 Git；.env 写进 .gitignore；命名带用途，出问题能立刻在控制台吊销重建。
另外，loop 每轮都会产生模型调用，Key 是唯一能把「哪一轮烧了多少」串起来的东西。轮次越多，这个入口越值钱。
3. 可复制配置：Base URL 和 Key 落到 Claude Code
3.1 环境变量方式（推荐给临时排查）
# 写入 ~/.zshrc 或 ~/.bashrc，不要写进项目仓库
export ANTHROPIC_BASE_URL="https://taotoken.net/api"
export ANTHROPIC_AUTH_TOKEN="sk-替换成你刚创建的那把Key"
# 让当前终端立刻生效
source ~/.zshrc
# 只打印前 8 位确认变量生效，别把完整 Key 贴到任何聊天窗口
echo "${ANTHROPIC_AUTH_TOKEN:0:8}"
ANTHROPIC_BASE_URL 决定请求发去哪，ANTHROPIC_AUTH_TOKEN 决定用哪把钥匙。两个都设好，Claude Code 启动时就不会再去读官方默认地址。
3.2 settings.json 方式（推荐长期挂着 loop）
如果你打算让这个 loop 长期跑，环境变量写在 shell 里的缺点是换个终端就没了。更稳的做法是写进 Claude Code 的配置文件 ~/.claude/settings.json：
{
"env": {
"ANTHROPIC_BASE_URL": "https://taotoken.net/api",
"ANTHROPIC_AUTH_TOKEN": "sk-替换成你刚创建的那把Key"
}
}
改完重启 Claude Code 会话，配置才会重新加载。这个文件在用户目录下，不在项目里，也就不存在误提交的问题。
3.3 把 /loop 命令挂上去
配置就绪后，回到项目目录，先确认 gh 已认证：
gh auth status
gh issue list --repo itwanger/PaiAgent --state open --json number,title,comments
第二条命令会返回一个 JSON 数组，每个元素带 number、title、comments 三个字段。这一步是给 Agent 提前确认「工具链是通的」，免得 loop 跑起来才发现 gh 没登录，每轮都在那儿重试。
然后启动 Claude Code，输入：
/loop 30m 检查 itwanger/PaiAgent 仓库的 open issue，对没有回复的 issue 根据项目 README 和已有信息生成准确的回复并提交评论。已回复过的跳过，不要重复评论。
间隔支持 m 和 h，最小 1 分钟，不写间隔默认 10 分钟。30m 意味着每半小时唤醒一次 Agent，这个值不要设太小，loop 的问题从来不是不跑，而是跑得太勤。
4. 验证：先打一发 curl，再看评论是否落地
4.1 先确认这把 Key 通不通
别急着挂 loop，先用一次直接请求确认链路。如果你的 Key 是从控制台新建的，这一步能帮你把 401 和 404 提前排掉：
curl -sS "https://taotoken.net/api/v1/messages" \
-H "x-api-key: $ANTHROPIC_AUTH_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-4-5",
"max_tokens": 64,
"messages": [{"role": "user", "content": "只回复两个字：通了"}]
}'
正常情况下你会拿到一段 JSON，里面 content 数组的第一项文本就是模型回复。如果返回里带 authentication_error，问题在 Key；如果返回 not_found 或提示路径不存在，八成是 Base URL 写多了或写少了。想让结果更好读，末尾加 | python3 -m json.tool 格式化一下。
4.2 手工跑一轮同样的任务
在挂 loop 之前，先不带定时器手动跑一遍自然语言任务，观察 Agent 这轮实际调了哪些工具。你会发现它的执行路径大致是：gh issue list 拿全量 open issue，逐个 gh issue view <number> --json title,body,comments 看评论，跳过分不清的，剩下的读 README 生成回复，最后逐条提交：
gh issue comment 6 --repo itwanger/PaiAgent --body "项目目前仍在持续开发中..."
gh issue comment 5 --repo itwanger/PaiAgent --body "PaiAgent 和 PaiFlow 的定位不同..."
gh issue comment 4 --repo itwanger/PaiAgent --body "当然可以，PaiAgent 是开源项目..."
手工这一轮的意义是成本可控，你能看清每步的实际输出，再决定要不要交给 30 分钟的心跳。
4.3 看 loop 有没有真的把评论写进去
判断标准只有一个：issue 下面是否出现了 Agent 提交的评论。用下面这条命令直接抽评论正文：
gh issue view 6 --repo itwanger/PaiAgent --json comments --jq '.comments[].body'
三条回复的质量应该是可以看的：问进度的会说明项目在持续开发、列已完成模块；问区别的会从架构层面区分轻量单体与微服务定位；问二开的会给出 Fork 后保留引用说明的流程。这些内容来自 README 和仓库元信息，而不是套话模板。如果发现评论是空的、重复的或者明显答非所问，直接看第 5 节。
5. 本篇常见错排查
| 现象 | 常见原因 | 处理方式 |
|---|---|---|
| 401 / authentication_error | Key 复制时带了空格、引号，或误用了别处的 Key | echo "${ANTHROPIC_AUTH_TOKEN:0:8}" 比对前缀，重新从控制台复制 |
| 404 或 model not found | Base URL 写成了 https://taotoken.net/api/v1 | 只保留到 /api，版本路径交给客户端拼 |
| loop 不启动 | 间隔写法错误，比如写了 30 没带单位，或小于 1 分钟 | 改成 30m 或 1h 这类带单位写法 |
| 同一个 issue 被反复评论 | prompt 里漏了「已回复过的跳过」 | 把防重条件补进命令原文，改完手工验证一轮再挂定时 |
| 每轮都在重试、消耗异常 | gh 未认证或权限不足，Agent 一直重试同一个调用 | 先跑 gh auth status，在 loop 之外把工具链修好 |
| 每轮都重读一遍 README | 项目知识没有沉淀，上下文没复用 | 把关键背景写进 CLAUDE.md 或 Skill 文件，减少每轮重复读取 |
| 跑了几轮就不动了 | 会话被中断，或达到迭代上限 | 检查上限设置，重启会话后重新挂 loop |
排查的核心思路是先区分「模型侧问题」还是「工具侧问题」。curl 那一步能通，说明模型侧没问题，剩下的 401 之外的报错基本都在 gh 或路径上。另外，不要一上来就把间隔改成 5m 去「加快验证」，排障阶段手动跑一轮比定时跑十轮更省事。
6. 把 Key 和 loop 一起管起来
配置这件事只有落到具体页面上才算闭环。Key 的创建和轮换在 https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys ，参数细节和不同客户端写法看接入文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc ，专门给 Claude Code 的那份在 https://taotoken.net/doc/claudecode-anthropic?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=claudecode-anthropic 。想单独确认某个模型通不通，去 https://taotoken.net/model-chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=model-chat 直接发一句话比改配置快得多。
如果这个回 Issue 的 loop 只是你日常开发里的一环，后面还想挂代码审查、CI 失败自动排查、依赖升级这类常驻任务，可以考虑 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding-plan ，把长期跑的几个 loop 放在同一个节奏里管理比一把 Key 到处散着用省心。
最后留个我自己的习惯：每次改完 /loop 的 prompt，先手动跑一遍同样的自然语言任务，看它这轮调用了哪些工具、读了多少上下文、提交了几条评论，确认输出符合预期，再挂上 30m 的节奏。定时任务真正麻烦的地方从来不是它不跑，而是它跑得太勤快，而你还没来得及发现问题。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
