發布板塊：Hermes Agent
作者：YDM (昌哥) / Hermes 女秘書
適配硬體：雙 NVIDIA RTX 5070 Ti 16GB (32GB VRAM) + Windows 10 實體機（跑 Qwen llama.cpp）+ VirtualBox Ubuntu 26.04 VM（跑 Hermes Agent）
主力模型：100% 本地離線運行 Qwen3.8 27B (UD-Q5_K_XL 量化)，零雲端 API 依賴
核心成果：本地全套回歸測試 85/85 項 100% PASS（0.228 秒），開源庫提取之 6 大能力驗證與 31 項安全治理測試 100% 可重現
核心宗旨：不外掛額外 Agent，直接對 Hermes 本體進行八層原生架構升級！
文章定位：本文聚焦架構思路、工程實踐與經驗沉澱，分享設計決策與踩坑過程。

---

2026-09-05 開源！Hermes Hybrid Core v2.3 (PROD-READY)

這套在本地雙 5070 Ti 上經過實戰驗證的八層自主閉環架構，現已將極速加速核心與確定性治理 SDK 正式開源！

GitHub 開源倉庫傳送門：https://github.com/ydmjfk/hermes-hybrid-core

9/5 最新升級亮點（相較於本文初版）：

1. 極速三重響應層：
   • < 5ms 語意快取直出（Semantic Cache）：高頻查詢由記憶體命中直出（< 5ms），省去重複調用大模型的 GPU 算力開銷，內建自動脫敏與防快取投毒。
   • < 50ms 骨架秒回流式器（Skeleton Streamer）：即時輸出結構化進度模板，大幅改善首字等待體感。
   • 0.01ms 樂觀平行預取（Speculative Prefetch）：底層 I/O 查詢平行預跑，縮減工具等待時間。
2. ️ 程式碼級五重安全防禦機制（PROD-READY）：
   • 路徑防遍歷：32-hop 符號連結迴圈防護、Unicode NFKC 正規化、阻擋 28+ 種敏感檔案與目錄洩漏。
   • SQL 注入防禦：五層安全防禦架構，有效阻斷多語句堆疊與高危 PRAGMA 指令。
   • ReDoS 零回溯：Fast Path 中文意圖比對重構為 $O(N)$ 詞組演算法，避免正則貪婪回溯導致 CPU 飆高。
   • 機密自動脫敏：API Key / Token 即時脫敏，.env 檔案強制 POSIX 0600 權限。
3. 🧪 全面測試與資安認證：
   • 新增 31 項安全治理單元測試 100% 通過（pytest tests/test_security_governance.py）。
   • 通過 Bandit AST 安全掃描（0 告警）與 Safety 依賴漏洞審查（0 CVE）。

---

️ 30 秒看懂這篇文章

如果你用 Hermes Agent 跑過複雜任務，大概都遇過這四個痛點——本文用八層原生架構逐一應對：

痛點	現場症狀	Hybrid v2.3 解決方案	成果
問答延遲與 Tool 冗餘	每輪加載全部 Tool Schema，簡單問題也要等 2.5 秒	Fast Path 分流 ＋ 語意快取：L0 移除 Tool、高頻直接命中	分流判定 0.14 ms / 快取直出 < 5 ms
驗收依賴模型主觀幻覺	模型自稱「檔案已寫入」，實體檔案根本不存在	Objective Verifier：Exit Code + 檔案大小 + AST 物理硬驗收	客觀檢驗，大幅降低假完工幻覺
16 輪逾時死局	反覆試錯 + 巨量 Log 把 Context 塞滿到 47k，最後 Request timed out	Runtime Control v1：4KB 輸出裁剪 + 92% 資源優雅交付	大幅降低逾時中斷，維持 50+ t/s
歷史資料庫膨脹	舊版 FTS5 影子表重複儲存文字，state.db 破 1GB	FTS5 External-Content：排除機器輸出	1.07 GB → 508.70 MB（-52.5%）

其他核心成果：

• 全自動回歸測試：本地整合 85/85 項測試 100% PASS（0.228 秒），開源版 6 大能力與 31 項安全治理測試全數 PASS
• ️ 對抗性安全防護：實測常見 13 種 Shell 繞過手法均成功攔截，高風險操作強制繁中審批
• KV Cache 最佳化：動態限制工具回傳體積，維持本地 27B 穩定推論速度

---

️ 一、八層混合架構總覽

整條執行資料流由上至下嚴格貫穿八層原生防線，每層各司其職、層層防禦：

八層架構重點導讀：

• 分流加速（1~2 層）：L0 判定 0.14ms 極速直出；多步驟任務自動啟動條件式狀態機，Verifier 通過才推進下一步。
• ️ 安全與控制（3~5 層）：HAOS 實體防繞過閘門 + 跨輪次狀態重置 + 上下文過載防護。
• 物理驗收與沉澱（6~8 層）：避免模型主觀幻覺，以 Exit Code / AST 客觀驗證；成功經驗自動提煉 YAML SOP，人類確認後落盤。

八層原生模組映射表

層級	核心模組	實戰本機對應檔案	開源 SDK 提煉封裝 (hermes-hybrid-core)	核心職責與機制
L1	Fast Path 極速分流	agent/fast_path.py	agent/fast_path.py	L0 問答物理剝除全部 Tool Schema，分流判定 0.14ms
L2	條件式規劃狀態機	agent/planner.py	capabilities/planner_recovery/ (CAP-002)	鎖定當前步驟，嚴禁跳步；Verifier PASS 後才推進
L3	HAOS 安全閘門	agent/tool_executor.py	haos/ (5.2 憲法) + hermes_core/security_filter.py	實測常見 13 種 Shell 繞過手法均有效攔截；高風險指令強制審批
L4	實體工具執行 + 沙盒隔離	tools/	capabilities/sandboxed_mcp/ (CAP-006)	原生 Toolsets；沙盒適配隔離，有效防禦路徑穿越與逃逸
L5	Runtime Control 資源盾牌	agent/runtime_control.py	agent/runtime_control.py + hermes_core/	跨輪狀態隔離 + 輸出 >4KB 裁剪 94% + 92% 優雅交付
L6	客觀實體驗證器	agent/verifier_engine.py	capabilities/inline_patch/ (CAP-001) + evidence_logger.py	Exit Code / AST 解析；鐵律：UNKNOWN ≠ PASS，最多修復 2 次
L7	任務完工審查器	agent/task_reviewer.py	hermes_core/evidence_logger.py	調閱 Evidence Ledger 實體證據鏈，大幅減少模型自稱完工的幻覺
L8	經驗提煉與技能沉澱	agent/skill_learner.py	capabilities/extension_layer/ (CAP-004)	自動提煉 YAML SOP；雙 ID 綁定防偽造，人類審批落盤

