GitHub Trending 今天有一个很务实的工具：pranshuparmar/witr。仓库描述只有一句话：“Why is this running? Trace any process, port, container, or file back to what started it”。它不是 LLM 框架，也不是新的 coding agent，但我认为它对 Agent 开发者很重要。
因为 Agent 时代的开发机越来越像一台小型生产环境。一个长任务 coding agent 可能启动 Vite、Playwright、数据库容器、消息队列、worker、临时 HTTP server、模型 proxy、日志 watcher。半小时后你回到终端，看到 3000、5173、9229、5432、6379 都被占了，CPU 还在跑。此时真正的问题不是“有什么进程”，而是“为什么它还在运行”。
传统工具可以分别回答局部问题。ps 看进程，lsof 看端口，ss 看 socket，systemctl 看 service，docker ps 看容器。但它们要求人类把输出拼起来。witr 的价值在于把这些状态组织成因果链，让你更快判断一个运行中的东西来自 shell、systemd、PM2、Docker、测试 runner 还是 Agent 自己。
安装体验
witr README 显示，它以单个静态二进制发布，覆盖 Linux、macOS、FreeBSD 和 Windows，也有 Homebrew、Conda、Winget、NPM、AUR、FreeBSD Ports 等安装方式。最短路径是：
brew install witr或者：
npm install -g @pranshuparmar/witrLinux 和 macOS 也可以用安装脚本：
curl -fsSL https://raw.githubusercontent.com/pranshuparmar/witr/main/install.sh | bash工具类文章必须提醒一句：把远程脚本 pipe 到 shell 前要审查脚本内容，尤其是在公司开发机上。witr 是 Apache-2.0 开源项目，但安装方式仍应遵循团队供应链规范。
用在 Agent 开发机
最常见场景是端口冲突。Agent 昨晚跑完任务，今天你启动 dev server 发现端口被占。
witr :3000理想输出不是简单的 PID，而是启动链。例如一个 Node 进程可能来自 systemd 到 pm2 再到 node server.js；一个端口可能来自 Docker 容器内部服务；一个测试 worker 可能由 Playwright 启动后没有清理。
如果 witr 输出支持 JSON，就可以把它接进 Agent 质量门：
witr :3000 --json > .agent-runtime/port-3000.json
jq '.chain' .agent-runtime/port-3000.json这样当 Agent 报告“端口冲突已处理”时，你可以要求它附上证据，而不是只说 kill 了某个 PID。
清理长任务残留
长任务 Agent 的一大问题是残留资源。它可能在失败重试里启动多个 server，或者在测试中断后留下 orphan process。建议给项目加一个清理脚本：
#!/usr/bin/env bash
set -euo pipefail
mkdir -p .agent-runtime
for port in 3000 5173 9229 5432 6379; do
echo "checking port $port"
witr ":$port" --json > ".agent-runtime/port-$port.json" || true
done
echo "runtime evidence saved to .agent-runtime/"这个脚本不直接 kill 进程，而是先保存证据。为什么？因为在多人开发机或远程沙箱里，盲目 kill 很危险。你需要先确认启动链是不是当前任务创建的，还是别人的服务。
和 Docker 沙箱一起用
AI Agent 安全实践里，经常建议把任务放进容器或临时 VM。问题是容器多了以后，排障反而更难：某个端口是宿主机进程、Docker port mapping、Compose service，还是 Agent 在容器里又启动了子进程？
witr 的 README 明确把 process、port、container、file 都放在目标范围内，这让它适合作为沙箱入口检查：
witr docker:my-agent-container
witr :8080
witr ./tmp/generated-report.json如果工具能把文件追溯到写入进程，就可以帮助判断某个生成物来自测试、构建还是 Agent 的临时脚本。对审计来说，这比单纯看文件时间戳可靠得多。
TUI 与 JSON 的分工
witr 提供 CLI、machine-readable JSON 和 interactive TUI。三种形式面向不同使用者。
CLI 适合快速排障：开发者在终端里问一个端口或 PID。
JSON 适合脚本和 Agent：把证据保存到任务日志，交给后续检查或人类 review。
TUI 适合探索：当一台机器上有很多 supervisor、container 和服务时，用交互面板查看链路会比一堆命令更省认知成本。
对 Agent 工作流来说，JSON 最关键。Agent 可以把 witr 输出作为观察输入，但不应该只拿自然语言解释。结构化输出能进入 CI、审计和回归测试。
局限
witr 的核心价值在单机因果追踪，不是全栈可观测性。它不能替代 OpenTelemetry、日志平台、APM、Kubernetes audit log 或云厂商监控。它也不可能在所有平台上拿到同样深的启动链，因为 Windows、macOS、Linux、FreeBSD 的进程模型和权限机制不同。
另一个局限是权限。追踪某些进程、端口或容器需要更高权限。开发者不能因为工具查不到链路，就断定没有风险；也不能为了方便排障，让 Agent 获得不必要的 sudo 权限。
我会怎样评分
从工具定位看，witr 很聚焦，问题定义清楚，跨平台分发完整，适合纳入开发环境基建。我会给它 8 分。
加分项是：问题足够具体、输出形态覆盖人和机器、安装渠道丰富、与 Agent 残留进程排障高度相关。
扣分项是：它不是生产级可观测性闭环，跨平台深度可能不一致；在高权限环境中使用时，仍要搭配团队审计规范。
结论
Agent 开发的复杂性不只在模型，也在运行环境。长任务 Agent 会启动更多进程、占用更多端口、创建更多临时文件和容器。witr 用一句朴素的问题切中了这个痛点：Why is this running?
如果你已经在用 OpenCode、Claude Code、Codex、OpenChamber 或远程 Agent 沙箱，我建议把 witr 放进开发机工具箱。它不会替你设计安全边界，但能让你在清理、排障和审计时少猜一点。