这三年下来，我已经离不开用AI辅助做行业研究，为此还搭建过一系列的skill和辅助系统，解决信息的筛选，归纳，联结，验证，沉淀。直到这周深度体验了Claude Code的动态工作流之后，才发现“人不要和大时代做对抗”这句话的真正含义。再次思考下：什么才是AI时代下人该做的深度研究，以及如何构建我与AI的协作互补关系。
一、从调研的陷阱说起
做技术调研其实是一件充满陷阱的事（无论对人还是AI），毕竟从调研的开始，会接收到大量的信息，信息观点越来越多，结论越来越模糊。所以时刻要懂得回归目标本身。这也一直以来，为什么AI不够优秀的地方，因为从注意力和联想的角度看，他会比人类更困于当前的信息量，并且对于真正有价值的跨界联想很薄弱。当然AI够优秀的地方，则是他的执行力，会以agent的形式一层层的去寻找，归纳，总结，完全可以避免细节的损耗。
虽然我这半年都没怎么对外发公众号了，但几乎行业里主流的战场我都有在全面的关注和研究，而支撑这输入输出的，则是一套自己的deep-research系统。而面对上周Claude Code上线了Dynamic Workflows这个功能，我想互相battle下，看他的默认能力，能否完全超越我自己。
二、Dynamic Workflows是什么
Dynamic Workflows（动态工作流）它的核心思路是：在执行任务之前，先由AI自动设计这个任务应该用什么工作流来完成，然后再启动执行。这和我们以前用的“计划模式”和“skill”有本质区别。计划模式是把任务拆得更细，但不一定符合某种合理的工作流，随着你提示词的安排，才有可能会加验收指标（这对Research而言至关重要），同理你也只有在有提示词的情况下，他才会更好的预设一些harness规则。但是动态工作流则会自动把验收逻辑、结果收敛、对抗验证这些东西都组进来。
触发方式很简单，直接在cc里使用/deep-research然后提供一些调研模板和入口资料即可，如果想单独用动态工作流的能力则是提示词或直接说ultracode，使用前注意，token消耗约为平常的数十倍。
三、内置的六种工作流模式
动态工作流的底层，是官方总结的六种核心调度模式，这是它为什么比普通的对话/agent/skill更强的原因。其实这六种模式背后其实只有两个核心问题：任务怎么拆？结果怎么合？分开六种本质就是对这两者的排列组合。
3.1 路由模式（Classify-And-Act）
先由一个agent分辨任务类型，再把任务分发给最适合的专门agent去做。核心逻辑是路由的选择逻辑，而非并行或迭代。一个任务只走一条路径，其他路径完全不执行。
比如我可以先有三个预设subagent角色：一个严格验证数据的分析agent、一个擅长写作的输出agent、一个专门找漏洞的挑战agent。让路由层会判断当前子任务适合交给谁，而不是让一个agent全包。这种模式的价值在于：精准和节俭，每个agent的提示词可以高度独立，不被其他目标干扰，形成有垂直深度的探索。token消耗最低，响应速度最快。职责边界非常清晰。缺点也很显著，对边界模糊的任务（比如“既是技术问题又是账户问题”）处理能力弱。
3.2 拆分合并（Fan-out & Merge）
也是我最常用的模式，核心逻辑是并行+合并。任务拆成N个独立子任务同时跑，等所有完成后统一合并。
优势在于速度和隔离。总耗时约等于最慢那个子任务，而非所有子任务之和。每个子任务有独立context，互不干扰，也不会因为某个子任务的噪声污染其他子任务。弱点是token成本是串行的N倍，合并层（Synthesize）本身也有难度——N路结构不一致的输出怎么融合是个设计挑战。子任务划分不好会导致遗漏或重复覆盖。
3.3 对抗验证（Adversarial Verification）
核心逻辑是检验，对同一个结论，让多个agent从“反驳”的角度去挑战，票数过半才算通过。
优势在于，由于Verifier不知道Worker的思路，只看结果，从结构上消除了“让模型检查自己写的代码”时的自评偏差。这种模式，解决了一个长期困扰我的问题：我们经常用口语化的方式跟AI聊，但AI倾向于顺着你的预期去回答，容易产生“确认偏误”。通过对抗验证强迫AI去寻找反例，去基于数据和实验来验证，而不是迎合你的想法。但是，验证这件事，他如果给出错误的判断，则会带偏Worker，去迎合Verifier。所以优选要基于可复现的事实，而非借助观点。开个玩笑的说，你如果让AI找问题，他能无穷无尽的找出问题，所以你得限制他找问题的边界。
3.4 生成与过滤（Generate & Filter）
核心逻辑是发散再收敛。先刻意产生过量的候选，再用rubric淘汰到精华，只保留高置信度的结果输出。
与其让一个agent输出一个“还行”的答案，不如让它生成十个，再用验证层筛选。因此优势在于多样性。多个Generator可以用不同策略、不同提示词，产出人工难以预想到的解法，过滤步骤让最终输出质量高度集中。弱点则是，Filter的rubric质量直接决定最终效果，rubric设计错误等于整个流程报废适合的场景是事先不知道正确答案的情况、需要从多种可能中择优、对多样性有明确需求。和Fanout-And-Synthesize的只是表面相似：两者都是“多路并行 → 单一输出”，最容易混淆。关键差异在于意图：Fanout的每一路都处理任务的不同部分，结果是互补的，合并时所有路都有贡献；Generate-And-Filter的每一路处理的是同一个任务，结果是竞争的，合并时大部分会被丢弃。前者是“拼图”，后者是“选美”。
3.5 锦标赛模式（Tournament）
核心逻辑是竞争淘汰。N个agent各自独立做同一件事，通过pairwise对比逐轮淘汰，最终选出最优解。
这个我以前手动干过——同一份代码变更跑两三个版本，再让AI比对哪个更好。现在可以直接在工作流里编排进来。优势在于评判稳定性。两两对比（“A和B哪个更好？”）比绝对评分（“给A打分”）稳定得多，因为排除了评分标准漂移的问题。结果经过多轮竞争，最终胜者的可信度高。和Generate-And-Filter的也是表面相似：两者都是从多个候选中选优。关键差异在于选优机制：Tournament用pairwise judge两两比较，是“让候选者互相竞争”。当rubric难以量化、判断本质上是相对的时候，会更可靠。
3.6 循环模式（Loop）
核心逻辑是自适应迭代，不断尝试，遇到阻力就收集错误信息，补充上下文，重新尝试，直到满足验收条件为止。
本质上是在对抗AI的随机性：多试几次，总会撞上更好的结果。但更成熟的做法是结合对抗验证，让每次循环都带着更多信息去执行，而不是纯靠随机。优势在于对工作量未知的任务的处理能力。其他五种模式都假设任务边界是确定的，Loop Until Done是唯一能处理“不知道要做多少轮”的模式弱点是潜在的失控风险——停止条件设计不好会无限循环。每一轮的agent是全新的context，无法积累跨轮状态（除非显式写入文件）。
四、我自己的skill和官方工作流的Battle
在动态工作流出来之前，我专门设计过一套自己的deep-research。我那套skill的逻辑大概是这样：只给一个简单的信息（比如某项目新上了某功能）让AI去搜索所有相关资料：官方文档、源代码、市场舆论把信息压缩成有意义的摘要多个agent角色做对抗分析，生成报告自动去重，因为多agent的内容重复率很高用了一段时间，我觉得挺好用的。但它有一个根本性的缺陷：缺乏以目标为导向的收敛。而且很多时候即使有第五步的去重，但这个时候，他经常删除掉有价值的信息，如果不做去重，又特别容易skill会给你一篇万字长文，信息很全，但没有直接告诉你“这件事跟你有什么关系、你应该怎么做”。然而，研究是为了“决策”服务的，这就是为什么很多skill只能止步于研究本身，有80分，但少了最关键的20分。以至于AI在初步完成了研究后，还需继续十次的思考和对话，才能达成满意的周全的结论。
官方动态工作流多做了什么
通过这周几次复杂调研任务的实验，我发现，Claude Code内置的deep research工作流（注意不只是skill，而是编译内嵌到cc里的模块），对比在我自己skill的基础上，多了几个关键环节：问题拆解层：它不会直接开始搜索，而是先开始问问问题，把我的问题拆成多个子问题：你真正想搞清楚什么？这件事和你有什么关系？哪些维度值得深究？这一步我以前是跳过的。可信度评估：对每条信息评估可证伪性，类似传统SEO里的权威性评分——来源是否可信？引用次数如何？这是我以前没想到要加的环节。交叉删除而非平均合并：我以前的做法是平均选取所有结论，所以文档很大。动态工作流会对每个结论做多agent投票，票数不足的删掉，不是简单合并。目标导向的输出：最终的报告不是信息堆砌，而是围绕你的原始目标给出判断和建议方案。而实现这点的关键在于他调度多子agent的预设能力，我之前之所以skill容易缺少最终目标导向，就是因为在海量信息后，指令权重的衰减。
这些机制解决了什么问题？
针对的就是AI做长任务的几个典型问题：目标漂移：任务开始时状态好，到中间就不知道在干什么了，结束时又重新找回节奏——类似人类上课走神。任务越长越明显。过早停止：跑着跑着遇到困难，AI认为自己“完成了”就停下了，实际上验收标准根本没过。上下文污染：单个agent做复杂任务，前置的大量prompt会压缩后续执行空间。更好的方式是把前置prompt控制在几k以内，用多agent来分摊上下文。输出偏向：AI倾向于顺着你的预期回答，口语化提问更容易触发这个问题。而动态工作流用结构化的方式解决了这四个问题：自动加验收指标防止过早停止；并行隔离上下文；对抗验证抵消输出偏向；拆解问题层层约束AI先理解目标再行动。
五、小结
最后，笔者作为个常年的研究工作者，对此CC新机制叹为观止，它内置的六种模式——路由选择、拆分合并、对抗验证、生成过滤、锦标竞选、Loop循环——覆盖了绝大多数复杂研究任务的调度需求。让我不再需要手动设计agent调度，也不再需要自己做去重和交叉验证，这些都被编进工作流本身了。而且他特别适合在缺少信息，开发性问题的探究上做思考，因为天然的多agent调度+任务目标的拆分，让他在通用性上再次提升，其实早在3年前的AI，对于一个层层约束，只让他解决极为清晰的小问题上，已经做得很好了，但是AI真正的质变还是在于通用性，这点才他的竞争对手，从简单的代码变为真正成为Agent，从固态解决一个问题，到适应任何问题。所以Dynamic Workflows动态工作流不是“更聪明的单次对话”，而是把研究流程本身结构化。原本我需要发起十几次独立对话的调研，现在压缩到3-4次。虽然对应的Token消耗是数十倍的增长了。
那为什么还需3-4次呢？我觉得根因在于这些需求的差异。第一是验证机制的严苛度，我是主要对区块链上的新技术做研究，很多事情，官方文档都是滞后的，有更值得参考的开源代码，链上交易等等数据，而目前AI默认还是以官方文档为准，而不是以事实性验证为准。第二是完全跨界的深度思考，这点虽然通过工作流预设可以解决一些（预定义各种维度的subAgent）来对同一个问题进行思考。但是AI擅长的还是主流思考模型，对非常新的，非常深刻，缺少数据依据的，则稍显不足。第三是解决方案设计与验证，解决方案的意义不在于提出而在于验证，支持，他依托于对现有机制，投入和成本的衡量，如果很好的调教AI当然可以做得更好，不过这就与通用性有所违背了。最后是极致的信息浓缩，这则是需要回归到对信息的受众的了解程度上，有的人毫无背景基础，需要你拟人的形象的表述，而有的听众，需要你一句话打动他~。
