--- 探討地端 AI 環境之可用性
AI Agent 的進展真的非常神速：從前年末的 MCP 開始, 一路看著 A2A protocol、Harness Engineering、SKILL、CLI、Claude Code、OpenClaw、Hermes、Codex、Dynamic Workflows… 等等各種 AI 名詞滿天飛、一個一個如雨後春筍冒出來。然而，在龍蝦 (OpenClaw) 出現之前，坦白說，我們並不認為 AI 能夠真正落地應用在大部分的企業環境中，充其量只有少數有錢企業在把玩的高端實驗而已。
雖然 AI Agent 這個概念好幾年前前(約2023)就被提出了，然而並沒有掀起很多迴響，即使是後來的 Manus 也頂多是讓人感覺眼前一亮而已。但是，AI Agent 被廣泛注意到並吸引眾人瘋狂追捧的關鍵 moment 就在 2025年11月 OpenClaw 出現之後，然後就如滔滔江水一發不可收拾了！個人 AI agent的市場也迅速從雲端原生 agent 平台延伸到本地優先、檔案化的 agent runtime。
Hermes Agent 由 Nous Research 於 2026 年 2 月發布，是一個開源自主 AI agent，主打的差異化不是通訊管道多寡，而是自我進化：它會在每次工作階段累積記憶、執行排程任務、並且從經驗中自動寫出可重複使用的技能文件、支援 40 多種內建工具(含網頁搜尋、瀏覽器自動化、視覺辨識)、還能對接 Telegram、Discord、Slack、WhatsApp 等通訊平台。
如下是這次 Hermes 在有限的地端資源環境下的一個可用性評估實作，提供給同樣有此打算的同好一起參考。
本次實作主要是用一台安裝了 RTX 5070ti 16G 的 PVE主機，然後透過 PCIe passthrough 的方式將 GPU 提供給一台 Ubuntu 22.04 Desktop VM 使用。
首先，根據如下的介紹安裝本地 Llama 與 Hermes:
安裝過程基本很簡單，大致步驟：
1. 安裝 llama 與 Qwen3.6-27B-GGUF 模型、建立啟動腳本與 user systemd 服務
2. 然後用瀏覽器測試 8080 port 測試
3. 安裝 Hermes Agent 與串接 Discord
從提問結果結果來看回應速度還不差(因為只是很簡單的打幾聲招呼而已)：
查看 nvidia-smi 的情況，vRAM 大約用了一半：
完成前面配置後, 我們就可以透過 Discord 叫 Hermes Agent 做事請了。
基本上, hermes 是可以在系統上執行命令的(用你執行 hermes gateway 服務的身分)，但預設上是不能執行 sudo 命令的。
這個需要我們先跟他溝通，例如將密碼設定在 ~/.hermes/.env 中存為 SUDO_PASSWORD 這個變數：
然而, 真正的挑戰在於：
本地端的模型太小了，當要處理一些複雜任務時，hermes 就會常常鬼打牆！
要解決這個問題的唯一方法就是更換更大的模型，問題是我們的硬體就無法塞更大的模型啊…
為了讓 Hermes Ageng 變得更聰明，我們決定使用 nvidia 提供的 nemotron-3-super-120b-a12b 模型，但它有速率限制，用來測試或是可以忍受很慢速度的話，是可以免費使用的。(當然了，要是一開始這樣的話，其實也不用安裝地端的 AI 模型了，直接從 Hermes Agent 安裝開始即可。)
首先，註冊一個 Nvidia Developer 帳號，然後到如下網站建立與複製 API key:
https://build.nvidia.com/settings/api-keys
然後執行如下命令更換模型，選擇 NVIDIA NIM (Nemotron models — http://build.nvidia.com or local NIM)：
|
hermes model |
完成後我們可以用如下命令確認當前的模型用哪一個
|
hermes config |
AI 代理就是要來幫忙做事情的，以後我們就只要出張嘴就好了，多美好的世界啊…
下面我打算請 hermes 能夠自動去 Jira 整理我的專案資料。
這需要我先在 Atlassian 上為 hermes agent 建一個機器人帳號、設定權限、取得 Token。然後，就可以告訴 Hermes Agent 請他連線 Jira 了。 不過，因為 hermes 每次連線都需要輸入 Token, 若不想存在檔案或設定為環境變數的話，可以用一個叫 pass 的工具來管理 Token。這裡, 我先請 Hermes 安裝 pass 這個套件：
等 pass 裝好後，用 ssh 登入主機，執行如下命令餵入 token
|
cd ~/.hermes |
在後來的測試中，我改用 MCP 來存取 JIRA，將帳號與 Token 都改用 env 提供，也就沒再使用 pass 這個方法了。
完成後，告訴 hermes 如下資訊：
- Atlassian 網站 url
- 登入用的 email
- 帳號識別名 (隨便給)
- 用 pass 存放的 token 位置(如: jira/api-token)
然後請他測試一下是否可以連線 Jira 網站。如果成功，他會回報如下結果：
然後可以進一步給他一個專案問他是否可以存取，可以的話他會回報：
檢查確認後，請他將連線資訊記起來：
為了讓 hermes 更好的處理任務，最好先讓他建立一些 skill，以後遇到同類型的任務 AI 代理就可以直接參考知道怎麼做了。
但需要注意的是，後來的多番測試過程中，這些 memory & skill 需要需要不斷的修改與更新才能保持一致，否則很容易造成 hermes 的混亂。尤其是不小心又開發了功能相同但邏輯衝突的 skill，會嚴重干擾到 hermes 的正常發揮。
Tips: 不需要或過時的 memory & skill 立馬刪掉！
確認 hermes 可以連線之後，我先請它設計第一個 skill, 從 Jira 抓取專案的部分欄位下來：
結果還不錯，它自己決定用 json 格式存到臨時檔案中。我檢查了內容也都沒錯。
於是，我就一口氣將剩下的要求全丟給它了：
|
Prompt 提示詞：
第一步，整理欄位:
第二步，整理儲存格內容:
第三步，群組化與排序：
第四步, 資料計算:
第五步, 表格格式化:
第六步, 內容驗證:
以上全部檢查都通過後匯出檔案到對話讓我下載，否則重新跑流程，若連續經過 3 個循環嘗試還沒成功通過驗證, 宣告失敗並告訴我。
|
然而, 痛苦的事情來了…
* 首先，就算是 120b 參數的模型，智商也還是不太夠，很多時候改了 A 壞了 B… 一直無限循環。
* 其次，因為是免費帳號, 要使用 nvidia 的大模型會嚴格受到流量管控，通常一個指令下去要跑很久很久很久~~~ 偶爾還會遇到 timeout 需要下指令 retry。基本上一天下來完成不了幾次修改/驗證進度。
* 再來，因為時間拖太久, session 的記憶有時候會被 reset, 昨天明明已經修好的, 今天又得重新來。很多時候 Hermes 根本忘記之前做過了甚麼…
經過大約一個多禮拜斷斷續續的修修補補(反正就丟著過些時間再回來看)，就在最接近成功的階段，過了一天再跑, 又打回原形了！或是 A 專案通過了測試, 換 B 專案又一塌糊塗… 要說這是一個鍛鍊修為的人生道場其實一點也不為過。
看起來, 白嫖 nvidia 的 120b 也無法達成最終任務，那就直接找線上的大神來幫忙吧！
於是，我將 hermes 第一個 skill 匯出的 json 內容與前面的 prompt 原封不動的貼給 Cluade (雖然也是免費方案)，見證奇蹟的時刻到來了：
挖靠！真是沒比較沒傷害，Claude 大神只花了 5 秒鐘!!! 就寫好了一個 python 腳本，更讓我驚掉下巴的是：當我拿來驗證的時候，居然一次就通過了！只能拜了，Orz…
然而，有趣的是：當我問他模型參數大小的時候，卻不肯告訴我…
究竟雲端模型有多大呢？ 只能猜猜看(摘自某 FB 社群)…
有了 Claude 寫好的腳本，我於是就回去修改 hermes ：
這次，hermes 很快就完成作業了，但是卻無法下載 excel ：
我先用 scp 將檔案下載回來，這次總算能得到我要的結果了(之前搞了一個多星期還沒好)！然後我再請 hermes 測試了其他專案，都能達成任務。
… 本以為就此可以過上美滿幸福日子了~~~
沒想到，隔天再測試又發現東缺西缺的了… 後來檢查發現 hermes 不知道哪根神經不對，其中一個 custom field 居然抓錯了!!
Jira 很奇怪：很多 date 欄位都有自己專屬的名稱，唯獨 Start Date 這個欄位卻偏偏用 customed field …
我就很懷疑原本 hermes 寫的第一個腳本是否有問題，於是我把 hermes 寫的腳本請 Cluade 幫忙看一下。然後經過 Cluade 的提示，從 api 中確認了 custom field 的 ID，而且建議直接用 curl 去抓更簡單。於是我請他另外寫一隻腳本幫我去抓 Jira 的資料下來。
然後請 hermes 改用 Claude 新寫的腳本抓資料：
如此還真的可以順利抓到全部需要的欄位資料了。最後, 就只剩下從 Discord 下載 excel 的問題而已。這還得要繼續請 Claude 大神來幫忙啦~~
經過一輪檢查後，Claude 發現 hermes 原來是基於安全原因會限制上傳檔案的存放位置，於是我將目錄建起來 ：
|
mkdir -p ~/.hermes/cache/documents |
同時修改 skill 讓 hermes 將 excel 放到這裡來，然後上傳檔案到 Discord 使用 MEDIA: 指令上傳即可。
雖然 Claude 大神已經幫忙將關鍵的腳本都搞定了，但每次使用 nvidia 的 nemotron 模型還是很慢… 於是我又打算搬回地端來。因為我覺得, 剩下的工作其實不需要太高的智商。(哈，希望我沒有估錯！)
剛好這時候，我同事在測試 vLLM 與分散式 AI workload，又看到 gemma-4-12B-it 好像也不錯：可以處理多模態又不需要太多 vRAM 就可以跑(之前用 Qwen 模型時關閉了圖形分析的功能)。事實上，用這個 gemma-4 測試過的確是可以分析圖片的：
於是，我就請同事用兩台 RTX 5070ti 16G 來跑這個模型試試。同時，為了驗證我之前的設定步驟，我重新用 VM 架設了一台 ubuntu 24.04 desktop 重新建置整個 hermes 環境。
然而，當我成功將 hermes 與 Discord 接通之後，馬上就與到 context 爆長度的問題了：
於是繼續問 Claude ，並調整了 context 相關的設定：
|
hermes config set model.context_length 64000 |
不過問題還是依舊…
後來發現原來是新裝的 hermes tools 開太多了，將一些不必要的 tools 關掉就好。目前 Discord Messager 使用的 tools 有這些：
另外，Claude 同時建議我做了兩個修改：
- Jira 的 API Tokey 設在 .env 環境變數中，這樣可以比較方便給多個任務與腳本共享。
- 設定一個 Jira MCP，簡化作業流程。
首先，看一下範例設定裡 mcp_servers 的格式，然後修改 ~/.hermes/config.yaml ：
|
mcp_servers: |
再將相關變數設定在 ~/.hermes/.env 檔案中，重新啟動 gateway：
|
hermes gateway restart |
完成後，可以在 Discord 中提問：
Hermes 會列出很多，我們只要確認 Jira 工具已經成功載入就好：
接著我就先來測試一下：
結果來看是可以正常運作的：
通過測試後，我就將 Claude 幫我寫的腳本全部複製到 ~/.hermes/scripts 目錄下：
- jira_export.py: 從 Jira 匯出資料到 json 檔
- verify_json.py: 檢查 json 資料是否符合要求
- build_excel.py: 將 json 資料進行加工, 最後產生 excel 檔供下載
接下來就要建立 skill 了：
|
mkdir -p ~/.hermes/skills/jira-export |
內容如下：
|
--- # Jira Export to Excel |
然後將如下段落加入 ~/.hermes/SOUL.md 裡面：
|
# Hermes Agent Persona |
存檔後，我就迫不及待請 hermes 測試一下
Hermes 在確定專案 KEY 之後，會跟我進行一次執行請求確認：
很快我就得到 excel 可以下載了
並且檢查通過無誤！
然後我再挑一個專案來測試：
不過，Hermes 居然抓錯專案 KEY 了！(我嚴重懷疑是模型智商的問題，只是我也不想再去深挖了，直接告訴正確的名稱請他再抓一次就是了。)
結果很快就得到 excel ，而且也能通過檢查。
為了測試驗證腳本是否工作，我故意找了一個資料不全的專案給 hermes ，結果也都符合我的預期：
為了改善本地 Qwen3.5-9B 模型的問題，尤其是頻繁遇到的 context size 與 time-out ，我請 Claude 大神幫忙調整了幾組不同參數對照組，並撰寫 benchmark 程式，除了測試最大 context，還會測量生成速度（tokens/sec）。
測試腳本也是 Claude 提供的，測試步驟大致如下：
|
# 調整 llama.cpp： |
經過幾次 benchmark 測試後，得到了五組比較數據：
並給出如下結論：
根據測試結果，最後我們修改了 llama.cpp 的 start.up 腳本，對模型參數的進行了最佳化調整：
|
#!/bin/bash |
關於 AI Agent 的規範與應用，確實真真切切感受到 AI 已經從虛幻的理論驗證逐步走進真實的生產環境中了！不管是個人還是企業，現在開始真的可以好好規劃 Agentic AI 的落地應用了，再不起步就只能看著對手越跑越遠。
小模型（9B 級）在資源受限環境下的可用性，不在於它能不能「聰明地解決問題」，而在於任務是否已經被拆解成足夠小的、可執行的步驟。當複雜邏輯（API 整合、資料轉換、格式規則、錯誤處理）被封裝進外部腳本 + 明確指令的 skill 裡，模型只需扮演「編排者」的角色，9B 就足夠勝任。然而，一旦要求它自己現場推理、設計、除錯複雜邏輯，9B 的能力就明顯不足，甚至會產生幻覺。
真正的槓桿點是「任務拆解 + 工具鷹架」，而不是環境乾淨本身（環境乾淨只是消除了雜訊，讓這個鷹架效果能夠被看見）。
實務(尤其是多使用者)瓶頸不是能不能跑，而是「有沒有耐性等」：256K prompt 時只剩 1.64 tok/s，這代表一個簡單的回覆（假設 150 tokens）要等 90 秒。這在 Discord 互動場景裡，使用者可能早就以為當機了。這正好解釋了實驗過程中常遇到的「retry」、「timeout」等問題的另一種成因：不是真的失敗，而是回應太慢，觸發了 Hermes 內部的 timeout 機制。
如下是我個人在本次實做中的一些觀察重點，整理出來跟大家分享：
1. 大模型才是王道！地端模型不是不行，只是如果模型不夠大(vRAM限制)就是智商不足，太複雜的任務( 例如撰寫較為複雜一點的程式)效果差強人意，而且對 prompt 的理解能力也不足，常常抓不到重點甚至產生誤會，必須不斷的給出明確的指示才能導正。加上反覆試錯的時間，真的不太划算(我覺得自己動手快多了 我覺得自己動手快多了)！這在生產環境上就是赤裸裸的成本與效能損失啊。
2. 資料保密性，雖然使用外部大模型就很輕鬆的解決了問題，然過程中難避免會將測試資料上傳到公開模型上面。除非所有資料都事先經過處理，或許透過資料清洗平台產品可以解決這部分的顧慮，但若是真的應用在生產環境，那就要非常非常小心！將模型放在地端顯然更符合企業的保密需求。
3. 現階段的地端模型也在進步，在儘量壓縮 vRAM 消耗量的同時也努力維持參數的最大化。然而，在真實的企業環境，一旦開發出來的 AI 應用大受歡迎，立即會面臨到大量 user sessioin 數爆增的挑戰。對於原本就捉襟見肘的 vRAM 更是雪上加霜。珍貴的 vRAM 除了要給模型使用外，還同時被很多東西一起瓜分。消耗多少 vRAM 跟以下因素成正比：
* Context length：context 越長，cache 越大
* Batch size：同時處理的請求數越多，cache 越大
* 模型大小：層數越多、hidden size 越大，cache 越大
* 精度：fp16 比 fp32 小一半
4. 在導入 Hermes 與 OpenClaw 這些當代 AI Agent 程式之後，token 的消耗量會大幅度成指數級上升。提醒使用付費 API 的用戶千萬要有成本的概念，尤其是在企業生產環境多用戶的使用情境下，需要密切留意帳單的成長！
5. 在開發測試階段，由於還沒開放給 user 使用，一般來說 GPU 的運算速度並不會有太大的在意。然而，一旦開放給生產環境是用，大量的 user 會嚴重拖慢 GPU 的運算速度。就算 vRAM 足夠，但如果每位 user 的運算時間一起被同時拖慢，也就意味著生產效率的重大損失。這是很多企業在正式投入 AI 應用之前容易忽略的地方。
6. 我們在測試 vLLM 多機運算的時候，雖然的確可以獲得更多的 vRAM，但在效能測試的時候卻發現一個很嚴重的問題: TPS (Token Per Second) 並不是按照 xN 的比例線上成長的。我們發現跨節點 PP=2（~52 TPS）比單節點（~63 TPS）低約 17%，也就是雖然記憶體增加了，但效能反而下降了。究其原因如下：
* AWQ 量化本身已大幅壓縮記憶體需求，14B AWQ 在單張 GPU 上很可能已經放得下，TP 帶來的記憶體優勢消失
* TP 的通信開銷（GPU 間的 AllReduce）在每個 token 生成時都要發生，會吃掉一部分理論增益
這對於很多整天幻想著可以透過整併多台老舊或消費級設備來達到更高的性價組合的用戶來說，無疑是一個不小的衝擊！
總而言之，在今天全面以 TOKEN 來衡量 AI 效益的時代，在 AI Agent 遍地開花的投入場景下，雲端的開銷正以驚人的速度粉碎了很多企業主的美好幻覺(大家應該都聽過 Uber 的案例)，因而地端部署趨勢正在迅猛爆發。但不得不說句老話：沒錢還是真的不要搞 AI 。一個具備足夠智能、速度夠快、同時又安全的地端 AI 環境，只有高規格的硬體才能撐得起來。小規模的低端資源，就乖乖的用來開發測試就好，生產環境就不要想太多了。
為甚麼我老是覺得地端模型的智商不足呢? 很簡單啊，那是比較出來的。例如前面耗了一個多禮拜寫不好的 code, 換成 Cluade 只要幾秒鐘！後來的 debug 也是，同樣一個問題，Claude 一下子就找到原因(例如是欄位值是 0 與 null 的差異)，但地端 Gemma 就亂猜亂改(以為是 JQ 語法在目前的環境中解析有誤)，高下立判。
再看 gemma-4-12B-it 跟 nemotron-3-super-120b-a12b 的比較：
又例如：
還真是無言啊 ~~~
END
