做了个小工具：让本地 AI Agent 操作堡垒机后的远程 Linux 环境

[lenovobenben]

最近在用 Codex / Claude Code / Gemini CLI 这类本地 AI coding agent 时，遇到一个很现实的问题：

代码可以在本地改，但真正需要验证的环境在公司内网里，前面有堡垒机、跳板机、MFA 、私有 kubeconfig 或各种登录脚本。 我不想把 SSH key 、MFA 、token 、kubeconfig 之类的东西交给 AI agent ，也不想让它自己学公司登录流程。

所以做了一个很小的工具：tmux-remote-linux 。

思路很简单：

1. 用户自己在本地 tmux pane 里完成登录、跳板、MFA 、切换环境等操作。
2. AI agent 不直接 ssh ，不接触凭据。
3. 它只通过几个脚本读取/写入这个 tmux pane 。
4. 这样本地 agent 就能操作“最终目标机器/环境”，比如跑检查命令、看日志、验证部署结果。
5. 生产环境模式下，每条命令可以要求人工确认。

项目地址： https://github.com/lenovobenben/tmux-remote-linux

一个模拟 demo： https://github.com/lenovobenben/tmux-remote-linux/releases/download/v0.1.0/demo.gif

这个工具本质上不是远程管理平台，也不是安全边界，就是一个很窄的 tmux bridge 。 它的价值在于兼容现实里的企业访问路径：堡垒机、跳板机、MFA 、VPN 、内网 Kubernetes 、各种奇怪 shell 初始化。

想问问大家有没有类似场景？ 你们现在是怎么让 AI agent 做远程验证的？还是完全手动复制命令和结果？

[openercn]

这个思路很像把 Agent 的执行环境做成一个受控 bridge 。我们做云端 Android 真机时也遇到类似边界：不让 Agent 持有账号/凭据，只让它在人工已登录、可观察、可接管的会话里做读取、点击和验证。后面真正影响可用性的，可能是操作审计、超时回滚、人工确认粒度，以及失败时怎么把现场留给人接手。