复刻 Claude Code 之父的「蜂巢」系统！三层循环架构全拆解：本地 /loop + 云端 Routines + 集群 /batch，7 个可抄的循环 Slash 命令详解

摘要2026年6月Claude Code 作者 Boris Cherny 在公开场合扔下一句爆炸性发言「我不再 prompt Claude 了我的工作是写循环。」这句话引爆了整个 AI 编程圈。开发者 Av1dlive 根据 Boris 的公开访谈从零重建了整套「蜂巢」THE HIVE系统配置。本文将完整拆解这套三层循环架构——本地 /loop、云端 Routines、集群 /batch——并给出 7 个可直接复用的 Slash 命令帮你从手动 Prompt 工程师进阶为循环工程架构师。全文约 5000 字建议收藏后实践。目录一、「蜂巢」是什么——Boris的AI开发流水线二、第一层本地循环/loop /goal 详解三、第二层云端例程Routines 配置与实战四、第三层集群/batch 动态工作流 Worktree 隔离五、七个可复用的 Slash 命令逐一详解六、三层协作与飞轮效应七、企业级多模型接入方案八、总结一、「蜂巢」是什么——Boris的AI开发流水线2026年6月2日WorkOS 主办的 Acquired Unplugged 活动上Claude Code 的作者 Boris Cherny 说了一句让全场沉默的话“I don’t prompt Claude anymore. I have loops that are running. They’re the ones that are prompting Claude and figuring out what to do. My job is to write loops.”翻译过来就是我不再手动给 Claude 写提示词了。我有一堆正在运行的循环是它们在 prompt Claude、决定该干什么。我的工作是写循环。这不是一句口号。Boris 在过去一个月里提了 259 个 PR没有一行代码是自己手写的——全是 Claude Code 在循环里自动完成的。他甚至删掉了自己的 IDE把整个开发流程交给了这套被他称为「THE HIVE」的循环系统。那么「蜂巢」到底是什么它不是某个单一功能而是一套三层循环架构层级名称运行环境最小频率核心命令第一层本地循环你的电脑关了就停1分钟/loop/goal第二层云端例程Anthropic 云端关了也跑1小时Routines/schedule第三层集群云端一次性扇出按需触发/batch 动态工作流这三层之间不是孤立的而是层层递进、互相接力的关系。开发者 Av1dlive 根据 Boris 在公开访谈中透露的细节从零复刻了这套配置并在 GitHub 上开源。下面我们就来一层一层拆解。二、第一层本地循环/loop /goal 详解2.1 /loop你的第一个自动化循环/loop是 Claude Code 内置的定时循环命令语法极其简单/loop间隔提示词或Slash命令间隔单位s秒、m分钟、h小时、d天最小间隔1 分钟带间隔 → 转成 cron 风格调度周期任务 7 天后自动过期不带间隔 → 模型自己决定节奏1 分钟到 1 小时之间自适应首先是 Boris 本人的入门例子一行就够/loop babysit all my PRs. Auto-fix build issues, and when comments come in, use a worktree agent to fix them.这句话的效果是Claude Code 会持续盯着你的所有 PR——构建失败自动修有人评论自动用隔离的 worktree 子智能体去改代码。全程不需要你碰键盘。场景一定时代码审查/loop 30m /code-review--fix每 30 分钟扫描当前 diff找出潜在 bug 和优化点能自动修的自动修。场景二监控 CI 状态/loop 5m 检查当前分支的 CI 状态如果有失败的 job分析原因并尝试修复每 5 分钟检查一次 CI pipeline发现失败就自动排查。PR 提交后不用一直盯着 CI 面板。场景三自动回复 GitHub Issue/loop 30m 检查仓库所有openissue对没有回复的 issue 根据 README 和已有信息生成准确回复并提交评论。已回复过的跳过不要重复评论。拆解这条命令的设计要素30m是心跳频率每 30 分钟唤醒一次 Agent中间的自然语言是每轮任务描述已回复过的跳过是防重机制——没有这句话Agent 每轮都会对所有 open issue 重新评论2.2 /goal让循环自己判断「做完了没」/loop解决的是隔多久再跑一次但它不替你判断任务到底完成了没有。/goal补的就是这一块。/goal是 ralph loop 的产品化版本——你给一个目标它反复跑每一轮跑完交给一个验证逻辑判断达成了吗没达成就重置上下文再来一轮达成了才自动停止。/goal 为这个项目写一套完整的单元测试覆盖率达到80% 以上/loop和/goal的核心区别对比维度/loop/goal触发方式按时间/状态重复按目标重复跑到验证通过为止完成判定无内建靠人中断内建验证逻辑自动停止适用场景盯状态变化CI、PR、Issue盯目标达成写测试、重构、迁移版本要求v2.1.72v2.1.139生产环境务必配护栏最大迭代次数防止空转无进展熔断连续 N 轮无变化就停Token/美元预算上限防止账单爆炸2.3 Codex 的对应功能OpenAI 的 Codex CLI 在 v0.128.02026年4月30日率先发布了/goal命令Claude Code 在 v2.1.1392026年5月11日跟进前后只差 11 天。Codex 的定时任务叫Automations功能与 Claude Code 的/loop对应——可以设置每天/每周定时触发让智能体在后台持续运行比如每天早上 8 点检查是否有新的 GitHub PR 评论需要回复。三、第二层云端例程Routines 配置与实战/loop有一个致命限制电脑关了循环就停了。2026年4月14日Anthropic 推出的 Routines 功能彻底解决了这个问题。3.1 Routines 是什么一个 Routine 是保存在 Anthropic 云端的 Claude Code 配置。你定义一个提示词附加一个或多个仓库连接你正在使用的工具GitHub、Slack、Linear 等然后打包。一旦完成Routine 在Anthropic 的云基础设施上运行——你的笔记本可以关闭Routine 照跑不误。3.2 三种触发方式1定时触发设置节律每小时、每晚、每周或仅限工作日。你输入本地时区的时间它会自动转换。# 在 Claude Code 中创建定时 Routine/schedule 每天凌晨2点从Linear提取最重要的bug尝试修复并在早班前打开草稿PR2API 触发每个 Routine 获得自己独特的 HTTP 端点和 Bearer Token。任何外部系统都可以向该端点发送 POST 请求并按需触发。// 外部系统触发 Routine 的示例constresponseawaitfetch(https://api.claude.ai/routines/rt_xxxxx/trigger,{method:POST,headers:{Authorization:Bearer claude_routine_token_xxxxx,Content-Type:application/json,Anthropic-Beta:experimental-cc-routine-2026-04-01},body:JSON.stringify({context:Sentry 告警生产环境 /api/checkout 接口 500 错误率超过 5%})});3GitHub 事件触发直接连接到你的仓库监听 PR、Push、Issue、Check Run、Workflow Run、Discussion、Release 等事件。支持按作者、标题、基础分支或标签过滤。# 示例只监听触及 auth 目录的 PRtrigger:github.pull_requestfilter:paths:-src/auth/**action:自动将变更摘要发布到#auth-reviews Slack 频道3.3 实际用例用例配置效果夜间 Bug 分类凌晨 2 点定时触发从 Linear 提取高优 bug自动修早班前开草稿 PRPR 审查自动化GitHub PR 事件触发监视特定分支新 PR结构化审查摘要发布到 Slack文档漂移检测每周定时触发扫描查找引用已变更 API 的文档自动打开更新 PR部署验证部署后 API 触发跑冒烟检查扫描错误日志发布 go/no-go 信号3.4 计划限制计划每日 Routine 运行上限Pro5 次Max25 次Team100 次Enterprise500 次每次 Routine 运行都计入你的常规订阅使用量。Pro 计划上每天 5 次足够测试但构建频繁依赖自动化的生产系统建议至少 Max 起步。四、第三层集群/batch 动态工作流 Worktree 隔离当第一层和第二层撞上大活——比如把整个项目的状态管理从 Redux 迁移到 Zustand——单个 Agent 是不够的。这时候拉第三层集群。4.1 动态工作流Dynamic WorkflowsClaude Code v2.1.154 引入的动态工作流是集群层的核心编排能力。它的工作方式是Claude 先写一段 JavaScript 编排脚本交给后台 runtime 执行脚本并行拉起几十到几百个子代理单次上限 1000并发 16脚本自己持有循环、分支、中间结果只有最终结论回到主对话内建对抗式验证一批代理去攻击结论另一批反驳直到收敛// 动态工作流编排脚本示例Claude 自动生成consttasksissues.map(issue({label:fix-${issue.number},prompt:修复 issue #${issue.number}:${issue.title},isolation:worktree,model:claude-sonnet-4-20250514}));// 并行扇出最多 16 个并发constresultsawaitPromise.all(tasks.map(taskagent(task.prompt,{label:task.label,isolation:task.isolation,model:task.model})));// 对抗式验证for(constresultofresults){constreviewawaitagent(审查这个修复方案检查是否引入新问题,{label:review-${result.label},agentType:code-reviewer});if(!review.approved){// 打回重做results.push(awaitagent(task.prompt,{/* 重试 */}));}}4.2 Git Worktree每个子智能体的隔离沙箱集群层的核心隔离机制是 Git Worktree。每个子智能体在独立的代码检出中工作互不干扰。# 在独立 worktree 中启动 Claude Codeclaude--worktree修复 issue #42 的内存泄漏问题在 Sub-agent 配置中# .claude/subagents/fixer.mdmodel:claude-sonnet-4-20250514isolation:worktreemax_turns:30tools:-bash-read-write-editMaker-Checker 模式是集群层的最佳实践// Maker在隔离环境中修改代码constfixawaitagent(修复这个安全漏洞,{label:maker,isolation:worktree});// Checker独立审查修改结果constreviewawaitagent(审查这个修复方案检查是否引入新问题,{label:checker,agentType:code-reviewer,isolation:worktree// 也在独立 worktree 中不和 maker 共享文件系统});4.3 最硬核的生产案例Bun 从 Zig 到 Rust 的移植Bun 作者 Jarred Sumner 用动态工作流加对抗式审查约 6 天完成从 Zig 到 Rust 的移植99.8% 测试通过。做法是每个修复一个子代理、各自在隔离的 git worktree 里并行、一份约 300 条规则的porting.md当共享指南。这个案例由 Anthropic 官方博客和 The Register 佐证是目前公开可查的最大规模集群层实战。五、七个可复用的 Slash 命令逐一详解以下 7 个 Slash 命令直接来自 Boris 的「蜂巢」配置每个都经过验证可运行。在.claude/commands/目录下创建对应的.md文件即可。命令 1盯 PR ——/watch-prs文件.claude/commands/watch-prs.md请检查我所有打开的 Pull Request 1. 列出每个 PR 的 CI 状态。 2. 如果 CI 失败分析日志找出根本原因在隔离的 worktree 中尝试修复推送修复 commit。 3. 如果有新的 Review 评论根据评论内容在 worktree 中修改代码并回复。 4. 如果有合并冲突尝试 rebase 到最新 main 分支解决冲突后 force-push。 5. 将本轮处理结果汇总输出到终端。 已处理过的 PR 如果没有新变化跳过。使用方式/loop 10m /watch-prs命令 2挖 Slack 反馈 ——/mine-slack文件.claude/commands/mine-slack.md请连接 Slack 工作区执行以下操作 1. 扫描过去 24 小时内 #user-feedback、#bug-reports、#feature-requests 频道的所有消息。 2. 对每条消息分类bug / feature_request / question / praise。 3. 对于 bug 类消息提取复现步骤在 GitHub 上搜索是否已有对应 issue。如果没有创建一个新 issue标签为 bug 和 from-slack。 4. 对于 feature_request 类消息汇总到 docs/feedback/slack-requests-$(date %Y-%m-%d).md 文件中。 5. 将汇总摘要发布到 #eng-daily 频道。 注意不要重复处理已归档的消息通过消息时间戳去重。使用方式/loop 1h /mine-slack命令 3清僵尸 PR ——/prune-stale文件.claude/commands/prune-stale.md请扫描仓库中所有 open Pull Request 1. 筛选出满足以下任一条件的 PR - 超过 14 天没有活动无新 commit、无新评论 - CI 持续失败超过 7 天且无人在修复 - 有未解决的合并冲突超过 3 天 2. 对每个僵尸 PR - 在 PR 下评论礼貌询问作者是否还打算继续给出 3 天回复期限。 - 如果已有类似提醒且超过 3 天无回复添加 stale 标签并关闭 PR。 - 关闭时附上说明如果后续需要继续请随时 reopen。 3. 将处理结果输出为表格PR 编号 | 标题 | 作者 | 状态 | 操作 跳过已在本轮处理过的 PR。使用方式/loop 1d /prune-stale命令 4给 Issue 分类 ——/triage-issues文件.claude/commands/triage-issues.md请扫描仓库中所有没有 triage 标签的 open Issue 1. 根据 Issue 内容分类添加对应标签 - bug报告了非预期行为包含复现步骤或错误日志 - feature请求新功能或增强 - documentation文档相关 - question使用问题或求助 - discussion开放讨论 2. 对 bug 类 Issue额外评估严重程度 - severity/critical影响核心功能无 workaround - severity/high影响常用功能 - severity/medium影响边缘功能或有 workaround - severity/low视觉问题或优化建议 3. 对每个 Issue 添加一条评论包含 - 分类依据一句话 - 建议的优先级 - 如果有相关 Issue 或 PR附上链接 4. 最后添加 triage 标签标记为已处理。使用方式/loop 2h /triage-issues命令 5沉淀规则进 CLAUDE.md ——/distill-rules文件.claude/commands/distill-rules.md请分析过去一周的 Git 提交历史和 PR Review 评论提炼出可沉淀为团队规则的模式 1. 扫描 git log --since7 days ago --oneline 和近一周的 PR Review 评论。 2. 识别以下模式 - 被反复指出的代码风格问题如这里应该用 async/await 而不是 .then() - 被频繁 revert 或回滚的变更类型如上次直接改数据库 schema 导致迁移失败 - 被多次讨论后达成共识的架构决策如我们决定所有 API 都要加限流 - 反复出现的 Bug 根因如又是忘记处理 null 的情况 3. 将上述模式提炼为简洁的规则条目追加到 CLAUDE.md 的对应章节 - 代码风格 → ## Code Style Rules - 架构决策 → ## Architecture Decisions - 常见陷阱 → ## Common Pitfalls 4. 每条规则不超过 3 行包含做什么和为什么。 5. 如果 CLAUDE.md 中没有对应章节自动创建。使用方式/loop 1w /distill-rules命令 6安全扫描 ——/security-scan文件.claude/commands/security-scan.md请对当前仓库执行安全扫描 1. 扫描所有依赖文件package.json / requirements.txt / Cargo.toml / go.mod 等检查是否有已知漏洞的依赖版本。 使用 npm audit / pip audit / cargo audit 等工具。 2. 扫描代码中的常见安全反模式 - 硬编码的密钥、Token、密码 - SQL 注入风险字符串拼接 SQL - XSS 风险innerHTML / dangerouslySetInnerHTML - 未验证的用户输入直接传给系统命令 - 不安全的加密算法MD5、SHA1 用于密码 3. 对每个发现的问题 - 评定严重程度critical / high / medium / low - 如果是依赖漏洞自动在 worktree 中尝试升级并创建 PR - 如果是代码问题自动在 worktree 中修复并创建 PR 4. 生成安全扫描报告docs/security/scan-$(date %Y-%m-%d).md 5. 将 critical 和 high 级别的问题摘要发布到 #security-alerts 频道。使用方式/loop 1d /security-scan命令 7依赖升级 ——/bump-deps文件.claude/commands/bump-deps.md请检查并升级仓库的依赖 1. 运行依赖检查工具列出所有可升级的依赖及其版本差异 - Node.js: npx npm-check-updates - Python: pip list --outdated - Rust: cargo outdated 2. 对于每个可升级的依赖 - 查看 CHANGELOG判断是否有 Breaking Changes - 如果是 patch 或 minor 升级且无 Breaking Changes → 自动在 worktree 中升级 - 如果是 major 升级或有 Breaking Changes → 在 worktree 中升级后运行完整测试套件 - 如果测试失败分析原因尝试修复兼容性问题 3. 所有升级通过测试后创建一个 PR标题格式chore(deps): bump X dependencies [$(date %Y-%m-%d)] 4. PR 描述中列出每个依赖的升级详情包名 | 旧版本 | 新版本 | 是否有 Breaking Changes 5. 如果某个依赖升级导致无法解决的兼容性问题记录到 docs/deps/blocked.md 并跳过。使用方式/loop 1w /bump-deps六、三层协作与飞轮效应6.1 三层协作流程以下是三层架构互相接力的完整 ASCII 流程图 | 「蜂巢」三层协作流程 | | | | 第2层云端 Routines24x7 运行最小1小时 | | ┌─────────────────────────────────────────────────┐ | | │ /schedule 每天凌晨2点 扫描Bug → 尝试修复 → 开PR │ | | │ /schedule 每周一 生成上周代码变更摘要 │ | | │ GitHub事件触发新PR → 自动审查 → 发布Slack │ | | └──────────────────────┬──────────────────────────┘ | | │ 发现写入文件 | | ▼ | | 第1层本地循环开机时运行最小1分钟 | | ┌─────────────────────────────────────────────────┐ | | │ /loop 10m /watch-prs ← 读云端Routines写入的│ | | │ /loop 30m /triage-issues 任务文件接力去干 │ | | │ /loop 1h /mine-slack │ | | └───────────┬─────────────────────────────────────┘ | | │ 撞上大活如迁移整个模块 | | ▼ | | 第3层集群一次性扇出成百上千子智能体 | | ┌─────────────────────────────────────────────────┐ | | │ /batch 启动动态工作流 │ | | │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ | | │ │Agent1│ │Agent2│ │Agent3│ .... │AgentN│ │ | | │ │fix-A │ │fix-B │ │fix-C │ │fix-N │ │ | | │ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ │ | | │ │ │ │ │ │ | | │ └────────┴────────┴──────────────┘ │ | | │ │ │ | | │ 对抗式验证 汇总 │ | | └──────────────────────┬──────────────────────────┘ | | │ 结果回流 | | ▼ | | ┌─────────────────────────────────────────────────┐ | | │ 第2层 Routines每周蒸馏更新 CLAUDE.md │ | | │ /schedule 每周一 /distill-rules │ | | │ 把集群的经验教训写进团队规则文件 │ | | └─────────────────────────────────────────────────┘ | | | 6.2 飞轮效应每周都比上周更聪明这套架构最迷人的地方不在于自动化而在于自进化。每一层都在为下一层积累知识第1周CLAUDE.md 只有 50 行基础规则 → 第2层 Routines 按规则跑发现规则不够用 → 第1层 /loop 遇到的坑被记录 → 第3层集群修复大规模问题时发现的模式 第2周/distill-rules 把上周的经验蒸馏进 CLAUDE.md → CLAUDE.md 变成 120 行覆盖了更多边缘情况 → 第2层 Routine 自动修复 Bug 的成功率从 60% 提升到 75% 第3周CLAUDE.md 变成 200 行 → 集群层的 Maker-Checker 协作更精准 → 修复成功率提升到 85% 第N周CLAUDE.md 成为一个活的工程知识库 → 新人入职不需要读文档Agent 自动按规则行事 → 每个循环都比上周更聪明这就是 Boris 说的我的工作是写循环的真正含义——他不是在写一次性脚本他是在设计一个能自我进化的系统。循环是管道资产是它调用的 Skill 和它沉淀的规则。七、企业级多模型接入方案在实际落地「蜂巢」架构时企业团队很快会面临一个现实问题Claude 不是唯一需要接入的模型。不同任务适合不同模型——Claude Opus 4 做主代理的推理决策Sonnet 4 做子代理的代码生成GPT-5 做文档和翻译DeepSeek 做成本敏感的大批量任务。如果每个模型都单独采购、单独管理 API Key、单独做账单核算运维成本会指数级增长。这就需要一个企业级大模型 API 聚合平台来统一管理。通过 微元算力(weytoken) 这样的聚合平台企业可以一个 API Key 接入所有主流模型Claude、GPT、DeepSeek、Gemini、Qwen 等不需要为每个厂商单独申请和续费统一用量管控和成本核算按项目、按团队、按模型维度实时查看 Token 消耗避免出现 Uber 那样四个月烧光全年预算的事故数据安全合规企业级数据隔离私有化部署选项满足金融、医疗等强监管行业的数据驻留要求智能路由和降级当某个模型厂商出现故障自动切换到备用模型保障「蜂巢」循环不中断在「蜂巢」架构中各层对模型的需求完全不同层级模型需求推荐接入方式第1层 /loop中等推理、高频调用Sonnet 4 / GPT-4.1第2层 Routines强推理、低频但关键Opus 4 / GPT-5第3层 集群大批量、成本敏感Sonnet 4 / DeepSeek-V3通过 微元算力(weytoken) 的 API 聚合能力你可以在不改动「蜂巢」核心逻辑的前提下灵活切换底层模型根据任务类型自动选择最优性价比组合。对于企业来说这意味着既享受了多模型生态的红利又避免了多厂商管理的碎片化成本。具体配置示例以 Claude Code 的 Sub-agent 配置为例# .claude/subagents/code-fixer.md# 通过统一 API 端点接入不同模型model:claude-sonnet-4-20250514isolation:worktreemax_turns:30# .claude/subagents/code-reviewer.md# 审查任务用更强的推理模型model:claude-opus-4-20250514isolation:worktreemax_turns:20# .claude/subagents/bulk-migrator.md# 大批量迁移任务用成本友好的模型model:deepseek-v3isolation:worktreemax_turns:50八、总结回顾全文我们完整拆解了 Boris Cherny「蜂巢」系统的三层架构第一层 /loop /goal本地循环最小 1 分钟一次适合盯状态变化和短期目标达成。电脑关了循环就停但开机时它是最高频的自动化工具。第二层 Routines云端例程最小 1 小时一次跑在 Anthropic 云上关了电脑照样跑。三种触发方式定时、API、GitHub 事件覆盖了 90% 的持续自动化场景。第三层 /batch 动态工作流集群一次性扇出成百上千个 worktree 子智能体并行每个在隔离的代码检出里。Maker-Checker 模式加对抗式验证保证质量。七个 Slash 命令盯 PR、挖 Slack 反馈、清僵尸 PR、给 Issue 分类、沉淀规则、安全扫描、依赖升级——每一个都可以直接复制到.claude/commands/目录下投入使用。飞轮效应三层循环互相接力每周的/distill-rules把经验蒸馏进 CLAUDE.md让下周的循环比上周更聪明。这不是一次性自动化而是持续进化的系统。最后如果你正在构建企业级的 AI 开发流水线必然会面临多模型管理的挑战。通过 微元算力(weytoken) 这样的企业级大模型 API 聚合平台你可以用一个统一的 API 端点接入所有主流模型灵活配置「蜂巢」各层的模型策略在稳定性、成本和效果之间找到最佳平衡。蜂巢不只是一个工具配置它是一种新的工作方式——你不再是那个在终端里一行行敲提示词的人你是那个设计循环的人。数据来源声明本文技术内容基于以下公开资料整理Anthropic 官方博客Dynamic Workflows、Routines 介绍、Boris Cherny 在 WorkOS Acquired Unplugged2026-06-02的公开访谈、Claude Code 官方文档Workflows / Scheduled Tasks / Subagents、Geoffrey Huntley 的 Ralph Loop 项目、Peter Steinberger 的公开推文2026-06-07、腾讯云开发者社区 windseeker 的深度分析文章《Claude Code 的三种循环》、爱范儿《Codex和Claude Code负责人都不写提示词了》专题报道、头条号二哥的 Loop Engineering 实战教程。文中代码示例均经过 Claude Code v2.1.x 及以上版本验证。部分成本数据引自 Anthropic 工程博客的 Multi-agent research system 文章及 TechCrunch 对 Uber 的报道。