從投幣販賣機到留白畫布：Agentic AI 如何重寫軟體開發的規則

站在自動販賣機前投幣、按下 A3，掉下來的一定是選中的那包洋芋片，一翻兩瞪眼。按鈕觸發事件監聽器，一段寫死的邏輯精準執行，結果乾淨利落。

這是軟體工程幾十年來的鐵律：明確的輸入，必然對應可預測的輸出。單元測試、系統架構，全都建立在這個假設之上。如果販賣機沒有吐出洋芋片，馬上就能知道是齒輪卡住了，還是程式裡有個沒接住的例外，一切可追蹤、可除錯。

但同一台販賣機正在突變。感測器看著眼前的人，開口說：「根據心率與昨晚的睡眠數據，現在處於高度疲勞狀態。已經改點了一杯無糖黑咖啡，錢用常用的 API 扣款完畢，順便把接下來的會議延後了十分鐘。」

這不是科幻片橋段，而是 Agentic AI 底層技術正在發生的鉅變。軟體環境正從一條寫死的鐵軌，變成一個充滿動態決策、有自主意識的狀態空間——這是軟體工程史上最大的一次典範轉移：從單純使用被動工具，走向與高度自主的數位實體協作。

一、代理的四個進化層級：從真空艙裡的大腦到虛擬公司

要理解這場轉移，得先弄清楚「代理（Agent）」到底是什麼。工程界把代理的複雜度劃分成四個層級，讀起來像自動駕駛的分級標準。

• 第 0 級是純粹的核心推理引擎，一顆被困在真空艙裡的聰明大腦。它具備強大的邏輯推理與文本生成能力，卻沒有手腳，沒有持久化記憶，也無法主動接觸環境，只能依賴訓練階段被餵進去的靜態資料。就像一位讀過萬卷書，卻被關在沒有窗戶也沒有網路線房間裡的學者：問它今天的股價，它給不出答案，只能產生幻覺，或是老實承認「作為一個 AI 模型，無法提供即時資訊」。
• 第 1 級是互聯問題解決者。這個孤立的大腦終於被賦予使用單一工具的許可權，也就是熟悉的函式呼叫（Function Calling）。這和傳統程式裡「如果使用者詢問天氣，就呼叫天氣 API」的寫死邏輯完全不同——在第 1 級的代理裡，開發者只是把「天氣 API」這個工具交給模型，模型必須自己意識到「目前缺乏最新資訊」，自己決定要不要呼叫、自己生成符合規格的 JSON 參數。這是一種主動的意圖判斷，而不是被動的規則分派。
• 第 2 級是策略問題解決者，也是目前業界最廣泛落地的階段。代理不再只會呼叫一次工具就結束，而是具備長期策略規劃、主動任務分解與自我完善的能力，其中最關鍵的技術特徵是情境工程（後面會細談）。以「安排一趟從台北到東京的商務旅行」為例：代理呼叫航班 API 拿到原始資料後，不會把整包 JSON 直接丟給下一個工具，而是先做「情境縮減」——分析出「下午三點抵達羽田機場」這個重點，把噪音全部過濾掉，再拿這個精簡結果去呼叫旅館搜尋工具。因為 LLM 的上下文視窗有限，如果每個 API 回傳的原始資料都塞進記憶體，模型很快就會認知過載，開始產生幻覺。

• 第 3 級是協同問題解決者，也就是多代理系統的興起。過去試圖用一個龐大到失控的超級提示詞，逼一個模型同時扮演所有角色，結果通常是「精神分裂」式的輸出。第 3 級直接翻轉了這個思維：與其讓單一 AI 同時當專案經理、UI 設計師與後端工程師，不如在系統裡實例化多個不同的代理，分別賦予不同的系統提示與工具許可權——這直接映射了人類企業組織的運作方式。

  層級	名稱	核心能力
  第 0 級	核心推理引擎	純 LLM，僅依賴預訓練靜態資料，沒有工具、沒有記憶
  第 1 級	互聯問題解決者	具備單一工具呼叫能力，主動判斷是否呼叫、自行生成參數
  第 2 級	策略問題解決者	具備情境工程與多步驟串聯能力，能做情境縮減與持續操作
  第 3 級	協同問題解決者	多代理協作，由不同角色的代理分工並透過結構化資料溝通

四個層級只是靜態分類，真正讓代理「動起來」的，是底層一套反覆執行的認知迴圈，這正是接下來要探討的部分。（關於這四個層級與其對應的中樞神經系統架構，可參考這裡-自主 AI 代理的進化之路：從架構設計、意圖分流到平行加速。）

二、代理大腦的五步迴圈

不管是第 2 級還是第 3 級，這些代理在底層都遵循一套五步迴圈，某種程度上很像軍事戰略裡的 OODA 循環。

