每个运维都遇到过
凌晨三点告警。某个端口在监听，某个进程在烧 CPU，某个容器在跑。你 SSH 上去，开始问那个最古老的问题：
> 这玩意儿为什么在跑？
然后你开始拼图：
– ps aux | grep xxx——找到进程 PID
– lsof -i :8080——找到端口占用
– systemctl status xxx——看是不是 systemd 起的
– docker ps——看是不是容器
– pstree -p——看父进程链
– 翻 shell history 看是谁、什么时候、用什么命令起的
五个工具，五次输出，你在脑子里做关联。系统告诉你”什么在跑”，但不告诉你”为什么在跑”。
witr（Why Is This Running）就是来填这个缺口的。单日 GitHub 涨 308 stars，Go 写的单二进制，一行命令把整条因果链给你画出来。
核心概念：causality chain
witr 的 README 里有一句话值得停下来想：
> Existing tools (ps, top, lsof, ss, systemctl, docker ps) expose state and metadata. They show _what_ is running, but leave the user to infer _why_ by manually correlating outputs across tools.
这个区分很重要：state vs causality。
ps 告诉你 PID 12345 是 node 进程，CPU 80%。但它不告诉你这个 node 进程是被谁起的、为什么被起、属于什么服务链。
witr 做的是causality tracing——追溯一个 running thing 的完整启动链：
systemd → pm2 → node app.js
这一行就回答了”为什么在跑”：systemd 在开机时启动了 pm2，pm2 守护了一个 node 应用 app.js。不是三个工具的三个输出，是一条因果链。
三种模式：CLI、JSON、TUI
witr 的输出有三种形态，对应三种使用场景：
1. CLI 人类可读输出：终端里直接看因果链，适合调试时用 2. JSON 机器可读输出：管道给其他工具，适合自动化告警和审计 3. 交互式 TUI：dashboard 式浏览，适合复杂场景的多跳追溯
三种模式共享同一个 tracing engine，区别只是 presentation layer。这个设计让我想到 Unix 哲学的一句话：“do one thing, do it well”——witr 做的就是 causality tracing 这一件事，输出形态只是接口。
它能追溯什么
witr 支持四种”running thing”作为入口：
– process：给定 PID，追溯启动链 – port：给定端口号，找到监听进程，再追溯启动链 – container：给定容器 ID，找到宿主进程，再追溯启动链 – file：给定文件路径，找到访问它的进程，再追溯启动链
四种入口共享一个核心：从”结果”反推”原因”。
这和分布式系统的 distributed tracing 是同构的。OpenTelemetry 做的是”一个请求穿过多个服务的因果链”，witr 做的是”一个 running thing 穿过多个系统层的因果链”。区别只是层级不同：OpenTelemetry 在服务间，witr 在 OS 层内。
为什么这个时间点火
witr 不是第一个做 process tracing 的工具。pstree、htop、atop 都部分做了类似的事。但 witr 在 2026 年 8 月单日涨 308 stars，有三个时机因素：
1. 容器化让因果链更复杂了
pre-container 时代，一个进程的启动链通常是 init → shell → command，两三跳。container 时代，启动链可能是 systemd → dockerd → containerd → containerd-shim → container init → shell → app，六七跳。人脑关联的极限是三四跳，超过就需要工具。
2. AI agent 时代让”为什么在跑”更难回答
当 AI agent 可以自主 spawn 进程、启动服务、创建容器，”为什么这个进程在跑”变成了一个 harder 的问题——它可能不是人起的，是 agent 起的，而 agent 的决策链可能不透明。witr 的 causality chain 可以帮助审计 agent 的副作用。
3. 单二进制 + 全平台
witr 是 Go 写的静态二进制，Linux/macOS/FreeBSD/Windows 全平台。Homebrew、APT、Winget、Conda、AUR、MacPorts 全打包。安装门槛极低——brew install witr 就完了。这是 Go 生态的优势：cross-compile 出来的单二进制可以覆盖几乎所有平台。
一个值得深想的设计
witr 的成功标准（README 里明确写了）不是”能追溯所有东西”，而是：
> witr succeeds when it can produce a complete, accurate, and human-understandable causality chain.
注意三个形容词：complete（完整）、accurate（准确）、human-understandable（人类可理解）。
前两个是技术指标，第三个是认知指标。一个 causality chain 如果需要你懂内核数据结构才能看懂，那它和 pstree 没区别。witr 的差异化在于：它的输出是给人类看的因果故事，不是给机器看的元数据 dump。
这个设计原则让我想到一个更广的观察：系统工具的下一波创新不在”能做什么”，而在”能不能讲清楚为什么”。ps 能列进程，lsof 能列文件描述符，ss 能列端口——它们都在回答”what”。witr 回答的是”why”，而”why”是运维最频繁被问、却最少被工具直接支持的问题。
链接
– GitHub: https://github.com/pranshuparmar/witr – 在线试用: https://pranshuparmar.github.io/witr/ – Hacker News 讨论: https://news.ycombinator.com/item?id=46392910
—
一句话总结：witr 不告诉你”什么在跑”，告诉你”为什么在跑”——把 ps/lsof/systemctl/docker 五个工具的拼图工作，变成一行命令的因果链。