以下是我用 Claude Code 最喜欢做的事情之一（除了让它安静地帮我干正事）：深度研究。而我研究最多的就是创始人。
创始人的故事无处不在，但又无处可寻。
有的藏在播客里，有的躺在 2019 年的 LinkedIn 帖子中，有的埋在一本没人读完的传记里。
要真正理解 Naval Ravikant 或 Tobi Lütke 如何从零到一，你得自己拼凑故事，跨越十几个浏览器标签页。
瓶颈从来不是素材，而是我自己的注意力被分散了。
所以我建了一条流程，让它替我组装信息。一个命令输入，一个连贯的故事输出，最后还带一张可视化时间线。
顺便说一句——如果你是创始人，在下面留下你的名字，我会把你的故事发给你。我保证，比你的维基百科页面精彩。
它到底怎么工作的
工作流很简单：
我说：嘿 Claude，研究一下 Naval Ravikant。
Claude 先确认它指的是哪个 Naval，如果不确定会追问。然后它开始派生出 Agent。
四个 websearch Agent 同时出发，每个负责一个方向：维基、传记、新闻、社交媒体。我发现让它们指向 parallel.ai 的 MCP，效果明显比用内置的 websearch 工具好。每个 Agent 把发现写到 files/{founder}/source\_research 里。
完整工作流：https://younesaeo.com/research
四个 分析 Agent 接手这些发现，相互交叉验证引用，每个负责一个生活维度：财务状况、个人成长、职业生涯。它们写进 files/{founder}/analysis。
一个 上下文增强 Agent 读取分析结果，把历史、文化、经济背景叠加到重要事件上——比如 2008 年的融资回合会放在 2008 年的背景下解读。输出到 files/{founder}/enhancement。
一个 整合 Agent 把一切按时间线梳理，按人生阶段聚类，这样下一个 Agent 的工作就更轻松了。
完整工作流：https://younesaeo.com/research
一个 可视化规划 Agent 读取整合后的时间线，按人生阶段拆分，然后写一份规划，说明如何编排图像生成。Claude 根据规划书派生出所需的 图像生成 Agent（通常 2 到 6 帧），每个 Agent 分配各自的事件列表。
Claude 本身不能生成图像，所以我写了一个小的 图像生成技能，它在底层调用 AI SDK，你可以选任意模型。Gemini 和 GPT 的图像效果最好。如果你想完全跳过这个技能和配套框架，可以直接指向 Higgsfield MCP。
图像生成完毕，时间线也建好了。最后一步：一份执行摘要报告，把所有信息整合成一个合理、可读的创始人故事，并配以时间线插图。
完整工作流：https://younesaeo.com/research
三个原语，任意载体
把这条流程剥开，核心只有三样东西：子 Agent、MCP 和技能。这就是一个深度研究 Agent 的全部工具包。而且因为这三样都是通用标准，所以完全不绑定 Claude Code。同样的工作流可以在 Codex、OpenClaw、Hermes、Cursor 上运行，或者下个月流行什么 Agent 都可以。
为什么用子 Agent，而不是技能
我的流程里包含十四个子 Agent。它们承担了几乎所有的重活。
这看起来可能是个奇怪的选择，因为理论上你可以用过去半年最热门的词——技能——来运行完全相同的工作流。我不这么做，有两个原因。
第一个是 上下文泛滥：
当 Claude 激活一个技能时，该技能生成的所有 token 都会保留在 Claude 的上下文中，直到会话结束。
窗口越来越大，上下文膨胀的模型会变笨，丢失原始任务的线索，并开始留下未完成的工作。
而子 Agent 有自己的独立上下文，永远不会泄露回去。技能不是一个免费的帮手，而是你为它发出的每个 token 付出的上下文税。
正是这一点，让主 Agent 保持编排者的角色，而不是研究者：它能够跟踪整个流程，交出最终输出，而不会让自身窗口腐烂。
第二个原因是 并行能力：
整个流程中有大段完全并行的操作（网页搜索、分析、图像生成）。技能不能并行运行。子 Agent 可以。
给正确的 Agent 选对模型
隔离上下文只是子 Agent 带来的一半好处。
另一半是：每个子 Agent 都是一个机会，让你选择能完成任务的最便宜模型。所以我按任务匹配模型。
网页搜索 Agent 跑在 Haiku 上。
它又快又便宜，而且因为它处理的是搜索返回的事实数据，所以几乎不会产生幻觉——这通常是小模型单独推理时的风险。
基于搜索结果，Haiku 完全够用。
分析和整合 Agent 跑在 Sonnet 上。它的推理能力接近 Opus，但速度快到可以同时派出七个，而不会让流程变得缓慢——如果跑在 Opus 上就会那样。
最终报告跑在 Opus 上。它是三者中最出色的创意写手，而报告的唯一任务就是读起来像是一个关于创始人的好故事，而不是数据转储。这是唯一一个我愿意为最慢、最聪明的模型买单的地方。
梦境是下一层
我刚才描述的工作流是静态的。子 Agent 不会学习，技能也不会进化。
如果你在可视化规划 Agent 里埋了一个 bug，它会在之后的每次运行中默默地存在，直到你恰好自己发现它。
Anthropic 的托管 Agent 有一个叫做梦境的功能。
大致思路是：让一个 Agent 读取过去几轮会话记录，找出反复出现的失败模式，并提出修复方案。
你可以在原始端运行同样的循环。这是一种元技能：
- 读取你最近 n 次运行的会话记录。
- 按子 Agent 归属对失败进行聚类。
- 分析失败原因：是提示词、工具列表，还是模型选择的问题。
- 针对有问题的 markdown 文件，提出具体的修改建议。
尚未完善的部分
最后一步目前还只是个想法。上述流程中的其他环节都已经过 120 次运行验证。
Dreaming 有一个工作坊和一个文档页面。
我接下来几天会进行实验，大概率会在另一篇文章里分享发现。
---
我把整个流程放到了一个 GitHub 仓库里。你可以 fork 它，完整跑一遍某个创始人的研究，或者改成你自己的，针对任何你感兴趣的话题创建专属研究流程。
希望这些对你有帮助，有问题随时问我。