将我的智能体拆分为廉价路由模型和高级合成模型，费用降低了约75%

我一直在为我们团队（5人，B2B销售场景）构建一个内部信息丰富智能体。它接收一个公司名称列表，并用公开信息对其进行丰富，然后我们的外联人员再进行处理。大约集成了8个工具。常见的工具包括：网络搜索、爬取、内部向量数据库查找、与CRM去重、按ICP匹配度分类、草拟简短的外联段落，以及几个用于处理边缘情况的粘合工具。当我首次让它运行时，所有请求都使用了gpt-5.4，因为那是我的初始设置。运行良好，但费用惊人。第一周处理了约1200家公司，花费约290美元。如果按照销售人员实际想要的量（接近每周5000家），这个成本无法扩展。我仔细查看了日志，费用分解让我大吃一惊。大约75%的LLM调用是我所谓的“路由”调用。根据当前状态、可用工具和上一个工具结果，选择下一个动作。这些调用的输出很小（一个工具名称加一个JSON参数块），其实不需要5.4级别的推理能力。它们只需要便宜、快速，并且足够聪明以避免选择错误的工具。剩下的25%是“合成”调用：总结抓取的页面、草拟段落、推理证据是否真正匹配我们的ICP。这些调用受益于真正的模型。我将架构改为：路由使用GPT-OSS 120B（通过兼容OpenAI的端点，我在GMI Cloud上，其他几个供应商也有类似定价），合成仍然使用gpt-5.4。SDK对此没有特别关注，只需要根据调用位置传递不同的base_url和模型字符串。本周处理了约1400家公司的数据：总费用约65美元。因此，在吞吐量略有提高的情况下成本降低了约78%。最终输出的质量对我们的销售人员来说感觉相同。在完全切换之前，我们并行运行了50家公司进行验证。需要修复的几个问题：1. GPT-OSS 120B的工具调用JSON大部分是干净的，但偶尔会留下一个尾随逗号。对解析做了清理。2. 默认的max_tokens是4096，即使我只想要一个工具选择，模型也乐于填充推理通道。将路由调用的max_tokens降至256，并收紧提示。3. 每次路由调用的延迟平均比5.4慢100-200毫秒，但吞吐量没问题，因为路由不在面向用户的临界路径上。如果您的智能体大多数调用是工具选择决策而非合成，那么这种拆分可能是最大的单一收益。将它们分开后，我们从“无法扩展”变成了“扩展性很好”，而无需更改其他任何东西。我仍在思考的是，GPT-OSS 120B对于路由任务来说是否真的是合适的规模，还是可以进一步降至30B左右的模型以节省更多？随着注册的工具增多，质量可能会下降，我还没有实际测试过。