Claude Code 创造者使用的 AI Agent Stack（Builder 指南）
Avid (@Av1dlive)
2026-06-09
D
原文
---
title: "Claude Code 创造者使用的 AI Agent Stack（Builder 指南）"
author: "Avid (@Av1dlive)"
source_url: "https://x.com/Av1dlive/status/2064292484856041558"
published_at: "2026-06-09T10:24:15.000Z"
fetched_at: "2026-06-11T02:38:11Z"
updated_at: "2026-06-11T03:22:46Z"
language: "zh"
review_status: "draft"
---
# Claude Code 创造者使用的 AI Agent Stack（Builder 指南）
我现在已经不 prompt Claude 了。我的工作是写 loops。
Boris Cherny 这句话刷爆了互联网。所以我复刻了他的整套配置。
下面是我的发现。
> **先说明一下。这是一份重构，不是泄密。Boris 没有公开他的 dotfiles。下面的内容来自他的公开访谈、帖子和 Anthropic 的发布文章：我把这些内容和 Anthropic 今年发布的 primitives 拼在了一起。具体的 slash commands、Routines 和文件布局，是我根据他描述做出的善意还原，不是从他机器里导出的原始配置。可以把它看成最接近他那套配置、同时可复现的版本。**
---
Claude Code 的创造者 Boris Cherny 那句话刷爆了互联网。
所以我拆解了他的完整配置。下面是我的发现。
### “我的工作是写 loops”
5 月，Anthropic 的 Claude Code 创造者 Boris Cherny 参加 Acquired Unplugged with WorkOS 时，把那句大家心照不宣的话说了出来。
> “我的工作是写 loops。”
他已经不 prompt Claude 了。他写的是会 prompt Claude 的 loops。
- 白天有五到十个交互式 session，夜里有“几千个”agents 在跑，大多是从手机上启动的。
- 几百个 Claude 实例监控 Twitter、GitHub 和 Slack，寻找产品想法。
他卸载了 IDE，因为他已经一个月没打开过了。
1. 这是一次阶段跃迁，而且可以复现。Anthropic 在过去六个月里发布了 Boris 用到的每一个 primitive：/loop、/schedule、Routines、/batch、dynamic workflows、skills、hooks 和 ant CLI。
2. 这些东西并不只对 Anthropic 工程师开放。它们现在就在你的 Claude Code 里。
3. 之前缺的是有人把整张图端到端拼起来：三层架构、文件布局、他描述的本地运行的七个典型 loops、符合他所说“夜间运行”模式的八个 Routines，以及把它变成一个系统而不是一堆功能的组合方式。
这就是本文要做的事。3357 个词，纯 builder 视角拆解；也是我读完所有 Boris 相关博客、推文、视频和 Claude 博客后自己在用的东西。
我把这套系统叫作 **THE HIVE**。它是一群几千个 agents，在你睡觉时处理你的代码库、收件箱、X mentions 和 CLAUDE.md。
三层可组合架构、真实文件路径、可运行的 slash commands，以及一条从周一到周五的上手路线。
---
### Boris 刚刚关于让 Opus 自主运行说了什么
6 月 8 日，也就是本文发出前 22 小时，Boris 发布了五条关于让 Opus 自主运行数小时或数天的新建议。它们直接支撑下面所有内容。
https://x.com/i/status/2063792263067754658
> “看到很多 benchmark 都显示 Opus 是最适合长时间运行工作的模型。”
他的五条规则，原话列出并展开：
**1. 权限使用 auto mode。** 这样 Claude 就不会请求批准。这是无人值守运行的关键解锁点。流程里没有人在场，就不会有 agent 空等一次点击。
**2. Dynamic workflows。** 让 Claude 编排几百或几千个 agents 来完成任务。这是 THE HIVE 的第 3 层。我们会在第 4 部分搭出来。
**3. /goal 或 /loop。** 推动 Claude 一直做下去，直到完成。这是修复 agentic laziness 的结构性办法。/goal 设定明确的完成标准。/loop 让 workflow 按计划反复触发。
**4. 云端 Claude Code。** 这样你就可以合上笔记本。最简单的路径是桌面 app 或移动 app。这也是为什么下面的架构里会有第 2 层（Routines）。
**5. 端到端自我验证。** Web 端用 Chrome 里的 Claude。移动端用 iOS/Android sim MCP。后端工作要有办法启动完整 web server。没有这一层，每个夜间运行都会变成早上醒来掷硬币。
再读一遍第 5 条。它是无人值守 Opus 工作里最重要的一条规则。
如果 Claude 不能在真实环境里验证自己的输出，你早上醒来就会看到一千个幻觉 diff。
下面的 HIVE 蓝图把这五条全部操作化。
---
### Part 1：agent 编排的三层架构
Anthropic 在过去六个月里发布的每个 primitive，都能放进三层架构中的某一层。
理解这三层，就能把一堆很酷的功能变成一个系统。
| 层级 | Primitive | 运行位置 | 合上笔记本后是否继续 | 最小间隔 | 用途 |
|---|---|---|---|---|---|
| **1. Local loops** | `/loop` | 打开的 Claude Code session | 否 | 1 min | 你写代码时，在 session 内持续推进的工作 |
| **2. Routines** | `/schedule` + Routines | Anthropic cloud | 是 | 1 hour | 夜间、无需看管、可持久运行的工作 |
| **3. Swarms** | `/batch` + dynamic workflows | worktree 里的 subagents | 否（绑定到单次 job） | N/A | 大规模并行的一次性 fan-out |
整个 HIVE 就是这三层的深度组合。
- Tier 1 让你工作时保持敏锐。Tier 2 在你不工作时继续让系统产出。Tier 3 把算力砸向那些足够大的问题。
- 魔法在于组合模式。
- 一个 Tier 2 Routine 触发一个 Tier 3 batch，batch 把发现写进文件，下一个 Tier 1 loop 读到文件并采取行动。
- 一旦这个飞轮转起来，你的时间就会花在评判标准、踩坑点和品味判断上。
我们逐层搭起来。
---
### Part 2：Tier 1，本地 loops（白天层）
/loop 是一个 session 级调度器，运行在活跃的 Claude Code session 里。
可以用固定 cron 间隔（最短一分钟），也可以让 Claude 动态选择间隔。
一个 session 最多容纳 50 个任务。循环任务 7 天后过期，并会在 `claude --resume` 后恢复。
你 99% 时间会用到这两种格式：
```bash
/loop 5m <prompt> # fixed interval
/loop <prompt> # dynamic interval (1m to 1h)
/loop 30m /<your-slash-command> # loop a slash command, not a prompt
```
有两个杀手级细节，大多数人会漏掉。
1. **你可以 loop 一个 slash command，而不只是一个 prompt。** 先把 workflow 写成 `.claude/commands/` 里的 slash command，然后 loop 它。这个 loop 就变成了任意复杂 workflow 的一行调度器。
2. **当你直接运行 /loop 时，`.claude/loop.md` 文件会替换内置 maintenance prompt**。项目级优先于用户级。改动会在下一次迭代生效。保持在 25000 bytes 以内。
---
### Boris 运行的 7 个 loops（你也应该运行）
其中四个直接来自 Boris 的配置：/babysit、/slack-feedback、/post-merge-sweeper、/pr-pruner。
另外三个是自然补全。
按下面顺序把它们放进一个新 session：
```bash
1. Babysit your PRs (review comments, failed CI, merge conflicts)
/loop 5m /babysit
# 2. Mine Slack feedback into PRs every 30 minutes
/loop 30m /slack-feedback
# 3. Sweep up missed code review comments after merges
/loop /post-merge-sweeper
# 4. Close stale PRs hourly so your dashboard stays clean
/loop 1h /pr-pruner
# 5. Triage new GitHub issues (classify, dedupe, label, assign)
/loop 15m /triage-issues
# 6. Mine corrections you keep making into CLAUDE.md rules
/loop 2h /claude-md-distiller
# 7. Watch the deploy and ping if anything regresses
/loop 5m /deploy-watch
```
七个 slash commands。七个 loops。全部都是 session 级的。
它们都在安全护栏内运行：不可逆操作只有在继续执行 transcript 已经授权的事情时才会推进。
---
### 一个 slash command 实际长什么样
Slash commands 放在 `.claude/commands/` 里，并提交到 git。
下面是 `.claude/commands/babysit.md` 的完整内容：
```markdown
---
description: Shepherd all open PRs assigned to me toward landed.
---
You are managing my open pull requests. For each PR I authored that is still open:
1. Pull the latest CI status. If anything failed and the failure is obvious
(flake, lint, formatting), push a fix. If it's a real test failure, leave
a comment explaining the suspected cause and tag me.
2. Read any new review comments since the last loop iteration. For each:
- If it's a nit and uncontroversial, fix it and reply with a brief note.
- If it's a design question, draft a reply but DO NOT post it. Surface
it to me in your iteration summary.
3. If the PR has merge conflicts against main and they look mechanical
(imports, lock files, whitespace), resolve them. If the conflict touches
logic, leave a note for me.
4. If the PR has been green and approved for >30 minutes, enable auto-merge.
Output: one-line status per PR. Do not be verbose.
```
就这样。一个带 description 和 prompt 的 markdown 文件。
每 5 分钟 loop 一次。现在你就有了一个持续看管 PR 的初级工程师，可以用 Esc 停掉。
---
### 让它扩展起来的模式
通过组合 slash commands 来组合 loops。
- /babysit 可以调用 /triage-issues 或 /slack-feedback。
- 一个 slash command 可以启动一个 subagent（`--agent=<name>`），这个 subagent 有聚焦的 system prompt 和受限工具集，并定义在 `.claude/agents/` 里。
你想要的文件布局是：
```bash
your-repo/
├── .claude/
│ ├── commands/ # Slash commands (the units of loop-able work)
│ │ ├── babysit.md
│ │ ├── triage-issues.md
│ │ ├── slack-feedback.md
│ │ └── ...
│ ├── agents/ # Custom subagents with specific tools/prompts
│ │ ├── code-reviewer.md
│ │ ├── triage-classifier.md
│ │ └── verifier.md
│ ├── skills/ # Knowledge the agents pull in (Part 5)
│ │ └── ...
│ ├── workflows/ # Saved dynamic workflows (Part 4)
│ │ └── ...
│ ├── hooks/ # PreToolUse / PostToolUse / SessionStart hooks
│ │ └── format-on-write.sh
│ ├── loop.md # Bare /loop default prompt
│ └── settings.json # Permissions (the safe-bash allowlist)
└── CLAUDE.md # Project-wide context, distilled rules
```
`.claude/` 里的所有东西都进 git，所以你的整套 agentic 配置会跟着 repo 一起走。
新人入职第一天就能继承这套配置。这正是 Anthropic 把新工程师上手时间从几周降到两天的方式。
---
### Part 3：Tier 2，Routines（夜间层）
你合上笔记本的那一刻，/loop 就死了。
要做夜间工作，你需要 **Routines**，也就是 Anthropic 云端托管的定时任务。
1. 通过 CLI 里的 /schedule 或 claude.ai/code 设置。它们运行在 Anthropic 基础设施上，基于一个全新的 git clone，connector 按任务配置，自主运行，最小间隔一小时。
2. Boris 说“用云端 Claude Code，这样你就可以合上笔记本”时，指的正是这个。
3. 你也可以通过 API call 或 GitHub events（webhook 形态）触发 Routine。这是把它们接入你其余 stack 的关键解锁点。
---
### 让 THE HIVE 夜间运行的 8 个 Routines
下面是典型的夜间任务组合。每个通过 /schedule 配一次，然后忘掉它们。
```yaml
# Morning report (fires before you wake up)
0 6 * * * /morning-report
→ Synthesize what landed overnight: PRs merged, issues closed, deploys,
incidents. Post to #standup.
# Deep codebase audit (runs nightly, takes hours)
0 22 * * * /deep-audit
→ Spawn a dynamic workflow that fans out across the codebase looking for
dead code, security issues, perf regressions, dependency drift. Write
findings to .claude/audit/<date>.md for the morning /triage to pick up.
# Twitter / X feedback monitor (every 2 hours)
0 */2 * * * /x-feedback
→ Pull recent mentions, replies, and quoted tweets of our product handles.
Classify (bug / praise / feature request / spam). Write actionable items
to a Linear feeder queue. Drop the rest.
# GitHub issue triage (every 4 hours)
0 */4 * * * /github-triage
→ Classify new issues, dedupe against existing ones, apply labels, assign
to the right teammate based on CODEOWNERS, and propose a severity.
# CLAUDE.md distillation (Saturdays at 3am)
0 3 * * 6 /distill-claude-md
→ Mine the last 7 days of sessions for corrections I keep making. Cluster
them with parallel agents, adversarially verify each candidate rule,
propose updates to CLAUDE.md. I review Sunday morning.
# Dependency hygiene (Sundays at 4am)
0 4 * * 0 /dep-hygiene
→ Check for security advisories, propose upgrade PRs for safe minors,
flag majors for human review.
# Flake hunter (every 3 hours during work hours)
0 9-18/3 * * 1-5 /flake-hunt
→ Look at the last 50 CI runs for tests that failed intermittently.
Spawn a workflow that reproduces and root-causes the top three.
# Weekly recap (Fridays at 5pm)
0 17 * * 5 /weekly-recap
→ Compile merged PRs, closed tickets, and deploys into a recap. Post to
#engineering. Include a "what got better this week" section.
```
这些 cron 表达式是精确的。
注意：对时间敏感的任务，避免用 `:00` 和 `:30`。Anthropic 会给循环任务加入最多 30 分钟的 jitter（抖动，由 task ID 派生），所以一个安排在 `:00` 的小时级任务，可能在之后最多 30 分钟内任意时间触发。
如果精确时间很重要，用 `3 9 * * *`，不要用 `0 9 * * *`。
---
### Routine 和 /loop 在实践里的区别
心智规则是：
- **Tier 1（/loop）** 适合需要当前 session 上下文的工作：打开的文件、当前分支、进行中的改动。你愿意的话，它可以每分钟跑一次。
- **Tier 2（Routines）** 适合在云端基于全新 clone、针对 repo 的 main 分支运行的工作。它最多每小时跑一次。
如果你发现自己想让一个 Routine 做需要本地工作目录状态的事情，那你选错层了。
---
### Part 4：Tier 3，/batch 和 dynamic workflows（swarm 层）
这是你抵达一千个 agents 的地方。
这就是 Boris 的第 2 条建议所说的：“使用 dynamic workflows，让 Claude 编排几百或几千个 agents 来完成任务。”
/batch 是 Claude Code 内置的 fan-out primitive。它会先问清这次改动，然后把工作分发给“完成任务所需数量的 worktree agents（几十、几百，甚至几千个）”。
每个 worktree 都是一个隔离的 git checkout，所以 agents 不会互相踩。
**Dynamic workflows** 是更通用的 primitive：Claude 动态写出一个 JavaScript 文件，使用 `agent()`、`parallel()` 和 `pipeline()` 来协调 subagents，每个 subagent 都有自己干净的 context window。
你可以通过要求 Claude 写一个 workflow 来触发它们，也可以启用 ultracode，让 Claude 自动启动一个。
它们在 5 月 28 日发布。
Workflows 给了你三个单一 context 做不到的东西：
- **每个 agent 隔离。** 每个 subagent 都有自己的 context window 和一个聚焦目标。没有交叉污染。
- **每个 agent 可选模型。** Workflow 可以给高难推理选 Opus，中间层选 Sonnet，低成本探索选 Haiku。
- **每个 agent 可选隔离级别。** Worktree（隔离 git checkout）或 remote（无 checkout）。Workflow 决定每个 agent 需要什么。
---
### **Workflow 从结构上防住的三种失败模式**
Claude 在单一 context window 里工作越久，越容易掉进 Anthropic 明确命名的三种失败模式。
- **Agentic laziness。** Claude 处理了 50 个安全项里的 20 个，然后声称剩下的也“已处理”。修法：`/goal <criterion>` 加 loop-until-done 模式，或者显式加入一个负责计数的 synthesizer。
- **Self-preferential bias。** Claude 会给自己的工作打高分。一个对结果有利害关系的 verifier 不可能是公平的 verifier。修法：用一个从没看过原始工作的独立 verifier，最好还换一个模型。
- **Goal drift。** 很多轮之后逐渐丢失目标保真度，尤其是在 compaction 之后。每次 summarize 都是有损的。“不要做 X” 会在第 47 轮悄悄消失。修法：用彼此独立的 Claude，各自拥有聚焦目标和隔离状态。
如果你曾经上线过一个 agent，并且心里暗暗知道它在骗你，原因就在这里。
Workflows 消除了制造这些失败模式的条件。这也是为什么 Boris 的第 3 条建议（/goal 或 /loop）和第 5 条建议（self-verification）对无人值守运行这么重要。
---
**一个真实的一千 agent 例子**
在一个 4000 文件的 monorepo 里，把所有 `user.email` callsite 迁移到 `user.primaryEmail`。
旧做法：写一个 codemod，祈祷它不会搞坏边缘情况，然后花一周 review diff。
**新做法：**
```markdown
ultracode migrate every callsite of user.email to user.primaryEmail.
Spawn one agent per file that touches user.email. Each agent makes the
change in its own worktree, runs the relevant test file, and adversarially
reviews its own diff. Synthesize at the end with a summary of any callsites
that needed manual intervention.
```
**Claude 会写出一个大概这样的 workflow：**
```javascript
// .claude/workflows/email-migration.js
const files = await bash('rg -l "user\\.email" --type ts');
const results = await parallel(
files.split('\n').filter(Boolean).map(file =>
pipeline(
[file],
// Stage 1: make the change in an isolated worktree
async (f) => agent(`In a worktree, change every user.email reference
in ${f} to user.primaryEmail. Run the colocated test file. Return
a diff and the test result.`, {
model: 'sonnet',
worktree: true,
schema: { diff: 'string', testPass: 'boolean', notes: 'string' }
}),
// Stage 2: adversarial review of the change
async (result) => agent(`Review this diff for correctness, especially
for cases where the rename might be wrong (e.g. external API contracts,
DB columns, serialization). Diff: ${result.diff}`, {
model: 'sonnet',
schema: { approved: 'boolean', concerns: 'array' }
})
)
)
);
return synthesize(results, 'Group by approved/needs-review. List concerns.');
```
这个文件不是你写的。是 Claude 写的。
你描述了任务。Claude 写出了 harness（执行框架）。
这个 workflow 会为每个匹配文件启动大约一个 agent，在真实代码库上很容易就是 800 个 agents。每个 agent 都在自己的 worktree 里，有自己干净的 context window。
Bun 团队就是用这种方式把他们的 Zig 代码库重写成 Rust 的。
---
**你会不断组合的六种 harness patterns（执行框架模式）**
Anthropic 发布过这些模式，它们覆盖了约 90% 的真实 builder 工作。
1. **Classify-and-act。** Router 判断任务类型，分发给 specialists。适合 triage、support、intake。
2. **Fan-out-and-synthesize。** 拆成 N 份，并行 agents，barrier merge。适合 migrations、scoring、bulk extraction。
3. **Adversarial verification。** 每个 producer agent 都配一个 fresh-eyes skeptic 来攻击它的输出。配对规则是：verifier 只看到 rubric 和 artifact，看不到是谁产出的。
4. **Generate-and-filter。** 生成 N 个候选，淘汰失败项，返回幸存者。要求“最好的答案”会让 Claude 太早下注。Generate-and-filter 会让 Claude 晚下注，等每个选项都被挑战之后再决定。
5. **Tournament。** 两两比较直到选出赢家。比较式判断胜过绝对打分，尤其适合基于品味判断的工作。Bracket 放在确定性的 loop code 里，而不是放在 context 里。
6. **Loop-until-done。** 持续启动 agents，直到停止条件触发（没有新发现、理论已验证、零错误）。适合 flake hunting、root-cause investigation。
真实 workflows 通常会组合其中两到四种。任务到 pattern stack 的映射如下：
| 使用场景 | Pattern stack |
|---|---|
| Migrations & refactors | Fan-out（每个 callsite 一个 agent）→ adversarial verification → loop-until-done。Bun 就是这样从 Zig 重写成 Rust 的。 |
| Deep research | Fan-out（并行搜索）→ 每条 claim 做 adversarial verification → 综合成一份带引用的报告 |
| Draft verification | 识别 claims → fan-out（每条 claim 一个 verifier）→ meta-verifier 检查 source quality |
| Sorting 1,000+ items | Tournament：两两比较、bucket-rank 或 bracket |
| Root-cause investigation | 从互不重叠的证据生成 theories → 一组 verifiers 和 refuters → loop 到只剩一个理论 |
| Triage at scale | Classify-and-act → 和现有 tickets 去重 → 修复或升级处理。搭配 `/loop` |
| Design, naming, UI choices | Generate-and-filter（5 到 20 个选项）→ 带 rubric 的 tournament |
| Lightweight evals | 在 worktree 里跑候选方案 → comparison agents 按 rubric 打分 → refine，再 re-grade |
捷径是：先识别你的任务正掉进哪种失败模式，然后选择能从结构上防住它的 pattern。
Drift → fan-out。Self-preference → adversarial verification。Open-ended → loop-until-done。Hard-to-score → tournament。
---
**防止 workflows 烧掉 token 的三种控制手段**
如果没有 guardrails，workflows 可能膨胀到你预期 token 的 5 到 10 倍。
- **/goal** 设定硬性完成要求。搭配 loop pattern 使用：“不要停，直到有一个理论成立。”没有它，workflow 会在第一个软完成点就停下来。
- **/loop** 按循环计划运行 workflow。持续 triage、每周 research updates、周期性 verification。
- **明确 token budgets。** 告诉 Claude：“use 10k tokens。”Anthropic 自己团队说得很直白：“Dynamic workflows often use more tokens, so think carefully about when and how to use them.” 大多数 coding tasks 不需要五个 reviewers 组成的 panel。
```plaintext
ultracode quick adversarial review of this assumption:
"moving to Postgres eliminates our shard rebalancing."
Use 5k tokens. /goal don't stop until you have either
a counterexample or three independent confirmations.
```
---
**处理不可信输入的 quarantine pattern（隔离模式）**
任何读取非你编写内容的 workflow（support tickets、bug reports、user feedback、web pages、third-party API output），都必须假设这些内容里可能有 prompt injection。
修法是结构性的。
一个只读 reader agent，没有高权限工具，负责消化不可信内容并输出结构化摘要。
另一个独立的 actor agent 从不看原始内容，只基于摘要执行任何高权限动作。
一个 30 行 reader，就能移除整整一类 injection 风险。
---
### Part 5：Skills，让其他一切值得运行的知识层
Workflow 是 agent 思考的方式。Skill 是 agent 知道什么。
没有 skills，每个 loop 和每个 Routine 都在重新发明轮子。
Anthropic 内部在九大类别里运行着几百个 skills。对 HIVE 来说，先做下面四类。
1. **Verification skills。** “花一周时间把你的 verification skills 做到非常好。”Anthropic 直接说，这是提升输出质量上影响最大的投入。这也是把 Boris 第 5 条建议端到端自我验证操作化的方式。
2. **Runbooks。** 每个服务的“症状 → 工具 → 查询模式”。这会让夜间 Routines 真正做有用的事，而不是原地空转。
3. **Data fetching and analysis。** Monitoring stacks、dashboard IDs、table schemas、canonical user_id、join keys。
4. **Code quality and review。** 给 adversarial-review subagents 用的 rubric。
---
**真正有效的 skill anatomy**
Skill 是一个文件夹，不是一个 markdown 文件。
下面是一个 signup-flow verification skill 的布局：
```bash
.claude/skills/signup-flow/
├── SKILL.md # Description (for the model) + main instructions
├── references/
│ ├── api.md # Detailed endpoint signatures, called on demand
│ └── known-gotchas.md # The hard-won lessons
├── scripts/
│ ├── drive_signup.ts # Playwright script: signup → email → onboarding
│ └── assert_state.sh # Programmatic state assertion at each step
└── config.json # Per-user setup (test email, target env)
```
`SKILL.md` 里的 description 字段，是整个 skill 里最重要的字段。
Claude 会在 session 开始时扫描它，用来判断：“这个请求有没有对应的 skill？”
它是触发条件，不是摘要。要写给模型看：
```yaml
---
name: signup-flow
description: Use when the user mentions signup, onboarding, email verification,
or activation flows. Drives the full signup→email→onboarding journey in a
headless browser, asserts state at each step, and surfaces the failing step
with the captured screenshot.
---
```
**Anthropic skills 文章里的五条规则，很容易跳过，但跳过代价很高：**
1. **不要复述显而易见的东西。** Claude 已经知道怎么写代码。Skills 应该聚焦那些能把 Claude 推出默认行为的东西。
2. **建立 Gotchas section，并逐步增长它。** 最高信号的内容，是那些来之不易的规则，比如“subscriptions table 是 append-only，你要的是最高 version 那行，不是最新 created_at 那行”。
3. **给 Claude 代码，而不只是文字。** Scripts 让 Claude 把轮次花在组合上，而不是重新拼 boilerplate。
4. **用 `${CLAUDE_PLUGIN_DATA}` 做 persistent memory。** 一个 morning-report skill，如果在生成下一份报告前会读取自己的历史，会比每天从零开始好得多。
5. **把 workflows 保存成 skills。** 把 workflow JS 放进 skill folder，从 `SKILL.md` 引用它。这样它就可发现、可分享。
最后一点是 Tier 3（workflows）和系统其他部分之间的桥。
一个保存成 skill 的 workflow，会变成 loop 或 Routine 可以调用的 primitive。这就是跨层组合的方式。
---
### Part 6：ant，让整套系统可以从 cron 里跑起来的无头指挥器
ant 是官方 Anthropic CLI。
安装一次：
```bash
brew install anthropics/tap/ant
# or
go install github.com/anthropics/anthropic-cli/cmd/ant@latest
```
它在 2026 年 5 月 28 日发布 v1.10.0，和 dynamic workflows 同一天。这个时机不是巧合。
- ant 给你的，是一个 shell-native、可脚本化、Unix pipe 友好的 Anthropic API 入口。
- 输出格式：json、jsonl、yaml、pretty、raw。输入模式：flags、heredocs、通过 `@path` 读文件、通过 `@data://` 读 data URLs。内置 GJSON syntax 做 transforms。
- 对 HIVE 来说，ant 是无头指挥器。
- Routines 运行在 Anthropic 云端。/loop 需要一个打开的 session。但 ant 可以从任何地方运行：你的笔记本 cron、CI、GitHub Action、服务器、webhook handler。
下面是一个 system cron entry：不需要任何打开的 Claude Code session，就能运行完整 morning report pipeline。
```bash
# Every weekday at 6am, generate the morning report and post to Slack
0 6 * * 1-5 cd ~/work/myrepo && \
gh pr list --state merged --search "merged:>=$(date -v-1d +%Y-%m-%d)" --json title,url,author \
| ant messages create \
--model claude-haiku-4-6 \
--message @data://stdin \
--transform 'content.0.text' \
| slack-cli post --channel '#standup'
```
这就是蜂群级 morning report。
每个 merged PR 都由 Haiku 并行变成一行摘要，然后发到 Slack。用 gh + ant + slack-cli + cron 搭出来。没有 framework。没有 FastAPI。没有 `import anthropic`。
模式是：ant 让 Tier 2 Routine 能伸出去触发 Tier 3 workflow，也让 Tier 1 loop 能唤醒 Tier 2 process。
它是把三层组合成一个系统的胶水。
心智模型是：像看待 curl 一样看待 ant。你不会为 curl 搭一个 framework。你会把它接进 pipe。
---
### Part 7：把 THE HIVE 组起来，composition flywheel
现在所有部件都有了。
下面是它们如何组合成一个系统，让 Boris 的配置、以及你自己的配置，都能在周五前成为可能。
这个飞轮（也就是 Boris 的手机如何在夜里运行几千个 agents）：
```markdown
┌──────────────────────────────────────────────────────────────┐
│ │
│ TIER 2: Overnight Routines (Anthropic cloud) │
│ • /deep-audit writes findings to .claude/audit/<date>.md │
│ • /x-feedback writes ideas to .claude/inbox/x.jsonl │
│ • /github-triage labels and assigns issues │
│ │ │
│ ▼ │
│ ant cron jobs read those files, post digests to Slack │
│ │ │
│ ▼ │
│ TIER 1: Morning /loops in open session read the inbox │
│ • /loop 15m /triage-issues acts on yesterday's triage │
│ • /loop 30m /slack-feedback turns ideas into PRs │
│ • /loop 5m /babysit shepherds those PRs to landed │
│ │ │
│ ▼ │
│ TIER 3: When a loop hits a big job (migrate 4000 files, │
│ audit security across the repo), it spawns a /batch or │
│ dynamic workflow with hundreds of worktree subagents │
│ │ │
│ ▼ │
│ Findings flow back to .claude/audit/, CLAUDE.md, Linear │
│ │ │
│ ▼ │
│ Weekly /distill-claude-md Routine mines all of this and │
│ proposes new rules. You review Sunday morning. │
│ The system gets smarter every week. │
│ │
└──────────────────────────────────────────────────────────────┘
```
组合规则：
1. **Tier 2 写文件。Tier 1 读文件。** Routines 基于全新 clone 运行，拿不到本地状态，所以唯一持久的交接物就是 git repo。让 Routines 把结构化输出（`.jsonl`、`.md`）写进 `.claude/inbox/` 或 `.claude/audit/`。Loops 从那里读取。
2. **Tier 1 按需启动 Tier 3。** 当一个 loop 遇到一个单个 Claude 扛不住的大任务（repo-wide refactor、1000-row triage），它会调用 /batch，或者要求写一个 workflow。Swarm 跑起来，写回结果，loop 继续。
3. **Tier 3 的结果进入 Tier 2 的下一个周期。** 夜间 audit 的 findings 会变成第二天早上的 triage queue。这个 clock cycle 以天为单位。
4. **CLAUDE.md distillation loop 关闭 meta-loop。** 每周，一个 Routine 挖掘你的 sessions，用并行 agents 聚类你反复做出的纠正，对候选规则做 adversarial verification，并提出 CLAUDE.md additions。你周日批准。下周你的 agent 就会可衡量地变得更好。
会滚雪球的是这一部分。不是模型，是系统。
---
### Minimal HIVE：周五前应该交付什么
如果你有一周时间，下面是该搭的东西。按顺序来。
1. **周一。** 打基础。
- `brew install anthropics/tap/ant`，并确认它能用。
- 创建 `.claude/`，里面放空的 `commands/`、`agents/`、`skills/`、`workflows/`，再放一个 `loop.md`，以及一个 `settings.json`，里面是你常用 bash commands 的 permissions allowlist。
- 写一个 starter `CLAUDE.md`，500 到 2000 tokens，包含项目、stack、code style、how-we-test。
**2. 周二。** 你的第一个 verification skill。
- 从上个月最痛的“Claude 写出来看似正确但实际不能用”的模式里挑一个。
- 建一个 skill folder，里面放一个能端到端 exercise 它并 assert 结果的 script。
- 这是你今年 ROI 最高的工程动作。它也是 Boris 第 5 条建议的具体形态。
**3. 周三。** 三个 slash commands。
- 从典型七个里挑三个。把 `.md` 文件写进 `.claude/commands/`。每个先手动测试，再 loop。
**4. 周四。** Loop 它们。
- 一个 session，设置 `/loop 5m /babysit`、`/loop 30m /slack-feedback`、`/loop 1h /pr-pruner`。让它们跑一整天。
- 根据让你意外的地方调 prompt。
**5. 周五。** 两个 Routines 和一个 workflow。
- 通过 /schedule 安排 `/morning-report` 和 `/deep-audit`。在真实代码库级任务上跑一个 ultracode workflow。
- Pro 每天 5 个 Routines，Max 15 个，Team/Enterprise 25 个。先挑最有价值的。
**6. 周末。** Distillation。
- 添加 Saturday 3am 的 `/distill-claude-md` Routine。周日早上 review 并 merge。
- 第二周周一早上，你醒来时会看到一份 morning report、一个 triaged inbox、八条夜间 audit findings、六个来自 X mentions 的新产品想法，以及一个更锋利的 CLAUDE.md。
---
### 结尾：写 loops
模型会不断变聪明。每个季度，都会有人发布一个东西，让你上个季度写的聪明 prompt 过时。
模型会变成 commodity（商品化基础件）。它本来就该如此。
会滚雪球的是 harness。
- 你 session 里的七个 loops。夜里运行的八个 Routines。你花一周打磨的 verification skill。Claude 写的、被你保存下来并从 slash command 调用的 workflow。每周日早上提炼团队 tacit knowledge 的 CLAUDE.md。
Boris 说，他的工作是写 loops。
- 他已经写得够久了，以至于他在发现之前一个月就已经卸载了 IDE。这就是现在这份工作的字面含义。
- 好消息是：Anthropic 在过去六个月里发布了你需要的每一个 primitive。Pattern language 已经公开。Claude Code 创造者描述自己使用的 stack，可以从公开材料复现。你刚刚读完了 spec，剩下就是组装。
- 坏消息是：没人会替你构建你的 HIVE。
- 去做周一清单。每天加一个 loop。到月底时，你回头看自己过去的 workflow（一个 Claude 穿着风衣，背后贴着三个 system prompts），会不敢相信自己以前居然是那样工作的。
- 模型会成为 commodity。Hive 是你自己的。
构建 loops。交付 loops。让 loops 去交付剩下的东西。
---
*Disclaimer*
*本文由作者基于自己的 notes 和最新文档写成，并由 Opus 4.7 编辑。*