當「AI 會搶走工作」成為許多人的焦慮根源，MGI 麥肯錫最新報告 Agents, robots, and us: Skill partnerships in the age of AI 提供了不同的敘事。報告指出，現有技術理論上能自動化美國約 57% 的工作時數，但這不等同於「57% 的崗位會消失」——真正的機會在於「重構工作流程」，讓人類、智能體（Agents）與機器人（Robots）協作，釋放潛在的經濟價值。

若企業與組織能善用這股變革，到 2030 年，美國每年有望新增約 2.9 兆美元 的經濟產能。

一、人機協作的新框架：為何是「合作」不是「取代」

技術潛力 ≠ 立即大規模替代

MGI 麥肯錫明確指出，他們估算的是「技術上可自動化的工作時數」，而不是預測未來多少職位會消失。

這 57% 的自動化潛力涵蓋廣泛，但真正實現還要跨越政策、成本、產業採用速度、組織習慣等多重門檻——也就是說，這是一條長時間、分階段的轉型之路。

因此，更恰當的理解是：自動化為工作內容帶來重構契機。

二、智能體 (Agents) 與機器人 (Robots)：新的工作基石

Agents = 虛擬同事 (Virtual Coworkers)

「智能體」這個術語被廣義定義，不僅限於生成式 AI，而包括所有能自動化「非物理」工作 (nonphysical work) 的軟體系統。報告引用這個概念，是為了涵蓋從行政、文書、資料處理到複雜認知任務等各類型工作。

當前技術能讓 Agents 執行佔美國工作時數約 44% 的任務。

Robots = 實體執行者（物理世界）

機器人則著重於物理工作 (physical work)——但即便是最先進的機器人，目前在靈巧度、環境感知、可靠性與安全性上，仍遠不及人類。報告指出，機器人能自動化的物理工作約佔工作時數的 13%。

人、智能體、機器人三分工的整體框架

報告中有一個 2×2 矩陣 (people-agents-robots matrix)，將所有工作時數依「是否可自動化」與「是否需要物理能力 / 社交情感能力」分類。自動化潛力最高的是「非物理、可自動化」這一塊 (agents 主導)；而真正需要人類的往往是帶有社交／情感需求或高靈巧度的工作。

這意味著：機器可能取代部分任務，但人依然不可或缺，特別是在 judgment、同理心、責任承擔、複雜環境反應等方面。

三、技能不會消失，而是重構 — AI 流利度成為新通用語言

大多數人類技能仍有價值

MGI 提出，在當前雇主重視的技能中，有超過 70% 同時適用於可自動化與不可自動化工作。換句話說，很多技能只是被重新配置，而不是被淘汰。

這代表，像是溝通、問題解決、判斷、領導、細節管理、客戶關係等等「跨領域通用技能」，仍然是未來勞動市場的核心。這與過去認為機器會取代重複性工作的論調，有著本質不同。

AI 流利度 (AI Fluency) 飆升

報告指出，在過去兩年中，美國職缺對「AI 流利度」的需求暴增近七倍，成為所有技能中漲幅最快的。

這裡的 AI 流利度，不只是會操作工具那麼簡單，而是指：

• 能理解 AI 做什麼、不能做什麼
• 能指揮、管理 AI／機器人團隊
• 能對 AI 輸出做批判性判斷
• 能把 AI 整合到工作流程設計中

對任何想在未來保持競爭力的人來說，AI 流利度將是新的基本能力。

四、重構流程，而不是用 AI 做舊流程 — 典型應用場景

MGI 報告強調，若只是把 AI 當作更快、更聰明的工具，用在原有流程中，能釋放的價值有限。真正的大幅提升來自「從工作流程 (workflow) 本身出發，重新設計流程」，並賦予人、agent、robot 各自最適合的角色。

以下為幾個典型場景（原文章中也提過） — 以便打造更具說服力、易落地的案例：

• 行政／辦公流程：將例行性文書、資料整理等交給 agent，讓人專注策略、決策、創造性任務
• 客服／支援中心：agent 負責初步查詢、分類、簡單回應；人則處理情緒、安撫、複雜問題
• 醫療與製藥：AI 協助資料整理、報告撰寫、初步分析，人類負責最終判斷、治療方案、倫理監督
• IT／老舊系統改造：使用 agent 分析依賴、生成新程式碼與測試，開發者轉為架構設計與驗證者

這樣的變革，不只是效率提升，而是在重新定義「什麼是人的價值」。

五、對組織與管理者的挑戰與機會

MGI 在報告中指出：真正的贏家不是那家買下最多 AI 工具的公司，而是最早重構流程、最懂如何建立人機信任、最擅長整合人力與技術的企業。

這對管理者／領導者提出新的挑戰：

• 需要有能力設計混合團隊 (human + agent + robot)
• 需要建立評估與驗證機器輸出的機制
• 建立容錯、試錯與學習文化（因為初期智能體與機器人一定犯錯）
• 將釋放出來的人力重新分配到創新、高價值、不可替代的工作

對你所屬的公司、團隊、產業而言，這是一次結構性重整的機會。

未來趨勢與專業建議

趨勢 1：AI 流利度成為通用語言

未來不只是科技領域，幾乎所有高階職位都會要求能用、懂、管、判 AI 的能力。
建議：將 AI fluency 視為基本職能，納入個人／團隊的能力養成與發展藍圖中。

趨勢 2：流程重構成為企業競爭優勢

真正的價值在於「誰能最早、最有效地把 AI／機器人嵌入到核心業務流程中」。
建議：企業領導者應著手審視現有核心流程 (供應鏈、客服、研發、行政…) 是否適合人-agent-robot 混合設計，並進行試點實驗。

參考來源

• 麥肯錫報告書：Agents, robots, and us: Skill partnerships in the age of AI

生成式 AI 正在進入一個關鍵轉折點。過去我們向 AI 提問，它回應一段文字；如今，一線研究已開始讓 AI 以「可操作的應用程式」來回答問題。
Google Research 最新公佈的 Generative UI（生成式 UI） 展示了一種嶄新的互動范式：AI 不是寫答案，而是「做出答案」。

對專業人士而言，這不僅改寫了軟體介面設計的流程，也代表著產品開發、教育科技、知識傳遞方式的徹底轉型。以下將以清晰架構帶你深入理解這場變革的技術核心、應用潛力與限制。

生成式 UI 是什麼？：從文字回答走向「動態應用」

打破傳統 Markdown 的靜態限制

傳統的 AI 回答大多以 Markdown 呈現：可讀、但不可互動。
Google 的研究則提出一個大膽假設：

如果 AI 能直接生成可點擊、可滑動、可運算、可視化的 App，體驗會有何不同？

答案是顛覆性的：
生成式 UI 不再提供靜態資訊，而是現場構建一個小型軟體，如互動實驗室、可視化模擬器、教學工具、遊戲等。

核心架構：虛擬 AI 工程團隊在 1 分鐘內完成開發

Google 的生成式 UI 主要由三大部分組成：

1. 伺服器端工具集：賦予模型「手與眼」

• 搜尋工具：強制查詢 Google Search，以確保內容真實、數據正確。
• 圖像生成工具：自動產生主題圖片或拉取真實影像。
• 其他 API（如地圖）：使 UI 能使用真實世界資料。

這讓 LLM 不再只是推理機器，而是能操控外部工具的「具身智能」。

2. 3000 字的系統指令：AI 的企業級工作手冊

這段巨量指令規範 AI 的開發流程，例如：

• 不得僅輸出文字，必須產生完整 UI
• 不得出現任何假按鈕或 placeholder
• 產生前需進行七步思維鏈推理
• HTML、Tailwind CSS、原生 JS 必須正確無誤

這套規範使生成結果兼具 工程品質、敘事能力與資料真確性。

3. 後處理模組：最終質檢

• 注入真實 API key
• 修補 HTML / JS / CSS 錯誤
• 確保安全性（如屬性轉義）

跨領域應用能力：AI 生成的不只是頁面，而是完整體驗

Google 展示多個案例，以下擷取專業人士較關注的代表性應用。

案例 1：分形探索者（Fractal Explorer）—動態數學實驗室

輸入指令：「詳細解釋分形」。

生成結果不是文章，而是一個 可操作的數學可視化工具：

• 互動式 Mandelbrot / Julia 雙畫布
• 迭代可調的 Koch 雪花、Sierpiński 三角形
• 混沌遊戲產生 Barnsley 蕨葉的模擬器
• 內建維度計算器

此案例展現 LLM 不只懂概念，還能寫出複雜的即時運算 JavaScript。

案例 2：Chronos—計時設備的歷史敘事網站

使用者輸入：「計時器的歷史」。

AI 生成：

