我们有兴趣融入 VSCode 通过 SSH 进行远程编辑的工作流程，因为现在每个人都在使用 VSCode，特别是他们使用的 VSCode 分支版本，这些版本利用 LLM 生成代码。
当 LLM 生成错误的代码时，我们称之为“幻觉”；当人类这样做时，我们称之为“工程”。
如果你知道自己在做什么，LLM 生成的代码在一般情况下是有用的。但如果你能在 LLM 和执行环境之间形成闭环（通过“代理”设置），它就极其有用。关于这一点有很多可说的，但就目前而言：这是对幻觉的一种半有效的解药：LLM 生成代码，代理脚手架运行代码，代码产生错误，代理将其反馈给 LLM，过程迭代。
所以，显然，问题在于你不希望这种迭代开发过程发生在你的开发笔记本电脑上，因为 LLM 有边界问题，它们会同样乐意地在你正在工作的 Git 项目上迭代你的系统配置。你真正希望能够做的一件事：在一个即时启动且不会以任何方式搞砸你的干净 Linux 实例上，为 LLM 运行一个闭环的代理式（“代理式”？我们现在是这么说的吗）配置。你明白我们的意思。
总之！我想提出一个担忧。
Emacs 托管了远程编辑系统的精神先驱，一个名为“Tramp”的超有用 Elisp 代码块。如果你能将 Tramp 连接到任何类型的交互环境——通常是 SSH 会话——在那里它可以运行 Bourne shell 命令，它就能将 Emacs 扩展到该环境。
所以，VSCode 有一个类似 Tramp 的功能。这很酷，对吧？你会想，拿 Tramp，也许简化一下，把 Elisp 换成 Typescript。
你想错了！
与在远程连接上就地取材的 Tramp 不同，VSCode 发动了全面入侵：它运行一个 Bash 片段暂存器，下载一个代理，包括 Node 的二进制安装。
我认为这是源代码？
代理通过端口转发的 SSH 运行。它建立一个 WebSockets 连接回你正在运行的 VSCode 前端。该连接上的底层协议可以：
- 在文件系统中游荡
- 编辑任意文件
- 启动自己的 shell PTY 进程
- 持久化自身
在安全界，对于以这种方式工作的工具有一个名称。我不会大声说出来，因为这对 VSCode 不公平，但让我们只说这个名字本质上是鼠类。
我会对让人们 VSCode 远程编辑开发服务器上的东西感到有点紧张，如果在生产环境中的事件期间发生这种情况，我会非常愤怒。
事实证明，我们不必关心任何这些就能让自定义连接到 Fly Machine 在 VSCode 中工作，所以这些都不重要，但：我们决定再次成为一个博客，所以：我们不得不学习这个，现在你也得学了。