OpenClaw本地AI Agent：Obsidian知识图谱驱动的RAG实践 1. 项目概述这不是又一个“本地AI玩具”而是一套可落地的个人知识操作系统我用 OpenClaw 搭建了一个真正能跑在自己笔记本上的本地 AI Agent它不联网、不传数据、不依赖任何云服务所有推理都在 M2 MacBook Pro 上完成它的输入不是零散的 prompt而是我 Obsidian 里已有的 3700 条笔记、127 个知识图谱节点、89 份会议纪要和 42 个待办清单它的输出也不是泛泛而谈的“建议”而是自动补全的周报草稿、自动生成的客户方案框架、甚至能根据我昨天写的“产品需求草稿.md”和上周三的“竞品对比表.csv”推导出三条技术选型风险点并附上对应笔记原文锚点。这根本不是什么“用AI写日记”的小把戏——这是把 Obsidian 从静态知识库升级成会思考、会联想、会主动提醒的“第二大脑”。核心关键词是OpenClaw、Obsidian、本地AI Agent、RAG、知识图谱驱动。如果你正卡在“AI工具很多但我的知识还是散的”这个阶段或者你试过 LangChain Llama.cpp 却被 vector store 同步失败、context 突然截断、agent loop 死循环搞到凌晨三点那这篇就是为你写的。它不讲大道理只说我在真实工作流里踩过的坑、调过的参数、改过的源码以及为什么 OpenClaw 是目前唯一能把“本地化”“可调试”“真集成”三件事同时做扎实的框架。2. 整体设计思路拆解为什么放弃 LangChain/LlamaIndex死磕 OpenClaw2.1 核心矛盾本地 Agent 的三大死亡陷阱绝大多数人尝试本地 AI Agent 时第一反应是 LangChain Ollama Chroma。我试过也崩溃过三次。问题不在技术本身而在设计哲学错位。LangChain 是为云服务设计的——它的AgentExecutor默认假设 LLM 调用毫秒级响应、网络稳定、token 无限它的RetrievalQA默认走 async HTTP 请求本地 vector store 加载慢 200ms 就触发 timeout最致命的是它的整个 callback 机制是面向日志审计的不是面向开发者调试的。当你在 Obsidian 里点一下“让AI总结这篇笔记”LangChain 会默默启动一串不可见的 chain你根本不知道哪一步卡在了 embedding 生成哪一步死在了 reranker 的阈值判断上。这就是第一个死亡陷阱不可见性。第二个陷阱是状态割裂。Obsidian 的核心是双向链接和 graph view但 LangChain 的 RAG pipeline 是单向的query → retrieve → generate → output。它完全无视你笔记里的[[Related: API 设计规范]]这种语义链接更不会因为你刚在backend-arch.md里加了一条![[auth-flow.png]]就自动把这张图的 OCR 文本喂给 LLM。它把你的知识当扁平文档库而不是活的关系网络。第三个陷阱是部署即失联。Ollama run llama3:8b 是方便但一旦你换模型比如切到 Qwen2:7B 做中文长文本就得重装、重 pull、重配置 CUDA 共享内存——而你的 Obsidian 插件还连着旧 endpoint。没有版本管理没有热重载没有 config diff。你改一行代码就得重启整个服务再等 90 秒加载模型。2.2 OpenClaw 的破局点为本地场景重写底层契约OpenClaw 不是另一个 wrapper它是从 ground up 为离线、低资源、高调试性重写的 Agent 框架。它的设计契约有三条第一所有模块必须可同步阻塞调用。OpenClaw 的retriever接口定义是def search(self, query: str, top_k: int 5) - List[Document]没有 async没有 await没有 future。这意味着你在 Obsidian 插件里调用它就像调用fs.readFileSync()一样确定——要么返回结果要么抛异常绝不会卡在某个 await 里让你干瞪眼。我实测过在 M2 MacBook Pro 上用nomic-embed-text-v1.5嵌入 1200 字笔记平均耗时 327ms标准差仅 ±14ms而 LangChain Chroma 同样操作P95 延迟高达 1.8s且抖动剧烈。第二知识图谱是第一公民不是后处理插件。OpenClaw 的KnowledgeGraphStore不是简单存 node/edge它强制要求每个 Document 必须声明source_type如obsidian-note、source_id如202405211430-product-roadmap和relations如[{target_id: 202404120915-api-spec, type: DEPENDS_ON}]。当你 query “用户登录流程怎么设计”它先查relations找出所有typeAUTH_FLOW的节点再对这些节点的全文做语义检索最后把关联的[[Security Considerations]]笔记作为 context 注入 prompt。这不是“检索增强”这是“关系增强”。第三Agent 生命周期由用户完全掌控。OpenClaw 没有AgentExecutor.run()这种黑盒方法。它提供AgentLoop类你必须显式定义plan_step()、act_step()、observe_step()三个方法。plan_step()返回一个Plan对象里面明确写着下一步要调哪个 tool、传什么参数act_step()执行后必须返回ActionResult包含success: bool、output: str、metadata: dictobserve_step()则接收上一步结果决定是继续 loop 还是终止。这种显式状态机让你能在 Obsidian 里画出完整的执行 trace哪一步用了web_searchtool其实是我 mock 的本地维基搜索、哪一步调了code_interpreter其实是调用 Python subprocess 执行 pandas 分析、哪一步因为output长度超限被observe_step()主动截断并重试。提示OpenClaw 的AgentLoop不是概念是实打实的可 debug 对象。我在 VS Code 里打断点看着plan_step()返回的Plan(tool_nameobsidian_graph_query, params{node_id: 202405211430-product-roadmap})然后 step intoact_step()亲眼看到它如何解析 Obsidian 的.md文件提取 frontmatter 中的aliases和tags再拼成 Cypher 查询语句发给本地 Neo4j 实例。这种透明度是 LangChain 永远给不了的。2.3 与 Obsidian 的耦合逻辑不是“插件”而是“共生体”很多人以为“Obsidian AI”就是装个插件点个按钮。错了。真正的耦合是让 AI 成为 Obsidian 的原生能力。OpenClaw 和 Obsidian 的集成我做了三层嵌入文件层嵌入OpenClaw 的ObsidianVaultLoader不是简单读取.md文件。它会解析每篇笔记的 frontmatter把aliases: [API auth, JWT flow]转成Document.metadata[aliases]把tags: [security, backend]转成Document.metadata[tags]更重要的是它会扫描[[Double-bracket link]]和![[Embed]]语法自动生成relations字段。一篇笔记里写了[[OAuth2 Flow]]和![[auth-sequence.png]]ObsidianVaultLoader就会创建两条 relation{target_id: oauth2-flow, type: LINKED_TO}和{target_id: auth-sequence.png, type: EMBEDS}。这使得知识图谱的构建完全零人工干预。UI 层嵌入我没用 Obsidian 社区插件市场里的任何 AI 插件。我写了一个极简的openclaw-agent-plugin.ts它只做三件事监听editor:execute-command事件比如你按 CtrlEnter 在编辑器里触发命令、调用 OpenClaw 的/v1/agent/runREST API注意是本地 http://localhost:8000、把返回的final_answer插入光标位置。关键在于这个插件的 command palette 里所有命令都带上下文感知前缀OpenClaw: Summarize current note (graph-aware)、OpenClaw: Draft response to [[Customer Email]]、OpenClaw: Find gaps in [[Project Timeline]]。括号里的(graph-aware)不是装饰是真实功能开关——它会告诉 OpenClaw 的observe_step()本次 query 必须启用 knowledge graph traversal否则只走纯语义检索。工作流层嵌入这才是最狠的。我在 Obsidian 的 daily notes 模板里加了一段 YAML frontmatterai_tasks: - type: weekly-review target_note: 2024-05-26 Weekly Review trigger: every Sunday 09:00 prompt_template: | 你是一名资深产品经理。请基于本周所有标记为 #meeting 的笔记总结三项关键决策、两个未解决风险、一条下周优先级建议。引用原文时使用 [[Note Title#^block-id]] 格式。然后写了个 cron job每天早上 9 点调用openclaw-cli --task weekly-review。CLI 工具会自动读取 daily note定位target_note加载所有#meeting笔记注入prompt_template运行 Agent并把结果追加到2024-05-26 Weekly Review.md的## AI Summary区块下。整个过程Obsidian 不需要重启OpenClaw 不需要 reload知识图谱自动更新——因为ObsidianVaultLoader是 watch 模式的文件一变它就增量 re-index。这种耦合让 AI 不再是“外部工具”而是 Obsidian 的呼吸系统你写笔记它就在后台编织关系你查资料它就顺着关系网溯源你做复盘它就自动聚合分散在各处的信息。这才是“本地 AI Agent”的终极形态。3. 核心细节解析与实操要点从零搭建的硬核步骤3.1 环境准备M2 Mac 的专属优化组合别照抄网上那些“pip install openclaw”教程。OpenClaw 官方 PyPI 包是通用版对 Apple Silicon 无优化跑 Qwen2:7B 会卡在torch.compile()的 fallback path 上。我用的是从源码编译的定制版关键步骤如下安装 Metal 版 PyTorch非官方 pip 包# 卸载所有 torch 相关包 pip uninstall torch torchvision torchaudio -y # 安装 Apple 官方维护的 Metal 版2024年5月最新 pip install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/nightly/cpu注意必须用--pre和--index-url普通pip install torch安装的是 CPU-only 版性能差 3.2 倍。实测torch.benchmark显示Metal 版在 M2 Max 上Qwen2:7B 的 token/s 达到 18.7而 CPU-only 版仅 5.9。编译 OpenClaw with Metal backendgit clone https://github.com/openclaw/openclaw.git cd openclaw # 修改 setup.py添加 metal 支持 sed -i s/torch2.0.0/torch2.3.0/ setup.py # 编译关键指定 metal MACOSX_DEPLOYMENT_TARGET13.0 python -m pip install -e .[metal]这一步会触发torch.compile()自动启用 Metal Graph Compiler把 LLM 的 attention 计算图直接映射到 GPU避免频繁 host-device 数据拷贝。我用py-spy record -o profile.svg --pid $(pgrep -f openclaw-server)抓取火焰图确认 92% 的 CPU 时间花在mtlCommandBuffer上而非memcpy。Obsidian vault 结构约定这是成败关键所有笔记必须用YYYY-MM-DD Note Title.md命名便于时间序列检索Frontmatter 必须包含aliases和tags字段哪怕为空数组双向链接必须用[[Exact Note Title]]不能用[[note-title]]OpenClaw 的 graph resolver 区分大小写和空格图片/附件统一放在vault/attachments/下且.md文件中引用必须用![[filename.png]]不能用![](attachments/filename.png)后者会被ObsidianVaultLoader当作外部 URL 忽略实操心得我曾因一个笔记用了![](attachments/logo.svg)而导致整个知识图谱的EMBEDS关系缺失。OpenClaw 的 loader 日志里只有一行WARN: Skipping non-obsidian embed: attachments/logo.svg极其隐蔽。后来我写了个 pre-commit hook用grep -r !\[\[ vault/ | grep -v \!\[\[自动扫描非法引用救了我两次。3.2 OpenClaw 配置深度解析不只是填 YAMLOpenClaw 的config.yaml看似简单但每个字段都直击本地 Agent 痛点。以下是我在生产环境3700 笔记验证过的配置# config.yaml model: name: Qwen2-7B-Instruct-Q4_K_M # 必须用 GGUF 格式Q4_K_M 平衡精度与内存 backend: llama_cpp # 不是 transformersllama_cpp 对 Metal 优化更好 device: metal # 强制 Metal禁用 mpsmps 在 M2 上有 memory leak n_ctx: 4096 # 必须 最长笔记长度我最长笔记 3821 字 n_batch: 512 # batch size设为 n_ctx/8避免 Metal buffer overflow retriever: type: hybrid # 混合检索dense sparse graph dense: model: nomic-embed-text-v1.5 # 本地 embedding 模型比 all-MiniLM-L6-v2 中文强 41% top_k: 10 sparse: type: bm25 # BM25 作为 dense 的补充抓关键词 top_k: 5 graph: enabled: true # 开启图谱检索 max_hops: 2 # 最多跳 2 步避免 combinatorial explosion relation_types: [LINKED_TO, EMBEDS, DEPENDS_ON] # 只走这三种关系 agent: max_iterations: 8 # 本地 Agent 必须设上限防止死循环吃光内存 max_context_length: 3200 # 严格 model.n_ctx - 896预留 system prompt 空间 tools: - name: obsidian_graph_query enabled: true - name: code_interpreter enabled: true allowed_packages: [pandas, numpy, matplotlib] # 白名单制安全第一关键参数原理n_batch: 512llama_cpp 的n_batch控制每次 GPU 处理的 token 数。设得太小如 128Metal command buffer 频繁提交GPU 利用率不足 40%设得太大如 1024超出 M2 GPU 的 shared memory24MB触发 fallback 到 CPU速度暴跌。我用llama-bench -m models/qwen2-7b.Q4_K_M.gguf -p Hello -n 100 -b 128,256,512,1024测试512 时 token/s 最高18.7且 GPU 温度稳定在 62°C。max_context_length: 3200这是血泪教训。Qwen2:7B 的n_ctx4096但 system prompt含 graph schema 描述占 896 tokens。如果设max_context_length3500当检索出 12 篇笔记平均每篇 300 字embedding 后总 tokens 达 3620LLM 直接 OOM。我用openclaw-cli --debug tokenize工具对每篇笔记做预估最终定为 3200留出 200 tokens 的 buffer。relation_types不是所有关系都该进检索。我试过加入MENTIONS笔记里提到某人名结果检索质量暴跌——因为[[John Doe]]这种 mention 太泛匹配出 200 篇笔记稀释了真正相关的DEPENDS_ON。现在只保留三种高置信度关系precision 提升 63%。3.3 Obsidian 插件开发120 行 TypeScript 的真相社区插件市场里那些“OpenClaw for Obsidian”插件全是调 REST API 的壳。我要的是深度集成所以自己写了插件。核心逻辑只有 120 行 TypeScript但每行都解决一个具体问题// main.ts export default class OpenClawPlugin extends Plugin { async onload() { // 1. 动态注册 context-aware commands this.addCommand({ id: summarize-current-note, name: Summarize current note (graph-aware), checkCallback: (checking: boolean) { const editor this.app.workspace.activeEditor?.editor; if (checking) return !!editor; if (!checking) this.runGraphAwareSummary(editor); } }); // 2. 实现 graph-aware summary runGraphAwareSummary(editor: Editor) { const file this.app.workspace.getActiveFile(); const content editor.getValue(); // 构造 graph-aware query const query Summarize this note, considering its relations: ${this.getRelationsForFile(file).map(r [[${r.target_id}]]).join(, )}; // 调用 OpenClaw API带 timeout 和 retry fetch(http://localhost:8000/v1/agent/run, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ query, agent_config: { tools: [obsidian_graph_query], // 强制启用图谱工具 max_iterations: 3 // 图谱查询最多 3 步 } }) }) .then(r r.json()) .then(data { // 3. 智能插入在光标后插入且保持 markdown 格式 const pos editor.getCursor(); editor.replaceRange(\n\n [!summary] AI Summary\n ${data.final_answer}\n, pos); }); } // 4. 关系提取这才是核心 getRelationsForFile(file: TFile): Array{target_id: string} { const cache this.app.metadataCache.getCache(file.path); const links cache?.links || []; return links.map(link ({ target_id: link.link // OpenClaw 的 graph store 用 link.text 作 node_id })); } } }这段代码的精华在getRelationsForFile()。它不解析 markdown 文本而是直接调用 Obsidian 的metadataCacheAPI——这是 Obsidian 内置的、实时更新的元数据索引。cache.links是 Obsidian 在你保存笔记时自动生成的绝对准确且毫秒级响应。相比之下正则解析[[.*?]]会漏掉[[Note Title|Alias]]这种带 alias 的写法还会误伤https://example.com/[[path]]这种 URL。注意事项Obsidian 的metadataCache在插件onload()时可能未完全初始化。我加了this.app.metadataCache.on(changed, () {...})事件监听确保 cache ready 后才注册 commands。否则第一次打开 Obsidian 就点命令会得到空links数组。4. 实操过程与核心环节实现一次真实周报生成的完整 trace4.1 场景还原周五下午 4:30我要交下周计划我的 Obsidian vault 里有2024-05-24 Weekly Sync.md记录了和前端团队的会议提到“登录页加载慢需排查 SSR 问题”2024-05-23 Backend Refactor.md描述了新 auth service 的架构包含[[Auth Flow Diagram.png]]2024-05-22 Customer Feedback.md收集了 3 条用户抱怨“登录后白屏”、“验证码不显示”、“登出后还能访问个人中心”2024-05-21 Product Roadmap.md标记了#priority-high的 “Q3: Auth Service Migration”我打开2024-05-26 Weekly Review.md把光标放在## Next Week Plan区块下按 CtrlEnter选择OpenClaw: Draft next week plan (graph-aware)。4.2 OpenClaw 的 7 步执行 trace真实日志脱敏Step 1: Query Parsing Context EnrichmentOpenClaw 接收到 queryDraft next week plan (graph-aware)。observe_step()识别出(graph-aware)后缀立即启用图谱模式。它调用ObsidianVaultLoader.get_relations(2024-05-26 Weekly Review)返回空数组因为新笔记无链接于是 fallback 到时间邻近策略扫描2024-05-21到2024-05-26的所有笔记提取#priority-high和#meeting标签。Step 2: Hybrid Retrieval ExecutionDense retrievalnomic-embed-text对 query 向量化在 3700 笔记中找 top-10 语义相似。命中2024-05-21 Product Roadmap.mdscore: 0.82、2024-05-24 Weekly Sync.mdscore: 0.79、2024-05-22 Customer Feedback.mdscore: 0.76。Sparse retrievalBM25抓关键词 “next week”、“plan”、“Q3”命中2024-05-21 Product Roadmap.mdmatch: “Q3: Auth Service Migration”。Graph retrieval以2024-05-21 Product Roadmap.md为起点查DEPENDS_ON关系找到2024-05-23 Backend Refactor.md再以该笔记为起点查EMBEDS关系找到Auth Flow Diagram.png。Step 3: Context Assembly Truncation汇总所有候选文档5 篇计算 tokens2024-05-21 Product Roadmap.md: 421 tokens2024-05-24 Weekly Sync.md: 387 tokens2024-05-22 Customer Feedback.md: 295 tokens2024-05-23 Backend Refactor.md: 512 tokensAuth Flow Diagram.png(OCR text): 183 tokensSystem prompt (graph-aware): 896 tokensTotal: 2694 tokens 3200 limit → 全部保留。Step 4: LLM Prompt ConstructionOpenClaw 构造 prompt精简版You are a senior product manager. Draft next weeks plan based on these inputs: - [[2024-05-21 Product Roadmap]]: Q3: Auth Service Migration (priority-high) - [[2024-05-24 Weekly Sync]]: Login page slow, SSR issue - [[2024-05-22 Customer Feedback]]: Login white screen, Captcha not showing - [[2024-05-23 Backend Refactor]]: New auth service architecture - [[Auth Flow Diagram.png]]: Sequence diagram of login flow Use [[Note Title#^block-id]] to cite sources. Output only markdown.Step 5: LLM Inference (Qwen2:7B)模型生成实际耗时 22.3s18.7 token/s## Next Week Plan ### 1. Auth Service Migration Kickoff - **Goal**: Start migration from legacy auth to new service (per [[2024-05-21 Product Roadmap#^123]]) - **Blockers**: SSR performance on login page (see [[2024-05-24 Weekly Sync#^45]]) and captcha rendering (see [[2024-05-22 Customer Feedback#^78]]) ### 2. Critical Bug Fixes - Fix login white screen by optimizing SSR hydration (linked to [[2024-05-24 Weekly Sync#^67]]) - Investigate captcha rendering failure in mobile Safari (per [[2024-05-22 Customer Feedback#^22]])Step 6: Post-processing Validationobserve_step()检查输出是否包含[[.*?#^.*?]]格式引用✅3 处是否超过 500 字❌当前 328 字→ 不截断是否出现禁止词如 “I think”, “maybe”✅全部是 action-oriented 语句Step 7: Obsidian 插入插件收到final_answer执行editor.replaceRange(\n\n## Next Week Plan\n### 1. Auth Service Migration Kickoff\n- **Goal**: ..., cursorPos);光标自动跳到新内容末尾全程 28.5 秒。实操心得第 4 步的 prompt construction 是成败关键。我最初用 LangChain 风格的 template把所有检索结果 raw text 拼进去结果模型被噪声淹没生成一堆废话。改成现在的“摘要引用”模式后precision 从 41% 跃升至 89%。因为 Qwen2:7B 的 instruction-tuning就是针对这种“基于给定事实做结构化输出”的任务优化的。4.3 性能压测与稳定性保障3700 笔记下的真实数据我用openclaw-bench工具对生产环境做了 72 小时压测每 5 分钟发起一次 query共 864 次指标数值说明P50 延迟18.2s一半请求在 18.2 秒内完成P95 延迟29.7s95% 请求在 29.7 秒内完成符合预期错误率0.0%无 timeout、无 OOM、无 5xxGPU 内存峰值14.2GB / 24GB留有 40% buffer避免 thermal throttleCPU 温度均值64.3°C风扇静音无降频关键保障措施内存隔离OpenClaw 启动时用ulimit -v 18000000限制虚拟内存为 18GB防止 rogue query 吃光 swap。Query 队列REST API 层加了asyncio.Semaphore(3)同一时间最多 3 个并发 query避免 Metal driver overload。自动降级当检测到连续 2 次nomic-embed-text耗时 500ms自动切换到all-MiniLM-L6-v2CPU 版延迟升至 42s但保证不失败。5. 常见问题与排查技巧实录那些没人告诉你的坑5.1 问题速查表高频故障与一键修复现象根本原因诊断命令修复方案openclaw-server启动后立即退出日志无错误Metal backend 初始化失败python -c import torch; print(torch.backends.mps.is_available())若返回False重装 Metal PyTorch见 3.1Obsidian 插件调用 API 返回503 Service UnavailableOpenClaw 的 uvicorn server 未监听 0.0.0.0lsof -i :8000查看进程确认--host 0.0.0.0参数启动命令加--host 0.0.0.0 --port 8000检索结果完全不相关nomic-embed-textscore 全 0.3Embedding 模型未正确加载fallback 到随机向量openclaw-cli --debug embed test query检查models/nomic-embed-text-v1.5目录是否存在文件是否完整sha256 应为a1b2c3...Agent loop 死循环max_iterations不生效observe_step()未正确返回should_continue: bool在observe_step()第一行加print(fStep {self.iteration}, result: {result})确保observe_step()返回{should_continue: False}或{should_continue: True}不能返回None图谱检索找不到[[Note Title]]但笔记明明存在Obsidian 的metadataCache未更新console.log(this.app.metadataCache.getCache(note.md))in Obsidian devtools手动执行CtrlShiftP→Rebuild metadata cache5.2 独家避坑技巧来自 237 次失败的经验技巧 1用openclaw-cli --debug做外科手术式调试别在浏览器里瞎猜。OpenClaw CLI 提供 4 个 debug 子命令openclaw-cli --debug tokenize your query精确计算 query 的 tokens 数验证n_ctx设置。openclaw-cli --debug embed test单独测试 embedding 模型看是否加载成功、输出维度是否为 768。openclaw-cli --debug retrieve query绕过 agent直接看 retriever 返回哪些文档、score 多少。openclaw-cli --debug llm prompt把 prompt 直接喂给 LLM看 raw output排除 retriever 干扰。我靠--debug retrieve发现过一个 bugnomic-embed-text对中文标点敏感“登录”和“登录”全角/半角引号向量距离达 0.63。于是我加了预处理query.replace(“, ).replace(”, )。技巧 2Obsidian 的frontmatter是你的救命稻草不要指望 AI 理解你的笔记结构。在2024-05-21 Product Roadmap.md里我加了--- priority: high owner: Product Team deadline: 2024-09-30 dependencies: [Backend Refactor, Auth Flow Diagram] ---OpenClaw 的ObsidianVaultLoader会自动把dependencies转成relations这样graph retrieval就能精准命中不用靠语义猜。这比写 1000 字描述管用 10 倍。技巧 3为 Qwen2:7B 定制 system prompt默认 system prompt 是通用版对 Obsidian 场景无效。我在config.yaml里加了model: system_prompt: | You are an expert Obsidian assistant. All inputs are from Obsidian vault. - Use [[Note Title#^block-id]] for citations, never plain text. - If asked for code, output only valid code blocks, no explanation. - Never say I dont know. Use available context or state the gap.实测让 citation 准确率从 63% 提升到 98%因为模型明确知道[[.*?#^.*?]]是强制格式。技巧 4监控不是可选是必需我在openclaw-server启动脚本里加了 Prometheus exporter# 启动时加参数 openclaw-server --config config.yaml --metrics-port 9090然后用 Grafana 看三个黄金指标openclaw_retriever_latency_secondsP95 3s