顾问模型和干活模型怎么分工

顾问模式不是团队自己攒的土办法，而是 Anthropic API 里一个正式的 beta 功能，advisor tool。执行模型 Claude Sonnet 5 拿到任务后自己往下做，只有走到需要拿主意的节点，才向顾问模型 Claude Fable 5 请教一次，拿到判断后接着把任务做完。

这不是靠你自己的代码手动发两次请求拼出来的：在 tools 里声明一个 advisor_20260301 类型的工具、指定顾问用哪个模型，剩下的全由 Anthropic 服务器端接管，执行模型像调用普通工具一样决定何时请教，服务器另起一次顾问模型的推理，顾问看到的是执行模型到当前为止的完整对话记录（含系统提示、工具结果、已经写出的内容），给出判断后原样塞回执行模型的对话里，执行模型带着这份建议接着写。全程在同一次 API 请求里完成：

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-8",
        }
    ],
    messages=[{"role": "user", "content": "Build a concurrent worker pool in Go with graceful shutdown."}],
)

模型搭配有硬规则：顾问必须至少和执行模型一样强，不能反过来。文档给的两个典型配法，已经在用 Sonnet 跑复杂任务的，配 Fable 5/Opus 当顾问换质量提升；已经在用 Haiku 但想要更聪明一点的，配 Opus 顾问，成本比把执行模型直接换成大模型低。

原帖配图：Sonnet 5 执行 + Fable 5 顾问在 SWE-bench Pro 上的成绩与成本对比。来源：X / @ClaudeDevs

为什么便宜：顾问的输出通常只有 400 到 700 个文本 token（算上思考过程也就 1400 到 1800 token），它只负责给一句关键建议，不负责把最终答案从头写到尾；账单上，顾问调用按顾问模型的费率单独计入 usage.iterations[]，不会并进执行模型的总数里。原帖里"Fable 5 每个任务仅被罕见调用（约一次）"，说的就是这套省钱逻辑的落地效果。

官方给的最佳实践是：该在动手写之前叫顾问，而不是写完了才回头问。针对 Haiku 执行模型容易"该问的时候没问"的问题，Anthropic 给了一段系统提示模板（提醒模型在写文件、下判断、卡壳时主动请教顾问），在内部编程基准上把 Haiku 的通过率提高了约 7.5 个百分点，这是一个有实测支撑的具体数字，不是泛泛的建议。

另一种分工：不咨询，直接分派任务

顾问模式里 Fable 5 全程不碰活，只在被问到时说一句话；编排模式不一样，Fable 5 一开始就当“编排者”，把任务拆成几块，分派给多个 Sonnet 5“工作者”子代理去并行干，自己只管规划和汇总结果，不亲自动手。

原帖配图：Fable 5 编排者 + Sonnet 5 工作者子代理的分工示意。来源：X / @ClaudeDevs

这套编排能力同样有正式的官方支撑，Claude Managed Agents 的多智能体会话功能。定义一个“编排者”agent 时，用 multiagent 字段声明它能调度的花名册（最多 20 个 agent，只能往下派一层，不能一直嵌套）：

coordinator = client.beta.agents.create(
    name="coordinator",
    model="claude-opus-4-8",
    tools=[{"type": "agent_toolset_20260401"}],
    multiagent={
        "type": "coordinator",
        "agents": [{"type": "agent", "id": research_agent.id}],
    },
)
session = client.beta.sessions.create(agent=coordinator.id, environment_id=environment.id)

每个工作者子代理都在自己独立的“会话线程”里跑，有自己的模型、系统提示、工具配置，彼此互不干扰（最多支持 25 个并发线程）。官方文档总结了三种适合往下派活的场景：并行拆解（同时分头查多个信息源、分析多个文件，编排者最后汇总）、按专长分派（把安全审查、写文档这类活交给对应领域的专精 agent，而不是让一个 agent 什么都干）、能力升级（只把一小部分特别难的子任务，临时升级给更强的 agent 处理）。

Anthropic 官方 cookbook 里有一个具体到能跑的例子，叫“协调者模式”（CMA_plan_big_execute_small.ipynb）：任务是核对 10 个国家公园、共 20 条事实是否与官方信源一致。一个顶级模型独自读完所有网页来核对，和让顶级模型只管拆题、把读网页的苦活派给多个便宜的工作者子代理并行干，效果对比：

官方跑出来的结果：分工团队比单打独斗便宜约 2.5 倍、快约 3 倍。但 notebook 也老实交代了四条踩坑经验，都是实测出来的，不是场面话：

notebook 也给了什么时候不该用这套拆法的判断：如果问题本身信息量小、没多少东西可查，硬拆成编排+工作者只是白付一次编排者的往返成本；如果编排者压根没委派任务、自己凭记忆就答了，等于白花一次顶级模型的钱；如果任务需要顶级模型亲自读懂原始材料里的微妙之处（不是简单核对事实），便宜的工作者子代理可能会在总结时把关键信息弄丢。

原帖配图：Fable 5 编排者 + Sonnet 5 工作者在 BrowseComp 上的成绩与成本对比。来源：X / @ClaudeDevs

为什么重复调用不用重新全额付费

原帖提到"每个子代理都保留自己的缓存"，这句话背后对应两层具体机制，顾问模式和编排模式各有一套。

编排模式这边：每个工作者子代理都跑在独立的会话线程里，线程本身是持久的，编排者过一会儿再回头找同一个工作者追问，那个工作者记得自己之前干过什么、说过什么，不需要把整段历史重新喂一遍才能继续对话。

顾问模式这边有更具体的开关：advisor 工具支持独立的 prompt caching，因为顾问在同一段对话里被多次请教时，它看到的转录内容前缀是稳定的（第 N 次请教＝第 N-1 次的内容后面多一段），开启缓存后，重复的那部分只按缓存命中价计费。官方给的经验值是：一段对话里顾问被叫两次以下，开缓存反而不划算（写缓存的成本比省下来的还高），大概到第三次调用才开始回本，长对话、多轮请教的场景才值得开。

顾问模式还是编排模式，看哪个条件

两种模式都是"让更强的模型少干活、把体力活让给便宜模型"，区别在于强模型到底"要不要接触活本身"。

想试试看，从哪一步开始

两种模式的最小实现都只要三步，挑跟自己场景匹配的那一套先试。

@ClaudeDevs 是 Claude 开发商 Anthropic 面向程序员的官方账号，2026 年 7 月 7 日给了个办法：贵模型只在该拿主意的时候出手，便宜的 Claude Sonnet 5 负责把大量内容写出来。

官方给了两种具体搭法，区别就在贵模型到底要不要碰活本身，一张图看懂。

两种搭法都让贵模型少干活。顾问模式：便宜模型自己往下干，卡在关键判断才问贵模型一句。编排模式：贵模型开头就把活拆成几块，派给几个便宜模型同时干，自己只管拆题和汇总。

官方拿两个公开测试量过账单。把「全程只用最强模型」的花费当作 100 块，看分工后各要花多少、成绩掉多少：

以上数字全部来自 Anthropic 官方自测，没有独立第三方复现。