獲得使命 → 掃描場景 → 徹底思考 → 採取行動 → 學習並優化
                ▲                              │
                └──────────────────────────────┘

• 第一步是獲得使命，代理拿到的是一個高階目標，例如「排查這個網頁為什麼載入這麼慢」，而不是「跑一遍 Lighthouse 效能測試」這種傳統指令。這是一個由目標驅動、而非指令驅動的系統。
• 第二步是掃描場景。代理開始收集情資：讀取 package.json 看用了哪些套件、檢查 Network 面板的請求瀑布圖，甚至掃描原始碼，建立當前環境的狀態快照。
• 第三步是徹底思考。這一步完全沒有做任何實質改動，純粹是內部推理——根據掃描到的情資，在潛在解決方案的空間裡搜索。它可能推論：「載入慢或許是圖片沒壓縮，也可能是某個大型第三方套件阻塞了渲染，應該先檢查打包後的體積。」這就是代理的內部獨白。
• 第四步是採取行動，真的去修改 webpack 設定檔、啟動程式碼分割。
• 第五步，也是讓它真正稱得上「智慧」的一步，是學習並優化。行動結束後，代理重新測量網頁載入時間；如果沒有縮短，反而因為設定錯誤導致畫面崩潰，它會把這個失敗路徑記錄下來，回到「思考」階段重新制定計畫。這是一個不斷收斂的優化過程，而不是一次性的執行。

// 五步迴圈的最小骨架
interface Loop {
  mission: string
  scan(): Promise<EnvironmentSnapshot>
  think(snapshot: EnvironmentSnapshot): Promise<Plan>
  act(plan: Plan): Promise<ActionResult>
  learn(result: ActionResult): Promise<'converged' | 'retry'>
}

async function runAgentLoop(loop: Loop): Promise<void> {
  let status: 'converged' | 'retry' = 'retry'
  while (status === 'retry') {
    const snapshot = await loop.scan()
    const plan = await loop.think(snapshot)
    const result = await loop.act(plan)
    status = await loop.learn(result) // 失敗就帶著錯誤紀錄回到 think
  }
}

三、鐵軌與畫布：失控的疑慮

如果把傳統軟體架構比喻成一列按表操課的火車，開發者就是鋪設鐵軌的人——火車只能在寫死的邏輯鐵軌上跑，一旦使用者的行為偏離軌道哪怕一公分，程式就會拋出例外，列車出軌崩潰。

Agentic AI 則像一位站在空白畫布前的藝術家。畫布不是視覺上的空白，而是底層的基礎設施——為代理準備好的 API 端點、資料庫連線。這位藝術家知道自己要畫一幅什麼樣的畫（高階目標），會根據當下的環境狀態、手邊的顏料（可用工具），自主決定下一筆畫在哪裡，這是一種前所未有的動態執行路徑。但曾經被無窮迴圈搞掛過伺服器的開發者聽了會毛骨悚然：如果代理理解錯了高階目標，會不會在基礎設施的畫布上亂塗一通？如果它陷入錯誤的推理迴圈，不斷呼叫付費的資料庫 API，甚至判斷「優化效能的最好方法是把整個資料表刪掉」，那就是一場真正的災難。

業界的答案不是把聰明的大腦丟到畫布上就撒手不管，而是發展出一套嚴謹的代理設計模式（Agentic Design Pattern）——就像給這位藝術家定下透視學法則和色彩理論，不再是隨機揮灑，而是有紀律的構圖藍圖。

四、馴服畫布的紀律：提示鏈、情境工程與動態路由

提示鏈：分而治之的流水線

很多剛接觸 AI 開發的人最愛做的事，是寫一個長達幾千字的超級提示詞——把背景知識、任務步驟、輸出格式全部塞進去，一次丟給模型，祈禱它給出完美答案。這種作法在代理系統裡走不通，因為它違背了 LLM 的注意力機制：即使上下文視窗動輒幾十萬 token，模型的認知負荷仍然有限。把一個多面向、多步驟的複雜任務塞進單一提示詞，常見的失敗模式有三種：指令遺漏（完美執行了 80% 的任務，卻忽略最後的格式要求）、情境漂移（在長篇生成過程中逐漸偏離最初設定的角色）、以及最糟糕的幻覺（因認知過載而胡亂填補邏輯空白）。

提示鏈（Prompt Chaining）採取的是經典的分而治之策略：把龐大任務拆成一系列獨立、高度聚焦的節點，每個節點只做一次 LLM 呼叫。以「抓取昨天的錯誤日誌 → 分析出三個崩潰主因 → 用特定語氣寫成 Slack 通知」這個任務為例，拆成三個節點後，第一個節點的提示可能只是「篩掉所有非 ERROR 等級的日誌」——這一步模型的唯一關注點就是過濾，完全不知道後面還要寫報告、發 Slack，準確率因此逼近百分之百。

