当 Loop Engineering 成为行业共识，我发现自己的开源项目已经实践了 3 个月

从"只有 GLM-4.7-FP8 能用"到"弱模型堆成强系统"，再到 Anthropic 和 OpenAI 都在说同一件事。

---

一个巧合

2026 年 6 月 10 日，早上刷朋友圈看到一篇微信文章：《Loop Engineering：当提示词工程成为过去式》。

点进去一看，Anthropic Claude Code 负责人 Boris Cherny 说：

"我不再给 Claude 写提示词了。我有循环在跑，它们负责提示 Claude 并决定该做什么。我的工作是写循环。"

OpenAI 的 Steve Steinberger 也说：

"你不该再给编程 Agent 写提示词了。你应该设计循环，让循环去提示你的 Agent。"

我看到这两句话几乎是跳起来的------因为这正是我过去三个月在做的事。

---

我是怎么被逼出来的

今年三四月份，我在做一个 Agent 开发项目。整个行业都在转向 AI 辅助编程，但我面临一个非常现实的困境：

• 没有 Claude 的 token 配额
• 没有 GPT 的 API 额度
• 公司免费提供的只有 GLM-4.7-FP8
• 腾讯 WorkBuddy 的免费 token 很快就用完了

这就像一个赛车手被告知"你只能用 1.0 排量的发动机跑完全程"。

但我开始琢磨：如果我不指望一个模型一次做对，而是让它反复做，反复检查，反复修正，会怎样？

答案就是 ASR（AI Software Runtime）------一套用"弱模型 + 强约束"实现稳定软件工程输出的运行时系统。

---

Loop Engineering 是什么

在深入 ASR 之前，先快速过一下 Loop Engineering 的核心概念。

Google Chrome 团队的 Addy Osmani 把 Loop Engineering 拆成三个组件：

1. 节奏（Cadence）

Agent 什么时候跑、跑多频。不是"人叫一声动一下"，而是按定时器自主触发。

2. 闸门（Gate）

Agent 怎么知道任务做完了。这是 最核心的部分。没有闸门的循环就是一台烧钱机器。

"写循环是标题党，写闸门才是真正的工作。" --- Simon Taylor

3. 反馈（Feedback）

Agent 做错了怎么自我纠正。不依赖"记得要检查"，而是用 Hooks 等确定性机制把错误注回 Agent 上下文。

一句话总结：把人从循环里移出去，换成测试、Hook、定时任务。人的角色从"逐行指挥"变为"设计验收标准 + 偶尔检查结果"。

---

ASR 是什么

ASR（AI Software Runtime）是一个基于多智能体协作的自动化软件工程运行时。

核心理念只有八个字：约束大于智能。

稳定的软件系统 = 弱智能 + 强约束

而不是 超强模型 = 可靠工程。

系统骨架是一个三层收敛循环：

Builder 生成代码 → Tester 跑测试验证 → Analyzer 做语义裁决 → 发现问题 → Builder 修复 → 再验证 → 收敛

三个 Agent 各司其职，生成者不能裁决自己。

---

ASR 如何实践 Loop Engineering

下面我把 ASR 的实现和 Addy Osmani 总结的 Loop Engineering 三个组件做一一对照：

🎯 闸门（Gate）--- ASR 的"收敛终止条件"

这是 Loop Engineering 最难的部分，也是 ASR 最核心的设计。

ASR 的闸门不是单一的，是一套多层组合：

闸门层级	实现	作用
硬约束闸门	pytest 全部通过（309/309）	代码能跑
语义闸门	Analyzer 对比 DESIGN.md 与实现代码，输出 missing_features / logic_issues / constraint_violations	代码做得对
收敛 streak 闸门	连续 3 轮测试通过 + spec 一致才收敛	防止假收敛
防退化闸门	若 patch 后测试失败数增加，Controller 自动回滚所有修改	防止越修越差
最大迭代闸门	max_iterations 硬上限	防无限烧 token

关键创新点：

