验证模式与模型分层让对的模型做对的事同样的任务质量账单从每月4200美元降到1600美元——没有换模型只是换了谁干哪件事本文导航验证模式Diamond里的对抗性把关模型分层的第一性原理判断力密度三层模型分工Opus决策、Sonnet执行、Haiku路由CLAUDE_CODE_SUBAGENT_MODEL与配置实战成本优化数据一份真实账单的拆解小结下节预告互动区验证模式Diamond里的对抗性把关上一节的Diamond里其实埋了个伏笔最后那个合并审查节点本质上就是Verifier验证者。这一节把它正式请出来讲清楚验证模式怎么设计。第36节讲拓扑模式的时候我说过Verifier的核心是对抗性——验证者不能是生成者的自己人。在Claude Code的Dynamic Workflows里落实这三条原则独立上下文。Verifier用独立的agent()调用不共享生成者的对话历史只看最终产物。这天然满足节点隔离。角色对立。生成者的prompt是实现它Verifier的prompt是推翻它。模型更强。裁决者的判断力要高于被裁决者这条下一节细说。在Diamond上加Verifier有三个可选位置我画出来通过通过通过驳回驳回通过需求拆解验证点1: 契约审查数据层生成服务层生成接口层生成验证点2: 单层自检合并验证点3: 全局对抗审查定向重生成交付验证点1生成前审查需求拆解和接口契约。最便宜的验证位置——契约错了后面全部返工。验证点2生成后、合并前各层自检。可以下放给生成Agent自己做self-check成本低但对抗性弱。验证点3合并后全局对抗审查。最强的Verifier放这里因为层间冲突只有拼起来才暴露。我的经验是验证点1和3必做2可选。一个常见的反模式是只做验证点3结果Verifier发现契约错误整个Diamond白跑一遍——验证点1一行代码就能省下这次全额返工。验证节点的prompt模板我固定用这个格式对抗性直接写进指令里constverdictawaitagent(你是独立评审员与生成方零关联。你的任务是找出问题而不是认可成果。 对以下产物逐项审查输出 JSON{verdict:pass|reject,defects:[{where:...,why:...,severity:high|mid|low}]} 没有问题才允许 verdictpass。产物${artifact},{model:opus,role:adversarial-reviewer,output:json,tools:[Read]},// 只给读权限防止Verifier顺手改代码);注意最后一个细节Verifier的工具集要收窄。只给Read不给Edit/Bash验证者只能挑毛病不能动手改否则它会跳过验证直接改产物对抗性就废了。模型分层的第一性原理判断力密度为什么Opus/Sonnet/Haiku要分工不是因为贵的就该干重要的活这种废话。我的框架是一个词判断力密度。不同任务对每token推理深度的要求差异巨大写一段CRUD代码模式匹配为主判断力密度低Sonnet绰绰有余。决定系统该不该有缓存层涉及权衡和预测判断力密度高必须Opus。从一段文本里提取5个字段几乎不需要推理判断力密度极低Haiku就够。用高判断力密度的模型干低密度任务是拿茅台炒菜——钱花在了模型的推理能力上而那部分能力根本没被用到。反过来用低密度模型干高密度任务是拿92号汽油跑F1——省了钱质量崩了。所以分层的正确问题不是哪件事重要而是哪件事需要每token推理深度。按这个标准我把典型图节点分成三档节点类型判断力密度推荐模型典型节点决策/裁决/架构高Opus需求拆解、契约设计、仲裁、对抗审查执行/生成/转换中Sonnet写代码、写文档、格式转换、数据分析路由/提取/分类低Haiku意图识别、字段抽取、结果分类、摘要再补一刀同一个节点在不同阶段密度也不同。比如代码生成整体是中密度但如果生成的代码里有个算法选型的决策点就该先用Opus出方案、再用Sonnet落实现。这就是决策与执行分离本质上是把一个混合密度节点拆成两个纯密度节点。三层模型分工Opus决策、Sonnet执行、Haiku路由把上一节的Diamond按这个框架重排一遍得到完整的模型分层版编排脚本// workflows/layer-gen-tiered.js —— 带完整模型分层的 Diamondexportdefaultasyncfunctionrun(ctx){// 【决策层 Opus】需求拆解错则全盘返工值得用最强模型constplanawaitagent(拆解需求为三层并定义接口契约输出 JSON${ctx.input},{model:opus,role:architect,output:json});// 【路由层 Haiku】快速判断各层复杂度决定是否需要升级模型constcomplexityawaitagent(判断以下三个模块各自的实现复杂度simple|complex输出 JSON {data:...,service:...,api:...} 契约${JSON.stringify(plan)},{model:haiku,role:router,output:json},);// 【执行层 Sonnet/Haiku 动态分派】简单层降级复杂层保级constpick(level)(levelcomplex?sonnet:haiku);constlayersawaitparallel([agent(实现数据层${plan.data_api},{model:pick(complexity.data),role:data-engineer,output:file}),agent(实现服务层${plan.service_api},{model:pick(complexity.service),role:backend-engineer,output:file}),agent(实现接口层${plan.http_api},{model:pick(complexity.api),role:api-engineer,output:file}),]);// 【裁决层 Opus】全局对抗审查 仲裁constvalidlayers.filter(Boolean);constreviewawaitagent(你是独立架构评审员任务是挑刺。审查三层代码接口一致性输出 JSON {verdict:pass|reject,defects:[...]} 代码${valid.join(\n\n)},{model:opus,role:adversarial-reviewer,output:json},);return{plan,complexity,review};}控制台输出$ claude workflow run workflows/layer-gen-tiered.js --input 实现一个带缓存的用户查询服务 [architect] 拆解完成opus输入1240 tok / 输出890 tok [router] 复杂度判定datasimple servicecomplex apisimplehaiku耗时2.1s [workflow] 动态分派data→haiku service→sonnet api→haiku [data-engineer] 完成haiku54行11.3s [backend-engineer] 完成sonnet96行28.7s [api-engineer] 完成haiku41行9.8s [adversarial-reviewer] verdictpassdefects 1 项low [workflow] 执行完成总耗时 51.4s 本次调用统计 模型调用 6 次opus×2 sonnet×1 haiku×3 估算成本$0.19未分层基线 $0.42节省 54.8%看到了吗路由节点Haiku2.1秒花的那点小钱直接把两个执行节点的成本砍半。这就是用便宜模型决定贵模型干什么活的杠杆效应。CLAUDE_CODE_SUBAGENT_MODEL与配置实战说说落地配置。Claude Code里子Agent的默认模型由环境变量CLAUDE_CODE_SUBAGENT_MODEL控制命令行和编排脚本里逐节点的model选项优先级更高。优先级链是节点级 model 选项 CLAUDE_CODE_SUBAGENT_MODEL 主会话模型我的标准配置写进项目的.claude/settings.json和CI环境变量# .envrc 或 CI 环境变量# 子Agent默认用 Sonnet执行类节点占大头性价比最优exportCLAUDE_CODE_SUBAGENT_MODELclaude-sonnet-4-5# 成本熔断单次 workflow 调用预算上限美元防止失控循环烧钱exportCLAUDE_CODE_WORKFLOW_BUDGET_USD2.0# 并发上限避免 fan-out 过宽触发限流exportCLAUDE_CODE_MAX_PARALLEL4踩过的坑说两个。第一别把CLAUDE_CODE_SUBAGENT_MODEL设成opus。我见过有团队图省事全量上opus结果一个中等复杂度的workflow跑出两位数美元而质量提升肉眼看不出来。默认模型应该是Sonnetopus只在节点级显式指定。第二并发上限别裸奔。parallel里挂10个Agent看起来很爽实际会撞API限流失败位变多filter(Boolean)之后剩一半结果反而拖慢整体。我的经验是并发4是个甜点位超过8收益递减、失败率上升。另外提一句跨框架的一致性如果你在Python侧也调Claude API做混合编排同样的分层原则适用——我习惯用pydantic定义每个节点的输出Schema做运行时校验路由节点解析失败直接降级到Sonnet重试防止Haiku的JSON抽风把脏数据流进下游。成本优化数据一份真实账单的拆解光说不练假把式。这是我参与的一个真实项目一个每天跑200次的PR审查重构建议workflow改造前全量Sonnet决策节点也是Sonnet改造后按三层分层。一个月22个工作日的数据指标改造前全Sonnet改造后三层分层变化月调用次数26,40027,200多了路由调用3%月成本$4,210$1,603-62%平均单次耗时74s61s便宜模型更快-18%审查问题召回率91%93%裁决换Opus2pp误报率12%7%对抗审查更严-5pp两个反直觉的点调用次数变多了成本反而降了62%。多出来的路由调用用Haiku成本忽略不计但让60%的执行节点降级成了Haiku。质量不降反升。因为分层把省下的预算投给了Verifier——裁决节点从Sonnet升级到Opus。所以模型分层不是单纯省钱是预算再分配把钱从低密度节点挪到高密度节点。从长度与耗时的关系看也有收获Haiku的执行节点平均输出token数和Sonnet差不多但耗时只有Sonnet的40%——生成类任务里模型速度差异比token成本差异更影响总时长。这也是为什么分层后端到端延迟降了18%。小结这一节把Diamond的智力配置做对了验证模式三原则独立上下文、角色对抗、裁决者更强Verifier工具集要收窄到只读。验证点1契约和3全局必做验证点2可选——在最早的位置拦截错误最省钱。模型分层的第一性原理是判断力密度不是任务重要性Opus管决策裁决、Sonnet管执行生成、Haiku管路由提取。路由节点是杠杆花Haiku的2秒钟决定哪些执行节点可以降级实测成本降62%、质量还微升。下节预告说到Claude Code里的图应用有一个绕不开的镇宅之宝——/deep-research。它是Anthropic官方内置的深度研究系统是目前公开可见的最完整的Graph工程落地之一。下一节我把它的五个阶段Scope → Parallel Search → Fetch → Adversarial Verify → Synthesize逐层拆开看它的图拓扑、状态管理和并行策略是怎么设计的。这节含金量极高建议先收藏。互动区你们给Verifier的prompt是怎么写的有没有遇到过验证者太宽容什么都给pass的问题我怀疑对抗性prompt的质量比模型选择影响更大想收集一批案例验证这个猜想。如果觉得本文对你有帮助欢迎点赞、收藏、关注三连本系列持续更新中关注不迷路~
