我把Hermes裏23個Agent全切到GLM-5.1：執行力比GPT強，但有個硬傷

大家好，我係孟健。

今日我嘅23個AI Agent全部由GPT轉咗去智譜GLM-5.1。一日落嚟：起咗一個完整網站、打通咗多Agent協作流水線、tune咗15個session行咗1556條消息。冇炒，冇傻，比GPT少廢話。

但有一個坑，真係好痛。

01 點解要換？

我係行Hermes Agent——一個開源嘅AI Agent框架，支援多平台（Telegram/Discord/CLI）、多模型切換、多Agent並行。我個團隊有23個Agent，各有分工：寫公眾號嘅墨微、做增長調研嘅墨探、出PRD嘅墨策、搞SEO嘅墨引、寫code嘅墨界……

之前全部行喺GPT上。講真，能力冇問題，但有兩件事令我好煩：

第一係貴。 23個Agent同時在線，每日早晚報、定時任務、突發協作，Token消耗得好快。

第二係囉嗦。 GPT系列有個毛病——佢太「熱心」喇。你叫佢改個設定檔，佢會先解釋一輪點解要改，再解釋點改，最後仲要總結改咗啲咩。23個Agent都係咁，效率直接打折扣。

所以當智譜放出GLM-5.1嘅程式API，我直接將所有Agent嘅默認模型轉咗過去。

02 切換過程：改一行設定

Hermes嘅模型切換極之簡單。全局設定喺~/.hermes/config.yaml，改兩行：

model:
  default: glm-5.1
  provider: zai
  base_url: https://open.bigmodel.cn/api/coding/paas/v4

然後用script將23個Agent嘅profile全部同步：