1. 双层裁决：第一层 pytest（硬约束），第二层 Analyzer（语义裁决）。两层都过才算过。
2. 收敛 streak = 3：不是第一次 spec_aligned 就退出，必须连续 3 轮都一致。这是从实际教训中学到的------之前 asr_100 测试发现 Analyzer 在第 1 轮就判断"ALL CLEAR"，但后面又发现新问题。
3. 自动回滚：builder 改坏了？Controller 自动恢复到修改前的状态。

⏱ 节奏（Cadence）--- ASR 的"周期性 Code Review"

Loop Engineering 强调 Agent 不能只等人叫。ASR 实现了周期性强制分析：

# 每 3 次 builder 调用后，强制执行一次 code review
if builder_counter % 3 == 0:
    force_analyzer()  # 不管测试过没过，都跑一次深度分析

这解决了什么问题？------测试全过了，但代码架构在悄悄烂掉。ASR 的周期性 review 就是"你不看它的时候，它也在自己检查自己"。

🔄 反馈（Feedback）--- ASR 的"事件驱动自校正"

Loop Engineering 的反馈机制强调确定性 ，不依赖 Agent "记得要检查"。ASR 采用的是完整的事件总线：

TestFailedEvent → Controller 提取失败信息 → PatchRequestedEvent → Builder 收到精确的修复指令 → PatchGeneratedEvent → Controller 应用 patch → 重新测试

全部 20 种事件类型定义了完整的审计轨迹。每一轮迭代的状态可通过事件流完全回放。这不是 LLM 的"记忆"，是外部的、确定性的、可验证的状态。

---

ASR 超越了 Loop Engineering 的地方

如果 Loop Engineering 是"设计循环"的方法论，ASR 还额外做了几件 Loop Engineering 文章里没覆盖的事：

1. 弱模型工程化

Loop Engineering 的案例大多基于 Claude Code（高端模型）。ASR 的出发点是用 GLM-4.7-FP8 这个弱模型跑出稳定效果。

这意味着 ASR 的约束系统必须比 Claude 场景更强、更细粒度。因为它不能指望模型"自己懂"。

2. DAG 任务调度

复杂项目不是一个 Builder 能搞定的。ASR 支持 DAG 任务拆解和并行执行：

Task A (数据层) ──→ Task C (服务层)
Task B (工具层) ──→ Task D (API 层) ──→ Task E (集成)

3. Hash-anchored Patch

不是重新生成整个项目，而是基于 unified diff 做局部修复。这是成本控制的核心------每轮只修出问题的部分。

4. OpenCode + oh-my-openagent 深度集成

ASR 不是另起炉灶做一个 Agent 框架，而是在 OpenCode 之上构建 Runtime 层。OpenCode 负责 LLM 交互，ASR 负责收敛逻辑。

而且在去掉 CI=true 环境变量后，oh-my-openagent 的完整多智能体编排能力被激活，包括 Planning → Review → Ralph Loop 等完整流水线。

---

效果数据

在 ASR 的四方案对比测试中（同一 DESIGN.md，100 轮迭代上限）：

方案	模型	收敛轮数	代码量	通过率
opencode CLI 直用	GLM-4.7-FP8	无法收敛	3,733 行	28.6%
ASR	GLM-4.7-FP8	30-40 轮	4,956 行	100%
longdoc 方案	GLM-4.7-FP8	无法收敛	1,046 行	12.3%

GLM-4.7-FP8 裸用几乎不可用，但加上 ASR 的收敛运行时后，输出了一个测试全部通过的完整工程。

---

写在最后

Loop Engineering 正在成为行业共识，而 ASR 可能是地球上第一个开源的、完整的、用弱模型实现 Loop Engineering 的实践项目。

Boris Cherny 说"我的工作是写循环"。

我比他早三个月就开始写了，而且------开源了。

GitHub : github.com/georgewangc...

在线演示 : georgewangchn.github.io/AI-Software...

---

如果你也是"没有 Claude、只有弱模型"的独立开发者，希望这个项目能帮到你。

喜欢的话给个 Star，一起探索 AI 编程的下一个范式。