别再给 Hermes 乱装插件:真正有用的是这 5 层

我越来越觉得，很多人第一次折腾 Hermes，都会犯同一个错：把它当成一个插件货架。

看到别人说 Hindsight 好，装。看到 Gbrain 好，装。Ego、Vercel Agent Browser、Firecrawl、Superpowers、LiteLLM、Obsidian、Mnemosyne、MCP Security Audit……一路装下来，像在给一个刚会走路的小孩配战术背心。

很帅。

也很容易摔。更烦的是，摔完以后你还不知道是哪块插件绊的脚。

真正值得抄的不是工具名单，而是一套系统搭建顺序：记忆、知识库、浏览器、观测、安全和路由。我的判断很明确：Hermes 变强，不是因为工具越多越好，而是因为你把它从聊天框，改造成了一套有记忆、有眼睛、有仪表盘、有刹车的操作系统。

少一个都难受。

多了也会炸。

第一层不是模型，是记忆：别让 Agent 每天失忆上班

Hermes 的第一层应该先接持久记忆。Hindsight、Mnemosyne、Obsidian、Perseus Vault 解决的是同一个问题：让 Agent 不再每个会话都从零开始。更准确地说，skills 存流程，memory 存偏好，session_search 找回旧决策。

这其实不是“记住用户喜欢喝冰美式”那种可爱小功能。

是 Agent 的地基。

标准短记忆很快会被塞满，几天后就可能要删旧内容腾空间；成熟一点的记忆 provider 应该支持 ranking、natural memory decay 和 vector search，用更少上下文找回更相关的东西。如果你用 Obsidian 做长期记忆，也不要每次让 Hermes 读完整个 vault。更好的方式是让 Mnemosyne 这类记忆层存“指针”：真正的细节在 Obsidian，当前 turn 只拿需要的线索。

这个设计很关键。

很多人的 Agent 用不好，不是模型笨，是每次都从婴儿状态开机。你让它管理邮件、网站、日程、客户、家庭采购、项目状态，却不给它一个可靠的长期记忆层，这就像让助理每天入职一次。你还嫌它问问题多。

有点缺德。

更实用的做法是分三类存：

• • 偏好记忆：用户怎么沟通、讨厌什么输出、常用决策标准。
• • 实体知识：项目、客户、网站结构、服务器、账号边界、家庭地点、常用商店。
• • 过程记录：上次为什么这么决定，哪些方案被拒绝，下一步卡在哪里。

如果你已经用 Obsidian，别急着让 Agent 全盘读写。先只读，再让 memory provider 存索引。让 Hermes 扫描几千条笔记、建议一套更符合自己关注点的组织结构，这类任务很适合读权限。但一上来就全权限写 vault，迟早会出现“它帮我整理了人生，也顺便重命名了三百个文件”的温馨事故。

我的建议很简单：先建记忆路由，再谈智能。没有路由的记忆，只是把上下文垃圾桶换了个名字。

第二层是知识库：Gbrain 的价值不是搜索快，是少做傻事

Gbrain 最适合处理网站、业务资料、homelab、项目文档这类稳定语料。没有它，Hermes 往往会先查 Hindsight，又在一堆文件和整个网站里翻来翻去，token 烧得很快乐，账单也很快乐。用了 Gbrain 之后，Hermes 可以直接查一个 local corpus，更快理解网站结构和业务资料。

注意这个细节：它不是“多了一个搜索工具”。

它是把“每次临场翻箱倒柜”，变成“提前整理好的可检索语料库”。

一个实际用法是：先让 Hermes 安装 Gbrain，再把网站管理资料 import 成 corpus。做完这一步后，Hermes 不再每个 session 都遍历文件来理解业务结构。

这就是知识库层的意义：把高频、稳定、结构复杂的信息，从即时上下文里挪出去。

哪些东西适合进 Gbrain 或类似知识库？

• • 公司网站：页面结构、产品说明、FAQ、品牌语气、历史改版记录。
• • Homelab：服务清单、端口、反代、备份策略、故障处理流程。
• • 个人项目：README、架构说明、常见命令、部署路径、已知坑。
• • 业务运营：价格表、套餐规则、客户问答、邮件模板。

但别把它当魔法。

简单 homelab 是否也值得上 Gbrain？判断标准不用复杂：如果你的资料每周都会被问到、每次查找都要跨多个文件、或者 Agent 经常因为找错文件开始瞎推理，那就值得。如果只是三份 Markdown，别上来就搞知识库。打开文件就行。

