Hermes-Agent：解决方案与工程实践
目录
安全基线：先读官方 Security
Hermes 同时覆盖 终端 与 公网消息表面，风险面比「纯本地 demo」大得多。请把 Security 作为上线前 checklist 的主文档，而不是零散搜 issue。
建议把安全讨论拆成四块，每块都能落到「谁负责、如何审计、如何回滚」：
- 入站身份：DM 配对、白名单、以及「谁能触发工具」的边界。
- 出站能力：哪些工具默认开启？是否需要二次确认？
- 密钥管理：API Key、Bot Token、MCP 凭证的存储与轮换策略。
- 供应链：MCP Server 从哪来、更新策略是什么（见下文 MCP 小节）。
安全评审最小问题清单（建议打印）
- 谁能给 bot 发私聊？是否需要审批？
- 哪些工具可以在群里执行？哪些必须私聊？
- 失败时是否会把敏感信息写进日志？
配置管理：从单文件到团队协作
官方提供配置与环境变量的完整参考：
团队实践建议：
- 把「可公开默认值」与「机密」分离；机密走密钥管理，不进仓库。
- 变更要走 review，尤其是 gateway 与 tools 相关项。
- 为「生产/预发/个人」准备不同 profile，避免手滑用错 Key。
命令审批与最小权限
README 提到命令审批（command approval）等机制；工程上要把审批规则写成可测试的策略，例如：
- 哪些模式匹配需要人工确认？
- 哪些操作永远拒绝（例如破坏性文件操作、向未知地址发起金融类请求等）？
不要依赖「模型很聪明所以不会乱点」——在工具权限面前，模型是调用者，不是担保人。
容器隔离与运行后端选择
若 agent 需要强隔离，优先评估官方文档中关于 container isolation 的说明，并结合你的后端（Docker/远程沙箱等）做网络与卷挂载最小化。评估表建议包含：
| 项 | 追问 |
|---|---|
| 文件系统 | 是否挂载了整个 $HOME？ |
| 网络 | 是否能访问内网管理网段？ |
| 身份 | 容器内运行用户与宿主机用户映射关系 |
MCP：扩展能力与供应链风险
MCP 让能力扩展很快，但也引入供应链风险（恶意 server、过度授权）。建议：
- 仅安装可信来源的 MCP Server，并限制其网络访问范围。
- 记录「哪个 MCP 提供了哪些工具」，便于审计与回滚。
详见 MCP Integration。
定时任务与通知疲劳
Cron 能力很强，但很容易造成「每晚 200 条 Telegram」式的组织伤害。建议：
- 先对单人账号试验，再接入群。
- 输出要结构化（摘要 + 链接），控制推送频率。
见 Cron。
定时任务的“运营参数”
除了技术配置，还要定义：触发频率、静默窗口、失败告警对象。否则会出现“技术上成功、组织上失败”。
可观测性：日志与排障入口
把 hermes doctor 作为一线工具；复杂问题回到官方 CLI 参考与 issue 搜索。对生产用途，建议额外记录：
- 网关进程存活与重启原因
- 工具调用失败率与平均耗时
- 各渠道入站速率（用于发现被刷）
CLI 全量命令见 CLI Reference。