AI應用

影片介紹 ClearMode 的 Marcelo 在這次影片介紹了一個他為 Hermes Agent Dashboard 開發的模組化外掛——Floating Chat Bubble（浮動聊天視窗）。這個外掛解決了他在使用 Hermes Agent 時的一個痛點：在操作 dashboard 的不同功能頁籤時，需要不斷切換回 chat 頁面才能下指令，非常不便。 什麼是 Floating Chat Bubble？ Floating Chat Bubble 是一個疊加在 Hermes Agent Dashboard 之上的浮動聊天介面。簡單來說，無論你在 dashboard 的哪個分頁（Kanban Board、Settings、Logs 等），這個聊天視窗都會跟著你，讓你不用切換分頁就能即時與 Agent 對話。 Marcelo 提到，這種浮動介面其實在網路世界很常見，只是大家可能沒注意到。他的靈感來自於自己在操作 Hermes Agent 時的不便，於是決定動手做一個解決方案。 核心功能 跨分頁即時對話 外掛最核心的功能就是「跟隨」：當你瀏覽 dashboard 的不同分頁時，chat bubble 會保持在畫面上。這意味著你可以一邊看著 Kanban 板上的任務，一邊直接在下方的浮動視窗中下指令，完全不用切換分頁。 可調整大小與位置 這個 chat bubble 預設固定在畫面右下角，但你可以拖曳四個角落來調整大小，也可以把整個視窗拖到畫面的任何位置。它會記住你的設定，下次開啟時維持在你喜歡的位置。 情境感知 當你進入 dashboard 的「Main Chat」分頁時，浮動視窗會自動隱藏，因為該分頁本身就已經是聊天介面了，不需要重複顯示。這是一個聰明的情境判斷。 主題支援 外掛支援 skin-aware（主題感知），會自動配合 dashboard 的暗色/亮色模式，保持視覺一致性。 開發歷程 Marcelo 提到，這個外掛是在過去幾週的直播中逐步開發完成的。他每週一、三、五上午九點（太平洋時間）進行直播，在直播中實作並測試這個外掛。 他已經針對 Hermes Agent 的多次更新進行了測試，確認外掛在這些更新中都能正常運作，核心功能穩定。 ...

前言 Microsoft 的 Superintelligence team 在 2026 年 6 月 2 日正式推出了 MAI-Code-1-Flash——一個專為日常開發者工作流設計的高效編碼模型。這個模型由 Microsoft 端到端打造，使用乾淨且具合法授權的資料訓練，目前已開始部署到 GitHub Copilot 的 VS Code 個人版使用者中。 簡單來說，這是 Microsoft 在「讓 AI 真正好用」這條路上又踏出的一步。 三大核心能力 根據官方公告，MAI-Code-1-Flash 主打三個特色： Agentic Coding（智能代理編碼）：模型直接在 GitHub Copilot harness 環境中訓練，能與開發者日常使用的工具和系統無縫協作，不是只在實驗室跑分，而是在真實環境中學習如何寫碼。 Adaptive Thinking（自適應思考）：遇到簡單任務時保持精簡，遇到複雜問題時自動分配更多推理預算。這就像一個懂得看場合的同事——小事不廢話，大事肯花時間。 強指令遵循能力：無論是一次性提問還是多輪對話，都能精準理解並執行開發者的意圖。 為什麼說「為開發者而生，不是為跑分而生」？ 這可能是這篇文章最關鍵的概念。大多數 AI 編碼模型的訓練目標是「在 benchmark 上拿高分」，但 MAI-Code-1-Flash 反其道而行——它在 GitHub Copilot 的生產環境中直接訓練，用真實開發者的使用數據來優化模型。 訓練過程中，團隊評估了核心軟體工程任務、倉庫問答、重構能力，以及從真實 Copilot 使用記錄中提取的遥測數據任務。這種「訓練、評估、生產」三者一致的方法，確保了實驗室裡的改進能真正轉化為開發者的體驗提升。 每個 token 都要花在刀口上 MAI-Code-1-Flash 引入了 自適應解決方案長度控制（Adaptive Solution Length Control） 技術。用白話來說： 簡單任務 → 精簡回答，少花 token 複雜任務 → 深入分析，多花 token 實際效果是：在 SWE-Bench Verified 上，MAI-Code-1-Flash 解決難題時最多少了 60% 的 token 用量。這不僅降低了延遲和成本，更讓互動式工作流變得更順暢——開發者不用等那麼久就能看到有用的輸出。 ...

