AI 代理的規劃能力：從被動反應到主動佈局

從自動販賣機到 AI 代理：一場互動典範的轉移

在使用傳統的自動販賣機的情境裡，投幣、按下 A1 的按鈕，機器發出運轉聲，咚一聲掉出指定的可樂。一切都是寫死在程式裡的——輸入什麼就輸出什麼，高度線性的關係，讓人充滿安全感，因為所有的執行路徑都在人類的預料之中。但如果把這台販賣機升級成現代人工智慧代理（AI Agent），情況就完全不一樣了。我們不再去按 A1 按鈕，而是走過去對機器說：「今天下午我連開了三個會，現在頭有點痛，而且等一下還要向老闆簡報，我需要提神。」這時代理不會呆呆地等待我們選擇飲料。它會自己去檢查庫存，發現原本提神的抹茶賣完了。於是在極短的時間內，它自己做決定——把氣泡水、冷壓薑汁加一點濃縮咖啡混合在一起，當場為我們特調出一杯能醒腦又不會太甜的飲料。

這就是代理具備規劃能力（Planning） 的展現。AI 正在從一個只會被動反應的機器，進化到像資深專案經理一樣，具備主動佈局與動態調整策略的能力。

規劃的本質：從 How 到 What

要理解規劃能力，必須先釐清一個核心轉變：從告訴機器如何做（How），轉變為告訴機器要做什麼（What）。

傳統程式設計必須明確寫出每一步：第一步開啟檔案、第二步讀取資料庫……如果中間遇到檔案損毀，程式就直接崩潰。但規劃模式的核心是：系統能將我們給的高階模糊目標，自主拆解成一系列可執行的子目標。就像汽車導航一樣，自己算出一條從現在走到目標的最佳路徑。

企業異地會議的範例

以籌備公司異地會議為例——這通常是專案經理的噩夢，牽涉到場地、餐飲、交通，甚至每個人的行程衝突。如果是傳統的自動化軟體，我們必須自己設定好每一個判斷條件。但面對有規劃能力的代理，我們只需要給目標和限制：「預算十萬、三十個人參加、下個月五號。」

剩下的交給 AI 去煩惱。它會自己上網找場地、找外匯。最關鍵的是它的適應性：假設首選飯店被訂滿了，或是挑好的餐廳當天公休，它不會像傳統程式那樣彈出錯誤視窗就罷工。它會意識到這條路不通，然後主動重新評估限制，去找符合預算的替代地點。

情境：籌備異地會議（預算十萬、三十人、下個月五號）

        使用者給目標
             │
             ▼
    ┌─────────────────┐
    │ 搜尋符合場地      │──── 找到君悅酒店
    └────────┬────────┘
             │ 被訂滿了！
             ▼
    ┌─────────────────┐
    │ 記錄新限制        │
    │（君悅不可用）      │
    └────────┬────────┘
             │
             ▼
    ┌─────────────────┐
    │ 重新搜尋替代方案   │──── 找到晶華酒店（預算內 ✅）
    └────────┬────────┘
             │
             ▼
    ┌─────────────────┐
    │ 搜尋鄰近餐廳      │──── 首選餐廳公休 😱
    └────────┬────────┘
             │
             ▼
    ┌─────────────────┐
    │ 重新評估          │
    │ 改訂第二順位餐廳   │──── 完成 ✅
    └─────────────────┘

    傳統程式：第一步失敗 → 直接當機
    AI 代理：第一步失敗 → 記錄限制 → 重找替代

規劃模式概述

在人工智慧的背景下，規劃代理就像是我們委託複雜目標的專家。當你要求它「在異地組織一個團隊活動」時，你定義的是 What（目標與限制），而不是 How（如何執行）。代理的核心任務是自主制定實現該目標的路線。它必須先了解初始狀態（例如預算、參與者人數、期望日期）和目標狀態（成功預訂異地場地），然後發現連接它們的最佳行動順序。這個計劃事先是未知的；它是為響應請求而動態建立的。

這個過程的關鍵特徵是適應性。最初的計劃只是一個起點，而不是嚴格的腳本。代理的真正威力在於其整合新資訊並引導任務繞過障礙的能力。如果首選場地不可用或所選餐廳已被訂滿，有能力的代理不會簡單地失敗。它會適應——記錄新的限制、重新評估選項、制定新的計劃。

規劃模式的適用邊界：靈活性 vs 可預測性

規劃模式不是萬靈丹。我們始終面臨著靈活性與可預測性之間的權衡。

