无限缓冲区：为何 AI 代理正在重建 Lisp 机器

Source: Dev.to

The GUI Trap

在过去的十年里，软件开发工具的演进被一个单一的指令所驱动：视觉人体工学。我们构建了 VS Code、IntelliJ 和 Zed 等工具，使其对人眼直观友好，优化像素级渲染、鼠标交互以及通过菜单的可发现性。

但随着大语言模型（LLM）的兴起，这种视觉指令已成为一种负担。当 AI 代理尝试使用现代 IDE 时，它会面对一堵不透明的像素墙。要执行一个简单操作——比如打开文件或运行测试——它常常必须在复杂的可访问性树中导航，或是臆造坐标点击。正是让 IDE 对人类友好的特性，使其对机器变得敌对。

当前的人工智能本质上是大规模的文本处理。如果我们想构建真正的 AI 控制平面，就必须摒弃屏幕的概念。高效的 AI 环境不应是按钮的集合，而应是 缓冲区 的集合。

• 文件系统 – 与其使用文件树小部件，AI 需要一个列出文件的文本缓冲区（例如 dired）。
• 进程管理 – 与其使用“终端标签页”，AI 需要一个读‑求‑输出循环（REPL），其中输入和输出仅仅是字符串。
• 状态 – 与其使用隐藏的内存结构，AI 需要编辑器自身状态的文本表示。

在这种范式下，读取世界状态就是 read()，改变世界就是 write()。所谓的“UI 导航”摩擦随之消失。

这并不是新想法。它正是 Lisp Machine 的哲学，似乎已被历史遗忘，却在一个持久的产物中得以保存：Emacs。Emacs 常被嘲笑为“缺少好编辑器的操作系统”，但正是这种架构特性正是 AI 代理所需要的。在 Emacs（以及 Lisp 环境）中，编辑器 与 用户代码 没有区别——一切都是数据，一切都是可塑的。

• 自省 – 代理可以查询它即将调用的函数的文档。
• 可扩展性 – 代理可以在运行时重新定义有缺陷的函数，而无需重启环境。

这种代码/数据二元性（同构性）使得代理能够成为系统的参与者，而不仅仅是外部操作员。

ZEMACS: A Headless Control Plane

为了演示这种架构，我们构建了 ZEMACS。ZEMACS 是一个“无头控制平面”，通过模型上下文协议（MCP）暴露 Lisp Machine 的语义。它完全剥离了 GUI，只保留编辑器的纯文本本质。

ZEMACS 为 AI 提供了：

• 通用搜索 – 将 grep 和 find 作为一等原语。
• 持久 REPL – 在“思考”之间保持状态的 Python/Bash 会话。
• LSP 集成 – 将类型定义和诊断作为文本流提供。

通过把编辑器视为文本 API 而非视觉应用，我们发现代理的能力、自治性和可靠性显著提升。

AI 辅助编码的未来不是在侧边栏中放一个更好的聊天机器人；而是一次回归 文本中心计算 的根本架构转变。当我们构建下一代开发者工具时，应该停止“为 AI 打造更好 GUI”的尝试。我们应该构建 无限缓冲区，并重建 Lisp Machine。

因为，归根结底，对 AI 来说，文本不仅仅是一个界面——它就是整个世界。