Google 工程師 Addy Osmani 最近提出了 Loop Engineering 這個概念：別再一句一句跟 AI 對話了，直接設計一個自動化迴圈，讓 AI agent 自己跑、自己改、自己驗，反覆迭代直到任務完成。
概念很漂亮。但我看完之後一直卡在同一個問題上：迴圈跑完，AI 說「做好了」- 你怎麼知道它是真的做好了？
Osmani 的答案是 sub-agent 互審 - 讓另一個 AI 當主管來檢查。但 AI 審 AI 終究是 probabilistic 的。兩個模型都覺得對，不代表真的對。這篇想聊的是一塊他沒提到的積木，以及為什麼有些環境天生就比其他環境更適合放 AI agent 進去跑 loop。
Loop Engineering 30 秒版
Osmani 的架構有五塊重要的組成加一個記憶層：
- Automations，排程觸發，不用人工手動啟動
- Worktrees，隔離的平行工作區，多個 agent 不會互相影響
- Skills，專案慣例寫成文件，agent 每次動手前先讀一遍
- Plugins/Connectors，讓 agent 能透過真實世界的工具（Slack、DB、CI）來獲得更多資料
- Sub-agents，做事的跟檢查的分開，避免產生bias 或者盲點
- External Memory，進度表，確保明天醒來還能接續昨天的進度繼續做下去
核心精神就是從「手動對話」升級成「設計系統」。但品質保證那一層，他只給了 sub-agent review。
但這裡問題就來了：如果兩個 AI 有同樣的 blind spot 呢？
缺失的第六塊積木：Deterministic Verification
Sub-agent 互相審核的天花板很明確：它終究是一個模型在評估另一個模型的輸出。輸出看起來合理、邏輯說得通，reviewer agent 就放行了。但「看起來合理」跟「事實上正確」並不是同一件事。
Deterministic verification 不一樣。它不估計、不評估、不用信心分數。它給你 binary pass/fail，對就是對，錯就是錯，沒有灰色地帶。
| 驗證方式 | 性質 | 失敗時的訊號 |
|---|---|---|
| Sub-agent review | Probabilistic | 「我覺得這裡可能有問題」 |
| Unit test | Semi-deterministic | 「這個 assertion failed」 |
| 編譯 + boot + CTS | Fully deterministic | 「系統拒絕啟動 / 硬體拒絕配合」 |
Unit test 算半個，它是 deterministic 的，但覆蓋率是人決定的。你沒寫到的 case，它就不會幫你擋。
但編譯失敗、SELinux deny、boot loop，這些不是你寫的 test，是系統本身的物理限制。你無法避開這個限制。
為什麼 AOSP / 嵌入式天生站在最有利的位置
做 web 的 Loop Engineering，最硬的驗證通常就是 CI test pass。但測試是人寫的，覆蓋率永遠有缺口。AI agent 完全可以寫出一段「能跑、test 也過、但邏輯是錯的」code。
AOSP 的環境不一樣。驗證不只是你寫的 test，是系統本身在各個層級設下的 hard gate：
- 編譯不過 = 型別系統否決你。API 不存在？連 binary 都生不出來。
- SELinux deny = kernel 否決你。權限沒開？process 直接被擋，不是 warning 是 denial。
- Boot loop =
PermissionManagerService否決你。狀態不一致？系統拒絕啟動。 - CTS fail = Google 的合規框架否決你。行為不符規範？不給你出貨。
這些驗證層不是工程師額外設計來管 AI 的。它們本來就在那裡，為了保護系統完整性而存在。AI agent 只是剛好撞上了一個已經佈好防線的環境。
Web app 定義「能跑」很模糊，頁面 render 了、沒有 500、用戶沒投訴，大概就算能跑。但一台 Android 設備定義「能跑」非常明確：開得了機、過得了驗證、SELinux enforcing mode 下所有 service 都活著。Binary 標準，沒有「大概能跑」這回事。
實際的 Loop 長什麼樣
把 Osmani 的積木對應到我們現有的 AOSP 工作流：
| Loop Engineering 積木 | AOSP 實現 |
|---|---|
| Automations | Jenkins CI / scheduled builds |
| Worktrees | git worktree（每個 feature 隔離） |
| Skills | ~/.claude/skills/ + knowledge docs |
| Plugins/Connectors | AOSP MCP（module deps、sepolicy、HAL interfaces、init services） |
| Sub-agents | Gerrit code review + AI reviewer（fresh sub-agent，no author bias） |
| External Memory | Plan docs + active-projects.md + TaskList |
| Deterministic Verification | 編譯 / boot / CTS / VTS，免費送的 |
一個具體的 loop 跑起來長這樣：
Jira ticket 進來
→ Agent 讀 source tree（MCP grounding，不靠記憶猜）
→ Agent 生成 CL
→ Sub-agent review（fresh context，no author bias）
→ Jenkins build（compilation gate）
→ Device boot（PermissionManager gate）
→ CTS subset（compliance gate）
→ Human +2（final checkpoint）
→ Merge七個步驟裡，有三個是 deterministic gate。Agent 想要繞過它們？不可能。編譯器不接受「看起來合理」當理由。
那 Web 怎麼辦？
不是說 web 就不能做 Loop Engineering，當然可以。但如果你想往 deterministic verification 靠攏，需要自己補一些東西：
- TypeScript strict mode = 編譯層的近似（型別錯就不給你跑）
- Contract testing / schema validation = boot-time check 的近似（API 契約不 match 就 fail）
- Property-based testing = 比 unit test 更接近 deterministic（自動生成 edge case）
但老實說，這些都是「近似」。Web app 的 runtime 太寬容了，undefined is not a function 不會讓你的 server 拒絕啟動，它只是在某個用戶的某次操作裡炸一下。嵌入式的 runtime 沒那麼客氣：錯了就是整台機器不動。
所有的 hard gate 都不是全能的
Deterministic verification 也有盲區。邏輯正確但 UX 爛、性能 regression、race condition，這些不會讓編譯失敗，也不會讓 CTS 報錯。還是需要人類判斷。
但 bottom line 明確了：至少「系統會不會炸爛」這個問題，在 AOSP 的 loop 裡，AI agent 搞不爛它。它可以犯錯，但犯的錯跑不進 production。這個 bottom line 在 web 環境需要花一些功夫來調整。
Loop Engineering 是架構，幻覺防線是理論基礎，AOSP MCP 是落地實現。三者疊起來的結論：不是所有 codebase 都同樣適合放 AI agent 進去跑 loop。有 deterministic verification 的環境，天生就是更安全的遊樂場。
參考資料
- Addy Osmani, Loop Engineering, 2026
- AI 為什麼會一本正經地胡說八道？從底層機制到實際可用的工程策略，姊妹篇
- S-LoRA / vLLM multi-LoRA serving infrastructure
- Android CTS (Compatibility Test Suite) documentation