Antigravity + Gemini + Jules + Stitch：被實戰逼出來的 Agent Workflow 起源與功能
keeponfirst-agentic-workflow-starter：被實戰逼出來的 Agent Workflow 起源與功能
2025 年底，我開始了一個看似簡單但逐步深化的實驗：
只用 Google AI 生態 (Antigravity + Gemini + Jules + Stitch) 來跑整個開發流程，
看看到底能跑到什麼程度。
最終它演化成一個完整的開源「Agentic Workflow Starter Kit」——
一套用來 結構化、可重複與可追蹤的 AI 協作流程。
🧠 一、起源：從單純嘗試到被實戰逼出來
最初，我完全沒打算做一套 workflow tool。
直到我看到訂閱Google AI Pro套餐，Jules每天配額有100次。
於是我冒出了一個想法：
「我已經買了 Google AI Pro 套餐，
那我能不靠其他 AI 工具，只用 Google 生態來做一個完整專案嗎？」
過程中，我先後用：
Antigravity 作為思想協調者 / Planner
Nano Banana（Gemini CLI）產生 UI 資產
Jules CLI 執行程式碼任務
Stitch / Pencil 做 UI 設計整合
⚙️ 二、這個 Repo 是什麼？
keeponfirst-agentic-workflow-starter 的定位是：
一個讓開發者可以快速啟動、執行、監控與追蹤 Agent Workflow 的 starter kit。
它融合了多種 AI 工具角色：
PLAN：Antigravity
ASSETS：Nano Banana
DESIGN：Stitch（可切 Pencil）
CODE：Jules CLI（可切 Codex）
REVIEW / RELEASE：Antigravity
–
它不是單純的「demo」，而是：
一套 結合 Orchestrator + Task Queue + Agent Executor 的 AI 專案 pipeline。
📌 三、核心功能與流程
1) Orchestrator — Antigravity 主管心智
Antigravity 在這套流程裡扮演:
將自然語言需求變成一系列任務
設計與拆解計畫
安排各 Agent 任務
掌握整體進度
你只要給它一句話：
/workflow Add a "dark mode" feature它就會開始拆解專案階段。
2) Phase 1: PLAN — 明確計畫與邊界
在這階段會產生像是：
plans/PLAN.md
任務拆解模板
這個階段不是寫 code，而是把需求具體化成一個可被後續 Agent 理解的架構。
3) Phase 2: ASSETS — 資產任務產生
在 Phase 2（ASSETS）階段，主要使用 Nano Banana 來處理視覺與設計相關的資產任務。
這個階段的產出包含：
圖示（icons）
視覺資源草稿
由於 Gemini Web / App 在實務上提供了更完整且穩定的生成能力，
此 workflow 採 Browser Generation 的方式：
由流程自動產生結構化 prompt
透過瀏覽器自動化操作 Gemini Web UI
將實際生成的結果直接納入 ASSETS 階段產出
這讓 Phase 2 從過去的 workaround，
正式進化為 可重複、可驗證、可自動化的資產生成流程，
同時也符合 Google AI Pro 訂閱用戶在現實環境中的可行使用路徑。
4) Phase 2.5: DESIGN — 結構化設計整合
在目前 workflow v1.9 的設計中，刻意把「設計」獨立成 Phase 2.5，
原因是實務上發現：設計若沒有被結構化，CODE 階段仍然會卡在大量人工轉譯。
因此，這一階段的目標並不是「產圖」，
而是 把 UI 設計轉換成可被開發階段直接消費的結構化資料。
在實作上，Phase 2.5 主要搭配以下工具：
Stitch：用來產出具備版型結構、元件關係與頁面層級的 UI 設計結果
Pencil：在需要補強流程、互動或使用情境時作為輔助設計工具
為了讓設計成果能夠被 workflow 程式化存取，
也另外實作了 kof-stitch-mcp，
讓 Stitch 的設計輸出可以作為 後續 CODE agent 的結構化輸入來源，
而不是僅止於人類閱讀的設計稿。
透過這一層的拆分，
CODE 階段的 agent 才能真正「接手實作」，
而不是再次進行 UI 與設計意圖的人工翻譯。
5) Phase 3: CODE — 實際程式碼任務隊列
透過：
Jules CLI (預設)
Codex CLI (可選)
產生並執行程式碼任務，並且留存 task 文件。
它支援：
非同步執行
透過 session ID 觀察進度
自動 trigger review
這是一種讓 AI 真的去 跑 code execution 而不是單純生成 code 文本的方式。
6) Phase 4/5: REVIEW & RELEASE — 回顧與交付
最後 Antigravity 會重新回顧：
是否符合最初計畫
產出是否達成預期
生成提交說明與版本
🧩 四、這套 Workflow 解決什麼問題？
以往 AI 協作的盲點在於：
結果對，但過程不可追蹤
生成不是執行
不同階段斷層明顯
而這個 workflow 的價值在於：
✔️ 有結構、有階段
✔️ 任務可追蹤、可審核
✔️ 執行階段有明確工具與可選 fallback
✔️ 不會把整個專案交給單一黑盒模型
這讓 AI 不只是「幫你寫東西」，
而是 在可被版本控制、可驗證的流程裡協作生產。
📌 五、結語：它現在被刻意設計成什麼樣子？
今天的 keeponfirst-agentic-workflow-starter 並不是一個「完成品」，
而是一個被刻意停在 可運作、可擴充、但尚未過度抽象 的狀態。
它的定位不是提供一套標準答案，
而是定義一個可以反覆實驗、反覆調整的 Agent Workflow 起點。
目前這套 workflow 已經能做到的是：
將 Agent 協作流程明確拆分成可追蹤的階段
讓任務實際被執行，而不只是生成文字
把 AI 放在「可替換的執行角色」，而非不可控的決策核心
保留人類在不可逆決策上的主導權
這也是為什麼這個專案目前仍以 starter 的形式存在。
它關心的不是「這套流程能不能包山包海」，
而是：
在模型能力快速變動的前提下，
我們是否能先把 可長期使用的協作結構 固定下來。
這個 repo 現階段呈現的，
正是我在實戰中對「agent workflow 應該長什麼樣子」的當下答案。
作者：Keeponfirst