个人知识库的规模与核心痛点
Paul Iusztin 花费了18个月时间，将其“第二大脑”转化为活的研究记忆库。目前，他在 Obsidian 中拥有超过 5,000 条笔记，在 Readwise 中另有 5,000 条笔记，此外还有分散在 Notion 和 Google Drive 中的内容。这个知识库每周以 250 个文件的速度增长，每月新增约 1,000 个文件。尽管体量庞大，Paul 面临的核心问题是研究资料的流失与检索困难。他的阅读列表往往成为“坟墓”，保存了大量社交媒体帖子、文章、视频和代码库，但在开始新项目时，他难以回忆起这些高信号笔记，或者需要花费大量时间才能找到可用的内容。
"I spent 18 months turning my second brain into my living research memory."
另一个关键痛点是系统缺乏个人锚点。Paul 希望研究系统能根植于他的个人笔记、价值观和信仰中，从而反映他个人的思考方式。现有的通用工具如 Codex Cloud 或 Notebook LM 虽然强大，但缺乏这种个性化连接。因此，他需要构建一个介于通用 AI 工具和个人第二大脑之间的中间系统，即所谓的“AI 研究操作系统”。
工具选择的决策框架
Louis-François Bouchard 指出，并非所有查询都需要复杂的 AI 研究系统。对于只需快速获取答案或简单搜索的问题，直接使用 Google 或 ChatGPT 等通用工具即可。然而，当问题变得复杂，需要处理长上下文、大量信息或进行后续追问时，依赖单一的大模型架构存在局限性。这不仅导致效率低下，还意味着用户完全受制于 OpenAI 等公司的架构设计。
对于需要深入挖掘、优化效率或构建可复用功能的项目，简单的 AI 代理（Agent）往往不够用。Paul 举例说明，他在制作新视频时，希望系统能理解他之前的视频内容，避免重复，并能引用其他相关内容。这种对长期记忆和上下文连贯性的需求，使得简单的对话式 AI 无法满足要求。因此，决策的关键在于区分任务的复杂度和对可复用性的要求。
现有工具的局限性分析
尽管 NotebookLM 等工具在消化内容和研究方面表现出色，但它们存在显著的缺陷。首先，用户不拥有这些数据，无法进行深度个性化定制。其次，这些工具通常不是为 Agent 原生设计的，难以与其他自动化流程集成。最后，对于需要编程或技术实现的任务，基于浏览器的工具显得力不从心。
"The main problem is that you don't own it. You cannot do anything you want with it. You cannot personalize as much as possible."
对于生产环境，虽然构建基于向量数据库的 RAG（检索增强生成） 管道是标准做法，但这需要复杂的基础设施，且对日常使用而言不够友好。手动检查、编辑和审查向量数据库中的笔记非常困难，缺乏直观性。因此，对于个人日常使用，Paul 和 Louis 认为需要一种更灵活、更易于手动干预且能与个人笔记深度集成的解决方案，而不是仅仅追求规模化生产的专业产品。
项目目标与协作背景
Paul Iusztin 是 Decoding AI 的创始人兼 CEO，专注于 AI 产品开发的课程和内容创作，同时也是畅销书《LM Engineers Handbook》的合著者。Louis-François Bouchard 则是 Towards AI 的联合创始人兼 CTO，也是 YouTube 频道 What's AI 的创作者，专注于 AI 工程技术和生产环境下的 AI 系统构建，著有《Building AI systems for production》。两人均拥有丰富的研究背景，Louis 曾拥有 AI 领域的博士学位。
他们的共同目标是通过构建一个可适应个人需求的工具，更好地利用现有的知识储备。这个系统不仅服务于他们个人的研究需求，还旨在为观众提供代码和实现方案，以便其他人也能根据自己的需求进行调整。通过结合 Paul 的内容创作视角和 Louis 的 AI 工程视角，他们致力于解决知识留存与高效检索之间的矛盾，打造一个真正属于个人的 AI 研究操作系统。
"The core goal of the repository that we built and on this project is that we want you to adapt it for your needs."
痛点：现有AI工具的上下文管理瓶颈
在构建个性化研究助手时，核心挑战并非缺乏数据，而是如何高效复用历史上下文。许多用户希望建立一个随时间累积、易于检查且可使用的个人维基百科，其中包含海量的来源、文档、视频和最新研究。然而，当前主流工具如 Cloud Code 或 ChatGPT 存在显著缺陷：用户在新一轮对话中必须重新粘贴所有链接、PDF 和信息，或者依赖难以维护的“技能（Skills）”模块。
"The bottleneck is how can you leverage it in the future? ... when you stop the conversation, it loses everything."
这种上下文窗口（Context Window）的局限性导致每次对话都从零开始，所有脚本、运行记录和结构化的知识在会话结束后即被遗忘。对于拥有大量历史内容的创作者而言，这种非持久化的记忆机制使得利用多年积累的内容变得极其低效，无法形成复利效应。
解决方案：构建本地化的个人研究操作系统
为了解决上述问题，团队决定构建一个基于纯文本文件（主要是 Markdown）的个人研究操作系统（AI Research OS）。该系统不依赖云端黑盒，而是将数据存储在本地文件系统中，确保数据的可访问性与持久性。作者将原本分散在多个平台的内容——包括 Granola 中的会议记录、Apple Notes 中的笔记、Chrome 保存的推文以及数百个视频素材——统一迁移至 Obsidian。
"I moved everything automatically into Obsidian... saved locally in my file system, which means that's basically my companion for researching and building everything I build now."
这一举措不仅实现了单一事实来源（Single Source of Truth），还通过 Codex 自动化配置，使得本地笔记能够被 AI 代理轻松读取和利用。该系统支持连接 GitHub 仓库、YouTube 视频链接、Readwise 和 Notebook LM 等多种数据源，形成了一个高度集成且可扩展的研究基础设施。
系统演进：三层架构的迭代逻辑
该研究系统的开发经历了从简单到复杂的三层架构演进，每一层的增加都是为了解决特定场景下的深度研究需求。
-
第一层（基础版）：最初仅用于生成课程教案。输入为“主题”和一组手动挑选的“黄金链接（Golden Links）”，输出为静态的研究 Markdown 文件。架构上，首先抓取黄金链接作为上下文种子，然后使用经典的深度研究算法（Deep Research Algorithm）。该算法包含一个主代理（Orchestrator）和多个子代理。主代理根据初始主题生成查询，子代理使用 Gemini 模型在 Google 上搜索资源并生成执行摘要，最后主代理聚合所有信息，避免上下文爆炸。
-
第二层与第三层（进阶版）：随着需求增加，系统引入了更复杂的索引机制和类似 Wiki 的综合版本，以处理更庞大的知识库。虽然本片段未详述后两层的完整技术细节，但明确指出 Paul 将在后续部分深入讲解原始内容、索引和综合笔记之间的转换逻辑。
"Paul will dive into all this three-layer system that we built with the raw content, the index... and the wiki-like synthesized version of all your notes."
这种迭代策略确保了系统既能处理简单的即时查询，也能应对需要多轮推理和深度聚合的复杂研究任务，同时保持了代码的可移植性和可定制性，用户可通过简单的提示词让 Codex 快速扩展新功能（如 YouTube 字幕解析）。
从公开网络到第二大脑：深度研究循环的演进
早期的课程生成系统虽然能快速产出内容，但存在明显的局限性。系统最初仅针对公开网络进行深度研究，这导致结果过于通用，且需要人工筛选所谓的“黄金链接”以去除噪音。为了解决这一问题，团队引入了排名算法，通过比较每个来源与用户初始主题的相关性，仅抓取排名最高的 K 个元素进行全文爬取，其余链接仅保留摘要，最终编译为单一的 Markdown 研究文件。尽管这种方法在短时间内生成了 35 节课程，但为了追求更高质量和个性化的内容，系统必须升级。
"So that's why we also applied a ranking algorithm where we wanted to like find the information with the highest signal."
升级的核心在于将深度研究循环的目标从公开网络转向用户的第二大脑（Second Brain）。第二大脑是指用户通过 Obsidian、Readwise 等工具有机整理和过滤的个人知识库。通过将研究算法指向这些经过人工筛选的高质量源，系统能够自动聚合那些“黄金链接”，从而摆脱对人工查找的依赖。这一策略的转变使得用户只需输入一个主题，系统即可自动发现并整合所需的所有信息，实现了从通用搜索到个性化知识挖掘的跨越。
混合源检索与静态文件的痛点
新的算法架构在输入端仅保留主题作为种子，但在检索端进行了重大扩展。系统不再局限于公开网络，而是将查询同时指向第二大脑（如 Obsidian、NotebookLM、GitHub、Google Drive、Notion 等）以及公开网络。这种混合检索策略确保了研究结果既具备广度，又拥有深度和个人相关性。经过排名、全文爬取和摘要生成后，所有信息被编译为研究 Markdown 文件。然而，这种静态文件结构带来了新的操作瓶颈。
"This research MD file is static. It's a pile of static data. And usually research is not static, right?"
研究过程本质上是动态的，用户往往在生成文件后意识到需要追问新问题，或者发现部分信息已过时。由于之前的操作涉及大量的 Token 消耗和时间成本，从头开始运行整个深度研究循环是不现实的。为了解决这一不可逆性和高成本问题，系统需要引入一个更灵活的层级，即“Wiki 层”，以替代单一的静态文件输出，从而实现知识的持续迭代和高效查询。
基于文件的轻量级 Wiki 架构设计
V3 版本系统引入了LM 知识库（即 Wiki 层），其核心设计理念是摒弃复杂的向量数据库、知识图谱或语义搜索基础设施。作者认为，对于个人研究操作系统而言，这些技术增加了不必要的复杂性。相反，新系统完全基于文件和引用构建，利用操作系统原生的文件管理机制，确保系统的轻量级和可维护性。输入源可以是 Obsidian、NotebookLM、YouTube 或自定义 URL（通过 Bright Data 等工具解析单页应用），输出则是结构化的 Wiki 页面。
系统架构分为三个主要部分：raw 文件夹、wiki 文件夹和 index 索引。raw 文件夹存储不可变的原始数据，确保源数据的完整性；wiki 文件夹包含由 LLM 生成的衍生内容，如概念对比、笔记或待解决的问题；而 index 则作为整个系统的入口点。这种设计避免了数据库的依赖，转而使用简单的基于引用的索引机制，使得系统更加透明且易于调试。
索引机制与 Agent 推理逻辑
系统的核心驱动是一个读取 index.yaml 文件的 Agent。该文件充当数据的目录，包含所有源文件的链接、摘要、元数据（如来源、标题、作者、发布日期）以及衍生出的 Wiki 页面数量。例如，一个典型的 index.yaml 可能包含 10 个源文件和 38 个衍生的 Wiki 页面。Agent 通过读取这个索引，理解数据的结构和关系，从而推理如何查找和处理数据。
"The index.yaml file is an entry point for our agent... It's an index, ultimately."
这种基于文件的索引不仅记录了源数据，还记录了 Wiki 页面与源数据之间的关联。随着 Wiki 的增长，系统能够通过这个简单的索引结构维护复杂的知识图谱。虽然目前只是第一版迭代，但这种去中心化的文件管理方式证明了其在个人知识管理中的潜力。它允许用户在不依赖复杂后端服务的情况下，实现高效的知识检索和内容生成，真正实现了“第二大脑”与 AI 研究工具的无缝集成。
动态知识图谱的可视化与结构化连接
该系统的核心在于将非结构化数据转化为可视化的实体与概念连接。通过提取诸如“工具注册表”、“上下文压缩”、“沙箱技术”等概念，以及“开源代码”、“闭源代码”、“MCP”等实体，系统能够在视觉上清晰地呈现知识间的关联。这种结构化的方式不仅便于人类理解，更为后续的自动化查询奠定了坚实基础。系统并非静态存储，而是通过层级化的索引机制来优化信息检索效率。
"You can beautifully and practically create connections."
为了实现高效的查询，系统引入了 index.yaml 文件作为入口，其中包含每个来源的摘要和元数据。当智能体（Agent）接收到查询请求时，它首先查阅这些源维基页面（Source Wiki Pages），这相当于每个条目的扩展执行摘要。如果所需信息在此层级已足够，智能体将直接返回结果，从而极大地节省 Token 消耗。只有在摘要中未找到关键信息时，系统才会进一步深入，链接到衍生内容如概念文件、实体笔记、对比分析等，最终才读取完整的原始来源（如整篇文章、论文或视频）。这种纯引用与层级构建的策略，确保了系统在处理海量数据时的Token 效率。
知识库的自我进化与第二大脑架构
该维基系统最显著的特征是其动态生命力。它不仅仅是一个被动的数据仓库，而是随着用户的交互不断自我进化。每一次提问都会在知识库中留下痕迹，LLM 会根据问题自动生成新的概念文件、笔记文件或对比文件。所有交互都会被记录在日志中，使得知识库能够真实反映用户的理解过程、知识盲区及历史疑问。
"The wiki doesn't evolve only when you ingest new data... it actually evolves as you start talking with it."
在架构设计上，该维基系统并不直接覆盖用户的整个“第二大脑”。作者采用 Tiago Forte 提出的 PARA 方法（Projects, Areas, Resources, Archives）来组织数据。所有的笔记、资源和来源被直接导入 PARA 结构中的“资源（Resources）”层级，保持为扁平列表。当需要使用时，再通过项目（Projects）和领域（Areas）进行引用。这种设计确保了 Obsidian 中的原始数据作为不可变的快照，LLM 不会直接修改这些个人笔记。当启动新项目时，系统通过深度研究算法将全局第二大脑的范围缩小至当前项目，实现从研究到工作的转化。
自动化研究工作流与技能调用演示
为了将理论转化为实践，作者展示了基于 AI Research OS Workshop 仓库的演示环境。该系统被打包为 Cloud Code 插件，并依赖于 Obsidian、Readwise 和 Notebook Elements 等工具。虽然安装涉及特定的 CLI 和认证配置，但其核心价值在于技能（Skills）的模块化调用。
在演示案例中，作者针对“代理 AI 工程（Agentic AI Engineering）”主题，准备了包含已知知识点和特定参考文件的数据转储（Data Dump）。通过打开 Cloud 会话并调用“研究技能（Research Skill）”，系统自动解析文件意图，并在启动深度研究前抓取这些信息作为上下文，以优化后续提问。系统提供了三种深度模式：Light（轻量）、Deep（深度）和 Fast（快速）。这些模式主要控制每轮的查询数量及总轮次，直接影响 Token 消耗。
| 模式 | 轮次设置 | 每轮查询数 | 适用场景 | Token 消耗预估 | 处理时间 | 作者选择 | 实际执行 | 备注 |
|---|---|---|---|---|---|---|---|---|
| Light | 1 轮 | 3 次查询 | 常规快速检索 | 中等 | 10-20 分钟 | 轻量模式 | 1 轮 3 次查询 | 平衡效率与深度 |
| Fast | 2 轮 | 3 次查询 | 极速响应 | 较高 | 较短 | - | - | 适合简单场景 |
| Deep | 多轮 | 多查询 | 海量笔记深度挖掘 | 极高 | 较长 | - | - | 仅在必要时使用 |
在演示中，作者选择了Light 模式以加速流程。系统随后进入自动模式，经过约 10 到 20 分钟的处理，完成了对选定主题的深度推理与信息整合。这一过程展示了如何将复杂的手动研究转化为自动化工作流，通过预设技能实现从数据摄入到知识生成的无缝衔接。
自动化Wiki构建与结构化知识提取
演示者展示了如何利用LLM将分散的笔记工具（如Obsidian、Readwise、Notebook LM）中的数据转化为结构化的Wiki。系统摄入原始文件后，自动生成包含原始文件副本、索引（指向Wiki的引用）以及子图（Subgraph）的结构。子图能直观展示知识关联，完全基于摄入文件生成。Wiki内部进一步细分为比较、概念、实体和来源四大对象。其中，“来源”部分仅保留执行摘要，这些摘要在摄入阶段计算一次，后续LLM无需反复阅读原始长文，从而优化了处理效率。
"The sources contain the executive summary of our raw sources... it needs just the executive summaries, which are computed just one time during the ingestion."
系统具备自动比较能力，能根据内容自动识别并对比相关主题，例如“Adjective RAG vs 文件系统”或“Compaction vs 递归语言模型”。更核心的是概念提取功能，它能从海量资源中自动提炼出理解主题所需的关键概念。例如，在“Agent Loop”主题下，系统自动生成包含图表、标签和详细解释的摘要，用户可对所有提取的概念和实体进行类似探索，实现知识的深度结构化。
代码仓库架构分析与对比学习
第二个案例聚焦于Harness Engineering（Harness工程），演示者选择三个开源仓库（Open Code、Pi、Hermes）进行深度摄入。此过程无需深度研究，只需指定探索主题，如通用架构、智能体架构、子智能体、记忆系统及智能体权限流。系统自动克隆这些仓库，并在每个仓库层面生成详细笔记，随后在Wiki衍生层创建高级笔记，对比各仓库架构或汇总整体趋势。
"I just want to ingest those repositories and explore topics such as the general architecture, agents architecture, sub agents, memory system, and the agent permission flow."
生成的Wiki同样包含原始文件、索引和Wiki本体。在仓库内部，系统针对特定主题（如权限流、记忆系统）生成详细解释文件。最具价值的是架构对比功能，它能清晰展示不同Harness之间的架构差异，并提取出关键的架构决策。这种直接从代码层面进行对比学习的方式，对于希望理解底层逻辑或自行开发Harness的用户极具实用价值，实现了从代码到结构化知识的自动化转化。
轻量级链接摄入与交互式知识迭代
第三个案例展示了最简化的工作流：仅摄入三个随机自定义链接。该流程不依赖Obsidian、Readwise等复杂设置，仅需安装插件，通过Git和curl获取URL即可运行。生成的Wiki包含索引、来源（每个来源一个执行摘要）、提取的概念和实体。这种轻量级模式证明了系统的通用性，即使在没有外部工具链支持的情况下，也能快速构建知识图谱。
"You can just install this plugin and run this examples because it here is not dependent on any other service than Git and using curl to get this URLs."
知识构建完成后，进入交互式问答阶段。用户可基于已生成的Wiki提问，例如“远程沙箱如何工作并集成到核心中”。系统查询Wiki并生成答案，同时根据问答过程动态更新Wiki，创建新笔记、比较或提取新实体。这种机制使得知识库不再是静态存储，而是随着用户探索不断演进的活体系统，实现了从被动阅读到主动知识构建的闭环。
项目现状、局限性与未来方向
项目目前仍处于早期构建阶段，部分功能尚显粗糙。主要局限性包括：缺乏Google Drive、Notion、Slack等常用平台的连接器；难以评估来源的时效性或强弱；且目前仅通过Cloud Code和Codex在终端中操作，缺乏友好的UI/UX。然而，这些并非当前优先事项。
"The core of this project is to be useful for us and for you to take over and add whatever you need."
开发者的核心目标是教学，即展示记忆和上下文管理的方法论，而非提供完美的商业产品。因此，额外功能被视为次要，重点在于提供一个可被用户接管并扩展的基础框架。项目鼓励用户根据自身需求添加连接器或改进评估机制，强调其作为开发者工作流工具的定位，旨在通过开源协作推动智能体记忆管理技术的发展。
系统设计的核心目标与短期优化路线图
在深入探讨技术细节之前，必须明确该项目的设计初衷并非构建商业级产品，而是专注于AI 工程（AI Engineering）的教学与最佳实践传授。尽管当前版本已具备演示价值，但开发团队已规划了明确的短期改进路径，旨在解决当前架构中的痛点。其中，内存压缩（Memory Compaction）被视为一个重大且复杂的挑战，因为正确管理内存状态在技术上极具难度，且该领域的最先进状态（State of the Art）仍在持续演进中。此外，团队还计划引入更严格的代码 linting（静态检查）机制，以提升代码质量和系统稳定性。这些优化措施将直接集成到未来的迭代版本中，确保系统在工程实践上的严谨性。
"Our goal is to teach AI engineering. It's not to build the next best product."
增强数据溯源与用户信任机制
为了提升系统的可信度与实用性，源数据溯源（Source Provenance）是下一阶段优化的核心重点。当前系统需要解决如何信任数据来源并对其进行有效排序（Ranking）的问题。通过增强溯源能力，系统能够更合理地复用（Reuse）历史数据，并在用户需要时提供快速访问。更重要的是，这一改进将赋予用户直接判断源数据相关性的能力，从而提升人机交互的效率与透明度。这些功能不仅涉及技术层面的优化，更关乎用户体验（UX）与数据可解释性，是构建可靠 AI 助手的关键环节。虽然这些改进主要面向未来优化，但它们构成了系统从"演示"走向"可用"的重要基石。
Towards AI Academy 与 Agent Engineering 课程
上述所有技术成果与优化思路，并未止步于演示仓库，而是被整合进了 Towards AI Academy 推出的 Agent Engineering（智能体工程） 课程中。该课程旨在通过构建一个类似的深度研究系统（Deep Research System），让学员亲手打造包含写作与调研智能体的复杂架构。课程假设完成时间约为 60 小时，最终项目要求学员构建一个多智能体系统（Multi-Agent System），以实践前文所述的最佳工程实践。对于对构建智能体系统感兴趣的开发者，该课程提供了从理论到实战的完整路径，帮助学习者掌握智能体协作与复杂系统构建的核心技能。
"We created a course called Agent Engineering where we build a similar deep research system... It's a very in-depth course where I assume it takes around 60 hours to complete."
课程资源与学习建议
对于希望深入掌握 AI 工程最佳实践的读者，建议通过 Towards AI Academy 获取相关课程资源。特别是 Agent Engineering 课程，它不仅涵盖了前文提到的多智能体系统构建，还深入探讨了智能体协作模式与工程化部署细节。通过完成该课程的最终项目，学习者将能够复现并优化类似深度研究系统的架构，从而在实际应用中提升对AI 智能体的理解与控制能力。该课程适合希望从"使用 AI"转向"构建 AI 系统"的工程师，提供了一套系统化、项目驱动的学习方案。
"If this presentation and the demo repo that you saw was interesting, please consider checking out the Towards AI Academy with our courses on there including the Agent Engineering course to learn more on the best practices when building around and with agents."