three-man-team进阶技巧：如何为三个Agent分配不同的Claude模型以平衡能力与成本

three-man-team 是一个结构化的三 Agent AI 开发团队框架，内置 Architect、Builder、Reviewer 三个角色，支持 Claude Code、VS Code、Cursor 等环境。本文讲解如何为这三个 Agent 分别指定不同的 Claude 模型，在能力与成本之间取得最佳平衡。

为什么三个Agent不该用同一个Claude模型

three-man-team 的核心理念是：三个角色，三种职责。Arch（Architect）负责规划和部署，Bob（Builder）负责写代码，Richard（Reviewer）负责把关质量。

三个角色的"脑力需求"完全不同：

• Arch需要理解整个系统、做架构决策、把控部署——需要最强的推理能力
• Bob只需按 Brief 精确构建，任务边界清晰——中等能力即可
• Richard的输入是 Bob 列出的具体文件清单，审查范围有限——快速模型完全够用

如果三个 Agent 全部跑在最强模型上，你为大量"低难度任务"支付了最高价格。而反过来，用便宜模型跑 Architect，又会在最关键的设计环节翻车。按角色分配模型，是 three-man-team 成本优化的进阶关键。

三种可用Claude模型ID速查

three-man-team 官方文档（自 v1.2.0 起支持按 Agent 指定模型）提供了三个模型 ID：

这三个 ID 在 templates/project-folder/new-setup.md 中有明确说明，Arch 在首次配置时会直接问你这个问题。

四套推荐搭配方案

根据项目类型选择方案，默认推荐第一套（也是项目文档给出的示例组合）：

选择原则：Arch 的模型决定项目上限，Bob 的模型决定交付速度，Richard 用更快的模型几乎不影响审查质量——因为他的输入范围（Bob 列出的文件 +git diff）本身就很小。

三种配置方式实操

方式一：首次设置时直接告诉 Arch（最推荐）

three-man-team 的初始化流程 templates/project-folder/new-setup.md 内置了第 4 个配置问题：

4. Agent models (optional)— 默认 Bob 和 Richard 使用你当前会话激活的模型。如果你想为每个 Agent 指定不同模型（比如 Opus 给 Arch、Sonnet 给 Bob、Haiku 给 Richard），现在告诉我就行。

你只需回答"Opus for me, Sonnet for Bob, Haiku for Richard"，Arch 会自动做两件事：

1. 把每个 Agent 的目标模型以注释形式写入 ARCHITECT.md 的 Briefing 区域，紧跟在对应 Agent 的启动提示词上方，形成持久记忆
2. 之后每次通过 Agent 工具启动子 Agent 时，自动带上model参数

方式二：启动子Agent时传递model参数

three-man-team 采用"单会话 + 子 Agent"模式：Arch 是主 Agent，Bob 和 Richard 由 Arch 通过 Claude Code 的 Agent 工具按需启动。因此模型分配发生在启动子 Agent 的那一刻——在 Agent 工具调用中传入model: "[model-id]"即可，例如：

Agent( prompt: "You are Bob on this project...", model: "claude-sonnet-4-6" )

这个机制写在 templates/project-folder/ARCHITECT.md 的 "Briefing Bob" 和 "Briefing Richard" 两节，generic 模板 templates/generic/ARCHITECT.md 中同样有对应说明。

方式三：手动粘贴提示词前切换模型

如果你不用 Agent 工具、而是手动把 Agent 提示词粘贴到新会话，那么只需在粘贴前切换到目标模型即可。三种方式效果等价，选顺手的。

注意默认行为：不做任何配置时，所有 Agent 都继承当前会话的模型。也就是说，如果你日常会话用 Sonnet，那么 Bob 和 Richard 也默认跑 Sonnet——这通常比全 Opus 省得多，但比推荐搭配略贵。

模型分配只是成本优化的一半

three-man-team 把 token 纪律写进了结构而非口号，模型分级要和 token 优化配合才有复利效应：

• Role-Scoped Loading（按角色加载）：Builder 从不加载完整项目规格，Reviewer 从不加载数据库 schema，每个角色只读自己职责内的文件
• Checkpoint-First（检查点优先）：用handoff/SESSION-CHECKPOINT.md替代重读完整日志
• RTK（可选）：压缩find、ls、grep的 bash 输出，通常再省 50-70% 的 bash 输出 token

完整的 token 纪律见 docs/token-optimization.md。模型分配管"用哪个大脑思考"，token 优化管"少思考多少"——两者叠加才是完整的成本控制。

常见问题

改了模型分配后怎么确认生效？在会话中让 Arch 展示下一次启动 Bob / Richard 的 Agent 调用，确认model参数已带上即可。Arch 会在 ARCHITECT.md 中留有注释备忘，不会每次会话都"忘记"你的偏好。

项目类型变了，要换搭配吗？可以随时换。重新告诉 Arch 新的模型组合，它会更新 ARCHITECT.md 中的注释；或者临时在某次 Agent 调用里直接传不同的model参数，只影响那一次启动。

为什么不是三个都用 Opus？能力过剩的 Agent 不会让产出更好，只会让账单更贵。three-man-team 的 Reviewer 环节本身已经保证了质量下限——Richard 不过关的工作打回重做。所以把 Opus 集中在 Architect 这一个"决策源头"上，是性价比最高的分配方式。

小结：three-man-team 的模型分配机制通过 new-setup.md 的第 4 个配置问题、ARCHITECT.md 中的model参数注释、以及 Agent 工具调用的model参数三层落地。记住一句话：Opus 规划、Sonnet 构建、Haiku 审查——能力给该给的地方，成本花在刀刃上。