• 暗色主題、垂直時間軸
• 從方尖碑、水鐘到原子鐘
• 每一節都有 AI 生成的歷史氛圍圖
• 工程突破以資訊框突出呈現
• 整體如博物館導覽般的敘事感

案例 3：Little Ballers Math Academy—客製化幼兒數學遊戲

Prompt：「用打籃球的可愛生物教五歲小孩加減乘除和二進位」。

AI 建立完整遊戲：

• 加法：傳球
• 減法：投籃
• 乘法：團隊演練
• 二進位：外星記分板與互動開關

所有美術資產（人物、場景、特效）由系統即時生成。

模型能力驗證：AI 與人類專家正面交鋒

Google 為此建立 PAGEN 資料集，由專業 Web 工程師花 3–5 小時構建高品質單頁網站，作為評估基準。

關鍵結果

• 生成式 UI Elo 分數：1710.7
• 人類專家：1756.0（僅略高）
• Markdown：1459.6
• 搜尋結果頁：1355.1

更值得注意：

• 與 Markdown 比賽中勝率 82.8%
• 與純文字比賽勝率 97.0%
• 44% 案例評分者認為 AI ≥ 人類工程師

也就是說，AI 用 1 分鐘產出的成果，在近半情況下等級已接近人類專家數小時的成果。

涌現能力（Emergent Capability）

低階模型無法勝任，如：

• Gemini 2.0 Flash：Elo 1332.9、29% 結構錯誤
• Gemini 3：Elo 1706.7、0% 致命錯誤

代表生成式 UI 是 需要 SOTA 推理能力 才能啟動的能力。

挑戰：速度、成本與韌性仍是硬傷

生成式 UI 雖強大，但仍有三大限制。

1. 生成延遲（1–2 分鐘）

對比搜尋引擎的毫秒級反應，這是明顯瓶頸。
Streaming 可降低體感等待，但仍不足。

2. 程式邏輯的細微錯誤仍會發生

即便 Gemini 3 已 0% 結構錯誤，
仍可能出現：

• 特定螢幕斷點 CSS 錯亂
• 少數 JS runtime error

3. 算力成本高

生成動態 UI ≫ 生成一段文字。
對商業化落地而言是現實挑戰。

下一個十年：軟體將從「產品」轉變為「按需生成的服務」

生成式 UI 展示了未來軟體的一種全新形態：

• 不再下載 App，而是由 AI 現場生成
• 不再學工具，而是直接獲得為你量身定做的工具
• 不再是閱讀內容，而是操作內容

舉例：

• 旅行規劃 → AI 生成專屬互動 App（地圖、價格、日程、預訂）
• 科學教育 → 即時生成可調參數的模擬器
• 數據分析 → AI 自動建立可視化儀表板
• 企業流程 → 自動生成工作流工具或小型內部系統

這是一場從「資訊搜尋」走向「功能生成」的革命。

未來趨勢與專業人士建議

1. 開始思考「需求即應用」的新產品邏輯

未來產品經理、工程師、教育者都需要重新審視：

• 使用者需要的是資訊？還是功能？
• 什麼場景適合讓 AI 自動生成 UI？

2. 預備迎接「AI 生成工作流」成為主流能力

企業將需要：

• 能與 AI 協作的 UX / 前端工程師
• 能寫 AI 指令的 Prompt Engineer
• 能定義商業邏輯並交由 AI 實作的 Domain Expert

這會是新時代專業人士的競爭力指標。

參考資料

• Generative UI: A rich, custom, visual interactive user experience for any prompt
• Generative UI: LLMs are Effective UI Generators
• Generative UI: LLMs are Effective UI Generators PDF

Meta 再度在開源 AI 領域投下震撼彈，正式推出 Segment Anything Model 3（SAM 3） 與 SAM 3D。
兩者結合後，AI 不只「看得見」，更開始能「聽得懂」、「想得通」，甚至「重建」真實世界。

從第一代的 去背神器（SAM 1），到能處理動態影像（SAM 2），再到如今能理解語意、生成 3D 模型的 SAM 3 + SAM 3D，這場升級已不只是版本提升，而是視覺 AI 的 質變時刻。

視覺 AI 從辨識物體到理解世界

過去的視覺 AI 依賴固定的標籤庫，例如「貓」、「車」、「杯子」。
而 SAM 3 帶來的關鍵革命，是能理解 開放式語彙（Open Vocabulary）——即使沒有在標籤庫裡，它也能理解語句中的語意並找出對應物件。

例如：

• 「紅白條紋的那把傘」
• 「坐著但手中沒有禮物的人」
• 「前景中最小的咖啡杯」

SAM 3 已從過去的「像什麼」辨識，進化到「你說的是哪一個」的語意理解層級。

SAM 3：語意驅動的影像與影片分割基礎模型

🔍 文本 + 視覺的深度融合

SAM 3 能直接接受自然語言描述並進行影像分割，具備：

• 語意理解（不是固定標籤）
• 多物件分割能力
• 跨影格一致的語意追蹤
• 能理解複雜描述與場景

⭐ 性能提升 2 倍

在官方測試中，SAM 3 在開放式語彙分割表現上，比包括 Google Gemini 2.5 Pro 在內的現有系統 高出整整 2 倍。

這使得 SAM 3 不再只是影像模型，而是具備「基礎語意能力」的視覺模型。

影片處理：接近即時的多目標追蹤能力

SAM 3 在影片處理上達到「接近即時」：

• 30 毫秒處理超過 100 個目標
• 長時間連續追蹤
• 自動辨識特定人物
• 支援語意追蹤（例如：「穿紅外套、在畫面左側的人」）

實際應用：Instagram Edits

Meta 即將把 SAM 3 放入 Instagram 的影片創作工具：

• 特定人物自動去背
• 一鍵動態特效
• 人物追蹤免逐格調整
• 創作者的時間成本大幅下降

SAM 3D：從單張影像重建 3D 世界的重大突破

SAM 3D 是本次最重要的技術之一，由兩大模型組成：

1. SAM 3D Objects：物件與場景重建
2. SAM 3D Body：人體姿態與形體重建

這兩個模型讓 AI 能真正理解影像中的空間與結構，而不是平面的像素。

SAM 3D Objects：自然影像中的 3D 物件重建

SAM 3D Objects 能在 日常照片 中做到：

• 產生具紋理的 3D Mesh
• 重建物體姿態、大小、形狀
• 處理遮擋、斷裂、間接視角
• 重建整個場景的空間布局

這讓 3D 建模不再需要專家、昂貴設備或多視角資料。

核心技術：打破 3D 資料瓶頸

Meta 建立了一個前所未有的 3D 資料引擎：

• 標註 近 100 萬張影像
• 產生 314 萬組模型內循環 Mesh（model-in-the-loop）
• 結合 AI、自動排序、人類評分、3D 專家修補
• 打造全新評測資料集 SA-3DAO

SAM 3D Objects 在人類偏好測試中以 5:1 勝過其他模型。

實際應用

• 遊戲開發：自動產生素材
• 電商：商品 3D 試擺
• AR/VR：加速內容建立
• 機器人：即時 3D 感知模組

SAM 3D Body：單張影像的高精度 3D 人體重建

SAM 3D Body 能做：

• 單張影像 3D 人體姿態
• 處理遮擋、奇特姿勢、多類衣著
• 接受 Mask 或 2D Keypoints 進行提示（promptable）
• 預測搭配「MHR（Meta Momentum Human Rig）」人體模型

🧩 技術細節

• 以 800 萬張高質量影像 訓練
• 包含多視角拍攝、動作捕捉資料、專業級影像
• 大幅提升 3D 姿態、骨架、皮膚變形、衣著等細節
• 多步驟精煉（multi-step refinement）
• 支援互動式提示（segmentation mask、2D 點位）

SAM 3D Body 已成為 Meta Codec Avatars 的重要基礎技術之一。

AM 3D 的限制：專業端使用時需注意

SAM 3D Objects 的限制

• 中等解析度，細節表現仍可提升
• 缺乏物理推理（物件接觸、碰撞、支撐等）

SAM 3D Body 的限制

• 目前無法處理多人互動
• 手勢細節仍略遜於專門手部建模模型

AI × 人類的資料引擎：突破 3D 訓練瓶頸

Meta 使用的資料流程：

1. 模型自動產生多個 3D 選項
2. 人類評估品質
3. 3D 專家處理少數困難案例
4. 模型吸收新資料並迭代
5. 重複循環，模型愈來愈強

這種「model-in-the-loop」策略成功解決：

• 3D Ground Truth 難以獲得
• 3D 資料昂貴且難產出
• 過去只能依靠少量合成資料訓練的限制

科學與保育應用：AI 作為科學家的「數位望遠鏡」

