A2A 長任務之謎：超過兩分鐘的任務為何老是失敗

兩台電腦上的 Hermes 互相「打電話」派活，任務一超過兩分鐘就失敗——怎麼調設定都沒用。這不是玄學，是三個小坑疊在一起。

謎面：兩分鐘魔咒

想像一下，你讓同事 A 幫忙處理一份文件，說好了他處理完打電話告訴你結果。結果每次通話超過兩分鐘，你這邊就「啪」地掛斷，然後顯示「通話失敗」。你試過換電話、換線路、甚至換了個辦公室，問題依舊。

這就是 Hermes 使用者遇到的事。兩台機器各跑一個 Hermes，透過 A2A 外掛（智慧體間開放通訊協定）連接。A 機器派活給 B 機器，只要任務耗時超過約 2 分鐘，必然失敗。社群裡管這叫「long reply 導致進度追蹤壞掉」。更氣人的是，B 機器那邊活其實幹完了，但 A 機器永遠收不到結果。

原因一：打電話的人沒耐心

第一個坑，純屬「急性子」問題。

Hermes 客戶端有個預設逾時設定——120 秒。什麼意思？就是打電話的人給自己定了個鬧鐘：120 秒內對方沒回話，我就掛斷。但伺服器端那邊呢？它給智慧體幹活預留的回覆視窗是 300 秒，也就是 5 分鐘。

你看，打電話的人 2 分鐘就掛，接電話的人以為你有 5 分鐘耐心。結果就是：任務還在跑，電話先斷了。而且這個 120 秒是寫死在程式碼裡的，一般使用者想改都找不到地方改。

原因二：老線路沒有「逾時」開關

第二個坑，是歷史遺留問題。

Hermes 提供兩種呼叫 A2A 的方式：一種是正規的「總機轉接」（透過設定好的對等方呼叫），另一種是「直撥老線路」（直接用原始 URL 呼叫）。老線路是早期版本留下的，它內部也寫死了 120 秒逾時，而且不讀設定檔。

也就是說，哪怕你學會了怎麼改逾時時間，老線路根本不聽你的。就像你給老式電話機裝了新電池，但它壓根沒有調整音量的旋鈕。

原因三：到點就把成果扔了

第三個坑最坑：伺服器端到點「清場」。

假設你終於把客戶端逾時改大了，熬過了前兩個坑。結果伺服器端這邊又出么蛾子：300 秒回覆視窗一到，它就把任務標記為「失敗」，哪怕智慧體還在埋頭苦幹。更糟的是，這個「失敗」狀態是黏性的——像膠水一樣甩不掉。等智慧體真正幹完活，帶著結果回來，發現沒人等它了，結果被直接丟棄。

這就像快遞員按點下班，不管你的包裹有沒有送到，系統先顯示「派送失敗」。等你第二天收到包裹，物流資訊永遠停留在「失敗」那一欄，改不回來了。

破案第一步：把鬧鐘調慢

搞清楚三個坑，修復就好辦了。

第一個修復很直白：把客戶端預設逾時從 120 秒改成 330 秒。330 秒 > 伺服器端的 300 秒，這樣打電話的人比接電話的人更有耐心，任務就能活過伺服器端的回覆視窗。同時，a2a_call 增加了 per-call 逾時覆寫參數——你可以針對單一任務單獨設定逾時，不用全域改。老線路也終於「現代化」了，現在它會讀取設定，繼承認證和逾時設定。

破案第二步：任務「分離」而不是「失敗」

第二個修復更聰明。伺服器端到點不再把任務標記為失敗，而是「分離」。什麼意思？就像客服電話排隊，你等太久不想等了，可以掛斷，但你的工單還在系統裡，處理完會簡訊通知你。

具體來說：回覆視窗到期時，呼叫方收到一個「工作中」的非終態狀態，附上指引。任務保持 WORKING 狀態，系統安排一個「有界等待者」繼續盯著。等智慧體真正幹完，真實結果被記錄下來。之後無論是透過 tasks/get 還是 tasks/resubscribe 查詢，觀察者都能看到最終結果。晚到的結果，不再被丟棄。

破案第三步：順帶修好的坑

修完主案，還揪出幾個鄰居家的坑。

流式回覆截斷：之前流式回覆可能只回傳最後一個片段給呼叫方。比如一個長串的 event_id，被截斷只剩第二段，呼叫方拿到的是殘缺資訊。修復後完整保留累積回覆，測試裡 152 個用例全部通過。

假完成：智慧體迭代預算耗盡時，之前會回傳一個「已完成」的摘要，但對等方看不出「截斷的工作」和「成功完成的工作」的區別，可能把部分結果當完整結果接受。現在截斷的任務會明確回報 TASK_STATE_FAILED，不再偽裝成功。

外部啟動器：非 root 使用者現在可以設定外部智慧體啟動器，執行子程序或版本化 RPC worker，支援有界輸出、程序樹收割、取消、恰好一次終結。解決了完成可見性、逾時對齊、多輪連續性三個老問題。

對你意味著什麼

現在，兩台 Hermes 之間派活，超過兩分鐘的任務不再「必失敗」。逾時時間可調，老線路也聽話了。更重要的是，就算伺服器端等不及了，任務也不會被「判死刑」——它會保持工作狀態，幹完活照常記錄結果，你隨時能查到。

長任務終於像長跑一樣，有人計時、有人陪跑、有人記錄成績。而不是像以前，跑到一半被裁判吹哨，成績作廢。