1. 从「写提示词」到「写循环」Loop Engineering 到底解决什么问题Loop Engineering循环工程是 AI Agent 领域近期被频繁讨论的一个概念简单说就是你不再逐句给 Agent 写提示词而是设计一套能自动运转的循环系统让 Agent 自己找任务、自己执行、自己检查、自己记录直到目标达成。它适合已经用过 Claude Code、Cursor、OpenClaw 这类编程 Agent但发现「任务一复杂就得全程盯着」的开发者。过去的用法是这样的你写一段提示词Agent 回一段你看一眼再补一句再等它回。整个流程里人本身就是那个循环——你负责判断下一步、负责纠偏、负责决定什么时候停。任务简单时没问题但一旦涉及多文件改动、跑测试、修 CI你的打字速度、注意力和耐心立刻变成瓶颈。Loop Engineering 的思路是把「你」从循环里拿出来换成一个可复用的系统骨架。你定义一次目标、规则、检查信号和终止条件之后每一轮迭代由系统驱动。这跟 Prompt Engineering 的区别不是「提示词写得好不好」而是「谁来推进流程」——前者优化单次交互后者设计持续运转的机制。下面我会先讲清楚一个 Loop 由哪几部分组成再给出一份可以直接复制到本地的配置骨架最后跑通一个最小闭环示例并把我踩过的坑列出来。2. 一个完整 Loop 的六个核心组成在动手写配置之前先把概念对齐。一个能自己转起来的 Loop通常包含六个部分缺一个都会退化成「跑过一次的脚本」。任务自动化是整个循环的心跳。它决定循环什么时候启动、去哪里找待办任务。可以是一个定时任务也可以是一个监听事件比如新 issue 出现。没有自动化就没有循环。并行隔离解决的是多个 Agent 同时干活时的冲突问题。最实用的做法是用 Git 的 worktree给每个 Agent 开一个独立的分支目录各自改各自的文件互不干扰。Skills / 技能定义任务需要的流程和规范。把规则写进一个文件Agent 执行时就有了决策依据不用你每次重复交代。MCP 与插件负责让 Loop 真正连上外部工具——读 issue、查数据库、发消息、开 PR底层走 MCP 协议就能接进来。子 Agent的关键是职责拆分。写代码的 Agent 不要同时负责检查代码因为它容易「手软」。换一个指令不同、甚至模型不同的 Agent 来审查往往能查出更多问题。记忆用于持久化任务状态。把关键信息落到一个 markdown 文件里下次启动新对话时Agent 读一遍就知道背景不用你从头解释。把这六块拼起来就是一个完整的 Loop。下面进入实操。3. TaoToken 前置准备拿到可用的 API Key要让 Loop 里的子 Agent 真正跑起来你需要一个稳定的模型调用入口。这里用 TaoToken 作为接入层它提供统一的 API 地址兼容常见的对话与编码模型调用方式。第一步打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录账号。第二步进入控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 在 API Keys 页面创建一个新的 Key。建议给这个 Key 起一个能区分用途的名字比如loop-agent-dev方便后续排查是哪个循环在调用。第三步把 Key 保存到本地环境变量不要硬编码进脚本。Linux / macOS 下可以这样export TAOTOKEN_API_KEYsk-你的keyWindows PowerShell$env:TAOTOKEN_API_KEYsk-你的key第四步确认接入地址。API 基础地址是https://taotoken.net/api注意这个地址不带任何查询参数。后续在配置文件里填的就是它。如果你只是想先验证模型能不能正常对话可以直接用模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 试一句确认返回正常再进入下一步。如果你打算长期跑编码类循环建议了解一下 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它在高频调用场景下更划算。4. 可复制的 Loop 配置骨架这一节给出一个最小可运行的 Loop 骨架。它的逻辑是定时触发 → 扫描任务 → 为每个任务开 worktree → 子 Agent 执行 → 另一个子 Agent 审查 → 写回记忆文件。先建目录结构mkdir -p loop-demo/{skills,memory,scripts} cd loop-demo git init任务定义文件skills/task-rules.md这是给 Agent 的决策依据# 任务规则 ## 目标 修复仓库中失败的测试每次只处理一个失败用例。 ## 约束 - 不允许修改测试文件本身 - 每次改动后必须运行 npm test - 若连续两轮未通过停止并记录到 memory/blocked.md ## 完成信号 npm test 全部通过退出码为 0。循环主脚本scripts/loop.sh负责调度#!/usr/bin/env bash set -euo pipefail REPO_DIR$(pwd) MEMORY_FILE$REPO_DIR/memory/state.md MAX_ROUNDS5 for round in $(seq 1 $MAX_ROUNDS); do echo Round $round # 1. 开独立 worktree实现并行隔离 WORKTREE$REPO_DIR/../wt-round-$round git worktree add -b loop-round-$round $WORKTREE 2/dev/null || true # 2. 调用子 Agent 执行修复 cd $WORKTREE python3 $REPO_DIR/scripts/run_agent.py \ --role executor \ --rules $REPO_DIR/skills/task-rules.md \ --memory $MEMORY_FILE # 3. 调用另一个子 Agent 审查 python3 $REPO_DIR/scripts/run_agent.py \ --role reviewer \ --rules $REPO_DIR/skills/task-rules.md \ --memory $MEMORY_FILE # 4. 检查完成信号 if npm test /dev/null 21; then echo 任务完成退出循环 break fi cd $REPO_DIR doneAgent 调用封装scripts/run_agent.py把 TaoToken 接进来import os import sys import argparse import requests API_BASE https://taotoken.net/api API_KEY os.environ[TAOTOKEN_API_KEY] def call_model(role, rules, memory): system_prompt f你是 {role} 角色的 Agent。\n规则\n{rules} if os.path.exists(memory): with open(memory, r, encodingutf-8) as f: system_prompt f\n历史记忆\n{f.read()} resp requests.post( f{API_BASE}/v1/chat/completions, headers{Authorization: fBearer {API_KEY}}, json{ model: claude-sonnet-4-5, messages: [ {role: system, content: system_prompt}, {role: user, content: 请执行当前轮次的任务。} ] }, timeout120 ) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: parser argparse.ArgumentParser() parser.add_argument(--role, requiredTrue) parser.add_argument(--rules, requiredTrue) parser.add_argument(--memory, requiredTrue) args parser.parse_args() with open(args.rules, r, encodingutf-8) as f: rules_text f.read() result call_model(args.role, rules_text, args.memory) print(result)记忆文件memory/state.md初始内容# Loop 状态记录 ## 已完成 - 空 ## 阻塞项 - 空这套骨架的关键点在于executor 和 reviewer 是两个独立调用模型可以不同指令也不同。reviewer 不负责写代码只负责挑毛病这样能避免「自己检查自己」的放水问题。5. 验证请求与成功结果配置写完后先单独验证 API 调用是否通。用 curl 发一个最小请求curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 回复 OK 两个字母}] }正常返回类似{ choices: [ { message: { role: assistant, content: OK } } ] }看到这个结果说明 Key 和地址都没问题。接着跑循环脚本chmod x scripts/loop.sh bash scripts/loop.sh预期输出会按轮次打印每轮包含 executor 和 reviewer 的执行结果。当npm test返回 0 时脚本打印「任务完成退出循环」并跳出。此时查看memory/state.md应该能看到本轮做了什么、哪些任务被标记为阻塞。如果测试一直不通过脚本会在 5 轮后停止并把阻塞项写进记忆文件等你人工介入。这就是「关键节点留人把关」的体现——不是所有任务都适合完全甩手。6. 本篇常见错误排查报错一401 Unauthorized。大概率是环境变量没生效或者 Key 复制时带了空格。先echo $TAOTOKEN_API_KEY确认值存在再检查请求头里Bearer后面有没有多余字符。报错二git worktree add提示分支已存在。说明上一轮没清理干净。可以在脚本开头加一段清理逻辑git worktree list | grep wt-round | awk {print $1} | xargs -I{} git worktree remove {} --force报错三多个 Agent 改同一个文件冲突。检查是不是漏了 worktree 隔离或者两个子 Agent 被分配到了同一个目录。并行隔离是硬要求不能省。报错四循环跑满 MAX_ROUNDS 仍未完成。先看memory/blocked.md里记录了什么。常见原因是完成信号定义得太模糊比如「代码质量好」这种没法自动判断的目标。把信号换成可执行的检查比如测试退出码、类型检查清零。报错五reviewer 和 executor 结论总是一致。说明两个 Agent 的指令区分度不够。给 reviewer 的 system prompt 里明确写「你的职责是找出问题默认假设代码有缺陷」并考虑换一个不同的模型来审查。报错六API 调用超时。长任务容易触发超时把timeout调大或者在循环里加指数退避重试。不要无脑重试连续失败三次就记录并跳过。排查完这些你的最小闭环基本就能稳定运转了。想进一步验证不同模型在循环里的表现可以去模型对话页面 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 逐个试需要管理多个 Key 或查看调用量去 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 接入细节和参数说明看文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。如果你主要跑编码类循环Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 会更适合长期使用。