Claude Advisor Tool：省钱又稳的“关键时刻问老师”打法

你肯定遇到过这种尴尬：

• 客服/助手/总结类任务，用 Sonnet 跑挺香，便宜。
• 一碰到复杂推理、规则密集、容易踩坑的场景（合同条款、金融口径、代码边界、长链路工具调用），Sonnet 就开始“自信胡说”。
• 你一狠心换 Opus：效果是好了，API 账单也开始教育你做人。

Advisor Tool 就是冲着这个矛盾来的：让便宜模型干活，贵的模型只在关键节点给“指导意见”，不直接对用户说话。

这招像什么？像你写方案，平时自己写，写到最关键那页去敲导师门：

“老师你帮我看下这个结构对不对？风险点有哪些？要不要刹车？”

然后你拿着建议继续写完交稿。

Advisor Tool 到底解决什么问题？

开发里最常见的两难：

• 全程 Opus：质量稳，但贵。
• 全程 Sonnet：成本低，但容易翻车，尤其是“看起来像对的错答案”。

Advisor Tool 让你走第三条路：

• Sonnet 负责执行、写输出、走流程（也就是你真正给用户看的内容）。
• Opus 只在需要时当顾问，给 Sonnet 一个“建议包”。
  • 可能是一份更靠谱的计划
  • 可能是对当前推理的纠错
  • 也可能是一个强硬的信号：停！别继续编了，信息不够/风险太高

关键点在这：

• Opus 不调用工具（避免它自己乱跑）
• Opus 不直接面向用户输出（避免你出现“双模型口径不一”的灾难）
• 你也不需要搞复杂的任务拆分、worker pool、编排 DAG

一句话：把“前沿推理能力”当成稀缺资源，只在刀刃上用。

适合用 Advisor Tool 的场景（很具体）

1）客服/销售助手：话术要稳，合规要命

Sonnet 平时跟用户聊得飞起。 遇到这些情况就该“问顾问”：

• 用户问退费/合同/赔付边界
• 用户描述含糊，Sonnet 准备脑补
• 用户在诱导越权（要内部数据、要绕过规则）

Advisor 给一句：

• “你可以这样问 3 个澄清问题”
• “这里属于高风险承诺，禁止做出保证”

你就能少背很多锅。

2）代码生成：平时能写，边界条件容易炸

Sonnet 写 CRUD、写脚手架很快。 一到这些地方就容易翻车：

• 并发、锁、事务
• 安全（鉴权、注入、密钥）
• 性能（N+1、索引、缓存一致性）

Advisor 适合干的事：

• 提醒潜在漏洞
• 给出更靠谱的实现路线
• 让 Sonnet 补上测试用例思路

3）内容生产：大部分是体力活，少部分是智力活

比如你写一篇教程：

• 80% 是结构、表达、示例（Sonnet 就行）
• 20% 是关键观点、结论推导、避坑点（请 Opus 指点一下）

一个好用的接入思路：让 Sonnet 自己决定“要不要请教”

你不想手动写一堆 if else，对吧？

可以让 Sonnet 在输出前做一次自检，判断是否需要 Advisor：

• 信息是否足够？
• 有没有高风险承诺？
• 这段推理有没有跳步？
• 用户要求是否和政策/合规冲突？

自检结果给一个简单标记：

• NEED_ADVICE = true/false
• reason = ...
• what_to_ask = ...

如果需要，再调用 Advisor（也就是 Opus 顾问）。

然后把 Advisor 的建议塞回 Sonnet，让 Sonnet 继续完成最终输出。

这个流程的手感就是：

Sonnet：我能不能直接答？不确定。

Opus（顾问）：你这题有两个坑，别直接承诺，先问用户三件事。

Sonnet：收到，我去问清楚再答。

极简流程图（建议你就按这个做）

1. Sonnet 生成草案 + 自检标记
2. 如果不需要请教：直接把 Sonnet 输出给用户
3. 如果需要请教：调用 Advisor（Opus）拿建议
4. 把建议交还给 Sonnet，让它修正/补问/改写
5. Sonnet 输出最终结果

示例：用“建议包”约束 Advisor 的输出格式

你要控制 Opus 的输出，否则它一兴奋就写成长文论文。

建议让 Advisor 只输出结构化建议，比如：

• plan：下一步怎么做
• risks：风险点
• stop_signal：是否需要叫停
• questions：需要问用户的澄清问题

像这样（示例格式）：

{
  "stop_signal": false,
  "plan": [
    "确认用户的目标与约束",
    "列出可行方案并标注风险",
    "给出推荐方案与执行步骤"
  ],
  "risks": [
    "用户信息不足导致误判",
    "存在合规/承诺风险"
  ],
  "questions": [
    "你所在地区/合同条款是哪一版？",
    "你要的结果更偏向省钱还是省时间？"
  ]
}

然后 Sonnet 拿着这个 JSON 去“落地成给用户看的话”。

伪代码：把 Advisor 插进现有 Claude 调用（Node/Python 都能照抄思路）

说明：不同版本 SDK/接口字段可能有差异，字段名按你项目里的实际 Claude API 来。思路别变就行。