工具不是香火，不用供满一桌。

验收标准也别玄学。你可以用 5 个问题测试：

1. 1. Hermes 能不能说清网站/项目的目录结构？
2. 2. 能不能引用具体文件或页面，而不是泛泛回答？
3. 3. 能不能在不全局搜索的情况下回答常见业务问题？
4. 4. 同一个问题隔天再问，答案是否一致？
5. 5. 当知识库没有证据时，它会不会承认“不知道”？

第五条最值钱。做不到这一点，系统会显得很勤奋，但骨子里还是不靠谱。

一个不敢说不知道的 Agent，加再多知识库也是自信地胡说。那玩意儿叫算命，不叫自动化。

第三层是浏览器：真正改变体验的是“可接管”

浏览器层可以拆成 Ego、Vercel Agent Browser、Firecrawl、agent-reach 这几类能力。一个很生活化的用法是：让 Hermes 用 Ego browser 在 IMAX 购票队列里等一小时，轮到时提醒你，然后你接管标签页买票。

这件事看着有点荒诞。

但它恰好说明浏览器层最关键的能力：不是“Agent 能不能点按钮”，而是人能不能随时接管 Agent 正在操作的真实页面。

传统浏览器自动化很容易卡在三个地方：登录、验证码、排队、支付。你让 Agent 全自动跨过去，风险很高；你让它完全不碰，又没意义。共享浏览器的价值就在中间：它可以帮你等、帮你检查状态、帮你准备页面，但关键动作由人接管。

这比“全自动买票”成熟多了。

浏览器工具可以按任务分层：Ego 对应的项目是 citrolabs/ego-lite，更偏共享真实浏览器和人工接管；Firecrawl 适合公开页面抓取；agent-reach 更适合简单搜索和信息收集；Vercel Agent Browser 则适合隔离执行、可复现任务和开发调试。登录 Instagram 这类容易被挡的站点，通常比普通抓取更需要真实浏览器环境。

这里能拆出一个实用分工：

• • 搜索/抓取：agent-reach、Firecrawl 这一类，适合公开页面、信息收集、批量阅读。
• • 真实登录环境：Ego 这种共享浏览器，适合需要登录、排队、人工接管的网站。
• • 云端浏览器：Vercel Agent Browser 这类，适合隔离执行、可复现任务、开发调试。

不要把所有网页任务都丢给一个浏览器工具。太笨重。

如果只是抓公开文章，用爬取工具。需要登录态，用共享浏览器。涉及支付、发送消息、提交表单，设置人工确认点。这个边界不性感，但救命。没有它，所谓自动化很快就会变成权限裸奔。

我的底线是：Agent 可以帮你排队，但别让它替你刷卡。

第四层是观测：Token 烧光前，先看它到底在干什么

第四层很容易被忽略：observability。一个 Agent 装了多个 MCP 和 skills 后，你会突然搞不清它为什么选某个工具，为什么重试，为什么上下文越塞越大，为什么一个小任务烧掉一坨 token。

“烧掉一坨”是技术术语。

token burning 是 Hermes 这类系统很常见的问题。把 iteration 设到 50、在构建 skill 时限制字符/token 用量，确实能让 token 更耐用一点。这个方法有用，但还是偏“口头教育”。

真正应该做的是记录指标：

• • 每个 workflow 调用了哪些工具。
• • 哪些工具失败最多、重试最多。
• • 每次完成任务用了多少上下文和 token。
• • 哪些技能经常被误触发。
• • 哪些 MCP 几乎不用，却每次都占配置和决策空间。

这东西听起来无聊。

但它会告诉你一个扎心真相：有时候让 Hermes 变强的方法不是再装一个插件，而是删掉三个。

追踪 tool failures、retry rates、context size、token usage per completed workflow，往往比增加 plugin 更能找到优化机会。因为 Agent 系统一复杂，问题不再是“缺能力”，而是“能力之间互相干扰”。

像什么呢？像你桌上放了 12 把螺丝刀，结果每次找十字螺丝刀都要翻半天。转头又买了第 13 把。

很人类。

也很蠢。

实操上，不需要一开始就做豪华 dashboard。先建一个最小日志：

workflow: email_triagestarted_at: 2026-07-30T09:00:00Ztools_used: [gmail, calendar, memory_search]retries: 1failed_tools: []approx_tokens: 8200result: draft_readyhuman_takeover: false

