在社群中，關於 Hermes Agent 的另一大宗常見抱怨，往往發生在將其導入 GitHub 工作流（Workflow）自動化之時。最典型的症狀是：明明單步測試都可以跑，但串接成完整流程後，Agent 卻極度容易卡死、陷入無限重試、誤判任務完成，或是永遠等不到下一步。
深入探究會發現，這類問題多半不是因為 LLM 模型的能力不足，而是出在「流程設計的系統性反模式（Anti-pattern）」——也就是將「輪詢（Polling）」機制放錯了位置，硬生生地將本該由事件驅動（Event-driven）的步驟，塞進了 LLM 昂貴且脆弱的思考迴圈裡。
本篇目錄
痛點一：致命的 LLM 輪詢陷阱 (The Polling Trap)
在 GitHub 的日常協作中，Issue 讀取、開分支、跑 CI 測試、發送 PR（Pull Request）到回填狀態，是最核心的開發生命週期。許多開發者試圖讓 Hermes Agent「一氣呵成」完成這所有動作。
然而，GitHub 系統並不會每秒主動推進並同步所有狀態給你的 Agent。如果你將「查詢 PR 狀態」、「等待 CI 條件通過」與「人工確認結果」全部混雜在同一個 Agent Step（推論節點）中，Agent 就會被迫開啟「過度輪詢」模式：不斷發送 API 檢查狀態。這不僅極度消耗 Token，更會拖慢整個系統效能，最後導致 Timeout 或 Agent 產生幻覺而中斷。
痛點二：人類確認點錯位 (Misplaced Human-in-the-Loop)
另一個常見的架構錯誤，是把「人工確認點」放得太晚，或是完全忽視邊界。GitHub 自動化流程並不是「每一段都必須 100% 自動化」。
在實際場景中，有些關鍵步驟（例如：Code Review 審查、Label 權重分配、Risk Check 佈署風險評估）必須先暫停，等待人類工程師確認後才能放行。如果你賦予 Agent 過多的自由度，讓它自己決定所有事情，最後就會演變成「看起來自動化程度很高，實際上任務卻一直處於非預期的等待或卡死」。在這種情境下，Hermes Agent 最需要的不是更多的自主決策權，而是清晰的「流程邊界（Process Boundaries）」。
架構優化建議：事件驅動為主，輪詢為輔
要打造穩定可靠的 GitHub Agent，最務實的做法就是將輪詢範圍縮到最小，徹底釐清 Webhook、事件觸發與人工確認的職責邊界。
讓 Agent 只專注於處理「明確輸入的事件（Explicit Inputs）」，例如：當收到 pull_request.opened 的 Webhook 時，Agent 才被喚醒執行程式碼分析與留評。輪詢機制應僅限於非同步狀態的背景補齊，絕對不能當成推動主流程的引擎。只要將這條控制線拉直，Hermes Agent 的工作流就能從「等待、重試、卡死」的泥淖中解脫。
常見問題 (FAQ)
A1: 最常卡在「輪詢（Polling）與事件驅動（Event-driven）混雜」的設計上。這會導致 Agent 不斷在思考迴圈中等待外部狀態改變，不知道何時該果斷進入下一個步驟，最終引發超時或邏輯崩潰。
A2: 因為 GitHub 的狀態變化（如 CI/CD 執行、他人審查進度）在時間上是不連續的。許多環節應該依賴系統的 Webhook 主動通知或人工確認來推進，而不是讓 LLM 耗費運算資源去反覆「猜測」狀態是否改變。
A3: 核心原則是：「用事件驅動（Webhook）做主線，輪詢只用來補齊狀態，人工確認點要嚴格設置在高風險步驟（如 Merge 或 Review）之前。」 讓 Agent 成為被動接收指令的高效執行者，而非主動盲目監控狀態的巡邏員。