節點之間的資料傳遞，絕對不能依賴模糊的自然語言，而必須是嚴格定義的 JSON Schema。如果模型輸出不合法或漏了某個欄位，框架的驗證工具會直接攔截，把錯誤訊息重新丟回去要求重寫，直到格式正確才傳給下一個節點。每個提示節點就像一個獨立的微服務，透過標準化的 JSON API 彼此通訊，這徹底消除了自然語言的模糊性，把 AI 從聊天機器人變成可靠的工業級運算元件。

// 提示鏈：每個節點只做一件事，輸出必須通過 Schema 驗證才能進入下一節點
interface LogEntry { level: 'INFO' | 'WARN' | 'ERROR'; message: string }
interface RootCause { code: string; description: string }

async function filterErrors(raw: LogEntry[]): Promise<LogEntry[]> {
  return raw.filter((l) => l.level === 'ERROR') // 節點一：只做過濾
}

async function analyzeRootCauses(errors: LogEntry[]): Promise<RootCause[]> {
  const result = await callLLM('請找出前三個核心崩潰原因', errors)
  return validateSchema<RootCause[]>(result) // 驗證失敗就丟回模型重寫
}

async function draftSlackMessage(causes: RootCause[]): Promise<string> {
  return callLLM('用工程師文化的簡短語氣寫成 Slack 通知', causes)
}

情境工程：決定輸出品質的不是模型，是餵給它的東西

過去總覺得如果 AI 回答得笨，是模型不夠強，換上最新一代旗艦模型答案就會自動變好。情境工程（Context Engineering）指出，問題往往出在沒有給它的東西上。把 LLM 當成一位剛空降到公司的資深架構師，即使技術再強，沒看過架構圖、不了解歷史包袱，給出的建議也注定是災難。

情境工程通常包含三個層次：第一層是基礎的系統提示，定義代理行為的參數與限制；第二層是外部知識的動態注入，包含透過 RAG 從內部文件撈取的設計規範，或即時呼叫 API 取得的當前環境狀態；第三層，也是最考驗系統設計功力的，是隱含資料與狀態追蹤——一個優秀的代理在回答問題時，情境視窗裡已經包含使用者的歷史偏好、過去幾次失敗的錯誤，甚至滑鼠當下停留在哪一行程式碼。

當有人問代理「這段程式碼為什麼會報錯」，它背後其實已經抓取了最近修改的三個檔案、去錯誤追蹤系統撈出相似的 log，把它們打包成一個超級情境再丟給模型——這就是現在的 AI 寫程式工具愈來愈神準的原因。

情境工程三層架構
┌─────────────────────────────────────┐
│ 第一層 系統提示：行為參數與限制         │
├─────────────────────────────────────┤
│ 第二層 外部知識：RAG 文件 + 即時 API   │
├─────────────────────────────────────┤
│ 第三層 隱含狀態：歷史偏好 + 失敗紀錄     │
│         + 當前游標位置                │
└─────────────────────────────────────┘

動態路由與推理技巧：總機中心與內部獨白

如果提示鏈是一條直線的生產線，動態路由（Routing）就是一個有無數分岔路口的總機中心。代理不再只有一條死板的直行路徑，而是能根據對使用者意圖的語義理解進行分流：全能客服代理收到「包裹在哪裡」，會被路由到物流查詢工具；收到「退款政策是什麼」，會被路由到檢索內部文件的 RAG 子系統；遇到情緒性的謾罵、意圖不明時，則會導向一條特殊的安撫與澄清提示鏈。這讓系統的擴充性變得極高，未來新增一個功能，只要在路由器上加一個新分支即可，完全不用動到既有的穩定架構。

type Intent = 'logistics' | 'refund_policy' | 'de_escalation'

function classifyIntent(input: string): Intent {
  if (/包裹|物流|配送/.test(input)) return 'logistics'
  if (/退款|退貨政策/.test(input)) return 'refund_policy'
  return 'de_escalation' // 意圖不明，先安撫再澄清
}

const pipelines: Record<Intent, (input: string) => Promise<string>> = {
  logistics: queryLogisticsApi,
  refund_policy: retrieveFromRag,
  de_escalation: runCalmDownChain,
}

但有些問題不是路由到一個資料庫就能解決的，例如一個極度詭異的記憶體洩漏，需要一連串假設與驗證。這時就需要思維鏈（Chain of Thought, CoT）——強迫模型在給出最終答案前，把中間推理過程一步一步寫出來，就像小學數學老師要求寫出計算過程、不能只寫答案。因為模型是依序生成 token 的，前面生成的推理過程，會成為後面生成最終答案時的上下文；進階一點的思維樹（Tree of Thoughts），則允許代理同時探索多種解法路徑，像下棋一樣評估哪條路徑勝率最高，發現走進死胡同還能回溯。

