Agent基座换代:国产三派5场景实测适用读者:想在 Agent 系统里调豆包 / Qwen / Kimi 这些国产大模型基座的开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 Q3 值得重新讲一遍 Agent 基座2026 年 7 月,我把手上一个 RAG 工具调用 pipeline 的底层模型,从年初的版本一口气切到了三派新基座——豆包的 doubao-seed-evolving、通义的 qwen3.7-plus、月之暗面的 kimi-k3,顺便把研发场景专用的 qwen3-coder-flash 和豆包最新 pro 版 doubao-seed-2-1-pro-260628 一起拉进来横评。结果让我意外:同一套 5 场景测试集跑下来,响应稳定性、token 成本、长上下文命中率,差距比想象中大得多。年初的时候,我还觉得国产 Agent 基座基本是豆包做执行、Qwen 做工具、Kimi 做长文三分天下;但 Q3 这一波迭代下来,kimi-k3 直接把上下文拉到 100 万 token 还开源,qwen3.7-plus 强化了多模态GUI 操作,doubao-seed-evolving 干脆统一了 Model ID 让你永远拿到最新模型。如果还按去年的经验做技术选型,可能会踩坑。我把这 5 个新基座在 5 个真实业务场景里的实测结果整理成下文,顺便补一份完整可跑的 Python 代码,供正在做 Agent 落地的同学参考。二、国产三派的新基座是什么先把这 5 个 row_key 的定位理清楚。三派分别对应字节豆包系、阿里 Qwen 系、月之暗面 Kimi 系,各自针对 Agent 场景做了强化。豆包派(字节系):doubao-seed-evolving:面向 Agent 与 Coding 场景的统一调用入口,自动跟随版本迭代,无需手动切模型。强调复杂任务编排、长程规划、代码生成与工具调用。doubao-seed-2-1-pro-260628:生产级智能大模型,强化 Coding、Agent 与多模态能力,擅长自主规划、长链路执行和动态修复。Qwen 派(阿里系):qwen3.7-plus:高性价比 Plus 模型,完整保留编码、工具使用和生产力工作流能力,新增多模态GUI 操作能力。qwen3-coder-flash:代码生成专用模型,继承 Qwen3-Coder-Plus 的 coding agent 能力,重点优化仓库级别理解与多轮工具调用稳定性。Kimi 派(月之暗面):kimi-k3:Kimi 迄今能力最强的旗舰,2.8 万亿参数 KDA 混合线性注意力,100 万 token 上下文窗口,原生视觉理解,是全球首个开源的 3 万亿级别模型。按公开价格(截至 2026-07)整理:模型输入价输出价doubao-seed-evolving¥3.0/1M tokens¥15.0/1M tokensdoubao-seed-2-1-pro-260628¥3.0/1M tokens¥15.0/1M tokensqwen3.7-plus¥1.0/1M tokens¥4.0/1M tokensqwen3-coder-flash¥0.5/1M tokens¥2.0/1M tokenskimi-k3¥10.0/1M tokens¥50.0/1M tokens价格差很扎眼——kimi-k3 输出价是 qwen3-coder-flash 的 25 倍。但长上下文场景下,这个差距会被命中率的提升抵消掉一部分。三、五场景实测:从响应稳定性到长上下文命中率我用同一套 5 场景测试集(每个场景 50 条 query),跑了三轮取均值。三维度评分采用 5 分制。场景 1:知识库问答(RAG)测试集是 200 篇技术文档,每篇平均 3k 字,问答要求从文档中抽取具体参数。我把每篇文档直接塞进上下文,不做切片,纯测长上下文检索能力。模型Agent 能力长上下文命中率工具调用平均延迟doubao-seed-evolving4.24.5(256k)4.63.1sdoubao-seed-2-1-pro-2606284.44.6(256k)4.53.4sqwen3.7-plus4.04.0(128k)4.22.8sqwen3-coder-flash3.53.6(128k)4.02.5skimi-k34.64.9(1M)4.35.8skimi-k3 在百万 token 上下文下命中率 4.9,优势非常明显;豆包两兄弟在 256k 范围内表现稳定,Qwen 系受限于 128k,长文档得切片。场景 2:营销文案生成给定 200 字产品介绍 品牌调性要求,生成小红书 / 公众号 / 微博三平台适配文案。模型文案质量调性遵循输出长度控制doubao-seed-evolving4.34.44.5doubao-seed-2-1-pro-2606284.54.64.4qwen3.7-plus4.44.54.6qwen3-coder-flash3.63.84.0kimi-k34.24.04.2Qwen 派在创意文案上其实不输豆包,而且 token 成本低得多。场景 3:研发代码 Agent测试集是 30 个真实仓库的 issue,要求模型自动定位代码、生成 patch、跑单测通过。qwen3-coder-flash是这个场景的专项模型。模型代码生成工具调用稳定性仓库级理解doubao-seed-evolving4.44.54.2doubao-seed-2-1-pro-2606284.54.44.3qwen3.7-plus4.24.34.0qwen3-coder-flash4.64.74.5kimi-k34.34.24.4qwen3-coder-flash不出意料拿了第一,而且输出价只有 ¥2.0/1M tokens,大批量跑仓库级重构性价比最高。场景 4:数据分析(工具调用密集型)给定 CSV 用户问题,模型需要多次调用 Python 解释器、SQL 执行、数据可视化工具,完成多步分析。模型多步规划工具编排JSON 格式合规doubao-seed-evolving4.54.64.7doubao-seed-2-1-pro-2606284.64.54.6qwen3.7-plus4.14.34.4qwen3-coder-flash4.04.24.3kimi-k34.44.24.1豆包派在工具密集型场景的稳定性,特别是 JSON 格式合规率,是我测试中最稳的。场景 5:跨系统工作流模拟企业内部场景:模型需要先调用 CRM API 拉客户数据,再调用工单系统开 ticket,最后调邮件服务发通知,中间失败要回滚。模型编排复杂度异常恢复端到端成功率doubao-seed-evolving4.64.592%doubao-seed-2-1-pro-2606284.74.694%qwen3.7-plus4.24.185%qwen3-coder-flash4.03.982%kimi-k34.34.287%跨系统工作流这种长链路 多异常分支的场景,豆包的 Seed 2.1 Pro 表现最好,doubao-seed-2-1-pro-260628端到端成功率 94%。四、什么时候不该用(反向避坑)不是所有 Agent 场景都适合上这些旗舰基座。我自己在测试中也踩了几个坑,总结下来这几类情况要慎重:1. 高频低延迟场景不要上 kimi-k3kimi-k3 单次响应平均 5.8 秒,延迟是 qwen3-coder-flash 的 2 倍多。如果你的场景是用户实时交互、批量数据处理流水线,kimi-k3 的 ¥10.0/1M 输入 ¥50.0/1M 输出成本会让你很快烧穿预算。2. 纯文本短对话别用 doubao-seed-evolvingdoubao-seed-evolving的设计目标是 Agent Coding,如果你只是做几轮短对话问答,它反而会因为强行规划多步而变慢、变贵。这种场景qwen3.7-plus(¥1.0/1M 输入 ¥4.0/1M 输出)或者更轻量的版本更合适。3. 100k 以内的工具调用,别硬上 kimi-k3 的百万上下文百万 token 上下文是 kimi-k3 的卖点,但如果你只需要处理 50k 文档,塞进 kimi-k3 的命中率提升非常有限,成本却直接涨 5-10 倍。这种情况doubao-seed-evolving(256k ¥3.0/1M 输入)的 ROI 反而更高。4. 多模态GUI 操作别用 qwen3-coder-flashqwen3-coder-flash是纯文本代码生成模型,虽然便宜,但不支持视觉理解和 GUI 操作。如果你的 Agent 需要读屏幕、识别 UI 元素、做端到端移动应用导航,只能用qwen3.7-plus或豆包系。5. 国内合规敏感场景要确认模型备案状态字节、阿里、月之暗面三家模型在不同行业的备案情况不一样,金融、政务、医疗这些强监管行业,选型前务必确认你目标的 row_key 是否已完成备案。五、生产环境实战:路由策略 监控 容灾跑完 5 场景,我现在的 Agent 生产线是这样配的(基于公开聚合接入文档):第一层:按场景路由ROUTER { knowledge_qa_long: kimi-k3, # 100k 文档检索 knowledge_qa_short: qwen3.7-plus, # 50k 文档 creative_marketing: qwen3.7-plus, # 营销文案 code_agent_repo: qwen3-coder-flash, # 仓库级代码 data_analysis: doubao-seed-evolving, # 工具密集 cross_system_workflow: doubao-seed-2-1-pro-260628, # 长链路 }第二层:失败回退每个主模型配 1-2 个降级模型,优先同派系切换,跨派系做兜底。比如doubao-seed-evolving失败,先回退到qwen3.7-plus,再回退到qwen3-coder-flash。第三层:成本监控关键指标:每千次请求的 token 消耗、超时率、JSON 格式失败率、端到端任务完成率。我把 kimi-k3 的成本告警阈值设到了 ¥500/小时,超过就触发强制切流。容灾:每个模型至少接入 2 个不同的 endpoint,主备切换间隔控制在 30 秒内。这一块 炻光 AI 接入管理平台 的统一接口封装帮了大忙,不用每个模型单独写接入层。六、完整代码:可复制即跑下面这段代码封装了一个简易的场景-模型路由器,带失败回退和成本统计,接 production 改两行就能用:import os import time import json from openai import OpenAI # 模型价格表(元/1M tokens) PRICE { doubao-seed-evolving: {in: 3.0, out: 15.0}, doubao-seed-2-1-pro-260628: {in: 3.0, out: 15.0}, qwen3.7-plus: {in: 1.0, out: 4.0}, qwen3-coder-flash: {in: 0.5, out: 2.0}, kimi-k3: {in: 10.0, out: 50.0}, } # 场景 - 主模型 - 备模型 ROUTER { knowledge_qa_long: (kimi-k3, [doubao-seed-evolving, qwen3.7-plus]), knowledge_qa_short: (qwen3.7-plus, [doubao-seed-evolving, qwen3-coder-flash]), creative_marketing: (qwen3.7-plus, [doubao-seed-2-1-pro-260628, doubao-seed-evolving]), code_agent_repo: (qwen3-coder-flash, [doubao-seed-evolving, qwen3.7-plus]), data_analysis: (doubao-seed-evolving, [doubao-seed-2-1-pro-260628, qwen3.7-plus]), cross_system_workflow: (doubao-seed-2-1-pro-260628, [doubao-seed-evolving, qwen3.7-plus]), } class AgentRouter: def __init__(self, api_key, base_url): self.client OpenAI(api_keyapi_key, base_urlbase_url) self.cost_log [] def call(self, scene, messages, toolsNone): chain ROUTER.get(scene, (qwen3.7-plus, [doubao-seed-evolving])) models_to_try [chain[0]] chain[1] last_err None for model in models_to_try: try: start time.time() kwargs {model: model, messages: messages, temperature: 0.3} if tools: kwargs[tools] tools resp self.client.chat.completions.create(**kwargs) latency time.time() - start usage resp.usage cost ( usage.prompt_tokens / 1_000_000 * PRICE[model][in] usage.completion_tokens / 1_000_000 * PRICE[model][out] ) self.cost_log.append({ model: model, scene: scene, latency: latency, in_tok: usage.prompt_tokens, out_tok: usage.completion_tokens, cost: round(cost, 6), }) return resp.choices[0].message, model except Exception as e: last_err e continue raise RuntimeError(fall models failed: {last_err}) def daily_cost(self): return sum(item[cost] for item in self.cost_log) # 示例:跑一个数据查询场景 if __name__ __main__: router AgentRouter( api_keyos.environ[API_KEY], base_urlhttps://selltoken.apifox.cn/v1, ) sql_tool [{type: function, function: { name: execute_sql, description: Execute SQL query, parameters: {type: object, properties: { sql: {type: string} }, required: [sql]} }}] msgs [{role: user, content: 查一下 2026 Q2 各产品线营收占比}] reply, used_model router.call(data_analysis, msgs, toolssql_tool) print(model:, used_model) print(content:, reply.content) print(cost so far:, router.daily_cost())七、调 Agent 基座 API 的几个细节(FAQ)Q1:同款 doubao-seed-evolving 不同时间返回风格不一样,正常吗?正常。它的 Model ID 设计就是统一入口持续演化,后台会自动跟随版本切换。如果你的业务对输出稳定性要求极高,建议固定用doubao-seed-2-1-pro-260628这类带日期戳的快照版本。Q2:qwen3-coder-flash 和 qwen3.7-plus 在代码场景怎么选?仓库级重构、跨文件分析、CI 自动化 → 优先qwen3-coder-flash(成本只有 1/4);如果还需要多模态读图、读截图、写前端 → 切qwen3.7-plus。Q3:kimi-k3 的 100 万上下文是按 token 阶梯计费吗?不同平台策略不一样。从我看到的接入层封装来看,有些平台在 128k 以上会触发阶梯价(输入输出各上浮),有些是统一价。生产环境部署前,务必确认你接入的 endpoint 计费档位。Q4:JSON 模式怎么开最稳?豆包系推荐response_format{type: json_object} system prompt 强约束;Qwen 系必须显式声明response_format;kimi-k3 在工具调用模式下 JSON 合规率最高(4.1 分),纯文本模式会掉到 3.8 左右。Q5:agent 调用超时怎么设置?豆包派 timeout 建议 60 秒;Qwen 派 45 秒;kimi-k3 因为推理深,建议 120 秒。超时直接切下一个备模型,不要硬等。八、参考资料Moonshot Kimi K3 模型卡阿里云百炼 Qwen3.7 模型文档字节豆包 Seed 系列模型文档九、写在最后最后总结 3 条实测下来的经验,供正在做 Agent 选型的同学参考:不要按模型名选型,按场景选型。同一款qwen3.7-plus在营销文案 4.5 分、在跨系统工作流只有 4.2 分——你拿的是 5 场景平均分,业务场景才有意义。百万 token 上下文是奢侈品,不是日用品。kimi-k3 的 100 万上下文确实惊艳,但 ¥50.0/1M 输出价格意味着跑一次长文档 RAG 成本是doubao-seed-evolving的 3 倍多。先评估你的真实命中提升值不值这个差价。Agent 基座一定要做主备成本监控双层路由。我测试中 5 个模型没有一款做到了 100% 端到端成功率,跨系统工作流场景最高也只到 94%。生产环境不接回退、不接成本告警,迟早出事。
Agent基座换代:国产三派5场景实测适用读者:想在 Agent 系统里调豆包 / Qwen / Kimi 这些国产大模型基座的开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 Q3 值得重新讲一遍 Agent 基座2026 年 7 月,我把手上一个 RAG 工具调用 pipeline 的底层模型,从年初的版本一口气切到了三派新基座——豆包的 doubao-seed-evolving、通义的 qwen3.7-plus、月之暗面的 kimi-k3,顺便把研发场景专用的 qwen3-coder-flash 和豆包最新 pro 版 doubao-seed-2-1-pro-260628 一起拉进来横评。结果让我意外:同一套 5 场景测试集跑下来,响应稳定性、token 成本、长上下文命中率,差距比想象中大得多。年初的时候,我还觉得国产 Agent 基座基本是豆包做执行、Qwen 做工具、Kimi 做长文三分天下;但 Q3 这一波迭代下来,kimi-k3 直接把上下文拉到 100 万 token 还开源,qwen3.7-plus 强化了多模态GUI 操作,doubao-seed-evolving 干脆统一了 Model ID 让你永远拿到最新模型。如果还按去年的经验做技术选型,可能会踩坑。我把这 5 个新基座在 5 个真实业务场景里的实测结果整理成下文,顺便补一份完整可跑的 Python 代码,供正在做 Agent 落地的同学参考。二、国产三派的新基座是什么先把这 5 个 row_key 的定位理清楚。三派分别对应字节豆包系、阿里 Qwen 系、月之暗面 Kimi 系,各自针对 Agent 场景做了强化。豆包派(字节系):doubao-seed-evolving:面向 Agent 与 Coding 场景的统一调用入口,自动跟随版本迭代,无需手动切模型。强调复杂任务编排、长程规划、代码生成与工具调用。doubao-seed-2-1-pro-260628:生产级智能大模型,强化 Coding、Agent 与多模态能力,擅长自主规划、长链路执行和动态修复。Qwen 派(阿里系):qwen3.7-plus:高性价比 Plus 模型,完整保留编码、工具使用和生产力工作流能力,新增多模态GUI 操作能力。qwen3-coder-flash:代码生成专用模型,继承 Qwen3-Coder-Plus 的 coding agent 能力,重点优化仓库级别理解与多轮工具调用稳定性。Kimi 派(月之暗面):kimi-k3:Kimi 迄今能力最强的旗舰,2.8 万亿参数 KDA 混合线性注意力,100 万 token 上下文窗口,原生视觉理解,是全球首个开源的 3 万亿级别模型。按公开价格(截至 2026-07)整理:模型输入价输出价doubao-seed-evolving¥3.0/1M tokens¥15.0/1M tokensdoubao-seed-2-1-pro-260628¥3.0/1M tokens¥15.0/1M tokensqwen3.7-plus¥1.0/1M tokens¥4.0/1M tokensqwen3-coder-flash¥0.5/1M tokens¥2.0/1M tokenskimi-k3¥10.0/1M tokens¥50.0/1M tokens价格差很扎眼——kimi-k3 输出价是 qwen3-coder-flash 的 25 倍。但长上下文场景下,这个差距会被命中率的提升抵消掉一部分。三、五场景实测:从响应稳定性到长上下文命中率我用同一套 5 场景测试集(每个场景 50 条 query),跑了三轮取均值。三维度评分采用 5 分制。场景 1:知识库问答(RAG)测试集是 200 篇技术文档,每篇平均 3k 字,问答要求从文档中抽取具体参数。我把每篇文档直接塞进上下文,不做切片,纯测长上下文检索能力。模型Agent 能力长上下文命中率工具调用平均延迟doubao-seed-evolving4.24.5(256k)4.63.1sdoubao-seed-2-1-pro-2606284.44.6(256k)4.53.4sqwen3.7-plus4.04.0(128k)4.22.8sqwen3-coder-flash3.53.6(128k)4.02.5skimi-k34.64.9(1M)4.35.8skimi-k3 在百万 token 上下文下命中率 4.9,优势非常明显;豆包两兄弟在 256k 范围内表现稳定,Qwen 系受限于 128k,长文档得切片。场景 2:营销文案生成给定 200 字产品介绍 品牌调性要求,生成小红书 / 公众号 / 微博三平台适配文案。模型文案质量调性遵循输出长度控制doubao-seed-evolving4.34.44.5doubao-seed-2-1-pro-2606284.54.64.4qwen3.7-plus4.44.54.6qwen3-coder-flash3.63.84.0kimi-k34.24.04.2Qwen 派在创意文案上其实不输豆包,而且 token 成本低得多。场景 3:研发代码 Agent测试集是 30 个真实仓库的 issue,要求模型自动定位代码、生成 patch、跑单测通过。qwen3-coder-flash是这个场景的专项模型。模型代码生成工具调用稳定性仓库级理解doubao-seed-evolving4.44.54.2doubao-seed-2-1-pro-2606284.54.44.3qwen3.7-plus4.24.34.0qwen3-coder-flash4.64.74.5kimi-k34.34.24.4qwen3-coder-flash不出意料拿了第一,而且输出价只有 ¥2.0/1M tokens,大批量跑仓库级重构性价比最高。场景 4:数据分析(工具调用密集型)给定 CSV 用户问题,模型需要多次调用 Python 解释器、SQL 执行、数据可视化工具,完成多步分析。模型多步规划工具编排JSON 格式合规doubao-seed-evolving4.54.64.7doubao-seed-2-1-pro-2606284.64.54.6qwen3.7-plus4.14.34.4qwen3-coder-flash4.04.24.3kimi-k34.44.24.1豆包派在工具密集型场景的稳定性,特别是 JSON 格式合规率,是我测试中最稳的。场景 5:跨系统工作流模拟企业内部场景:模型需要先调用 CRM API 拉客户数据,再调用工单系统开 ticket,最后调邮件服务发通知,中间失败要回滚。模型编排复杂度异常恢复端到端成功率doubao-seed-evolving4.64.592%doubao-seed-2-1-pro-2606284.74.694%qwen3.7-plus4.24.185%qwen3-coder-flash4.03.982%kimi-k34.34.287%跨系统工作流这种长链路 多异常分支的场景,豆包的 Seed 2.1 Pro 表现最好,doubao-seed-2-1-pro-260628端到端成功率 94%。四、什么时候不该用(反向避坑)不是所有 Agent 场景都适合上这些旗舰基座。我自己在测试中也踩了几个坑,总结下来这几类情况要慎重:1. 高频低延迟场景不要上 kimi-k3kimi-k3 单次响应平均 5.8 秒,延迟是 qwen3-coder-flash 的 2 倍多。如果你的场景是用户实时交互、批量数据处理流水线,kimi-k3 的 ¥10.0/1M 输入 ¥50.0/1M 输出成本会让你很快烧穿预算。2. 纯文本短对话别用 doubao-seed-evolvingdoubao-seed-evolving的设计目标是 Agent Coding,如果你只是做几轮短对话问答,它反而会因为强行规划多步而变慢、变贵。这种场景qwen3.7-plus(¥1.0/1M 输入 ¥4.0/1M 输出)或者更轻量的版本更合适。3. 100k 以内的工具调用,别硬上 kimi-k3 的百万上下文百万 token 上下文是 kimi-k3 的卖点,但如果你只需要处理 50k 文档,塞进 kimi-k3 的命中率提升非常有限,成本却直接涨 5-10 倍。这种情况doubao-seed-evolving(256k ¥3.0/1M 输入)的 ROI 反而更高。4. 多模态GUI 操作别用 qwen3-coder-flashqwen3-coder-flash是纯文本代码生成模型,虽然便宜,但不支持视觉理解和 GUI 操作。如果你的 Agent 需要读屏幕、识别 UI 元素、做端到端移动应用导航,只能用qwen3.7-plus或豆包系。5. 国内合规敏感场景要确认模型备案状态字节、阿里、月之暗面三家模型在不同行业的备案情况不一样,金融、政务、医疗这些强监管行业,选型前务必确认你目标的 row_key 是否已完成备案。五、生产环境实战:路由策略 监控 容灾跑完 5 场景,我现在的 Agent 生产线是这样配的(基于公开聚合接入文档):第一层:按场景路由ROUTER { knowledge_qa_long: kimi-k3, # 100k 文档检索 knowledge_qa_short: qwen3.7-plus, # 50k 文档 creative_marketing: qwen3.7-plus, # 营销文案 code_agent_repo: qwen3-coder-flash, # 仓库级代码 data_analysis: doubao-seed-evolving, # 工具密集 cross_system_workflow: doubao-seed-2-1-pro-260628, # 长链路 }第二层:失败回退每个主模型配 1-2 个降级模型,优先同派系切换,跨派系做兜底。比如doubao-seed-evolving失败,先回退到qwen3.7-plus,再回退到qwen3-coder-flash。第三层:成本监控关键指标:每千次请求的 token 消耗、超时率、JSON 格式失败率、端到端任务完成率。我把 kimi-k3 的成本告警阈值设到了 ¥500/小时,超过就触发强制切流。容灾:每个模型至少接入 2 个不同的 endpoint,主备切换间隔控制在 30 秒内。这一块 炻光 AI 接入管理平台 的统一接口封装帮了大忙,不用每个模型单独写接入层。六、完整代码:可复制即跑下面这段代码封装了一个简易的场景-模型路由器,带失败回退和成本统计,接 production 改两行就能用:import os import time import json from openai import OpenAI # 模型价格表(元/1M tokens) PRICE { doubao-seed-evolving: {in: 3.0, out: 15.0}, doubao-seed-2-1-pro-260628: {in: 3.0, out: 15.0}, qwen3.7-plus: {in: 1.0, out: 4.0}, qwen3-coder-flash: {in: 0.5, out: 2.0}, kimi-k3: {in: 10.0, out: 50.0}, } # 场景 - 主模型 - 备模型 ROUTER { knowledge_qa_long: (kimi-k3, [doubao-seed-evolving, qwen3.7-plus]), knowledge_qa_short: (qwen3.7-plus, [doubao-seed-evolving, qwen3-coder-flash]), creative_marketing: (qwen3.7-plus, [doubao-seed-2-1-pro-260628, doubao-seed-evolving]), code_agent_repo: (qwen3-coder-flash, [doubao-seed-evolving, qwen3.7-plus]), data_analysis: (doubao-seed-evolving, [doubao-seed-2-1-pro-260628, qwen3.7-plus]), cross_system_workflow: (doubao-seed-2-1-pro-260628, [doubao-seed-evolving, qwen3.7-plus]), } class AgentRouter: def __init__(self, api_key, base_url): self.client OpenAI(api_keyapi_key, base_urlbase_url) self.cost_log [] def call(self, scene, messages, toolsNone): chain ROUTER.get(scene, (qwen3.7-plus, [doubao-seed-evolving])) models_to_try [chain[0]] chain[1] last_err None for model in models_to_try: try: start time.time() kwargs {model: model, messages: messages, temperature: 0.3} if tools: kwargs[tools] tools resp self.client.chat.completions.create(**kwargs) latency time.time() - start usage resp.usage cost ( usage.prompt_tokens / 1_000_000 * PRICE[model][in] usage.completion_tokens / 1_000_000 * PRICE[model][out] ) self.cost_log.append({ model: model, scene: scene, latency: latency, in_tok: usage.prompt_tokens, out_tok: usage.completion_tokens, cost: round(cost, 6), }) return resp.choices[0].message, model except Exception as e: last_err e continue raise RuntimeError(fall models failed: {last_err}) def daily_cost(self): return sum(item[cost] for item in self.cost_log) # 示例:跑一个数据查询场景 if __name__ __main__: router AgentRouter( api_keyos.environ[API_KEY], base_urlhttps://selltoken.apifox.cn/v1, ) sql_tool [{type: function, function: { name: execute_sql, description: Execute SQL query, parameters: {type: object, properties: { sql: {type: string} }, required: [sql]} }}] msgs [{role: user, content: 查一下 2026 Q2 各产品线营收占比}] reply, used_model router.call(data_analysis, msgs, toolssql_tool) print(model:, used_model) print(content:, reply.content) print(cost so far:, router.daily_cost())七、调 Agent 基座 API 的几个细节(FAQ)Q1:同款 doubao-seed-evolving 不同时间返回风格不一样,正常吗?正常。它的 Model ID 设计就是统一入口持续演化,后台会自动跟随版本切换。如果你的业务对输出稳定性要求极高,建议固定用doubao-seed-2-1-pro-260628这类带日期戳的快照版本。Q2:qwen3-coder-flash 和 qwen3.7-plus 在代码场景怎么选?仓库级重构、跨文件分析、CI 自动化 → 优先qwen3-coder-flash(成本只有 1/4);如果还需要多模态读图、读截图、写前端 → 切qwen3.7-plus。Q3:kimi-k3 的 100 万上下文是按 token 阶梯计费吗?不同平台策略不一样。从我看到的接入层封装来看,有些平台在 128k 以上会触发阶梯价(输入输出各上浮),有些是统一价。生产环境部署前,务必确认你接入的 endpoint 计费档位。Q4:JSON 模式怎么开最稳?豆包系推荐response_format{type: json_object} system prompt 强约束;Qwen 系必须显式声明response_format;kimi-k3 在工具调用模式下 JSON 合规率最高(4.1 分),纯文本模式会掉到 3.8 左右。Q5:agent 调用超时怎么设置?豆包派 timeout 建议 60 秒;Qwen 派 45 秒;kimi-k3 因为推理深,建议 120 秒。超时直接切下一个备模型,不要硬等。八、参考资料Moonshot Kimi K3 模型卡阿里云百炼 Qwen3.7 模型文档字节豆包 Seed 系列模型文档九、写在最后最后总结 3 条实测下来的经验,供正在做 Agent 选型的同学参考:不要按模型名选型,按场景选型。同一款qwen3.7-plus在营销文案 4.5 分、在跨系统工作流只有 4.2 分——你拿的是 5 场景平均分,业务场景才有意义。百万 token 上下文是奢侈品,不是日用品。kimi-k3 的 100 万上下文确实惊艳,但 ¥50.0/1M 输出价格意味着跑一次长文档 RAG 成本是doubao-seed-evolving的 3 倍多。先评估你的真实命中提升值不值这个差价。Agent 基座一定要做主备成本监控双层路由。我测试中 5 个模型没有一款做到了 100% 端到端成功率,跨系统工作流场景最高也只到 94%。生产环境不接回退、不接成本告警,迟早出事。
)
