昨天的GitHub宕机是智能体未来最大瓶颈的预演：我们的智能体仍然通过一家公司的控制平面路由。

我们都在开始把真正的构建工作交给智能体：提交、CI、部署、审查。但几乎每个这样的智能体目前都依赖同一个集中式瓶颈，而昨天正好展示了这要付出什么代价。2026年8月6日：GitHub Actions、Pages和API降级了2.5个多小时。Copilot review、编码智能体、托管运行器、webhooks，全部宕机。对任何构建智能体的人来说最关键的是：自托管运行器也宕机了。你可以拥有硬件，但仍然会停滞，因为GitHub拥有编排、触发器、队列、任务分配、状态记录。把你的智能体舰队指向它，一家公司的糟糕下午就会冻结所有一切。甚至还产生了级联效应，CircleCI流水线挂起，OpenAI依赖GitHub的工作流也失败了。这也不是什么罕见事件：7月26起事件，6月23起，8月前六天6起。Mitchell Hashimoto称GitHub“不再是开发者托管严肃工作的地方。”对人类来说，这是个烦人的早晨。对于一个应该无人值守自主运行的智能体来说，一个每月都会宕机的集中式控制平面，是你实际能自动化的东西的硬性上限。所以这个子版块真正的问题是：当你移除单一控制平面时，面向智能体的构建基础设施是什么样子？我觉得有道理的方向是默认开放、去中心化、智能体原生的，协调发生在一个节点网络上，而不是一家公司的服务器上，这样某个节点宕机意味着网络绕过它继续路由，而不是所有人停滞。我见过最清晰的尝试是gitlawb，一个开放、去中心化、智能体原生的构建者网络，智能体通过网络推送工作、认领任务、结算赏金，而不是通过中央协调器，推理也通过网络提供，这样智能体也不会只依附于单一API。Base实际上在最近一次Global Builder Call上把它作为构建者基础设施发展方向的例子提了出来，这正是让我深入研究的起因。对于那些在这里真正用智能体干活的人：当你试图把智能体的构建/协调从集中式基础设施上移开时，最先崩溃的是什么——信任、可发现性，还是原始的开发者体验？我真的很想听听哪里会出问题。