Anthropic 和 LangChain 都整理过一组常见 pattern。它们不是产品开关更像任务几何的解法工作集是否已知、对象是否同质、误报是否昂贵、方案空间大不大、比较是绝对还是相对、范围能不能事先框死。弄清形状比背功能名管用。也可以把六种模式当成积木。真正值钱的很少是单独一块而是怎么搭。下面先把每块看透再谈组合顺序、错配代价和选型。六种组织形状总览分类再派发、铺开再收拢、发现再验证、生成再过滤、两两打擂台、循环到停止分类再派发、铺开再收拢、发现再验证、生成再过滤、两两打擂台、循环到停止先分类再派专家Classify and act混合输入不该塞给同一个角色。工单里既有缺陷也有需求还有咨询日志里既有配置错误也有权限问题用户反馈里既有产品建议也有安全投诉。先分类再路由到不同专家子智能体最后按类汇总。适用信号很清楚同一批次里处理逻辑明显分叉。如果硬用同一个 prompt 处理全部模型会在「像缺陷」和「像需求」之间摇摆输出字段也不稳定。分类的价值是把异质问题重新变回同质子问题后面才能安全地 fan-out。分类阶段值得单独做干净。分类错了后面再并行也只是把错误放大。必要时给分类结果留一刀校验抽检低置信类别或让第二个分类器对边界样本复判。也不要把分类器做成无限细的标签树。标签太多路由会碎专家子智能体反而难沉淀。反模式是「先并行再在总结时分类」。那样每个子任务已经按错误假设处理过一遍总结阶段只能做文案归类救不回处理逻辑。先铺开再收拢Fan-out and synthesize同类工作作用于大量独立对象时最自然的形状是每个对象一个子任务并行执行最后合成一份总报告。代码目录审查、批量文档摘要、多源材料收集、按文件迁移都属于这类。有两点比较关键。工作集要先显式列出否则「铺开」没有边界。没有列表就没有覆盖证据。合成步骤最好是屏障等全部 fan-out 结束再按统一协议合并而不是边跑边用主上下文消化全过程。每个局部任务最好拥有干净上下文避免互相污染。合成也不是拼接而是过滤、去重、排序、留证据。Fan-out 解决的是覆盖和吞吐不自动解决误报。如果你得到很多「看起来像问题」的条目下一步通常要接验证而不是直接当结论发布。很多人把 fan-out 当成 workflow 的全部最后只是更快地得到一份更长的未校验清单。还有一个实现细节对象之间真的独立吗如果文件 A 的改法取决于文件 B 的接口决策盲目并行会制造冲突。这时要先做分层先共享决策再 fan-out 执行或按依赖批次推进。Fan-out 假设的是可并行单元不是任意切片。先召回再独立证伪Adversarial verification误报成本高时发现和验证必须拆开。第一遍尽量扩大召回找出可疑项第二遍把每个可疑项送给独立验证者验证者重新读证据返回确认或驳回只有存活下来的结果进入终稿。这直接针对 self-preferential bias。验证者不继承发现者的自我辩护路径上下文隔离本身就是机制不只是角色扮演。安全审计、合规检查、事实核查、关键架构结论都适合这个形状。Claude Code 的 deep research 思路也接近多角取证之后对声明做交叉核验再合成带引用报告。验证者的提示词应该逼它寻找否定证据而不是复述发现者的理由。更稳的做法是只给验证者「原始证据定位 待验证声明」不给发现者的长篇论证。否则隔离会被叙述穿透。代价是更贵、更慢。换来的是置信度不是速度。如果业务更在乎召回、能接受人工二次筛选可以减弱验证强度如果误报会直接进入阻断决策验证就不该省。也要分清「验证失败」和「验证驳回」后者是判断为不成立前者是没跑成。官方文档后来把未完成核验标成 unverified而不是当成 refuted就是在避免这种账目错误。先发散再过滤Generate and filter方案空间大时一上来就押一个答案往往更差。可以并行生成多个候选——不同架构、不同实现、不同文案——再按同一套标准打分、去重、过滤只保留少数高分结果。和 fan-out 的差别在于fan-out 通常是「同一类检查作用于很多对象」generate-and-filter 是「同一问题产生多个竞争解」。前者扩覆盖后者扩搜索。过滤标准要事先写清否则最后只是在多个漂亮答案里凭感觉挑一个。标准最好能落到结构化字段正确性、复杂度、可运维性、兼容成本。过滤层可以是脚本规则也可以是另一个子智能体但评分字段要能排序不能只是一段印象派评语。命名、设计探索、重构策略、限流方案对比都常见这个形状。反模式是生成很多候选却不隔离输出位置结果互相覆盖或生成后仍回到主模型自由发挥「我更喜欢哪个」把过滤阶段重新变回单上下文品味裁决。不打绝对分改打擂台Tournament有些好坏很难绝对打分却比较容易两两比较。风格选择、主观品味、多个实现「哪个更干净」都属于这类。做法是让多个候选进入淘汰赛由评判者做 pairwise 比较胜者晋级直到留下冠军或 Top N。Anthropic 特别强调过相对判断常常比绝对打分稳。一千行支持工单按严重度排序硬让一个上下文直接排序质量会塌拆成比较管线或分桶再合并更符合模型实际能力。人做评审时也常有类似现象问「这件有多严重」波动很大问「这两件哪个更严重」稳定得多。Tournament 贵因为它比较次数会随候选数上升。候选很多时先用 generate-and-filter 粗筛再对前几名打擂台通常更划算。也可以先分桶高、中、低三档内比较再合并避免全量两两爆炸。反模式是用 tournament 处理本该有客观标准的问题。能否通过测试、是否满足接口契约不该靠品味淘汰赛。擂台适合主观或相对秩序不适合可机器判定的对错。范围未知就循环到停Loop until done有时你事先不知道工作集有多大死代码可能还有、漏洞可能还有、间歇失败的测试可能还有。这时不该假装「跑三轮就够」而该定义停止条件——例如连续两轮没有新发现或某项检查连续两轮无改进——然后循环派发直到条件满足。循环里通常还要做去重否则同一发现会反复出现停止条件失真。也要防 runaway官方 runtime 会对总 agent 数、并发数设上限你自己设计时同样需要硬边界。Token 预算、最大轮次、最大无改进轮数最好同时存在。这个形状解决的是未知范围下的完备性压力。它和 fan-out 的差别是fan-out 先有集合再穷尽loop 边发现边扩张集合靠停止条件宣布「暂时穷尽」。边界已经很清楚、再循环只会烧 token 的任务不适合它。对已知 80 个文件做审查却写成 loop until done是典型错配。真正值钱的是组合不是单模式实际高价值任务很少只落在一种形状上。更常见的是组合。安全审计先枚举工作集再 fan-out 发现对每个 finding 做 adversarial verification最后 synthesize 成带覆盖证据的报告。没有验证审计像惊吓清单没有覆盖数字审计像观点文章。深度研究多角度 fan-out 搜索与取证对关键声明做交叉验证再合成带引用结论。研究质量往往不取决于搜得有多热闹而取决于哪些声明活过了验证。大规模迁移先列出调用点或文件集合再对每个对象在隔离工作区修改随后验证失败则局部重试最后汇总。隔离工作区解决并行冲突验证解决「改了但不等价」。分诊队列先 classify-and-act再对高风险动作做权限隔离。读不可信内容的角色不直接执行高权限写操作。这是 pattern 与权限边界的组合不只是路由技巧。根因调查从日志、代码、数据等不同证据面分别生成假设再让验证者与反驳者挑战必要时 loop直到假设收敛或证据不足被显式承认。它同时对抗自证和过早锁定。命名或设计选择先 generate-and-filter 拉开候选再对 Top N 做 tournament。既避免单点品味也避免全量擂台过贵。组合时有一条实用顺序先决定工作集如何产生再决定是否需要验证再决定如何聚合最后才决定要不要循环。很多人一上来就「多开几个 Agent」跳过了工作集和停止条件最后得到的是热闹不是证据。也可以压成四问有没有集合集合里要不要分型每个结果要不要独立过检范围是否可能继续长大四问答完积木差不多就选好了。跟一条完整配方从需求到编排骨架发版前鉴权审计配方列出工作集、铺开审查、独立验证、合成报告并附覆盖账本列出工作集、铺开审查、独立验证、合成报告并附覆盖账本拿「发版前做一次 API 鉴权审计」当例子走一遍公众号读者也能直接改写成提示词的骨架。需求先写硬检查src/routes/全部路由只报告确认成立的问题最终必须给出文件总数、确认数、驳回数误报进入阻断所以必须独立验证。形状判断工作集可列出 → 先枚举再 fan-out对象同类 → 不需要先 classify误报昂贵 → 必须接 adversarial verification范围已知 → 不用 loop until done。于是编排骨架就固定了enumerate files → fan-out audit → verify each finding → synthesize report with coverage numbers对应提示词可以很短「用 workflow 审计src/routes/鉴权。先列出全部路由文件并打印数量对每个文件做审查每个 finding 交给独立验证者只保留 confirmed最终报告必须包含文件总数、发现数、确认数、驳回数和失败文件列表。」你会发现pattern 名称可以不出现在提示词里。真正起作用的是任务形状被翻译成了工作集、验证和覆盖证据。模型随后写脚本多半会落到同一副骨架上。如果把需求改成「帮我看看鉴权大概有没有风险」形状就变了你要的是启发不是发版门禁。这时单上下文或单个 subagent 更合适硬上 fan-out verify 是烧钱。错配比不会用更常见不会用六种模式最多是保守用错模式会主动制造成本或假信心。把主观选择做成绝对打分得到的是不稳定排序。把客观对错做成 tournament浪费算力。把已知集合做成无限 loop烧钱。把高误报场景只做 fan-out产出惊吓清单。把异质输入直接 fan-out专家逻辑错位。把验证者喂进发现者的长篇叙事隔离名存实亡。所以学 pattern不只是记住名字更是记住它在替你承担哪类失败同时引入哪类成本。Fan-out 换覆盖付并发与聚合成本verification 换置信度付双倍判断成本tournament 换相对秩序付比较次数loop 换未知范围下的完备性付失控风险。没有免费的形状。怎么快速判断该用哪种不必背模式名按任务形状问这几句就够。工作集能不能先列成数组列得出偏向 fan-out列不出可能要先 discover或直接 loop until done。对象处理逻辑是否同类同类走 fan-out异类先 classify。误报是否昂贵昂贵就加独立验证。是在处理很多对象还是在为同一问题找多个解前者 fan-out后者 generate-and-filter 或 tournament。评价更适合绝对分还是两两比相对比较走 tournament。范围是否已知未知就给硬停止条件不要只写「尽量完整」。这几问答完编排脚本的骨架基本就出来了。模型随后做的往往是把这副骨架写成可执行代码。动态 workflow 的「动态」很多时候不是神秘创造力而是模型把任务几何映射到这些积木上。如果大部分问题都答不清楚通常不是该上更复杂 workflow而是任务本身还没定义好。先把成功标准、边界和不可做什么写清再谈 pattern。什么时候不要上复杂形状小改动、单点排查、边界清晰且人工一眼能核对的结果用对话或单个 subagent 更快。Workflow 更贵也会放大边界不清时的跑偏。Anthropic 也提醒过不是每个任务都需要更多算力五个评审团围观改按钮通常是过度设计。我自己用的判断很简单要一次回答用对话要一套可证明、可复跑的过程再上 workflow。选 pattern 的目标不是更炫而是让覆盖、验证和停止条件长在结构上。还有一个实用门槛流程是否值得复用。一次性的好奇探索不必沉淀成脚本每次发版前的质量扫描、每次大迁移前的风险评估、每次技术选型前的多维研究才值得把编排留成资产。动态生成解决的是「这次怎么组织」保存下来解决的是「下次别从零再发明一次」。系列收束单上下文败在规模它把计划、状态、证据都背在同一段对话里规模一上就漏项、自证、漂移、被噪音淹没。动态 workflow 把控制流、状态、覆盖交给代码设计阶段用智能执行阶段用结构模型继续判断系统开始做账。六种 pattern 则是面对不同任务几何时的组织答案。它们可以单独用但更常组合。稀缺的不是多开 Agent而是让 Agent 以正确结构协作。完成靠证据不靠语气。顺序别反先看任务形状再选组织方式最后才谈开多少 Agent。反了的话热闹会先到可靠性很少跟着来。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。
