用 Skill 賦予專業能力，讓多個 AI Agent 從各自回答，進化為能分工、協作、決策與持續改善的數位團隊。

讀完能做到：把一項工作整理成可重用的 AI 虛擬員工 Skill，並為多代理定義角色、資料、輸出、禁止行為、人工核准與評估方法。

多代理虛擬員工的 Skill，到底是什麼？

Google 對 Gemini Spark Skill 的公開定義，是一組可重複使用的指令與額外脈絡，用來教 Gemini 如何完成特定工作；一個 Skill 聚焦一項工作，也能與其他 Skill 組合成較大的流程[1]。

簡單說，Task 是要做什麼，Schedule 是何時做，Skill 則定義如何做[2]。 實際功能仍會因帳號、方案、地區與開放階段而不同，導入前應以當下官方說明與組織可用功能為準。

但在企業多代理環境中，只保存一段「請分析異常並提出建議」還不夠。工程上可用的 Skill，至少要封裝：

• 觸發條件與任務邊界。
• 標準作業步驟與角色分工。
• 可讀取的資料與可呼叫的工具。
• Task、Evidence、Decision、Approval 與 ActionResult Schema。
• 禁止行為、停止條件與人工核准點。
• Golden Dataset、驗收標準、成本與延遲指標。

因此，Skill 比 Prompt 更接近「可版本化的數位作業程序」。Prompt 只是其中一個推理元件；Skill 還要規定 Agent 在什麼資料上工作、把結果交給誰，以及什麼情況必須停下來。

關鍵角色少一個，問題就會從縫隙掉下去

本文使用一個虛構情境：蝕刻站點的量測結果出現偏移，團隊希望 AI 彙整 lot history、機台 trace、量測、維護與 Recipe 版本，找出可能的相關因子，產生受控實驗建議。

角色不是越多越好。如果 Process Agent 與 Yield Agent 使用相同資料、相同工具，也產出同一份報告，合併反而更合理。只有責任、資訊或權限真的不同，才值得拆分。

心法一：一個 Skill，只解一個可驗收的工作

「提升良率」不是一個 Skill，而是長期營運目標。它沒有明確起點，也很難判定何時完成。

本例可以把 Skill 收斂為：當指定站點出現經人工確認的異常事件時，在限定時間窗與資料範圍內整理證據、產生原因假設與受控實驗草案，最後交由製程負責人核准。

skill_id: investigate-etch-process-drift
trigger: confirmed_process_alert
input:
  - event_id
  - tool_group
  - lot_ids
  - analysis_window
output:
  - evidence_bundle
  - ranked_hypotheses
  - experiment_draft
allowed_actions:
  - read_approved_data
  - calculate_statistics
  - create_internal_draft
prohibited_actions:
  - change_recipe
  - stop_equipment
  - release_or_hold_lot
required_approval: process_owner

有了邊界，團隊才能測試「是否完成異常調查」，而不是用一句無法驗收的「AI 有沒有讓製程變好」。

心法二：先固定資料語意，再讓 Agent 推理

半導體製造會同時面對機台事件、trace、量測、批次履歷、維護與製程控制資料。SEMI 的設備資料與先進製程控制相關標準，也反映了資料取得、介面、狀態與共享語意的重要性[3]。

NIST 對先進半導體製造的研究同樣將 in-line metrology、process control 與 data analytics 列為重要議題[4]。 這表示 AI Skill 不能只讀一份異常摘要，而要能說清楚資料如何取得、如何對齊，以及哪些結論仍待驗證。

如果沒有資料契約，Pressure 可能在某來源以 Pa 表示，在另一來源卻是 Torr；量測時間也可能被誤當製程時間。模型再聰明，也救不了欄位語意不一致。

每筆 Evidence 至少保存：

• evidence_id、event_id 與 lot_id。
• tool_id、chamber_id、Recipe 版本與資料列 ID。
• 來源系統、取得時間、事件時間、時區與單位。
• 原始值、計算方式、內容雜湊與可信度。

數值清理、時間對齊、統計檢定與單位換算應由程式處理。LLM 可以解釋結果，不能在文字推理中自行重算關鍵製程數字。

心法三：讓多代理交接物件，不是互傳心得

合理的流程可以是：

