養豬場不靠大喊，Agentic Workflow 實踐指南

Agy 工作流架構（Agentic Workflow） 是指透過任務拆解（Task Decomposition）、系統指令邊界約束與強型別結構化輸出（Structured Output），將大語言模型（LLM）從單次對話問答升級為端到端自動化交付的工程方法。在「AI 都能自己寫 Code，工程師是不是乾脆去養豬？」的時代焦慮下，解答並非逃避，而是轉換為「產線架構師」思維：豬不是叫來就會自己長大的，AI 也是。只會丟 Prompt 如同隨手亂灑飼料，打造具備自動檢驗與反饋閉環的完整 Antigravity 工作流 才是現代工程師的核心競爭力。

「AI 都會自己寫 Code 了，我是不是乾脆去轉職養豬算了？」

這幾年看著大型語言模型從寫簡單函式一路進化到架構重構，許多工程師都曾半開玩笑地說出這句話。

但如果有一天，你真的跑去老家開了一座養豬場，滿懷期待地走進豬舍對著小豬大喊：「你！今天給我長胖 5 公斤！」——你猜小豬會有什麼反應？

小豬只會用無辜的大眼睛看著你，發出呼嚕聲，然後一動也不動。

現實就是這麼殘酷：豬不是叫來就會自己長大的，AI 也是。

很多人剛接觸 AI 輔助開發時，最常犯的直覺錯誤，就是以為只要對著對話框丟一句 Prompt，魔法就會自動發生。當產出的程式碼漏洞百出、被模型截斷時，又急忙複製錯誤訊息回去抗議。

這就像拿著飼料隨處亂撒的兼職飼育員。要讓系統真正穩定運作，我們必須以「智慧養豬場架構師」的思維，從單純餵食 Prompt，邁向建構全自動化的工程產線（Agentic Workflow）！

養豬與養 AI 的共通法則

如果你去參觀現代化的智慧養殖場，你會發現現場早已不是傳統的泥巴地與木製食槽，而是一整套高度自動化的精密設施。將這套思維對照到現代 AI 軟體工程，兩者具備驚人的映射關係：

flowchart TD
    A["飼料：輸入層 (Prompt / Clean Context)"] --> B["環境：執行規範 (System Instruction)"]
    B --> C["時間：推理迭代 (Iteration Lifecycle)"]
    C --> D["規則：輸出驗證 (Structured Output / Schema)"]
    D --> E["觀察：閉環監控 (Automated Testing & Logs)"]

1. 飼料（Prompt & Context）：高營養、剪枝後的無雜訊輸入。如果你給豬吃餿水，豬就會生病；如果你把整座專案沒整理的雜訊一次灌給模型，就會引發 Context Rot（上下文腐爛）與幻覺。
2. 時間（Iteration & Context Lifecycle）：給予 AI 處理邏輯、發起多輪工具呼叫與自我修正的推理生命週期。
3. 環境（System Instruction）：剛性的角色設定與全局邊界規範，如同豬舍的生物安全隔離牆。
4. 規則（Structured Output / Schema）：確保產出規格絕對固定、不野生氾濫的強型別通道。
5. 觀察（Monitoring & Feedback Loop）：自動化測試與 Log 監控機制，隨時掌握每批產出的健康狀態。

[!IMPORTANT]
Prompt 只是餵 AI 吃東西，Agentic Workflow 才是真正的養豬場。
只會寫 Prompt 的工程師就像拿著飼料隨便亂撒的飼育員；打造 Agentic Workflow 的工程師，才是建構全自動產線的系統架構師。

建立輸入與輸出的剛性控制台

要擺脫「對著 AI 祈禱」的徒勞模式，第一步是把輸入與輸出的控制權收回工程師手中。在現代 AI 開發架構中，這對應到三個核心技術元件：

1. System Instruction（環境與邊界設定）

設定 AI 的「剛性邊界」與「專業靈魂」。不要在每次發問時重複貼背景，而是直接在全域設定中定義：

• 角色權責：例如「只輸出符合 Web Standard 的 Web Component 前端架構師」。
• 負面約束 (Negative Constraints)：明訂絕不使用的全域 CSS 樣式、絕不引入特定肥大 Runtime。

2. 精準剪枝的 Context（高純度飼料）

給予剪枝後的必要資料，包含明確的 Data Contract（如清晰的 TypeScript Interface 或 JSON 結構）與具體 Task，避免龐大專案歷史雜訊稀釋模型的注意力。

3. Structured Output（自動計重通道）

透過 Agy 與 Gemini API 原生支援的 response_schema，強制要求 AI 必須回傳 JSON Schema 格式。這就像養豬場的「自動計重與消毒通道」，產出不符規格直接退件重來，絕對不讓未經驗證的字串流入既有程式碼庫中。

任務拆解樹：如何一個人管理 1,000 隻豬？

如果問一個現代智慧養豬戶：「你一個人要怎麼管理 1,000 隻豬？」
他絕對不會回答：「我就每天跑來跑去，一隻一隻手洗、一隻一隻拿飼料餵。」如果這樣幹，豬還沒長大，人就先累垮了。

真正能規模化管理上千隻豬的核心，在於極致的任務拆解 (Task Decomposition)：