# 一鍵同步所有profile的config.yaml
for profile in ~/.hermes/profiles/*/; do
  cp ~/.hermes/config.yaml "${profile}config.yaml"
done

重啟gateway，搞掂。

由改設定到全部Agent上線，5分鐘。

03 實測：GLM-5.1行Agent到底得唔得？

今日全日行咗一日，核心做咗三件事：

1）由零開始搭建Hermes Agent 101網站

我叫小墨（我嘅主Agent）獨立完成一個畀新手嘅入門指南網站。佢自己研究咗Hermes嘅GitHub倉庫、Release Notes、官方文檔，然後：

• 寫咗一個完整嘅單頁應用（index.html，30KB純手寫）
• 包含Hero區、9大核心能力卡片、7天入門路徑、OpenClaw遷移指南、FAQ
• 設定好SEO（sitemap、robots.txt、llms.txt、Schema.org結構化數據）
• 一鍵部署到Cloudflare Pages

網站已經上線：hermes101.pages.dev

全程我冇寫過一行code。 小墨用GLM-5.1行咗172條消息，自主完成。

2）打通多Agent串行流水線

呢個先係今日嘅重頭戲。

先補充下背景：Telegram入面Bot默認係睇唔到其他Bot消息嘅。 呢個係平台一直以嚟嘅限制，搞到多Bot協作幾乎冇可能做到。直到Telegram喺@BotFather入面加咗一個開關——Bot-to-Bot Communication Mode，容許Bot透過 @OtherBot 提及或者reply嘅方式互相溝通。今年4月3號嘅Bot API 9.6又將Managed Bots（畀Bot創建同管理其他Bot）整套agentic能力放咗出嚟。

即係話，多Bot協作呢件事，係最近先真正行得通。

我將23個Agent嘅Bot-to-Bot Mode全部開咗，加埋入一個共享Telegram group。驗證通訊鏈路：

通咗。然後開始搭建流水線。

之前23個Agent喺group入面各自做各自嘅嘢，欠缺一個「串連」嘅機制。例如做網站，應該係：調研→PRD→預算→合規→SEO策略→設計→開發→部署→驗收→推廣，每一步都依賴上一步嘅產出。

今日搭咗一套Pipeline回調機制：

1. 小墨創建Pipeline（JSON狀態文件），自動派發Step 1畀墨探
2. 墨探完成之後@hermes_xiaomo_bot /pipeline-done hermes101-site step-1
3. 小墨收到回調，標記done，自動派發Step 2畀墨策
4. 跟住推進，直到10步全部完成

呢條流水線打通咗。10個Agent串行協作，好似工廠流水線咁自動推進。

3）排查Bot-to-Bot通訊嘅陷阱

過程入面中咗幾個真實嘅陷阱，GLM-5.1展現咗一個令我意外嘅能力——除錯排錯。

陷阱1：Bot之間@唔到
一開始其他Bot收唔到小墨嘅@提及。GLM-5.1自己去睇Telegram Bot API文檔，發現Telegram已經開放咗Bot-to-Bot Communication，但需要用正確嘅mention entity格式。佢自己寫script用Telegram API發送帶mention entity嘅消息，解決咗。

陷阱2：API Key揾唔到
某個Agent嘅gateway報錯Provider 'zai' is set but no API key found。GLM-5.1自己去睇Hermes嘅provider源碼，發現喺provider嘅extra_env_vars會順序揾GLM_API_KEY、ZAI_API_KEY、Z_AI_API_KEY——而profile目錄下嘅.env只有GLM_API_KEY。佢將所有profile嘅key都補齊咗。

陷阱3：ALLOWED_USERS冇加Bot ID
Bot之間嘅消息被TELEGRAM_ALLOWED_USERS過濾咗。GLM-5.1查出曬所有23個Bot嘅ID，一次過加入白名單。

呢三個陷阱，全程係佢自己排查、自己修，我只係喺旁邊睇住。

04 體感對比：GLM-5.1 vs GPT

用咗一日，講幾個真實體感：

執行力強。 畀佢一個任務，佢直接做，冇廢話。改設定就改設定，check日誌就check日誌，唔會先同你講一段「好嘅，等我幫你分析一下呢個問題」嘅過場。

除錯能力在線。 遇到API報錯、設定缺失、權限問題，佢可以自己追根溯源——睇源碼、check環境變數、比對設定差異。呢個能力我原本以為只有Claude同GPT-5級別先有。

中文理解好。 始終係國產模型，中文指令嘅意圖理解更準確，特別係涉及設定、路徑、環境變數呢啲中英混雜嘅場景。

上下文壓縮後恢復快。 Hermes有自動context壓縮機制，GLM-5.1喺壓縮後恢復上下文嘅能力唔錯，唔會好似某啲模型壓縮後直接「失憶」。

但有一個硬傷：並發限制。

05 硬傷：並發rate limit

呢個係GLM-5.1做Agent最大嘅問題。

當多個Agent同時行（例如今日同時有3-4個Agent處理緊各自嘅任務），會觸發rate limit。表現係API返回429，Agent卡住等緊。

對於單Agent對話場景完全冇問題。但多Agent並發係Agent框架嘅核心能力，呢個限制會直接影響團隊效率。

目前嘅應對策略：

• 錯峯調度：定時任務（cron）之間隔開10分鐘
• 串行Pipeline：多Agent行流水線而唔係並行
• 加retry：遇到429自動等陣重試

但呢啲係workaround，唔係solution。希望智譜快啲放開並發限制。

06 結論：國產模型行Agent，用得，而且唔錯

我嘅判斷：GLM-5.1係目前國產模型入面行Agent嘅第一梯隊。

佢嘅優勢好明確——執行力強、少廢話、中文好、除錯能力在線。呢啲特質對一個需要自主操作終端、瀏覽器、檔案系統嘅Agent嚟講，非常關鍵。

劣勢都好明確——並發限制。如果你嘅場景係單Agent或者Agent串行，GLM-5.1完全可以取代GPT。如果係多Agent高頻並發，就要等智譜放開限流。

我而家嘅策略：日常任務全部行GLM-5.1，高並發場景fallback去GPT。 成本直接減咗一半。

國產模型喺Agent呢個賽道嘅差距，比大多數人諗嘅要細。

📍 如果你都用緊AI Agent做project，可以試下Hermes。hermes101.pages.dev有完整入門指南。

覺得有用？轉畀你寫code嘅朋友。
有問題留言區傾，我每一條都會睇。
你覺得國產模型幾時可以全面取代GPT行Agent？

🚀 想同更多AI愛好者交流，共同成長嗎？

同一班志同道合嘅人，持續精進 AI 嘅每一日

大家好，我是孟健。

今天我的23個AI Agent全部從GPT切到了智譜GLM-5.1。一天下來：建了一個完整站點、搭通了多Agent協作流水線、調了15個session跑了1556條消息。沒崩，沒傻，比GPT少廢話。

但有一個坑，是真的痛。

01 為什麼要換？

我跑的是Hermes Agent——一個開源的AI Agent框架，支持多平台（Telegram/Discord/CLI）、多模型切換、多Agent並行。我的團隊有23個Agent，各有分工：寫公眾號的墨微、做增長調研的墨探、出PRD的墨策、搞SEO的墨引、寫代碼的墨界……

之前全部跑在GPT上。說實話，能力沒問題，但兩個事讓我煩：

一是貴。 23個Agent同時在線，每天早晚報、定時任務、突發協作，Token消耗飛快。

二是囉嗦。 GPT系列有個毛病——它太"熱心"了。你讓它改個配置文件，它先給你解釋一遍為什麼要改，再解釋怎麼改，最後還要總結一下改了什麼。23個Agent都這麼幹，效率直接打折。

所以當智譜放出GLM-5.1的編程API，我直接把所有Agent的默認模型切了過去。

02 切換過程：改一行配置

Hermes的模型切換極其簡單。全局配置在~/.hermes/config.yaml，改兩行：

model:
  default: glm-5.1
  provider: zai
  base_url: https://open.bigmodel.cn/api/coding/paas/v4

然後用腳本把23個Agent的profile全部同步：

# 一鍵同步所有profile的config.yaml
for profile in ~/.hermes/profiles/*/; do
  cp ~/.hermes/config.yaml "${profile}config.yaml"