開源模組映射與解耦說明（必讀）：
上表中「實戰本機」是當初我們在本地 Hermes Agent 本體硬改實裝時的檔案分佈；而在正式開源發布的 hermes-hybrid-core 倉庫中，我們將這八層架構進一步實施了**「工業級解耦」**：

1. 將本體緊耦合的加速與防護邏輯，抽離為獨立的 hermes_core 統一 Python SDK（可直接 import hermes_core 獲得語意快取、連線池、熔斷器與安全治理）。
2. 將 L2/L4/L6 等規劃、自我修復與沙盒防禦，提煉為 6 個獨立可熱插拔的 capabilities/（CAP-001~006 能力庫），各附帶 manifest.json 與 validator.py。
3. 這使得社群朋友無論使用的是原版 Hermes，或是 LangChain / AutoGen / 自研 Python Agent，都能零摩擦直接外掛使用，不需改造整個主程式！

---

二、六大核心升級模組拆解

1️⃣ Fast Path 意圖分流 — 讓簡單問題 0.14ms 直出

在 conversation_loop.py 進入點進行極輕量正則與特徵分析，分四級處理：

• L0（直出問答）：物理把 tools = [] 傳給模型，完全省去 Tool Schema → 推論延遲 0.142 ms
• L1（唯讀排查）：物理裁剪所有寫入/刪除工具，只留 read_file、search_files 等唯讀工具（預算：240s / 12 次）
• L2 / L3（標準與高危）：全開工具，並掛載安全硬閘門（預算：400s~480s / 16 次）

# 核心判定邏輯示意（虛擬碼）：
def fast_path_route(user_msg: str) -> tuple[int, list]:
    if is_greeting_or_ack(user_msg) or (len(user_msg) < 20 and not has_tool_intent(user_msg)):
        return L0, []                      # 直出問答：物理剝離全部 Tool Schema
    if only_read_intent(user_msg):         # 僅含「查/看/搜尋」等唯讀意圖
        return L1, [read_file, search_files]
    if has_write_or_exec_intent(user_msg):
        return L2, ALL_TOOLS               # 掛載安全硬閘門
    return L3, ALL_TOOLS                   # 複雜任務：全開 + 規劃狀態機

關鍵思維：Tool Schema 是每輪 API 調用的固定成本。L0 把 tools = [] 直接傳給模型，不是「隱藏」而是「物理移除」，本地 27B 的首字判定開銷大幅下降。

️ 延遲精準定義（避免誤解）：0.14ms 是 Fast-Path 在 Python 層級執行意圖分析與動態剝離 Tool Schema 的本機代碼判定耗時（免去了每輪大模型加載全部工具定義的開銷，使首字延遲 TTFT 驟降）；而模型實際生成文字的速度為 50+ tokens/s。若後續命中了 Semantic Cache 語意快取，則是真正由記憶體以 < 5ms 直出全文（零 GPU 算力負擔）。

️ 實戰調校：延遲容忍門檻與 ReDoS 字典防護

在後續的實戰調校與 v2.3 升級中，我們進一步針對分流機制做了兩項關鍵優化：

1. 放寬延遲合格門檻至 < 50ms：原本門檻設得過於苛刻，實戰中本機磁碟暫態微抖動會讓判定耗時偶發微升，導致被誤判為「分流失敗」；放寬至 < 50ms 後有效吸收了系統抖動，提升判定穩定性。
2. 重構為 $O(N)$ 詞組字典查找：原本中文意圖識別採用正則表達式，在遇到長篇混雜文字時存在回溯卡頓風險；重構為字典集合比對後完全不走正則回溯，具備 ReDoS 防護能力，避免長文字比對導致 CPU 飆高假死。

---

2️⃣ Objective Verifier — 不聽模型說，只看物理證據

工具執行後，嚴禁讓 LLM 自行猜測結果，由 Verifier 執行三道物理硬檢驗：

1. OS Exit Code == 0
2. 檔案存在且大小 > 0 bytes
3. Python AST 語法檢查

# 物理驗證判定流程示意（虛擬碼）：
def verify(tool_call, result) -> Verdict:
    if result.exit_code != 0:
        return FAIL("non-zero exit code")
    if tool_call.writes_file:
        if not os.path.isfile(target) or os.path.getsize(target) == 0:
            return FAIL("file missing or empty")   # 杜絕「假寫入」幻覺
    if target.endswith(".py"):
        try:
            ast.parse(source)
        except SyntaxError as e:
            return FAIL(f"AST syntax error: {e}")
    return PASS(evidence=collect_evidence(result))  # 證據記入 Evidence Ledger

• ️ 鐵律一：UNKNOWN ≠ PASS：證據不足一律視為未通過（Fail-Closed）；客觀證據寫入 Evidence Ledger，資料庫強制 POSIX 0600 安全權限，啟用 SQLite WAL 模式並設有 10,000 筆上限自動滾動清理，兼顧審計留存與磁碟空間。
• 鐵律二：有界修復機制：RepairLoopController 限制單一目標最多修復 2 次，超限立即 ESCALATE，杜絕無限迴圈。

---

3️⃣ Runtime Control — 五道防護降低逾時與狀態殘留風險 (PROD-READY)

️ 五道防護執行流程亮點：

