原文：重新思考Agent和编辑器 - From Chaofan
目前的Agent或者Cursor这样的编辑器，并没有像Emacs一样暴露出一个实时环境，也没有一个M-x一样的接口。Emacs的mode设计和M-x命令天然符合LLM tool call这个模式。所以理想的跑在Emacs的Agent，不应该是对话和执行命令的简单复刻，而可以：
这是只有Emacs才能做到的事情。
我觉得现在Agent已经有很完美的harness environment了，根本没有必要专门去兼容Elisp，Emacs是多动手指来提升效率，Agent时代动动嘴皮子的事儿，语音输入git push比C-g g P p 方便多了
deepseek发布的harness就像一个受限的简化的lisp机器
动态的修改代码运行环境实际上并不困难，很多语言都可做到，但故意不做，或把这点做得很难用，隐藏的很深，说白了就是不认可这个功能，不相信用户，认为用户会自己把运行环境搞废掉。 所以这才是只有emacs才能做到的事
最近也在考虑这个问题, 理论上能实现, 但是可能会增加复杂度, 或者影响效率, 还会涉及安全问题, 最终不划算.
比如agent读文件, 如果用emacs的buffer打开, 再读取buffer里的内容, 或者在buffer里搜索, 效率真的会高吗? 因为工程文件可能非常多, buffer不能一直打开着, 会消耗很多内存, 所以用完就得关闭, 每次访问一点内容就反复用emacs打开关闭文件, 效率可能并不高.
其次, 让agent运行elisp代码, 这个需要沙盒来保证安全, 但emacs没这个功能, 而且实现也麻烦. 实现后, 得到的收益可能并没有多高(因为上面的原因).
emacs的运行时环境对agent来说可能价值没那么大, 还是更适合人来操作.
按ai的说法就是把文本存buffer里打开，读取效率最高，比存硬盘上在打开关闭高很多, ai会告诉你文件数量越多越应该用buffer
动态eval一段ELisp代码修改环境
并不觉得 agent 需要一个 emacs 的运行时。对于 agent 来说，写 typescript / python 不比写 lisp 容易？它们也都支持热重载，生态还完善的多。
根据当前上下文的mode、buffer、布局，动态地模型一组可用的命令列表，这样Agent不光是能补全，还能感知用户编辑器的上下文
emacs 是一个 lisp 解释器加上基于其上构建的编辑器。人类需要编辑器提供的可交互的操作环境，agent 不需要。补全和感知用户编辑器的上下文都不再是什么很有必要的事情了。以现在的agent 的理解能力，你用最简单的语言模糊描述一下场景，agent 就知道你指的到底是什么场景了。人也不会在编辑器里面仔细的看代码了，一目十行的扫一下就行了。人类未来用编辑器的场景：1. 改配置文件，这种时候自己改比 agent 快，或者 agent 还没配置好需要自己操作一下。2. 使用 orgmode/markdown 来进行古法写作，心流写作，这种时候也不是需要 agent 干活的时候。
这个, 我上面已经说了, 在内存里肯定快啊, 但是问题也说了.
一个工程有很多文件, 而ai会访问大量文件, 有时候甚至是工程外的sdk源码, 大量的文件没法在emacs里同时打开, 因为太耗内存了. 这样它就要关闭一些. 很可能会遇到用emacs频繁打开再关闭的情况, 这样效率可能并不高. 另外, 如果agent只需要grep一下, 那它用emacs打开后搜索的代价比直接用rg还要大, 文件系统也有缓存, 不一定比emacs的buffer里慢.
让agent用emacs, 远不如用专门的代码库索引工具.
这篇文章其实设想的是如果 emacs 的各个部分都能被 agent 进行调动，将会产生许多精妙的组合和效果。由于 emacs 的高度可定制性，这是可行的，而且对于 elisp 工具的编写会相当有利
AI时代来了，IDE会消失，编程语言会消失， Emacs也许也会消失
前AI时代，Emacs/Vi的效率来源于手动写代码，心流合一的快捷体系和效率
AI时代，手机 + 语音输入法就可以交付软件了，以前享受编程细节的体验和工具不再有，而提供这些高级体验的工具（比如Emacs）也会随之消失
不用担心。本无钱财家累,何谈消失。
我不担心，我现在都很少打开Emacs了，手机电脑都用我家硬件的 LightOS, 走到哪豆包语音输入法说到哪
开完会，健完身，程序全部自动写好了
现有的各种支持MCP的agent比如claude code, codex等等配合Emacs MCP就能做到，最简单的情况，expose a tool, 允许agent eval elisp就行了。可以为人服务，也可以自动化一些事情。
眼下AI大行其道的时候，但AI毕竟是由人来操控的。至少有两件事情还是得人来做，1, 编辑 & reuse prompt，操控AI，给AI提供context; 2. 检查AI的工作成果，因为AI不会为结果负责任。个人看法，emacs在这两件事情上都有很大的发挥空间，而且因为这么多年的历史积淀和进化，别的从0开发的软件想赶上来不是一两天能做到的事情，就算AI开发软件再快，结果好不好用还是需要人和时间来给出答案。另一方面，已经存在的用户的习惯也不是短时间内能变化的（参考现在键盘的布局历史）。
文件数量过多，grep rg也要卡一会的，emacs可控制打开到一定文件数量停止，grep rg我以前用一直没找到控制搜索文件数量的选项，似乎只能是等它目录全部扫完。
至于内存消耗问题，都用ai了还担心这个吗，ai本身的内存消耗就是有点夸张的，都要按电力算了，但大家好像都不在意这个问题
emacs 要改造：编辑区->显示为主；M-x 或 minibuffer → 交互输入框； deepseek harness做后端引擎; 快捷键机制 → 以M-x 命令使用为主
这个我也不清楚，不知道我看到的数据是不是做了夸张加工过的，据我所知，一些机房耗电量最大的似乎不是机器本身，而是防止机器温度过高的散热系统，夏天热带地区散热系统全速运转的功耗都超过机器本身功耗了（不过也可能是设计问题）
赞同楼上判断，我的判断和 emacs 没落论相反，我持 emacs 复苏论，我也认为 ai 反而给 emacs 了机会，我的相关发言：1 2 3 4
虽然总体是这么说，但是某种程度上，emacs 在手中变得没落还是复苏，确实是一个非常个人相关的判断：
很多耗电的地方, 比如框间连线的光模块也很耗电; 其实存在一些减少耗电的办法, 但是没人实现, 因为客户不在意这些, 做出来不赚钱(以上是我知道的部分, 不一定很准确