done

重啓gateway，完事。

從改配置到全部Agent上線，5分鐘。

03 實測：GLM-5.1跑Agent到底行不行？

今天跑了一整天，核心幹了三件事：

1）從零搭建Hermes Agent 101站點

我讓小墨（我的主Agent）獨立完成一個面向新手的入門指南站點。它自己研究了Hermes的GitHub倉庫、Release Notes、官方文檔，然後：

• 寫了一個完整的單頁應用（index.html，30KB純手寫）
• 包含Hero區、9大核心能力卡片、7天入門路徑、OpenClaw遷移指南、FAQ
• 配好SEO（sitemap、robots.txt、llms.txt、Schema.org結構化數據）
• 一鍵部署到Cloudflare Pages

站點已上線：hermes101.pages.dev

全程我沒寫一行代碼。 小墨用GLM-5.1跑了172條消息，自主完成。

2）調通多Agent串行流水線

這才是今天的重頭戲。

先補個背景：Telegram裏Bot默認是看不到其他Bot消息的。 這是平台一直以來的限制，導致多Bot協作幾乎不可能做。直到Telegram在@BotFather里加了一個開關——Bot-to-Bot Communication Mode，允許Bot通過 @OtherBot 提及或者reply的方式互相通信。今年4月3日的Bot API 9.6又把Managed Bots（讓Bot創建和管理其他Bot）整套agentic能力放了出來。

也就是說，多Bot協作這個事，是這陣子才真正能跑通的。

我把23個Agent的Bot-to-Bot Mode全部打開，加到一個共享Telegram羣裏。驗證通信鏈路：

通了。然後開始搭流水線。

之前23個Agent在羣裏各幹各的，缺一個"串起來"的機制。比如做站，應該是：調研→PRD→預算→合規→SEO策略→設計→開發→部署→驗收→推廣，每一步依賴上一步的產出。

今天搭了一套Pipeline回調機制：