flowchart LR
    Root["智慧養豬場運營系統"] --> F["餵食模組 (Feeding)"]
    Root --> E["環控模組 (Environment)"]
    Root --> H["健康監測 (Health)"]

    F --> F1["早餐高蛋白配方"]
    F --> F2["晚餐易消化飼料"]

    E --> E1["自動沖洗通道"]
    E --> E2["溫濕度感測調節"]

    H --> H1["視覺巡檢辨識"]
    H --> H2["異常即時通報"]

軟體工程最常見的災難，就是對 AI 拋出「1,000 隻豬的巨型模糊指令」：

1
2

❌ 錯誤示範：
「幫我寫一個完整的會員管理系統，要包含登入、註冊、權限控管、資料庫設計跟前端 UI，要能直接跑起來。」

面對這種指令，AI 往往產出寫到一半被截斷的程式碼、漏掉權限校驗，或寫出難以重構的數千行泥潭程式碼。

關鍵思辨：Structured Output vs. Markdown Plan

[!TIP]
在 Agentic Workflow 中，Structured Output 才是可被程式接管的核心驅動資料，Markdown Plan 只是給人類看的「施工藍圖展示版」。

實戰範例：以會員模組為例的 Task Schema

透過定義 Task Schema，我們能將巨型需求分解為可循序執行的單元：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

{
  "type": "OBJECT",
  "properties": {
    "feature_name": { "type": "STRING" },
    "subtasks": {
      "type": "ARRAY",
      "items": {
        "type": "OBJECT",
        "properties": {
          "step": { "type": "NUMBER" },
          "category": { "type": "STRING", "enum": ["DB", "API", "UI", "Test", "Deploy"] },
          "task_description": { "type": "STRING" },
          "expected_output": { "type": "STRING" }
        },
        "required": ["step", "category", "task_description", "expected_output"]
      }
    }
  }
}

當要求模型規劃會員系統時，配合上述約束，即可獲得可程式化處理的結構化產出：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

{
  "feature_name": "Member Authentication Pipeline",
  "subtasks": [
    {
      "step": 1,
      "category": "DB",
      "task_description": "定義使用者資料結構與安全雜湊欄位 (user_id, email, password_hash, role)",
      "expected_output": "Database Schema Definition"
    },
    {
      "step": 2,
      "category": "API",
      "task_description": "撰寫 POST /register 與 /login 的驗證處理邏輯與 JWT 簽發",
      "expected_output": "API Router 程式碼"
    },
    {
      "step": 3,
      "category": "UI",
      "task_description": "建立獨立的 <member-login-card> Web Component 並啟用 Shadow DOM",
      "expected_output": "Web Component 原始碼"
    },
    {
      "step": 4,
      "category": "Test",
      "task_description": "撰寫單元測試驗證表單驗證、錯誤狀態與 Token 儲存",
      "expected_output": "member-login-card.test.ts"
    },
    {
      "step": 5,
      "category": "Deploy",
      "task_description": "建立掛載測試範例並驗證端到端流程",
      "expected_output": "index.html 整合頁面"
    }
  ]
}

透過這種拆解，每個子任務只載入該步驟所需的資訊，避免 Token 爆滿，並讓工程師撰寫腳本走 subtasks.forEach() 驅動 Agy 一步一步執行，若 Step 4 測試失敗也只需精準重跑 Step 4，無須推翻整座豬舍。

常見問題 FAQ

Q1：Agentic Workflow 和普通 Prompt Engineering 有什麼本質差異？

Prompt Engineering 著重於如何精準措辭讓單次回應品質最佳，屬於「問一答一」的互動；Agentic Workflow 則強調建立工具呼叫循環、狀態機與驗證閘門，讓 AI 能夠在一套受控的軌道上自主完成多步驟任務並自動修正錯誤。兩者是「單次表演」與「自動化流水線」的根本差異。

Q2：Task Schema 該拆到多細才合適？

以「能否獨立撰寫單元測試」為邊界。若一個任務含「寫 DB + 刻 UI + 串接第三方金流」即過粗；拆成「定義 DB Schema」、「實作 API 端點」、「建立獨立 UI 元件」則是標準的 Agentic Workflow 交付顆粒度。

Q3：Structured Output 的 Schema 驗證失敗時如何處理？

建議建立工程重試閘門（Validation Gate）。若回傳內容無法通過 Schema 驗證，系統應自動將錯誤訊息作為 Feedback 回傳給模型要求重新格式化，避免髒資料污染下游產線。這是 Agy 與 Gemini API 搭配使用時的關鍵最佳實踐。

本日實作作業

拿出你的開發筆記，挑選一個目前正在進行的日常功能，運用本文的任務拆解邏輯（需求 ➔ 資料合約 ➔ API ➔ UI ➔ 測試 ➔ 部署），手動撰寫一份標準的 JSON 任務拆解清單。

在確立了 Agentic Workflow 觀念後，下一個震撼的真相是：養豬真正累的早就不是養本身，而是管理！
明天我們將請出 Google 的命令列神器 Agy CLI，並在專案中建立養豬場的最高管理憲法——AGENT.md！

系列導讀與延伸連結

• 上一篇：系列首篇
• 下一篇：Google Agy CLI 專案管理指南：建立 AGENT 憲法約束代理人架構邊界實踐
• 延伸閱讀：AI 時代前端架構的變革：從 Web Component 與原生 ESM 談程式碼泥潭實踐指南

• ← 上一篇
• 下一篇 →