1. 从提示词工程师到 AI 系统架构师为什么你需要 Loop Engineering如果你已经能把单次提示词写得很好却依然觉得每天在重复“发现问题、拆任务、跑一遍、检查、记录、再继续”这套动作那你遇到的不是提示词瓶颈而是循环瓶颈。Loop Engineering 要解决的就是这件事把一串反复发生的动作设计成一个能自己转起来、还能在关键节点刹车的闭环系统。它适合已经会用 Agent 写代码、但想让 Agent 跨任务持续工作的开发者也适合正在从“提示词工程师”往“AI 系统架构师”迁移的人。ReAct 关注的是单次任务里的“感知、推理、行动、观察”也就是一个 Agent 怎么把一件事做完。Loop Engineering 关注的是外层多个任务怎么编排、状态存哪里、谁来验证、什么时候停。两者不是替代关系而是内外两层。内层 ReAct 负责执行外层 Loop 负责调度、验证和记忆。你过去优化的是内层的一句话现在要设计的是外层的一整套骨架。这篇会给你两样能直接复制的东西一份settings.json和一份config.toml骨架以及把 TaoToken 作为统一 Key 和 API 通道接进这套循环的步骤。最后给出循环调用的验证动作和一份报错排查清单。全程按“先手动跑稳、再包成循环”的顺序来不让你一上来就搭一个跑不动的全能系统。2. TaoToken 前置统一 Key 与 API 通道Loop Engineering 的第一个现实问题是循环会反复调用模型如果每个 Agent、每个子任务都散落着不同的 Key 和不同的接入地址你的状态文件和日志里会混进一堆难以追踪的调用来源。TaoToken 在这里的角色是统一入口——一个 Key、一个 API 通道让外层循环的调度层只需要认一个出口。你需要先拿到 Key。进入控制台创建 API Key建议按用途分 Key比如一个给主调度循环一个给验证用的独立评估器。这样后面做对抗验证时执行者和评审者用的是不同 Key日志里能直接区分也方便单独限流。控制台创建 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Key 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteAPI 基础地址用https://taotoken.net/api注意这个地址不带 UTM 参数直接写进配置即可。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 需要看模型列表和通道说明时从那里进。注意Key 只放在环境变量或本地配置文件里不要写进会被 Agent 读取并提交的仓库文件。循环系统最容易出的安全事故之一就是凭证被写进日志或状态文件后随代码一起提交。3. 可复制配置settings.json 与 config.toml 骨架这一节是全文的核心。我把它拆成两个文件settings.json管循环的调度、验证和状态config.toml管模型通道和 Key 引用。两者配合外层循环只读这两个文件就能跑起来。3.1 settings.json循环调度与状态骨架这份骨架对应 Loop Engineering 的六要素调度、工作树、技能、连接器、子智能体、状态文件。字段名保持直白方便你按项目改。{ loop: { name: ci-triage-loop, schedule: { mode: interval, interval: 30m, stop_condition: all_failures_classified_or_max_turns, max_turns: 30 }, worktree: { enabled: true, base_branch: main, per_agent_dir: .loop/worktrees }, skills: [ skills/repo-context.md, skills/test-commands.md ], connectors: [ { type: github, scope: issues,checks }, { type: ci, scope: failed_jobs } ], sub_agents: { executor: { model: claude-sonnet, role: edit_and_run }, verifier: { model: claude-haiku, role: independent_check } }, state_file: .loop/state/ci-triage.md, hard_gate: { commands: [npm run lint, npm run typecheck, npm test], must_pass: true } } }几个字段值得单独说。stop_condition是循环的刹车没有它 Agent 会一直转或者提前喊完成。hard_gate是硬闸门验证不通过就不允许进入下一轮这是防“假装干完了”的关键。sub_agents里执行者和验证者用不同模型天然形成对抗验证避免同一个模型自己检查自己的盲区。3.2 config.toml模型通道与 Key 引用config.toml负责把 TaoToken 的统一通道接进来。Key 从环境变量读不硬编码。[provider.taotoken] base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY default_model claude-sonnet [provider.taotoken.roles] executor claude-sonnet verifier claude-haiku [loop.runtime] state_dir .loop/state worktree_dir .loop/worktrees log_level info max_retries 3 retry_backoff exponential [loop.safety] deny_paths [.env, secrets/, *.pem] require_review_before_merge trueapi_key_env指向环境变量你在 shell 里export TAOTOKEN_API_KEY你的Key即可。deny_paths是安全红线防止循环把凭证文件读进上下文或写进日志。require_review_before_merge对应“你打算 review 它产出的代码吗”这个问题——不打算 review就别开自动合并。3.3 把两个文件接起来在循环入口脚本里先加载config.toml拿到通道再读settings.json拿到调度参数。伪代码逻辑如下import json, tomllib, os with open(config.toml, rb) as f: cfg tomllib.load(f) with open(settings.json) as f: loop json.load(f)[loop] os.environ[TAOTOKEN_API_KEY] os.environ[TAOTOKEN_API_KEY] base_url cfg[provider][taotoken][base_url] state_file loop[state_file]这样外层循环只依赖一个通道和一个状态文件换模型、换 Key、换调度节奏都只改配置不动业务逻辑。这就是从“写提示词”到“设计系统”的实际差别。4. 验证请求让循环真的转起来配置写完不代表能跑。先做一次手动运行确认单轮能稳定走完 Discover、Plan、Execute、Verify、Iterate再包成循环。这一步对应“先让一次手动运行稳定”。4.1 单轮手动验证先不接调度手动触发一轮观察状态文件有没有被正确写入。用 curl 直接验证 TaoToken 通道是否通curl https://taotoken.net/api/v1/messages \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet, max_tokens: 256, messages: [{role: user, content: 回复 OK 两个字母}] }返回里能看到正常内容说明 Key 和通道没问题。如果这里就报 401先别往下走去排查 Key。4.2 循环调用验证动作通道通了之后跑一轮完整循环重点看三件事状态文件是否更新、硬闸门是否被执行、验证者是否独立于执行者。# 手动跑一轮不接定时器 python run_loop.py --once --config config.toml --settings settings.json # 查看状态文件 cat .loop/state/ci-triage.md # 查看本轮是否触发硬闸门 grep -E lint|typecheck|test .loop/state/ci-triage.md状态文件里应该出现类似这样的记录# Loop state · ci-triage ## 上次运行 2026-06-09 03:30 UTC 7 个失败已分类3 个草拟修复4 个上报 ## 进行中 - fix-auth-token-refresh — 本地测试通过等 CI ## 今日完成 - bump-axios-1.7.4 → 已合并 ## 上报给人 - src/billing/refund.ts — 根因不明看到“上报给人”这一栏有内容说明循环知道什么时候该停、该交回给人这是设计对了的信号。如果所有失败都被标成“已修复”却没有验证记录那大概率是硬闸门没生效。4.3 接上调度单轮稳定后再把schedule.mode从手动切到interval或者接 cron。第一次接调度时把max_turns设小比如 5观察几轮没问题再放大。循环不是免费的它无论有没有产出都在消耗 token先用小步验证成本。5. 本篇常见错排查清单循环跑起来后翻车模式基本集中在几类。下面按现象、根因、处理来列。现象一Agent 提前发“完成”信号活干一半就退。根因是没有硬闸门模型自己判断“做完了”。处理在settings.json的hard_gate.commands里至少放一个客观验证命令must_pass设为 true验证不过不允许进入下一轮。现象二状态文件没更新下一轮从零开始。根因是状态外置没做对或者state_file路径写错。处理确认state_dir存在且可写每轮结束强制写一次状态不要依赖模型上下文记忆。现象三401 或 403。根因是 Key 没读到或权限不对。处理确认TAOTOKEN_API_KEY已 exportapi_key_env名字和实际环境变量一致分用途的 Key 不要混用。现象四429 限流。根因是循环并发太高或调度间隔太短。处理调大interval给执行者和验证者用不同 Key 分流max_retries配合retry_backoff做退避。现象五验证者和执行者结论总是一致。根因是两者用了同一个模型自我检查有盲区。处理sub_agents里执行者和验证者换成不同模型验证者用更小更独立的模型做对抗验证。现象六凭证出现在日志或状态文件里。根因是deny_paths没配或 Agent 读了敏感文件。处理把.env、secrets/、*.pem加进deny_paths日志里对 Key 做脱敏。现象七循环越跑越慢token 消耗失控。根因是技能没沉淀每轮冷启动重讲项目背景。处理把项目上下文写进skills/循环每轮加载技能而不是重新描述。注意无人值守的循环等于无人值守的攻击面。生成代码未审就上线、技能文件被注入、凭证泄露进日志、权限蔓延这四类问题在循环系统里会被放大。require_review_before_merge和deny_paths是底线配置不要为了省事关掉。6. 下一步把判断、验收和刹车留在自己手里Loop Engineering 的用法从来不是把人拿掉而是把人从重复劳动里抽出来。你设计的是调度、验证、记录和停止条件执行交给循环。过去比谁提示词写得好接下来比谁的循环设计得好。如果你还在单轮调试阶段先用模型对话把 ReAct 内层跑顺https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 。如果你要长期跑编码循环或 Agent 编排用 Coding Plan 把通道和额度固定下来https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入细节和参数说明都在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。先把一次手动运行跑稳再包成技能再包成循环最后才去接调度。顺序反了你会在一个跑不动的全能系统里 debug 到怀疑人生。