1. 小墨創建Pipeline（JSON狀態文件），自動派發Step 1給墨探
2. 墨探完成後@hermes_xiaomo_bot /pipeline-done hermes101-site step-1
3. 小墨收到回調，標記done，自動派發Step 2給墨策
4. 依次推進，直到10步全部完成

這條流水線調通了。10個Agent串行協作，像工廠流水線一樣自動推進。

3）排查Bot-to-Bot通信的坑

過程中踩了幾個真實的坑，GLM-5.1展現了一個讓我意外的能力——調試排錯。

坑1：Bot之間@不了
一開始其他Agent收不到小墨的@提及。GLM-5.1自己去翻了Telegram Bot API文檔，發現Telegram已經開放了Bot-to-Bot Communication，但需要用正確的mention entity格式。它自己寫腳本用Telegram API發送帶mention entity的消息，解決了。

坑2：API Key找不到
某個Agent的gateway報錯Provider 'zai' is set but no API key found。GLM-5.1自己去查了Hermes的provider源碼，發現zai provider的extra_env_vars會依次查找GLM_API_KEY、ZAI_API_KEY、Z_AI_API_KEY——而profile目錄下的.env只有GLM_API_KEY。它把所有profile的key都補齊了。

坑3：ALLOWED_USERS沒加Bot ID
Bot之間的消息被TELEGRAM_ALLOWED_USERS過濾了。GLM-5.1查出所有23個Bot的ID，一次性加到白名單裏。

這三個坑，全程它自己排查、自己修，我只在旁邊看着。

04 體感對比：GLM-5.1 vs GPT

用了一天，說幾個真實體感：

執行力強。 給它一個任務，它直接幹，不廢話。改配置就改配置，查日誌就查日誌，不會先給你講一段"好的，我來幫你分析一下這個問題"的過場。

調試能力在線。 遇到API報錯、配置缺失、權限問題，它能自己追根溯源——翻源碼、查環境變量、對比配置差異。這個能力我原本以為只有Claude和GPT-5級別才有。

中文理解好。 畢竟國產模型，中文指令的意圖理解更準，特別是涉及配置、路徑、環境變量這些中英混雜的場景。

上下文壓縮後恢復快。 Hermes有自動context壓縮機制，GLM-5.1在壓縮後恢復上下文的能力不錯，不會像某些模型壓縮後直接"失憶"。

但有一個硬傷：併發限制。

05 硬傷：併發rate limit

這是GLM-5.1做Agent最大的問題。

當多個Agent同時跑（比如今天同時有3-4個Agent在處理各自的任務），會觸發rate limit。表現是API返回429，Agent卡住等待。

對於單Agent對話場景完全沒問題。但多Agent併發是Agent框架的核心能力，這個限制會直接影響團隊效率。

目前的應對策略：

• 錯峯調度：定時任務（cron）之間錯開10分鐘
• 串行Pipeline：多Agent走流水線而不是並行
• 加retry：遇到429自動等待重試

但這些是workaround，不是solution。希望智譜儘快放開併發限制。

06 結論：國產模型跑Agent，能用，而且不錯

我的判斷：GLM-5.1是目前國產模型裏跑Agent的第一梯隊。

它的優勢很明確——執行力強、少廢話、中文好、調試能力在線。這些特質對一個需要自主操作終端、瀏覽器、文件系統的Agent來說，非常關鍵。

劣勢也明確——併發限制。如果你的場景是單Agent或者Agent串行，GLM-5.1完全可以替代GPT。如果是多Agent高頻併發，還需要等智譜放開限流。

我現在的策略：日常任務全走GLM-5.1，高併發場景fallback到GPT。 成本直接砍了一半。

國產模型在Agent這個賽道的差距，比大多數人想的要小。

📍 如果你也在用AI Agent做項目，可以試試Hermes。hermes101.pages.dev有完整入門指南。

覺得有用？轉給你寫代碼的朋友。
有問題評論區聊，我每條都看。
你覺得國產模型什麼時候能全面替代GPT跑Agent？

🚀 想要與更多AI愛好者交流，共同成長嗎？

和一羣志同道合的人，持續精進 AI 的每一天