# WorkBuddy万字保姆教程｜用好「深度研究」永不加班～
**作者**: 智见AI-大鹏
**日期**: 2026-07-09T12:55:46.000Z
**来源**: [https://x.com/zjp1997720/status/2075202251887718619](https://x.com/zjp1997720/status/2075202251887718619)
---
最近在和电子工业出版社合作录那个 WorkBuddy 实战课，这是第三节课的文档版内容，我继续免费分享出来。上一篇讲的是 WorkBuddy 界面和功能区，反响非常好，这篇接着往深了走——聊 Deep Research。
之前两篇WorkBuddy的深度实战长文都爆了，这一篇再次预定一下爆款
https://x.com/zjp1997720/status/2067946720009584880?s=20
https://x.com/zjp1997720/status/2074418155406111072?s=20
先给个我的判断：Deep Research 是我日常用得最多的一个功能。写公众号文章、准备一场培训、设计一个 skill，我几乎都是先调研起手。原因很简单，调研能帮我补信息面的缺口。但更关键的是，调研的结果大部分是喂给 Agent 的——让它在接下来的任务里有更多上下文。所以调研这事，只有很少一部分是给我自己看的，大部分是给 Agent 准备弹药。
这篇我拆一下 WorkBuddy 官方到底是怎么设计 Deep Research 的，以及基于这些设计，你怎么把它用对。
相信我，这篇搞懂了，你对Agent的认知会有个质的飞跃～
## Deep Research 到底是什么
上一篇里我提到过一句：深度研究既不是单一 Skill，也不是 MCP，更不是一段 Prompt。这个说法方向没错，但不够精确。这次我重新拆了一遍，给你一个更准的理解。
Deep Research 本质上是一个 rule 驱动的主从代理系统——rule 当大脑定流程，subagent 当手脚做检索，skill 当专用工具补中文信息源，plugin 把这三样打包成一个能分发的容器。Hook 全程不参与。
这句话信息量挺大，我一个一个拆。它其实是四种机制拼在一起的，每种干一件事：
Plugin，只管"装什么"。 它就是个清单，告诉 WorkBuddy 这里面有哪些 agent、哪些 skill、哪些文件。本身不含任何逻辑。你理解成一个快递箱，箱子上贴着标签写里面装了啥，但箱子自己不干活。
Rule，管"怎么想"。 这是整个系统的大脑。Deep Research 的 rule 是默认激活的，只要这个插件在跑，这套研究方法论就会自动注入到主 Agent 里。它规定了这些事：拿到调研问题先拆成子问题、给每个子问题分配检索方向、subagent 必须带来源引用、什么时候算调研完成。Rule 自己不干活，只做编排和决策。
Subagent，管"怎么干"。 这是执行层。主 Agent 根据研究计划，把子任务分给好几个 subagent 并行跑。Subagent 有三个特点：并行——好几个同时跑各查各的；轻量——每个只管一个子问题，上下文窄不会跑偏；有预算上限——工具调用次数有限，防止它失控空转。干完之后每个 subagent 返回一份带来源的检索报告，主 Agent 再汇总、去重、整理。
Skill，管"用什么干"。 它是专用工具。Deep Research 里内置了一个专门搜微信公众号文章的 skill。为什么要这个？因为通用搜索像 Google、Bing，在中文高质量信息源上有盲区。微信公众号是中文互联网里最大的高质量内容池之一，但通用搜索引擎根本搜不到。所以官方专门做了个 skill 来补这个缺口。
## 为什么这套东西不跑飞
你可能会想，让一个大模型自由研究，这事不是很容易跑偏吗。要么上下文被一堆搜索结果塞满，要么一直转圈查不完，要么中途忘了自己本来要干嘛。
这套设计之所以成立，核心是有三道边界兜着。
第一道，主 Agent 和 subagent 职责硬隔离。 主 Agent 只编排和决策，不直接检索；subagent 只检索和报告，不做最终决策。为什么要硬隔离？因为如果主 Agent 既编排又自己搜，它的上下文窗口会被一堆原始搜索结果塞满，后面做决策的质量就下来了。硬隔离保证主 Agent 的上下文始终干净，它只看 subagent 返回的精炼报告。
第二道，subagent 有工具调用预算。 每个子代理能调用多少次搜索工具，是有上限的。到了上限强制返回，不管查没查完。这防两种情况：一是它在一条路上无限深挖浪费资源，二是它陷入死循环——搜不到换个词再搜，搜到了继续顺着链接往下翻。预算强制它在有限步内收口。
第三道，研究计划落盘。 主 Agent 开检索之前，会先把研究计划写成一个 Markdown 文件，存到工作目录里。计划里有拆出来的子问题、每个子问题往哪查、subagent 怎么分派、什么时候算完。为什么要存成文件？因为长任务里上下文窗口会被压缩。如果计划只存在于对话里，压完之后主 Agent 可能就忘了自己本来要干嘛。存成文件，哪怕上下文被压缩，它也能重新读回来，恢复完整记忆。
但这里有个必须讲清楚的认知差。
很多人一听"研究计划落盘"，就以为 Agent 会先把计划拿给你看、等你点头了再开干。不是这么回事。 这个落盘文件是主 Agent 自己的"北极星"，是它怕自己失忆给自己留的备忘录，不是给你确认的。Rule 原文写得很直接：这个计划会在整个研究过程中当你的北极星。
Rule 里唯一涉及"先跟你确认"的，是开头那个澄清问题机制——如果问题有歧义，Agent 会问你最多 3 个澄清问题，问完就开干。但这跟"把完整研究计划摊给你确认"完全是两码事。问题够清晰的话，它直接进研究阶段，不停下来给你看计划。
这意味着什么？如果你想先看研究计划、确认方向再让它执行，你得自己补这一步。 怎么补，下面讲。
## 怎么写好一个调研提示词
讲了这么多架构，回到最实际的问题。你打开 WorkBuddy，选了深度研究，面对一个空输入框——你该写什么？
这里要补一个派活的方法。给 Agent 派活，核心是讲清楚三件事：现状（你现在什么情况）、目标（你要什么）、过程（怎么做）。行话叫 SGP——State、Goal、Process。
普通任务里这三个都重要，但在 Deep Research 场景下，权重不一样了：
为什么 P 可以弱化？因为 Deep Research 的 Rule 已经把过程接管了。拆问题、分 subagent、设收敛条件、汇总报告，这些都是 Rule 在干。你不需要教它"先做什么后做什么"，Rule 自己有数。
你真正要花力气的是 S 和 G——把问题的边界和验收标准定清楚。
下面用五个技巧串一遍。案例就用最近很火的 Loop Engineering，我拿它实际跑了一次调研。
技巧一，问题边界要窄，别给一汪洋大海。
Deep Research 的 Rule 会自动拆问题，但拆得好不好，取决于你原始问题清不清楚。差的写法："帮我调研一下最近火爆的 Loop Engineering"——太宽了。Loop Engineering 到底是哪个层面？技术框架？工程理念？最佳实践？Agent 没判断依据，subagent 就会漫游，预算全耗在低价值方向。好的写法："帮我调研 Loop Engineering 的起源、定义、核心原理、最佳实践，以及有哪些可以直接学的开源项目"——有边界，拆出来的子问题就精准，一个查起源定义，一个查实践，一个查开源项目。
技巧二，说明调研用途和给谁看。
同一个主题，"为我自己做决策"、"为写公众号"、"为给老板汇报"，调研角度完全不一样。不说清楚，Agent 只能猜，猜偏了预算就白花。我这个案例里，用途是"产出一份面向 AI 小白的白皮书"。这句话很关键，它告诉 Agent 结果不能堆术语，要通俗，要有实践路径，因为最终读者是小白。
技巧三，把已知信息做减法。
这是大多数人会忽略的。subagent 有预算，如果它把预算花在查你已经知道的东西上，真正该深挖的方向就没预算了。我这个案例里，本地已经有一些 Loop Engineering 的素材，我就直接告诉它："本地已有相关素材，可以先利用起来，这些不用重新查。"这样它会先读本地的，把预算省下来去查外部还没有的信息。
技巧四，要对比或评估，就给维度。
竞品分析、方案对比这种调研，你不给维度，Agent 就用自己的默认维度去比，可能根本不是你关心的。给维度就是给验收标准。我案例里涉及"有哪些可以学的开源项目"，那就给维度——"从文档质量、学习曲线、社区活跃度、实际落地案例几个维度评估"。这样返回的不是一串项目名，而是带评估的结构化清单。
技巧五，也是最重要的——要求先出研究计划，确认后再执行。
这是我们拆完 Rule 之后发现的一个认知差。很多人以为选了深度研究，Agent 会自动先出一份计划给你确认。前面讲过了，不是的。Rule 里没有这个机制，落盘的计划是它自己的北极星。所以这一步你要自己补。
两种方式。第一种，直接在提示词里写明："正式开始调研前，请先向我展示你的研究计划，等我确认后再执行。"第二种，依赖 WorkBuddy 的自动判断——现在的版本 Plan 模式不再是一个固定按钮了，它会根据任务复杂度自己判断要不要先进规划状态，或者你提示词里明确说"先计划再执行"，它也会进。不管哪种方式，效果一样，都是补上"方向对齐"这一步。我建议直接在提示词里写明，最稳。
把五个技巧合一起，我的 Loop Engineering 调研提示词长这样：
```
S / 现状：
我准备调研 Loop Engineering 这个最近火爆的概念。
本地已有相关素材，可以先利用起来，这些不用重新查。
G / 目标：
调研 Loop Engineering 的起源、定义、核心原理、最佳实践，
以及有哪些可以直接学的开源项目。
开源项目从文档质量、学习曲线、社区活跃度、实际落地案例几个维度评估。
最终产出一份面向 AI 小白的白皮书。
P / 过程：
正式开始前，先向我展示研究计划，等我确认后再执行。
```
注意 P 部分就一句话。因为 Rule 已经接管了过程，你不用教它怎么调研。你只需要补上 Rule 没做的——"先把计划给我看"。
对比一下烂提示词和这个 SGP 提示词，差别很明显：烂的只有个主题，其他全靠 Agent 猜，预算漫游，方向零控制，结果大概率通用还堆术语；SGP 的边界、用途、受众、已知信息、评估维度全清楚，先看计划再确认，预算精准。
## 实操：十几分钟跑出一份 12000 字白皮书
上面这套，我用 Loop Engineering 在 WorkBuddy 里实际跑了一次，把整个过程给你看一遍。
第一步，发提示词，Agent 先摸本地家底。
把组装好的 SGP 提示词贴进去，选深度研究，发送。
因为我告诉它"本地已有素材"，它没有直接开始联网搜，而是先做了一件事：派了一个 explorer subagent 去扫本地素材。 这个动作不算正式调研，只是先摸清楚家里有什么。这个 explorer subagent 在本地是并行搜的，同时走不同路径找，找到本地 Wiki 知识库，也找到一堆相关材料，读完报告给主 Agent。这就是前面讲的"主 Agent 不直接检索"——连摸底这活儿也委托给 subagent 了。
第二步，主 Agent 判断家底，给研究计划。
主 Agent 拿到 explorer 的报告，开始判断。它给了几个很清晰的判断：
1. 本地已经有一份待发布的 Loop Engineering 白皮书，还有配套的 Wiki 和来源台账，基本闭环。
2. 但读者画像变了——上次面向的是用过 AI 但没建立 Agent 工程认知的人，这次面向 AI 小白，表达方式得变。
3. 之前的调研缺开源项目评估，这次要补。
它还画了张素材覆盖图，哪些已经具备、哪些还缺，清清楚楚。
接着列出六个子问题，每个对应检索来源、用啥工具、分给哪个 subagent。比如开源项目评估走联网搜索，起源定义交给一个 research subagent，最佳实践和小白路径交给另一个。
最后它问我一个关键问题：是直接复用旧白皮书只做交叉验证，还是完全另起炉灶？
这就是 Rule 里那个澄清机制的实际表现——它用工具向你提问，而且只问影响方向的关键问题。
我直接告诉它：
> 完全另起炉灶。把本地旧白皮书当不存在，重新做一版；本地材料只做补充和交叉验证。
到这，WorkBuddy 才开始正式干活。
第三步，并行执行——三路 subagent 加主 Agent 同时干。
正式开跑后，WorkBuddy 同时做两件事。
第一，并行启动三个后台 subagent 分别联网搜。一个查起源定义，一个评估开源项目，一个查官方指南和实践路径。不同 subagent 的提示词不一样，有的抓开源项目，有的抓官方文档（比如 Anthropic 和 OpenAI 的），有的查起源。
第二，主 Agent 自己读本地五份核心材料。这里有个很多人没注意到的细节：主 Agent 等子代理的时候不是闲着。 它读完本地五份核心文章，三个 subagent 同时在跑。主 Agent 没干等，而是先整理本地材料，预判新旧白皮书的核心差异——读者水平不同、要把 Claude Code 官方那几种 Loop 模式讲清楚、要新增开源项目评估和小白实践路径。它还提前给出了新白皮书目录。
这就是主从并行的价值：子代理在外面查资料，主 Agent 在本地搭框架，两边不是串行排队。比很多人想的"Agent 一步步排队干活"高效太多了。
第四步，三路 subagent 回传结果。
三个子代理的活儿都回来了。
查起源定义的那个，发现我之前白皮书里关于概念传播链的顺序有问题，做了纠正，还补了权威定义、学术线索和 7 月最新动态。
评估开源项目的那个，筛出 11 个项目，按四个维度做了评估，最后选出 Top 3。
查官方指南和实践的，调研了官方文档、企业案例、最佳实践，整理出适合 AI 小白的六步路径。
注意——每个 subagent 返回的报告都带来源引用。这是 Rule 强制的，产出格式必须包含 References 部分，用 Markdown 链接列出来源。这不是一堆链接，是结构化、可追溯的检索报告。
第五步，主 Agent 综合产出。
素材全到位后，主 Agent 开始写新版白皮书。它综合了本地旧白皮书框架、配套讲义、Wiki 卡片、最近推文里的检查清单，加三个 subagent 的联网调研结果。它不是简单拼接，会先判断现有材料够不够撑住需求，够了才动笔写。
最后主 Agent 统一汇总，生成一份新版白皮书。
整个任务大概十几分钟，最后输出一份 Markdown 文档——14 章、3 个附录，大概 12000 字，面向 AI 小白的 Loop Engineering 白皮书。
因为我一开始定义的受众就是 AI 小白，它的口吻也很小白化。先讲清楚这白皮书给谁看、当前什么问题，然后讲定义、起源、时间线，为什么这个概念最近火，最新动态，以及它跟 Prompt Engineering、Context Engineering 这些概念的区别。
## 最后说几句
回顾整个演示，你重点理解几件事就够了：
主 Agent 是先摸底再制定计划，不是拿到任务就立刻拆问题；澄清问题是关键的人工确认点，但它问的是方向，不是展示完整研究计划；并行不只是 subagent 之间，子代理在外面查的时候主 Agent 在本地搭框架，两边同时干；每个 subagent 的报告都带来源引用，这才是"可追溯"的真正含义；工具调用预算是硬约束，问题太泛等于预算浪费等于产出拉胯。
最后留个问题给你想：这套"主控 rule + 并行 subagent + 专用 skill"的模式，如果搬到你自己工作里——比如做一个"调研某个技术方向再产出决策报告"的自动化场景，rule 该写什么、subagent 该有几个、skill 该补哪些你自己领域的信息源？
架构是现成的，变量是你的领域知识。
对 WorkBuddy 感兴趣的朋友可以继续蹲这个系列，大鹏只做深度实践类的文章。
## 相关链接
- [智见AI-大鹏](https://x.com/zjp1997720)
- [@zjp1997720](https://x.com/zjp1997720)
- [6.8K](https://x.com/zjp1997720/status/2075202251887718619/analytics)
- [https://x.com/zjp1997720/status/2067946720009584880?s=20](https://x.com/zjp1997720/status/2067946720009584880?s=20)
- [https://x.com/zjp1997720/status/2074418155406111072?s=20](https://x.com/zjp1997720/status/2074418155406111072?s=20)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [8:55 PM · Jul 9, 2026](https://x.com/zjp1997720/status/2075202251887718619)
- [6,815 Views](https://x.com/zjp1997720/status/2075202251887718619/analytics)
- [View quotes](https://x.com/zjp1997720/status/2075202251887718619/quotes)
---
*导出时间: 2026/7/9 23:23:40*