Meta 與 Conservation X Labs 推出 SA-FARI：

• 超過 1000 萬部野生動物影片
• SAM 3 能自動偵測、追蹤稀有物種
• 串接 FathomNet 進行深海生物辨識

SAM 3 已走向科研領域的實際應用。

Segment Anything Playground：讓頂尖 AI 走入每個人手中

Meta 推出全新的 Segment Anything Playground：

• 不需要寫程式
• 上傳圖片 → 選物件 → 自動重建 3D
• 支援 SAM 3 + SAM 3D
• 可自由旋轉、調整視角、自訂輸出

這是一個讓 AI 從實驗室走向大眾的關鍵產品。

產品應用：Marketplace、Instagram、Meta AI 全面升級

Facebook Marketplace

「View in Room」已整合 SAM 3 與 SAM 3D：

• 自動生成 3D 商品
• 可在使用者房間中擬真呈現
• 比例、光線、視覺保持一致

Instagram Edits

• 一鍵追蹤人物
• 自動去背特效
• 動態特效快速套用

Meta AI Vibes

• 自動影片混剪
• 語意選取與特效套用

開源策略：Meta 的 AI 大棋局

Meta 採取全面開源策略：

• 開放 SAM 3D 模型權重
• 推出推論程式碼
• 開放評測資料集
• 未來發布 SA-3DAO

這讓產業能依需求打造自家版本：

• 醫療影像版 SAM
• 製造業檢測版 SAM
• 生物顯微鏡版 SAM
• 半導體檢測版 SAM

Meta 正打造視覺 AI 的全球標準。

未來趨勢與專業建議

1. 視覺工作流程全面進入「語意提示（Prompt）」時代

專業人士需要開始建立屬於自己的提示語模板，提升影像處理效率。

2. 垂直產業將開始打造「領域專屬版 SAM」

建議企業從現在開始：

• 整理影像資料庫
• 建立專業名詞語意標註
• 規劃微調模型流程
• 建立半自動資料引擎

這將成為 AI 生產力競爭的下一階段。

參考資料

• Meta AI Blog（SAM 3 & SAM 3D）
• Segment Anything Playground
• The latest AI news from Meta
• Conservation X Labs
• ExecuTorch Adoption in Reality Labs

在 AI 編程快速演進的今年，OpenAI 突然拋出一顆震撼彈——GPT-5.1-Codex-Max。
相較於上一代 Codex，這次的更新不只是性能提升而已，而是真正意義上的「能力邁向長程推理階段」：

• 能夠跨越數百萬 token、連續運行 超過 24 小時
• 原生支援上下文壓縮，任務不中斷
• 在軟體工程任務效率上達到全新 SOTA
• 提供適用於 CLI、IDE、雲端與 API 的完整工具鏈

對於需要長時程推理、複雜系統構建、跨文件專案管理的專業工程師，本篇文章將帶你深入解析 Codex Max 的核心革新、實務意義與未來潛力。

開始使用：快速安裝指令

$ npm i -g @openai/codex

Codex Max 從第一天起就能在：

• CLI（命令列工具）
• IDE 擴充套件（如 VS Code）
• 雲端環境
• Code Review 工作流中直接使用，API 也即將開放。

GPT-5.1-Codex-Max 是什麼？具備哪些新能力？

1. Frontier 等級的 AI 編程模型

GPT-5.1-Codex-Max 建構於 OpenAI 最新的 **基礎推理模型（foundational reasoning model）**之上，這個模型專為跨領域的「代理式任務（agentic tasks）」訓練，包括：

• 軟體工程（PR 建立、Code Review、前端與後端開發）
• 數學推理
• 技術研究
• 多步驟任務執行

它的定位很清楚： 成為工程師可依賴的「長時程 AI 編程夥伴」。

2. 重大突破：跨上下文窗口的長時間連續運行

原生 Compaction（壓縮）技術：突破上下文限制

這次最具革命性的技術，是模型原生支援 Compaction。
它能在窗口即將耗盡時：

1. 自動壓縮早期內容
2. 騰出新的上下文空間
3. 在同一任務中繼續推理

結果是：

• 任務不中斷
• 推理不需要分段
• 模型能連續處理數百萬 token

OpenAI 內部測試顯示：Codex Max 可在單一任務中持續運行超過 24 小時。

這對專業工程師的意義非常重大，因為你可以讓模型做：

• 大型專案 refactor（跨數百個檔案）
• 深度 debugging（長達多小時）
• 書籍或大型技術文件分析
• 自動 code review pipeline
• 多小時的 agent loop

在真實世界工程任務的強化表現

1. 針對工程任務的特化訓練

GPT-5.1-Codex-Max 在訓練過程中加入大量真實任務：

• PR 建立
• Code Review
• 前端 UI/UX 開發
• 技術問答（Q&A）
• 多檔案關聯程式碼任務

其結果是：

• 實務工程表現全面提升
• 推理更合理
• 步驟更清晰
• 錯誤更容易被發現

同時，它也是 第一個能在 Windows 環境運作的 OpenAI 模型，顯示其訓練範圍更接近真實開發設置。

2. Token 效率大幅提升：效能與成本同步下降

更有效率的推理：30% 少用的思考 token

在 SWE-bench Verified 測試中：

• 相同 medium 推理強度下
• Codex Max 效能高於 GPT-5.1-Codex
• 同時使用 少 30% 的思考 token

這會直接轉化為：

• 更低成本
• 更快回應
• 更穩定的推理過程

xhigh reasoning：專為深度工作打造

如果你進行的是：

• 系統重構
• 多步驟分析
• 長篇內容精準推理

可啟用 xhigh 模式，讓模型思考更久、輸出品質更穩定。

官方仍建議： medium 推理是日常使用的最佳選擇。

業界產品比較：Codex Max vs Claude Code

第三方測試指出：

• Claude Code：速度快、反應迅速
• Codex Max：長時程推理強、token 使用更省、上下文能力更穩

兩者定位並非互斥，而是適合混合使用：

• Claude：快速 prototype
• Codex Max：跨專案、跨數百檔案的大型任務

GPT-5.1 Pro：低調上線的另一款升級版本

除了 Codex Max，OpenAI 也同步釋出 GPT-5.1 Pro。
雖然官方資訊不多，但測試顯示：

• 指令遵循能力比標準 5.1 明顯更強
• 在 IDE 整合後可作為快速協作助手
• 與 Gemini 3 仍有差距，但在工程輔助面仍具競爭力

未來趨勢與對工程師的實務建議

1. AI 將開始佔據工程專案的「長時程工作區段」

Codex Max 的長時間連續推理能力，將使 AI 從「輔助工具」進化為能處理：

• 大型 refactor
• 長時間 debugging
• 跨專案關聯分析
• 持續 code review pipeline 的主力工程夥伴。

2. 多模型協作將成為新常態

工程團隊應開始建立：

• 模型能力矩陣
• 任務指派策略
• 自動化 code pipeline 利用不同模型的優勢建立「AI DevOps」。

參考資料

• OpenAI：GPT-5.1-Codex-Max 官方介紹
• https://x.com/mattshumer_/status/1991263717820948651

在 2025 年的 Microsoft Ignite 大會上，微軟正式揭示 Copilot 生態的重大升級，包括支援可記憶偏好與工作流程的 Work IQ 智能層、統合管理所有智慧體（Agent）的 Agent 365 控制平台，以及 Word、Excel、PowerPoint 與 Teams 內建的全新智慧體模式。
本篇文章將帶你深入解析這些更新如何改變企業的數位工作流程，並說明它們對專業人士的實際影響。

一、Work IQ：讓 Copilot 具備長期記憶的智慧層

— 能理解你、預測你、並協助你打造專屬 Agent 的核心引擎

微軟宣布，超過 90% 的《財富》500 大企業已導入 Microsoft 365 Copilot。隨著 Work IQ 的推出，Copilot 的能力不再僅是「回應指令」，而是開始理解個人化的工作模式，並透過推理能力在背後主動支援使用者。

1. Work IQ 三大核心能力

（1）工作資料理解

Work IQ 會分析使用者在 Outlook、Word、Teams、OneDrive 等工具中的郵件、文件、會議紀錄與聊天內容，理解：

• 你如何進行工作
• 內容的邏輯、關聯性與專案脈絡

（2）使用者個人化記憶

包括：

• 常用表達風格
• 工作偏好（如常合作對象、常用格式、核准流程）
• 習慣的工作流程

Work IQ 不只理解組織架構，更能理解「你的工作模式地圖」。

（3）推理與預測能力

在推理層加入 AI 推論後，Work IQ 可：

• 主動推測使用者下一步行動
• 根據意圖推薦最佳智慧體（Agent）
• 自動建立跨文件、跨流程的相關建議與洞察

