最近在团队里调 Claude 相关的工作流时一个感受特别明显模型能力确实强但复杂任务一旦放开了跑token 消耗和费用上涨的速度也是真的吓人。尤其是标题里这种“Claude Fable 5.1”之类的顶配模型叫法不管它是某一代官方旗舰还是第三方封装命名大家关心的核心问题其实都一样——怎么在尽量少花钱的前提下把模型的产出质量压到最高这篇文章想分享一套我们实际在用的打法把子代理策略和Gauntlet 循环组合起来用“多角色分工 循环质检”的方式替代过去“一个超级模型从头写到尾”的粗暴调用。文章会从概念讲起给出可在 Claude Code 中运行的示例配置最后附上常见报错和更低成本的工程建议。无论你是个人开发者还是小团队只要正在用 Claude 做编码、评审或自动化流程这篇文章都有参考价值。1. 背景顶配模型的成本压力到底来自哪里先聊一个很现实的问题为什么用 Claude 这类语言模型写代码成本会超出预期第一个原因是按 token 计费。API 模式下输入文本、输出文本、工具返回结果、系统提示词都会折算成 token。表面上你只是在对话框里让模型“看下这段代码”实际上每次调用都会把当前上下文完整算一遍。任务一旦复杂多轮对话累积下来的上下文可能轻松膨胀到几万甚至十几万 token费用自然水涨船高。第二个原因是长上下文陷阱。很多同学习惯把整个项目文件一股脑塞给模型让它在超长上下文里做推理。模型处理能力虽然强但上下文越长单次调用的成本越高而且当任务目标不明确时模型可能输出大量无关分析这些输出同样算钱。第三个原因是反复返工。一次重构任务如果第一版就偏离需求后面所有重试都是额外开销。这就像写代码不写测试上线后再抓 bug修复成本反而更高。顶配模型并不是不能用而是要改变使用方式。正确的思路是不让最贵的模型去做所有事情而是让它做最关键的事情。把信息收集、格式化、初步检查这类“花时间但不烧脑”的活拆给子代理或轻量模型让主模型专注于决策、设计和最终判断。Gauntlet 循环解决的是质量问题每一轮输出都经过自动评审不过关就进入下一轮修复避免低质量结果直接进入下游流程。2. 概念拆解子代理策略与 Gauntlet 循环2.1 什么是子代理子代理Subagent可以理解成一个有“岗位说明书”的独立模型会话。每个子代理只负责一个子任务拥有独立的角色设定、可访问的工具列表和上下文范围。举个例子架构师子代理只读代码输出重构方案。编码员子代理读取方案执行代码修改。评审员子代理读取修改后的代码给出通过或不通过的结论。子代理之间不共享完整对话历史。主代理协调者可以把任务分解后分发给不同的子代理再把结果汇总。这样做的好处有几个上下文隔离每个子代理只看到与自己任务相关的文件片段不会把整个项目历史都塞进同一个上下文。工具权限最小化编码员能写文件评审员只读文件降低误操作风险。便于复用与并行同一个评审员子代理可以被多次调用多个小任务也可以并行处理。在 Claude Code 中子代理可以通过.claude/agents/目录下的 Markdown 文件来定义。不同版本对字段的支持会有差异但基本思路是一致的。2.2 什么是 Gauntlet 循环“Gauntlet” 本意是“严酷考验”Anthropic 在评估模型能力时也用过类似的命名比如那套包含 ARC-AGI-2、HLE 等高难度基准的测试集合。而在本文的工作流里Gauntlet 循环不是官方功能而是一种工作流设计模式把任务拆成可以被自动检查的单元。让子代理执行第一轮产出。用评审子代理或自动化测试对产出进行评分。不通过时把失败项反馈给执行子代理进入下一轮修复。循环直到评分达标或达到最大轮数。听起来很像“写代码—跑测试—修 bug”的 TDD 流程但 Gauntlet 循环更进一步检查对象不只是功能正确性还包括代码风格、边界条件、可维护性、是否偏离原始需求。每一轮循环都会记录失败原因避免同一个问题反复出现。为什么这种循环能省成本因为大多数第一版输出并不完美。如果不设置评审环节直接把这版代码提交给人类使用等到发现问题再整体重来花费的 token 更多。Gauntlet 循环等于把“返工成本”前置到模型内部用便宜的评审调用换取昂贵的主模型调用次数减少。2.3 为什么“子代理 Gauntlet 循环”能低成本榨干模型价值核心在于把成本从“token 总量”转移到“有效产出率”。子代理负责缩小上下文让每一次模型调用都只处理必要的信息。Gauntlet 循环负责质量控制让每一次主模型调用都尽量产生可用结果。评审不通过时修复指令是聚焦的不会让模型从头再读一遍所有代码。这套组合真正改变的是以前你花 100 个 token 得到 30 个有效 token 的产出现在你花 40 个 token 得到 35 个有效 token 的产出。剩下的问题只在“40”和“35”这两个数字怎么调到健康区间。3. 环境准备与工具链3.1 工具选型低成本方案的关键是“不同难度用不同档位的模型”所以我建议按下面方式分配工具用途成本档位Claude Code主调度器与代码任务执行按订阅或 API 用量轻量模型 / 规则脚本关键词过滤、格式校验、简单测试极低Claude 旗舰模型架构设计、关键评审、复杂重构最高必须精打细算如果你已经在使用 Claude Code安装方式通常很简单# 需要 Node.js 环境建议 18 及以上具体以官方最新要求为准 npm install -g anthropic-ai/claude-code安装完成后在项目目录运行claude首次运行会引导你完成登录授权。部分环境可能需要配置代理或 API Key具体请参考官方文档。后续实际使用中可以用/model类指令切换模型档位也可以用/compact压缩上下文具体指令名称以你安装的版本为准。3.2 示例项目结构为了让后面的配置更好理解我们先规划一个最小项目结构your-project/ ├─ .claude/ │ ├─ agents/ │ │ ├─ architect.md │ │ ├─ coder.md │ │ └─ reviewer.md │ └─ settings.json ├─ AGENTS.md └─ src/ └─ legacy.pyAGENTS.md是全局行为规范告诉主代理这个项目的代码标准、工作流步骤和退出条件。.claude/agents/存放自定义子代理定义。.claude/settings.json用来配置权限和钩子。3.3 环境常见坑Claude Code 迭代很快不同版本、不同操作系统下表现可能不同。网上最常见的问题集中在安装阶段我在第 5 章节会专门给出排查表。这里只强调一点在开始搭工作流之前先跑一个最简单的对话确认你的环境能正常完成读文件、写文件等基础操作再往上增加子代理和循环逻辑。4. 完整实战用 Gauntlet 循环做一个代码评审与重构任务这一章我们用一个真实场景来演示整套策略假设项目里有一个遗留函数src/legacy.py它功能能用但结构混乱、缺少边界处理我们希望在不改变外部行为的前提下完成重构并且保证重构质量。4.1 定义子代理角色首先创建架构师子代理。它的职责是分析现有代码输出重构方案但不直接改代码。--- name: architect description: 分析代码结构与需求输出重构方案。适用于代码评审前的任务拆解和改造设计。 tools: Read, Grep --- 你是一名架构师。你的工作流程是 1. 阅读目标文件和关联代码。 2. 分析当前代码的问题包括重复逻辑、过长函数、边界条件缺失、命名不清晰等。 3. 输出重构方案方案必须包含 - 问题清单 - 目标结构 - 改动范围预估 - 需要保留的外部行为说明 约束 - 只做分析和设计不修改任何文件。 - 输出尽量精简避免无关解释。然后创建编码员子代理它负责按方案实施修改。--- name: coder description: 负责按架构方案实现代码修改适合执行具体重构或 bug 修复任务。 tools: Read, Write, Edit, Bash --- 你是一名编码执行者。你的工作流程是 1. 阅读架构师输出的方案。 2. 按方案修改目标文件。 3. 修改完成后列出每个改动的文件与改动原因。 约束 - 只做代码实现不做设计方案调整。 - 如果方案中存在明显错误可以在输出中标记“方案问题”但不要擅自扩大改动范围。 - 修改必须保持外部接口不变。最后创建评审员子代理它负责对修改结果进行严格评分。--- name: reviewer description: 对代码修改进行严格评审给出通过/不通过结论。适用于每次代码修改后的质量门禁。 tools: Read, Grep, Bash --- 你是一名严格评审员。请检查目标代码并输出以下内容 ## 评审结果 - 问题级别致命 / 严重 / 建议 - 问题描述具体到行号或函数名 - 修复建议 ## 最终结论 - 通过 / 不通过 评审标准 - 外部行为是否改变。 - 是否存在明显逻辑漏洞或边界条件遗漏。 - 代码风格是否符合项目规范。 - 重构是否引入新的复杂度。注意不同版本 Claude Code 对子代理 frontmatter 字段的支持可能有差异尤其是tools列表的写法。如果自定义子代理没有被正确加载建议优先检查官方对 Subagents 的文档说明再对照修改。4.2 编写 AGENTS.md 工作流规范AGENTS.md是用来约束主代理行为的关键文件。我们在里面写明 Gauntlet 循环的触发方式。# 项目工作流规范 本项目的代码修改必须经过以下 Gauntlet 循环 1. 主代理先用 architect 子代理分析任务输出重构方案。 2. coder 子代理按方案执行修改。 3. reviewer 子代理对修改结果进行评审。 4. 如果 reviewer 结论为“不通过”把问题清单反馈给 coder 修复然后再次评审。 5. 同一任务的修复循环最多执行 3 轮超过 3 轮仍未通过必须停止并输出人类干预报告。 其他约束 - 所有子代理输出的解释性文字应尽量精简。 - 与任务无关的仓库文件不要读取。 - 不要把完整文件内容重复粘贴到对话中优先使用工具读取。AGENTS.md的核心作用是让主代理不再自由发挥。它把我们的成本控制和质量要求写成了可执行的流程规范。4.3 运行 Gauntlet 循环进入项目目录cd your-project claude然后给主代理下发任务请按照 AGENTS.md 中的工作流对 src/legacy.py 执行一次重构。 背景这个函数目前能工作但存在重复逻辑和边界条件缺失。我们希望在保持外部行为不变的前提下拆分函数并补充必要校验。 请从启动 architect 子代理开始。每一轮修复后都要由 reviewer 完成质量门禁并把评审结果汇总到最终报告里。实际执行过程中主代理会按规范先调用architect拿到方案后交给coder再让reviewer检查。如果评审不通过coder会带着问题清单做下一轮修复。这个过程中上下文被有效隔离每一轮修复只需要读取相关文件和评审报告不需要把完整历史重新加载。4.4 成本估算与观察方法我们不需要依赖官方控制台也可以在方案设计阶段估算一轮 Gauntlet 循环的成本单轮成本 ≈ 输入 prompt token × 输入单价 输出 token × 输出单价 工具返回内容折算 token × 输入单价 系统提示词 token × 输入单价这里的输入单价和输出单价需要以你实际使用的模型和渠道为准不同档位模型差距很大。重点不是算出精确金额而是建立两个意识上下文越大输入成本越高所以要尽量让子代理只读它需要的文件。输出越冗长成本增加越明显所以要约束子代理“输出精简、结论明确”。Claude Code 会在会话中显示用量信息也可以在对应控制台查看历史用量建议每次跑完一个循环任务后都记录一下 token 消耗。只要记录两三次你就能知道当前项目的单次任务预算大概是多少。4.5 运行结果说明一次顺利的 Gauntlet 循环最终报告应该包含这些内容架构师给出的问题清单和目标结构。编码员实际修改的文件列表。评审员的通过结论和遗留建议。如果经历了多轮修复还需要记录每一轮失败原因。这份报告不仅是产出物也是后续审计成本和质量的历史数据。没有记录就没有优化依据。5. 常见问题与排查思路5.1 高频报错排查表问题现象常见原因解决思路claude不是内部或外部命令 / 无法识别npm 全局 bin 目录不在 PATH或安装不完整检查 Node.js 与 npm 是否正常使用npm install -g后确认全局 bin 路径已加入 PATH必要时重装error: claude native binary not installed安装过程中postinstall脚本没有成功执行先卸载再安装检查 npm 权限尝试更新 Node.js 后重装如果还是不行看官方 GitHub issue 中对应操作系统的解法VSCode 插件关闭软件后找不到历史对话会话存储或恢复机制与预期不同尽量使用命令行工具管理长任务查看官方对会话恢复/继续的命令说明子代理没有被调用AGENTS.md或.claude/agents/配置未被正确加载确认文件路径、frontmatter 字段格式用最简单的角色测试一遍循环执行太多轮费用反而升高没有设置最大循环次数和退出条件在AGENTS.md中写死最大轮数超过轮数后转人工处理模型回答越来越慢 / 上下文过长一个会话塞入了过多历史使用/compact压缩上下文或主动开新会话继续任务提示新用户暂时不可用官方风控或区域限制遵守官方服务条款等待官方放开不要通过非正规渠道购买共享账号5.2 子代理配置不生效的排查顺序如果自定义子代理没有被正常加载我建议按下面的顺序排查文件路径是否正确.claude/agents/目录必须和AGENTS.md同级。frontmatter 格式是否完整name、description、tools等字段是否齐全写法是否符合当前版本要求。主代理是否看到角色可以先用一句话让主代理描述当前项目可用的子代理如果描述不出来说明配置没有加载成功。暂不确定的环境逐项替换tools列表排除工具名拼写问题。5.3 一个容易踩的坑Gauntlet 循环 ≠ 无限重试很多同学设置循环后看到模型没有通过评审就机械地让它再来一轮结果费用直接翻倍。Gauntlet 循环的重点是**“失败后给出可执行的修复指令”**不是简单地说“再试一次”。每一轮反馈都要带着具体失败项否则循环次数越多浪费越大。6. 低成本使用的最佳实践与工程建议6.1 按任务难度选择模型档位能交给轻量模型或规则脚本的任务不要使用顶级模型。比如关键词提取、格式校验、简单正则匹配本地脚本处理。文件分类、接口参数翻译轻量模型处理。架构设计、复杂重构评审、疑难 bug 分析才调用顶级模型。这条原则听起来简单但实际项目里非常容易被忽略。很多团队习惯把所有请求都发到同一个旗舰模型费用高且响应慢。正确做法是在入口层做路由分流。6.2 上下文隔离是省钱的第一杠杆每次调用前先问自己这次任务必须看到哪些文件那些文件里又有哪些片段是必要的用子代理配合精确的Read/Grep让模型只接触相关信息。代码仓库里的大段依赖注入、配置模板、历史注释不应该作为无关内容进入上下文。6.3 压缩工具链输出工具调用返回的内容同样折算 token。比如Bash执行测试时输出了一大段日志这些日志会被塞进上下文。可以在子代理定义中约束工具输出截断让模型只关注关键部分。如果用的是 Claude Code 这类工具务必关注它对工具返回内容的截断机制。6.4 权限与安全边界生产环境使用子代理时务必给每个角色分配最小工具权限能只读就不给写权限。能写单个文件就不给全仓库写权限。能跳过 Bash 就不给执行权限。同时API Key 或登录凭证绝对不能写入项目文件、提交到 Git 仓库。如果代码中需要引用密钥优先使用环境变量或专用的密钥管理工具并定期轮换。6.5 把质量门禁前置到 CI除了在模型内部做 Gauntlet 循环也可以把检查环节放进 CI 脚本先跑静态检查和单元测试。如果静态检查失败直接通知开发者不调用顶级模型。只有基础检查通过的任务才进入模型重构或评审流程。这里要用合规的方式操作自有代码仓库不要把 CI 流程和账号体系混在一起。质量门禁的意义在于把“模型评审”作为人工评审的前置过滤而不是替代一切测试。6.6 建立用量与质量双看板成本优化不能只盯着 token 总量。建议每次任务记录四个数据指标说明任务类型重构 / 代码评审 / 文档生成 / bug 修复输入 token 量反映上下文控制是否到位输出 token 量反映模型是否出现啰嗦输出评审通过轮数反映初始提示词质量和任务拆解水平每周末回看一次你会发现有些任务明明可以用轻量模型完成却因为默认配置被送进了顶级模型有些子代理的定义太模糊导致输出废话多。这些优化空间只看总账单是发现不了的。7. 总结与实践建议Gauntlet 循环和子代理策略并不是什么黑科技它本质上是把工程里的“角色分工”和“质量门禁”迁移到了模型调用层。子代理负责缩小上下文循环负责拦截低质量输出两者组合之后顶级模型的每一次昂贵调用都尽量落在关键路径上。如果你想在项目里快速落地我建议从一个小任务开始而不是直接串联完整流程。比如先定义architect和reviewer两个子代理跑一次代码分析任务观察 token 消耗和输出质量。跑通之后再加入coder和循环逻辑逐步扩展。这样即使中间配置出了问题也容易定位。最后留一个思考题给你当你下一次准备让 Claude 执行任务时有多少上下文是真正必要的又有多少次“再试一次”其实应该被替换成更具体的失败反馈把成本优化当成工程质量问题来对待而不是单纯的省钱技巧这套思路在任何一代 Claude 模型上都值得长期使用。