引言：一台「不該跑 AI」的機器 這篇文章是 point.free 上一篇 Gemma 4 系列的最後一篇——前面兩篇講了怎麼把 Gemma 4 的 MTP drafter 量化、怎麼跟 verifier 配對，而這一篇要回答一個更刁鑽的問題： 「把這些成果丟到一台根本沒有資格跑 AI 的機器上，會怎樣？」 作者的硬體規格聽起來像是一台從墳墓裡挖出來的古董： CPU：Intel Xeon E5-2620 v4（2016 年產，約為當前筆電 CPU 的五分之一慢） 記憶體：128 GB DDR3（頻寬只有最新筆電 RAM 的五分之一到六分之一） GPU：無（連內顯都沒有） 換作一般工具，比如 ollama，直接放棄。但這篇文章的作者說：「等等，聽我說完……」 核心問題：記憶体牆（Memory Wall） 要理解這篇文章的精髓，先搞懂一個概念——LLM 推理的瓶頸不在運算能力，而在記憶體頻寬。 當你使用 ChatGPT 看著文字逐字流出時，你看到的是「decoder pass」。在這個階段，處理器要不斷把龐大的模型權重從記憶體拉進 CPU cache 才能計算下一個 token。處理器的運算速度其實很快，但它大部分時間都在等記憶體傳輸——這就叫「記憶體受限」（memory-bound），而非「運算受限」（compute-bound）。 這就是著名的「記憶体牆」問題。不管你用的是 2016 年的 Xeon 還是最新的 H100，這堵牆都在那裡。 所以，直接拿預設參數跑 llama-cli 在 DDR3 機器上會慢到令人發指。解法是什麼？把 ik_llama.cpp 能用的優化選項全部拉滿。 那串「魔法咒語」 作者甩出了一長串 llama-cli 參數，看起來像中世紀巫師的咒語： llama-cli \ --model gemma-4-26B-A4B-it-Q8_0.gguf \ --model-draft wikitext-2-raw_ik-llama-mtp_drafter-conservative/gemma-4-26B-A4B-it-assistant-Q8_0.gguf \ --spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune \ -cnv --color --jinja --special \ -sm graph -smgs -sas -mea 256 --split-mode-f32 \ --temp 0.7 -t 8 --parallel 8 \ --cpu-moe --merge-up-gate-experts \ --flash-attn on --mla-use 3 \ --mlock --run-time-repack --no-kv-offload 25 個參數，一半沒有文件說明，四分之一會靜默失敗。這就是作者所說的「可用性的護城河」（usability moat）——黑盒工具讓你看不見這些，但也讓你無法優化。 ...

前情提要 過去幾年，OpenAI 的旗艦模型（GPT-4o、GPT-5 系列、o1/o3 推理模型、Codex 程式生成模型）只能透過 OpenAI 自家 API 呼叫。不管你的公司用什麼雲端，只要想用 OpenAI 最強的模型，就得連到 api.openai.com。 現在，這個局面被打破了。 2026 年 6 月 1 日，OpenAI 正式宣布其 frontier models（包含 GPT-5、o3、Codex 等）以及 Codex CLI 開發工具，全面上架 AWS Marketplace。 這聽起來像是「又多了一個呼叫方式」，但實際上，這一步的意義遠比你想像的深。 這次上線了什麼？ 簡單來說，這次 AWS 上架的包含兩大塊： 1. OpenAI 模型作為 AWS Marketplace 產品 你可以在 AWS Marketplace 直接訂閱 OpenAI 的模型，然後透過 AWS 的 API Gateway、Bedrock 或直連方式呼叫。计费走 AWS 帳單，跟其他 AWS 服務（EC2、S3、Lambda）的帳單合在一起。 支援的模型包括： GPT-5 系列（包含不同尺寸與成本效能比的版本） o3 / o4 推理模型（高階邏輯推理、數學、程式生成） Codex 模型（專為程式碼生成與理解優化） 2. Codex CLI 工具 Codex CLI 是 OpenAI 推出的命令列開發助手，可以直接在終端機裡跟 AI 對話、生成程式碼、review PR。現在這個工具也可以透過 AWS 基礎設施運行，對已經深度使用 AWS 生態的開發者來說，整合度更高。 ...