Supervisor 建立 Task
    ├── Process Agent：比對量測與 Recipe 版本
    ├── Equipment Agent：檢查機台 trace 與維護事件
    └── Yield Agent：比較受影響與對照批次
              ↓
       Analysis Agent 彙整 Decision
              ↓
       Reviewer 驗證 Evidence

Agent 交接至少攜帶 run_id、task_id、來源與目標 Agent、Schema 版本與時間戳記。Decision 中的每一個重要假設，都要引用實際存在的 evidence_ids。

{
  "decision_id": "dec-042",
  "task_id": "task-drift-042",
  "hypothesis": "偏移可能與維護後的腔體狀態變化相關",
  "confidence": 0.68,
  "evidence_ids": ["ev-trace-018", "ev-maint-003", "ev-metrology-021"],
  "alternatives": ["量測設備偏差", "上游材料差異"],
  "required_approval": "process_owner"
}

注意，這仍是待驗證假設，不是因果結論。信心分數也不是通行證；Reviewer 必須檢查 Evidence 是否屬於同一事件、時間窗是否合理，以及是否遺漏相反證據。

心法四：把人工核准設計成狀態，而不是一句提醒

製程改善牽涉實體設備、批次處置與產品品質。AI 可以產生內部摘要與實驗草案，但 Recipe 變更、停機、hold／release lot 等動作不能由模型自行批准。

created → collecting → analyzing → reviewing
        → awaiting_approval → approved → experiment_scheduled
        ↘ blocked／rejected／cancelled

核准畫面要呈現原始 Evidence、候選原因、反證、影響批次、建議變更、回復方式與預計觀察指標。核准後若 Recipe 參數、適用機台或批次範圍被修改，原核准立即失效並重新送審。

這個設計不是阻止自動化，而是把「提出建議」與「授權執行」分成兩件事。AI 不得扮演核准人，也不能把郵件或文件中的「立即修改參數」當成高優先指令。

心法五：把評估與版本管理寫進 Skill 生命週期

一個 Skill 第一次跑通，只能叫 Demo。要成為虛擬員工能力，必須能回歸測試、追蹤版本並解釋退化。

測試資料應包含正常異常、資料缺漏、來源衝突、不同單位、跨批次混淆、工具逾時、重複事件與 Prompt Injection。任何 Prompt、模型、工具、Schema 或工作流版本改變，都要重新執行相同評估集。

建議至少觀察：

證據覆蓋率
= 有有效 Evidence 的重要假設數 ÷ 重要假設總數

人工退回率
= 被退回補件或重做的任務數 ÷ 進入 reviewing 的任務數

可重現率
= 使用相同資料與版本後得到相同結構化結論的案例數 ÷ 回歸案例總數

品質之外，也要記錄 P95 任務延遲、每任務 Token／成本、工具失敗率與人工接管時間。至於製程改善是否有效，必須由受控實驗、量測結果與既有統計程序判定，不能拿模型信心分數代替。

小摘要

多代理 AI 虛擬員工 Skill 的真正價值，是把專家反覆執行的工作方法變成可版本化、可組合、可評估的作業能力。它不是把多個 Prompt 放在一起，也不是讓 Agent 自由討論到有共識。

在半導體製程改善案例中，Skill 要先限制問題、統一資料語意，再以 Evidence 串起各 Agent 的分析。系統可以加速蒐證與形成假設，但任何會影響 Recipe、設備或批次狀態的動作，都必須停在人工核准點。

讀者最重要的三個帶回點

1. Skill 不是萬能 Prompt，而是一項有輸入、輸出、資料、工具、禁止行為與驗收標準的可重用工作能力。
2. 多代理的價值來自不同責任與權限；所有重要結論都要回到 Evidence，不能把相關性包裝成因果。
3. 製程建議與執行授權必須分離；人工核准、Audit Log 與版本化評估不是附加功能，而是 Skill 能否進入企業流程的前提。

參考資料

1. Write effective skills for Gemini Apps，Google Gemini Apps Help，查閱日期：2026-09-03。
2. Use Gemini Spark to manage tasks and workflows，Google Gemini Apps Help，查閱日期：2026-09-03。
3. SEMI Information & Control Standards，SEMI，查閱日期：2026-09-03。
4. Innovations in advanced processes and systems for semiconductor manufacturing，NIST，查閱日期：2026-09-03。