面对 GPT-6 家族,真正困难的通常不是“调用哪个模型”,而是如何把模型、推理强度、提示词、技能和外部工具组合成一条成本可控、结果可测、失败可恢复的工作流。对创业团队而言,最稳妥的做法不是让最强模型处理所有请求,而是先划分任务,再把额外算力留给真正需要复杂判断的环节。
下文使用
fast、balanced、deep表示三种模型角色,并不假设它们是官方型号。接入时应替换为供应商实际提供的 GPT-6 模型名称和 API 字段。
不按“强弱”选模型,而按失败成本分流
同一产品里的任务差异很大。分类、改写和字段抽取通常边界明确;多文档分析、复杂代码修改或高风险决策则需要更多推理。可以先建立三档路由:
| 任务档位 | 典型任务 | 推荐角色 | 主要目标 |
|---|---|---|---|
| 低复杂度 | 分类、摘要、格式转换、意图识别 | fast | 低延迟、低成本 |
| 中复杂度 | 客服回复、常规代码生成、单文档分析 | balanced | 质量与成本平衡 |
| 高复杂度 | 多步骤规划、复杂调试、跨文档推断 | deep | 提高复杂任务成功率 |
路由条件应尽量使用可观测信号,而不是让模型凭感觉决定是否升级,例如:
- 输入长度和附件数量;
- 是否要求调用工具;
- 是否涉及付款、权限、法律或生产环境变更;
- 第一次生成是否未通过格式校验或事实检查;
- 用户是否明确要求深入分析。
一种实用策略是“默认便宜,失败升级”:先用较快模型处理,只有在结构校验失败、置信度不足或评审器拒绝时,才切换到更强模型。需要注意,高风险操作不应先执行再升级;它们应直接进入强模型与人工审批路径。
推理强度是一项预算,不是越高越好
如果接口支持 reasoning effort 一类参数,可以把它理解为每次请求的计算预算。简单抽取任务使用高推理强度,往往只会增加延迟和费用;复杂规划使用过低预算,则可能产生遗漏步骤、错误工具参数或过早下结论。
可以把任务与推理预算绑定:
# model-policy.yaml
routes:
extraction:
model_role: fast
reasoning_effort: low
max_retries: 1
customer_reply:
model_role: balanced
reasoning_effort: medium
max_retries: 1
production_change:
model_role: deep
reasoning_effort: high
human_approval: true
max_retries: 0
这份配置的价值不只在于路由。它还能让产品、工程和财务团队讨论同一组约束:哪些请求值得更高成本,哪些失败可以重试,哪些动作必须停下来等人确认。
评估时不要只看平均响应质量。至少同时记录:
- 任务成功率,而非仅记录请求成功率;
- P50、P95 延迟;
- 每个成功任务的成本;
- 首次通过率与升级率;
- 工具调用错误率;
- 人工接管比例。
把提示词、技能和工具拆成独立组件
长提示词很容易变成难以维护的“规则仓库”。更好的方式是将其拆成三层:
- 稳定契约:角色、边界、输出格式和禁止事项;
- 任务指令:本次请求要解决的问题;
- 技能资产:可版本化的领域流程、示例和检查清单。
例如,一个客服退款技能可以写成独立文件:
技能:refund-review/v3
目标:判断退款请求是否满足政策,并生成给客服人员的建议。
流程:
1. 读取订单状态,不得猜测。
2. 检查购买时间、商品类型和退款窗口。
3. 缺少字段时返回 needs_more_information。
4. 只生成建议,不直接执行退款。
5. 输出 JSON:decision、reason、missing_fields、recommended_action。
技能版本应和评测结果一起保存。修改退款规则后,可以针对历史案例重放 v2 与 v3,而不是凭几次人工试用判断新提示词是否更好。
工具编排也要遵循最小权限原则。读取订单和执行退款不应是同一个工具;建议采用 read_order、prepare_refund、commit_refund 三段式设计。模型可以读取信息并准备操作,但真正产生副作用的 commit_refund 需要确定性校验、幂等键,必要时还要人工批准。
一个可改造的模型路由器
下面的 Python 脚本默认只打印请求,因此可以直接运行。设置 LIVE=1 后,它会向配置的 HTTP API 发送请求。示例假设服务接受 model、input 和 reasoning_effort 字段;实际字段应根据所用 GPT-6 API 文档调整。
#!/usr/bin/env python3
import json
import os
import sys
import urllib.request
MODELS = {
"fast": os.getenv("GPT6_FAST_MODEL", "replace-with-fast-model"),
"balanced": os.getenv("GPT6_BALANCED_MODEL", "replace-with-balanced-model"),
"deep": os.getenv("GPT6_DEEP_MODEL", "replace-with-deep-model"),
}
def choose_route(task: str, text: str) -> tuple[str, str]:
high_risk_words = ("production", "payment", "permission", "delete", "生产", "付款", "权限", "删除")
complex_words = ("compare", "debug", "plan", "比较", "调试", "规划")
if task == "production_change" or any(word in text.lower() for word in high_risk_words):
return "deep", "high"
if len(text) > 4000 or any(word in text.lower() for word in complex_words):
return "balanced", "medium"
return "fast", "low"
def build_request(task: str, text: str) -> dict:
role, effort = choose_route(task, text)
return {
"model": MODELS[role],
"reasoning_effort": effort,
"input": [
{
"role": "system",
"content": (
"Return JSON with keys answer, confidence, and needs_review. "
"Do not claim that an external action succeeded unless a tool result confirms it."
),
},
{"role": "user", "content": text},
],
"metadata": {"task": task, "model_role": role},
}
def send(payload: dict) -> dict:
if os.getenv("LIVE") != "1":
return {"dry_run": True, "request": payload}
url = os.environ["GPT6_API_URL"]
api_key = os.environ["GPT6_API_KEY"]
request = urllib.request.Request(
url,
data=json.dumps(payload).encode("utf-8"),
headers={
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json",
},
method="POST",
)
with urllib.request.urlopen(request, timeout=60) as response:
return json.loads(response.read().decode("utf-8"))
if __name__ == "__main__":
task = sys.argv[1] if len(sys.argv) > 1 else "customer_reply"
text = sys.argv[2] if len(sys.argv) > 2 else "Summarize this customer request."
print(json.dumps(send(build_request(task, text)), ensure_ascii=False, indent=2))
先以 dry-run 模式检查路由:
python3 gpt6_router.py customer_reply "总结用户的问题并列出缺失信息"
python3 gpt6_router.py production_change "删除生产环境中的旧索引"
确认实际接口格式后,再替换模型名并启用真实请求:
export GPT6_FAST_MODEL="实际的快速模型名"
export GPT6_BALANCED_MODEL="实际的均衡模型名"
export GPT6_DEEP_MODEL="实际的深度推理模型名"
export GPT6_API_URL="https://your-provider.example/v1/responses"
export GPT6_API_KEY="your-api-key"
export LIVE=1
python3 gpt6_router.py customer_reply "为延期订单生成回复草稿"
生产代码还应增加超时分类、指数退避、响应结构校验、请求 ID、用量记录和敏感信息过滤。不要对产生副作用的工具调用进行无条件自动重试,否则可能重复扣款、重复发信或重复修改资源。
上线前,把工作流当成系统而不是一次调用
GPT-6 家族能否稳定落地,最终取决于模型之外的工程措施。上线前可以逐项检查:
- 是否为每类任务指定了默认模型、推理强度和升级条件;
- 是否用固定测试集比较质量、延迟和单次成功成本;
- 提示词与技能是否有版本号、负责人和回滚方式;
- 工具参数是否经过服务端校验,写操作是否支持幂等;
- 高风险动作是否需要人工批准;
- 日志是否记录路由结果、工具结果和失败阶段,同时避免泄露敏感数据;
- 模型不可用或超预算时,是否有降级路径。
创业团队不必一开始就构建复杂的多智能体平台。一个明确的任务分类器、一份可审查的模型策略、少量权限清晰的工具,再加上一套持续回放的评测集,通常比“所有请求都交给最强模型”更容易控制,也更适合逐步进入生产环境。