布萊嗯研究所

現象：free 很小，不代表開不了程式 / A tiny free column is not “cannot start” 假設你在 Linux 終端機打出 free，free 欄只剩幾十 MB，used 卻佔了一大半。很容易先想到「記憶體爆了，得重開或加 RAM」。先停一下：這個畫面常常不是實體記憶體已經沒了，而是把「完全沒被用到的頁」，當成「還能開新程式的空間」。 Suppose you run free in a Linux terminal and the free column is down to a few dozen megabytes, while used takes most of the row. It is easy to jump to “memory is exhausted; reboot or add RAM.” Pause first: that picture often does not mean physical memory is gone. It means idle pages have been mistaken for the space still available to start a new program. /proc/meminfo 的 MemFree，依 Linux 7.4-rc1 的 proc 文件，是目前的 free RAM；在 highmem 系統上，它是 LowFree 與 HighFree 的和。它變小，只表示幾乎沒有完全閒置的頁。核心會把讀過的檔案留在記憶體裡，這份快取叫 page cache，也就是頁快取。那些頁還佔著 RAM，所以 MemFree 下降，但它們不是某個程式私有、放不掉的佔用。[1] In Linux 7.4-rc1’s proc documentation, MemFree in /proc/meminfo is the current free RAM; on highmem systems it is the sum of LowFree and HighFree. A small value only means there are almost no completely idle pages. The kernel keeps files it has re...

現象：改是改了，答案還是舊的 / The record changed, yet old answers persist 假設你把網站搬到新主機，在 DNS 管理介面把 A 記錄改成新 IP，自己測試也正常；幾分鐘後同事回報，看到的還是舊網站。先別急著把記錄改第二次：可能不是改失敗，而是查詢本身沒有走到你修改的那台伺服器。 Suppose you move a site to a new host and update its DNS A record in the management console; your own test works, yet minutes later a colleague reports the old site is still being served. Do not rush to edit the record a second time: the change may not have failed — the query itself may never have reached the server you edited. 在終端機輸入網址，多數情況不是直接去問「管這個網域的伺服器」，而是交給遞迴解析器代問，例如寬頻業者的解析器或公共 DNS。依 RFC 1034，DNS 定義了快取所取得資料的程序；解析器替很多使用者共用同一份答案，你問到的可能是幾分鐘前別人問過的副本，而不是最新狀態。[1] When you type a hostname, you are usually not addressing the servers that manage the zone directly. A recursive resolver asks on your behalf — the resolver of your broadband provider or a public DNS, for example. RFC 1034 defines procedures for caching retrieved data, so a resolver serves the same copy of an answer to many users: what you receive may be a copy fetche...