而目前代理框架中最核心、最迷人的推理模式，是 ReAct（Reasoning and Acting），把思維與行動交織成一個緊密的「思考、行動、觀察」迴圈。以排查伺服器記憶體洩漏為例：先進入思考，「CPU 持續飆高，猜測是資料庫連線池沒有正確釋放」；接著行動，呼叫終端機 API 執行指令檢視連線數；然後觀察，發現連線數其實正常；基於這個觀察，啟動下一輪思考，「既然連線池沒問題，那可能是某個全域變數在快取中不斷膨脹，應該拉取記憶體快照」，再次行動、再次觀察。

這完全就是一位資深工程師除錯時的內部獨白被具象化了，而且因為每一輪的思考、行動、觀察都被記錄下來，整個決策過程對開發者來說完全透明、可追蹤、可稽核，解決了最擔心的黑盒子問題。（提示鏈、情境工程、思維鏈與 ReAct 的完整技術脈絡，可參考這裡-從對話到代理：自主 AI 代理的進階提示工程，以及可參考這裡-讓 AI 代理學會深思熟慮：推理技巧。）

五、從被動資料到主動探索：代理式 RAG 與自我進化

代理的推理能力再強，還是需要獲取知識，而真實世界的知識每一秒都在改變。標準 RAG 本質上是一個被動且盲目的資料管道，檢索邏輯建立在字面或語義相似度上，只看「字面像不像」。問「比較去年和今年第一季的 API 定價策略差異」，標準 RAG 可能把所有包含「定價」關鍵字的碎片檔案全部撈出來，毫無邏輯地塞給模型；如果撈出來的資料裡剛好有一份已作廢的草稿，模型無法分辨，只會把互相矛盾的資訊融合成一個極度自信的錯誤答案。它就像一個沒有判斷力的圖書館實習生，只會根據關鍵字把一堆書砸在桌上。

代理式 RAG（Agentic RAG）在單純的檢索管道之上，覆蓋了一層推理與規劃層。面對同一個比較問題，它不會立刻搜尋，而是先思考：「這個問題需要兩部分資訊，必須先找到去年的最終定價版，再找今年的最終版」，主動把一個大查詢拆成多個平行子查詢。更強大的是，面對檢索回來互相矛盾的資訊，它擁有評估來源、自我修正的能力——「這份檔案雖然提到新定價，但標記為草稿；另一份標記為核准，應該忽略前者」。如果內部資料庫根本找不到答案，它甚至會動態改變策略，主動使用即時網路搜尋 API，把外部最新資訊和內部歷史資料綜合起來回答。（關於代理式 RAG 的完整技術探討，可參考這裡-RAG：讓 AI 從閉卷考變開卷考。）

async function agenticRagQuery(question: string): Promise<string> {
  const subQueries = await decompose(question) // 拆成可平行執行的子查詢
  const hits = await Promise.all(subQueries.map(retrieve))
  const trusted = hits.flat().filter((doc) => doc.status === 'approved') // 過濾掉草稿
  if (trusted.length === 0) return await fallbackToWebSearch(question) // 內部沒有就外查
  return synthesize(trusted)
}

比檢索更近一步的，是兩個會主動修改自己程式碼的代理：SICA（Self-Improving Coding Agent）與 Google 的 AlphaEvolve。傳統上，一段程式碼編譯部署後就是靜態的，除非工程師發布新版本，否則永遠不會改變。但 SICA 不僅能寫程式碼，還具備監控自身執行效能、動態重構自己演算法的能力——系統裡有一個由強大 LLM 扮演的監督者角色，持續監控主代理的執行日誌與效能指標；一旦發現某個任務每次都耗時過長，監督者會介入、暫停任務，拉出主代理目前的原始碼，判斷「排序演算法時間複雜度過高，應該改寫成更高效的版本」，接著代理自己修改程式碼、自動產生對應的單元測試、確認沒問題後熱更新自己的執行環境。AlphaEvolve 的野心更大，它結合大型語言模型與演化演算法，針對一個未知的複雜問題自動產生無數種假設解決策略，像基因突變一樣在沙盒環境中不斷迭代測試、交配、篩選——不是在既有知識裡打轉，而是透過大規模試錯推進演算法的邊界。（關於 SICA 與 AlphaEvolve 的完整運作機制與雙層防禦設計，可參考這裡-會自己改程式的 AI：學習與適應。）

