Posts on 凱凱的技術筆記

Hermes Agent 擴充：Floating Chat Bubble 外掛實作分享

Fri, 05 Jun 2026 01:22:16 +0800

影片介紹

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 推出 MAI-Code-1-Flash：為開發者而生的高效編碼 AI

Wed, 03 Jun 2026 16:39:50 +0800

前言

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 用量。這不僅降低了延遲和成本，更讓互動式工作流變得更順暢——開發者不用等那麼久就能看到有用的輸出。

Instagram 帳號被劫持？史上最蠢漏洞，只要帳號名稱就搞定

Wed, 03 Jun 2026 06:26:42 +0000

前幾天，一堆 Instagram 帳號——包括像白宮帳號這種高知名度的——好像都被黑了。

我雖說不是什麼小年輕了，但在獨角獸級公司找漏洞跟開發也快十五年，但這絕對是我見過最無厘頭、「蠢到不太可能成真」的一個。

劫持流程：簡單到令人髮指

Step 01：偽造位置 + 啟動客服

攻擊者只需要你的帳號名稱就能開工。接著連上一個靠近你城市位置的 VPN 或 proxy，讓 Instagram 的安全演算法不會起疑（這個資訊從你的公開個人頁面、About 區塊，或一百種其他方式就能拿到）。一旦看起來請求來自正確的地區，攻擊者就會告訴 Meta 支援 AI 帳號被黑了，要求把驗證碼發到他們控制的任意 Email。

Step 02：就結束了

真的，就結束了。這是我在生產環境中看過的第一個真正的「零驗證密碼重置」。系統似乎不會檢查你提供的 Email 是不是使用者以前用過的。一旦 AI 把驗證碼發到攻擊者的信箱，攻擊者再把碼填回去完成驗證，平台就乖乖送上一條新密碼重置連結，帳號歸屬權直接移交。

Instagram 的 AI 可能會問攻擊者要一段自拍影片來證明身分。目前的 AI 辨識力還不太夠，所以簡單到拿目標個人動態裡一張已經公開的 AI 動畫照片就能搞定。

雙重驗證（2FA）也沒用

如果你在想，因為這個高權限恢復流程被系統視為「真正的擁有者」進行的完整帳號重置，原本的雙重驗證會在過程中被徹底繞過。

既有的工作階段會被撤銷，密碼被更改，而且不會有任何 Email、簡訊或推播通知。真正的擁有者無法再發起恢復，因為 Email 和電話號碼現在都對應到攻擊者。沒有客服人員可以升級處理，就只有你跟一個聊天機器人奮戰，希望能奪回控制權，同時祈禱對方不要再來一次。

如果你屬於 A/B 測試中 AI 支援選項啟用的帳號，更慘——你甚至關不掉它。

黑市熱鬧滾滾

多個黑市的 Telegram 群組紛紛推出「帳號劫持」服務，價格高昂但交付速度極快。考慮到短帳號可以價值數十萬到數百萬美元，這也就不令人意外了。

帳號已經被轉賣（例如 hey），被用於宣傳（例如 obamawhitehouse 或美國太空軍上士長的帳號 ocmssf）。

已經修好了

所有 Telegram 群組都安靜下來了，因為 Meta 似乎已經修復了這個問題。但這個方法似乎已經活躍了好幾週，甚至好幾個月。

一個市值 1.5 兆美元的公司竟然連基本的安全防護都沒有，他們的支援 AI 只要你開口，就會隨意更換任何人的綁定 Email——這事實本身既恐怖又搞笑。

原文：The Newest Instagram “Exploit” is the Goofiest I’ve Seen by Sid’s Blog | 2026-06-01

十年前的 Xeon 伺服器，也能跑得動 260 億參數的 Gemma 4

Wed, 03 Jun 2026 00:00:00 +0000

引言：一台「不該跑 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 旗艦模型正式登陸 AWS — 從 API 到基礎設施的戰略一步

Tue, 02 Jun 2026 14:15:43 +0000

前情提要

過去幾年，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 生態的開發者來說，整合度更高。

PVE + OpenWRT 家庭網關實戰：從 USB Wi-Fi 到雙線 PBR 策略路由

Tue, 02 Jun 2026 13:24:22 +0000

最近把家裡的網路架構從單純的 USB 無線網卡上網，一路進化到雙線並行 + 策略路由（PBR），踩了不少坑，也累積了不少實戰經驗。把這些筆記整理成文，方便日後重置時快速恢復，也分享給有類似需求的同好。

一、基礎架構：PVE + OpenWRT + USB Wi-Fi 網關

硬體配置

底層系統：Proxmox VE（PVE）
網關系統：OpenWRT（安裝於 PVE 的 VM 100）
對外網路（WAN）：TP-Link Archer T2U PLUS（RTL8821AU 晶片，USB 無線網卡）

關鍵硬體解法：USB 延長線的電壓災難

一開始我直接用了一條 5 米 USB 延長線把網卡接到 PVE 主機，結果 PVE 完全認不到網卡（unable to enumerate）。查了一下才發現是長距離 USB 延長線導致嚴重電壓衰減，網卡啟動電流不足。

解法：換成「帶獨立 110V 供電的 USB 擴展器（Hub）」，確保網卡啟動時供電充足。這個硬體成本不高，但解決了最大的穩定性問題。

PVE 開機啟動順序設定

因為 OpenWRT 是所有 LXC / VM 的網路源頭，而 USB 擴展器需要時間初始化，所以開機順序必須嚴格設定：

VM 100（OpenWRT）：Boot order = 1 / Startup delay = 15（等待 USB 擴展器就緒）
其他 LXC / VM：Boot order = 2（或更後）/ Startup delay = 30~45（等待 OpenWRT 撥接上網）

OpenWRT 自動連網腳本

USB 網卡直通載入速度比 OpenWRT 開機慢，需要延遲執行 Wi-Fi 重載指令。在 OpenWRT 的 /etc/rc.local 中，exit 0 之前加上：

Stanford 怎麼教 AI Agent：一份值得開發者參考的 Guidelines

Tue, 02 Jun 2026 11:21:40 +0000

前陣子 Hacker News 上有一篇貼文衝上熱門，標題是「AI Agent Guidelines for CS336 at Stanford」，短短時間內拿到了四百多則按讚。

第一眼看到的時候，我心裡想的是：不過就是一份 prompt 吧？但仔細看完之後，發現這份只有兩千多字的 Markdown 檔案，其實藏著不少值得開發者思考的東西。

什麼是 CS336？

CS336 是史丹佛大學一門叫做「Language Modeling from Scratch」的課程。簡單來說，這門課不教你怎麼呼叫 API，而是從零開始，用 Python 和 PyTorch 實作一個語言模型。

課程非常硬核——你需要自己寫 tokenizer、transformer block、訓練迴圈，甚至 Triton kernel。正因如此，學生在作業上花的时间非常多。

於是教授們想了一個辦法：讓學生在寫作業時，可以請 AI 助手幫忙，但有一套明確的「遊戲規則」。

核心原則：Agent 是助教，不是解答器

這份 Guidelines 的第一句話就點出了核心精神：

AI agents should function as teaching aids that help students learn through explanation, guidance, and feedback—not by completing assignments for them.

換句話說，AI Agent 的角色是「老師」，不是「代考」。

接下來，文件列出了 Agent 應該做和不應該做的事情。我整理成幾個重點：

Agent 應該做的：