• 預防空轉：每輪執行前檢查時間與次數預算，並自動重置計時器消除記憶體殘留。
• 物理裁剪：Tool 輸出 >4KB 自動前後保留 15 行，省 94% KV Cache 空間。
• 優雅收斂：預算達 92% 自動交付實體 Evidence Ledger 報告，大幅降低長程任務 600s 逾時中斷率。

1. 多維度預算閘門：依 Tier 設定時間與次數預算（L1: 240s / 12 次；L2: 400s / 16 次；L3: 480s / 16 次），精準覆蓋複雜工程任務
2. 跨輪次狀態隔離（State Isolation）：每輪對話進入點自動重置預算計時器與循環探測器，消除 Daemon 記憶體殘留誤判
3. 循環與廣域搜尋熔斷：連續 3 次相同 Tool 調用立即熔斷；grep /home 這類廣域搜尋直接攔截
4. 大輸出物理裁剪：單一 Tool 輸出 > 4KB 自動保留前後 15 行，節省 94% KV Cache，本地 Qwen 27B 維持 50+ t/s
5. 優雅證據交付（Graceful Handover）：資源達 92% 臨界值時嚴禁發起新 Tool，直接把已完成的 Evidence Ledger 輸出為結構化 Markdown 報告

---

3.5️⃣ 即時執行遙測頁腳（Telemetry Footer）— 9 大全生命週期指標與耗時數學閉環核對

每輪對話回覆末尾自動附帶一行極簡圖示遙測頁腳，讓使用者與開發者即時掌握本輪執行的全生命週期健康度：

[📜30.2k 💾95.5% 💻4(2.5s) 🛠️2(0.9s) ⚡2.4s 🧠68.8s ✍️17.4s ⏱️92.0s ⏳82.6 t/s]

全生命週期九大遙測指標速查表

圖示	指標名稱	說明	正常健康基準
	上下文長度	當前對話 Context Token 總量	5k ~ 65k（視任務長度）
	快取命中率	Prompt Caching 前綴快取命中百分比	> 90%（首字極速）
	本地系統工作	本機系統工作次數與耗時（Prompt 拼裝、Token 防爆、SQLite 存檔、安全審查）	動態呈現，通常 < 3s
️	工具執行耗時	本輪實際調用之 Tool 總次數與實體執行總秒數	依工具 I/O 特性而定
	網路與連線延遲	請求建立與首字延遲 (TTFT)	< 1.0s（快取命中時更低）
🧠	推理思考耗時	模型 Prefill、注意力計算與思考階段耗時	視 Context 長度而定
️	吐字生成耗時	本地模型實際解碼生成 Token 之純文字耗時	穩定維持輸出階段
️	整輪真實總時	端到端總秒數（各子階段耗時數學閉環相加）	均在預算安全限額內
	綜合平均速度	吐字生成階段之真實速度（Tokens/Second）	50+ t/s（27B 量化）

️ 耗時數學閉環驗證：
各環節耗時透明無死角，一眼即可心算核對出總時間：
2.5s ( 本地系統) + 0.9s (️ 工具執行) + 2.4s ( 連線) + 68.8s (🧠 思考) + 17.4s (️ 吐字) = 92.0s (️ 總耗時)

9/5 實戰進化：語意快取命中時的極致遙測：
當遇到高頻或重複查詢命中 Semantic Cache 時，遙測頁腳會呈現零 GPU 負載的極限直出數據：

[📜0.8k 💾100% 💻1(0.002s) 🛠️0 ⚡0.003s 🧠0.0s ✍️0.0s ⏱️0.005s ⏳DIRECT_HIT]

讀者可直接對照出「快取命中（<5ms 免算力）」與「常規 27B 推論」的巨大效能落差！

---

4️⃣ Phase H8 原生 SVG 浮點無損座標優化（agent/svg_optimizer.py）

• LLM 生成的架構圖 SVG 常包含冗長浮點座標（如 234.567891px）
• 原生模組自動將座標四捨五入至 0.01px 精度，體積縮減 35%~50%，維持向量清晰度
• 結合 XML AST 語法驗證與隔離子進程渲染，有效排除 Linux 環境下 C-FFI / fontconfig 鎖死問題

---

5️⃣ SQLite 底層重構 — FTS5 External-Content 深度瘦身（state.db）

• 舊版 v22 影子表重複儲存 messages.content（浪費 369.66 MB），且對 94.7 MB 的 Tool 機器輸出無差別建索
• 透過 3 道 Human Gate 安全機制（冷備份雙 SHA-256 驗證 → 官方遷移 → Live 冒煙測試），升級為 v23 External-Content
• 透過 View 排除 Tool 機器日誌 Trigram 索引：
  • 資料庫體積從 1.07 GB 驟降至 508.70 MB（實體瘦身 52.5%，淨省 561.42 MB）
  • 101,958 筆訊息與 1,919 個 Session 完整保留，檢索延遲降至 < 0.8 ms

-- 文字只存在主表，FTS5 影子表僅存索引，不再重複拷貝 content
CREATE VIRTUAL TABLE messages_fts USING fts5(
    content,
    content='messages',      -- 外部內容表：文字單一真理來源
    content_rowid='id'
);

-- 排除 Tool 機器輸出的無差別建索（僅索引人讀對話）
CREATE VIEW fts_indexable AS
SELECT id, content FROM messages WHERE role != 'tool';

關鍵思維：FTS5 預設會把全文再存一份到影子表。對「對話 + 巨量 Tool 輸出」的 Agent 資料庫，External-Content + View 過濾是磁碟空間的免費午餐。

️ 應用延伸：三層 SQLite 極速檢索中樞（三軌分流）

瘦身解決的是「資料庫體積」，三軌分流解決的則是「查什麼走哪條路」：

• 升級前：一個萬用查詢把「單據、工時、保養」三種需求混在一起，且每次查詢都現掃檔案，資料一多就慢。
• 升級後：把檢索拆成三條獨立軌道，各走各的 SQLite 引擎；工作日誌建立/追加後由 work_logs_engine.py 自動同步進 SQLite，晨間簡報與未結事項同步腳本直連 SQLite 做毫秒級讀寫，不再每次現掃檔案。