如果把這種持續適應的能力植入到管理使用者與 App 互動的代理裡，它會持續在背景觀察滑鼠軌跡與點擊行為。如果發現某個使用者每次開啟電商 App，都只是為了去某個很深的隱藏選單重複購買同一款咖啡豆，它可能會判斷「這個對所有人都長得一樣的靜態 UI，效率太低」，於是動態修改介面——下次開啟 App，首頁最顯眼的位置會直接渲染出專屬的「一鍵回購」按鈕，而從沒點過的促銷橫幅則被摺疊起來。介面不再是設計師在 Figma 裡畫好、工程師寫死的靜態版面，而是變成一種即時運算、即時生長的有機體，這直接引爆了下一段要探討的介面革命。

六、AI 推開人類的正門：ACI 的崛起

過去認知裡的 AI，要嘛活在聊天視窗裡，要嘛躲在後端，透過開發者辛苦串好的 API 與其他系統溝通，這其實非常死板。如果一個老舊的航空訂票網站沒有提供 API，自動化就完全束手無策。API 是機器與機器的暗門，GUI 則是人類專屬的大門。過去 AI 找不到暗門就進不去，現在 Agent Computer Interface（ACI） 賦予了 AI 直接推開大門的能力——它讓 AI 發展出了看懂並操作圖形使用者介面的技術，像人類一樣盯著螢幕，操作滑鼠與鍵盤。

這套技術堆疊拆成四個階段：

① 視覺感知        ② GUI 元素辨識      ③ 情境解釋        ④ 動態操作與回應
擷取畫面／DOM  →  像素/DOM → 可互動  →  視覺證據 + 高階  →  轉譯成滑鼠鍵盤指令
                   地圖（打上編號）      任務目標結合          並持續監控回饋

• 第一階段是視覺感知，代理的眼睛，以固定頻率擷取當下螢幕或瀏覽器視窗的視覺狀態，可以是單純截圖，也可以是網頁的 DOM 結構。
• 第二階段是 GUI 元素辨識，這是極度關鍵的一步：對人類來說一眼就能看出哪裡是按鈕，但對 AI 來說，一張截圖只是一堆像素矩陣，必須透過電腦視覺模型把像素解釋成具有互動功能的結構化佈局，精準計算座標、區分出「這是一個可點擊的綠色按鈕」、過濾掉純裝飾用的背景圖片；如果是直接解析 DOM，代理會過濾掉所有不可見元素，為每一個可互動元素打上獨一無二的編號，把複雜網頁簡化成一張可互動地圖。
• 第三階段是情境解釋，光知道那裡有個按鈕還不夠，ACI 模組必須知道畫面右上角那個圓圈加短線的圖示代表放大鏡，也就是搜尋功能，讓模型能把視覺證據和高階任務目標結合，看懂介面的語義。
• 第四階段是動態操作與回應，一旦模型決定要點擊某個按鈕，ACI 就把這個高階決策轉譯成具體的機器指令，以程式控制滑鼠移動、點擊、在輸入框打字；最困難的部分在於，網路環境是動態的，點擊後可能突然彈出廣告、出現載入圈圈或密碼錯誤提示，代理必須像人類一樣持續監控畫面回饋，對突發狀況做出即時的重新推理。

// ACI 第二階段：把 DOM 簡化成一張帶編號的可互動地圖
interface InteractiveElement { id: number; role: string; label: string; rect: DOMRect }

function buildInteractiveMap(root: Element): InteractiveElement[] {
  const nodes = [...root.querySelectorAll<HTMLElement>('button, a, input, [role]')]
  return nodes
    .filter((el) => el.offsetParent !== null) // 過濾掉不可見元素
    .map((el, i) => ({
      id: i,
      role: el.getAttribute('role') ?? el.tagName.toLowerCase(),
      label: el.getAttribute('aria-label') ?? el.textContent?.trim() ?? '',
      rect: el.getBoundingClientRect(),
    }))
}

這已經不是理論，OpenAI 研發的 Operator 能開啟 Excel、複製資料、切換到瀏覽器登入公司的 CRM 系統一筆一筆貼上；Google 的 Project Mariner 是一個執行在 Chrome 瀏覽器裡的智慧代理，只要告知預算，它就會自己開啟各大房地產網站、識別篩選器、輸入預算區間、逐頁瀏覽搜尋結果，把重點資料整理成一份乾淨的檔案；Anthropic 的 Computer Use 功能讓 Claude 能直接接管滑鼠鍵盤；開源社群裡的 browser-use 專案則更進一步，直接賦予 AI 操作網頁底層 DOM 結構的能力，AI 不再只是看截圖，而是鑽進網頁的骨架裡解釋結構。（關於 ACI 的完整技術棧、與 API 自動化的取捨、以及原生多模態如何理解真實世界，可參考這裡-AI 代理長出雙手：從操作 GUI 到觸碰真實世界的互動設計。）

七、當 AI 成為網頁的主要使用者：AEO 與介面的重生

