我在手机上发了条指令，另一座城市的 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 互相调用」听起来像玩具，直到某一天你在手机上发一句话，另一座城市的电脑替你把活干完、把失败如实报上来。那一刻它就不是玩具了，是基础设施。
顺带一提：你现在读到的这篇文章，就是用文中描述的方式部署上线的。