1. 为什么你的多代理协作总是跑一半就散架LoopEngineering 这个词最近被聊得很多但真正动手把 Automations、Sub-agents、Worktrees、Skills 串成一条能跑的链路时大部分人卡在同一个地方每个代理各自拿着不同的 Key、不同的 base_url、不同的鉴权方式配置散落在四五个文件里跑起来互相打架。你以为是逻辑问题其实是通道没统一。这篇要解决的就是这件事。核心思路很简单用 TaoToken 的统一 Key 和 API 通道把 Automations 的触发层、Sub-agents 的调度层、Worktrees 的隔离层、Skills 的挂载层全部收口到一套凭证体系下。你不需要在每个代理里重复填 Key也不需要为每个子代理单独维护一份环境变量。一份 config.toml 加一份 settings.json就能把多代理协作链路跑通。适合谁看已经在用编码代理做自动化、手上有多个子任务需要并行、被 Worktree 切换和子代理鉴权折腾过的人。如果你还没搭过任何 loop建议先把单个代理的手动运行跑稳定再回来看这篇。下面按“先统一通道、再给配置骨架、最后三步验证”的顺序走。每一步都有可复制的片段你照着改路径和模型名就能用。2. TaoToken 统一 Key 在多代理场景里到底省了什么先说清楚 TaoToken 在这个链路里的位置。它是一个统一的模型 API 通道你拿到一个 Key 之后所有需要调用模型的环节——Automations 里的定时触发、Sub-agents 里的验收代理、Skills 里挂载的背景说明——都走同一个 base_url 和同一个 Key。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置里直接写这个。为什么多代理场景特别需要统一 Key因为 Sub-agents 的本质是“写的和验的分开”。写代码的代理和验收的代理如果用不同的凭证通道你会在两个地方分别处理限流、分别处理超时、分别处理模型切换。一旦验收代理因为鉴权失败静默退出你的 loop 就会变成“自己给自己打分”的单代理Ralph Wiggum 循环那种“假装干完了”的问题立刻出现。统一 Key 之后你只需要在一个地方管理凭证。Automations 触发时读的是同一份配置Sub-agents 派生时继承的是同一个环境Worktrees 里每个工作区共享同一套 API 通道但互不干扰文件。这是后面所有配置骨架能成立的前提。拿 Key 的路径进控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 在 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 创建一个新 Key。建议给 loop 单独建一个 Key不要和你日常对话用的混在一起方便后面按 loop 维度看用量和吊销。注意Key 只显示一次创建后立刻写进你的密钥管理或本地环境文件不要提交到仓库。生产 loop 里关掉 verbose 日志避免凭证泄露进日志。3. config.toml 与 settings.json 可复制骨架这一节给两份骨架。config.toml 负责 Automations 的触发节奏、停止条件、Worktree 隔离策略settings.json 负责 Sub-agents 的派生规则、Skills 挂载、统一 API 通道。两份文件放在项目根目录路径按你的实际结构调整。3.1 config.tomlAutomations 触发与 Worktrees 隔离# config.toml — LoopEngineering 主配置 [api] # 统一通道所有代理共用 base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY # 从环境变量读取不硬编码 timeout_seconds 120 max_retries 3 [automation] name ci-triage-loop # 触发节奏每 30 分钟一轮也可换成事件触发 schedule */30 * * * * # 停止条件写死别让它无限跑 stop_condition consecutive_failures 3 OR accepted_changes 10 max_iterations 20 # 每轮开始前读状态文件续上上次进度 state_file .loop/state.md [worktrees] # 每个 Sub-agent 一份独立工作区互不干扰 enabled true base_dir .loop/worktrees # 命名规则代理角色 任务短标识 naming {role}-{task_slug} # 合并策略验收通过后才合回主分支 merge_policy after_verification cleanup_on_success true [gates] # 硬闸门过不了就自动拒不进入下一轮 require_tests true require_typecheck true require_lint true # 安全闸门 enable_sast true enable_secret_scan true这份配置里几个关键点。stop_condition必须写死这是防止 loop 无限烧 token 的第一道闸。state_file让每轮能续上避免重复劳动。worktrees.enabled打开后每个子代理拿到独立工作区改同一个文件也不会打架。gates里的三项是硬闸门测试、类型检查、lint 任一不过就拒绝这是防“假装干完了”的核心。3.2 settings.jsonSub-agents 派生与 Skills 挂载{ api: { base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, default_model: claude-sonnet-4-20250514 }, sub_agents: { writer: { role: implementation, model: claude-sonnet-4-20250514, instructions_file: .loop/skills/writer.md, worktree: true, max_turns: 15 }, verifier: { role: verification, model: claude-sonnet-4-20250514, instructions_file: .loop/skills/verifier.md, worktree: true, max_turns: 10, independent_context: true } }, skills: [ { name: project-context, path: .loop/skills/project-context.md, mount_to: [writer, verifier] }, { name: ci-conventions, path: .loop/skills/ci-conventions.md, mount_to: [writer] } ], logging: { verbose: false, redact_secrets: true } }这里最重要的是verifier的independent_context: true。它让验收代理不继承写代码代理的上下文避免“自我说服”。两个代理都走同一个base_url和api_key_env但指令文件不同、上下文隔离。skills数组把项目背景挂载到对应代理每轮直接读省得你反复解释。3.3 Skills 文件的最小写法Skills 不需要复杂格式一个 markdown 文件就够。关键是写清楚项目约定和踩过的坑。# .loop/skills/project-context.md ## 技术栈 - 运行时Node 20 TypeScript 5.4 - 测试vitest覆盖率门槛 80% - 包管理pnpm ## 约定 - 所有 API 调用走 src/lib/http.ts 的统一封装 - 错误处理用 Result 类型不抛异常 - 提交信息遵循 conventional commits ## 踩过的坑 - 2026-06-08Windows runner 上 PowerShell 撞 TLS 1.2改用 bash - 2026-06-10axios 1.7.4 在 Node 20 下有 keep-alive 泄漏锁 1.7.2这份 skill 挂到 writer 和 verifier 上两个代理每轮都读同一份背景验收标准才一致。4. 三步验证连通性、子代理调用、工作树切换配置写完不算跑通必须按顺序验证三件事。跳过任何一步后面出问题你都不知道是哪层断的。4.1 第一步连通性验证先确认统一 Key 和 API 通道能通。用 curl 直接打一次不要经过任何代理逻辑。export TAOTOKEN_API_KEY你的Key curl -s -X POST https://taotoken.net/api/v1/messages \ -H x-api-key: $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 64, messages: [{role: user, content: reply with OK only}] }预期返回里能看到content字段且文本是 OK。如果返回 401检查 Key 是否带空格如果返回 404检查 base_url 是不是写成了带路径的完整地址。这一步通了说明通道没问题后面所有代理共用这条通道。4.2 第二步子代理调用验证连通性过了之后验证 Sub-agents 能不能正确派生并各自拿到独立上下文。用一个最小脚本模拟 writer 和 verifier 的调用。# 模拟 writer 代理 curl -s -X POST https://taotoken.net/api/v1/messages \ -H x-api-key: $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 128, system: 你是 writer 代理只负责实现不负责验收。, messages: [{role: user, content: 写一个返回两个数之和的函数}] } # 模拟 verifier 代理独立上下文 curl -s -X POST https://taotoken.net/api/v1/messages \ -H x-api-key: $TAOTOKEN_API_KEY \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 128, system: 你是 verifier 代理只负责验收不继承 writer 的上下文。, messages: [{role: user, content: 验收上面那个求和函数指出边界问题}] }两次调用都返回正常说明子代理能各自独立走统一通道。如果你在 settings.json 里配了independent_context实际运行时 verifier 不会看到 writer 的中间推理只会看到最终产物。这一步验证的是“写的和验的分开”能不能成立。4.3 第三步工作树切换验证最后验证 Worktrees 隔离。确认每个子代理拿到独立工作区且合并策略生效。# 初始化 loop 工作区 mkdir -p .loop/worktrees # 为 writer 创建独立工作树 git worktree add .loop/worktrees/writer-fix-auth -b loop/writer-fix-auth # 为 verifier 创建独立工作树 git worktree add .loop/worktrees/verifier-fix-auth -b loop/verifier-fix-auth # 查看当前所有工作树 git worktree list预期输出里能看到主工作区和两个 loop 工作区各自在不同分支。在 writer 工作区里改文件verifier 工作区不受影响。验收通过后按merge_policy after_verification合回主分支然后清理。# 验收通过后合并 git checkout main git merge loop/writer-fix-auth # 清理工作树 git worktree remove .loop/worktrees/writer-fix-auth git worktree remove .loop/worktrees/verifier-fix-auth三步都过了你的多代理协作链路就算跑通了。接下来是排障。5. 本篇常见错排查5.1 子代理静默退出loop 变成单代理现象loop 跑完一轮日志里只有 writer 的输出verifier 没有任何记录。原因通常是 verifier 的鉴权失败但被吞掉了。检查 settings.json 里 verifier 的api_key_env是否和 writer 一致以及环境变量是否在派生时正确传递。把logging.verbose临时打开看 verifier 的请求有没有发出去。5.2 Worktree 切换后文件冲突现象两个子代理改同一个文件合并时报冲突。这说明 Worktrees 隔离没生效或者两个代理被分到了同一个工作区。检查naming规则是否唯一{role}-{task_slug}里 task_slug 如果重复两个代理会撞到同一个目录。确保每个子任务有独立的 slug。5.3 Skills 没挂载上代理每轮从零解释现象代理反复问项目用什么框架、约定是什么。检查 skills 数组里的mount_to是否包含了对应代理名以及path是否指向真实存在的文件。Skills 文件路径是相对项目根目录的不是相对工作区。5.4 停止条件没生效loop 无限跑现象token 用量持续上涨loop 不停。检查stop_condition的语法以及max_iterations是否设了合理值。consecutive_failures和accepted_changes这两个变量需要你的运行时代码实际去更新配置里写了不代表会自动统计。如果运行时没实现计数停止条件永远不会触发。5.5 验收代理太宽容坏活也通过现象verifier 几乎不拒绝任何产出。这通常是 verifier 继承了 writer 的上下文或者 verifier 的指令文件写得太模糊。确认independent_context: true生效并在 verifier 的 skill 里写清楚硬性验收标准比如“测试覆盖率低于 80% 直接拒绝”“类型检查有 error 直接拒绝”。6. 把链路跑稳之后该盯什么链路跑通只是开始。真正决定这套 loop 值不值得继续跑的是一个指标每个被接受的改动的成本。如果接受率低于 50%说明你的闸门太松或者任务选得不对loop 在亏本。具体做法在状态文件里记录每轮产出的改动数和被接受数每周看一次比值。接受率低的时候先收紧 verifier 的验收标准再检查 writer 的 skill 是不是缺了关键背景。别急着加更多代理先把两个代理的协作质量提上去。另外两件事定期做。一是每 30 天复审一次权限loop 用到的 Key 和仓库写权限有没有蔓延。二是读 diff即使 loop 自动合并了你也要抽查。认知投降是 loop 最大的隐性成本你慢慢不再自己判断loop 返回啥就收啥最后仓库里有什么你都不知道。如果你还没拿到统一 Key从控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 建一个 loop 专用 Key接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。想先验证模型输出质量再上 loop可以用模型对话 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 手动跑几轮。长期做编码和 Agent 协作的Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 更适合按量跑 loop。Claude Code 相关的接入参考 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一个我踩过的坑Worktrees 的清理一定要在合并成功后做如果合并失败还清了工作树你的改动就找不回来了。清理前先git worktree list确认分支状态别偷懒。