近期我在開發生成式照護機器人的過程中，「Agentic AI」這個詞開始頻繁出現在各需求單位的討論。只是談得越多，我反而越擔心，因為不同角色對它的期待落差很大。有人希望它能自動做出決策，有人則只是把它視為更聰明的助理工具。如果只是停留在名詞層次，很難判斷這樣的技術究竟適不適合真正進入產品開發流程，更遑論落地在高度受限的醫療場域。

在我的理解中，所謂的 Agentic AI 並不是指某一個特定模型或新名詞，而是一種工作方式的轉變。它不再只是被動回應指令，而是在給定目標與限制條件後，能自行規劃行動、拆解任務，並在執行過程中不斷修正路徑。這類系統通常具備狀態感知、任務規劃，與自我修正的能力，能長時間維持上下文，而不是每一次都從零開始產生答案。也正因為這樣，它的表現高度依賴使用者所提供的背景資訊與邊界設定，一旦脈絡不清，就很容易過度延伸，甚至產生錯誤的行為。

基於這樣的特性，我覺得光靠聽別人的經驗分享，或是網路上的文章跟影片，無法真正理解 Agentic AI 的能跟不能。於是我選擇從自己最熟悉、但早被時間跟忙碌給擱置的舊專案下手，透過實際操作來觀察，當 AI 被賦予更多主動權後，整個開發流程會發生什麼樣的改變，又在哪些地方仍然必須由人工來介入跟收斂。

我刻意挑選了兩種性質不同的專案來做實驗。一個是十三年前我用 Objective-C 開發，後來在十年前因平台政策變更而下架的攝影教學 App；另一個則是我個人網站中，之前仰賴 Flash 呈現，目前已經無法正常運作的後台數據統計功能。這些專案都有完整的歷史脈絡，也存在明確的功能目標，非常適合用來實作跟觀察 Agentic AI 在實際工程情境中的行為。整個過程中，我並沒有親自動手改寫程式碼，而是嘗試把規劃、實作，與修正都交給 AI，我退到測試跟判斷的角色。這樣的嘗試，讓我對於人與 AI 的分工有了更具體的理解，也成為這篇文章整理與分享的起點。

在實作部分，我並沒有一開始就把指令丟給執行環境，而是刻意把「思考」與「執行」拆成兩個階段。我先在 Gemini 中說明專案背景、改寫目標與限制條件，讓模型協助我調整提示詞的結構，直到我確認這段描述已經足夠清楚，才將它轉貼到 Antigravity，作為正式的執行指令。這樣的流程，看似多了一道工，實際上卻能有效降低後續修正成本，避免 AI 在一開始就走偏方向。