如果一個工作流程已經高度固定——像是工廠的標準化流水線，或是每個月底固定的薪資結算流程——在這種情境下，給 AI 太多自主規劃權，讓它每次都自己去摸索最佳路徑，反而會增加不確定性。我們不會希望財務每個月用不同的邏輯來發薪水。

經驗法則：如果任務本身就是一個閉著眼睛都能走完的固定迷宮，直接給它地圖就好。只有在環境動態且複雜的情況下，規劃模式才能發揮最大價值。

導入前要先問自己：我是在尋求單純的效率，還是需要系統去發現解決方案？

企業場景的實際應用

員工入職流程

新員工入職不是寄封歡迎信就結束了。建立各系統帳號（Email、VPN、HR 系統）、分派培訓課程、安排導師、跨部門協調設備與權限——代理可以按邏輯順序執行這些相依任務。

        ┌──────────────────┐
        │  新員工入職觸發    │
        └────────┬─────────┘
                 │
    ┌────────────┴────────────┐
    │                         │
    ▼                         ▼
┌──────────┐           ┌──────────┐
│ 建立Email │           │ 建立VPN   │
│ 帳號      │           │ 帳號      │
└────┬─────┘           └────┬─────┘
     │ 成功                 │ 成功
     ▼                      ▼
┌──────────┐           ┌──────────┐
│ 發送      │           │ 分派培訓  │
│ 歡迎信    │           │ 課程      │
└──────────┘           └──────────┘

    ┌──────────────────┐
    │ 跨部門協調設備權限 │ ← 耗時最長，背景執行
    └────────┬─────────┘
             │ 權限審核失敗！
             ▼
    ┌──────────────────┐
    │ 暫停該環節        │
    │ 通知管理者補件    │ ← 不影響其他任務
    └──────────────────┘

代理會先建立帳號，確認帳號啟用後才發送歡迎信，而非一股腦全部同時進行。如果某個系統回傳權限審核失敗，代理會暫停該環節、通知管理者補件，同時繼續處理其他不相依的任務。

機器人自動導航

在倉儲機器人的場景中，代理需要在避開突然出現的障礙物（如人員、落下的紙箱）的同時，最佳化時間與能源消耗。代理不是死板地執行「左轉→直行→右轉」的固定路線，而是根據即時感測器資料動態規劃路徑。

      原始路徑
  ┌───── A 點 ─────┐
  │  左轉 → 直行    │
  │        ↓        │
  │    ⚠️ 障礙物！   │
  │  人員突然出現    │
  └─────┬──────────┘
        │
        ▼
    ┌──────────────┐
    │  暫停當前路徑  │
    │  感測器回報    │
    └──────┬───────┘
           │
    ┌──────▼───────┐
    │  重新計算路徑  │
    │  右轉 → 繞行   │
    │  同時檢查電量  │
    └──────┬───────┘
           │
    ┌──────▼───────┐
    │ 電量 > 30%    │
    │ 繼續執行任務   │
    │ 抵達 B 點 ✅  │
    └──────────────┘

發現前方阻擋時，立即重新計算替代路線，並考量剩餘電量決定是否需先返回充電站。

智慧客服系統

面對客戶抱怨「我上週買的筆電無法開機」，代理可自主建立診斷計劃：先查詢訂單確認保固狀態，再引導使用者進行基本排錯，若無法解決則自動蒐集裝置日誌，必要時將完整脈絡整理後升級給人類技術人員。

        ┌──────────────────┐
        │  客戶抱怨：        │
        │  「筆電無法開機」  │
        └────────┬─────────┘
                 ▼
        ┌──────────────────┐
        │  查詢訂單與保固狀態 │
        │  確認仍在保固期內  │
        └────────┬─────────┘
                 ▼
        ┌──────────────────┐
        │  引導使用者排錯    │
        │  ① 檢查電源連接    │
        │  ② 強制重啟       │
        └────────┬─────────┘
                 │ 仍無法開機
                 ▼
        ┌──────────────────┐
        │  自動蒐集裝置日誌  │
        │  系統記錄、錯誤碼  │
        └────────┬─────────┘
                 │
                 ▼
        ┌──────────────────┐
        │  升級給人類技術人員 │
        │  附完整脈絡：      │
        │  訂單編號          │
        │  排錯記錄          │
        │  日誌檔            │
        └──────────────────┘

代理避免客戶重複描述問題，確保轉交時資訊完整。

開發框架實作：LangChain.js 規劃與編寫

