agent-shell：把 ACP 代理接進 Emacs 原生緩衝區

問題不在模型，在於每個代理都有自己的殼

Claude Agent、Codex、Gemini CLI、Goose、Cursor CLI、Qwen Code，這些工具各自有命令列介面、各自的輸出格式、各自的對話歷史存放方式。對每天在 Emacs 裡寫程式的人來說，要跟其中任何一個講話，就得切到終端機，或者另外開一個視窗。切換本身不貴，貴的是上下文：你在 Emacs 裡看到的檔案、選取的區域、當下的專案目錄，到了另一個殼裡都要重新交代一次。

agent-shell 的目標讀者很明確，就是不想離開 Emacs 的使用者。它不訓練模型、不代理請求、不管理金鑰，只做一件事：把 ACP 代理接進一個原生 Emacs 緩衝區。README 把它定位成 shell，這個詞選得準確，因為使用體驗接近 shell，但底層是結構化的協定訊息往來，不是字元串流的解析。

這個定位也決定了它的邊界。它不試圖統一各家代理的行為差異，也不提供跨代理的抽象層。ACP 協定本身負責那部分，agent-shell 只負責 Emacs 這一端。

acp.el 是傳輸層，agent-shell 是介面層

根據 README，agent-shell 依賴 acp.el 與代理溝通，而 acp.el 是同一作者的另一個專案。這個分層值得注意：協定實作與 Emacs 介面被拆成兩個套件，代表 ACP 的訊息處理、連線生命週期、請求與回應的配對，都在 acp.el 裡；agent-shell 處理的是緩衝區呈現、輸入送出、以及 Emacs 端的互動。

對使用者的直接影響是相依性。安裝 agent-shell 時，acp.el 必須存在，否則代理根本連不上。README 沒有在安裝段落明講這件事，只說 agent-shell 依賴 acp.el，所以第一次設定失敗時，先確認 acp.el 是否已經在 load-path 裡，比翻 agent-shell 的程式碼更快。

第二個影響是可替換性。既然協定層被抽出去，理論上其他 Emacs 前端也能接上同一個 acp.el；反過來說，agent-shell 能支援哪些代理，取決於 acp.el 對 ACP 的實作程度，而不是 agent-shell 自己。README 列出的代理清單很長，從 Anthropic、OpenAI、Google 到 xAI、Mistral、Cursor 都有，但清單本身不說明每個代理的支援完整度是否一致。

安裝路徑與實際會用到的設定

README 開頭掛著 MELPA 的 badge，代表這個套件可以從 MELPA 取得。在 Emacs 裡的基本流程是把 MELPA 加進 package-archives，然後安裝 agent-shell：

M-x package-install RET agent-shell

設定方面，README 沒有在提供的內容裡給出完整的 init 範例，只有散落在各篇更新文章的說明。因此本文不列出無法從素材確認的設定鍵。可以確定的是，agent-shell 的啟動需要指定一個 ACP 代理，而代理本身是外部程式，必須先安裝在系統上（例如 Claude Agent 或 Gemini CLI 的命令列工具），agent-shell 再透過 acp.el 啟動它。

這意味著兩段式安裝：先裝代理的命令列工具並確認它能獨立執行，再裝 agent-shell。如果代理本身跑不起來，agent-shell 的緩衝區只會顯示連線失敗，除錯時要先把這兩層分開。

另外，README 提到多個社群擴充套件，例如 agent-shell-sidebar 提供側邊欄、agent-shell-manager 提供列表管理、agent-shell-workspace 用 tab-bar 管理多個 session。這些不在主套件內，需要另外安裝，但它們反映了主套件在「同時開很多個 session」這件事上留給外部處理。

生態系是這個專案最實在的部分

README 花了相當篇幅列出相關專案，數量超過二十個，涵蓋側邊欄、書籤、通知、Org 整合、Tramp 整合、沙箱執行、多代理協調。這份清單本身就是一項事實陳述：agent-shell 的核心刻意保持精簡，把周邊功能留給第三方。

其中幾個值得注意。agent-circus 在 Docker 容器裡執行代理，處理的是代理能直接讀寫你檔案的風險。agent-shell-tramp 把 Tramp 接進來，讓遠端檔案情境下的代理操作可行。ob-agent-shell 是 Org Babel 後端，代表 agent-shell 的 session 可以被 Org 文件當成程式碼區塊執行。meta-agent-shell 做多代理協調與任務分派。