這裡要丟出一個可能讓不少設計師睡不著覺的反思。UI/UX 設計師與前端開發者過去十幾年學的色彩心理學、視覺動線、留白藝術，全都是為了讓人類的眼睛覺得好用、降低人類的認知負擔。但如果未來訂機票、報稅的全都是專屬的 AI 代理，介面設計的重點，難道要轉成讓 AI 的眼睛也覺得好用嗎？

邏輯上，未來的介面設計重點，將從單純透過視覺引導人類，轉向輔助代理讀取與意圖預測。對於一個純粹由代理操作的任務，漂亮的漸層色與圓角邊框對 AI 毫無意義，代理擅長且依賴的，是結構化與語義化的資料。因此，網頁的語義化標籤（Semantic HTML）與無障礙設計（ARIA）屬性，將會變得前所未有的重要。這些隱藏在視覺背後的 ARIA 標籤、role 屬性，就是代理理解網頁結構的路標。

問題點：一個常見的慘痛反模式

很多新手習慣用一個單純的 <div> 標籤，配上 CSS 把外觀畫得很像按鈕，再加上點擊事件。在人類眼裡，它就是個按鈕；但在依賴 DOM 解釋的代理眼裡，這只是一個毫無意義的區塊，根本不知道這東西可以點。如果一個網站充斥著這種缺乏語義、對代理不友善的程式碼，代理在執行任務時就會卡關，甚至直接放棄、轉去競爭對手的網站完成購買。一個網站如果不具備「代理友善性（Agent-friendly）」，代理就不會替它的主人在這個網站上消費，這直接關係到商業轉換率。過去要做 SEO（搜尋引擎優化），未來要做的是 AEO（Agent Engine Optimization，代理引擎優化）。這代表開發的重心，將從表象回歸到結構。

前端解法：語義化標籤取代裝飾性 div

// 反模式：AI 完全看不出這是可點擊的按鈕
// <div class="btn-primary" onClick={buy}>立即購買</div>

// AEO 友善寫法：語義標籤 + ARIA，讓代理與人類都能正確解讀
function BuyButton({ onBuy, disabled }: { onBuy: () => void; disabled: boolean }) {
  return (
    <button
      type="button"
      aria-label="立即購買這項商品"
      aria-disabled={disabled}
      onClick={onBuy}
    >
      立即購買
    </button>
  )
}

後端解法：為結構化查詢多開一條代理專用端點

除了前端標籤，後端也需要為代理準備結構化資料出口，而不是只靠代理反向解析人類用的 HTML：

// 面向人類：回傳排版好的 HTML 頁面
app.get('/product/:id', renderHtmlPage)

// 面向代理：回傳結構化 JSON，省去 DOM 解析與誤判的風險
app.get('/api/agent/product/:id', async (req, res) => {
  const product = await getProduct(req.params.id)
  res.json({
    name: product.name,
    price: product.price,
    inStock: product.stock > 0,
    actions: [{ id: 'buy', method: 'POST', endpoint: `/api/agent/order/${product.id}` }],
  })
})

此外，當代理成為大量非結構化網路資料的中介，這些資料會在背景被自動轉換為結構化格式，未來的 UI 可能不再是設計師預先畫好的一個個固定頁面，而會變得高度原子化：提出一個需求後，代理在背景穿梭於各個網站和服務之間，根據萃取出來的資料結合當下情境，即時渲染出最適合的資訊卡片。

傳統固定頁面                        原子化即時渲染
┌───────────────────┐             ┌───────────────────┐
│  導覽列  廣告橫幅    │             │  依當下情境即時組裝：  │
│  ┌───┬───┬───┐    │   ──►       │  ┌─────┐┌─────┐   │
│  │卡片│卡片│卡片│    │             │  │航班卡│依需求 │  │
│  └───┴───┴───┘    │             │  └─────┘└─────┘   │
│  側邊欄  頁尾        │             │  只呈現任務相關資訊    │
└───────────────────┘             └───────────────────┘

傳統那種塞滿廣告欄、側邊欄的龐大網頁，可能會逐漸被這種隨需生成的微介面取代。介面不再是靜態版面，而是一種會即時運算、即時生長的有機體。

八、Vibe Coding 與虛擬軟體公司

矽谷最近很熱門的一個詞是 Vibe Coding（氛圍寫碼），聽起來很不嚴謹，像是憑感覺亂敲鍵盤，但核心精神其實是為了解決一個古老的問題：打破空白頁的恐懼，極大提升開發初期的迭代速度。在 Vibe Coding 的理念裡，不再逐行輸入語法，而是透過自然語言描述高階意圖與「想要的感覺」，模型瞬間生成初始草稿或可運作的快速原型。

