对于长期使用 Emacs 的人来说，编辑器里已经存在很多有价值的活状态：尚未保存的 buffer、major mode、point 和 region、project、Magit、Org、xref、LSP、process buffer……如果 agent 只能看到磁盘文件，它其实丢掉了 Emacs 工作流里相当重要的一部分上下文
基于这个想法写了 Magent，一个使用 Emacs Lisp 实现的、Emacs-native 的 LLM coding agent
项目目前已经可以用于一些简单的项目开发（复杂任务未经过长期测试），欢迎大家一起参与讨论
文档在这里：https://jamie-cui.github.io/magent/zh/index.html
Quick Start
;; 前置条件：配置好 gptel 的默认模型
(setq gptel-model 'claude-sonnet-4-20250514)
(setq gptel-api-key "sk-ant-...") ; or use ANTHROPIC_API_KEY env var
;; 配置 magent，会直接使用已配置好的 gptel 默认模型
(use-package magent
:vc (:url "https://github.com/Jamie-Cui/magent" :rev "master")
:ensure t
:after (agent-shell gptel)
:demand t
:config
;; 可选: append an additional personal skill directory. Later entries
;; have higher precedence and become the skill manager's install target.
(add-to-list 'magent-skill-directories
(expand-file-name "skills" user-emacs-directory)
t)
(magent-agent-shell-ensure-config))
之后 M-x agent-shell 就会有 Magent 可以选择了
See gptel documentation for full provider setup (Anthropic, OpenAI, Ollama, etc.).
Magent 是啥？
Magent 更接近“gptel + stateful agent runtime”，而不是 gptel 的替代品，也不是外部 CLI agent 的简单包装。
各部分的职责是：
- gptel (GitHub - karthink/gptel: A simple, extensible LLM client for Emacs · GitHub) 继续负责 provider、模型、API key、HTTP/SSE 和流式传输
- agent-shell (GitHub - xenodium/agent-shell: A native Emacs buffer to interact with LLM agents powered by ACP · GitHub) 提供默认交互界面
- Magent 通过进程内 ACP adapter 接入 agent-shell，不需要启动一个外部 ACP agent 进程
- Magent 自己负责 agent loop、工具调用、权限、session、skills、child agents 和持久化
Magent 架构的好处是：已经配置好的 gptel provider 可以直接复用，同时 agent 又能真正进入 Emacs 的运行时环境
为什么还要在 Emacs 里实现 Agent Runtime？
先说明一点：Magent 并不独占访问 Emacs 状态的能力。
给 Claude Code、Codex 或其他外部 agent 接入一个 emacs_eval skill、MCP server 或类似桥接层，同样可以让它查看 buffer、major mode … 单从最终能完成的任务来看，两种方案没太大区别
Magent 选择的区别在于 runtime 边界
| 方案 | Agent Runtime | Emacs 的角色 | Provider Transport |
|---|---|---|---|
| 外部 Agent + Emacs Bridge | 运行在外部进程中 | UI 和工具 Endpoint | 由外部 Agent 负责 |
| Magent | Agent Runtime 和工作流状态保留在 Emacs 中 | Runtime、UI 和工具执行环境 | 交给 gptel |
Magent 通过 gptel-request 调用模型，但以下部分都在 Emacs Lisp 中运行：
- agent loop 和工具调用；
- permission、approval 和 audit；
- project-scoped session；
- turn、tool call、取消和失败状态；
- skills、capabilities 和 custom agents；
- …
Magent 想探索的不是“怎样让外部 agent 多一个 Emacs 工具”，而是另一个问题：
如果把 Emacs 本身当作 agent runtime，而不只是 agent 的客户端，会形成怎样的工作流？
目前有哪些功能
1. Coding Agent 工具链
目前内置了 15 个工具，包括：
- 文件读取、创建和精确编辑；
- grep、glob 和 shell；
- emacs_eval；
- websearch；
- Org 格式的 repository summary；
- skill 调用；
- child-agent 的创建、通信、等待、查看和关闭
2. 项目级 Session
Magent 的 session 默认按 project 隔离
在一个 Git 项目中打开 Magent，后续对话、agent 选择、skills 和 child-agent jobs 都属于这个项目。退出或重启 Emacs 后，可以从持久化的 session 中恢复
3. 权限与审计
不同 agent 可以有不同的工具权限：
- allow：直接允许；
- deny：拒绝；
- ask：执行前询问；
- 文件操作还可以按 glob pattern 设置规则
4. Skills 和 Slash Commands
Magent 的 skill 是文件化的，可以来自：
- 包内置的 skills/；
- 用户目录；
- 项目本地 .magent/skills/
当前内置的 agent-shell slash commands 包括：
/explain
/fix
/init
/review
/summarize
/test
/compact
/clear
FYI 这些 commands 和 emacs 工作流相关，目前还没太想好后面应该怎么做，所以请 expect breaking change
好的，那我改下表述