proxxx：把 Proxmox 集群塞进一个终端 cockpit
很多 homelab 和小团队的 Proxmox 集群，最后都会长出一套零散脚本：一个查 VM 状态，一个临时迁移，一个从 PBS 拉备份，一个在事故时提醒自己不要手滑删东西。Web UI 能做大部分操作，但放进 on-call、CI 或 repeatable runbook 里时，终端仍然更顺手。问题是，终端工具一旦能写入基础设施，就不能只是一个漂亮 TUI。
今天看的是 fabriziosalmi/proxxx。它是一个 Rust 写的 Proxmox VE / Proxmox Backup Server terminal cockpit，把 CLI、TUI、MCP server、alert/HITL daemon 放在同一个 proxxx 二进制里。README 的核心取向很明确：不在集群里额外部署 daemon，而是通过 PVE/PBS 现有 REST API 和 SSH 做管理；读操作要快，写操作要经过 pre-flight risk gate，必要时再通过 Telegram 做 human-in-the-loop 审批。
按 GitHub repository API、README、LICENSE、Cargo.toml、latest release、tags 和 commits API 在 2026-08-29 18:03 Asia/Shanghai 能核验的信息，fabriziosalmi/proxxx 当前有 23 stars、2 forks。主要语言是 Rust，许可证是 MIT，默认分支是 main，仓库创建于 2026-05-01 17:08:46 UTC，latest push 是 2026-08-29 10:02:39 UTC。最近提交是 8a4888d，提交时间 2026-08-29 09:58:22 UTC，主题是更新依赖以清理供应链审计失败。最新 GitHub Release 是 v0.13.2，发布时间 2026-07-07 13:57:40 UTC；Cargo.toml 里的 crate version 也是 0.13.2，MSRV 标为 Rust 1.95。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | fabriziosalmi/proxxx |
| 定位 | Proxmox VE / PBS 的 Rust TUI、CLI、MCP server 与运维 cockpit |
| Stars | 23 |
| Forks | 2 |
| 主要语言 | Rust |
| 许可证 | MIT |
| 创建时间 | 2026-05-01 17:08:46 UTC |
| Latest push | 2026-08-29 10:02:39 UTC |
| 最近提交 | 8a4888d，2026-08-29 09:58:22 UTC |
| 最新 Release | v0.13.2，2026-07-07 13:57:40 UTC |
| 关键词 | Proxmox、TUI、CLI、GitOps、HITL、MCP、audit log |
它不是只做一个 Proxmox TUI
proxxx 的入口看起来像熟悉的 terminal dashboard：proxxx 打开 TUI，proxxx ls nodes、proxxx ls guests、proxxx fleet 可以快速看节点、guest、storage 和多集群概览。README 里强调它能在一秒内 cluster-wide read，也支持 fuzzy search、fleet view、cross-cluster find <vmid>，这些都很适合每天在几个 PVE 节点之间来回切的人。
但它真正有意思的地方，是把只读巡检和危险写操作分开处理。README 里列了很多 write path：start、stop、migrate、snapshot、clone、backup、patch、disk move。对这些操作，proxxx 做了 per-guest 和 state-change 两类 pre-flight risk gate，例如运行中、长时间 uptime、HA 管理、非空 pool 删除、root role ACL 删除、shared storage 删除、bulk change 等。也就是说，它不是让终端操作变得更快之后就结束，而是先承认“更快”本身会放大误操作。
这点对 Proxmox 特别重要。PVE 经常服务于 homelab，也经常服务于小公司的真实业务。前者想要单 binary、少配置、能在 SSH 会话里快速处理；后者需要 audit、审批、可重放命令和 CI 友好的 JSON。proxxx 试图把这两类需求放在一个工具里，而不是只面向其中一端。
GitOps 和 incident freeze 是值得看的部分
README 里的 proxxx state {export,diff,apply} 很像把 Proxmox 配置做成可审查的 desired state。它会导出 byte-stable TOML，覆盖 pools、ACL grants、storage definitions、backup jobs、cluster firewall、notification matchers、HA rules/resources、PCI/USB device mappings 等 state family，然后支持 diff 和 apply。
这种设计的实用点不是“把 Proxmox 变成 Kubernetes”，而是让小型虚拟化环境也有一个能进 git、能 code review、能 CI gate 的声明式层。比如你可以在 merge 前跑 drift check，或者先 dry-run 一次 state apply。README 还提到 reconcile run、reconcile converge，以及 opt-in 的 auto_converge daemon；但 severe change 不会被无人值守自动应用，而是转成 alert 等人确认。
incident freeze 也很像一个真实运维工具会长出来的功能。proxxx incident freeze --reason X --ttl 4h 会冻结 cluster-wide mutation，读操作保留，thaw 之后恢复。这不是花哨功能，而是在事故调查或高风险窗口里避免“我只是想看一下，顺手点错”的保护层。
MCP server 的边界感比常见 agent 工具更好
现在很多基础设施项目都会加 MCP server，但真正麻烦的是权限边界。proxxx README 写到它提供 stdio JSON-RPC 和 HTTP/SSE transport，工具 registry 是 compile-time fixed，并且 destructive tools 默认 fail-closed：除非有匹配 policy 把它们路由到 HITL approval，否则拒绝执行。HTTP serve 默认只绑定 loopback；非 loopback bind 需要 mcp_token。
这比“把集群交给 agent 管”要靠谱。对于 LLM / agent integrator，最小可用路径应该是让模型读取 cluster digest、查节点、查 guest、做解释，而不是直接赋予迁移和删除能力。proxxx 的 describe --output llm-context 也很实用：它生成 token-compact 的文本上下文，可以贴给 AI chat 做辅助诊断。这里的姿势是先增强人的操作，而不是让 agent 直接接管虚拟化平台。
安装和供应链细节做得比较认真
proxxx 提供 Homebrew、.deb、Linux musl 静态二进制和从源码构建路径。README 里不仅给了下载命令，还明确列出 SHA-256、sigstore keyless cosign signature、CycloneDX SBOM 的验证流程。最新 release v0.13.2 的 assets 也确实包含 macOS Apple Silicon、Linux x86_64/aarch64 musl tarball、sha256、cosign bundle 和 SBOM 文件。
对一个 23 stars 的小项目来说，这个供应链投入有点超规格，但也符合它管理基础设施的定位。一个能关 VM、迁移磁盘、改 firewall 的工具，release 验证不应该是 README 末尾一句“trust me”。它还标榜 zero telemetry，本地 config/cache/audit log 放在用户控制的路径下，audit log 用 SQLite 和 HMAC-SHA256 chain 做 tamper signal。这些都不是替代正式合规系统，但至少让工具作者知道它运行在哪个风险层。
适合谁
第一类是 Proxmox homelab 用户，尤其是已经有 1-3 个节点、经常在 Web UI 和 SSH 之间来回跳的人。单 binary、TUI、ls guests、console handoff、PBS browse/restore 这些功能会马上有用。
第二类是小型平台或 SRE 团队。你可能还没到引入大型私有云平台的规模，但已经需要 JSON 输出、risk gate、HITL、audit log、drift check 和批量操作。proxxx 可以作为一个更可审查的 Proxmox 操作入口。
第三类是想把 LLM 接到基础设施可观测层的人。MCP server、read-only profile、destructive tool fail-closed、loopback-only HTTP 默认值，让它比很多“agent ops”项目更适合先做受控实验。
Caveats
第一，它是一个很新的项目，stars 只有 23，虽然最近提交活跃，但真实用户规模和长期维护节奏还需要观察。生产环境最好先从 read-only profile 和测试集群开始。
第二，功能面非常宽。TUI、CLI、GitOps、MCP、HITL、audit、PBS restore、console handoff 都在同一个 binary 里，优点是统一，风险是每条路径都需要自己验证。不要因为 README 覆盖面大，就跳过 staging。
第三，它的场景很垂直。如果你不用 Proxmox VE/PBS，它不是通用终端运维工具。如果你已经有成熟的 Terraform/OpenTofu、Ansible、监控和审批系统，proxxx 更适合作为 Proxmox-specific cockpit，而不是替换整套平台工程。
总结
fabriziosalmi/proxxx 值得关注的地方，是它把 Proxmox 终端管理从“更快的命令”往“更可控的操作系统”推了一步。TUI 和单 binary 降低了使用门槛，risk gate、HITL、incident freeze、audit log、release verification 又把危险操作的边界拉了回来。
它还早，必须谨慎试用；但如果你维护的是一个真实承载工作负载的 Proxmox 集群，而不是玩具环境，proxxx 的设计问题意识是对的：终端工具不只要顺手，还要在你手快的时候拦你一下。