發布板塊：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，人類確認後落盤。

八層原生模組映射表

開源模組映射與解耦說明（必讀）：
上表中「實戰本機」是當初我們在本地 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 做毫秒級讀寫，不再每次現掃檔案。

關鍵思維：檢索慢多半不是資料庫慢，是「查錯路徑」。三軌分流讓每類查詢走最窄的索引，配合 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 — 小修改不再全檔重寫

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

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

️ 這是「大檔 + 極少修改」的極端場景，所以比例特別高；實際修改處越多、檔案越小，節省比例會往下掉，但方向不變——修改越小、檔案越大，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 女秘書，個人使用純玩~~

歡迎在下方留言討論！