/deep-research深度解析Claude Code的杀手级Graph应用一条斜杠命令背后是四种Agent、五层Diamond、几十次并发调用——这是目前公开可见的最完整Graph工程落地本文导航为什么说/deep-research是杀手级应用五阶段工作流全景内部图拓扑拆解四种Agent角色状态管理证据池、引用映射、研究笔记并行策略扇出宽度、早停与预算控制复刻你自己的deep-research系统小结下节预告互动区为什么说/deep-research是杀手级应用前面三节我们用Dynamic Workflows自己搭图说实话手搭的图多少有点玩具感。这一节讲一个真正经受过生产考验的图系统——Claude Code内置的/deep-research命令。用过的人都知道它的体验你给一个研究问题它吭哧吭哧跑几分钟到十几分钟最后交给你一份带完整引用来源的研究报告。但多数人没意识到这条斜杠命令背后跑的是一个完整的多Agent图搜索Agent、分析Agent、验证Agent、综合Agent各有各的上下文、各有各的模型层级、各有各的终止条件。为什么我说它是杀手级应用三个理由它是Graph工程的全要素示范。我们在第33到40节讲过的拓扑模式——Diamond、Router、Verifier、Convergent Loop——它一个不落全用上了而且是嵌套着用。它解决了真实痛点。深度研究是单Agent做不好的典型上下文塞不下几十个网页、单视角容易被单一信源带偏、没有验证就是幻觉复读机。这正是第6节讲的单Agent Loop五大缺陷的活体标本。它是可拆解、可复刻的。它的每个设计模式都能被抽出来用在你自己的系统里这一节最后一部分我就带大家复刻一个。先给个直观的量级感受一次典型的/deep-research执行会发起20到60次子Agent调用抓取并精读15到40个信源全程在16并发的舰队边界内第48节讲过的硬限制最终产出一份几千字的带引用报告。这是一个真正意义上的子Agent舰队作战。五阶段工作流全景把/deep-research的执行过程拉直了看是五个阶段证据不足/有冲突证据充分研究问题① Scope 问题拆解与检索规划Opus② Parallel Search 并行搜索搜索Agent舰队Haiku/Sonnet③ Fetch Read 抓取精读分析AgentSonnet④ Adversarial Verify对抗验证Opus⑤ Synthesize 综合报告综合AgentOpus带引用的研究报告逐个阶段说人话① Scope范围界定拿到研究问题后先不急着搜而是把问题拆解成3到6个子问题并为每个子问题生成检索计划关键词变体、期望信源类型、判定标准。这一步是典型的决策/裁决活判断力密度高用Opus。规划错了后面全是白搜——和第50节验证点1必做是同一个道理。② Parallel Search并行搜索检索计划里的每个子问题扇出一个搜索Agent并发执行web搜索。这是整个流程里调用次数最多的阶段也是成本大头所以搜索Agent用的是便宜模型Haiku做检索式扫描、Sonnet做需要判断的相关性筛选。③ Fetch Read抓取精读搜索命中的URL并不等于证据必须抓取全文做精读提取。分析Agent把网页原文压缩成结构化的证据条目claim evidence source这一步是上下文压缩的关键——不压缩的话几十个网页的原文会直接撑爆后续节点的上下文。④ Adversarial Verify对抗验证这是全系统的灵魂。验证Agent拿着证据清单去挑刺来源可信吗证据支持结论吗不同来源之间矛盾吗不通过就带着缺口回到②补搜——这是一个Convergent Loop第38节有最大重试次数防止无限循环。⑤ Synthesize综合报告证据充分后综合Agent把所有证据条目编织成一份带引用的连贯报告。注意它不只是拼接还要做观点冲突的显式处理“A来源认为XB来源认为Y证据权重更支持Y”。五个阶段对应五层判断力密度模型分配正好是第50节那套框架的实例化Opus管①④⑤Sonnet管③和部分②Haiku管纯检索扫描。内部图拓扑拆解四种Agent角色把五阶段翻译成图拓扑/deep-research的内核是一张多层嵌套的Diamond综合层单节点验证层Convergent Loop分析层Diamond ②扇出-汇聚搜索层Diamond ①扇出-汇聚规划层单节点缺口补搜通过Scope Planner搜索Agent: 子问题1搜索Agent: 子问题2搜索Agent: 子问题n...Search Collector 汇聚分析Agent: 信源1分析Agent: 信源2分析Agent: 信源m...Analysis Collector 汇聚Verify Agent 对抗验证Synthesis Agent四种Agent角色的契约我整理成一张表角色职责模型输入输出扇出宽度搜索AgentSearcher按检索计划搜网、筛相关性Haiku/Sonnet子问题 检索计划候选URL列表3~8分析AgentAnalyst抓全文、提取证据条目SonnetURL 原始网页结构化证据5~15验证AgentVerifier对抗审查证据与结论Opus全部证据条目verdict 缺口清单1综合AgentSynthesizer织报告、显式处理冲突Opus全部通过验证的证据带引用报告1几个拓扑设计上的门道是我反复看它执行日志总结的验证层收敛为单节点是有意为之。扇出的搜索和分析天然多样但裁决必须一个人说了算——多个Verifier投票会引入新的合并难题第49节讲的Fan-in困境而验证的判断力密度要求高单点强模型比多点弱模型便宜且稳。补搜回路边V→S是有条件边。它不是无脑循环验证Agent输出的缺口清单会精确路由到具体子问题的搜索Agent——这是定向重试而不是整体重跑和第31节失败路由的定向修复完全同构。每层都有自己的汇聚节点Collector做的是压缩去重结构化不是简单收集。上下文在层与层之间被不断压缩这是对抗Context Rot第7节的核心手段。状态管理证据池、引用映射、研究笔记单Agent做研究最头疼的是状态搜到的东西放哪引用怎么跟结论挂钩/deep-research的解法是把状态拆成三张表Agent之间不共享对话历史只共享这三张表——这就是第19节节点隔离的教科书级实践状态表内容写入者读取者证据池Evidence Poolclaim / evidence / source / confidence分析Agent验证、综合Agent引用映射Citation Map结论ID → 证据ID列表 → URL综合Agent报告渲染研究笔记Research Log每阶段的决策、缺口、重试记录所有Agent验证Agent、人用pydantic把这三张表的Schema钉死Python侧做数据校验时的标准动作# schemas.py —— deep-research 状态表的 Schema 定义pydantic 校验frompydanticimportBaseModel,Field,HttpUrlclassEvidence(BaseModel):证据条目分析Agent的产出单元claim:strField(description一句话结论)evidence:strField(description支撑原文摘录)source:HttpUrlField(description来源URLpydantic自动校验URL合法性)confidence:floatField(ge0,le1,description置信度 0~1)classCitationMap(BaseModel):引用映射结论 → 证据链 → URL保证报告可溯源conclusion_id:strevidence_ids:list[str]urls:list[HttpUrl]classResearchLog(BaseModel):研究笔记阶段决策与缺口供Verifier定向路由stage:strField(pattern^(scope|search|read|verify|synth)$)gaps:list[str][]# 验证Agent发现的证据缺口retries:int0# 该阶段已重试次数为什么状态要这么拆两个字溯源。报告里每句话都能顺着引用映射摸到证据池里的原文摘录再摸到URL。用户质疑某条结论时你不需要重跑整个系统只需要打开那条证据看原文。这个设计比把所有网页原文塞进上下文让模型自己引用可靠一个数量级——后者的引用经常是幻觉。并行策略扇出宽度、早停与预算控制/deep-research的效率有一半来自并行策略的设计我总结成三条第一扇出宽度分层设定。搜索层扇出38个子问题数量决定分析层扇出515个命中URL数量决定验证层和综合层永远是1。宽度不是拍脑袋搜索层的瓶颈是信源多样性够覆盖子问题就行分析层的瓶颈是IO抓网页宽一点吞吐高。但所有层加起来不能突破第48节的舰队边界——并发16、总量1000所以分析层实际执行时是分批的// 分析层的分批扇出并发上限内滚动执行批内并行、批间流水consturlscollector.pickCandidates(30);// 汇聚节点筛出的候选URLconstevidence[];for(constbatchofchunk(urls,8)){// 每批8个16并发留一半余量constreadsawaitparallel(batch.map((u)agent(抓取并提取证据条目输出JSON数组${u},{model:sonnet,output:json})),);evidence.push(...reads.filter(Boolean).flat());// 标配清洗if(verifyQuick(evidence))break;// 早停证据已饱和就不再抓}第二早停early stopping。证据池达到饱和就提前终止搜索和抓取。饱和的判定标准是边际收益递减最近N个新增证据条目没有带来新的claim维度。没有早停的deep-research会把预算烧在重复证据上。第三预算控制三件套阶段级timeout搜索阶段不超过X分钟、重试上限补搜循环最多2轮呼应第38节Convergent Loop的收敛设计、成本熔断累计花费超过阈值就带着现有证据进入综合阶段——降级交付而不是崩溃第32节优雅降级的标准打法。这三条合起来回答了一个问题为什么/deep-research快而不糙。快来自并行和早停不糙来自验证回路和溯源状态。两者缺一不可——只并行不验证是幻觉生成器只验证不并行是慢如老牛。复刻你自己的deep-research系统说了这么多别人的设计怎么变成自己的我把最小可运行版本浓缩成一张对照表和一段编排脚本。先看/deep-research的设计模式怎么映射到你自己的系统/deep-research 的设计你可以复刻的实现Scope规划Opus拆解子问题输出JSON检索计划并行搜索parallel扇出搜索Agent接你的搜索API抓取精读pipeline(urls, 抓取, 提取)Sonnet压缩成证据条目对抗验证独立Verifier 条件补搜回路最大2轮综合报告Opus按引用映射织报告三张状态表JSON文件 / SQLitepydantic校验核心编排脚本骨架约30行就是整个系统的图结构// workflows/my-research.js —— 自建 deep-research 最小骨架exportdefaultasyncfunctionrun(ctx){// ① Scope拆解子问题判断密度高 → Opusconstplanawaitagent(把研究问题拆成3~5个子问题并给出检索词输出JSON${ctx.input},{model:opus,role:planner,output:json});letevidence[];for(letround0;round2;round){// Convergent Loop最多2轮// ② Parallel Search ③ Fetch搜索与抓取融合成一层扇出constfoundawaitparallel(plan.queries.map((q)agent(搜索并提取关于「${q}」的证据条目输出JSON数组,{model:sonnet,output:json})));evidence.push(...found.filter(Boolean).flat());// fan-in清洗 → 证据池// ④ Adversarial Verify带缺口清单的对抗验证裁决密度最高 → Opusconstverdictawaitagent(你是独立验证员任务是挑刺。审查证据池输出JSON{pass:bool,gaps:[...]} 证据池${JSON.stringify(evidence)},{model:opus,role:verifier,output:json,tools:[Read]});if(verdict.pass)break;// 证据充分则出环plan.queriesverdict.gaps;// 定向补搜缺口变检索计划}// ⑤ Synthesize带引用综合Opusreturnawaitagent(基于证据池写研究报告每条结论标注来源${JSON.stringify(evidence)},{model:opus,role:synthesizer,output:file});}对照第48节的三原语视角这段脚本用了agent5种角色、parallel搜索层fan-out、手写循环实现Convergent Loop。图结构不在任何DSL里就在这些函数组合里——这就是Dynamic Workflows图隐含于代码的含义。跑自建版本时的调试建议把每一轮的证据池快照存成文件evidence.round1.json验证Agent的verdict单独落日志。deep-research这类长流程最大的调试痛点是不知道中间发生了什么快照文件就是你的时间旅行调试器——这一招从LangGraph的Checkpointer借来的工具不同思想通用。小结这一节把/deep-research这个杀手级应用拆到了螺丝钉五阶段工作流Scope规划 → 并行搜索 → 抓取精读 → 对抗验证 → 综合报告本质是多层嵌套Diamond 一个Convergent Loop。四种Agent角色搜索Haiku/Sonnet、分析Sonnet、验证Opus单点收敛、综合Opus模型分配严格按判断力密度。状态管理三张表证据池、引用映射、研究笔记节点间只共享结构化状态不共享对话历史溯源能力是可靠性的来源。并行三策略分层扇出宽度、边际收益早停、预算三件套timeout/重试上限/成本熔断快而不糙的根本。全部设计模式可复刻30行编排脚本 pydantic状态Schema就能搭出你自己的深度研究系统。下节预告/deep-research再漂亮也只是Claude Code能力图谱的一个亮点。下一节我们把镜头拉远客观盘点Claude Code Graph的优势与局限什么场景它是降维打击什么场景它会让你在第三天就想换LangGraph哪些坑是官方文档不会告诉你的这一节可能有点劝退但每一条都是实战换来的。互动区你们有没有用/deep-research做过真实的研究任务体感上它的报告质量对比人工调研能打几分最想吐槽的是哪个环节评论区聊聊我打算把大家的案例汇总成一篇实战评测。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~