LangChain.js 可以實作規劃模式。以下範例示範如何建立一個具備規劃與寫作能力的代理——它會先為某個科技主題制定大綱，再依據大綱寫出文章。

import { ChatOpenAI } from '@langchain/openai'
import { ChatPromptTemplate } from '@langchain/core/prompts'
import { createToolCallingAgent } from 'langchain/agents'
import { AgentExecutor } from 'langchain/agents'

const llm = new ChatOpenAI({ model: 'gpt-4o', temperature: 0 })

const plannerAgent = await createToolCallingAgent({
  llm,
  tools: [],
  prompt: ChatPromptTemplate.fromMessages([
    ['system', '你是一個專業的技術寫作與內容策略專家。先擬定寫作計劃，再依據計劃寫出文章。'],
    ['human', '主題：強化學習在 AI 中的重要性\n\n' +
     '1. 先為這個主題制定一個 bullet-point 大綱\n' +
     '2. 依據大綱寫出一篇約 200 字的摘要'],
  ]),
})

const executor = new AgentExecutor({ agent: plannerAgent, tools: [] })
const result = await executor.invoke({
  input: '請開始規劃與寫作',
})
console.log(result.output)

這個代理的關鍵在於它不是一份靜態的待辦清單。在傳統腳本中，步驟之間的邏輯是靜態寫死的——開發者在寫程式時就預先固定了每一步的順序與邏輯，例如「第一步開啟檔案、第二步讀取資料」，如果第一步因為檔案不存在而失敗，第二步根本無法執行，程式就直接崩潰。每一步能做什麼、走不通時該怎麼辦，都沒有動態判斷的空間。但在 LangChain.js 中，代理是在編排工具、處理步驟間的依賴關係。如果第一步搜尋回傳了意料之外的資訊，代理會意識到原本設定的第二步不能用了，於是在執行任務的當下，一邊做、一邊評估、一邊修正計劃。

進階規劃：Google Deep Research

當目標變得龐大又模糊，單一線性代理就不夠用了。這時需要引入更具規模、能長期運作的系統，例如 Google Deep Research。

這是一個長期執行的非同步過程——我們可以丟給它一個極度發散的研究主題，然後去喝咖啡、開會、甚至睡覺，它會在背景工作好幾個小時。它的設計有一個非常關鍵的亮點：它不是一拿到任務就埋頭亂做，而是先擬定計劃，提交給我們審查。它會將模糊的提示解構為一個詳細的多點研究計劃，在正式投入大量運算資源之前，先跟我們確認研究方向。

              ① 使用者提交模糊主題
         ┌──────────────────────────────┐
         │  「索馬魯肽的經濟影響」          │
         └──────────────┬───────────────┘
                        ▼
         ┌──────────────────────────────┐
         │  ② 擬定研究計劃 ➔ 提交審查      │
         │  代理解構目標為多點研究計劃       │
         └──────────────┬───────────────┘
                        ▼
      ┌───────────────────────────────────┐
      │  📋研究計劃                         │
      │  ├ ❶ 蒐集FDA臨床試驗數據            │
      │  ├ ❷ 分析市場規模與競爭者            │
      │  ├ ❸ 評估保險給付影響               │
      │  └ [批准執行] [修改計劃]             │
      └──────────────┬────────────────────┘
                     │ 批准
                     ▼
         ┌──────────────────────────────┐
         │  ③ 深度研究迴圈（數小時）       │
         │  搜尋→分析→發現矛盾→深入挖掘     │
         └──────────────┬───────────────┘
                        ▼
         ┌──────────────────────────────┐
         │  ④ 產出最終報告               │
         │  含圖表、引用來源、查閱清單      │
         └──────────────────────────────┘

主動解決矛盾

Deep Research 最令人驚豔的能力是主動解決矛盾。假設它在研究某個經濟指標時，讀到報告 A 說「通貨膨脹正在加劇」，但隨後又看到資料庫 B 顯示「民生物價在下跌」。傳統搜尋引擎大概就是把這兩份互相矛盾的資料並排丟給我們自己去苦惱。但 Deep Research 的內部邏輯會觸發一個衝突標籤——它會自己發現矛盾。然後暫停原本的主任務，自動生成一個全新的、專門針對這個矛盾點的搜尋，去挖掘為什麼 A 和 B 結論不同。直到釐清了這個知識落差，才回到主線上。