Step A：Sonnet 先跑一遍，产出草案 + 自检

const draft = await claude.messages.create({
  model: "claude-sonnet",
  messages: [
    { role: "user", content: userInput },
    { role: "system", content: "输出两段：1)给用户的草案 2)自检JSON: {need_advice, reason, what_to_ask}" }
  ]
});

const { userDraft, selfCheck } = parseDraft(draft);

if (!selfCheck.need_advice) {
  return userDraft;
}

Step B：需要请教时，调用 Advisor（Opus 当顾问）

const advice = await claude.messages.create({
  model: "claude-opus",
  // 这里用 Advisor Tool / 或你环境中对应的“顾问”调用方式
  // 核心是：让 Opus 只给建议，不直接写最终回复
  messages: [
    { role: "system", content: "你是顾问，只输出JSON建议包，不要写给用户看的成文。" },
    { role: "user", content: JSON.stringify({
        userInput,
        sonnetDraft: userDraft,
        reason: selfCheck.reason,
        whatToAsk: selfCheck.what_to_ask
    }) }
  ]
});

const advicePack = JSON.parse(extractText(advice));

Step C：把建议喂回 Sonnet，让它完成最终输出

const finalAnswer = await claude.messages.create({
  model: "claude-sonnet",
  messages: [
    { role: "system", content: "根据顾问建议修正输出。顾问说停就改为澄清提问，不要硬答。" },
    { role: "user", content: userInput },
    { role: "assistant", content: userDraft },
    { role: "user", content: `顾问建议(JSON)：${JSON.stringify(advicePack)}` }
  ]
});

return extractText(finalAnswer);

你会发现：逻辑很短，接入成本很低。

成本怎么省出来的？给你一个直观算法

你不需要精确到小数点，抓大头就够用：

• 大部分请求：Sonnet 一次就过 → 你付 Sonnet 的钱
• 少部分“高风险/高难度”请求：Sonnet + Advisor(Opus) + Sonnet → 多付一次顾问费

关键在“少部分”这三个字。

一个实战小建议

把 Advisor 触发率控制在 5%~20% 区间，通常就很舒服。

• 低于 5%：你可能没真正用到刀刃
• 高于 20%：说明你的任务本质就需要更强模型，别硬省，直接提高 Sonnet 的约束或改用更强主模型

让触发更聪明：3 个常用触发策略

1）基于“风险关键词/意图”触发

适合客服、合规、金融。

• 退款、赔偿、保证、合同、法律、处方、投资建议
• 绕过规则、要隐私数据

命中就请教。

2）基于“自信度/不确定性”触发

让 Sonnet 自己打分：

• confidence: 0-100
• need_advice: confidence < 70

再配合规则：低自信 + 高风险 → 必请教。

3）基于“输出校验失败”触发

适合结构化输出场景：

• JSON 解析失败
• 关键字段缺失
• 单元测试/校验规则没过

没过就请教 Advisor，让 Opus 给修复策略。

避坑清单（这几条踩中就会很痛）

• 让 Opus 直接对用户输出：你会得到两套口径，产品像人格分裂。
• 顾问建议太长：token 像漏水一样流走。给 Advisor 严格格式，最好 JSON，字段越少越好。
• Sonnet 不服管：系统提示里写清楚，“顾问 stop_signal=true 就必须改为澄清问题/拒答”。
• 每次都请教：那你就是换了个方式用 Opus，省钱就别想了。
• 没做日志：你无法优化触发率。至少记录 need_advice、触发原因、顾问建议长度、最终是否被用户追问。

一套你可以直接抄的提示词（精简版）

给 Sonnet 的 system（自检版）

你要输出两部分：
A) 给用户看的回复草案。
B) 自检JSON：{need_advice:boolean, reason:string, what_to_ask:string}
当存在高风险承诺、信息不足、复杂推理、可能越权/合规问题时，把 need_advice 设为 true。

给 Advisor（Opus）的 system（只给建议）

你是顾问。你不直接写给用户看的内容。
只输出JSON：{stop_signal:boolean, plan:string[], risks:string[], questions:string[]}
内容要短，最多10条。

给 Sonnet 的 system（融合建议版）

你负责最终输出给用户。
必须遵守顾问JSON：stop_signal为true时，改为澄清提问或拒绝，不要继续硬答。
把 plan/risks 转成用户能看懂的表达。

你现在就能做的落地清单

• 把现有的 Sonnet 调用包一层：加“自检 JSON”。
• need_advice 为 true 时走 Advisor 调用。
• Advisor 输出严格 JSON，别让它写长文。
• 把建议回灌给 Sonnet，统一由 Sonnet 面向用户。
• 做日志：触发原因、触发率、建议长度、用户是否满意。

做到这一步，你会明显感觉：

• 平时成本还是 Sonnet 的成本
• 关键问题翻车率下去
• 用户追问和投诉变少（这东西比省 token 更值钱）

如果你愿意贴一下你现在的业务场景（客服？代码？内容？还是工具调用链？）和你用的 SDK 语言，我可以给你把“触发规则 + 提示词 + 日志字段”按你的场景定制成一套更贴手的版本。😉