推荐 GitHub - gdanov/emacs-gravity: Emacs idiomatic claude code UI · GitHub
感觉非常好用, 不像 claude-code.el 和 claude-code-ide.el 那样依赖于 eat/vterm 而存在渲染问题
emacs-gravity 基于 magit-section 来原生嵌入到 Emacs buffer 中, 同时对工具调用过程、多轮交互有比较优秀的优化
刚刚用上, 语言比较苍白~ 欢迎大家一起尝试~
6 个赞
good good study,day day emacs
1 个赞
这个是基于 Hook 来交互，感觉不如 GitHub - xenodium/agent-shell: A native Emacs buffer to interact with LLM agents powered by ACP · GitHub 基于 ACP 的靠谱。
2 个赞
目前体验最好的还是 agent-shell
1 个赞
大家假期快乐🙂
经过 gui emacs as first class 还是转向 tui + neivim 的思考🤔后，决定还是不放弃 gui emacs 长期以来积攒的工作流。
然而在 claude code 当道的此刻，就必须要为 gui emacs 找到一个好用的 claude code interface 插件。claude-code.el 和 claude-code-ide.el 都因为终端 wrapper 的实现而存在不愉悦的渲染问题。
本帖最初推荐的 claude-gravity 的 emacs 原生结构化呈现方式是一种更好的尝试。尽管这个包目前处于 alpha 开发阶段，expect rough changes。
试了下坛友推荐的 agent-shell。尽管最初对 acp 的功能性还有 concern，今天配置下来并试用后觉得 agent-shell 已经相当可用。也是极力推荐。
感慨于 emacs 的生命力。在 agent 当道的今天，emacs 仍然能够不被 coding agent 完全取代。
happy hacking！
1 个赞
emacs-gravity 感觉太 vendor lockin? 不知道改用其他 agent 像 codex 多容易 还有 claude-code 更新 作者跟得上吗?
agent-shell 主要问题还是 ACP不是 first-class citizen 我看 claude-code-acp 和 codex-acp 都是 zed 在维护且问题也不少
agent 现在太 hot 迭代速度非常快 尤其 claude-code 还不开源 (–最近开源了–)
只是看 codex-acp 和 claude-code-acp 就看到几个 issues
codex acp 不能用 plan mode
还有我刚试用 ~/.agent/skills 的读不到 只能读到 ~/.codex/skills
例如 claude-code-acp 只用用 API key 因为 based on claude agent sdk
不知道 agent-shell 主要是作者一人维护 能走多远
vterm/eat 问题不少 但少了 ACP 中间这一层 使用体验和终端一致 也不用担心作者弃坑
解决一些 unicode font 的 issue 我目前 claude-code/codex 在 vterm/eat 几乎和原生 terminal 体验一致
emacs native 體驗很棒 (不用和 vterm/eat 搶 hotkey) 但感覺犧牲不少
3 个赞
如果在claude-code/codex间切换, 而且想让体验和终端一致, 安利一下在下大半年来开发维护的repo: GitHub - tninja/ai-code-interface.el: Unified Emacs interface supporting OpenAI Codex, GitHub Copilot CLI, Claude Code, Gemini CLI, Opencode, and more · GitHub
它也有agent-shell backend和eca backend 
这是网友贡献的
本站主贴: (发布) 集成多种AI coding cli tool的emacs前端, ai-code-interface.el
请问 ai-code-interface.el 可以认为是 claude-code.el 的多后端版本吗, 统一了不同 coding agent 的使用体验, claude-code.el 中存在的 vterm 闪烁问题会继承
我这个项目 ai-code-interface.el，现在已经不只是“把几个 coding CLI 接进 Emacs”了。
我更想做的是一个 action-centric 的统一界面：尽量保留 Emacs 用户原有的 muscle memory，让不同 agent 进入同一套工作流，而不只是多开几个聊天窗口。
最近加的一些特性里，我自己觉得更关键的，不只是表面的交互便利，而是开始往 harness / feedback loop 方向走了。比如可以在 AI 改完代码后自动运行测试，并根据结果继续 follow up；也在尝试更偏 TDD 的闭环。这类东西我觉得比单纯“包一层 UI”更重要，因为它更接近真实软件工程里的工作流，而不只是 prompt 往返。
另外也做了一些 editor-aware integration，比如 session 里自动链接 filepath / url / symbol、@文件 自动补全、Emacs 侧 MCP function、以及结合 org task 文件做项目级任务管理。我的想法不是做一个 chat wrapper，而是尽量让 Emacs 本身成为 agent 可以利用的工作环境。
如果有兴趣的话, 更多内容, 请看README, 有任何问题ping我
1 个赞
agent-shell 目前好像是全职开源
大伙没人用ECA吗？ 我感觉比agent-shell好用，2个都用过个把月，目前eca
Claude ide el 3天前剛剛加入alternative render，去閃
agent-shell video 666
2 个赞
eca + 1
因为 eca 不是主流的 AI agent，生态和 claude code / codex 之类的没法比。
ACP 是 Zed 发明的，所以 Zed 来维护反而更好。
各位都用哪個mcp來使用clangd的indexes啊？
试用了agent-shell以后的感想，分享下 
ai之下不需要工具，通用型工具更是错误的道路，一个便利的前端集成式gui,一个ai生成的特定功能app,一个高效实用的工作流，都没啥意义，无非是站在“ai的肩膀上创造一些只对个人有价值的临时幻象”，无非还是在借助ai实现ai以后能实现的东西，ai 不缺创造工具的能力，缺创造工具的说明书，缺个体的唯一性表达，缺个体对原理的唯一性理解，即缺skill 开源应该以skill的形式发布，而不应该再是源码的方式
我不质疑开发者的专业性和编程思想，我质疑的是“创造一个通用型工具” 是否已经不适合ai时代的方向
2 个赞
你的意思是说：AI 时代可能更重要的是 skill 和个体表达，而不是传统意义上大而全的工具。这个判断我觉得很有启发。
不过我会觉得，断言‘不需要工具’还是说得有些过了。因为工具的本质，其实是对人类能力和 workflow 的抽象与复用。即便未来的基座 AI 再强大，人们依然需要把高价值的做事方法沉淀下来，以便于重复使用、分享以及降低门槛。这种沉淀的载体可以是通用工具，可以是专用脚本，甚至可以是 skill 本身。
这有点像：机器码（底层算力）再强，也不等于我们不需要应用软件。应用软件的价值，从来不是为了证明底层不够强，而是为了把底层能力组织成更稳定、可复用、易传播的形式。
1 个赞
他的意思是未来不再需要工具类的 app 了。工具类的 app 都做出 API 的形式让 AI 调用就行了。未来的 App 只有娱乐性质的 app 了。