這完全解決了人類手動研究的最大瓶頸：我們在面對海量資訊時，最大的敵人往往是時間和確認偏見。我們常常找兩個小時就累了，或者只要找到幾個能支援既有觀點的來源就心滿意足地停下來。但 AI 不會疲倦，也沒有認知偏誤，能處理比人類多出幾十倍來源，大大擴展了探索邊界。

企業級整合：OpenAI Deep Research API

要將這種強大的研究能力整合進企業內部的私有資料庫，就需要 OpenAI Deep Research API。它提供了不同層級的模型——o3-deep-research-2025-06-26 專門用來處理深度資訊綜合，o4-mini-deep-research-2025-06-26 針對延遲敏感應用設計。

import OpenAI from 'openai'

const openai = new OpenAI({ apiKey: 'YOUR_OPENAI_API_KEY' })

const response = await openai.responses.create({
  model: 'o3-deep-research-2025-06-26',
  input: [
    {
      role: 'developer',
      content: 'You are a professional researcher preparing a structured, data-driven report. Focus on data-rich insights, use reliable sources, and include inline citations.',
    },
    {
      role: 'user',
      content: 'Research the economic impact of semaglutide on global healthcare systems.',
    },
  ],
  tools: [{ type: 'web_search_preview' }],
})

const finalReport = response.output.at(-1)?.content?.[0]?.text
console.log(finalReport)

這套 API 的關鍵優勢在於透明度——它公開了代理的所有中間步驟，包含推理過程、實際執行的外部搜尋查詢，以及為了分析資料而自主執行的程式碼。開發者可以透過 response.output 逐一檢視：

// 檢視推理過程
for (const item of response.output) {
  if (item.type === 'reasoning') {
    for (const part of item.summary) {
      console.log(`  - ${part.text}`)
    }
  }
}

// 檢視實際的搜尋查詢
for (const item of response.output) {
  if (item.type === 'web_search_call') {
    console.log(`Query: ${item.action.query}, Status: ${item.status}`)
  }
}

// 檢視代理自主執行的程式碼
for (const item of response.output) {
  if (item.type === 'code_interpreter_call') {
    console.log(`Code:\n${item.input}`)
    console.log(`Output:\n${item.output}`)
  }
}

舉例來說，設定系統為「專業醫療研究員」，查詢「索馬魯肽（Semaglutide）的經濟影響」。具備深度規劃能力的代理，它的思考路徑完全不同：

查詢：「索馬魯肽（Semaglutide）的經濟影響」

從減肥藥聯想到飛機燃油，這就是代理在執行過程中不斷發現新節點、驗證新假設的過程。

要實現這種跨領域的深度研究，代理需要同時存取公開網路與企業內部資料。這就帶出了兩個關鍵的企業級設計：MCP（模型上下文協定） 與透明度機制。

MCP：橋接資料孤島

MCP（Model Context Protocol，模型上下文協定） 解決了企業導入 AI 最頭痛的問題：資料孤島與安全性。在典型的企業環境中，內部銷售資料存放在 CRM、競爭對手分析在私有雲端、財務報表在 ERP——這些系統之間彼此隔離，傳統 AI 只能存取公開網路。

MCP 就像一座安全控管的專屬橋樑——開發者可以授權代理在合規的安全框架下走過這座橋，去讀取內部的私密資料庫，然後將外部公開情報與內部銷售資料融合在一起寫成報告。這不僅解決了資料孤島問題，也確保了存取權限可控。

透明度的設計

進階的 Deep Research API 還有一個關鍵設計：透明度。它公開了代理的所有中間步驟——包含推理過程、實際執行的外部搜尋查詢、以及為了分析資料而自主執行的程式碼。等於是把運算草稿紙全部攤在桌上給開發者檢查。

從 MCP 的資料整合到中間步驟的可見性，這兩個設計共同回答了企業導入 AI 代理時最常問的兩個問題：「資料安全嗎？」和「結果可信嗎？」——前者靠 MCP 的控管橋樑解決，後者靠完整的透明度機制解決。

規劃能力對 UI/UX 的深遠影響

規劃能力不只是後台的技術升級，更從根本上改變了使用者與系統的互動模式。以下是幾個關鍵的 UI/UX 挑戰與設計方向：

1. 計劃審查與批准流程（Plan Review & Approval）

Google Deep Research 最值得參考的設計是「先擬計劃、再送審查」。這對 UI 的啟示是：當代理需要長時間執行複雜任務時，不應該直接埋頭就做。UI 應該在正式執行前，呈現一份計劃摘要，讓使用者確認方向是否正確：

