这是个很大胆的假设。因为如果前台都交给 AI 实时组织和调用，某种程度上就是把更多正确性压力转移到 AI 当下的决策上。可目前很多工具类软件之所以可靠，恰恰是因为它们背后的能力经过了仔细测试、验证和长期打磨。
另一方面, 即使AI的当下决策几乎都是正确的, 就算未来人只提供 prompt，prompt 本身其实也需要经过测试和迭代.
后端的 API 肯定还是需要程序性的验证的，而不是纯靠 AI 的 agent 能力执行。我的意思是工具类 app 这种呈现形式可能不再需要了。
Claude code ide.el是不是就是這個思路啊？
会不会后端API是工具，前端调用AI Agent的东东就是工具类app？ 
发现了一个新玩法：agent → 聊天软件（飞书、微信等）–> api → emacs 这样emacs就是一个集agent管理和agent编辑于一身的最强工具了 哈哈
飞书-api我研究过一点, 感觉是有点夸张, 想不出来什么样的存在才能与其完美适配, 但感觉emacs是不行的
感觉通过 ghostel 直接在 Emacs 中使用 native 的 coding agent, 例如 opencode, codex 体验都还不错
agent-shell 通过 acp 来支持的 feature 似乎还是少了些
2 个赞
推荐一下 GitHub - dgillis/emacs-codex-ide: Codex IDE integration for Emacs · GitHub
这个是基于 app-server 的，相当于给 codex 重新写了一个前端 UI，能和 emacs 内置工具协作，感觉非常不错
1 个赞