---
title: "跑了一个月循环后，我学到了什么？？？"
author: "Jason Zhou (@jasonzhou1993)"
source_url: "https://x.com/jasonzhou1993/status/2075179471951614381"
published_at: "2026-07-09T11:25:15.000Z"
fetched_at: "2026-07-09T14:52:23Z"
updated_at: "2026-07-09T14:55:52Z"
language: "zh"
review_status: "draft"
---
# 跑了一个月循环后，我学到了什么？？？
上周我写了 loop engineering：从给 agent 下提示、让它完成一个任务，转向设计一种系统，让 agent 自己决定要做什么、执行、验证，并随着时间不断改进。
但很多人的反应是：好，我被说服了，可我到底该怎么构建一个？**更重要的是，我怎么构建一个真正能工作的？**
因为任何人都可以把 agent 包进一个 while true，然后叫它 loop。这只是最容易的 5%。真正的工作，是那些能让你放心放手的护栏。
过去一个月，我们一直在做一个实验：通过搭建很多很多 loop 来运行 [@SuperDesignDev](https://x.com/@SuperDesignDev)。这里想分享一些真正实用的经验。
### 一个好 loop 的解剖结构
我们运行的每个 loop 都有同样四个部分。
### 1. Loop contract
一个 Markdown 文件，每次运行触发时都会注入给 agent。这是 loop 的宪法。它包含四件事：
- **Goal**（目标）：什么叫赢，以及是否真的有终点
- **Boundaries**（边界）：它可以自由做什么、绝不能做什么，以及哪些可以自己发布、哪些需要人类介入
- **SOP**（标准作业流程）：每次运行遵循的步骤
很多人对 boundary 部分投入不足，但它恰恰决定你能不能放心放手。拿我们的一个 loop **Error Sweep** 来说：它每天早上读取生产环境错误追踪器，挑出最严重的新 bug，然后发出修复。下面是它 contract 里真实的 boundary 片段：
```
- Fix only when the root cause is clear AND the fix is low-risk.
Anything risky or large: open a PR and flag a human. Do not merge it yourself.
- Make the smallest fix that works. One PR per fix.
- Never open a new PR while a previous Error Sweep PR is still unmerged.
- Never copy credentials, tokens, or user data into a report or a PR.
```
这些都不是在讲怎么修 bug。它们是四句话画出的围栏。在围栏内，agent 可以自己发布；在围栏外，由人类决定。你要给 agent 画清楚这幅图：什么时候可以自己发布，什么时候应该停下来问人。
我们通常会把 contract、state、logs 放在一个 Markdown 文件里，像这样：
```markdown
# <loop name> — contract
## Goal
What winning looks like. Is there a finish line, or does this run forever as a monitor?
## Boundaries
- Free to do: ...
- Never do: ...
- Ship on its own vs ask a human: <the exact line>
## SOP (each run)
1. Read state + logs.
2. Gather what changed. Pick the single most worthwhile thing to do.
3. Do it (or hand it to an executor).
4. Verify. Record what happened. Report.
## Current understanding
...Current state of the loop run
## Logs
...Logs of past runs
```
### 2. State + logs
一个在两次运行之间什么都记不住的 loop，只是一个多绕了几步的 cron job。它需要记忆，而且要分成两部分：
- **State** 是持久图景：backlog、当前假设、它已经发出但还需要跟进的实验。每次运行开头读取，并且刻意保持很小。
- **Logs** 是逐次运行发生了什么的追加式记录。
最清楚的例子，是我们的 Error Sweep loop 维护的 state。它用这部分 state 避免浪费一次运行去重新调查自己已经理解的东西：
```
## Skip these fingerprints (known noise or upstream, not ours)
- ResizeObserver loop limit exceeded
- Stripe.js network blip on /checkout
## Fixed, still watching
- null-team-on-login (019edc8a) — fixed in #1027, confirm it stops firing in prod
```
没有这个块，loop 每天早上都会重新发现同一个噪声错误，浪费一次运行去追它，还会惹你烦。有了它，loop 会跳过自己已经判断过的东西，把注意力放在新东西上。State 是 loop 停止重复自己的地方。
State 也保存 loop 在运行中学到的东西：关于谁会转化的工作假设，以及它从犯错中学到的习惯。我们的 CRM loop 里有这样的行：
```
- users who hit the credit wall in their first week reply about 3x
more than everyone else. Draft those first.
- Before drafting, check what the user actually built, not the label on their
profile. One account tagged "SaaS dashboard" was really a print brochure.
```
这些都不是来自最初的 contract。Loop 是一轮一轮跑出来才挣到这些经验的；现在每次运行都会从更聪明的一步开始。这就是为什么一个好的 loop 到第三个月会比第一周更有价值：它的 state 吸收了自己见过的一切。
### 3. /verify
对于任何交付高风险工作的 loop（例如真实的生产代码变更、给真实客户发消息），这是前置条件。基本上，你要确保验证流程足够简单，并且能产出人类容易审查的证据。
一般来说，这意味着：
- 搭好环境，让验证既省 token 又可靠
- 有一种方式把验证证据包含进去
对工程任务来说，这意味着：
1. 一个 [dev-local.sh](http://dev-local.sh/) 脚本，方便启动本地开发环境和远程 sandbox 环境来测试（比如 crabbox）
2. 让 agent 能像真实用户一样自驱动应用的工具（例如 Playwright-CLI）
3. 包含测试 SOP 的 /verify skill
4. 一个上传截图和视频证据、并附到 PR 上的地方（我们上传到 GitHub release assets）
其他非工程工作可能更棘手，但不是不可能。比如 CRM loop 里，我们有一个 verifier agent，会用特定的反废话规则审查草拟出来的消息。
我们把这套工程任务设置开源成了一个 verifier-setup skill（https://github.com/AI-Builder-Club/skills）。
结果是，一个来自 loop 的 PR 不会以“相信我，它能跑”的形式出现。它会带着一段功能正常工作的视频出现。我可以几秒内批准，因为我看到的是行为，而不是读着 diff 然后祈祷。这也是为什么 verifier 是判断一个 loop 是否值得做的决定性因素。
### 4. Trigger
是什么把 loop 唤醒。它有三种形态，选对形态就是成本模型的一半：
- **Continuous for-loop。** 这是 ralph-loop 或 /goal 类型的触发方式。Agent 会在 for-loop 里一直运行，直到条件满足。这是自主研究 agent 背后的形态。适合有边界的推进（“一直做，直到测试套件变绿”），但作为常驻机制会很浪费。它主要适用于存在即时反馈循环且规格清楚的场景。（比如大多数修 bug 的工程工作）
- **Time based。** 由日程触发 loop：每小时、每天早上 6 点。我们的 Error Sweep、React Doctor、doc maintainer 和 CRM loop 都跑在 cron 上。
- **Workflow / event based。** 新邮件到达、事故被打开、PR 落地。Loop 只有在有东西可处理时才运行。它甚至可以和 time based 结合——例如一个基于时间的 tick 每小时运行脚本检查是否有新的支持工单；如果有，就触发 agent；如果没有，就记录并保持安静。这是管理 loop 成本的好办法；你会在 Evolve 部分看到它的机制。
### Orchestrator + Executor + Verifier
一旦 loop 触碰到任何非平凡工作，我们就开始把它拆成三个角色：
> Orchestrator 负责找到工作。Executor 在隔离环境中完成工作。Verifier 证明它确实有效，并附上证据。
1. **Orchestrator / prioritiser（编排者 / 优先级排序者）。** 按计划醒来的 agent。它的工作不是完成任务，而是*找到*任务：收集信号，看发生了什么变化，挑出这次运行最值得做的一件事，然后交出去。
2. **Executor（执行者）。** 在隔离空间里完成实际工作（对代码来说，就是从 main 拉出一个新的 git worktree，这样它永远不会污染你的工作区，也不会污染另一个 loop 的运行）。
3. **Verifier（验证者）。** 独立确认 executor 的工作，并产出人类一眼能看的证据。
但不是所有 loop 都需要这三层。三层形态是复杂的、会发代码的 loop 最终长出来的样子。很多好的 loop 只是 orchestrator 自己把整件事做完。让我给你看这两端。
### Evolve Loop：构建反脆弱 loop
在 Nassim Taleb 的《反脆弱》里，他把系统分成三类：脆弱系统害怕波动，一次事故就意味着巨大损失；稳健系统能承受波动，并恢复到原来的样子；反脆弱系统会从波动中获益，每次冲击都会让它变得更强。玻璃是脆弱的，石头是稳健的，你的免疫系统是反脆弱的：每一次小感染都会训练它。
把这个视角指向 loop，问题就变得具体了：**一次运行失败时，教训去了哪里？** 在我们的实践中，一条教训有三个去处，抽象层次从低到高依次是：
每个人都有 logs，而且它们只会越来越长。把经验提炼成规则，才会让 loop 变得反脆弱。问题是：谁来做这个提炼？
所以在 Loopany（我们为这些 loop 构建的内部应用）里，这变成了一个单独的运行角色：**evolve**。一个 agent session 会读取这个 loop 最近十几次运行的 logs、结果和成本，然后提出问题：我们在哪里重复犯错？哪些运行被浪费了？哪条 boundary 太松，哪条太紧？它的输出不是产品代码，而是对 loop 本身的修改：
- loop contract 和 state 约定
- 触发机制
- 用于重复性、确定性 agentic 步骤的脚本
- Skills
- 给人看的 dashboard
**这是一个用来改进 loop 本身的 loop。**
##
## 运行 Superdesign 的真实 loop
我们一直在用 loop 自动化 Superdesign 的大部分工作，有些有效，有些无效（经验会在另一篇博客里写）。下面是几个我们日常运行的真实例子，相对容易让你复制和搭建。
### Doc maintainer loop
这是我们最简单、也最有用的 loop 之一。它每周一次，让项目文档保持诚实。
这个 loop 只有一层。Orchestrator 读取 diff，检查文档，如果有东西漂移了就打开一个 PR，然后结束。没有单独的 executor，也没有单独的 verifier，因为这个任务足够简单、爆炸半径足够小，一个 agent 可以把它装在脑子里。
你当然可以加层：加一个 verifier 来事实核查每条文档声明，加一个 pass 来标记它注意到的技术债。但你不应该这么做，至少在简单版本真正烧到你之前不要。先构建一层版本，感受到具体痛点，再只添加那个能修掉痛点的层。
这是我会建议你第一个构建的 loop，所以这里给你一个模板：
```markdown
# doc-maintainer — contract
## Goal
The README, setup guides, and examples always match what the code
actually ships. Zero drift found = a successful run, not a wasted one.
## Boundaries
- Ship on its own: open ONE pull request with the fixes. That's it.
- Never: rewrite accurate docs to look busy, touch anything outside
the docs, stack a 2nd PR while last week's is still open.
## SOP (each run)
1. Read the diff: every commit + PR since the last sweep (cursor is
in state).
2. Compare README, setup guides, examples, runbooks against what the
code ships NOW.
3. Verify for real: run the commands, check the links, try the
examples. Never trust memory.
4. Drift found → smallest fix, fresh worktree, one PR explaining what
drifted and why. Nothing stale → clean stop.
5. Move the cursor, log the run.
## State
- last-sweep cursor (commit hash)
- open PR, if any
## Logs
- one dated line per run: drift count + PR link, zero included
```
### Bug hunter loop
有些 loop 会把真实代码发给真实客户，而那里的错误代价很高。这时候三层都会派上用场。
我们的 **Error Sweep** loop 每天早上运行：
1. **（orchestrator）**它从错误追踪器里拉取过去 24 小时的生产错误（我们写了一个特殊脚本，从 PostHog / LLM log / server logs 收集数据），按出现次数 × 用户数排序，跳过 state 里已知噪声的 fingerprint，然后挑出影响最大的那个*新*异常。它会拉取反混淆后的 stack trace，并找到根因。
2. **（executor）**如果原因清楚且风险低，它就在一个新的 worktree 里修复，并发出 PR。如果风险高或改动大，它会停下来并标记给人类。Boundary 里的这条分支每次运行都在真正发挥作用。
3. **（verifier）**修复必须先被证明，才算数；之后这个 loop 还会在后续运行中继续观察这个 fingerprint，确认错误真的停止出现。一个没有让真实数字变化的修复，就不是修复。
**React Doctor** 是同样的形态，只不过目标从运行时错误变成代码健康：每天早上，它用 npx react-doctor 扫描应用，挑出最严重的单个问题，在隔离 worktree 里修掉，验证，然后打开一个 PR。它会把健康分数作为每日指标报告出来，让你能看到曲线变化。而且它有一条小护栏，让它不会难以承受：
> If a previous React Doctor PR is still open and unmerged, don't open another one today. Refresh the open PRs' statuses and still report the score.
这条规则就是一个有用的 loop 和一个把你淹没在 30 个永远不会审查的 PR 里的 loop 之间的区别。Loop 必须尊重你的 review 带宽，而不只是尊重它自己的吞吐量。
### Support triage loop
它每小时针对我们的 Intercom inbox 运行一次。它的指导原则是：**每张支持工单都是一个免费窗口，让你看到产品缺口。** 一个写信来的用户，等于免费递给你一份 bug 报告、一个转化阻塞点，或者一个困惑信号。大多数支持系统会回复消息，然后把这个窗口扔掉。这个 loop 会两者都保留。
每次运行有四个动作：
1. **拉取窗口。** 上次运行以来的一切，加上今天到期的所有跟进。窗口会在静默时段自动扩大，所以漏掉一次触发也不会丢工单。按最后发言者分桶：customer = 需要回复，bot = 审查它，teammate = 已经处理。
2. **先调查，再回复。** 这是差异点。对每张工单，先根据真实数据查根因：检查用户账号、他们的实际 session、错误日志、账单记录。永远不要盲答。很多时候，用户对问题的描述并不是问题本身。
3. **扇出到三个输出。** 每张工单最多可以产生三件事：一条在会话里立即解决用户问题的**回复**；
一个归档到知识库的**信号**：工单背后的产品缺口，只写一次，之后 growth 和工程 loop 可以根据这个模式行动；
当根因是真 bug 时，它会在新的 worktree 里**生成一个修复 agent**，带上 verifier 和证据，使用和 bug hunter loop 相同的机制。
4. **写回，然后睡眠。** 设置跟进日期，记录这次运行，等待下一次 tick。
让它可以安全面对真实客户的 boundary 是：回复分层。常规的事实性答案可以自己发出。任何敏感事项、退款、愤怒用户、非英语且我无法审查语气的回复，都只能在人类批准后发出。
**搭建它**和其他 loop 是同一个配方：一个 contract 文件，加上一个每小时的 cron。下面是 support contract，裁剪成你可以直接拿走的模板：
```markdown
# support-triage — contract
## Goal
Every inbound ticket gets a correct, investigated response within an hour,
and every product gap behind a ticket becomes a signal the team can act on.
No finish line: this is a monitor.
## Boundaries
- Ship on its own: replies to routine, factual questions (how-to, billing
lookups, known issues with a documented fix).
- Ask a human first: refunds, angry or churn-risk users, anything legal,
any reply in a language the team can't review.
- Never: promise features or timelines, share another user's data, close
a ticket without a root cause written down.
## SOP (each run)
1. Pull conversations since the last run timestamp + follow-ups due today.
Bucket by last speaker (customer / bot / teammate).
2. Per ticket: investigate root cause against the product DB, error logs,
and billing BEFORE drafting anything. Never answer blind.
3. Reply per the boundary tiers. Draft-only where approval is required.
4. If the root cause is a bug: spawn a fix agent in a fresh worktree,
require verification evidence, open a PR flagged to the team.
5. File a signal for any recurring or conversion-relevant gap (dedupe
against existing signals first).
6. Set follow-up dates. Log the run.
## State
- open follow-ups (ticket id -> due date)
- recurring-theme tally (feeds signal creation)
- standing lessons (e.g. "duplicate messages = retry artifacts, not spam")
## Logs
- one dated line per run: tickets handled / replies sent / signals filed
```
然后在 cron 前面放一个便宜的 gate，让 agent 只有在窗口里确实有东西时才醒来（也就是前面说的 Evolve 动作），然后让它运行。收益不只是更快回复，而是那些信号：当五个人都问怎么导出某个东西时，那就是一个已经归档、等待 growth loop 处理的转化缺口，而不是某个人也许会在季度复盘里注意到的模式。
### CRM lifecycle loop
Loop 不是工程玩具。我们一些价值最高的 loop 从不碰一行代码。这个 loop 负责我们的客户外联，它是三层形态指向人而不是代码时最完整的表达。
每天早上：
1. **脚本先拉数据。** 过去 24 小时谁活跃了、新的商务邮箱注册用户、以及收到的所有回复。确定性的前置阶段，不在拉数据上花 LLM。已经回复的用户会完全退出 loop：正在进行的真人对话属于人类。
2. **Orchestrator 提出 segment**，而不是一次性挑人。也就是今天值得触达的高意图用户组：本周撞到 credit wall 的人、新的 business signup、高传播潜力的 builder。这些是例子，不是固定列表；segment 会在每次运行时根据数据重新提出，哪些 segment 会转化则存在 state 里。
3. **每个 segment 生成一个 executor sub-agent**，逐个用户工作：读取他们实际构建了什么，读取过去和他们的每一次交流，然后草拟一封个人邮件。永远不要盲写。Profile label 写着 “SaaS dashboard”，实际可能是一本印刷宣传册；executor 检查的是真实作品，不是标签。
4. **Verifier 在任何 draft 出去之前检查它**：根据数据事实核查邮件里的每个 claim（不能有任何虚假内容以你的名义发出），然后检查 voice 和 anti-slop 规则。这又是 SEO 故事里的 taste 问题，但在这里它是可处理的，因为“这条关于用户项目的 claim 是否真实”有可检查的答案。
5. **发送按风险分层。** 我们一开始只生成 draft：每封邮件都等待人类处理。随着 segment 证明了自己的回复率，低风险 segment 获得了在围栏内自行发送的权利。高接触 segment 仍然作为 draft 留给人类批准。自主性是每个 segment 自己挣来的，不是授予整个 loop 的。
6. **摩擦变成信号。** 当研究发现用户卡在某件事上，那不只是邮件素材，它会提交一个信号给其他 loop 读取；如果是真 bug，则生成一个 fix agent，使用和 bug hunter 相同的机制。
你在第 1 部分看到的围栏支撑了整件事：7 天抑制期、无回复最多跟进一次、用户回复就交给人类接管。而 state 负责复利：记录每个 segment 的发送和回复，保留能转化的，丢掉不能转化的。Loop 对*该给谁发邮件*的 taste 每周都会可衡量地变好，因为它是根据回复率校准的，而不是靠感觉。
```markdown
# crm-lifecycle — contract
## Goal
Turn high-intent product activity into conversations. Success = reply rate
and upgrades per segment, not emails sent. No finish line: this is a monitor.
## Boundaries
- Ship on its own: sends to segments that have EARNED it (see state:
approved_segments). Everything else: drafts only, a human sends.
- Ask a human first: any new segment's first batch, anyone who ever
replied, any claim the verifier couldn't confirm.
- Never: email anyone contacted in the last 7 days, send a 2nd follow-up
without a reply, invent facts about what a user built.
## SOP (each run)
1. Scripts have already pulled actives, signups, and replies. Read the
output. Users who replied exit to a human.
2. Score users, then propose SEGMENTS (groups, not one-off picks).
Check state for which segments converted before proposing more.
3. Per segment: spawn an executor sub-agent. Per user: read what they
actually built + every past exchange, then draft. Never draft blind.
4. Every draft passes the verifier: fact-check each claim against the
data, then voice + anti-slop rules. Nothing false goes out.
5. Route by risk: approved segments send; the rest queue for review.
6. Friction found during research → file a signal; real bug → spawn a
fix agent.
## State
- approved_segments (earned autonomy + the reply rate that earned it)
- per-segment performance (sends → replies → upgrades)
- suppression list · standing lessons (e.g. "verify from their real
work, not their profile label")
## Logs
- one dated line per run: segments proposed / drafts / sends / replies
```
###
### 好 loop 的 checklist
- [ ] **Loop contract file：** goal、SOP、输出规则，每次运行都读取
- [ ] **Boundary and constraints**：什么可以自己发布、什么要问人；no-op 也是一次有效运行
- [ ] **State + logs**：跨运行的记忆，让它不会重复做同一件事
- [ ] **Cheap verifier**：用证据证明；如果没有，就让人留在 loop 里
- [ ] **Isolated execution**：每次运行使用新的 worktree 或自己的 sandbox
- [ ] **Cost-effective trigger**：gate script 或 event；空运行不花钱
- [ ] **Loop evolve cycle**：审查运行历史，把机械工作折叠进 scripts / skills
- [ ] **Small scope**：不断拆分 loop，直到“就让它跑吧”让人感觉舒服
###
### Loopany：**我们的内部 loop 管理工具（已开源）**
<video controls src="https://video.twimg.com/amplify_video/2075178981889064960/vid/avc1/1280x720/rG7-9nI-pE3lkd5b.mp4?tag=28"></video>
我们一直在用内部工具 Loopany 来编排公司里的所有 loop。它对我们非常有用，所以我们把它开源了。
它是一个 loop 管理环境，可以连接到你团队自己的本地 agent。
- **内置 loop templates 与自动 log / state tracking**
- **Programmable triggers + Auto retry & recovery**
- **The evolve cycle**
- **Mini apps for each loop**
- **Team workspace so loops don't conflict**
欢迎试用并告诉我们反馈：[https://github.com/superdesigndev/loopany-platform](https://github.com/superdesigndev/loopany-platform)