2. Work IQ for Custom Agent：打造屬於你的智慧工作夥伴

企業或開發者可利用 Work IQ 打造專屬於特定部門或職位的 Agent，例如：

• 法務文件審查 Agent
• 財務模型自動化 Agent
• 專案管理與流程協作 Agent

並完整支援：

• 現有的權限架構
• 敏感度標籤
• 合規審計
• API 及 Copilot Studio 開發

二、Microsoft 365 Copilot 全面升級：Office、語音、影像抓取與行動體驗

Microsoft 365 Copilot 在 Office 應用中的智慧體模式已正式亮相，並強化跨裝置與語音互動的體驗。

1. Word / Excel / PowerPoint 的智慧體模式

• Excel 智慧體模式：支援切換 Anthropic 與 OpenAI 模型
• Word 智慧體模式：正式上線
• PowerPoint 智慧體模式：可透過 Frontier Program 搶先體驗

此外，使用者可直接在 Copilot Chat 中產生高品質：

• 企劃文件
• 財務報表
• 簡報

2. 語音互動：真正把 Copilot 當「同事」使用

12 月起，使用者可：

• 對 Copilot 說：「今天的工作重點是什麼？」
• 請它摘要錯過的 Teams 會議
• 在手機上用語音整理 Outlook 信箱

新增「摘要並回覆」一鍵功能可快速處理郵件與排程，提升行動工作的效率。

3. 圖像／文字即時抓取

使用「詢問 Microsoft 365 Copilot」後：

• 任意圖片或文字都可直接輸入 Copilot
• 適用於截圖、掃描文件、拍攝投影片等情境

三、企業級 Agent 與 GPT-5.1：真正改變業務流程的 AI 工作引擎

微軟的策略非常明確：用智慧體（Agent）重新定義企業運作模式。

1. 銷售智慧體：Sales Development Agent

功能包括：

• 自主培育潛在客戶
• 管理銷售管道
• 連結 CRM（如 Salesforce、Dynamics 365）
• 主動展開個人化客戶觸達
• 直接在 Microsoft 365 工作流程中採取行動

預計 2025 年 12 月透過 Frontier Program 提供。

2. App Builder：用自然語言快速建立應用與工作流

適用於無程式或低程式碼環境：

• 幾分鐘即可建立 App 或自動化流程
• 搭配智慧工作流 Agent，適合 HR、IT、營運流程自動化使用

3. GPT-5.1 正式加入 Copilot Studio

企業可直接選擇：

• 各版本 OpenAI 模型
• Anthropic 模型
• 自家或外部模型

並依任務選擇最佳模型。

四、Agent 365：企業智慧體的統一控制中心

微軟估計到 2028 年將有 13 億個智慧體。Agent 365 因此成為企業管理智慧體不可或缺的中樞。

Agent 365 五大能力

1. 統一資訊表
   管理所有 Agent 的真實狀態與來源。
2. 權限控管
   指定 Agent 能存取的資料範圍，符合企業合規需求。
3. 可視化監控儀表板
   即時觀察 Agent 行為與績效。
4. 互操作性
   支援第三方數據、應用與智慧體共同運作。
5. 安全防護
   偵測智慧體攻擊、監控漏洞、提供修復建議。

支援的智慧體生態包括 Adobe、Manus、SAP、ServiceNow、Workday 等大型合作夥伴。

五、Windows 與智慧體全面整合：專業 Agent 已接入

1. Ask Copilot：任務列上的 AI 中樞

透過 Windows 任務列即可：

• 搜尋檔案與設定
• 呼叫或監控智慧體（如 Researcher）
• 啟動第三方 Agent

2. Windows 365 for Agents：給 AI 的雲端 PC

開發者能在雲端 PC 上部署企業級 Agent，如：

• 在完整 Windows 環境中運作的 Copilot Studio
• 在 Linux 上運作的 Microsoft Researcher

3. 合作夥伴智能體生態加速擴張

包含 Manus、Fellou、GenSpark、Simular、Tinyfish 等領先 Agent 開發商都已採用 Windows 365 for Agents。

例如 Manus 透過 Windows 365 提供：

• 全球可用的安全運算資源
• 企業等級合規支援
• 可擴充的 AI Agent 部署模式

結語：智慧體生態全面展開，企業 AI 採用進入加速期

微軟此次更新展示了清晰方向：
未來的工作場域將由大量智慧體協作，而 Copilot 是連接這些智慧體的核心。

此外，微軟也推出：

• Microsoft Defender、Entra、Intune、Purview 的 12 個新安全 Agent
• Microsoft 365 Copilot Business（中小企業版，每人每月 21 美元，12 月起適用）

AI 不再只是工具，而是企業營運的新基礎。

在 AI 工具快速演進的時代，開發者越來越需要能兼具智慧、速度與可靠性的模型。OpenAI 最新推出的 GPT-5.1 正是為此而生：它在推理效率、程式碼生成、工具調用與長時間互動體驗上全面升級，為代理式（agentic）與開發者工作流程帶來大幅提升。

本文將帶你深入了解 GPT-5.1 的全新能力、實測效能、應用工具等資訊。

GPT-5.1 概覽：更快、更靈活、更聰明

GPT-5.1 是 GPT-5 系列的最新模型，特色在於：

• 自適應推理（Adaptive Reasoning）：依任務難度自動調整「思考時間」。
• No-Reasoning 模式：不需深度推理時可瞬間回應。
• 超長 Prompt 快取（Extended Prompt Caching）：快取保存長達 24 小時。
• 更強程式碼體驗：更自然、更可操控、更少過度思考。
• 新增 apply_patch 與 shell 工具：提升自動化開發流程。

高效推理：GPT-5.1 如何「越簡單越快、越難越深思」？

自適應推理（Adaptive Reasoning）

GPT-5.1 最大的突破之一是它能根據任務難度「調整思考力道」：

• 簡單任務 → 減少 token、加快速度
• 困難任務 → 增加推理深度、提高準確率

根據 Balyasny Asset Management 測試：

• GPT-5.1 速度比 GPT-5 快 2–3 倍
• 在工具密集型推理任務中，token 使用量比其他頂尖模型少 約 50%

Pace（AI 保險 BPO）也表示，他們的 AI 代理在 GPT-5.1 上運行速度快 50%，且準確度更高。

實例比較：查詢 npm 版本列表

新增 “No-Reasoning” 模式：極速任務的新利器

開發者可透過 reasoning_effort="none"，讓 GPT-5.1 以「無推理模式」運行：

• 適合低延遲、需快取回應的任務
• 工具調用速度比 GPT-5 minimal 快 20%（Sierra 實測）
• 更適合搜尋、簡單程式碼任務、平行工具調用

預設推理模式為 'none'，但若你有更複雜任務：

• 'low' or 'medium'：更複雜工作
• 'high'：優先智慧與穩定性

📌 延伸 Prompt 快取：長達 24 小時的上下文記憶

新版 prompt cache 讓 GPT-5.1 可保存快取長達：

24 小時（原本只有數分鐘）

優點包括：

• 更低延遲
• 長對話 / 長程式開發更順暢
• 成本更低（快取 token 依舊是 90% 折扣）

使用在回應 Response API 或聊天完成 Chat Completion API 中新增對應參數(參閱提示快取文件)：

"prompt_cache_retention": "24h"

程式開發更強大：GPT-5.1 的 Coding 升級

GPT-5.1 在程式語言理解與工程工作流上全面提升：

• 更自然的「開發者人格」
• 更少 overthinking
• 更準確的 patch 生成
• 前端設計能力變強
• 在低推理模式下表現依舊亮眼

在 SWE-bench Verified 測試中：

• GPT-5.1 達到 76.3%（領先 GPT-5 的 72.8%）

GPT-5.1 新工具：apply_patch 與 shell

1. apply_patch：更可靠的程式碼修改

透過結構化 diff，自動：

• 新增檔案
• 修改檔案
• 刪除檔案

不再需要 JSON escaping，支援多步驟程式碼調整流程。

將其包含在 tools 陣列中"tools"(參閱開發者文件)：

"tools": [{ "type": "apply_patch" }]

2. shell：讓模型能「在你的本機環境執行命令」

模型會產生 shell commands → 開發者執行 → 回傳結果 → 模型持續任務

將其包含在 tools 陣列中"tools"(參閱開發者文件)：

"tools": [{ "type": "shell" }]

shell可用性

GPT-5.1 所有可用模型：

• gpt-5.1
• gpt-5.1-chat-latest
• gpt-5.1-codex
• gpt-5.1-codex-mini

與 GPT-5 相同價格與 Rate Limit。

目前 尚未計畫下架 GPT-5，若未來要下架會提前通知。