每周让 Hermes 自己复盘一次：哪些 workflow 慢，哪些失败多，哪些工具从没用过。然后只做一件事：删、合并、限权或补提示。

别一边漏水一边装修客厅。

第五层是安全和路由：MCP 很酷，也可能很脏

任何 MCP 接入前都应该先做安全审计。MCP Security Audit 这类工具不是装饰，而是权限验收的一部分。MCP servers 很酷，但也可能很脏，这个提醒必须认真。

Agent 一旦接了 MCP，就不只是“会聊天的软件”。它可能读文件、发请求、查邮箱、动日历、看浏览器、调用支付或交易相关 API。尤其是投注、交易、支付这类场景，哪怕收益故事听起来再刺激，也必须先把权限边界写清楚。

我不评价这个收益。

我只说一句：把 Agent 接到交易、投注、邮箱、日程、文件系统之前，先把权限边界写清楚。否则不是智能体，是一个带自信表情的远程遥控器。

安全层至少要有四个门：

1. 1. 最小权限：能只读就只读，能限定目录就别给全盘。
2. 2. 工具审计：新 MCP 先跑安全检查，看它能访问什么、会不会外发数据。
3. 3. 人工确认：发邮件、改日程、提交表单、付款、交易，一律设确认点。
4. 4. 回滚记录：它改了什么，能不能撤，撤回命令在哪里。

这里还牵出另一个能力：路由。

Hermes 更适合做 executive assistant / operations layer。深度开发可以交给 Codex 或 Claude Desktop 这类 implementation worker；Hermes 负责 Wechat、Feishu、邮件、日历、跟进、Drive、检查系统真实状态，以及把任务派给更合适的工具。

这个分工很健康。

Hermes 不必什么都亲自干。它更像前台加调度员：接收需求、找历史、判断任务类型、把深度编码交给 Codex/Claude，把浏览器任务交给 Ego，把长期知识交给 Gbrain，把邮件日历交给对应 MCP。

关键是别让它乱派活。

你可以用一张简单规则表：

这张表不高级。

但比“让 Hermes 自己看着办”强太多。因为“自己看着办”这五个字，在 Agent 世界里经常翻译成：我猜一个，错了再说。

别从工具开始，从一个重复工作流开始

最有价值的建议，不是某个工具名，而是这个顺序：不要从安装很多 skills 开始。先找一个你每周都重复的 workflow，比如邮件 triage、会议 follow-up、项目状态检查，把它做成一个 skill，写清输入、输出和验证步骤。

这话朴素到不像互联网建议。

所以它大概率是对的。

如果你现在想搭 Hermes，我会按这个顺序来：

1. 1. 选一个每周重复的任务：不要选“管理我的人生”，先选“每周五汇总项目状态”。
2. 2. 写成 skill：输入是什么，步骤是什么，输出格式是什么，怎么验证。
3. 3. 接记忆层：记录偏好、实体、旧决策，不要让它每次重新问。
4. 4. 接知识库层：把稳定资料 import 成 corpus，减少全局搜索。
5. 5. 接浏览器层：只处理需要真实页面状态的任务，并设人工接管点。
6. 6. 加观测和安全：记录工具调用、失败、token、权限，定期删掉没用工具。
7. 7. 再考虑模型和 worker 路由：把深度编码交给专门工具，别让 Hermes 硬装全能。

这套顺序的核心不是“保守”。

是别把复杂系统的失败伪装成智能体的成长痛。

很多 Agent 系统不是不够聪明，是太像一个没有项目经理的创业公司：每个人都很努力，每个工具都觉得自己有用，会议开到凌晨两点，没人知道客户到底要什么。

嗯。

熟悉得让人沉默。

总结

• • Hermes 体验提升的核心不是插件数量，而是记忆、知识库、浏览器、观测、安全和路由形成闭环。
• • 第三方 memory provider、Obsidian、Mnemosyne、Gbrain 这类工具要解决的是“连续性”，不是炫技。
• • Ego / Vercel Agent Browser 的价值在于真实登录环境和人工可接管，不是盲目全自动。
• • MCP 和外部 API 必须先做权限、安全审计和人工确认，尤其涉及邮箱、日程、支付、交易时。
• • 最好的起点不是装满工具，而是把一个每周重复 workflow 写成 skill，并要求给出可验证证据。

如果一句话收尾，我会这么说：别急着给 Hermes 买装备。

先教它别乱跑。