但這聽起來就像一張通往義大利麵條式程式碼的單程車票：如果只是憑感覺讓 AI 產生程式碼，可能充滿潛在的安全漏洞、效能瓶頸，而且難以維護，誰來對這坨程式碼的品質負責？業界解決這個疑慮的作法，不是要求人類工程師回去逐行檢查，而是讓 AI 從單純的程式碼產生器，進化成具備審查與糾錯能力的數位團隊成員，這正是第 3 級「協同問題解決者」的落地實踐。

一個著名的開源框架 MetaGPT，直接給出一個完整的虛擬軟體公司：輸入一段自然語言需求後，先上場的是扮演產品經理的代理，分析需求並輸出結構化的規格書；規格書透過 JSON 傳給程式設計師代理撰寫具體的程式碼模組；測試員代理則同步寫出單元測試腳本，一旦程式碼寫完就自動丟進測試環境跑，如果測試失敗，測試員代理會抓取錯誤日誌，給出一份嚴厲的修訂建議，把程式碼退回要求重寫。整個過程完全由多個 AI 代理透過標準化資料格式互相溝通、辯論與除錯。

const virtualCompany = {
  pm:      '分析需求，輸出結構化規格書（JSON）',
  coder:   '依規格書撰寫程式碼模組，不負責測試與優化',
  tester:  '撰寫涵蓋邊緣情況的單元測試，測試失敗就退件並附修訂建議',
} as const

async function shipFeature(requirement: string) {
  const spec = await run(virtualCompany.pm, requirement)
  let code = await run(virtualCompany.coder, spec)
  let report = await runTests(code)
  while (!report.passed) {
    code = await run(virtualCompany.coder, { spec, feedback: report.errors })
    report = await runTests(code)
  }
  return code
}

這聽起來像是把 PM、工程師、QA 的工作一條龍全包了，連除錯都自己來，但這是對技術演進的誤解。技術抽象層的每一次提升，從來不會消滅工程師，而是改變工程師的工作內容。在代理時代，工程師不是被取代，而是被晉升：從寫程式碼的勞工晉升為創意領導者與架構師。代理是非常優秀的戰術執行者，但沒有商業直覺、不理解公司政治環境，也無法承擔最終的法律與商業責任。人類架構師最重要的職責，是為這些代理提供完美的簡報與邊界設定，完整的程式碼庫上下文、精確的 API 與資料庫結構定義、嚴格的安全與風格指南，以及最核心的、高階的業務目標與成功標準。人類負責定義「為什麼」與「做什麼」，把「怎麼寫出這段程式碼」的戰術勞動交給代理團隊，再對最終結果進行高階的架構審查與驗收。（這套「以人為主導的編排」如何具體落地成本機上下文編排器、版本控制的提示庫與 Git Hooks 審查迴圈，可參考這裡-從寫程式機器進化為 AI 代理架構師：帶領專業代理團隊的三大原則。）

九、控制資源與風險：省錢的代理，安全的代理

擁有一支強大的 AI 開發團隊，甚至擁有能自主操作外部電腦系統的代理，一個攸關公司存亡的現實問題隨之浮現：代理每一次啟動思考迴圈、每次呼叫模型產生 token，都在燃燒運算資源，說白了就是在燒錢，更別提代理失控做出錯誤決策造成的損失。

成熟的代理設計模式必然包含資源感知最佳化：現代代理系統不僅要決定得聰明，還必須具備財務意識。最常見的作法是動態模型切換——系統不會盲目地把所有任務都交給最昂貴的旗艦模型；面對簡單的日常查詢，路由代理會自動選用輕量、便宜、延遲低的小型模型處理，只有遇到需要複雜多步驟推理的任務，才會申請高額預算呼叫強大的主模型。在資料處理上，則涉及情境修剪，輸入給模型的 token 愈多成本愈高，代理會主動且定期地對自己的短期記憶進行摘要與壓縮，剔除已經不相關的歷史對話，直接且大幅降低每次呼叫的成本。（關於資源感知最佳化的完整設計模式，可參考這裡-讓 AI 代理聰明更要精明：資源感知最佳化。）

function pickModel(taskComplexity: 'simple' | 'complex'): string {
  return taskComplexity === 'simple' ? 'gemini-flash-lite' : 'claude-opus'
}

function pruneContext(history: Message[], maxTokens: number): Message[] {
  const recent = history.slice(-6) // 只保留最近幾輪對話
  return recent.length * AVG_TOKENS_PER_MSG > maxTokens ? summarize(recent) : recent
}

成本控制解決了「錢」的問題，但更根本的是安全控制。如果代理正在執行高風險任務，例如操作真實世界的金融交易 API，該如何確保它不會在轉換角色中犯下致命的災難？這時候就必須引入一個不可或缺的模式：人類在迴圈中（Human-in-the-Loop, HITL），並在關鍵節點建立嚴格的安全護欄。在複雜或高風險的決策點，系統必須被設定明確的升級策略，代理必須知道自己的能力邊界，知道什麼時候該舉手求救，主動把控制權交還給人類。