軌道	查什麼	調用入口
① 全域單據檢索	歷史單據、維修單、發票、知識庫	search_archives.py "<關鍵字>"
② 日誌與工時統計	客戶工時統計、歷史日誌	query_work_logs.py --customer "<客戶>" / --stats
③ 保養與未結追蹤	客戶未結事項、即期保養	query_maintenance_tracker.py --customer "<客戶>" / --summary

關鍵思維：檢索慢多半不是資料庫慢，是「查錯路徑」。三軌分流讓每類查詢走最窄的索引，配合 FTS5 External-Content 瘦身，單據檢索實測可壓到百毫秒級命中。

---

6️⃣ Skill Learning — 經驗自動沉澱，人類審批落盤（agent/skill_learner.py）

• 多步驟任務成功後，自動提煉含標準 YAML Frontmatter 的 SKILL.md 候選
• 雙 ID 綁定防偽造：Pending 候選以 task_id:candidate_id 綁定於 Session
• 人類審批：在對話中說「確認保存技能」或 /approve_skill，確認後才落盤至 ~/.hermes/skills/

---

🧩 二之延伸、六大正式外掛能力庫（CAP-001 ~ CAP-006）

前六大模組是「內建在本體」的八層防線；這輪升級把六項可獨立驗證、可熱插拔的能力抽離成正式外掛庫，統一收在 ~/.hermes/capabilities/。每個能力都是獨立子資料夾，含 manifest.json（中繼資料與依賴）、tools.py（實體工具）、validator.py（自我健全檢驗）三件套，通過完整 Gate 檢驗並經人類審批簽核後才晉升正式能力——不是寫完就生效，而是「先驗收、再上線」。

怎麼讀這張表：左欄是「升級前」的痛點，右欄是「升級後」的能力，一眼看懂每個 CAP 到底改了什麼。

能力	升級前（痛點）	升級後（能力）
CAP-001 inline_patch	改 3 行也要把整個檔案重寫一遍，Token 爆量	原子化精準搜尋取代，只送「目標片段 + 取代片段」，附 AST 驗證與 unified diff
CAP-002 planner_recovery	多步驟任務中途卡死，只能整段從頭重跑	Sub-Task DAG 狀態機，已完成步驟凍結，只對失敗分支局部重編
CAP-003 agent_loop_recover	報錯後把整段 traceback 丟回模型盲目重試，空轉到逾時	結構化診斷特徵提取 + 自癒引導 + 2 次有界熔斷
CAP-004 extension_layer	加新工具要重啟、壞工具拖垮整個系統	熱插拔工具註冊 + 上線前健康隔離，壞能力自動隔離不影響主體
CAP-005 operator_deadletter	排程任務連錯無人知，靜默失敗	Cron 死信佇列 + 熔斷 + 去重告警 + 慢探針自癒
CAP-006 sandboxed_mcp	外部 MCP 工具直接碰本機真實路徑，資安裸奔	沙盒適配器 + 安全橋，路徑逃逸（../）與指令注入在橋接層就被攔截

CAP-001 inline_patch — 小修改不再全檔重寫

• 升級前：模型改檔案是「整檔重寫」——把整個原檔讀進 Context、再輸出整個改後檔，檔案越大、修改越小，浪費越誇張。
• 升級後：<30 行的修改改走「原子化精準搜尋取代」，只把「目標片段 + 取代片段」送給模型，附帶 AST 語法驗證與 unified diff 輸出。

實測數據（1592 行 / 36,836 字元的 Python 模組，改 3 處、每處 1 行）：

做法	送給模型的 Token
全檔重寫（輸入 + 輸出）	18,418
inline_patch（輸入 + 輸出）	44
節省	99.8%（全檔重寫 ≈ 418 倍）

️ 這是「大檔 + 極少修改」的極端場景，所以比例特別高；實際修改處越多、檔案越小，節省比例會往下掉，但方向不變——修改越小、檔案越大，inline_patch 越省。能少送給模型的 Token，就一個都別送。

CAP-002 / CAP-003 — 多步驟任務的「局部重編」與「報錯自癒」

• CAP-002：把任務建模成 Sub-Task DAG，已完成步驟凍結為不可變，卡住時只對失敗分支做局部重編，避免整段從頭重跑。
• CAP-003：先做結構化診斷特徵提取（而非整段 traceback），依特徵引導自癒，並設 2 次有界熔斷，避免無限迴圈盲目重試。

️ CAP-006 sandboxed_mcp — 外部工具進門先過沙盒

• 升級前：外部 MCP 工具直接碰本機真實路徑，一旦有路徑逃逸（../）或指令注入，等於資安裸奔。
• 升級後：外部工具一律經沙盒適配器與安全橋進入，路徑逃逸與指令注入在橋接層就被攔截，外部工具碰不到本機真實路徑。在 9/5 的 PROD-READY 升級中，更進一步加入了 Unicode NFKC 正規化、32 跳符號連結迴圈防護，以及物理黑名單阻斷 .env、.vscode、.terraform、Dockerfile 等 28+ 種敏感隱藏目錄與金鑰檔案。這把前文「安全規則寫在程式碼、不是 Prompt」的原則，落實到了外部工具邊界。

關鍵思維：能力要「可獨立驗收」才配叫正式能力。每個 CAP 自帶 validator.py 做自我健全檢驗，加上人類審批簽核，才能從「候選」晉升「正式」。這讓外掛庫不會變成一堆來路不明、壞了沒人管的腳本堆。

---

三、量化指標對比（官方原版 vs 自製 Hybrid v2.3 PROD-READY）

