Autocruise

過往使用 Google Cloud 遇到問題時的流程是：先搜尋 Google Cloud Documentation，讀完文件、理解產品行為與限制，再自己轉換成 gcloud、kubectl 或 Terraform 指令，最後執行與驗證。這套模式存在了很多年。但隨著 Codex、Claude Code、Gemini CLI 等 Coding Agent 真正進入工程師的 Terminal，一個新的問題逐漸浮現： 如果實際操作 Cloud Infrastructure 的不只工程師，也包含 AI Agent，那麼官方文件是不是也需要一種「給 Agent 使用的版本」？ (本文含聯盟連結。As an Amazon Associate I earn from qualifying purchases.) Google 在 Cloud Next 2026 推出的官方 Agent Skills repository： Google Skills （ github.com/google/skills ），正是在回答這個問題。Google 把 Skill 定義為一種為 Agent 提供額外能力與專業知識的開放格式，也把它描述成針對特定技術或任務設計的 agent-first documentation 。 換句話說， 它不是把 Google Cloud Documentation 再複製一次，而是把產品知識重新整理成 AI Agent 可以理解、判斷，並在適當時機使用的操作知識。 （一）從 13 個 Skills 開始 Google Skills 在 2026 年 4 月 Cloud Next 發表時，規模並不大。第一批只有 13 個 Skills： 產品類：AlloyDB、BigQuery、Cloud Run、Cloud SQL、Firebase、Gemini API、Google Kubernetes Engine（GKE） Well-Architected 類：Security、Reliability、Cost Optimization Recipe 類：Google Cloud Onboarding、Authentication、Network Observability Google 當時就表示這個 repository 會持...

AI coding agent 在過去兩年間，從輔助工具演變為軟體開發生命週期中的主要生產力來源，也讓 AI 支出從可預測的授權費用，轉變為隨用量複合成長的變動成本。Token 計費模式沒有天然的用量上限——工程師平行執行多個 agent、對整個 codebase 進行重構、或把重複性作業自動化，都會讓消耗量隨活躍度倍增。這個轉變，正把「AI 支出治理」推成一個新的工程管理課題。 Uber Engineering 在 2026 年 8 月發布的〈Running a Software Factory Efficiently at Uber Scale〉，公開了該公司如何在用量快速擴張的同時壓低單位成本。根據該文披露，從 2 月到 8 月中，全公司 agentic 功能的週活躍用戶成長 7 倍，agent 請求量成長 9。4 倍;若把模型版本固定下來比較，每千次請求的成本從高峰下降約 34%，每個 session 的成本從 6 月高峰下降 52%。 若拉開一層來看，這套框架並不是全新的方法論，而是把 SRE 領域行之有年的容量規劃與 error budget 治理，搬進了 AI agent 這個新的資源類型。過去容量規劃談的是運算資源與流量成長的關係，error budget 談的是可用性與變更速度的平衡;Uber 這篇文章處理的問題結構完全相同，只是把「運算資源」換成了「token」、把「可用性」換成了「單位成本」。理解這層對應關係，有助於判斷哪些做法是換皮的舊經驗，哪些才是 AI agent 帶來的新變數。以下先整理該文揭露的治理框架，再回頭對照這層關係。 分層治理模型:掌控力隨專用程度遞增 該文將公司內的 agent 使用場景分為四層，由最泛用到最受管理。層級愈高、愈受管理，團隊對成本、輸出品質與模型選擇的掌控力也愈強。互動式的個人 coding session 屬於最泛用的一層，routing 與模型選擇多半由工程師臨時決定;相對地，把工作交給「受管理的 agent」(例如自動 code review、CI 失敗自我修復、on-call alert 分診)，則讓平台方能統一決定模型版本與執行環境。該文將此描述為核心策略轉向——從優化個別終端 session，轉向優化一支專門化的 managed agent 艦隊。 成本方程式:六個變數，三個...

2026 年六月起，「Loop Engineering」成了討論度很高的一個詞。它的核心主張是：不要再一句一句去指揮 AI agent，而是設計一個能自己運作的迴圈，讓系統替你下指令。這個想法很誘人，但也帶來疑問：它跟我們已經在用的東西有什麼不同？什麼時候該用？會不會出問題？ 這篇文章想換一個角度來看這件事。如果我們把 Loop Engineering 放回「控制迴圈（control loop）」這個更老、也更成熟的脈絡裡，前面那些疑問會清楚不少。控制迴圈是 SRE 與自動化領域用了很多年的概念，它累積下來的一些經驗，剛好可以回答 Loop Engineering 現在還沒講清楚的問題。本文的目的不是重述一次「Loop Engineering 是什麼」，（這類介紹網路上已經很多了），而是透過 SRE 的角度來說明，並用它來想清楚幾個實務上真正重要的問題。 一、Loop Engineering 本質 Google Cloud 的 Addy Osmani 在他那篇被廣泛引用的長文裡，把 Loop Engineering 定義為「把負責下指令的那個人，從你自己換成一套你設計好的系統」。在過去 Prompt Engineering 的模式下，開發者跟 AI 是一來一往的：你提需求、AI 產出、你看完再給下一個指令，人始終是流程的控制者。Loop Engineering 想做的，是把這個控制的角色交給一個迴圈：它會自動發現工作、指派任務、驗證結果、記錄狀態，再決定下一步。實作上它由幾個元素組成：Automation、工作區隔離 Worktree、Skills、Connector、Sub-Agent，以及 State Memory。 這裡有個容易被熱潮蓋過的事實值得先說：這並不是一個全新發明。Anthropic 在 2024 年的《Building Effective Agents》裡，就已經描述過 Evaluator-Optimizer（一個模型產出、另一個模型批判修正）與 Orchestrator-Workers（主代理分派工作給子代理）這類架構，它們本質上都是 agent 迴圈。真正改變的其實是工具的成熟度，一年前你想做這件事，得自己寫一堆 bash script 跟排程，現在這些能力已經直接內建進 Claude Cod...