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 编写的开源 AI 代理，可常驻后台，通过 CLI 或 Telegram 交互。它强调执行前询问、Shell 黑名单和基于 SQLite 的结构化记忆。本文基于官方文档与仓库信息，分析其机制、运行方式与适用边界。
- 适合谁用？
- Mercury Agent 适合那些需要长期运行、且对执行权限有明确担忧的个人开发者或小型团队，尤其是希望通过 Telegram 远程管理任务、又不愿完全放权给代理的用户。它不适合需要复杂工作流编排或深度定制模型行为的场景，因为其扩展机制目前仅基于 Agent Skills 规范，且记忆结构固定为 10 种类型。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：一个会先问你的常驻代理
大多数 AI 代理能读文件、执行命令、抓取网页，但它们通常静默行动。Mercury 的定位恰恰相反：它在执行前请求许可，并把记忆持久化到本地 SQLite。这个项目面向的是那些希望代理 24 小时在线，但又不愿放弃控制权的用户。你可以在 CLI 或 Telegram 上与它对话，它会在后台运行，崩溃后自动重启。它不是一个通用聊天机器人，而是一个带权限边界的任务执行器。如果你需要代理在无人值守时替你管理日程、整理笔记或执行定时任务，Mercury 提供了一种结构化的方式，而不是像裸脚本那样直接放权。
权限硬化的具体机制：黑名单与作用域限制
Mercury 的权限模型分为三层。第一层是 Shell 命令黑名单，`sudo`、`rm -rf /` 这类命令被硬编码禁止执行，无论用户是否在对话中批准。第二层是文件夹级别的读写作用域，代理只能访问你指定的目录，而不是整个文件系统。第三层是会话级的审批流：每次启动时，你必须选择 `Ask Me` 或 `Allow All` 模式。在 `Ask Me` 模式下，每个敏感操作都会进入待批准队列；在 `Allow All` 模式下，代理仍受黑名单和文件夹作用域的限制。这个设计的关键在于，即使你选择了完全放权，最危险的操作依然被物理阻断。README 明确提到“pending approval flow”，但没有说明审批队列在 CLI 和 Telegram 上如何呈现，这是一个需要实测的细节。
Second Brain：SQLite 与 FTS5 支撑的结构化记忆
Mercury 的记忆系统被称为 Second Brain，底层是 SQLite 数据库，并启用了 FTS5 全文搜索。它支持 10 种记忆类型，能够自动从对话中提取信息，处理冲突，并自动合并重复内容。这意味着代理能记住你的偏好、目标和习惯，而不需要你手动录入。例如，你告诉它“我每天上午九点检查邮件”，它可能会存储为一条日程记忆，并在后续对话中引用。与向量数据库不同，SQLite 加 FTS5 的方案更轻量，没有外部服务依赖，数据文件就在本地。但这也意味着记忆的语义理解能力有限，它依赖关键词匹配而非语义相似度。如果输入是口语化的模糊表述，自动提取可能会失败，冲突解决策略的具体实现细节在文档中并未展开。
Soul 机制：用 Markdown 定义人格，而非配置文件
Mercury 将代理的人格定义为四个 Markdown 文件：`soul.md`、`persona.md`、`taste.md` 和 `heartbeat.md`。这些文件由你拥有，可以自由编辑，没有公司包装层。`soul.md` 可能定义核心价值观，`persona.md` 定义说话风格，`taste.md` 定义审美或偏好，`heartbeat.md` 可能定义定期自检的提示词。这种设计的好处是人格可版本控制，你可以用 git 跟踪变化。但 README 没有给出这些文件的具体格式或示例，只提到它们是 Markdown 格式。实际使用中，你需要自行摸索如何让模型理解这些文件中的指令。相比用 JSON 或 YAML 配置，Markdown 更易读，但解析时可能产生歧义，例如同样的措辞在不同模型上可能产生不同的行为。
Token 预算与实时流式输出：控制成本的手段
Mercury 内置每日 token 预算，当用量超过 70% 时，它会自动切换到简洁回答模式。你可以通过 `/budget` 命令查看状态、重置或覆盖预算。这个机制对 API 成本敏感的用户很实用，尤其是当代理常驻后台时，它可能在你不知情的情况下消耗大量 token。此外，CLI 和 Telegram 都支持实时流式输出。CLI 端实现了光标保存与恢复，以及 Markdown 重渲染；Telegram 端则通过可编辑状态消息实现流式效果。README 没有说明预算的统计周期是按 UTC 还是本地时间，也没有说明超过预算后是否完全停止响应还是仅降级为简洁模式。这些细节需要在实际使用中验证。
常驻模式：从 CLI 到 Telegram 的切换
`mercury up` 是推荐的常驻命令，它会安装系统服务（如果未安装）、启动后台守护进程，并确保代理持续运行。在守护进程模式下，Telegram 成为主要交互渠道，因为 CLI 没有终端输入，只能查看日志。这意味着如果你通过 SSH 启动守护进程，之后断开连接，你仍然可以通过 Telegram 与代理对话。服务安装支持 macOS 的 LaunchAgent、Linux 的 systemd 用户单元和 Windows 的任务计划程序，均不需要管理员权限，但 Linux 下需要启用 linger 才能实现开机自启。崩溃恢复机制采用指数退避，每分钟最多重启 10 次。这适合需要长期运行的场景，比如定时任务或监控。但要注意，一旦进入守护模式，CLI 就退化为只读日志，所有控制都转移到 Telegram，这要求你必须配置好 Telegram 访问控制。
Telegram 访问控制：配对码与用户管理
Mercury 对 Telegram 访问有明确的审批流程。首次连接时，用户需要提供配对码，管理员可以通过 `mercury telegram list` 查看待批准的请求，并用 `mercury telegram approve <code|id>` 批准。你可以使用 `mercury telegram promote` 和 `demote` 来管理管理员权限，`reset` 命令则清空所有访问记录。这个设计防止了陌生人直接控制你的代理。但 README 没有说明配对码的有效期，也没有说明是否支持多管理员同时在线。对于单人使用，这个流程足够；对于团队共享一个代理实例，可能需要更细粒度的权限划分，例如限制某些用户只能读不能写，但当前文档中并未提及。
扩展技能与安装方式：基于 Agent Skills 规范
Mercury 支持通过单条命令安装社区技能，并可将技能作为定时任务运行。技能遵循 Agent Skills 规范（agentskills.io）。首次运行时，它会自动在 `~/.mercury/skills/web-search/SKILL.md` 创建一个默认的 `web-search` 技能。这意味着扩展不是插件式的代码模块，而是以 Markdown 文件描述的指令集。这种方式的优点是低门槛，但缺点是复杂逻辑难以实现，例如需要调用外部 API 或处理二进制数据的技能，可能无法仅靠 Markdown 描述完成。README 没有列出具体的技能安装命令格式，也没有说明技能市场的来源。如果你需要的是类似插件系统的深度扩展，Mercury 的模型可能不够用。
编辑结论
Mercury Agent 适合那些需要长期运行、且对执行权限有明确担忧的个人开发者或小型团队，尤其是希望通过 Telegram 远程管理任务、又不愿完全放权给代理的用户。它不适合需要复杂工作流编排或深度定制模型行为的场景，因为其扩展机制目前仅基于 Agent Skills 规范，且记忆结构固定为 10 种类型。在采用前，建议先阅读 `soul.md` 与 `persona.md` 的格式示例，确认你能接受用 Markdown 文件定义人格的方式；同时，用 `mercury doctor --platform` 检查你的系统是否满足后台服务要求，特别是 Linux 下需要启用 linger 才能实现开机自启。若你无法接受“先问后做”的交互模式，或需要代理在无人监督时执行高风险命令，这个工具并不适合你。
社区笔记