📋 研究計劃（預計耗時 15 分鐘）
├── 階段一：蒐集 FDA 批准記錄與臨床試驗數據
├── 階段二：分析市場規模與主要競爭者
├── 階段三：評估保險給付對銷售的影響
└── 階段四：整合為最終報告

[批准執行] [修改計劃] [取消]

這就像是請了一個超認真的實習生，他先拿著大綱跑來問：「我打算從這三個角度切入，方向對嗎？」批准後才投入大量資源執行。

2. 多步驟進度可視化

不同於傳統的單次查詢，規劃中的代理可能需要執行數十個步驟。UI 需要設計類似任務看板（Kanban） 或 GitHub Actions 流水線的視覺化介面，讓使用者一目瞭然：

每個步驟獨立顯示其狀態（待執行、進行中、成功、失敗、已重試），讓使用者隨時掌握全域進度。

3. 動態重規劃的通知機制

規劃能力最核心的特色是代理會根據新資訊動態調整計劃。但這也帶來 UX 上的信任挑戰：如果代理自己偷偷改了計劃，使用者卻不知道，會產生嚴重的失控感。

UI 應該在代理偏離原計劃時主動通知：

🔔 代理已調整原定計劃
原因：首選場地「台北君悅酒店」已被訂滿
替代方案：已自動尋找並預訂「台北晶華酒店」
差額：預算內 ✅

[查看變更對比] [接受] [干預]

這讓使用者在代理展現適應力的同時，仍保有知情權與最終決定權。

4. 中斷與重新導向

當代理正在執行一個長時間的規劃任務時，使用者可能突然改變主意，或發現代理走錯了方向。UI 需要提供非同步中斷機制——使用者可以隨時介入、修改指令，代理則根據新指令重新規劃後續步驟，而非從頭開始。

// 概念示意：UI 可以發送插隊指令給正在執行的代理
// 實際 API 名稱與用法依所選代理框架而定
await agent.interrupt({
  reason: '使用者變更優先順序',
  newDirective: '改為搜尋高雄的場地',
  preserveCompleted: true, // 保留已完成步驟的結果
})

5. 信心指數與替代方案展示

代理在規劃過程中，可能會對某些步驟的結果不那麼確定（例如找到的場地評價資訊不足）。UI 可以設計信心指數的視覺化呈現，並主動提供替代方案：

🏨 推薦場地：台北晶華酒店
信心指數：▰▰▰▰▰▰▰▰▰▰ 92%（基於 47 則近期評價）

🔄 替代方案
├── 台北萬豪酒店（信心 85%）
├── 寒舍艾美酒店（信心 78%）
└── 查看更多 →

這讓使用者不只是被動接受單一結果，而是能理解代理的判斷依據，並做出更明智的決策。

總結：當 AI 的最佳路徑與人類直覺背道而馳

規劃模式是將代理系統從簡單的反應響應者提升為策略性、以目標為導向的執行者的核心組件。現代大型語言模型為此提供了基礎能力——自動將高階目標分解為連貫的、可操作的步驟。這種模式從簡單的順序任務執行（如 LangChain.js 的規劃與寫作代理）擴展到更複雜的動態系統（如 Google DeepResearch 的迭代研究計劃）。規劃在人類意圖和複雜問題的自動執行之間架起了重要的橋樑。

重點回顧

• 規劃使代理能夠將複雜的目標分解為可操作的連續步驟，從被動反應轉變為策略執行者
• LLM 可根據任務描述自動產生逐步方法來執行規劃，無需人工預先編寫腳本
• 規劃模式的核心是適應性——代理會根據新資訊動態調整計劃，而非死板地遵循腳本
• Google Deep Research 是先擬計劃再審查、非同步執行、主動解決矛盾的典範
• OpenAI Deep Research API 將規劃能力開放給開發者，支援 MCP 整合私有資料庫，並提供完整的中間步驟透明度

但這也留下一個值得深思的問題：今天我們看到 AI 能夠在執行計劃的過程中，根據新資訊不斷自我修正、動態調整策略。但如果它自主探索的過程中適應得太過頭——它計算出來的最佳執行路徑，完全超出我們人類當初能想像的範圍，甚至與人類的直覺和常識背道而馳——我們敢讓它執行嗎？

當 AI 的最佳路徑與人類直覺相悖時，我們該如何治理這些會自己改變心意的超級代理？這個問題，或許是接下來十年 AI 領域最深沉的課題之一。

參考資料

• 第 6 章：規劃