我们想接入代码编辑器 Visual Studio Code（VSCode）通过 SSH 远程编辑的流程，大家都在用 VSCode，尤其是用大语言模型（LLM）生成代码的分支。LLM 写错代码叫幻觉，人做对才叫工程。如果能用代理把 LLM 和执行环境闭环连接，让代码运行、报错、再反馈给 LLM，循环迭代，LLM 生成的代码就会格外有用。但这不该跑在开发笔记本上，LLM 边界感差，会改系统配置，也会折腾你正在做的项目。最好跑在闭环代理配置里。
正文
我们想接入 VSCode 通过 SSH 远程编辑的工作流，因为现在人人都用 VSCode，尤其是那些用 LLM 生成代码的 VSCode 分支。
LLM 写错代码叫“幻觉”，人写错叫“工程”。
如果你懂行，LLM 生成的代码通常有用。但要是能打通 LLM 和执行环境之间的闭环（用“Agent”架构），就极其有用。这能部分缓解幻觉：LLM 生成代码，Agent 脚手架运行代码，代码报错，Agent 把错误反馈给 LLM，如此迭代。
显然，你不想让这种迭代开发发生在开发笔记本上，因为 LLM 没有边界感，它会像迭代 Git 项目一样乐意迭代你的系统配置。你真正想要的是：在一个瞬间启动、绝不会搞砸你的干净 Linux 实例上，为 LLM 运行闭环 Agent 配置。
不过，我想提个担忧。
Emacs 有远程编辑系统的精神先驱，一段极有用的 Elisp 叫 “Tramp”。只要把 Tramp 连到任何能跑 Bourne shell 命令的交互环境（通常是 SSH 会话），它就能把 Emacs 扩展到那个环境。
VSCode 有个类似 Tramp 的功能。你以为会是取 Tramp 稍简化，把 Elisp 换成 TypeScript？错了！Tramp 在远程连接上就地取材，VSCode 却是全面入侵：它跑一段 Bash 暂存脚本，下载一个 Agent，包含 Node 的二进制安装。
Agent 通过端口转发的 SSH 运行，建立回到 VSCode 前端的 WebSocket 连接。该连接的底层协议可以： * 在文件系统里乱逛 * 编辑任意文件 * 启动自己的 shell PTY 进程 * 自我持久化
安全界给这种工作方式的工具起了个名字。我不明说，对 VSCode 不公平，但可以说这名字本质上带有“信徒”意味。
要是让人在开发服务器上用 VSCode 远程编辑，我会有点紧张；要是生产事故时这么干，我会抓狂。
结果我们发现，要在 VSCode 里连上 Fly Machine 自定义连接，根本不用管这些，所以深层看都没关系。但我们决定还是做个博客，所以我们弄明白了，你们也得明白。
评论
讨论整体倾向于「这不是漏洞，而是远程开发工具的设计本意」，但围绕微软把双向通道做成了默认架构、且远程可反向在本地执行代码这一点，出现了明确的安全派反驳。分歧主轴是：该由使用者自己搞清楚信任边界，还是工具本身就制造了一个被误认为沙箱的陷阱。
认为这本来就是远程开发的正常设计
- 远程 agent 的职责就是让远端成为本地的延伸：跑扩展、起容器、装包、转发端口，穿隧道属于功能集合的一部分；把它装在生产服务器上还惊讶于它的行为，是使用者的问题（较多人）
- 通过 SSH 传二进制做自举是自然选择，因为不能假设远端能访问公网；一个专门用来改文件、跑命令的程序能干这些事，算不上离奇（较多人） > agent 本来就该跑在远程开发机上，如果你把它装到生产服务器还对它的行为感到意外，那是你自己的问题。（@binlog）
- 有人补充 VSCode 的 SSH 扩展在多个团队大规模使用过，从未出问题，访问权限可以任意收紧（少数人）
- 也有人认为对大型开发团队而言，这套扩展加 devcontainer 基本就是正解（少数人）
认为真正的风险是反向的本地代码执行
- 关键不在于远程能改文件跑命令，而在于远程可以反过来在本地机器上执行代码；微软官方扩展的安全声明自己就写明了这一点（高赞） > 官方声明写得很清楚：被攻陷的远程端可以利用 Remote 连接在你的本地机器上执行代码，那这就算不上什么沙箱。（@Rapzid）
- 有评论追问文章里的方向到底指向哪台机器：如果 websocket 是让远端反过来操纵本地前端，那才是真正疯狂的设定（较多人）
- 有人明确划线：反向的「远程对本地为所欲为」不可接受，正向那部分可以接受（较多人）
- 有人指出 2025 年至今这一点完全没有改善，反而有更多人误以为用虚拟机或远程 SSH「沙箱」开发是安全的（较多人）
- 有评论说问题的放大点在于它现在披着 AI agent 的外衣，安全顾虑被显著拓宽（少数人）
认为「这不就是 RAT 吗」的类比站不住脚
- Tramp 当年同样能漫游文件系统、编辑任意文件、起 shell，SSH 本身允许远程执行 shell 时就是 RAT 的原型，不必为此惊慌（较多人） > Tramp 能干同样的事，而 SSH 本身就是那类工具的鼻祖，不明白为什么有人被吓到。（@Joker_vD）
- 有人直接点出文章绕来绕去，其实是在回避「rootkit」这个词（少数人）
抱怨的是臃肿、专有与不可替代
- 连上几台机器后自动装 node、npm 和几百 MB 依赖，还常驻一个 node 服务，这种体验让人再也不用 VSCode 的 SSH（较多人）
- 该扩展在 VSCodium 里直接不可用，而且没有像样的替代品（较多人）
- 有人因此长期避开 Zed，后来发现 Zed 也有远程 SSH，专门提醒嫌 VSCode 臃肿的人（少数人）
- 有人尝试在云主机上跑
code serve-web、经 Tailscale 暴露，浏览器里用 VSCode 加 neovim，本地几乎不装东西，目的就是减少 SSH 配错和扩展被攻陷的攻击面，效果意外地好（少数人） - 也有人反问为什么不用 sshfs，这东西在 VSCode 出现之前就用了很多年（少数人）
认为 agent 的权限边界应该收得更紧
- 有人自己的 agent 设计约束是走不出工作目录，甚至连该目录的完整路径都不许猜；对比之下 VSCode 走的是完全相反的方向（较多人） > 我希望它只把我自己会敲的命令输进命令行，让我看得懂它在做什么，也不会被结果吓到。（@walrus01）
有价值的补充
- 有评论梳理出机器角色的混乱：本地是前端、远端是沙箱后端，如果 websocket 允许的是前端在沙箱上跑命令，那并不稀奇，因为 SSH 本身已经能做到；真正可疑的是反方向。
- 有人翻出 2025 年 2 月的一个早期观察：LLM 生成的代码在你清楚自己在做什么时通常有用，但把 LLM 和执行环境闭环起来（即 agent 形态）会带来数量级的提升，被认为判断得相当超前。
- 有读者特别称赞原文结尾那种「我们发现这些都不重要，但我们又变成博客了，所以还是得学，现在你也得学」的坦率语气，认为在人人都在猜文本是不是 AI 写的年代，这种写法格外可贵。
- 有人感慨 2025 年那篇吐槽放到 2026 年看已经显得古雅，隐含行业变化之快。
- 有人表示自从改成口述指挥 AI，已经基本不用任何 GUI，终端就够了。
- 一条玩笑：既然这样，我的开发机也该改叫 Fly Machine。