1. 为什么量化投研需要一个“第二大脑”做量化投研的人都有一个共同的痛点信息过载。每天要读几十份研报、跟踪上百个因子、记录无数次回测结果还要把宏观数据、行业逻辑、个股基本面串成一条线。时间一长你会发现真正值钱的不是某个策略代码而是你过去三年积累下来的研究脉络和决策依据。这些东西散落在微信收藏、浏览器书签、本地txt、Excel表格里用的时候找不到找到了又看不懂当时的上下文。我从2023年开始系统性地搭建个人知识库试过Notion、Logseq、思源笔记最后稳定在Obsidian上。原因很简单本地Markdown存储、双向链接、插件生态开放。这三个特性决定了它不只是一个笔记软件而是一个可以被程序读写、被AI Agent调用的结构化知识底座。你标题里提到的OpenClaw本质上是一个AI Agent框架它需要“养料”才能持续输出有价值的分析。Obsidian知识库就是那个养料库——把非结构化的投研笔记变成Agent可以检索、推理、引用的长期记忆。这篇文章适合三类人一是正在做量化投研、苦于知识管理混乱的从业者二是想用AI Agent辅助投资决策但不知道从哪里喂数据的开发者三是已经用上Obsidian但只把它当记事本、没发挥出真正价值的中级用户。我会从整体设计思路讲到具体配置再到实际跑通一个“研报自动归档因子逻辑关联Agent问答”的完整链路。你不需要是程序员但需要愿意动手改配置、写几行简单的脚本。2. 整体架构设计Obsidian如何成为Agent的长期记忆2.1 核心思路把知识库当成数据库来设计大多数人用Obsidian是“写日记”模式今天想到什么记什么文件夹随便建标签随手打。这种用法对人脑友好但对AI Agent极其不友好。Agent需要的是可预测的结构、稳定的元数据、明确的关联关系。所以第一步要转变思维你不是在写笔记你是在建一个面向机器读取的知识图谱。我的方案是把知识库分成四层原始素材层、加工笔记层、因子逻辑层、决策记录层。原始素材层放PDF摘录、网页剪藏、数据截图加工笔记层放我对这些素材的总结和思考因子逻辑层放可复用的量化逻辑比如“动量因子在A股中证500的IC衰减规律”决策记录层放每次调仓的理由和事后复盘。这四层通过Obsidian的[[双向链接]]和YAML frontmatter串联起来形成一个有向图。为什么这么分因为Agent在回答“为什么上周减仓新能源”时需要沿着“决策记录→因子逻辑→加工笔记→原始素材”这条链路回溯而不是在一堆日记里做语义搜索。语义搜索会漏掉关键上下文而结构化链接不会。2.2 为什么选Obsidian而不是Notion或LogseqNotion的问题在于数据在云端API有速率限制而且块结构对程序读写不友好。Logseq的outliner模式适合大纲式思考但量化投研需要大量表格和代码块Logseq的渲染性能跟不上。Obsidian的本地文件系统纯Markdown意味着你可以用任何编程语言直接读写文件不需要经过API。Python的pathlib、frontmatter库、markdown库就能完成90%的操作。另一个关键点是插件生态。Obsidian有Dataview插件可以用类SQL语法查询笔记有Templater插件可以自动化生成模板有Obsidian Git插件可以做版本控制。这些插件组合起来就是一个轻量级的“知识库操作系统”。OpenClaw作为Agent框架只需要通过文件系统读取这些Markdown文件就能获得结构化的上下文。2.3 OpenClaw在架构中的角色OpenClaw不是替代Obsidian而是Obsidian的“消费者”。它的工作流程是定时扫描知识库中新增或修改的笔记→提取YAML元数据和正文→构建向量索引和关键词索引→当用户提问时先做混合检索→把检索结果作为上下文喂给大模型→生成回答并写回Obsidian作为新的决策记录。这个闭环的关键在于写回机制。很多Agent只读不写导致每次对话都是“一次性”的没有积累。OpenClaw可以把每次问答的结论自动生成一篇Markdown笔记打上#agent-output标签并链接到相关的因子笔记。这样你的知识库会随着使用越来越厚Agent的长期记忆也越来越强。3. 知识库结构搭建从文件夹到元数据规范3.1 文件夹结构设计我不建议用太深的文件夹层级因为Obsidian的搜索和Dataview已经能解决分类问题。我的结构是/KnowledgeBase /00-Inbox # 临时剪藏每周清理 /01-Sources # 原始素材研报PDF摘录、数据截图、网页存档 /02-Notes # 加工笔记行业分析、个股研究、宏观复盘 /03-Factors # 因子逻辑可复用的量化逻辑卡片 /04-Decisions # 决策记录调仓理由、事后复盘 /05-Agent # Agent输出自动生成的问答记录 /99-Templates # 模板文件 /99-Attachments # 图片、PDF等附件这个结构的好处是编号前缀强制排序在文件管理器里和Obsidian侧边栏里都是一致的。00-Inbox是唯一允许“乱”的地方其他文件夹都有明确的元数据规范。3.2 YAML frontmatter规范每篇笔记的顶部必须有YAML frontmatter这是Agent读取元数据的入口。我定义的字段包括--- title: 动量因子在中证500的IC衰减分析 date: 2025-03-15 type: factor tags: [factor/momentum, market/csi500, status/verified] source: [[2025-03-10 中金量化研报]] related_factors: [[[反转因子]], [[波动率因子]]] confidence: 0.85 last_review: 2025-06-01 ---type字段决定这篇笔记在知识图谱中的角色Agent会根据type决定如何处理。confidence是我对这条逻辑的置信度0到1之间每次复盘后更新。last_review用于提醒自己定期回顾避免过期逻辑被Agent误用。注意YAML对缩进和冒号极其敏感。建议用Templater插件自动生成frontmatter避免手写出错。特别是tags字段如果写成tags: factor/momentum而不是列表Dataview查询会失效。3.3 双向链接的三种用法Obsidian的双向链接不只是“相关笔记”在量化投研场景下有三种明确用法第一种是证据链链接。在决策记录里写“本次减仓基于[[动量因子失效]]和[[流动性收紧]]”Agent回溯时就能找到具体依据。第二种是因子关联链接。在因子笔记里写“本因子与[[反转因子]]相关性-0.6”形成因子网络。第三种是时间线链接。在月度复盘里链接到当月的所有决策记录形成时间序列。这三种链接在Dataview里可以分别查询。比如找出所有链接到“动量因子失效”的决策记录就能统计这个逻辑被使用过多少次、事后胜率如何。这是纯文本笔记做不到的。4. 核心插件配置与自动化流程4.1 Dataview把知识库变成可查询的数据库Dataview是Obsidian最强大的插件没有之一。它允许你用类似SQL的语法查询笔记的元数据。比如我想找出所有置信度低于0.6且超过30天未回顾的因子笔记TABLE confidence, last_review, file.mtime FROM 03-Factors WHERE confidence 0.6 AND date(today) - date(last_review) dur(30 days) SORT confidence ASC这个查询会生成一个动态表格每次打开笔记都会刷新。我把它放在/03-Factors的索引笔记里每周一早上看一眼就知道哪些逻辑需要重新验证。另一个实用查询是决策记录胜率统计TABLE decision, outcome, date FROM 04-Decisions WHERE outcome ! null SORT date DESC LIMIT 20outcome字段是我在事后复盘时填的值为win、loss或flat。这样就能快速回顾最近20次决策的结果分布。4.2 Templater自动化生成标准笔记Templater插件可以用JavaScript模板自动生成笔记内容。我定义了三个核心模板因子卡片模板、决策记录模板、研报摘录模板。以因子卡片为例新建笔记时自动填入--- title: % tp.file.title % date: % tp.date.now(YYYY-MM-DD) % type: factor tags: [factor/, status/draft] confidence: 0.5 last_review: % tp.date.now(YYYY-MM-DD) % --- ## 因子定义 ## 计算方式 ## 历史表现 ## 适用市场环境 ## 相关因子 ## 失效条件这样每次新建因子笔记结构都是一致的Agent读取时不会因为格式混乱而解析失败。status/draft标签表示待验证验证后手动改为status/verified。4.3 Obsidian Git版本控制与自动备份量化投研的知识库是核心资产必须做版本控制。Obsidian Git插件可以定时自动commit和push到私有仓库。我的配置是每30分钟自动commit一次每天凌晨push一次。这样即使误删笔记也能回滚到任意时间点。提示不要把附件文件夹纳入Git否则仓库会迅速膨胀。在.gitignore里加上99-Attachments/附件用其他方式备份。4.4 与OpenClaw的对接配置OpenClaw读取Obsidian知识库有两种方式直接读文件系统或者通过Obsidian的Local REST API插件。我推荐直接读文件系统因为更稳定、更可控。在OpenClaw的配置文件中指定知识库根目录knowledge_base: type: obsidian root_path: /Users/yourname/KnowledgeBase include_folders: - 02-Notes - 03-Factors - 04-Decisions exclude_folders: - 00-Inbox - 99-Templates - 99-Attachments metadata_fields: - title - type - tags - confidence - related_factorsexclude_folders很重要因为Inbox里的内容未经验证Templates是空模板Attachments是二进制文件这些都不应该进入Agent的检索范围。5. 实操从零跑通一个研报归档到Agent问答的完整链路5.1 第一步研报摘录与结构化假设我读了一份关于“AI算力产业链”的研报在01-Sources里新建笔记用以下模板--- title: 2025-06-10 AI算力产业链深度 date: 2025-06-10 type: source tags: [source/report, industry/ai-compute] source_url: 内部研报编号XXX --- ## 核心结论 - 算力需求未来三年CAGR 45% - 国产替代加速关注[[寒武纪]]、[[海光信息]] ## 关键数据 | 指标 | 2024 | 2025E | 2026E | |------|------|-------|-------| | 市场规模 | 1200亿 | 1800亿 | 2600亿 | | 国产化率 | 15% | 25% | 40% | ## 我的批注 国产化率数据可能偏乐观需要交叉验证。链接到[[国产化率验证]]注意表格的Markdown语法。Obsidian原生支持表格但Agent读取时需要用markdown库解析。表格的列名要稳定不要今天用“市场规模”明天用“市场空间”否则Agent做时间序列对比时会出错。5.2 第二步生成加工笔记与因子卡片基于研报摘录我在02-Notes里写一篇行业分析在03-Factors里新建一个“AI算力需求因子”卡片。因子卡片的关键是可计算。不要写“算力需求增长”要写“算力需求因子 云计算资本开支同比增速 × 0.6 芯片进口额同比增速 × 0.4”。这样Agent在回答相关问题时可以引用具体的计算逻辑。因子卡片的related_factors字段链接到其他相关因子比如“半导体周期因子”、“国产替代因子”。这些链接在Dataview里可以生成因子关系图。5.3 第三步决策记录与事后复盘当基于以上分析做出调仓决策时在04-Decisions里新建记录--- title: 2025-06-15 加仓AI算力板块 date: 2025-06-15 type: decision tags: [decision/buy, sector/ai-compute] related_factors: [[[AI算力需求因子]], [[国产替代因子]]] related_sources: [[[2025-06-10 AI算力产业链深度]]] outcome: null review_date: 2025-09-15 --- ## 决策理由 基于[[AI算力需求因子]]连续三个月上行且[[国产替代因子]]出现拐点信号决定加仓。 ## 仓位变化 - 加仓前5% - 加仓后12% ## 风险点 - 国产化率不及预期 - 海外制裁升级outcome字段先留空到了review_date再填写。我设置了一个Dataview查询自动列出所有到期未复盘的决策TABLE decision, review_date FROM 04-Decisions WHERE outcome null AND date(review_date) date(today)5.4 第四步OpenClaw检索与问答当我在OpenClaw里提问“当前AI算力板块的持仓逻辑是否仍然成立”Agent的执行流程是用关键词“AI算力”和“持仓逻辑”在知识库中做混合检索命中04-Decisions里的决策记录和03-Factors里的因子卡片。提取这些笔记的正文和元数据按相关度排序。把Top 5笔记作为上下文加上用户问题一起发给大模型。大模型生成回答Agent把回答写回05-Agent并自动链接到引用的笔记。写回的回答笔记格式--- title: Agent问答AI算力持仓逻辑验证 date: 2025-06-20 type: agent-output tags: [agent/qa, sector/ai-compute] references: [[[2025-06-15 加仓AI算力板块]], [[AI算力需求因子]]] --- ## 问题 当前AI算力板块的持仓逻辑是否仍然成立 ## 回答 根据知识库中的记录[[AI算力需求因子]]最新读数为0.78仍处于上行区间...这样每次问答都成为知识库的新节点下次检索时会被再次命中形成正反馈。6. 常见问题与排查技巧实录6.1 Agent读不到最新笔记怎么办最常见的原因是文件编码或YAML格式错误。Obsidian默认UTF-8但如果你从Windows复制内容过来可能是GBK编码。用file -I note.md检查编码用iconv转换。YAML错误更隐蔽比如title: 包含:冒号必须加引号否则解析失败。建议在OpenClaw的日志里打开debug模式看它解析每篇笔记时的报错。6.2 Dataview查询结果为空先检查文件夹路径是否正确。Dataview的FROM 03-Factors是相对于知识库根目录的不是绝对路径。然后检查frontmatter字段名是否一致confidence和Confidence在YAML里是两个不同的键。最后检查日期格式Dataview要求YYYY-MM-DD写成2025/06/15会解析失败。6.3 双向链接在Agent检索中失效Obsidian的双向链接语法是[[笔记名]]但Agent读取时拿到的是纯文本。你需要在OpenClaw的预处理阶段用正则提取链接目标然后构建图结构。如果笔记名包含特殊字符如[[动量因子(优化版)]]正则要能处理括号。建议笔记名只用中文、英文、数字和连字符避免括号和空格。6.4 知识库越来越大导致检索变慢当笔记超过5000篇时全量扫描会变慢。解决方案是分层检索先用Dataview或文件修改时间筛选出最近3个月活跃的笔记再在这些笔记里做向量检索。OpenClaw支持配置max_scan_files和recency_weight参数把检索范围控制在合理规模。6.5 常见问题速查表问题现象可能原因排查方法解决方案Agent回答与知识库无关检索未命中或元数据缺失检查OpenClaw日志的检索结果补充frontmatter调整检索权重Dataview表格不刷新插件未启用或语法错误打开Dataview设置看报错修正查询语法重启Obsidian笔记同步冲突多设备同时编辑查看Git冲突标记配置自动commit间隔避免同时编辑YAML解析失败缩进或特殊字符用YAML验证工具检查加引号统一用2空格缩进Agent写回笔记格式乱模板未生效检查Templater配置固定写回模板禁用自由格式实操心得我踩过最大的坑是YAML里的tags字段。Obsidian支持tags: [a, b]和tags: a, b两种写法但Dataview只认第一种。如果你混用查询会静默失败不报错但结果为空。统一用列表格式能省掉很多排查时间。7. 进阶让知识库主动“喂养”Agent7.1 定时任务每日自动生成投研简报我用Python写了一个脚本每天收盘后运行做三件事扫描01-Sources里当天新增的研报摘录提取关键数据查询03-Factors里所有status/verified的因子计算最新读数把结果汇总成一篇Markdown笔记写入05-Agent。OpenClaw第二天早上读取这篇简报就能基于最新数据回答用户问题。脚本的核心逻辑from pathlib import Path import frontmatter from datetime import date kb_root Path(/Users/yourname/KnowledgeBase) today date.today().isoformat() # 收集当天新增素材 new_sources [] for f in (kb_root / 01-Sources).glob(*.md): post frontmatter.load(f) if post.get(date) today: new_sources.append(post) # 收集已验证因子 factors [] for f in (kb_root / 03-Factors).glob(*.md): post frontmatter.load(f) if status/verified in post.get(tags, []): factors.append(post) # 生成简报 brief f# 每日投研简报 {today}\n\n brief f## 新增素材 {len(new_sources)} 篇\n for s in new_sources: brief f- [[{s.get(title)}]]\n brief f\n## 已验证因子 {len(factors)} 个\n for f in factors: brief f- [[{f.get(title)}]] 置信度: {f.get(confidence)}\n (kb_root / 05-Agent / f{today}-简报.md).write_text(brief)这个脚本用frontmatter库解析YAML用pathlib遍历文件不依赖Obsidian运行可以在服务器上定时执行。7.2 因子衰减监控自动标记过期逻辑量化因子有生命周期一个因子失效后如果不及时标记Agent会继续引用过时逻辑。我在因子卡片里加了last_review和decay_rate字段用Dataview查询自动列出需要重新验证的因子TABLE confidence, last_review, decay_rate FROM 03-Factors WHERE date(today) - date(last_review) dur(90 days) SORT decay_rate DESCdecay_rate是我根据历史IC衰减速度估算的值越高表示失效越快。这个查询放在因子索引页每周一早上过一遍手动更新last_review和confidence。7.3 决策复盘自动化让Agent参与事后分析到了review_dateOpenClaw可以自动读取决策记录结合当前市场数据生成复盘报告。比如对于“加仓AI算力板块”的决策Agent会检索相关的因子笔记和后续的研报摘录分析当时的判断哪些被验证、哪些被证伪。复盘报告写回04-Decisions更新outcome字段。这个闭环的价值在于你的每一次决策都成为Agent的学习材料。时间越长Agent对你投资风格的了解越深给出的分析越贴合你的实际框架而不是泛泛而谈。8. 我踩过的坑与最终稳定方案最早我用Obsidian的标签系统做分类打了上百个标签结果标签爆炸根本管不过来。后来改成“文件夹少量核心标签双向链接”的组合文件夹管大类标签管状态status/draft、status/verified链接管关系。这个组合用了半年没有再出现分类混乱。另一个坑是过度依赖Dataview的实时查询。当笔记超过3000篇时每次打开索引页都要等好几秒。后来我把高频查询结果用Templater生成静态表格每天更新一次打开速度从3秒降到0.2秒。低频查询保留Dataview动态生成。最后是关于Agent的“幻觉”问题。OpenClaw在检索不到相关内容时会基于大模型自身知识编造答案。我的解决方案是在Prompt里强制要求如果检索结果为空或相关度低于阈值必须回答“知识库中暂无相关记录”并建议用户补充哪类笔记。这个约束写死在OpenClaw的系统Prompt里不能由用户覆盖。这套方案跑了大半年知识库从200篇笔记涨到4000多篇Agent的问答准确率从最初的60%提升到85%以上。最明显的感受是以前查一个历史决策要翻半天聊天记录和Excel现在直接问Agent3秒出结果还附带引用来源。知识库不再是“死”的存档而是随着每次使用不断生长的活体。