未來展望：更智能、更自動化的 agentic 模型

OpenAI 表示將持續推出更強大的模型，聚焦：

• 高效推理
• 自動化工具操作
• 具備自主能力的 agentic 行為
• 更可靠程式碼生成
• 更適合長時間任務的運作模式

我們可以期待接下來幾個月會看到更多強化版模型推出。

附錄：模型評測數據

結語

GPT-5.1 不僅是速度加快的 GPT-5，更是一次推理思維、工具交互與程式工作流程的全面升級。無論你是想打造 AI 代理、開發智慧應用、管理大型程式庫，或優化你的開發者體驗，GPT-5.1 都是目前最強大且高效的選擇之一。

參考資料

• 原文：Introducing GPT-5.1 for developers

從「AI神話」回到現實世界的工作場景

近年來，生成式 AI 在各種研究基準（knowledge & reasoning benchmarks）上屢創佳績，但這些多為「受控環境下的學術題」—但實際進入真實工作環境後，並模擬真實工作任務的表現如何呢?
於是，2025 年由 Center for AI Safety 及 Scale AI 等多機構發表的研究中，提出了 RLI 基準：從自由職業實際市場出發，衡量 AI 在真實、端到端、具有經濟價值的工作任務上的自動化能力。
研究結果顯示：目前最強的 AI 模型在這些任務上的自動化率僅約 2.5%。

RLI 是什麼？真實世界的 AI「工作實測」

為何要建立新的基準？

過去的 AI 評測往往聚焦于快速解題、知識推理、或受限任務（如問答、摘要、程式修正），但真實遠端工作往往複雜得多：跨領域、長時間、多階段交付並含有互動、視覺、音頻等要素。論文指出：「AI 在研究型基準上進步神速，但仍不清楚這些進步如何轉化為經濟價值與真正的自動化。」
因此，RLI 的設計目標就是從真實商業自由職業案件中抽樣，涵蓋遊戲開發、產品設計、建築、資料分析、動畫製作等多個領域。研究指出：「這些專案的成本甚至超過 US$10,000，完成時間超過 100 小時。」

RLI 規模與構成

• 專案總工作量超過 6,000 小時，總商業價值逾 US$140,000。
• 涵蓋多達 23 個不同工作類別，來自真實自由職業平台的案件。
• 所有案件皆具備「專案簡報（brief）」「輸入檔案（input files）」「人類提交成果（human deliverable）」。
  這樣的設計讓 RLI 比過去許多偏「軟體／文字」的基準更加貼近真實市場。

RLI 資料集的建立流程：從 64 領域篩選到 240 個真實專案

研究團隊首先在 64 個職業領域中初步挑選，經篩選後鎖定 43 個符合條件的領域。
接著，他們招募了 358 名經驗豐富的自由職業者，這些受測者在 Upwork 平台平均工作時數已達 2,341 小時、完成專案數平均為 89 件，平均收入約為 US$23,364。
最終，從初始 550 件專案中篩選出 240 件符合標準的 RLI 專案。

評估 AI 的四大指標

RLI 不僅收集真實專案，也制定了「可量化」的評估指標：

1. 自動化率（Automation Rate）：AI 成功完成、達到人類交付標準的專案比例。
2. Elo 評分：採「配對比較」方式，AI 模型間相對勝負的量化分數，將人類基準設定為 1,000 點。
3. 專案收益（Dollars Earned）：AI 成功完成專案所代表的貨幣價值。
4. 自動化通縮（Autoflation）：若 AI 可替代人力，專案成本下降的比例。

為了衡量交付品質，研究人員還設計了手動評估平台，評估者從「合理客戶視角」檢驗 AI 成果是否符合專案 brief，並採三點量表檢判。

結果：AI 的真實表現只有 2.5%

研究對六款邊緣 AI 智能體進行測試，包括 GPT‑5、Claude Sonnet 4.5、Grok 4、Gemini 2.5 Pro、Manus 等。

• 最高自動化率為 Manus 約 2.5%。
• 其他模型如 Grok 4／Sonnet 4.5 約 2.1%；GPT-5 約 1.7%；ChatGPT Agent 約 1.3%；Gemini 2.5 Pro 約 0.8%。

換句話說，即使是最前緣的 AI，也只能完全獨立完成不到 3% 的真實自由職業專案。
Elo 評分雖然顯示模型間有進步，但「絕對完成專案」的能力仍然遠低於人類基準。

為什麼 AI 仍然未達「高度自動化及高工作完成度呢」？

透過對大約 400 份交付評估樣本的質性分析，論文指出主要原因包括：

1. 技術與檔案完整性問題：生成損毀檔案、格式錯誤、無法使用。
2. 交付成果不完整或關鍵缺漏：如缺少素材、影片截斷、未提供源檔。
3. 品質不足達專業水準：即便完成檔案，其細節粗糙、不能達客戶預期。
4. 一致性差：多檔案專案中，風格或結果間前後不一致。

這些皆反映了 AI 在「世界知識校驗」「記憶與持續性」「視覺／音頻互動驗證」等方面的不足——特別是在建築設計、遊戲開發與網站建構這類需強調交互、視覺、音頻驗證的專案中，瓶頸尤為明顯。

哪些領域 AI 表現較為亮眼？

雖然整體自動化率極低，但論文指出，AI 在創意性較強或工具化較好的任務中已展現相對優勢，如：

• 圖像／音頻生成任務：AI 工具生成宣傳素材、圖像或音頻型作品。
• 寫作、資料檢索／網頁爬蟲任務：AI 在文字與資訊檢索領域效率較高。
  這與模型目前在視覺生成、語言生成上較成熟的事實一致。例如，Sonnet 4.5 在簡單 Web 視覺化任務上的成果甚至被評為優於人類交付。
• 例如: GPT-5在閱讀/寫作/數學/知識也超越GPT-4模型

結論：AI 還遠不能100%完成人類的複雜工作

RLI 的研究為我們提供了一個「可量化」且貼近真實工作的基準。其結論清晰：即使是當前最先進的 AI，也僅能完成極少數具經濟價值的真實專案。
儘管 AI 在研究基準上的躍進迅速，但進入真實遠端工作市場後，依然存在明顯差距。主要障礙在於：自我校正能力弱、跨模態（視覺／音頻／互動）理解薄弱、長篇／多階段專案管理能力不佳。
因此，目前更合理的策略是將 AI 視為「強化人類能力」的工具，而非完全替代人類專業人士。

未來趨勢與實務建議

1. AI 作為「協作夥伴」而非替代者：專業人士與企業應聚焦在 AI 能提升效率、輔助創作、改善流程的場景，並非單純追求全面替代。
2. 強化資料真實性、驗證能力將成為關鍵突破點：未來若 AI 能夠自動偵測錯誤、修正檔案格式、跨模態驗證影片／互動效果，其於真實工作場景的應用才有機會大規模擴展。

參考資料

• Remote Labor Index 原始論文：https://www.remotelabor.ai/paper.pdf

原文：Han Lee – Claude Agent Skills: A First Principles Deep Dive

上篇我們理解了 Skill 的結構與撰寫方式；篇將以工程視角拆解 Skill 作為「Meta-tool」 的設計、兩段訊息注入機制、API 請求結構，以及從「發現 → 授權 → 注入 → 執行」的完整生命週期。讀完後，你將能以第一性原理理解為何 Skills 能做到「不執行程式碼、卻改變模型行為」。

內部架構：Skill 作為 Meta-tool

Skill（大寫 S） 是 Claude 的「元工具（Meta-tool）」。
它的任務是動態生成所有可用技能清單，再交給模型自行匹配。

核心特徵

• prompt 為動態生成：列出所有 skill 名稱與描述。
• 無外部分類器：由模型自行推論何時使用。
• Token 預算限制：每次清單上限約 15,000 字元，逼迫 skill 描述精簡。
• 獨立於 system prompt：存在於 tools 陣列中，而非全域系統指令。

Skills 物件設計：不是「直接執行」，而是「注入與改寫」

傳統工具（如 Read、Bash、Write）會直接執行並回傳結果；Skills 則不直接執行，而是做兩件事：

1. 將專用指示注入對話歷史（conversation context），透過完整提示改寫模型接下來的推理方式。
2. 動態修改執行環境（execution context），例如開放工具權限、切換模型、調整思考 token 參數等。

這個過程透過兩則使用者訊息完成：

• 一則是給使用者看的中繼資訊（可見、極短）。
• 另一則是給模型看的完整 skill 提示（隱藏於 UI）。

Normal Tool vs Skill Tool：設計差異

Skill 工具結構與動態描述生成

