Claude（以及大多數主流 AI 對話工具）之所以會在對話進行到一半時突然被打斷、要求你「開新對話」或「總結一下再繼續」，核心原因是每一次對話都受限於一個叫做 Context Window（上下文視窗）的容量上限——這個上限以 Token（詞元）為計算單位，一旦當前對話累積的 Token 數（包含你打的字、AI 的回覆、以及你上傳的文件內容）逼近或超過這個上限，系統就必須開始「忘記」較早的內容，或直接提示你另開對話。這不是 Claude 特有的怪癖，而是所有主流大型語言模型共通的技術限制。這篇文章會拆解 Token 上限實際運作的方式、為什麼對話會在你毫無防備時被打斷，以及幾個常見、有邏輯依據的因應方向——但這裡要先說在前面：坊間流傳「貼上這段文字，從此不再卡 Token 上限」這類說法，通常誇大了單一 prompt 能解決的問題範圍，本文不會提供、也不會背書任何號稱「貼上就一勞永逸」的萬能文字。 Token 上限（Context Window）到底是什麼？為什麼對話久了會被打斷 Token 是 AI 模型處理文字的最小計算單位，大致可以理解成

「Software Factories」（軟體工廠）是 2026 年 6 月底、7 月初在舊金山舉行的 AI Engineer World's Fair 2026 大會主題，指的是「把整個軟體開發生命週期，交給 AI 代理自主執行的迴圈化流程」這個正在成形中的產業共識。這場大會的主題演講合輯，找來 Microsoft、OpenAI、開源陣營的 Z.ai（GLM）與 MiniMax、以及 Hugging Face 等多方代表，各自用自己的產品語言詮釋「軟體工廠」該長什麼樣子。表面上大家都在講「用 AI 代理自動化開發流程」，但仔細拆開每家公司的論點，會發現彼此對「工廠裡誰負責什麼」「開源還是閉源」這些問題，其實各自站在不同位置。這篇文章不做誰對誰錯的評判，而是把幾個關鍵爭點攤開，讓正在評估 AI 開發代理平台的企業與開發者，看清楚自己在挑的到底是什麼。 這場論戰的起點：AI Engineer World's Fair 2026 與「Software Factories」是什麼 AI Engineer World's Fair 2026 於 2026

這起事件的核心事實是：AI 開源社群平台 Hugging Face 於近期公開表示，遭遇一起由 AI Agent（代理型 AI）主導的網路攻擊，攻擊者透過資料處理管道入侵系統、建立臨時沙箱環境執行攻擊計畫，Hugging Face 團隊在事件應對過程中，甚至因為美系主流商用模型的安全護欄機制拒絕分析可疑程式碼，而改用中國開源模型 Z.ai GLM 5.2 來協助拆解攻擊痕跡。這件事之所以值得台灣企業認真看待，不是因為它有多聳動，而是因為它把「AI Agent 可能被拿來自動化攻擊」這個過去偏向理論推演的風險，變成一起有具名企業、有 CEO 公開發言、有可查證新聞報導佐證的真實案例。以下用 Fortune 於 2026-07-20 的原始報導為唯一事實依據，拆解這起事件實際發生了什麼、哪些說法仍在調查中，以及它對正在評估導入 AI Agent 的企業，代表什麼樣的治理提醒。 事件本體：Hugging Face 遭遇了什麼樣的攻擊 根據 Fortune 的報導，攻擊者透過 Hugging Face 的資料處理管道（data processing...

ChatGPT Work 是 OpenAI 在 2026 年 7 月發表的企業／團隊向 AI Agent 產品，由 Codex 與 GPT-5.6 共同驅動，重點不是「回答問題更聰明」，而是「能讀懂團隊正在進行的工作情境，並跨工具、跨檔案、跨桌面應用自動把任務做完」。簡單說，你平常用的 ChatGPT 是你問、它答，成品要自己動手整理；ChatGPT Work 則是把團隊已經存在的筆記、草稿、待辦想法當作背景知識，自己規劃步驟，直接在你電腦裡把試算表、文件、簡報這類成品做出來。這篇文章會把 OpenAI 這場發表會的幾個關鍵宣稱拆開來看，說明每一項對台灣企業與開發者實際代表什麼，而不是逐句複述發表會內容。 ChatGPT Work 是什麼？跟你平常用的 ChatGPT 差在哪 先把最容易搞混的地方講清楚。一般 ChatGPT（不管是網頁版、App 還是加購方案）本質上是一問一答的助理：你把問題或素材丟進對話框，它給你答案或草稿，剩下的整理、彙整、跨檔案比對，都是你自己動手完成。ChatGPT Work 定位不同——它是一個會「主動規劃並執行」的.

Context engineering（情境工程）是讓 AI 模型理解「你的企業」而不只是理解「全世界公開知識」的治理工程，做法是把對的資料、對的權限設計、對的稽核機制接上模型，讓輸出不只是聽起來有道理，而是真的可以被信任、被追蹤、被究責。這個概念之所以突然重要，是因為企業 AI 已從「回答問題」走到「自己做決定、自己採取行動」的階段。AI 只是生成文字時，答錯了頂多是困擾；但當 AI Agent 能觸發流程、存取客戶資料、直接執行操作，一次錯誤就可能變成營運風險、法遵曝險或資安事故。這篇文章整理一段科技媒體人與企業科技主管的訪談重點，聚焦「治理層」——誰能存取什麼、出錯後誰負責、企業導入 AI Agent 前該先打好哪些地基，而不是把訪談內容當成單一廠商的產品介紹來讀。 為什麼「換一個更強大的模型」解決不了問題 企業軟體是一層一層疊上去的：資料層、情境層、應用邏輯層、使用者體驗層，每一層都經過長時間磨合才穩定。AI 的特別之處在於，它幾乎同時衝擊每一層。很多組織以為把夠強的模型接進既有系統就能自動生出成果，結果發現原本小心維護的資料流程、跟不上

MCP（Model Context Protocol，模型上下文協定）是一套讓 AI 模型自己「發現」並使用外部工具的標準化協定，跟傳統 API 最大的差異在於：API 是寫給程式對程式溝通用的固定契約，而 MCP 是寫給模型讀的、可以動態理解「這個工具能做什麼」的說明書。這個差異聽起來像是工程師才需要在意的架構選擇，但它其實直接牽動一件企業愈來愈在意的事——AI Agent 每執行一次任務，要燒掉多少 Token。這篇文章會從「傳統 API 為什麼讓 AI Agent 變貴」出發，拆解 MCP 想解決的問題，以及這對正在評估 AI Agent 工具的企業採購決策，意味著什麼。 傳統 API 為什麼「餵不飽」AI Agent？ API 存在了幾十年，一直是系統與系統之間的通用握手方式：你定義一個端點（endpoint），送出一個請求，拿到一個回應，乾淨、可預期。對傳統軟體來說，這套邏輯完全夠用。但當大型語言模型進到這個場景，情況變得不一樣了。模型不會只呼叫一個端點就結束，它可能要串接十個端點、把它們串在一起、還要解讀不結構化的資料，甚至根據前一步