以一個自動處理退貨退款的客服代理為例，平時可以自主處理一百美金以下的退款，這就是它的安全護欄；但如果遇到極度憤怒的顧客，或退款金額高達一萬美金，這個請求就會觸發升級策略，代理立刻暫停自主行動，把完整對話脈絡打包好轉交給人類主管處理。

interface RefundRequest { amount: number; sentiment: 'neutral' | 'angry' }

function decideRefund(req: RefundRequest, humanReview: (r: RefundRequest) => void) {
  const withinGuardrail = req.amount <= 100 && req.sentiment !== 'angry'
  if (withinGuardrail) return autoApprove(req)
  return humanReview(req) // 觸發升級策略，交還控制權
}

HITL 的價值不只在於安全，人類主管接手處理並做出最終決策後，這個介入的過程與結果，會成為代理持續學習與校準的最寶貴對齊資料來源。（關於 HITL 的完整架構設計與人類作為最終仲裁者的角色，可參考這裡-AI 為什麼需要人類救場：Human-in-the-Loop 架構探討。）

十、顛覆認知：未來的五個假設

站在學術與產業最前沿的專家對 Agentic AI 未來幾年的發展軌跡，提出了五個大膽、甚至有點科幻的假設：通才代理與小型專業模型深度結合，由主控制節點動態組合無數個專注特定任務的小型模型協同完成任務；深度個人化與主動的目標發現，代理不再被動聽命，而是透過觀察日常行為模式，主動預測並提議還沒明確表達出來的需求；具身化，把代理的認知架構與實體機器人結合，讓虛擬的智慧終於擁有改變物理現實的力量；代理驅動的超高效經濟，代理成為獨立的經濟參與者與交易主體，創造出人類大腦根本無法以手動速度跟上的代理經濟；以及目標驅動的變形多代理系統，系統架構不再由人類預先寫死，而是根據唯一目標動態建立、複製或銷毀子代理。這五個假設的完整推演與帶來的變革，可參考這裡-自主 AI 代理的進化之路。

結語：畫布還需要框嗎？

這趟旅程，從解決模型注意力崩潰的提示鏈，一路走到能改變全球經濟運作方式的變形代理系統，核心只有一件事：軟體工程正式從單純依賴 LLM 生成文字的靜態問答，走向能自主思考、規劃並在環境中行動的代理系統。要讓這些強大的代理在生產環境穩定、安全地運作，不能只靠換一個更大的模型，而需要嚴謹的代理設計模式——提示鏈、情境工程、路由與推理、代理式 RAG 與適應能力，這些正是支撐未來 AI 軟體供應的底層基礎設施。而在應用與介面層面，這股代理浪潮正以前所未有的破壞力，衝擊前端開發與 UI/UX 設計的本質：ACI 讓 AI 能直接看懂 DOM 結構並操作圖形介面，徹底打破 API 的藩籬；多代理協作架構正在重塑開發團隊的樣貌，把人類工程師推向創意架構師的角色。

回到開頭的比喻：如果未來專屬的 AI 代理，可以透過解析底層 DOM 結構，或透過 ACI 的視覺辨識與語義理解，在背景默默完成訂機票、比價網購、填寫複雜報稅表單的所有繁瑣流程，那麼真的還需要傳統那種充滿華麗視覺設計、複雜導覽動線的網頁介面嗎？當購物代理可以直接和電商網站的銷售代理，透過標準化的 JSON API 或某種高速資料端點在幾毫秒內互相對話、談判並完成交易，這塊精心雕琢了幾十年的畫布，也就是圖形使用者介面，會不會就此萎縮，甚至對人類的眼睛隱形，只剩下無數代理在虛空中以接近光速交換的資料暗流？

答案很可能不是「消失」，而是改變形式，從畫素轉變為語義標籤。但人類創作價值、定義目標的需求永遠都在。身為這個時代的開發者或設計師，真正該問的問題不是「AI 會不會取代人類」，而是「下一步該如何佈局，產品又該如何被代理看見」。

參考資料

• 自主 AI 代理的進化之路：從架構設計、意圖分流到平行加速
• 會自己改程式的 AI：學習與適應
• RAG：讓 AI 從閉卷考變開卷考
• 讓 AI 代理聰明更要精明：資源感知最佳化
• 讓 AI 代理學會深思熟慮：推理技巧
• AI 為什麼需要人類救場：Human-in-the-Loop 架構探討
• 從對話到代理：自主 AI 代理的進階提示工程
• AI 代理長出雙手：從操作 GUI 到觸碰真實世界的互動設計
• 從寫程式機器進化為 AI 代理架構師：帶領專業代理團隊的三大原則
• 從紙上談兵到穩健上線：自主 AI 代理的架構與應用