Likefr - 技术
type: channel
link: https://likefr.com/index.php/category/%E6%8A%80%E6%9C%AF/
description: 技术
items: SummerMemory Graph 优化:性能提升15倍 + 交互式相似度阈值
items: 记一次 OpenClaw Node Exec 审批问题的踩坑与解决

SummerMemory Graph 优化:性能提升15倍 + 交互式相似度阈值
type: item
date: 2026-06-16T12:40:16+08:00
description: 背景问题SummerMemory Graph（知识图谱可视化）的 /graph-data 接口响应耗时 5.3 秒，随着记忆文件不断增长，这个问题会指数级恶化。问题分析1. O(n²) SQL 查询瓶颈原始代码对每对文件执行一次独立的 PostgreSQL 查询，计算 embedding 向量余弦距离： for i, path1 in enumerate(path_list): for path2 in path_list[i+1:]: cur2.execute(""" SELECT MAX(1 - (m1.embedding <=> m2.embedding)) AS similarity FROM memories m1, memories m2 WHERE m1.path = %s AND m2.path = %s """, (path1, path2)) 100 个文件 = 4950 次 SQL 查询，每次都做向量距离运算。2. 无意义的噪音链接链接由两部分组成： 目录关系链接（同目录即关联，weight=0.3）：4950 条 embedding 语义链接（weight>0.8）：2086 条 大部分记忆文件都在 memory/ 目录下，导致每个节点和所有节点相连，图谱变成毛线团。3. Cosmograph WASM 内存泄漏动态更新 links 时，Cosmograph 的 WASM DuckDB 表生命周期管理有 bug，反复 setConfig 会导致 Array buffer allocation failed。优化方案性能优化：单次查询 + numpy 质心计算 # 一次查出所有 embedding cur2.execute("SELECT path, embedding FROM memories WHERE embedding IS NOT NULL") # Python 内存中计算每个文件的 embedding 质心 for path, embs in path_embs.items(): arr = np.array(embs) centroid = normalize(arr).mean(axis=0) centroids[path] = normalize(centroid) # 内存中 O(n²) 算余弦相似度（向量点积） sim = float(np.dot(c1, centroids[path2])) 结果| 指标 | 优化前 | 优化后 | |------|--------|--------| | 接口耗时 | 5.3s | 0.35s | | SQL 查询次数 | 4950 次 | 1 次 | | 链接数 | 7036（70%噪音） | 891（纯语义） |交互式相似度阈值前端右侧边栏新增滑块控件，拖动即可实时调整链接过滤阈值： 拖动滑块 → debounce 300ms 请求后端 /graph-data?threshold=0.90 后端按阈值过滤返回 links 前端淡出→更新→淡入 + 重新启动模拟动画 这样避免了 Cosmograph WASM 内部表冲突的内存泄漏问题，阈值过滤逻辑全部在后端完成。其他改进 左侧文件列表按 last_updated 降序排列（最新更新的文件在最上面） 去掉了目录关系的噪音链接，只保留 embedding 语义链接 节点数据新增 last_updated 时间字段 技术栈 后端：Python + PostgreSQL（pgvector）+ numpy 前端：Vue 3 + Cosmograph 部署：阿里云 + 宝塔面板 源码 GitHub：[Likefr/SummerMemory](https://github.com/Likefr/SummerMemory) 在线体验：[ai.likefr.com/graph](https://ai.likefr.com/graph)

记一次 OpenClaw Node Exec 审批问题的踩坑与解决
type: item
date: 2026-05-31T16:48:14+08:00
description: 问题描述在使用 OpenClaw Node 执行远程命令时，遇到 SYSTEM_RUN_DENIED: approval required 错误，明明已设置 security: full 和 ask: off，配置显示正确但仍被拒绝。环境信息OpenClaw 版本: 2026.5.28+架构: Gateway (multi-server) + Node (Work-PC / Home-PC)操作系统: Gateway (Ubuntu), Node (Windows + WSL2)目标: 在 Node 上执行远程命令错误现象# 在 Gateway 执行 exec(host="node", node="Work", command="hostname") # 返回 UNAVAILABLE: SYSTEM_RUN_DENIED: approval required排查过程1. 检查 Gateway 配置openclaw config get配置正确：{ "tools": { "exec": { "security": "full", "ask": "off", "host": "auto" } }, "agents": { "list": [{ "id": "main", "tools": { "exec": { "node": "6009e1d3f068e1cab0dcf9c99060b292739a19c2076198cec06ff1922a3bd555" } } }] } }2. 检查 Node approvals 配置cat ~/.openclaw/exec-approvals.json初始配置（有问题的版本）：{ "version": 1, "socket": { "path": "/home/administrator/.openclaw/exec-approvals.sock", "token": "Uh_SGs…xr1n" }, "defaults": { "security": "full", "ask": "off", "askFallback": "full", "autoAllowSkills": true }, "agents": {} }3. 验证 effective policyopenclaw approvals get --node Work输出显示配置正确读取：Effective Policy ┌────────────┬────────────────────────┬───────────────────────┬────────────────────┐ │ Scope │ Requested │ Effective │ Notes │ ├────────────┼────────────────────────┼───────────────────────┼────────────────────┤ │ tools.exec │ security=full, ask=off │ security=full, ask=off │ requested applies │ └────────────┴────────────────────────┴───────────────────────┴────────────────────┘4. 尝试的解决方案（均无效）✅ 修改 Gateway openclaw.json：tools.exec.ask: off✅ 修改 Node exec-approvals.json：移除 permissions 字段✅ 重启 Node 服务：systemctl --user restart openclaw-node✅ 重启 Gateway：openclaw gateway stop && openclaw gateway start✅ 检查 Node 日志：无错误信息✅ 查阅官方文档和 GitHub issue根本原因exec-approvals.json 中的 socket 字段阻止了配置生效。当 socket 字段存在时，OpenClaw 会尝试通过 Unix socket (exec-approvals.sock) 通信来获取 approvals 配置。如果：Socket 文件不存在Socket 文件权限不正确Socket 通信失败则回退到某个默认行为（可能是 deny），导致配置文件中的 security: full 和 ask: off 被忽略。新版推荐方案：exec-policy preset yolo在新版 OpenClaw 中，官方提供了更简洁的方式来一键配置 YOLO 模式（无需手动编辑 JSON）：# 在 Node 端执行（推荐方式） o…