Pd = {
  name: "Skill",  // 工具名稱常數

  inputSchema: {
    command: string  // 例如 "pdf", "skill-creator"
  },

  outputSchema: {
    success: boolean,
    commandName: string
  },

  // 🔑 關鍵：動態產生 skills 列表（而非固定字串）
  prompt: async () => fN2(),

  // 驗證與執行
  validateInput: async (input, context) => { /* 五種錯誤碼 */ },
  checkPermissions: async (input, context) => { /* allow/deny/ask */ },
  call: async *(input, context) => { /* 產出訊息 + 修改執行上下文 */ }
}

為什麼要動態 prompt？

與固定描述的工具不同，Skill 工具會在執行時聚合所有 skills 的「名稱＋描述」，組成 <available_skills> 清單供模型判斷是否要呼叫某個 skill。
這就是漸進式揭露（Progressive Disclosure）：先提供最少的技能中繼資料，只有當模型選擇某個 skill 後，才載入其完整提示，避免上下文暴漲、同時維持可探索性。

async function fN2() {
  let A = await atA(),
    { modeCommands: B, limitedRegularCommands: Q } = vN2(A),
    G = [...B, ...Q].map((W) => W.userFacingName()).join(", ");
  l(`Skills and commands included in Skill tool: ${G}`);
  let Z = A.length - B.length,
    Y = nS6(B),
    J = aS6(Q, Z);
  return `Execute a skill within the main conversation

<skills_instructions>
...（使用說明與注意事項）
</skills_instructions>

<available_skills>
${Y}${J}
</available_skills>
`;
}

為何不放在 System Prompt？

有些系統（如某些助理）會把工具定義放在 system prompt。但 Claude 的 Skills 不這麼做，理由是：

• system prompt 具全域與持久影響，一旦放入就會「長駐」整段對話。
• Skills 需要暫時、具任務範疇（scoped）的行為。

因此，Skills 以 tools 陣列中的 Skill 工具描述出現；個別 skill 的名稱則是 Skill 的 input_schema.command 的取值。

API 請求實例

{
  "model": "claude-sonnet-4-5-20250929",
  "system": "You are Claude Code, Anthropic's official CLI...",
  "messages": [
    {"role": "user", "content": "Help me create a new skill"}
  ],
  "tools": [
    {
      "name": "Skill",
      "description": "Execute a skill...\n\n<skills_instructions>...\n\n<available_skills>\n...",
      "input_schema": {
        "type": "object",
        "properties": {
          "command": {
            "type": "string",
            "description": "The skill name (no arguments)"
          }
        }
      }
    },
    { "name": "Bash", "description": "Execute bash commands..." },
    { "name": "Read" }
  ]
}

<available_skills> 每次請求都重新生成，通常有約 15,000 字元的預算上限，迫使技能描述精煉、避免擠爆上下文。

兩段訊息注入設計：透明度 × 可讀性

為什麼需要兩段訊息？

• 若全部可見，UI 會被上千字的內部指令淹沒。
• 若全部隱藏，使用者又看不到系統正在做什麼。

解法：注入兩則訊息，各司其職——

1. 可見的中繼訊息（短、機器可解析的 XML），2) 不可見的完整提示（長、只送 API）。

可見的中繼訊息（isMeta: false）

let metadata = [
  `<command-message>${statusMessage}</command-message>`,
  `<command-name>${skillName}</command-name>`,
  args ? `<command-args>${args}</command-args>` : null
].filter(Boolean).join('\n');

messages.push({
  content: metadata,
  autocheckpoint: checkpointFlag
});

使用者會看到類似：

<command-message>The "pdf" skill is loading</command-message>
<command-name>pdf</command-name>
<command-args>report.pdf</command-args>

通常 50–200 字元，讓前端以特殊樣式呈現與審計紀錄。

隱藏的完整提示（isMeta: true）

let skillPrompt = await skill.getPromptForCommand(args, context);

let fullPrompt = prependContent.length || appendContent.length
  ? [...prependContent, ...appendContent, ...skillPrompt]
  : skillPrompt;

messages.push({
  content: fullPrompt,
  isMeta: true  // 隱藏於 UI，僅送 API
});

典型內容（500–5,000 字）：任務背景、流程步驟、可用工具、輸出格式、環境路徑等（如 PDF 專家流程）。

👉 圖片建議：左右對照圖「左＝簡短 XML 狀態」「右＝Markdown 長提示（標註 isMeta:true）」。

為何不能合併成一則？

兩者受眾不同、目的不同、處理管線不同：

• 可見訊息：給人看、要極簡、要能被 UI 解析。
• 隱藏訊息：給模型看、可冗長、免經 UI 驗證。
  合併會違反單一職責原則並汙染 UI／上下文。

訊息組合的擴充：附件與權限

除了兩段核心訊息，有時還會加入**附件（attachments）與權限設定（command_permissions）**訊息：

let allMessages = [
  createMessage({ content: metadata, autocheckpoint: flag }),   // 1. 可見中繼
  createMessage({ content: skillPrompt, isMeta: true }),        // 2. 隱藏長提示
  ...attachmentMessages,                                        // 3.（條件式）附件
  ...(allowedTools.length || skill.model ? [
    createPermissionsMessage({                                  // 4.（條件式）權限/模型
      type: "command_permissions",
      allowedTools: allowedTools,
      model: skill.useSmallFastModel ? getFastModel() : skill.model
    })
  ] : [])
];

• 附件：診斷資訊、檔案參考或補充上下文。
• 權限：當 frontmatter 指定 allowed-tools 或要求切換 model 時，才加入。
• 可視性：依需求決定是否顯示於 UI，但通常屬於機制性訊息。

案例：技能執行生命週期（以 pdf skill 為例）

Phase 1｜發現與載入（啟動時）

系統啟動會掃描所有來源的 skills，解析 SKILL.md 的 frontmatter 與內容，建立技能物件。

async function getAllCommands() {
  let [userCommands, skillsAndPlugins, pluginCommands, builtins] =
    await Promise.all([
      loadUserCommands(),
      loadSkills(),
      loadPluginCommands(),
      getBuiltinCommands()
    ]);
  return [...userCommands, ...skillsAndPlugins, ...pluginCommands, ...builtins]
    .filter(cmd => cmd.isEnabled());
}

針對外掛型 skills 的載入（略）後，會形成類似：

{
  "type": "prompt",
  "name": "pdf",
  "description": "Extract text from PDF documents (plugin:document-tools)",
  "whenToUse": "When user wants to extract or process text from PDF files",
  "allowedTools": ["Bash(pdftotext:*)", "Read", "Write"],
  "model": null,
  "isSkill": true,
  "disableModelInvocation": false,
  "promptContent": "You are a PDF processing specialist..."
}

Phase 2｜第 1 回合：使用者請求與 skill 選擇

使用者：「Extract text from report.pdf」。
系統先過濾可供 Skill 工具列出的 skills（需有 description 或 when_to_use）：

async function getSkillsForSkillTool() {
  const all = await getAllCommands();
  return all.filter(cmd =>
    cmd.type === "prompt" &&
    cmd.isSkill === true &&
    !cmd.disableModelInvocation &&
    (cmd.source !== "builtin" || cmd.isModeCommand === true) &&
    (cmd.hasUserSpecifiedDescription || cmd.whenToUse)
  );
}

接著格式化清單為 <available_skills>，模型讀取後以語義推論判斷 pdf 符合需求，於是呼叫 Skill 工具：

{
  "type": "tool_use",
  "name": "Skill",
  "input": { "command": "pdf" }
}

關鍵：沒有任何外部演算法在做分類／意圖偵測；純 LLM 推論。

Phase 3｜Skill 工具執行

1. 輸入驗證（是否存在、可否自動啟動、型別是否為 prompt 等）。
2. 權限檢查（deny/allow 規則；預設 ask 由使用者確認）。
3. 載入 Skill 檔並產生兩段訊息；必要時加入權限／模型覆寫。
4. 回傳 contextModifier，在後續回合自動預核准工具或切換模型。

yield {
  type: "result",
  data: { success: true, commandName: skillName },
  newMessages: messages,
  contextModifier(context) {
    // 預先開放 allowedTools
    // 覆蓋 mainLoopModel（若指定）
    return modified;
  }
};

Phase 4｜送交 API（第 1 回合完成）

{
  "model": "claude-sonnet-4-5-20250929",
  "messages": [
    { "role": "user", "content": "Extract text from report.pdf" },
    { "role": "assistant", "content": [{ "type": "tool_use", "name": "Skill", "input": { "command": "pdf" } }]},
    { "role": "user", "content": "<command-message>The \"pdf\" skill is loading</command-message>\n<command-name>pdf</command-name>" },
    { "role": "user", "content": "You are a PDF processing specialist...\n## Process\n1. Validate PDF exists\n2. Run pdftotext...", "isMeta": true },
    { "role": "user", "content": { "type": "command_permissions", "allowedTools": ["Bash(pdftotext:*)", "Read", "Write"], "model": null } }
  ]
}

