GBrain 查询感知机制与发挥策略分析

一、场景分析：GBrain 查询感知机制

1.1 问题背景

在对话中通过 MCP 工具调用 gbrain 进行查询（query/search/think 等）时，gbrain 是否有日志记录这些查询？如果当前无记录，能否启用？

1.2 现有日志基础设施

gbrain 内置了 mcp_request_log 审计表（同时存在于 PGLite 和 Postgres 引擎）：

mcp_request_log (
  id            SERIAL PRIMARY KEY,
  token_name    TEXT,         -- 调用方身份
  agent_name    TEXT,         -- 可读的 agent 名称
  operation     TEXT NOT NULL, -- 调用的工具名
  latency_ms    INTEGER,      -- 响应耗时
  status        TEXT,          -- success / error / rate_limited
  params        JSONB,         -- 请求参数（默认脱敏）
  error_message TEXT,
  created_at    TIMESTAMPTZ
)

索引：idx_mcp_log_time_agent(created_at, token_name)、idx_mcp_log_agent_time(agent_name, created_at DESC)

1.3 两层传输的关键差异

维度	HTTP 传输层（gbrain serve --http）	Stdio 传输层（当前模式）
mcp_request_log 写入	✅ 每次 tools/call 完整记录	❌ 无任何写入
Admin SSE 实时推送	✅ /admin/events 广播	❌ 不支持
管理面板日志查询	✅ 24h 请求量/错误率/分页	❌ 无
参数值记录	🔒 默认脱敏（只记录 declared_keys + approx_bytes）	N/A 不记录
--log-full-params 选项	✅ 可启用完整参数（启动有警告）	N/A
last_used_at 更新	✅ 60s 去重	❌ 无

1.4 脱敏机制（summarizeMcpParams）

默认情况下，即使 HTTP 传输层记录 params，也不会记录 query 原文字段值，而是只记录：

redacted: true
kind: "object" / "array"
declared_keys: 传入的参数名列表（如 ["query", "limit"]）
approx_bytes: 粗略大小（向上取整到 1KB 粒度，防侧信道）
unknown_key_count: 非声明参数的数量

这一设计的目的是防止隐私数据（人名、公司名、查询关键词等）长期留存。

1.5 现状结论

当前 gbrain 以 stdio MCP 子进程方式集成在 Hermes 中，没有任何查询日志。Stdio 传输层设计上就是"本地 pipe，OS 级别信任，不做持久化日志"。如果希望有日志，需要改为 HTTP 传输层（gbrain serve --http --port 8765），然后 Hermes 的 config.yaml 中把 MCP server 的 transport 改为 http 指向该端口，同时配置 access token 认证。

二、如何发挥 GBrain

2.1 GBrain 的核心能力

能力	说明	适用场景
混合搜索（query）	向量+关键词双通道检索+多查询扩展	知识检索、记忆召回
关键词搜索（search）	pg_trgm 模糊匹配	精确查找已知实体
图谱遍历（traverse_graph）	沿 link 关系逐层展开	关系查询、关联分析
多跳推理（think）	跨页面+跨 takes 的综合推理回答	复杂问题、需要综合判断的场景
时间线记录	实体级 timeline 事件管理	项目历史追踪
预测校准（takes）	带权重的预测 + Brier 评分校准	投资判断、决策跟踪

2.2 当前集成方式的局限

查询无感知：stdio 模式下无日志，无法追溯"哪些查询被触发过"
数据增长被动：gbrain 的内容只靠对话中主动 put_page 写入，缺乏自动化的数据同步机制
功能未被充分利用：当前会话主要使用 query/search/get_page，think 和 traverse_graph 等高级功能尚未融入工作流

2.3 发挥策略

数据策略：建立定期的知识注入管线——Trilium 笔记 → 定时同步到 gbrain page；对话中的重要结论 → 自动 put_page 写入
查询策略：在对话中，Hermes 主动检测实体提及后自动调用 gbrain query 补充背景，而非被动等待用户要求查
推理增强：对于涉及多因素的决策问题，先用 think 进行多跳检索+推理，而非仅做单次 query
决策追踪：利用 takes 系统记录投资判断，并定期检查校准效果
异常监控：find_anomalies 定期扫描——哪些实体被触发多了、少了，发现知识盲区

三、GBrain 有必要独立 Docker 化？

3.1 当前架构

Hermes 容器
  ├── Hermes Gateway（主进程）
  ├── Subagent 子进程
  └── gbrain（MCP stdio 子进程，bun serve）
       └── PGLite 数据库（/opt/data/home/.gbrain/）

gbrain 作为 Hermes MCP stdio 子进程运行，共享容器文件系统，数据存储在宿主挂载卷中。

3.2 独立化的收益

维度	当前 stdio 子进程	独立 Docker
部署耦合度	高——gbrain 随 Hermes 启停	低——可独立升级、重启、扩缩容
资源隔离	共享 CPU/内存，bun 进程可能竞争	独立 cgroup，可单独限制资源
故障隔离	gbrain crash → Hermes 失去 MCP 工具	独立容器，不影响 Hermes 主进程
传输层选择	仅支持 stdio	可暴露 HTTP 端口，启用日志/认证
维护复杂度	低——无需额外编排	需 compose 编排 + 端口映射
数据持久化	依赖宿主卷映射	依赖 volume 或 bind mount

3.3 建议

短期：保持 stdio 子进程模式。当前 gbrain 仅用于会话中知识检索，PGLite 引擎轻量（无外部依赖），stdio 延迟最低且无需额外认证配置。没有日志对当前使用场景来说是可接受的——查询结果体现在对话上下文里，本身就是"活日志"。

中期触发 Docker 化的信号：

需要 HTTP 传输层启用审计日志——独立容器+HTTP 端口暴露是前提
gbrain 升级频率高于 Hermes——独立容器可单独拉镜像/重启
切换到 Postgres+pgvector 引擎——数据库独立于应用容器是标准模式
gbrain 数据量大幅增长，需要独立资源控制
多个 Hermes 实例共享同一个 gbrain——此时 gbrain 应作为独立服务暴露

架构方案（Docker 化后）：

+-------------------+      MCP HTTP       +------------------+
| Hermes H01~H04    |◄────────────────────►| gbrain 容器       |
| (4× Hermes 实例)   |   token 认证        | (bun serve --http)|
+-------------------+                     +--------+---------+
                                                   |
                                          +--------+---------+
                                          | PGLite 或 Postgres |
                                          +-------------------+