一个下午，少量 token，把归档两年的 Weave Scope 从 x86_64 的烂摊子里拉出来，生成多架构镜像直接推 Docker Hub。故事是真的，新仓库是真的，manifest 也在。但"救活"这两个字，我不认。
构建流程是 agent 最擅长吃掉的活，这我从来不否认。Makefile 冻结、Go 包损坏、C 库太老、打包脚本不兼容，这些东西繁琐、机械、反馈快。一个下午做完我不意外，我自己也天天用这类工具。问题在于把这层活干完就宣布一个内核级可观测性项目被救活了——这一步跨得太大。Weave Scope 不是写两个 API 就讲完的 web 服务。底下是 Go 和 eBPF 写的内核探针加 agent，中间是响应式 Web UI，最外面才是那套遗留 Makefile。三层里哪层最难？从来不是构建层。构建层再烂，烂在明处：编译不过、链接失败、依赖冲突，报错全在脸上。真正难的是探针层。eBPF 程序在 x86_64 上有多少架构假设，换到 arm64 上不是重新编译一遍就能保证行为的。pt_regs 偏移、syscall 参数位置、内存读取方式，两个架构根本不是一回事。Scope 的老探针当年只给 x86_64 写，谁敢保证它在 arm64 上加载后读出来的是对的？这种错不是代码里写死一个 bug，而是"看起来能加载，跑起来数据是歪的"——比编译失败毒得多。
Antigravity 干的事——解析仓库结构、诊断构建障碍、重构 Dockerfile 和 buildx、自动生成多架构清单——值钱，我不否认。但全程都在第三层。它没让 eBPF 探针在 arm64 上多加载一次，没画出一张 arm64 宿主机上的实时拓扑，没验证那套 host PID 采集逻辑有没有架构相关的 bug。它把外层打包好，让镜像能推上去。这跟"活了"之间，隔着一整条验证层。
Weave Scope 当年的情况很典型：仓库归档，依赖树整个冻结，Makefile 只给 amd64/x86_64 写，C 库老到新的交叉编译工具链都未必认。手动升级到支持 ARM64 和 AMD64 的 buildx 工作流，传统上要花几天：坏掉的 Go 包一个个换，过时的 C 库一个个对，打包脚本里的架构判断一个个改。这些债，AI 干得快。但你得分清，这些全是第三层的债。地基债——eBPF 探针的跨架构正确性——它没碰，大概率也碰不了。
再看那行快速启动命令，这是我最不舒服的地方：
docker run --privileged --pid=host --network=host \
-v /var/run/docker.sock:/var/run/docker.sock \
marioezquerro/scope:latest
特权模式，等于把宿主机 root 给了容器。host PID namespace，等于容器能看见宿主机所有进程。挂 Docker socket，等于容器能控制宿主机 Docker。三样叠一起，容器出岔子不是它自己挂掉，是宿主机跟着遭殃。你自己本地跑，我一句话不说。但把它当"快速启动"到处发，不补一句风险提示，这是把别人往裸奔里带。
我知道有人会说，这只是个 demo，别上纲上线。可观测性工具就不是 demo 友好的东西。它的核心卖点是"让你看见宿主机和容器的真实拓扑"。如果这个"看见"在 arm64 上其实看不见，或者看见的是错的，你跑通 demo 又算什么？Demo 跑通只证明镜像能启动，不证明探针能工作。一个能启动但探针不加载的 Scope，还不如一个装睡的人——装睡的人至少不给你错误信息，它会。
这种叙事为什么流行？原因不复杂：构建流程是工程里唯一能一顿饭工夫从"坏"变"好"的部分，而且它还能截图。修好 Makefile，生成一波 multi-arch image，Docker Hub 上一排绿色架构标签，发出去就是一篇爽文。eBPF 对不对、privileged 该不该用、arm64 上拓扑准不准，这些问题没有一个能一下午出答案。它们不截图、不发绿标，所以被自动忽略了。
评论区已经有人把话说到点子上：代理能一个下午解决冻结的 Makefile 和多架构 Docker 流程，但 eBPF、内核组件、特权主机挂载得另说，只有看到 Scope 在 arm64 和 amd64 上映射出实时拓扑，才能算真活了。这个判断我完全同意。多架构清单只保证镜像能拉下来、二进制是 arm64 的，不保证这个二进制在 arm64 内核上加载 eBPF 时不被拒绝，也不保证 host PID namespace 里的采集逻辑没有架构相关的坏假设。把"能构建"当成"能工作"，这是这一行现在最普遍的自欺。
工具能替你修外围，修不了你埋在内核里的雷。一个项目的"活"，不是看它能不能被 docker run 拉起来，是看它在目标架构上有没有产生正确行为、权限边界清不清楚、出了问题你有没有止损点。三样全省了，只把 Dockerfile 修通，那叫给烂地基刷漆。而且刷漆这件事在 AI 时代被放大得特别厉害——agent 太擅长刷漆了，不怕繁琐、不怕试错、不怕重来，一个下午能把你看得到的外围弄得漂漂亮亮。越是这样越要警惕：漂亮的外围会让人忘记真正的地基还在渗水。欠的债迟早要还，工具只是把催债时间往后推了几天。
如果让我给这个复兴定个验收标准，我不看 Docker Hub 上有几个架构标签。我看三件事：
- 在 x86_64 上先跑出原版 Scope 的行为基线：哪些探针正常、哪些已知坏、Web UI 能画到什么程度。没有基线，后面全是瞎对照。
- 在 arm64 上同一套验证跑一遍：eBPF 程序能不能加载、能不能在 host PID namespace 里正确读进程、Web UI 能不能实时映射拓扑。这一步不是在 QEMU 里跑个容器就叫验证，得在真实 arm64 宿主机上跑。
- 把特权参数逐个拆掉：
--privileged能不能换成具体 capability？--pid=host是不是必须？Docker socket 能不能用只读挂载？每拆掉一个，就少一块裸奔面积。拆完剩下的，才是真正必要的高风险边界。
三件事做完，才轮到多架构镜像发布。顺序不能反。反了，你就是在用一个没验证过的内核级工具去教别人开三扇大门。不是帮忙，是埋雷。
我把话说重了，特别是对一个下午的尝试。一个下午能把冻结两年的构建链修到能推多架构镜像，这本身不差，比很多半途而废的"复活计划"强。但如果这篇文章停在"我做完了，大家快去用"，没把"我还没验证"这半句补上，就是半桶水晃荡——响得最亮的地方，往往不是最深的地方。
我也可能是错的。Antigravity 也许把里面 eBPF 的事顺手也处理了，作者也许在 arm64 上已经看到实时拓扑了，只是文章里没写。要让我改观，拿工程证据来：arm64 上实时拓扑截图、eBPF 加载日志、权限收窄后的命令。别拿 Docker Hub 的 manifest 给我看，那东西证明不了正确性。
我的态度很明确：别再把"能构建"和"能工作"混为一谈。工具能替你修 Makefile，修不了你埋在内核里的雷。一个工程师真正值钱的部分，从来不在构建流程上，在你敢不敢为那串特权参数负责。先把验证做出来，再谈复兴；验证没出来，那叫重新打包。