Hermes Agent 的应用 · 草稿
0x00 序※
聊天模型本身不缺，缺的是一条能落到自己手里的工作流。只在聊天框里问问题，答案在会话里；一旦要查服务器、读笔记、处理邮件、记录结果，信息就散回各处了。
我想要的不是“多一个能聊天的 AI”，而是一个能接进既有系统的 agent：它有边界、有记录，能读知识库，也能在批准后操作远端工具。这篇把这条链路拆开：知识库、远程执行、MCP 网关，以及模型调用统计分别解决什么问题。
0x01 先把能力接进工作流※
Hermes 原本就是我的消息与 webhook 网关，连接 QQ、Telegram、告警等入口。它适合承接“事情来了以后怎么办”；但 agent 还需要能读写长期信息。
知识库这边，Trilium 同时保留两条通道：
- ETAPI：批量、脚本、定时和跨机器同步；
- MCP：对话里即时搜索、创建、修改单篇笔记。
这不是二选一。ETAPI 负责机器对机器，MCP 负责 agent 对人。结果就是：一次排障的结论不再只留在聊天记录里，可以直接沉到笔记；下一次再问，agent 有可追溯的上下文，而不是从零猜。
0x02 远程操作不是把 SSH 直接暴露出去※
真正危险的不是“AI 会执行命令”，而是把一个没有权限边界、没有审计、没有反向代理约束的 shell 直接交给它。
所以远程执行单独用了 ssh-mcp：服务作为 systemd user service 运行在本机端口，使用 Bearer token 鉴权；公网入口由 Caddy 按路径分流，/mcp 转到 ssh-mcp，原有 Trilium 服务不改。HTTPS 下已验证过 initialize 与 tools/list，也实际通过 443 执行过只读磁盘查询。
这层设计的重点不是“能通”，而是四件事：
- 最小权限：默认只给必要工具；读命令、写命令、服务控制应分级。
- 显式审批：有副作用的操作必须能看见目标、命令和影响范围。
- 审计留痕：谁在何时调用了什么工具、返回什么结果，都能回查。
- 边界收口：服务只暴露单一入口；令牌不进笔记、不进仓库、不出现在日志里。
MCP 只是协议，不是权限系统。协议把“工具”交给模型；认证、授权、审批和审计仍然得由网关和宿主系统负责。
0x03 客户端边界比协议更现实※
同一套 MCP 服务，在不同客户端的体验并不一样。
桌面端可以使用 Streamable HTTP + Bearer token 的接入方式；网页和移动端则受 OAuth/ORS 能力与产品入口约束。尤其是 iPhone 端不能像桌面端那样直接填入自定义 MCP，这意味着“服务器已部署成功”不等于“所有设备都能用”。
这也改变了架构取舍：核心能力放服务器，桌面端作为完整控制台；移动端以消息、通知、只读查询和经审批的轻操作为主。不要为了让手机也能直连，就把本来应留在网关后的高权限接口裸露出来。
0x04 模型网关解决的不是聊天，而是账本※
模型来源一多，成本和行为就开始失去可见性：ChatGPT、IDE、OpenCode、Hermes 各自走各自的通道，谁消耗了多少 token、用了什么模型、哪类任务最贵，最后很难对账。
因此还在评估把调用收敛到模型网关：重点不是把订阅当 API 转发，而是为可合规接入的 API 调用建立统一的日志和统计维度——调用方、模型、输入输出 token、失败率、延迟与费用。订阅型产品与 API 的边界必须保留，不能为了统计而走违反服务条款的转发方案。
0x05 还没有解决完的事※
这套东西现在不是“全自动自治”，仍有几个硬边界：
- 移动端与网页端的 MCP 接入能力不一致；
- OAuth/地区限制会影响部分登录与授权流程；
- 高权限工具如何做更细的策略、审批与密钥轮换；
- 长期存储、审计日志和模型用量如何统一观测；
- 自动化应如何在失败时安全降级，而不是把错误扩大。
0xFF 跋※
把 AI 接进工作流，不是把更多账号和密钥塞给它。真正值得搭的是一层可控的接口：知识沉淀有位置，远程执行有边界，模型调用有账本，失败时能退回来。
聊天框是入口，不是系统。Hermes、Trilium、MCP 和网关拼起来之后，agent 才开始从一次性的问答工具，变成可以长期协作、但仍然受控的工作节点。
