Y
我是看了老特的YT視屏才開始學習使用Hermes agent，在騰訊雲服務器上建立了自己的Hermes agent，一樣使用Telegram來和Hermes對話。原來的用途很單純，所以也只使用一個Profile，來自動幫我抓取產業新聞，整理週報，月報之類的瑣事，使用的模型就是Deepseek V4 flash這個當時屬於白菜價的模型。不過當我歷經了多次Deepseek多次把自己整掛了以後，我還得登上服務器去自行處理後。我開始思考如何讓模型工作更穩定。
首先使用的就是多Profiles來分工，首先我把Agent角色分成Orchestrator，Specialist，Auditor三種，再來就讓Deepseek自行設計Agent的溝通方式（Agent bus），要求只有最容易維護。AI的設計如下：
所有的通訊都透過Orchestrator，這個Agent會知道所有Agent的任務和執行結果，但是不需要去管執行細節。我的實際實作如下：
這套流程跑下來，可以解決Hermes agent變笨和記憶體的問題。 先簡單的野人獻曝，如果有需要更細項的說明，歡迎一起討論。
很好的分享，不過文章有點長，我直接讓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 |
預設值是打開的，目前沒有感到任何不便。使用Hermes作為24小時工作助手，還是蠻方便的，尤其是多Profile實在太方便了。 我設計了一套multi agent架構，說實在的，不覺得比以前多花多少錢，而且也更好的讓我利用Deepseek的離峰價格，避免被過度漲價。