刪掉的是什麼？ / What was actually removed? 假設你在 Linux 伺服器刪掉一個很大的舊日誌，目錄裡已經找不到它，磁碟用量卻幾乎沒變。先別急著再刪一輪：檔名消失，不一定代表資料已經釋放。本文聚焦一種常見原因，也就是仍有程序開著那個檔案，不把所有空間問題都歸到同一個答案。 Imagine deleting a large old log on a Linux server. It disappears from the directory, yet disk usage barely changes. Resist deleting more files: a missing name does not necessarily mean the data has been released. This article focuses on one common cause—a process still has the file open—not a universal explanation for every space problem. 依 Linux 系統呼叫手冊，unlink 移除的是檔案系統中的一個名稱。只有當它是最後一個硬連結，而且沒有程序開著檔案，佔用的空間才會供重新使用。硬連結可以理解成同一份檔案的另一個名字；刪掉其中一個名字，並不是刪掉其他名字。[1] According to the Linux system-call manual, unlink removes a name from the filesystem. The space becomes reusable when that was the last hard link and no process has the file open. A hard link is another name for the same file; removing one name does not remove the others. [1] 程序開啟檔案後，會取得檔案描述符，也就是用來操作已開啟檔案的編號。即使最後一個名字被移除，只要仍有描述符指向它，檔案就會繼續存在，直到最後一個相關描述符關閉。因此，目錄中的名稱與程序手上的開啟狀態，要分成兩條線來看。[1][2...

目錄怎麼又回去了？ / Why did the directory revert? 假設你在 Linux 的 Bash 終端機裡執行一支腳本，裡面明明寫了切換目錄，腳本也沒有報錯，結束後卻還停在原處。這通常不是路徑失靈，而是你把「另一個 shell 的工作目錄」，當成了眼前這個 shell 的狀態。 Imagine running a script in a Bash terminal on Linux. The script changes directory without an error, yet your terminal remains where it started. Usually the path is not broken: you have mistaken another shell’s working directory for the state of your current shell. 工作目錄是程序用來解讀相對路徑的起點，不是整台電腦共用的一個游標。以 bash go.sh 執行腳本時，新的 Bash 會繼承起始目錄；它之後呼叫 cd，只改變自己的工作目錄，並不把變更回寫給啟動它的 shell。[1] The working directory is a process’s starting point for resolving relative paths, not a computer-wide cursor. Running bash go.sh starts another Bash that inherits the initial directory. Its subsequent cd changes its own working directory, without writing that change back to the shell that launched it. [1] 圖一｜繼承不等於回寫：腳本結束，外層仍在原處。原創示意圖，非產品或實測截圖。 / Figure 1 | Inheritance is not write-back: the outer shell stays put after the script exits. Original diagram, not a product ...

假設你準備接手一個小網站，筆電上已經裝了一套 Python，專案卻需要另一個版本。光想到調整環境，就有點想先去倒杯水。容器吸引人的地方，正是讓應用程式連同需要的檔案一起安排好；不過，這個看起來獨立的小空間，究竟獨立到哪裡？ Imagine taking over a small website. Your laptop already has Python installed, but the project needs another version. Just thinking about adjusting the environment might send you off for a glass of water. A container helps by packaging an application with the files it needs. But how independent is this seemingly separate space? 先看看，箱子底下是什麼 / Look beneath the boxes 在一般 Linux 容器的情境裡，容器內可以有自己的應用程式、函式庫與檔案配置，執行時卻共用承載它的 Linux 核心。虛擬機器則可以有自己的客體核心。把兩者都畫成一個方框很方便，卻容易漏掉這個關鍵差別。 [1] In a typical Linux container setup, each container can have its own application, libraries, and filesystem layout while sharing the Linux kernel that runs it. A virtual machine can have its own guest kernel. Drawing both as simple boxes is convenient, but it hides this essential difference. [1] 圖一｜先找核心在哪一層，比只看方框更容易理解差異。原創簡化示意圖，非產品截圖。 / Figure 1 | Locate the kernel before comparing the boxes. Original simp...

🌐 語言模式 / Language Mode: 中英對照 (Bilingual) 繁體中文 (Chinese) English Only NVIDIA Grace Blackwell GB10 vLLM V1 + NVFP4 + MTP Hermes Autonomous Agent 【實戰指南】在 NVIDIA GB10 (DGX Spark) 從零打造本地 AI Agent：vLLM + Qwen3.8-27B-NVFP4 + Hermes Agent 完整部署與調優 Building a Local AI Agent on NVIDIA GB10 (DGX Spark): Complete Setup & Tuning Guide for vLLM + Qwen3.8-27B-NVFP4 + Hermes Agent 徹底釋放 121 GB 統一記憶體與 Blackwell SM 12.1 原生 NVFP4 算力——包含 FlashInfer JIT 防 OOM 秘訣、MTP 投機解碼實測數據對決、256K 超長上下文配置與 Systemd 常駐維運指南。 Unleash 121 GB of Unified Memory and native Blackwell SM 12.1 NVFP4 acceleration — covering FlashInfer JIT OOM prevention, MTP speculative decoding benchmarks, 256K context configuration, and systemd production deployment. Hardware: NVIDIA GB10 (aarch64 / SM 12.1) Engine: vLLM 0.28.1 V1 (CUDA 12.8) Model: unsloth/Qwen3.8-27B-NVFP4 ...

Beyond chat responses: Mastering the architecture for reliable, production-grade AI agents. 🔎 工具速覽 / AT A GLANCE Category AI Workflow Orchestration / MLOps Pricing Open Source / Enterprise Custom BestFor 需要將 AI 能力整合到企業 CI/CD 流程的團隊 GitHub Stars ⭐ 276 🚀 引言 / Introduction 大家是不是覺得，現在的 AI 聊天機器人（LLM）已經很厲害了？只要問它個問題，它都能給你一個看似完美、字斟句酌的答案。但當我們把這些 AI 想像成真正的「員工」，讓它去處理複雜的商業流程——比如寫一個需要跑測試的 PR、或是生成一個完整的網站介面時，大家會開始遇到一個問題：它給的答案，怎麼確定是『對的』？它有沒有偷偷跑掉資料庫的順序？它寫的程式碼，有沒有隱藏的資安漏洞？這就是目前 AI Agent 的真正『阿基里斯腱』：從 '答案' 到 '可靠的產出' 的鴻溝。這時候，我們不能再把 AI 當成一個聰明的聊天窗口了，它必須是一個擁有自身工作站、能執行、能回溯、更能經得起專業『品質檢驗』的『數位員工』。本文要聊的，就是如何建立這樣一套工業級的 Agent 運作框架。 🛠️ 核心功能 / Key Features 我們看的是像 useagent 這類架構的崛起。它最大的創新點，已經遠遠超過了單純的 Prompt Engineering。它提供的是一個完整的『數位工作空間』概念，這不是一個 API Call，而是一個持續、可追蹤的『事件流』（Event-sourced timeline）。想像一下，它給你的不只是一個 JSON 回應，而是一個完整的、帶有生命週期的工作成果：一個跑完測試的 PR、一個可即時預覽的網站...