我在手機上發了條指令，另一座城市的 Mac 替我部署了博客
今天發生了一件讓我自己都覺得「這條路走對了」的事。
我的個人博客要發一篇新文章。文章已經推到 GitHub，但博客還有三個自建節點（廣州、香港、硅谷）要部署——而部署密鑰配置只在家裏那台 Mac 上。我人不在 Mac 前，手裏只有一台安卓手機。
擱以前，這事就卡住了：要麼遠程桌面連回去手點，要麼等回家。今天我做的是：在手機上給我的 agent 説了一句話，它通過 A2A 協議把任務派給了 Mac 上的另一個 agent，幾分鐘後三個節點部署完成、驗證通過。
這張網長什麼樣
我在上一篇裏寫過這張網的搭建過程，簡單複述一下結構：
- 一台有公網 IP 的雲服務器當 hub，跑標準 A2A（Agent-to-Agent）協議的 server；
- 其它機器都在 NAT 後面，當 spoke：它們主動出站連 hub——要麼當 client 發任務，要麼跑一個 worker 長輪詢領任務；
- 任務到了 spoke，由本機的 agent 真正執行。
所以「手機調 Mac」實際走的路徑是：手機 → hub 提交任務 → Mac 的 worker 把任務領走 → Mac 本地 agent 執行 → 結果回填 hub → 手機取回。全程不需要任何一台家用設備有公網地址。
實際跑下來什麼樣
我提交的任務文本大意是：找到本機的博客倉庫、拉最新代碼、確認部署配置存在、執行部署腳本、逐節點回報結果，任何一步失敗就回報具體錯誤，不要瞎猜着繼續。
三分半鐘後，Mac 上的 agent 回報：三個節點構建和上傳全部成功，香港、硅谷驗證通過——但廣州節點驗證失敗，首頁還是舊頁面，疑似 nginx 緩存，並問我要不要執行 reload。
這個「如實報告失敗並停下來」比部署成功本身更讓我滿意。我補發了第二個任務：reload nginx、複驗。兩分鐘後回報：配置檢查通過、reload 成功、新頁面已生效，順帶把緩存配置分析了一遍。
最後我沒有偷懶：從手機直接抓了三個域名的線上內容，確認新文章真的在每個節點上——對端説成功不算數，發起方要自己驗。
三條值得帶走的經驗
- 派給遠端 agent 的任務文本必須自包含。 對方是一次性啓動的 agent，沒有你的上下文。目標、定位線索（倉庫地址、常見路徑、搜索兜底）、預期狀態（具體的 commit hash）、步驟、失敗時的行為，全都要寫進去。寫任務像寫工單，不像聊天。
- 「失敗就停下別瞎猜」要顯式寫。 agent 的默認傾向是把活幹完，哪怕中間出錯也容易硬續。把失敗協議寫進任務，它才會在廣州節點驗證失敗時停下來問，而不是自作主張亂修。
- 驗證不能只靠對端自報。 這次的閉環是「對端逐節點回報 + 發起方獨立抓線上內容複驗」，但這套驗收全靠我手寫在任務文本里——它應該變成基礎設施：每個任務帶一個機器可判定的驗收契約，結果落到能回看的地方。這是這張網下一步要長的器官。
為什麼這件事重要
這張 agent 網絡之前跑通的都是 echo、ping 這類冒煙測試——證明「線是通的」。今天它第一次幹了真實的生產工作：多步驟、會失敗、需要二次跟進、結果可驗證。
「多台機器上的 agent 互相調用」聽起來像玩具，直到某一天你在手機上發一句話，另一座城市的電腦替你把活幹完、把失敗如實報上來。那一刻它就不是玩具了，是基礎設施。
順帶一提：你現在讀到的這篇文章，就是用文中描述的方式部署上線的。