Mercury Agent：把「先問再做」寫進工具層的常駐 AI 代理
Soul-driven AI agent with permission-hardened tools, token budgets, and multi-channel access. Runs 24/7 from CLI or Telegram.
秒懂
- 它是什麼？
- Mercury Agent 是一個以 TypeScript 撰寫、可從 CLI 或 Telegram 操作的常駐 AI 代理。它的核心賣點不是模型能力，而是把權限檢查、Token 預算與記憶結構直接織進工具呼叫流程。
- 適合誰用？
- Mercury Agent 適合需要長時間背景運行、又不想讓代理任意執行破壞性指令的個人或小團隊。它的權限模型比多數 CLI 代理更細，Shell 黑名單與資料夾範圍是實質約束，不是口號。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
一個把「拒絕權」當作功能的代理
多數 AI 代理的說明文件都在強調模型多強、工具多廣。Mercury Agent 的 README 卻把第一句話放在「asks first, and remembers what matters」。這個定位很直接：它預設你不想讓代理默默執行 `sudo` 或 `rm -rf /`。專案以 TypeScript 撰寫，授權 MIT，提供 npm 套件與免 Node.js 的獨立二進位檔。它的目標使用者不是只想玩玩 ChatGPT 的人，而是願意把一個代理掛在背景、讓它讀檔案、跑指令、甚至透過 Telegram 遠端操作自己機器的人。這種使用情境下，「代理做了什麼」比「代理能多聰明」更值得擔心。Mercury 的設計就是把這份擔心轉成具體的程式碼約束，而不是事後的日誌檢討。
權限不是設定檔，是執行路徑上的閘門
README 列出三層防護：Shell 黑名單、資料夾層級的讀寫範圍、以及待核准流程。黑名單直接擋掉 `sudo` 與 `rm -rf /` 這類指令，意思是即使代理的模型輸出建議執行，實際的 shell 呼叫層也不會讓它過。資料夾範圍則把代理能碰的檔案系統限制在某個根目錄之下，這比單純依賴模型「聽話」可靠得多。對話開始時，使用者要選 `Ask Me` 或 `Allow All`，這是 session 層級的決定。`Allow All` 並非移除黑名單，只是跳過逐次詢問。這個設計有個值得注意的取捨：黑名單是靜態的，若你的工作流程需要某個被擋的指令，你無法在對話中臨時解禁，只能改程式碼或設定。對安全是好事，對彈性是限制。
Second Brain：SQLite 不只是聊天紀錄
記憶功能取名 Second Brain，底層是 SQLite 加上 FTS5 全文檢索。README 聲稱有 10 種記憶型態、自動萃取、衝突解決與自動整合。換句話說，代理會從對話中主動抽出偏好、目標與習慣，寫入結構化儲存，而不是把整段聊天丟進向量資料庫。這與常見的 RAG 做法不同：它沒有提到 embedding 或向量搜尋，而是用傳統 SQLite 的全文索引。好處是輕量、可攜、易於檢查，你隨時可以打開資料庫檔案看它到底記了什麼。壞處是語意檢索能力有限，FTS5 比不過語意向量，若你的問題是「找出我上次提到的那個想法，但我忘了用詞」，它可能找不到。README 沒有提供記憶 schema 的細節，實際的型態欄位與合併邏輯要自己翻原始碼才能確認。
Token 預算：把成本變成對話內指令
多數代理工具把 token 用量放在後台儀表板。Mercury 把它做成 `/budget` 指令，可以在對話中直接查詢、重置或覆寫。每日預算超過 70% 時，代理會自動切換成簡潔模式。這個機制對常駐代理特別重要，因為背景 daemon 可能在你睡覺時持續運作，若沒有預算上限，一夜之間就能燒掉大量額度。README 特別強調 `/budget` 這類指令不消耗 API token，因為它們在本地處理。設計上，預算是「每日」而非「每小時」或「每請求」，這代表你無法用它在短時間內限制突發用量。若你擔心的是某個失控迴圈在幾分鐘內噴光額度，每日預算幫不上忙。你需要的是外部監控或更細的速率限制，README 沒有提到後者。
從 CLI 到 Telegram：常駐模式的通道轉移
`mercury up` 是 README 推薦的啟動方式，它會安裝系統服務、啟動背景 daemon 並確保程式在跑。這裡有個關鍵轉變：daemon 模式下 Telegram 變成主要通道，CLI 只剩日誌功能，因為背景程序沒有終端機可以接收輸入。這代表你的日常工作流程會變成：在手機上打字給代理，代理在你的機器上執行工具。Telegram 的存取控制因此很嚴格，README 列出 `mercury telegram approve`、`reject`、`promote`、`demote` 等指令，顯示它採用配對碼或待審核請求的方式，不是任何人加了 bot 就能用。跨平台服務安裝各有方法：macOS 用 LaunchAgent、Linux 用 systemd user unit、Windows 用 Task Scheduler，而且都不需要管理員權限。Linux 要開機自動啟動需啟用 linger，README 沒細說，但這是 systemd user service 的常見前提。
擴充技能與人格檔案：代理的界線由你定義
Mercury 的人格不是寫死的系統提示，而是由 markdown 檔案組成，包括 `soul.md`、`persona.md`、`taste.md` 與 `heartbeat.md`。這些檔案放在 `~/.mercury` 下，你擁有並可隨時編輯。首次執行時，它還會在 `~/.mercury/skills/web-search/SKILL.md` 建立一個預設的 web-search 技能。技能安裝用單一指令，而且可以排程成重複任務，規格遵循 Agent Skills 規範。這個設計的優點是透明，你可以直接看到代理的「個性」是哪些文字，不像黑箱系統提示。缺點是，若你想改變行為，你得自己會寫這些 markdown 的結構，README 沒有提供完整的 schema 範例。技能系統的實際載入機制與權限邊界，文件只給了表面，深入整合前需要看原始碼。
安裝與維護成本：一鍵腳本背後的升級路徑
安裝有三條路：curl 或 PowerShell 的遠端腳本、npx 直接執行、或 npm 全域安裝後用 `mercury` 指令。README 強調第一種不需要 Node.js，代表它會下載獨立二進位。這對沒有 Node 環境的使用者很友善，但獨立二進位的升級路徑與 npm 套件不同。`mercury upgrade` 指令存在，文件沒說明它是否同時處理兩種安裝方式。`mercury doctor` 可以重新設定名稱、供應商、通道與權限預設值，`doctor --platform` 則顯示跨平台的終端機與 daemon 相容性診斷。維護成本主要落在三處：一是 SQLite 記憶檔案的成長與備份，二是 Telegram 配對使用者清單的管理，三是技能更新與相容性。MIT 授權代表你可以改原始碼，但改了就脫離官方升級線，這是開源專案常見的取捨。
替代方案的真實差異：權限哲學的對比
市場上常見的 CLI AI 代理，例如 OpenAI 的 Codex CLI 或各種 open-source 的 terminal agent，多半採用「你給它 shell，它自己決定何時執行」。它們的防護通常是事後確認或簡單的 y/n 提示。Mercury 的差異在於把黑名單與資料夾範圍變成硬性程式碼約束，而不是模型提示的一部分。另一個對比是像 LangChain 之類的框架，它們提供工具呼叫的抽象層，但權限邏輯要你自己實作。Mercury 把這層內建，讓使用者不用寫 policy 程式碼。相對地，框架型方案允許你完全自訂權限規則，例如依使用者角色或時間動態調整，Mercury 的固定模式較難做到。若你的需求是「代理可以讀 A 目錄、寫 B 目錄、但絕對不能碰網路」，Mercury 的文件沒有顯示這種細粒度控制，它只有資料夾範圍與全域的 Shell 黑名單。
編輯結論
Mercury Agent 適合需要長時間背景運行、又不想讓代理任意執行破壞性指令的個人或小團隊。它的權限模型比多數 CLI 代理更細，Shell 黑名單與資料夾範圍是實質約束，不是口號。但若你的工作仰賴自訂模型或私有部署，現階段要自己繞過官方安裝流程。若你只需要一次性對話，或根本信任代理全權執行，這套「先問後做」的流程反而會拖慢你。採用前先確認三件事：你的 Telegram 使用情境是否接受配對審核流程；你的任務是否真的需要跨 CLI 與 Telegram 的常駐存取；以及你是否願意把記憶放進 SQLite，並接受 FTS5 全文檢索的既有結構。這些都是 README 明寫的邊界，不是隱藏風險。
社群筆記