近年企業引入生成式 AI，早已不缺能回答問題的工具。無論是 ChatGPT、Gemini、Copilot，還是企業自建的 Agent，都能勝任檔案摘要、數據分析與內容生成。然而當 AI 真正進入日常工作，問題便隨之浮現：AI 雖然聰明，卻未必知道你正在做甚麼。
員工每天的工作脈絡，往往散落在 Outlook、Slack、Teams、Salesforce、SAP、Google Drive、Excel 以及各種本機檔案與項目管理工具中。每次想請 AI 協助，依然得自己先翻找資料、補充前因後果、上傳檔案，再手動告訴它事情的來龍去脈。
AWS 推出 Amazon Quick Desktop，正是處理這種問題。Quick Desktop 目前已在 macOS 與 Windows 推出，並於 iOS 及 Android 推出全新 Activity Feed。AWS 對它的定位已超越傳統 Chatbot，期望打造一套能讀取工作上下文、跨系統執行任務，並讓 Agent 在背景持續運作的企業級 AI 助手。
在 AWS 香港傳媒簡報會中，大中華區合作夥伴解決方案架構師主管 Dickson Yue 將企業引入 AI 的 4 大瓶頸歸納為：數據分散於不同系統、員工需頻繁切換應用程式、離開電腦後難以持續管理 Agent 任務，以及消費級 AI 缺乏企業級權限與資產管理。
因此 Quick Desktop 最值得關注的，是 AWS 嘗試在企業現有工具之上，建立一層可理解及串連工作 Context 的 AI 介面，而非多了一個大模型選項。
先解決「AI 不知道你正在做甚麼」
典型企業流程很少侷限於單一 App。以銷售主管準備客戶會議為例：需求來自 Outlook 信件，最新討論在 Slack，歷史紀錄存於 Salesforce，訂單數據在 SAP，最終報價單卻又存在桌面的 Excel 裡。過去即使每套軟件都內建 AI，真正串連這些資訊的依然是員工自己。
AWS 在香港簡報中表示，Quick 可透過原生及第三方整合接通逾 1,000 款應用程式（現場列出的例子包括 Teams、Zoom、Gmail、Outlook、Slack、Microsoft 365、Salesforce 及 SAP 等）。官方資料亦確認，目前提供逾 100 款預建 Action Connector，並可透過 REST API、OpenAPI、MCP 等方式延伸至其他企業系統。
Desktop App 更進一步將本機資料納入 AI 可存取的工作 Context。企業可指定授權 Quick 存取特定資料夾，讓它直接搜尋、讀取與處理當中的檔案，無需每次把 PDF 或 Word 檔案重新上傳到一個新的 Chat Session。桌面版亦整合了本機 Browser Automation、本機 Code Execution，以及企業自行配置的 MCP Server。
這意味著 Quick 想解決 AI 能否理解這份檔案與哪一個客戶、哪次會議、哪封 Email，以及哪個正在進行的項目有關，而非單純「AI 能否讀懂這份檔案」。
Personal Knowledge Graph：建立個人的工作知識脈絡
一般 AI Memory 大多僅止於記憶使用者偏好或過往對話；Quick 則更進一步，將工作環境中的人物、項目、公司、事件、檔案、通訊、行動與決策建立關係。系統會從已連接的應用程式與獲授權的本機檔案中抽取這些 Entity，再建立彼此的關聯，而且 Knowledge Graph 是每名用戶獨立建立的。
以一個產品發布項目為例：3 星期前在 Teams 開會、2 星期前收到客戶 Email、昨日 Slack 再有工程部更新，以及今日日曆上的決策會議。在傳統搜尋中，這些只是幾筆獨立資訊；Knowledge Graph 則嘗試理解它們其實屬於同一件工作的不同階段。
Dickson Yue 在現場亦把這種個人化記憶及工作脈絡管理，列為 Quick 與一般 AI 工具的重要差異。當 AI 真正掌握「你是誰、你在做甚麼、誰與這件事有關、之前發生過甚麼」，員工才不用每一次工作都由零開始重新解釋 Context。
Activity Feed：從資訊海中過濾出「需要你決策的事」
這種 Context 亦被用在另一項新功能 Activity Feed。現時大部分企業工具的設計邏輯是「有新東西就通知你」，結果員工一天可能面對數十封 Email、Slack 訊息、日曆提醒與 CRM 更新，真正重要的事情反而埋在大量資訊之中。
Quick 採取相反方向。Activity Feed 將來自 Email、Messaging、Calendar 及其他已連接服務的資訊放到同一畫面，再根據 Knowledge Graph 掌握的脈絡判斷優先次序。AWS 將內容分為 Important、Informational 及 Low Priority，並可直接提供下一步 Action。
另一點值得注意，已處理、過期或不再需要用戶跟進的事項，會逐步從 Feed 中移除。官方強調這個 Feed 應該隨着工作完成而愈來愈短，而不是像一般 Inbox 一樣愈積愈多。
對管理層而言，它要解決的是把大量通知整理成真正需要人判斷的待辦事項，而非只是少開幾個 App。
Skills：將資深員工的 Know-how 轉化為企業 AI 資產
另一個對企業比普通 Prompt 更有價值的功能是 Skills。Skill 可以理解為一套可重用的工作方法。假設企業每星期都要製作競爭對手報告，以往每次都要重新告訴 AI：先找哪些來源、如何分類、哪些數據一定要核實、報告採用甚麼格式。Quick 可以把這整套做法保存成一個 Skill。AWS 官方將其定義為一套可重用的 Instructions，包含多步工作流程、工具及參考檔案；建立後可發布和分享給同一組織的其他用戶。
真正有價值的企業知識，很多時候是在資深員工腦內。如果這些 Know-how 可以逐步變成 Skill，AI 的價值便由「每個員工自己學 Prompt Engineering」，走向把個人工作方法變成可以分享、更新和管治的企業 AI 資產。
異步工作模式：下班後繼續運行的 Cloud Agent
Quick Desktop 的另一個關鍵改變，是 Agent 不一定要跟着人的 Session 一同結束。Quick 的 Routine 可以按時間自動執行 Agent，例如每天早上整理未讀訊息、每星期搜尋競爭對手消息，或者定期產生 Project Report。這些 Routine 在 Cloud 執行，因此即使 Desktop App 已關閉甚至電腦關機，Agent 仍可以按時間工作，再把結果送到 Activity Feed。
不過這裏有一個重要限制。如果某個步驟需要讀取電腦本機檔案、使用本機 Browser Automation 或執行 Local Code，電腦仍需要保持開啟及連線；真正完全不依賴電腦的，是在 Cloud 執行的 Agent 工作。這讓工作方式由傳統同步 Chat，逐漸變成 Asynchronous Work（異步工作）。
現場實試體驗：評價標準應從「回答速度」轉為「人工時間節省了多少」
在 AWS 安排的 mini workshop 中，AWS 資深生成式人工智能市場拓展專家 Terence Chow 先以自己的日常工作示範 Quick Desktop。他未有逐一打開電郵、Slack、日曆及文件翻找資料，而是直接讓 Quick 從已連接的工作資訊中整理當日事項、相關人物、文件及下一步行動。Terence 亦展示 Quick 如何利用 Knowledge Graph 把不同時間出現的會議、訊息、人物及文件串連起來：例如準備一場活動時，Quick 可從相關 Slack 訊息、Excel 名單及過往討論中整理資料，再據此建議 Demo 內容。他亦將這套邏輯延伸至傳媒工作流程，示範由尋找熱門題材、切入角度、資料搜集到協助內容製作。
到傳媒即場實試時，Quick 預先提供了一套「搵料」Skill，讓使用者輸入研究題目後，按既定方法拆解任務。今次操作中，它不是直接生成一個答案，而是將研究需求拆成多個 Sub-task，搜尋不同來源，再逐步整理重點、風險及值得跟進的問題。使用者更可即場修改 Skill，將自己慣用的資料搜集邏輯、格式要求乃至 Fact-check 流程保存下來，方便日後重複使用或分享給團隊。
短時間試用後，一個很明顯的感受是：使用 Agent 後，不能再單純用 Chatbot 的回應速度來衡量效率。Quick 執行較完整的 Research 時，需要拆解工作、搜尋不同來源並整合結果，部分 Report 明顯要等候較長時間；但假設一項原本需要人手搜尋、整理與比對大量資料的工作，能交由 Agent 在背景處理，而員工期間可專注於其他工作，那麼等候數分鐘本身未必代表效率較低。對企業而言，更值得量度的 KPI，或許不再只是 First Token Latency，而是整項工作到底節省了多少 Human Time Saved。
▲現場再叫他自行編寫一套「去中文 AI 味」的 Skill ，我覺得他參考了現行的 GitHub 的 Humanize Skill ，兩者的 rules 都非常相近。我覺的 Quick 的原生廣東話口語算是表現不錯，作個人簡單報告尚算自然，但若要 output 文書信件，這套 skill 雖然可以改善一些 AI 特定重覆的文句格式，但仍比不上有用上中文文章訓練的模型。
Mission Control：Agent 愈多，企業愈需要統一管理與權限控制
當企業由一個 Chatbot 走向幾十個 Agent，誰知道它們正在做甚麼？Quick Desktop 為此提供 Mission Control，可集中查看所有 Agent 的執行情況、完成結果、需要人工介入的任務，以及不同 Routine 的運行情況。管理者亦可以查看 Run History、暫停或取消工作，以及在 Agent 操作第三方系統時審批授權。
在安全架構上，企業不能簡單理解為「裝了 Desktop App，所有資料都留在電腦」。官方表明，對話、Memory、Knowledge Graph、Agent 產生的檔案及可搜尋內容的索引，均按用戶保存在 Amazon Quick Account，與其他用戶隔離。Desktop App 則負責與獲授權的本機檔案及工具連接。
針對相關工具存取，Quick 提供細緻的權限控制，可設定 Always Allow、Ask Each Time 或 Always Deny。AWS 表示，用戶的對話、檔案及 Personal Context 不會用作訓練或改善 AI 模型。Agent 能力愈強，企業要問的已由「AI 是否安全」，延伸至「哪些 Agent 可以採取行動，哪些行動一定要有人批准」。
企業計 ROI：模型速度以外，更要看節省多少人手時間
Amazon Quick Desktop 最值得企業決策者關注的，最終是 Quick 押注的方向：企業 AI 的競爭焦點正由單純比較模型能力，延伸至 Context、Integration、Memory、Workflow 與 Governance，而非它在 Benchmark 上是否比其他模型強。
如果一間公司每天都有大量工作橫跨 Email、Chat、CRM、檔案及本機 Excel，員工經常花時間搜尋資料、製作重複報告，再把結果複製到另一個系統，那麼 Quick 這類 Agentic Desktop 的 ROI 就有具體的衡量方式：會議準備時間減少多少、員工少切換多少次系統、有多少重複流程可以變成 Skill，以及 Agent 在背景運行期間能釋放多少人手時間。
今次短時間試用後，我認為 Quick Desktop 最值得注意的地方，是它提出另一種工作方式：人不用先把所有資訊找齊再交給 AI；讓 AI 理解工作背景、拆解及執行可以交出去的任務，人集中處理真正需要判斷的決策。
這亦可能是企業由 Chatbot 走向 Agentic AI 時，最值得衡量的生產力改變。