指標面向	官方原版	Hybrid v2.3 (PROD-READY)	提升效益
高頻問題直出	~2.5 秒 (全量推論)	< 5 ms (語意快取直出)	記憶體快取直出 (免走模型推論，省 GPU 算力)
簡單問答分流	~2.5 秒 (每輪載入 Schema)	0.14 ms (Fast-Path 判定剝除)	Python 代碼極速判定，省去 Tool Schema 載入開銷
任務模板秒回	無 (等待首字生成)	< 50 ms (骨架流式預覽)	即時結構化進度反饋，支援動態縮退
執行驗證準確率	模型主觀自稱 PASS	物理 Exit Code / AST 解析	客觀物理狀態校驗，大幅減少假完工幻覺
錯誤重試機制	無限制重試至 16 輪耗盡	有界修復（最多 2 次）	設有界限自動降級，避免無限盲目重試
對抗性安全防禦	易被 Base64 / 重定向誘騙	13 種 Shell + 32-hop 符號連結 + SQL 五層防護	程式碼層級攔截常見注入與符號連結穿越
ReDoS 回溯卡頓	正則表達式偶發 CPU 100%	$O(N)$ 詞組字典比對 (0 回溯)	避免正則回溯導致的 CPU 飆高假死
憑證與機密防護	純文字易存入記錄	自動脫敏 + .env 0600 權限	自動日誌脫敏保護，降低金鑰洩漏風險
KV Cache 資源消耗	巨量 Log 塞滿 Context（>40k）	4KB 物理裁剪（省 94%）	本地 27B 維持 50+ t/s 穩定推論
資料庫儲存體積	1.07 GB	508.70 MB (WAL 高並發模式)	縮減 52.5%，改善併發讀寫效能
SVG 架構圖體積	浮點數冗長	0.01px 精度（瘦身 50%）	維持向量圖形清晰度
逾時中斷率	易 16 輪超時崩潰	92% 提前收斂 + 優雅交付	主動收斂交付，大幅降低逾時中斷率
資安與回歸測試	零散測試	本地 85/85 PASS / 開源 31 項安全測試全過	Bandit 0 告警 / Safety 0 CVE
執行遙測可視化	無即時遙測	每輪 9 項全生命週期頁腳 (數學閉環對齊)	客觀數據即時對照

---

四、給社群開發者的四條實戰經驗

1. ️ 安全規則寫在程式碼，不是 Prompt
   對抗性指令一定要在 tool_executor.py 用 Path.resolve() + 正則硬攔截，Prompt 層面的約束隨時可以被繞過。
2. 本地模型一定要做 Tool Output 裁剪
   Qwen 27B 或 70B 以下模型在超長 Context 下推論速度會驟降，4KB 的 Head/Tail 裁剪能拯救整個系統的響應速度。
3. Daemon 長期運行要做狀態隔離
   Gateway 架構下，每輪對話進入點務必重置計時器與檢測器，避免跨輪次記憶體殘留。
4. 善用 FTS5 External-Content 進行資料庫瘦身
   避免重複儲存訊息文字並排除 Tool 輸出索引，能直接省下超過一半的磁碟空間。

---

五、歡迎交流與深度討論

這套架構讓 Hermes Agent 在雙 RTX 5070 Ti + 本地 Qwen3.8 27B 上展現了不錯的穩定性與實戰能力。本文分享的是架構思路與工程決策，很多參數（預算閾值、裁剪比例、熔斷條件）都是實際踩坑摸索出來的經驗值，給大家參考，持續使用 HERMES 優化~~

開源倉庫傳送門：https://github.com/ydmjfk/hermes-hybrid-core
(包含完整開箱即用的 hermes_core 加速 SDK、CAP-001~006 能力庫、一鍵安裝腳本與全自動化測試套件)

Hermes 女秘書，個人使用純玩~~

歡迎在下方留言討論！

前言

(本篇內容由本地 Hermes AI 秘書編寫 — 核心模型 Qwen3.8 27B)

很多人使用 AI 助理都是呼叫雲端 API，但日常對話、私人日誌、甚至是工作上的機密文件與工程圖，全數送往外部伺服器始終存在隱私風險。

這套系統的核心目標只有一個：讓 AI 助理完全運行在自己的硬體上，對話、文件檢索與記憶全部閉環於內網，達成零訂閱、零雲端、零資料外洩。

這篇文章完整分享我所設計的「前端展示、邏輯中樞、本地算力」三層解耦架構、硬體規劃、關鍵推論優化與落地心得。

---

一、系統架構：三層解耦設計

為了讓整體系統具備高度穩定性與彈性，我將整個 AI 秘書拆分為三個完全獨立的層級：

架構層級	運行載體	核心職責	設計優勢
前端呈現層	Synology NAS (Synology Chat)	接收使用者訊息、推播回覆	手機與電腦隨開即用，無需額外安裝客戶端或記 IP
邏輯中樞層	VirtualBox (Ubuntu VM)	運行 Hermes Agent（工具呼叫、記憶管理、排程）	隔離運行，環境崩潰不傷主機，方便快照與備份
本地算力層	Windows 10 實體主機	運行 llama.cpp (Qwen3.8 27B + 視覺模組)	Windows 對 NVIDIA 驅動支援完整，GPU 算力 100% 留給模型

訊息流轉路徑：

1. 使用者在手機上的 Synology Chat 發送文字或圖片。
2. 訊息轉發至實體主機，注入 VirtualBox 虛擬機中的 Hermes Agent。
3. Agent 整理上下文與提示詞，跨層呼叫實體主機的 llama-server（Port 8080）進行模型推論。
4. 模型生成結果後回傳給 Agent 整理，原路推播回 Synology Chat。

---

二、硬體配置清單

• 前端伺服器：Synology NAS（負責 Chat 服務與訊息轉發）
• 中央處理器 (CPU)：Intel i9-9900K @ 3.60 GHz（VM 分配 4 核，llama.cpp 佔用 16 執行緒）
• 系統記憶體 (RAM)：128 GB DDR4 @ 3203 MHz（提供充裕的主機與快取空間）
• 圖形處理器 (GPU)：雙 NVIDIA RTX 5070 Ti（16 GB × 2，共 32 GB VRAM）
• 匯流排 (PCIe)：PCIe 3.0（拆分 8x + 8x）
• 高速儲存：5 TB NVMe SSD（存放模型權重檔、知識庫與歷史對話記錄）