這種生態形狀有兩面。好處是主套件不必承擔所有使用情境，更新時波及面小。壞處是品質與維護狀態參差不齊，而 README 只給連結，不給任何成熟度描述。如果你需要某個特定功能，得自己去看那個擴充套件的原始碼與提交歷史，不能只看它在清單上。

贊助訴求寫在 README 最前面

README 的第一個段落不是功能介紹，而是贊助請求，作者 Álvaro Ramírez 直接寫明這個專案需要資金，理由是使用者付費購買 LLM token 的同時，也應該考慮支持開發與維護。

把這段放在最前面，是一個明確的訊號：這是一個由單一作者主導、以贊助為主要支持模式的專案。對採用者來說，這不是道德問題而是風險問題。單一維護者的專案，回應速度可能很快，也可能在某段時間內完全停滯；README 沒有提供任何關於維護節奏、回應時間或長期計畫的承諾。

授權是 GPL-3.0。這對個人使用沒有實質影響，但如果你打算把 agent-shell 嵌進內部工具再散布，GPL-3.0 的傳染性條款需要你的法務確認。本文不提供法律意見，只指出授權識別碼。

什麼情況下它會讓你失望

第一個限制來自協定本身。agent-shell 只支援 ACP 代理。如果你的團隊內部代理或是某個自建工具不走 ACP，agent-shell 幫不上忙，你得先寫一個 ACP 相容層，或者改用其他前端。README 列出的清單雖然長，但清單之外的工具就是不能用，這不是設定問題。

第二個限制是多程序架構的必然成本。每個 session 對應一個外部代理程序，開多個 session 就是多個程序。這在一般的筆電上通常不是問題，但如果你習慣同時開十幾個 session，記憶體與啟動延遲會累積。README 沒有提供任何關於資源使用的數據，因此本文也不給數字。

第三個限制是文件分散。README 本身偏短，大量功能說明放在作者部落格的更新文章裡，從 0.5 到 0.63 有八篇。這代表想知道某個功能怎麼用，得先去翻對應版本的部落格文章。對喜歡一次讀完手冊的人來說，這種文件組織方式會拖慢上手速度。

最後，它不適合不想碰 Emacs Lisp 的人。雖然日常使用不需要寫 Lisp，但當某個行為不符合預期時，除錯的終點通常是一個 Emacs Lisp 檔案。

和直接用終端機跑代理的差別

最直接的替代方案就是原本的做法：在終端機裡跑 Claude Agent 或 Gemini CLI。兩者的差別不在模型能力，而在整合深度。

終端機方案的好處是零設定、零相依、代理官方直接支援，出問題時責任歸屬清楚。缺點是它和 Emacs 之間沒有共用狀態，你選取的區域、當前緩衝區的檔案路徑、專案的目錄結構，都要手動複製過去。

agent-shell 換來的是這些狀態留在 Emacs 裡，輸出進到原生緩衝區，可以套用既有的 Emacs 操作習慣，例如用 occur 搜尋對話、用 Org 模式整理輸出、用既有按鍵綁定在緩衝區之間移動。代價是多了一層 acp.el 與一個外部程序，以及前面提到的單一維護者風險。

另一個方向是其他編輯器的代理整合，例如 VS Code 或 Cursor 內建的做法。那些方案的整合度通常更高，但綁定在特定編輯器上。agent-shell 的價值在於它服務的是 Emacs 使用者，而不是提供一個跨編輯器的通用方案。

編輯結論

如果你日常在 Emacs 裡工作，而且已經在用 Claude Agent、Codex 或 Gemini CLI 這類 ACP 代理，agent-shell 值得裝起來試；它把代理輸出放進原生緩衝區，而不是另外開一個終端機。如果你不用 Emacs，或者你的代理不支援 ACP，這個套件對你沒有意義。裝之前先確認兩件事：你的代理是否真的走 ACP（README 列出的清單是唯一依據），以及 acp.el 是否已隨 agent-shell 一併安裝。授權是 GPL-3.0，與你既有套件的相容性請自行確認，本文不構成法律意見。

官方來源

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. xenodium/agent-shell on GitHub