Obsidian+OpenClaw：构建量化投研的AI第二大脑

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或Logseq

Notion的问题在于数据在云端，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 20

outcome字段是我在事后复盘时填的，值为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_factors

exclude_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的执行流程是：

1. 用关键词“AI算力”和“持仓逻辑”在知识库中做混合检索，命中04-Decisions里的决策记录和03-Factors里的因子卡片。
2. 提取这些笔记的正文和元数据，按相关度排序。
3. 把Top 5笔记作为上下文，加上用户问题，一起发给大模型。
4. 大模型生成回答，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 常见问题速查表

实操心得：我踩过最大的坑是YAML里的tags字段。Obsidian支持tags: [a, b]和tags: a, b两种写法，但Dataview只认第一种。如果你混用，查询会静默失败，不报错但结果为空。统一用列表格式，能省掉很多排查时间。

7. 进阶：让知识库主动“喂养”Agent

7.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 DESC

decay_rate是我根据历史IC衰减速度估算的，值越高表示失效越快。这个查询放在因子索引页，每周一早上过一遍，手动更新last_review和confidence。

7.3 决策复盘自动化：让Agent参与事后分析

到了review_date，OpenClaw可以自动读取决策记录，结合当前市场数据，生成复盘报告。比如对于“加仓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，现在直接问Agent，3秒出结果，还附带引用来源。知识库不再是“死”的存档，而是随着每次使用不断生长的活体。