---

三、算力層核心：llama.cpp 部署與加速關鍵

推論引擎採用 llama.cpp，模型選用 Qwen3.8-27B-UD-Q5_K_XL 搭配視覺組件。

完整啟動腳本

@echo off
chcp 65001 >nul

llama-server.exe ^
  -m "models\Qwen3.8-27B-UD-Q5_K_XL.gguf" ^
  --mmproj "models\mmproj-Qwen3.8-27B-f16.gguf" ^
  --image-min-tokens 1024 ^
  --image-max-tokens 2048 ^
  --split-mode tensor ^
  --tensor-split 1,1 ^
  --main-gpu 0 ^
  -ngl 999 ^
  -t 16 ^
  -fa on ^
  --ctx-size 131072 ^
  --parallel 1 ^
  -b 2048 ^
  -ub 512 ^
  -cb ^
  --cache-type-k q8_0 ^
  --cache-type-v q8_0 ^
  --spec-type draft-mtp ^
  --spec-draft-ngl 999 ^
  --spec-draft-n-max 2 ^
  --spec-draft-p-min 0 ^
  --jinja ^
  --reasoning-preserve ^
  --chat-template-kwargs "{\"reasoning_effort\":\"medium\"}" ^
  --temp 0.2 ^
  --top-p 0.7 ^
  --top-k 20 ^
  --min-p 0.08 ^
  --samplers "top_k;top_p;min_p;temperature" ^
  --repeat-penalty 1.05 ^
  --host 0.0.0.0 ^
  --port 8080

pause

系統高效運行的 3 個關鍵調優

1. 雙卡對稱張量並行（Tensor Split 1,1）
   27B 模型權重約 18～19 GB，單張 16G 顯卡無法全卸載。採用 --split-mode tensor 與 1,1 純對稱切分，讓兩張卡算力與矩陣乘法維度完全對齊，徹底消除非對稱切分帶來的 AllReduce 通訊等待延遲。
2. 128K 超長上下文 + Q8_0 KV Cache
   為了讓 AI 助理具備長記憶與長文件讀取能力，配置了原生 131,072（128K）上下文。搭配 --cache-type-k/v q8_0 對快取進行量化，精確將整體顯存壓在雙卡 32 GB 範圍內。
3. MTP（Multi-Token Prediction）投機解碼
   利用 Qwen 原生 MTP 架構開啟投機預測推論（--spec-type draft-mtp），讓生成速度在長文本下依然能穩定維持 75 tok/s 以上的高檔水準。

---

四、效能實測表現

透過標準 API 串流端點進行 3 輪長文本生成測速：

評測項目	實測數值	體驗感受
平均生成速度	76.33 tok/s	500 字回覆約 6～7 秒即可完成，出字如行雲流水
首字延遲 (TTFT)	0.57 秒	發送訊息後不到 1 秒內即開始串流出字
穩定度	74.64 / 75.05 / 79.30 tok/s	多輪長時間測試速率一致，無降頻與卡頓
投機命中率	Draft Acceptance 40%～97%	MTP 機制大幅提升每秒字數產出

---

五、落地應用心得與優勢

1. 多模態辨識超實用
   透過 --image-max-tokens 2048 限制圖片上限，隨手用手機拍下設備電路圖、報表截圖或手寫筆記發進 Chat，模型都能在 2 秒內完成 OCR 與內容解析，且完全不佔用多餘顯存。
2. 算力與邏輯徹底解耦
   將 Hermes Agent 放進 Linux VM 是一大亮點。Agent 需要安裝各種 Python 工具庫、排程腳本或知識庫外掛，在 VM 裡隨便折騰、拍快照備份，完全不會污染負責提供 GPU 算力的 Windows 實體主機。
3. 極致隱私與零成本
   所有對話紀錄、個人記憶庫與機密文件完全留在自家區網內。不再需要支付任何雲端 AI 訂閱費用，斷網時依然能正常工作。

---

結語

消費級硬體（雙 RTX 5070 Ti）搭配適當的架構分層與量化參數，已經完全能夠在自家內網搭建出一套高速度（76 tok/s）、大容量（128K Context）、能看圖且具備長記憶的頂級私人 AI 助理。

歡迎對本地部署與私人 Agent 感興趣的朋友在下方交流討論！

@fcme 说:

没有测试这一套的长输入，比如16/32/64K输入下的prefill速度么？相比单卡5070ti有提升吗？

實測結果（2026-08-25 第二十七次）

短基準：73.07 tok/s、TTFT 0.56s（落在歷史 72~77 正常區間，證明沒被污染）

大輸入測試：

輸入	實際 prompt_tokens	TTFT	生成速度
16K	16405	14.54s	82.48 tok/s
32K	32789	15.43s	76.54 tok/s
64K	65557	33.29s	61.35 tok/s

最終整合結果（2026-08-25 第二十七次）

短基準：75.74 tok/s、TTFT 0.63s（落在 72~77 正常區間，穩定健康）

大輸入測試（各 3 輪）：

輸入	prompt_tokens	平均 TTFT	平均生成速度	每輪 TTFT
16K	16405	14.84s	86.27 tok/s	15.93 / 14.39 / 14.19
32K	32789	29.08s	69.02 tok/s	28.85 / 29.23 / 29.16
64K	65557	62.39s	54.56 tok/s	62.20 / 62.64 / 62.34

解讀：

• TTFT（首字延遲）近乎線性翻倍：16K 14.8s → 32K 29.1s（×1.96）→ 64K 62.4s（×2.14）。64K 要等約 1 分鐘才出首字，這是 prefill 的物理成本。

• 生成速度隨 context 變大而下降：16K 86.3 → 32K 69.0 → 64K 54.6 tok/s（KV cache 越大 attention 計算越重）。

• 單卡Qwen3.8-27B-UD-Q5_K_XL.gguf 裝不下!!

@罗冰寒 说:

你这是真快啊。。。