此時，對話上下文（長提示）與執行上下文（工具白名單／模型）都已就緒，但尚未真正做事。

Phase 5｜工具執行（在 skill 上下文中）

Claude 於下一回合依據已注入的提示執行：

1. 檢查 report.pdf 是否存在
2. 呼叫 Bash：pdftotext report.pdf output.txt
3. 用 Read 讀取 output.txt
4. 將結果呈現給使用者

{
  "type": "tool_use",
  "name": "Bash",
  "input": {
    "command": "pdftotext report.pdf output.txt",
    "description": "Extract text from PDF using pdftotext"
  }
}

差別在於：Bash、Read、Write 已被預先允許，不需再次徵求同意，流程順暢完成。

心智模型回顧（Key Takeaways）

• Skills 是 SKILL.md 的提示模板，不是可執行程式。
• Skill（大寫 S）是 tools 陣列裡的 Meta-tool，不是 system prompt 的一部分。
• 對話上下文透過 isMeta:true 的訊息注入；執行上下文則調整工具許可與模型選擇。
• 選擇使用哪個 skill，由 LLM 讀描述後自行推論，非演算法匹配。
• 工具權限具範疇性：在技能執行期間預先允許，任務後環境恢復。
• 兩段訊息同時滿足透明度（人類可見）與可操作性（模型可用）。

結語：以「提示×權限」取代「程式×函式」

將專業知識「提示化」並以一則 Meta-tool 管理其範疇化的權限與模型，讓 Claude 得以在安全、可控、可組合的框架下完成複雜任務。
這種設計避免了工具爆炸與系統提示臃腫，同時保留 LLM 的語義彈性——這，就是 Agent Skills 的優雅之處。

參考資料

• 原文：Han Lee – Claude Agent Skills: A First Principles Deep Dive

原文：Han Lee – Claude Agent Skills: A First Principles Deep Dive

在大型語言模型（LLM）的快速演進中，Anthropic 的 Claude 系列以強調安全性與可控性著稱。而在 Claude 的整個架構中，「Agent Skills 系統」是最值得技術人員深入研究的一環。它並非傳統意義上的外掛（plugin）或工具呼叫，而是一種以提示（prompt）為核心的元工具機制，能讓模型在不同任務中切換「思考模式」，達到專業化與模組化的效果。

本文將從第一性原理出發，完整解析 Claude 的 Agent Skills 架構與運作邏輯，並以實際案例（如 skill-creator 與 internal-comms）說明技能的建立、載入、與決策過程。

什麼是 Claude Agent Skills

Skills 是什麼？
它不是函式呼叫、不是伺服器、也不是可執行程式。Skill 是一個結構化的提示模板，在被呼叫時會把 領域專屬的指示 注入到對話上下文中，並可同時改變執行上下文（如：開啟哪些工具權限、切換模型）。

Skill 的存放位置
Skill 以資料夾為單位，內含 SKILL.md（核心提示）、以及可選的 scripts/、references/、assets/。它們不會被硬寫進系統提示（system prompt），而是透過一個名為 Skill（大寫 S） 的「元工具（meta-tool）」動態管理。

誰做決策？
不是外部程式碼在做意圖分類，也沒有 embeddings 或關鍵字比對。是 LLM 本身在閱讀 Skill 列表的文字描述後，用語言理解自行決定是否要用哪個 Skill。這一切都發生在模型的前向推論之中。

Skills 與傳統工具的差異：

重點心智模型：
工具會「做事」，Skills會「讓模型準備好、以專家方法來做事」。Skills 調整的是模型的行為策略與權限環境。

從實例看 Skill 的構成：以 skill-creator 為例

關鍵洞見：
Skill = 提示模板 + 對話上下文注入 + 執行上下文修改 +（可選）資料與腳本

Skill 會被 Claude Code 從多處載入：使用者設定（~/.config/claude/skills/）、專案資料夾（.claude/skills/）、外掛提供的 skills、以及內建 skills。以 Claude Desktop，也可直接上傳自訂 Skill。

漸進式揭露（Progressive Disclosure）是核心設計哲學

1. 先只曝光前言（frontmatter）：名稱與描述足夠讓 LLM 決定是否選用。
2. 選中後再展開 SKILL.md：提供完整但聚焦的指示。
3. 需要時才載入腳本與參考資料：把冗長內容拆到外部檔案，避免上下文暴漲。

🔍 沒有 /references 或 /assets 目錄，顯示該技能以提示為主體、腳本為輔。

SKILL.md：前言區（Frontmatter）與提示內容（Content）

SKILL.md 由兩部分組成：

Frontmatter

• name（必填）：Skill 名稱，也是 Skill 工具的 command。
• description（必填）：最關鍵訊號，LLM 靠它判斷何時使用此 Skill。建議用動作導向語言（「當使用者想要…時使用」）。
• license（選填）：授權說明。
• allowed-tools（選填）：預先開放的工具白名單。可用萬用字元或限定子命令。務必最小化權限。
  • 範例：
    • allowed-tools: "Read,Write,Bash,Glob,Grep,Edit"（skill-creator）
    • allowed-tools: "Bash(git status:*),Bash(git diff:*),Read,Grep"
    • ✅ 僅列必要工具；❌ 不要貪心全開，破壞安全模型。
• model（選填）：可指定特定模型，預設 inherit（沿用當前會話）。
• version（選填）：純記錄用途。
• disable-model-invocation（選填）：若 true，不會被自動列入給 LLM 的可用清單，只能用手動指令（如 /skill-name）啟動。
• mode（選填）：若 true，此 Skill 被視為「模式指令」，會在清單上方以「Mode Commands」區塊凸顯（如 debug-mode、expert-mode）。

關於 when_to_use（未文件化、可能已棄用或尚未公開）

程式碼中可見 when_to_use 被附加到 description 後方以加強語意，但 官方未文件化，行為可能變動。實務建議：把使用時機直接寫進 description，避免依賴未公布欄位。

SKILL.md提示內容

實務守則

• 盡量小於 5,000 字，避免淹沒上下文。
• 用 祈使句（「分析…」、「執行…」），不要用「你應該…」。
• 把冗長清單、範例、模板拆到外部檔案，用 {baseDir} 引用路徑，不要寫死絕對路徑。
  • ✅ Read {baseDir}/config.json
  • ❌ Read /home/user/project/config.json

與資源打包：scripts/／references/／assets

專案結構建議：

my-skill/
├── SKILL.md
├── scripts/      # 可執行腳本（Python/Bash）
├── references/   # 文字型參考資料（會讀入上下文）
└── assets/       # 模板與二進位資源（僅路徑引用，不讀入）

• scripts/：交給 Bash 工具執行的自動化腳本（如 init_skill.py）。適合多步驟、決定性邏輯或資料處理。
• references/：會被 Read 載入上下文的文件（規範、樣式指南、Schema 等）。
• assets/：只用路徑引用、不讀入上下文（HTML 模板、圖片、字型）。避免浪費 token。

常見設計樣式（Patterns）與進階工作流

Pattern 1：Script Automation（腳本自動化）

使用場景：需要多個指令或確定性邏輯的複雜操作。
這種模式將計算任務卸載到scripts/目錄中的 Python 或 Bash 腳本中。技能提示符號指示 Claude 執行腳本並處理其輸出。

SKILL.md 例：

Run scripts/analyzer.py on the target directory:

`python {baseDir}/scripts/analyzer.py --path "$USER_PATH" --output report.json`

Parse the generated `report.json` and present findings.

所需工具：

allowed-tools: "Bash(python {baseDir}/scripts/*:*), Read, Write"

Pattern 2：Read – Process – Write

情境：檔案轉換、格式清理、報表輸出。
最簡單的模式－讀取輸入，依照指令轉換，寫入輸出。適用於格式轉換、資料清理或報告產生。

SKILL.md 例：

## Processing Workflow
1. Read input file using Read tool
2. Parse content according to format
3. Transform data following specifications
4. Write output using Write tool
5. Report completion with summary

所需工具：

allowed-tools: "Read, Write"

Pattern 3：Search – Analyze – Report

情境：程式碼安全檢查、巨量資料模式搜尋。
使用 Grep 在程式碼庫中搜尋模式，讀取符合的檔案以取得上下文，分析結果，並產生結構化報告。或者，在企業數據儲存中搜尋數據，分析檢索到的數據以獲取信息，並產生結構化報告。

SKILL.md 例：

## Analysis Process
1. Use Grep to find relevant code patterns
2. Read each matched file
3. Analyze for vulnerabilities
4. Generate structured report

