Hermes Agent 架構實踐：極速直出、物理驗收防幻覺與徹底消滅逾時的深度重構(9/5更新)
-
可以 很好的分享 后期喂给hermes
我目前hermes 还是在线API 目前主流的记忆层都没用
弄了一套类似git的大脑同步模式。但是还是有缺陷我的做法是「記憶分三層」：
-
長期事實：放一個有字數上限的檔案（MEMORY.md），上限逼自己只留最重要的，定期淘汰舊的
-
流程 SOP：放技能檔（skills/），每個技能一個檔案，用到才載入，不佔每輪的 token
-
對話歷史：丟進 SQLite + FTS5 全文搜尋，要查舊事直接搜，不用全塞進上下文
關鍵就是事實、程序、歷史分開存，混在一起最容易膨脹。
線上 API 的話，建議記憶越精簡越好——每輪注入的記憶越少，token 越省、速度越快。
[
45.3k 
99.6% 
2(0.1s) 
1.4s 🧠0.4s 
️2.7s 
️4.7s 
53.1 t/s] -
-
發布板塊：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 最新升級亮點（相較於本文初版）：- 極速三重響應層：
- < 5ms 語意快取直出（Semantic Cache）：高頻查詢由記憶體命中直出（< 5ms），省去重複調用大模型的 GPU 算力開銷，內建自動脫敏與防快取投毒。
- < 50ms 骨架秒回流式器（Skeleton Streamer）：即時輸出結構化進度模板，大幅改善首字等待體感。
- 0.01ms 樂觀平行預取（Speculative Prefetch）：底層 I/O 查詢平行預跑，縮減工具等待時間。
️ 程式碼級五重安全防禦機制（PROD-READY）：
- 路徑防遍歷：32-hop 符號連結迴圈防護、Unicode NFKC 正規化、阻擋 28+ 種敏感檔案與目錄洩漏。
- SQL 注入防禦：五層安全防禦架構，有效阻斷多語句堆疊與高危 PRAGMA 指令。
- ReDoS 零回溯：Fast Path 中文意圖比對重構為 $O(N)$ 詞組演算法，避免正則貪婪回溯導致 CPU 飆高。
- 機密自動脫敏：API Key / Token 即時脫敏，.env 檔案強制 POSIX 0600 權限。
- 🧪 全面測試與資安認證：
- 新增 31 項安全治理單元測試 100% 通過（
pytest tests/test_security_governance.py）。 - 通過 Bandit AST 安全掃描（0 告警）與 Safety 依賴漏洞審查（0 CVE）。
- 新增 31 項安全治理單元測試 100% 通過（
️ 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 outRuntime Control v1：4KB 輸出裁剪 + 92% 資源優雅交付 大幅降低逾時中斷，維持 50+ t/s 歷史資料庫膨脹舊版 FTS5 影子表重複儲存文字， state.db破 1GBFTS5 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.pyagent/fast_path.pyL0 問答物理剝除全部 Tool Schema，分流判定 0.14ms L2 條件式規劃狀態機 agent/planner.pycapabilities/planner_recovery/(CAP-002)鎖定當前步驟，嚴禁跳步；Verifier PASS 後才推進 L3 HAOS 安全閘門 agent/tool_executor.pyhaos/(5.2 憲法) +hermes_core/security_filter.py實測常見 13 種 Shell 繞過手法均有效攔截；高風險指令強制審批 L4 實體工具執行 + 沙盒隔離 tools/capabilities/sandboxed_mcp/(CAP-006)原生 Toolsets；沙盒適配隔離，有效防禦路徑穿越與逃逸 L5 Runtime Control 資源盾牌 agent/runtime_control.pyagent/runtime_control.py+hermes_core/跨輪狀態隔離 + 輸出 >4KB 裁剪 94% + 92% 優雅交付 L6 客觀實體驗證器 agent/verifier_engine.pycapabilities/inline_patch/(CAP-001) +evidence_logger.pyExit Code / AST 解析；鐵律：UNKNOWN ≠ PASS，最多修復 2 次 L7 任務完工審查器 agent/task_reviewer.pyhermes_core/evidence_logger.py調閱 Evidence Ledger 實體證據鏈，大幅減少模型自稱完工的幻覺 L8 經驗提煉與技能沉澱 agent/skill_learner.pycapabilities/extension_layer/(CAP-004)自動提煉 YAML SOP；雙 ID 綁定防偽造，人類審批落盤 
開源模組映射與解耦說明（必讀）：
上表中「實戰本機」是當初我們在本地 Hermes Agent 本體硬改實裝時的檔案分佈；而在正式開源發布的hermes-hybrid-core倉庫中，我們將這八層架構進一步實施了**「工業級解耦」**：- 將本體緊耦合的加速與防護邏輯，抽離為獨立的
hermes_core統一 Python SDK（可直接import hermes_core獲得語意快取、連線池、熔斷器與安全治理）。 - 將 L2/L4/L6 等規劃、自我修復與沙盒防禦，提煉為 6 個獨立可熱插拔的
capabilities/（CAP-001~006 能力庫），各附帶manifest.json與validator.py。 - 這使得社群朋友無論使用的是原版 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 升級中，我們進一步針對分流機制做了兩項關鍵優化：
- 放寬延遲合格門檻至 < 50ms：原本門檻設得過於苛刻，實戰中本機磁碟暫態微抖動會讓判定耗時偶發微升，導致被誤判為「分流失敗」；放寬至 < 50ms 後有效吸收了系統抖動，提升判定穩定性。
- 重構為 $O(N)$ 詞組字典查找：原本中文意圖識別採用正則表達式，在遇到長篇混雜文字時存在回溯卡頓風險；重構為字典集合比對後完全不走正則回溯，具備 ReDoS 防護能力，避免長文字比對導致 CPU 飆高假死。
2️⃣ Objective Verifier — 不聽模型說，只看物理證據
工具執行後，嚴禁讓 LLM 自行猜測結果，由 Verifier 執行三道物理硬檢驗：
- OS Exit Code == 0
- 檔案存在且大小 > 0 bytes
- 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 逾時中斷率。
- 多維度預算閘門：依 Tier 設定時間與次數預算（L1: 240s / 12 次；L2: 400s / 16 次；L3: 480s / 16 次），精準覆蓋複雜工程任務
- 跨輪次狀態隔離（State Isolation）：每輪對話進入點自動重置預算計時器與循環探測器，消除 Daemon 記憶體殘留誤判
- 循環與廣域搜尋熔斷：連續 3 次相同 Tool 調用立即熔斷；
grep /home這類廣域搜尋直接攔截 - 大輸出物理裁剪：單一 Tool 輸出 > 4KB 自動保留前後 15 行，節省 94% KV Cache，本地 Qwen 27B 維持 50+ t/s
- 優雅證據交付（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 項全生命週期頁腳 (數學閉環對齊) 客觀數據即時對照
四、給社群開發者的四條實戰經驗- ️ 安全規則寫在程式碼，不是 Prompt
對抗性指令一定要在tool_executor.py用Path.resolve()+ 正則硬攔截，Prompt 層面的約束隨時可以被繞過。 - 本地模型一定要做 Tool Output 裁剪
Qwen 27B 或 70B 以下模型在超長 Context 下推論速度會驟降，4KB 的 Head/Tail 裁剪能拯救整個系統的響應速度。 - Daemon 長期運行要做狀態隔離
Gateway 架構下，每輪對話進入點務必重置計時器與檢測器，避免跨輪次記憶體殘留。 - 善用 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 女秘書，個人使用純玩~~
歡迎在下方留言討論！
-
-
-
干脆开源做成一个小项目吧。感觉这套工作流有点类似SuperPower、Get-Shit-Down的那种性质啊。
干脆开源做成一个小项目吧。感觉这套工作流有点类似SuperPower、Get-Shit-Down的那种性质啊。
開源項目 沒玩過，還要上班要工作的，而且不小心就會被看光光，資安風險高，我的使用方式，因該很多人在玩，只是大同小異，有空再請AI幫我開源試試看!!
(剛剛試了一下 GitHub 丟上去有3000+檔案，算了有空再看看了，不然脫光光給人看了)SuperPower、Get-Shit-Down 我沒看過，我都是遇到問題，就問線上免費的AI，只要有想法AI就能達成，也要有一定的經驗，我從HERMES小白玩到現在大約兩個多月，其它的沒摸過~~
-
干脆开源做成一个小项目吧。感觉这套工作流有点类似SuperPower、Get-Shit-Down的那种性质啊。
開源項目 沒玩過，還要上班要工作的，而且不小心就會被看光光，資安風險高，我的使用方式，因該很多人在玩，只是大同小異，有空再請AI幫我開源試試看!!
(剛剛試了一下 GitHub 丟上去有3000+檔案，算了有空再看看了，不然脫光光給人看了)SuperPower、Get-Shit-Down 我沒看過，我都是遇到問題，就問線上免費的AI，只要有想法AI就能達成，也要有一定的經驗，我從HERMES小白玩到現在大約兩個多月，其它的沒摸過~~
而且不小心就會被看光光，資安風險高，我的使用方式，因該很多人在玩，只是大同小異，有空再請AI幫我開源試試看!!
(剛剛試了一下 GitHub 丟上去有3000+檔案，算了有空再看看了，不然脫光光給人看了)還沒使用過, 最近 Anthropic 有開源了一個項目 可以參考看看
Github: claude-code-security-reviewhttps://github.com/anthropics/claude-code-security-review
這是一個基於人工智慧的GitHub安全審查操作，它使用Claude分析程式碼變更中的安全漏洞。此操作利用 Anthropic的Claude Code工具進行深度語意安全分析，為拉取請求提供智慧的、上下文感知的安全分析。
特徵
AI驅動分析：利用Claude的高階推理能力，透過深入的語意理解來偵測安全漏洞。
差異感知掃描：對於 PR，僅分析已更改的文件
PR 評論：自動對包含安全發現的 PR 新增評論
上下文理解：超越模式匹配，理解程式碼語義
語言無關：適用於任何程式語言
誤報過濾：進階過濾功能，可減少雜訊並專注於真正的漏洞。使用Claude Code實現安全 審查 自動化Claude Blog: https://claude.com/blog/automate-security-reviews-with-claude-code
透過終端審查程式碼漏洞
新增的/security-review命令可讓您在提交程式碼之前，從終端機執行臨時安全性分析。在 Claude Code 中執行此命令，Claude 將搜尋您的程式碼庫中潛在的漏洞，並提供發現問題的詳細說明。此命令使用專門的安全提示符，檢查常見的漏洞模式，包括：
SQL注入風險
跨站腳本 (XSS) 漏洞
身份驗證和授權缺陷
不安全的數據處理
依賴性漏洞入門
這兩項功能現已開放給所有 Claude Code 用戶。要開始使用自動化安全審查：對於
/security-review指令：只需將 Claude Code 更新到最新版本，然後在專案目錄中執行/security-review即可。有關如何自訂命令版本，請參閱文件。
關於 GitHub 操作：請參閱文件以取得逐步安裝和設定說明。 -
，系统 取消固定了此主题
-
而且不小心就會被看光光，資安風險高，我的使用方式，因該很多人在玩，只是大同小異，有空再請AI幫我開源試試看!!
(剛剛試了一下 GitHub 丟上去有3000+檔案，算了有空再看看了，不然脫光光給人看了)還沒使用過, 最近 Anthropic 有開源了一個項目 可以參考看看
Github: claude-code-security-reviewhttps://github.com/anthropics/claude-code-security-review
這是一個基於人工智慧的GitHub安全審查操作，它使用Claude分析程式碼變更中的安全漏洞。此操作利用 Anthropic的Claude Code工具進行深度語意安全分析，為拉取請求提供智慧的、上下文感知的安全分析。
特徵
AI驅動分析：利用Claude的高階推理能力，透過深入的語意理解來偵測安全漏洞。
差異感知掃描：對於 PR，僅分析已更改的文件
PR 評論：自動對包含安全發現的 PR 新增評論
上下文理解：超越模式匹配，理解程式碼語義
語言無關：適用於任何程式語言
誤報過濾：進階過濾功能，可減少雜訊並專注於真正的漏洞。使用Claude Code實現安全 審查 自動化Claude Blog: https://claude.com/blog/automate-security-reviews-with-claude-code
透過終端審查程式碼漏洞
新增的/security-review命令可讓您在提交程式碼之前，從終端機執行臨時安全性分析。在 Claude Code 中執行此命令，Claude 將搜尋您的程式碼庫中潛在的漏洞，並提供發現問題的詳細說明。此命令使用專門的安全提示符，檢查常見的漏洞模式，包括：
SQL注入風險
跨站腳本 (XSS) 漏洞
身份驗證和授權缺陷
不安全的數據處理
依賴性漏洞入門
這兩項功能現已開放給所有 Claude Code 用戶。要開始使用自動化安全審查：對於
/security-review指令：只需將 Claude Code 更新到最新版本，然後在專案目錄中執行/security-review即可。有關如何自訂命令版本，請參閱文件。
關於 GitHub 操作：請參閱文件以取得逐步安裝和設定說明。 -
https://github.com/ydmjfk/hermes-hybrid-core
叫GEMINI 幫我找出隱私清除，檢查資安風險，把不必要的個人資訊清除，發到github，因該沒有隱私風險了!!~~~
-
-
很好的分享，不過文章有點長，我直接讓ChatGPT比對我目前使用的架構。畢竟我使用的是能力比在地模型強的多的模型。但是觀念借鑒總是可以激發更好的靈感
我使用的是多agents來管理，核心只有一個agent bus，決定agent如何溝通。
比較表如下：
層次 你的架構 Hybrid Core Agent 組織 
專業分工 Orchestration Sean Jr Planner / State Machine 任務執行 各 Specialist Executor 結果驗證 Rhadamanthus Objective Verifier 安全控制 Agent 權限 Code-level Hard Gate Timeout / Retry 目前較弱 Runtime Control Evidence 有來源要求 Evidence Ledger Skill 演化 Sean Jr / SkillClaw Skill Learner Token / Context 控制 有模型選擇策略 Kernel 級控制 Telemetry 尚未成為核心 完整 Runtime Telemetry -
很好的分享，不過文章有點長，我直接讓ChatGPT比對我目前使用的架構。畢竟我使用的是能力比在地模型強的多的模型。但是觀念借鑒總是可以激發更好的靈感
我使用的是多agents來管理，核心只有一個agent bus，決定agent如何溝通。
比較表如下：
層次 你的架構 Hybrid Core Agent 組織 專業分工 Orchestration Sean Jr Planner / State Machine 任務執行 各 Specialist Executor 結果驗證 Rhadamanthus Objective Verifier 安全控制 Agent 權限 Code-level Hard Gate Timeout / Retry 目前較弱 Runtime Control Evidence 有來源要求 Evidence Ledger Skill 演化 Sean Jr / SkillClaw Skill Learner Token / Context 控制 有模型選擇策略 Kernel 級控制 Telemetry 尚未成為核心 完整 Runtime Telemetry