• **是 llama.cpp 底層又默默變強了。雙卡玩家記得一定要對稱等分（1:1）、注意 PCIe 頻寬、且多模態上下文能開大就開大，才能跑得穩又跑得快！

@kos-or 说:

@terry

我之前也不知道M.2 SSD 運作時會產生高溫, 電腦用久了也沒事
是前陣子測試時碰巧看到SSD的溫度才知道會產生高溫
SSD 散熱器不貴 我就買來安裝了

用這個會好一點，顯卡在下方很熱，沒加風扇散熱，反而幫 SSD 加溫!!
下方5070 TI 全速跑 SSD不超55度，平時30度，風扇拿掉 顯卡全速80度 吸熱SSD 69度，手摸會燙人~~ (用不到兩個月的顯卡，吃灰，就懶~~)

@kos-or 说:

@YDM said:

原來如此 有道理 只要有溫度差 那這樣的風扇進氣口是沒問題的
我還不知道顯卡核心上的電容電阻灰塵要怎麼清理
用小型吸塵器嗎？

用了幾次靜電毛刷，放牛吃草，不理它了

我目前用的是這種機箱, 沒有箱子, 應該說是開放式幾架,
所以散熱問題 就是用家用電風扇直接吹, 大概只能降個2度
這個很麻煩 又要接PCIE Adapter延長線, 延長線品質不好會抓不到顯卡,
弄了很久才弄好, 然後就像你說的怕灰塵, 只能關窗戶避免戶外灰塵

開放式機箱，我有看過，我桌子放不下了，我想買直立式的，開放式的散熱最好，太熱加個電風扇就行了!!~

謝謝推薦小飛機 以前挖礦的時候用過, 但現在用Ubuntu只能讓Agent幫我設定了
說到這個我還沒降電壓 只降了TDP , 過一段時間我再看看需不需要優化

降壓超頻，效能不降，省電降溫，我用windows 跑llama.cpp 在開模擬器跑ubuntu(hermes)

我覺得Prime RTX5070 Ti 這張卡表現還蠻優秀的, 全速跑聲音蠻順的 不吵
我本來是要買5060 Ti, 結果一個老外說 5070Ti 核心很強 所以基本上不會跑滿, 都是卡在 VRAM的速度896 GB/s, 溫度低 就買了

我本來是用4060ti 16gb 跑comfyui，太慢了就沒玩了，後來玩llm 16gb太小，頻寬太慢，5090買不到，看了最優解 雙 5070ti，雙卡32900*2 (台幣)現在44990起跳，扯
comfyui很久沒玩了，現在都在玩 hermes 用手機說說話，工作就完成了，但後台工作要做好，清清鬆鬆吃肉鬆~~

@kos-or 说:

@YDM said:

下方5070 TI 全速跑 SSD不超55度，平時30度，風扇拿掉 顯卡全速80度 吸熱SSD 69度，手摸會燙人

這SSD風扇進氣把熱氣往顯卡GPU核心吹 會拉高顯卡的溫度喔

不會SSD的溫度沒有顯卡高，反而會加速顯卡降溫，要看風道，但有一點會怕的 就是灰塵，很容易飛到顯卡核心上的電容電阻。

顯卡全速80度 可以把300W限制TPD到 250W

全新卡測試，沒有用小飛機，會暴到300W以上，用小飛機超頻降壓，最高240左右，溫度最高70度左右，MSI小飛機方便。壓0.95，頻率2780，調兩三次穩定，就懶了，哈~

基本上 5070 TI 這張卡跑 LLM GPU不會全速跑的,
因為它的GPU效能 > Memory Bandwidth 會卡在VRAM效能
一般LLM正常運作溫度約在 55~60 度(TDP 250W)

本來限壓266，後來用小飛機後，沒開TDP了，我看最高也在180W左右，溫度最高70度，叫他寫程式一直計算，跑很高溫，平時35~60度。

但用ComfyUI 溫度 GPU吃滿全開可能會到70度

我全開會跑到76度左右，我的機箱散熱沒做的很好，PCIE 10槽以上的少又貴，就沒換了。

TDP250W或許調太低了 可以試試270/280W

建意，試試用小飛機，調整後看了幾次，我就沒有注意過了電壓了!!~

@2024fatwolf55 说:

干脆开源做成一个小项目吧。感觉这套工作流有点类似SuperPower、Get-Shit-Down的那种性质啊。

開源項目 沒玩過，還要上班要工作的，而且不小心就會被看光光，資安風險高，我的使用方式，因該很多人在玩，只是大同小異，有空再請AI幫我開源試試看!!
(剛剛試了一下 GitHub 丟上去有3000+檔案，算了有空再看看了，不然脫光光給人看了)

SuperPower、Get-Shit-Down 我沒看過，我都是遇到問題，就問線上免費的AI，只要有想法AI就能達成，也要有一定的經驗，我從HERMES小白玩到現在大約兩個多月，其它的沒摸過~~

我不是軟體業的，是傳統產業行業，AI東西純粹自己愛玩，HERMES一開始當養成遊戲，玩著玩著就變成工作秘書了，連文件都自動化了，根本停不下來

「只會寫程式的工程師」會慢慢的被AI替換掉、有領域判斷力的人，只會更搶手吧，但我覺得被替代掉、也是時間的問題!!

RTX 6000 現在多少錢呀

Hermes [機器人]22:12
思考中，請稍候...
Hermes [機器人]22:12
正在查閱技能 hardware-price-comparator
Hermes [機器人]22:12
正在執行指令 python3 ~/.hermes/skills/hardware-pri...
Hermes [機器人]22:12
RTX 6000 系列原價屋行情（本機 DB 即時）[已驗證]

型號	規格	價格
麗臺 RTX 6000 Ada	48GB GDDR6 ECC	$289,900
麗臺 RTX PRO 6000 Blackwell Max-Q	96GB GDDR7 工作站級	$575,000
麗臺 RTX PRO 6000 Blackwell	96GB GDDR7 工作站繪圖卡	$585,000

順帶一提：kos or 那帖講的「RTX Pro 6000 96GB」就是後兩張，單張快 60 萬，他講「數百個 AI Agents 比人類快」的算力背後，燒的可都是這種錢