所需工具：

allowed-tools: "Grep, Read"

Pattern 4：Command Chain Execution

情境：具有依賴關係的多步驟操作。
執行一系列命令，其中每一步都依賴前一步的成功。這在類似 CI/CD 的工作流程中很常見。

SKILL.md 例：

Execute analysis pipeline:
npm install && npm run lint && npm test

Report results from each stage.

所需工具：

allowed-tools: "Bash(npm install:*), Bash(npm run:*), Read"

進階工作流

Wizard-style 多步驟嚮導

使用場景：每步驟向使用者確認後再前進。

SKILL.md 例：

## Workflow

### Step 1: Initial Setup
1. Ask user for project type
2. Validate prerequisites exist
3. Create base configuration
Wait for user confirmation before proceeding.

### Step 2: Configuration
1. Present configuration options
2. Ask user to choose settings
3. Generate config file
Wait for user confirmation before proceeding.

### Step 3: Initialization
1. Run initialization scripts
2. Verify setup successful
3. Report results

Template-based 產生

使用場景：從 assets/ 讀模板、填入欄位、輸出成品。

SKILL.md 例：

## Generation Process
1. Read template from {baseDir}/assets/template.html
2. Parse user requirements
3. Fill template placeholders:
   -  → user-provided name
   -  → generated summary
   -  → current date
4. Write filled template to output file
5. Report completion

Iterative Refinement

使用場景：先廣掃後深挖，再產出修正建議與工時估計。

SKILL.md 例：

## Iterative Analysis

### Pass 1: Broad Scan
1. Search entire codebase for patterns
2. Identify high-level issues
3. Categorize findings

### Pass 2: Deep Analysis
For each high-level issue:
1. Read full file context
2. Analyze root cause
3. Determine severity

### Pass 3: Recommendation
For each finding:
1. Research best practices
2. Generate specific fix
3. Estimate effort

Present final report with all findings and recommendations.

Context Aggregation

使用場景：聚合多來源（README、package、git、grep）成整體視圖。

SKILL.md 例：

## Context Gathering
1. Read project README.md for overview
2. Analyze package.json for dependencies
3. Grep codebase for specific patterns
4. Check git history for recent changes
5. Synthesize findings into coherent summary

到這裡，我們已了解 Skills 是如何被設計、撰寫與打包的：
它不是外部程式，而是能讓 Claude 暫時「切換人格」的提示容器。
由於原文資料太多可以分享我們將分成上下兩篇來介紹，在下一篇中，我們將深入探討 Skills 在內部如何被載入、解析與執行——包括 Skill 工具（meta-tool）的 API 結構、兩段訊息注入設計，以及完整的執行生命週期，對原文有興趣也可前往原文觀看，我們下次見~~

參考資料

• 原文：Han Lee – Claude Agent Skills: A First Principles Deep Dive

AI 正從「單體巨腦」邁向「專家協作網路」

初次與 GPT-5 對話時，許多開發者都會察覺到一個微妙的變化——它不只是回答問題，而是在選擇如何回答。
在 GPT-5 背後，運行著一個名為 Router（路由器） 的智慧調度核心。這個模組會根據任務性質與需求，將請求分派給最合適的「大腦」：

• 輕量核心模型：處理快速事實查詢與摘要任務。
• Thinking 思考推理模型：專責邏輯推理與複雜問題。
• 工具整合層：當需要計算或檢索外部資料時，路由器會自動呼叫相關工具。

這項變革的意義不僅在於效能提升，更代表 AI 架構正從「單一模型」邁向「多智能體協同」的新典範。

一、為什麼路由機制成為 GPT-5 的關鍵？

在 GPT-4 時代，無論使用者要寫詩、除錯或查拼字，系統都必須啟動同一個大型模型——這就像用火箭引擎烤麵包。雖然可行，但既耗能又不必要。

GPT-5 引入的路由機制徹底改變這種模式。它會在收到請求後即時分析內容，根據任務性質選擇合適模型：

如此一來，AI 不再為簡單任務動用龐大模型，提升效率並降低資源浪費。

二、GPT-5 路由決策的四大支柱

GPT-5 的路由器在決定使用哪個模型時，主要根據以下四個因素運作：

1️⃣ 對話類型（Conversation Type）

系統會先判斷任務屬性——是閒聊、程式審查、數學推導，還是故事撰寫？
例如：

• 「週末要去哪玩？」→ 啟動快速模式。
• 「請逐步推導這個定理」→ 切換至深度思考模式。

2️⃣ 任務複雜度（Task Complexity）

路由器能解析提示詞的難度信號。若問題包含多步邏輯或抽象概念，會自動啟用高推理模型。
根據 AIMultiple 的分析，GPT-5 採用混合多模型架構，根據提示複雜度與反應需求動態分派運算資源。

3️⃣ 工具需求（Tool Needs）

出現「計算」、「查詢」、「寫信」等指令時，路由器會調用內建工具或 API 模型。
不同於早期 ChatGPT 插件需手動啟用，如今這些過程已完全自動化。測試顯示，GPT-5 的工具誤調率較 GPT-4 減少近 50%。

4️⃣ 使用者意圖（Explicit Intent）

GPT-5 能讀懂語意細節——輸入「請深入分析」時，系統會自動切換到 Thinking 模式；輸入「請快速總結」則啟用快速模式。
這種「軟指令層（Soft Instruction Layer）」讓自然語言成為模型決策的一部分。

三、超越 Toolformer 與傳統插件：動態決策的時代

2023 年的 Toolformer 模型曾讓 LLM 學會在訓練中自行調用外部工具，但這仍是靜態學習。
GPT-5 的路由機制則屬於動態決策引擎：它能在運行時即時判斷是否啟用工具。

同樣，ChatGPT 舊版插件需要手動開啟，GPT-5 則以策略層取代手動操作，讓工具調用在背景自動完成。
因此，GPT-5 可被視為 Toolformer 的自主性 + ChatGPT 插件的生態系 + 即時路由指揮官 的融合體。

四、GPT-5 路由架構的四大優勢

效率與速度

• 輕量模型處理日常任務，節省大量算力。
• 在多項基準測試中，GPT-5 的回應速度比 GPT-4 Turbo 快 2–3 倍。
• 當負載過高時，mini 模型會自動接手低優先任務。

模組化與可解釋性

• 每個子模型功能明確，可獨立升級。
• 錯誤診斷更清晰：是路由選錯，還是推理出錯。
• 架構類似微服務（Microservice），更易維護與擴充。

專業化輸出

• 子模型針對特定任務優化（如 reasoning、summarization）。
• 支援對話中無縫切換模式，體驗更流暢。

彈性控制

• 使用者可手動切換「Fast / Thinking」模式，兼顧效率與深度。

五、潛在挑戰與技術瓶頸

• 除錯困難：需追蹤多層決策紀錄，類似分散式系統除錯。
• 延遲疊加：多層推理鏈會增加反應時間。
• 成本與能耗：多個小模型並行可能比單一大模型耗資更多。
• 語氣一致性問題：不同子模型風格需透過人格濾鏡統一。
• 路由誤判風險：分派錯誤會導致回答深度不符。

緩解方式包括：平行執行（Parallel Calls）、結果快取（Caching） 與 強化學習式路由訓練。

六、AI 的新方向：從單體智能到多智能體協作

GPT-5 的「Router + Multi-Model」架構揭示了 AI 正在邁向 模組化與多智能體化（Agentic AI）。
未來的 AI 不再依賴單一模型，而是由多個專家模型組成的協作網路。

部分研究團隊已在測試「百專家模型（100-Expert LLMs）」，以中央控制器協調數十個子模型。
隨著硬體演進，這種協作成本將不斷下降，並最終取代傳統「一體式模型」設計。

結語：AI 的「協作智能」時代正式啟動

GPT-5 的即時路由機制讓 AI 從「孤立天才」轉變為「專家合奏」。
它帶來效率與精度的雙重提升，也提出新的挑戰：如何讓所有模組協同一致、維持對話流暢。

從技術角度看，這不僅是一項工程創新，更是一場設計哲學革命。
未來的 AI 將學會「如何選擇思考方式」，而非僅僅「思考本身」。

專業建議與趨勢

1. 導入智能路由概念
   新創團隊在設計 LLM 應用時，應先規劃任務分類與分派邏輯，而非單純追求更大模型。
2. 強化可觀測性（Observability）
   建立清晰的決策追蹤鏈（Decision Trace），方便除錯與模型監控。
3. 保持人格一致性
   為多模型協作系統設計統一語氣與風格層，確保使用者體驗連貫。

原文：https://bhavishyapandit9.substack.com/p/gpt5-router-a-deep-dive