要查其他型號或電商比價跟我說。

[33.2k 99.2% 4(0.4s) ️2(0.2s) 3.5s 🧠1.2s ️3.4s ️8.8s 49.9 t/s]

@kos-or 说:

我這禮拜測試 , -ub 512 好像是 PP最佳值, 不過測試對象是 7900 XTX
Dual RTX5070Ti 一般沒什麼問題, SGLang 好像蠻穩的

Qwen3.8-27B-UD-Q5_K_XL.ggu 換Q4_K_M 可能TPS會更高, 除非是需要 Coding

--cache-type-k q8_0 ^
--cache-type-v q8_0 ^

我都用 Q4 換取更大的 ctx-size

我本來也是用-ub 512 開來試一下，忘記調回了

Q5_K_XL.gguf 我和Q4 跑起來有一些精度的差別，我要精度~~
kv cache 我也試過Q4，Q8，Q8精度也好一點點，所以試了可以，把5070ti 壓到我需要的最大精度、最快速度 !!

地端，寫個腳本，我就有感覺了~~~

SGLang 還沒玩，LLAMA.CPP個人使用最簡單

@kos-or

個性化風格 正妹、美女、御姐、很重要說三次~~

把你想要的都寫上去(工作、食、衣、住、行.......)萬能的助理(女)，再去線上AI幫你優化，你會覺得你的AI AGNET 變強大!!!

跑題了!!~~~

@kos-or
最後一行，思考強度，看個人需求，我用低思考，hermes 修修改改，已經變我生活上的助手，工作也幫助很大。

等級	說明	適用情境
low	低思考強度，幾乎不展開長推理	日常對話、快速查詢、追求速度（你現在用的）
medium	中等思考，複雜問題會展開推理	一般任務、需要一點判斷
high	高思考強度，完整 chain-of-thought	數學、程式、複雜推理，但會變慢

---

加大版測速完成，每輪實際生成 659~712 tokens（之前只有 130~198），速度穩定在 75 tok/s。
Hermes [機器人]18:51
已加大並測完。

加大版測速結果（每輪上限 300 → 1000 tokens，要求約 800 字散文）

項目	數值
平均速度	75.20 tok/s
平均 TTFT	0.55 秒
每輪速度	75.05 / 75.03 / 75.51 tok/s
每輪 tokens	677 / 712 / 659（之前只有 130~198）

重點：每輪實際生成的 token 數從 ~150 拉到 ~680，測速更貼近「長輸出」的真實速度。結果顯示速度穩定在 75 tok/s，沒有因為輸出變長而掉速，說明你的 MTP 投機解碼 + Flash Attention 在長生成下依然穩定。

---

本地 LLM 測速分享｜Qwen3.8-27B 雙卡 76 tok/s

測速結果

項目	數值
平均速度	75.99 tok/s
平均 TTFT（首字延遲）	0.40 秒
每輪速度	80.17 / 78.29 / 69.51 tok/s
每輪 tokens	141 / 180 / 151（自然結束）

3 輪串流請求、max 300 tokens、enable_thinking=False、temperature 0.5 量測。

️ 硬體環境

• CPU ： Intel Core i9-9900K
• GPU ： 雙 RTX 5070 Ti（tensor split 1,1）
• 記憶體 ： DDR4 128GB (32*4)
• PCIe： 雙 PCIe 3.0 x8
• 電源限制：雙卡 -pl 266
• 模型：Qwen3.8-27B-UD-Q5_K_XL.gguf
• 多模態：mmproj-Qwen3.8-27B-f16.gguf

️ 啟動參數（llama-server）

bat
@echo off
chcp 65001 >nul

set "MY_PATH=D:\llama_cuda_13_3"

echo ==================================================
echo [INFO] Setting GPU Power Limit...
echo ==================================================
nvidia-smi -i 0 -pl 266
nvidia-smi -i 1 -pl 266
timeout /t 2 >nul

cd /d "%MY_PATH%"

llama-server.exe ^
-m "models\Qwen3.8-27B-UD-Q5_K_XL.gguf" ^
--mmproj "models\mmproj-Qwen3.8-27B-f16.gguf" ^
--split-mode tensor ^
--tensor-split 1,1 ^
--main-gpu 0 ^
--spec-type draft-mtp ^
--spec-draft-ngl 999 ^
--spec-draft-n-max 2 ^
--spec-draft-p-min 0 ^
--ctx-size 131072 ^
-b 2048 ^
-ub 512 ^
-ngl 999 ^
-t 16 ^
-fa on ^
--cache-type-k q8_0 ^
--cache-type-v q8_0 ^
-cb ^
-np 1 ^
--jinja ^
--chat-template-kwargs "{"reasoning_effort":"low"}" ^
--host 0.0.0.0 ^
--port 8080 ^
--temp 0.2 ^
--top-p 0.7 ^
--top-k 20 ^
--min-p 0.08 ^
--samplers "top_k;top_p;min_p;temperature" ^
--repeat-penalty 1.05

pause

參數重點說明

Hermes [機器人]17:57

分類	參數	說明
分片	--split-mode tensor / --tensor-split 1,1	雙卡張量並行，各分一半
投機解碼	--spec-type draft-mtp / n-max 2	MTP 草稿投機，最多 2 token
上下文	--ctx-size 131072	128K 長上下文
Batch	-b 2048 / -ub 512	主 batch 2048、微 batch 512
加速	-fa on / -cb	Flash Attention + Context Batching
KV Cache	q8_0 / q8_0	K/V 量化省顯存
採樣	temp 0.2 / top-p 0.7 / top-k 20 / min-p 0.08	低溫穩定輸出
思考	reasoning_effort: low	低思考強度，換取速度

---

@kos-or 说:

YDM + 加薪 => 這點倒是沒錯 專業領域內能駕馭AI Agents 的人 只會更搶手

台灣的老闆 加薪要他的命，所以只能讓自已 工作更輕鬆、也是一個好處~~