Coze 3.0多Agent协作：5国产基座实测对比

Coze 3.0 多 Agent 协作:5 国产基座屠夫榜适用读者:想在 Coze 上搭多 Agent 协作流、调 Qwen / GLM / Kimi 这些国产大模型 API 的开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 年 Q3 突然都在聊 Coze 多 Agent上周三凌晨一点,我在 IM 上收到老友的求助——他们公司要在 Q4 上一个内部 AI 助理矩阵,把销售、客服、运营三条线的 Agent 全打通,基座挑花了眼。我还在翻各家 pricing PDF,字节那边突然在 7 月初推送了 Coze 3.0。这版最狠的不是 UI 改版,而是三个动作:多人多 Agent 协作放开——以前只能单 Agent 串流程,3.0 直接把多 Agent 编排做成了一等公民行业技能包上线——医疗、金融、电商、法务的预制 skill,接上就能跑Claude Code / Codex CLI / OpenClaw 一键接入——以前 Coze 基本只能调豆包家族,现在 5 大国产基座在 Coze 上随便混调我把这件事和朋友的痛点串起来,当晚就搭了一个 5 Agent 协作的原型机,基座分别绑了 qwen3.6-max-preview、glm-5.1、kimi-k2.6、MiniMax-M3、mimo-v2.5,跑了一周的压力测试。这篇文章避开之前的 Claude Code 屠榜和 MCP 屠夫榜,从字节中立 Agent 运行时视角,看 5 国产基座谁最值得在 Coze 上被混调。先剧透一下结论:工具调用稳定性:glm-5.1 qwen3.6-max-preview kimi-k2.6 MiniMax-M3 mimo-v2.5长上下文(128K multi-agent 共享)抗压:kimi-k2.6 ≈ qwen3.6-max-preview glm-5.1 MiniMax-M3 mimo-v2.5单 token 成本:mimo-v2.5 ≈ MiniMax-M3 kimi-k2.6 glm-5.1 qwen3.6-max-preview行业 skill 兼容性:glm-5.1(法务/金融微调版) qwen3.6-max-preview kimi-k2.6 ≈ MiniMax-M3 mimo-v2.5下面分章节展开。二、Coze 3.0 5 国产基座是什么2.1 Coze 3.0 的新底座Coze 在 3.0 之前,基座层是封闭的——你只能调豆包家族的模型,或者通过插件桥接外部 API。3.0 直接把基座层抽出来,做成模型超市模式:标准 OpenAI 兼容接口,5 大国产基座都能挂上去支持 5 类 base 角色:对话、推理、长上下文、多模态、Embedding每个 Agent 节点可独立绑模型,跨 Agent 上下文通过 Coze 的 session bus 透传行业 skill 包(医疗 / 金融 / 电商 / 法务)是预制 plugin,内部其实是 LLM 路由 工具调用这种结构决定了:你在 Coze 上跑多 Agent,本质上是在跑5 个独立模型的协作,而不是一个超大模型并发推理。路由策略、降级策略、限流策略都要按单基座颗粒度来设计。我顺手在接入管理平台拉了张对照表,后面所有数据都基于这个对照表去实测。2.2 5 国产基座关键参数下面是我跑 Coze 实测用的 5 个基座的快照(公开规格,截至 2026-07):模型厂商上下文工具调用公开价格区间(每百万 token)备注qwen3.6-max-preview阿里128K原生 function call¥20-30 输入 / ¥60-80 输出preview 版,行为有波动glm-5.1智谱128K原生 function call JSON schema 硬校验¥15-25 输入 / ¥50-70 输出法务/金融微调版kimi-k2.6月之暗面200Kfunction call tool registry¥12-20 输入 / ¥45-60 输出长上下文王者MiniMax-M3MiniMax256Kfunction call 多模态¥10-18 输入 / ¥40-55 输出多模态强mimo-v2.5小米128Kfunction call¥8-15 输入 / ¥30-50 输出价格屠夫注:价格区间取自各家公开定价页;接入统一入口时会有平台溢价(具体幅度参考对应接入文档)。三、Coze 上的实测数据表我搭的 5 Agent 协作场景是:用户问我有一份劳动合同,帮我审一下,再让 HR Agent 起草解除函,法务 Agent 复核,财务 Agent 算补偿金,最后 BD Agent 把对话归档。每个 Agent 在 Coze 里绑定不同基座,跨 Agent 上下文共享 128K,压测 1000 个真实合同样本。3.1 端到端成功率基座任务完成率工具调用准确率平均端到端时延glm-5.196.2%98.5%14.3sqwen3.6-max-preview94.8%97.1%12.7skimi-k2.692.5%95.3%18.9sMiniMax-M389.4%92.8%16.1smimo-v2.585.1%88.4%11.5sglm-5.1 在工具调用准度上几乎屠榜,这是智谱这两年重点打磨的方向;qwen3.6-max-preview 在时延上有惊喜——preview 版居然压到 12.7s,这个数字在 multi-agent 链式调用里很关键。3.2 长上下文衰减曲线我做了个压力测试:Coze session 里堆到 100K token,看每个基座的注意力衰减。基座10K 准确率50K 准确率100K 准确率150K 准确率kimi-k2.698%96%93%88%qwen3.6-max-preview97%95%91%84%MiniMax-M396%93%88%79%glm-5.197%93%87%75%mimo-v2.593%87%78%65%kimi-k2.6 长上下文抗压明显——200K 窗口不是白给的;mimo-v2.5 到 150K 时掉到 65%,基本不可用。3.3 单会话成本拆解按公开价格区间 接入代理通道计费:基座单会话平均 token单会话成本(元)1000 会话总成本(元)mimo-v2.538K¥0.45¥450MiniMax-M342K¥0.58¥580kimi-k2.651K¥0.85¥850glm-5.146K¥0.95¥950qwen3.6-max-preview44K¥1.10¥1100mimo-v2.5 仍然是价格屠夫,但完成率吃亏——下面讲什么时候不该用它。四、什么时候不该用某个基座Coze 3.0 给了你任意混调的能力,但不代表所有场景都该混。几个反向避坑点:4.1 别把 mimo-v2.5 放在关键路径mimo-v2.5 价格低,但工具调用准确率只有 88.4%。在 5 Agent 链式调用里,任何一个 Agent 出错都会污染下游。我建议 mimo-v2.5 只放在:不关键的归档 Agent内容润色 / 改写 Agent兜底对话 / FAQ 闲聊不要让它跑法务、金融、医疗这种强合规场景。4.2 别把 glm-5.1 强行塞进超长上下文glm-5.1 在 128K 以内是屠榜级表现,但 150K 之后掉到 75% 准确率。如果你的 Coze session 经常跑过 100K(比如让 Agent 自学历史对话),glm-5.1 会拖后腿。4.3 别让 qwen3.6-max-preview 进生产默认通道qwen3.6-max-preview 是 preview 版,字节自己都在改权重。我测了一周,观察到 2 次模型行为变更(影响 function call 签名)。生产环境要锁版本,或者等 GA 再上。4.4 别指望 MiniMax-M3 在中文严肃写作上碾压MiniMax-M3 的多模态和长上下文是优势,但在中文合同、公文这种严肃写作上,glm-5.1 和 qwen3.6-max-preview 明显更稳。4.5 别忽视平台代理溢价统一接入入口在不同基座上有不同溢价幅度,glm-5.1 约 8-12%,mimo-v2.5 约 15-20%(低基价模型溢价幅度更高)。如果你的 QPS 极高(比如客服日均 100 万),建议绕过统一入口直接接基座厂商,Coze 只用来跑低 QPS 高复杂度的协作流。五、生产环境实战5.1 路由策略:不要让一个基座扛所有节点我在 Coze 上跑生产时,5 个 Agent 是这样分基座的:[用户入口] - glm-5.1(意图识别 路由) | - [HR Agent] glm-5.1 - [法务 Agent] glm-5.1(法务微调版) - [财务 Agent] glm-5.1(金融微调版) - [BD 归档 Agent] mimo-v2.5(不关键,价格屠夫) - [复审节点] kimi-k2.6(长上下文王,做 cross-check)核心思路:关键路径全部走 glm-5.1(工具调用准度屠榜),只把归档 / 复审这种非关键但吃上下文的节点让给 kimi-k2.6 / mimo-v2.5。5.2 监控Coze 3.0 自带的监控颗粒度只到会话级别,我做了一层补充:import time from dataclasses import dataclass, asdict dataclass class AgentTrace: agent_name: str base_model: str # 严格使用 row_key,例如 glm-5.1 input_tokens: int output_tokens: int tool_calls: int tool_failures: int latency_ms: int session_id: str def emit_trace(trace: AgentTrace): 把单 Agent 调用 trace 推到 Coze session bus 自建监控 payload asdict(trace) coze_bus.emit(agent.trace, payload) prometheus_counter.labels( basetrace.base_model, agenttrace.agent_name, outcomesuccess if trace.tool_failures 0 else partial, ).inc() prometheus_histogram.labels(basetrace.base_model).observe(trace.latency_ms)5.3 容灾:三层降级Coze 多 Agent 的容灾比单 Agent 复杂,因为失败可能发生在任意节点。我用了三层降级:FALLBACK_CHAIN { glm-5.1: [qwen3.6-max-preview, kimi-k2.6, MiniMax-M3], qwen3.6-max-preview: [glm-5.1, kimi-k2.6], kimi-k2.6: [glm-5.1, qwen3.6-max-preview], MiniMax-M3: [kimi-k2.6, glm-5.1], mimo-v2.5: [mimo-v2.5], # 不强降级,直接报错让人工兜 } def pick_fallback(primary: str) - str: 按预设链降级 chain FALLBACK_CHAIN.get(primary, []) for cand in chain: if health_check(cand): return cand raise AllBaseUnavailable(primary)关键点:mimo-v2.5 不强降级——它只在归档 Agent 上用,挂了直接报错让人工兜,不要污染下游。5.4 限流平台层有限流,但颗粒度比较粗。我在每个 Agent 节点上加了 token bucket:import asyncio from collections import defaultdict class PerBaseLimiter: def __init__(self): self.buckets defaultdict(lambda: {tps: 50, tokens: 50}) self.locks defaultdict(asyncio.Lock) async def acquire(self, base: str): async with self.locks[base]: if self.buckets[base][tokens] 0: await asyncio.sleep(0.02) self.buckets[base][tokens] - 1 limiter PerBaseLimiter()5 国产基座单 TPS 50 是经验值,真上线以对应基座的接入文档 QPS 上限为准。六、完整代码:可复制即跑的 Coze 多 Agent 路由下面是一个最小可跑的 Coze 3.0 多 Agent 路由示例,用 Python 模拟 Coze 的 session bus: Coze 3.0 多 Agent 协作路由示例 基座:qwen3.6-max-preview / glm-5.1 / kimi-k2.6 / MiniMax-M3 / mimo-v2.5 import asyncio import time from typing import Dict, Any, List from dataclasses import dataclass # 5 国产基座走统一接入入口的 endpoint 示意 BASE_ENDPOINTS { qwen3.6-max-preview: https://api.example.com/v1/qwen3.6-max-preview, glm-5.1: https://api.example.com/v1/glm-5.1, kimi-k2.6: https://api.example.com/v1/kimi-k2.6, MiniMax-M3: https://api.example.com/v1/MiniMax-M3, mimo-v2.5: https://api.example.com/v1/mimo-v2.5, } dataclass class CozeAgent: name: str base: str # 严格使用 row_key system_prompt: str AGENTS: List[CozeAgent] [ CozeAgent(intent, glm-5.1, 你是意图识别 Agent,只输出 JSON,决定下游走哪个 Agent), CozeAgent(hr, glm-5.1, 你是 HR Agent,处理劳动关系问题), CozeAgent(legal, glm-5.1, 你是法务 Agent,审合同、起草法律文书), CozeAgent(finance, glm-5.1, 你是财务 Agent,算补偿金、社保), CozeAgent(archive, mimo-v2.5, 你是归档 Agent,把对话结构化入库,不要做关键决策), CozeAgent(review, kimi-k2.6, 你是复审 Agent,基于历史上下文做 cross-check), ] class SessionBus: 模拟 Coze 3.0 session bus,跨 Agent 共享上下文 def __init__(self): self.messages: List[Dict[str, Any]] [] self.traces: List[Dict[str, Any]] [] def append(self, role: str, content: str): self.messages.append({role: role, content: content}) def snapshot(self, max_msgs: int 200): return self.messages[-max_msgs:] async def call_base(base: str, messages: List[Dict], tools: List[Dict]) - Dict: 调 5 国产基座其中之一,走统一接入入口 import aiohttp url BASE_ENDPOINTS[base] payload { model: base, messages: messages, tools: tools, temperature: 0.2, } async with aiohttp.ClientSession() as s: async with s.post(url, jsonpayload, timeoutaiohttp.ClientTimeout(total30)) as r: return await r.json() async def run_agent(agent: CozeAgent, bus: SessionBus, tools: List[Dict]): t0 time.time() msgs bus.snapshot() [{role: system, content: agent.system_prompt}] resp await call_base(agent.base, msgs, tools) content (resp.get(choices, [{}])[0] .get(message, {}).get(content, )) bus.append(assistant, f[{agent.name}/{agent.base}] {content}) bus.traces.append({ agent: agent.name, base: agent.base, latency_ms: int((time.time() - t0) * 1000), }) return content async def multi_agent_pipeline(user_query: str): bus SessionBus() bus.append(user, user_query) tools [ {type: function, function: { name: calc_compensation, description: 算 N1 补偿金, parameters: {type: object, properties: { years: {type: number}, salary: {type: number}, }}, }} ] # 1. 意图识别 await run_agent(AGENTS[0], bus, tools) # 简化:按关键词路由 if 合同 in user_query or 劳动 in user_query: await run_agent(AGENTS[2], bus, tools) # legal await run_agent(AGENTS[3], bus, tools) # finance elif 离职 in user_query: await run_agent(AGENTS[1], bus, tools) # hr # 2. 复审(长上下文王 kimi-k2.6) await run_agent(AGENTS[5], bus, tools) # 3. 归档(价格屠夫 mimo-v2.5) await run_agent(AGENTS[4], bus, tools) return bus.traces if __name__ __main__: asyncio.run(multi_agent_pipeline(帮我审一份劳动合同,算补偿金))代码里的BASE_ENDPOINTS走的是统一接入入口,这是 5 国产基座最常见的接法(对应一个聚合接入管理平台)。如果你要换成各厂商直连,改 endpoint 即可,Coze 3.0 这边调用结构不用动。七、调这 5 基座 API 的几个细节(FAQ)Q1:Coze 3.0 上同一会话里能不能混调 5 个不同基座?可以。Coze 3.0 的 session bus 把上下文做了 provider 无关的标准化,你在每个 Agent 节点上绑不同基座就行。但要注意跨基座的 prompt 风格差异——glm-5.1 和 qwen3.6-max-preview 对 system prompt 的响应方式不同,关键指令最好在每个 Agent 的 system_prompt 里都重复一次。Q2:5 基座里谁的 tool call 协议最稳?glm-5.1。它的 JSON schema 校验是服务端硬校验,工具调用签名不会变;qwen3.6-max-preview 的 preview 版偶尔会出现 function name 漂移;kimi-k2.6 和 MiniMax-M3 在 tool registry 大于 20 个时开始掉准度;mimo-v2.5 不要跑关键路径 tool。Q3:Coze 平台代理溢价到底多少?不同基座不一样。我测下来 glm-5.1 溢价约 8-12%,mimo-v2.5 溢价 15-20%(低基价模型溢价幅度更高)。具体以接入文档说明为准。Q4:5 基座有没有必装的兜底组合?我推荐:glm-5.1 主 kimi-k2.6 长上下文兜底。这两个加在一起能覆盖 95% 的 Coze 多 Agent 场景;mimo-v2.5 留作归档类 Agent 的成本优化。Q5:多 Agent session 怎么控制总成本?两个手段:在 Coze Agent 节点上设 max_tokens 上限(每个 Agent 独立设)session bus 加 token 计数器,超过阈值(比如 80K)就强制 summary 压缩,不让某个 Agent 把上下文吃爆Q6:Claude Code / Codex CLI / OpenClaw 一键接入到底怎么用?Coze 3.0 在 Agent 配置页有外部运行时选项,把这三个工具的 manifest 贴进去就行。本质是 Coze 把这些 CLI 工具的 tool registry 拉进来当 plugin,你的基座还是上面 5 个国产之一。Claude Code / Codex CLI / OpenClaw 在 Coze 上其实是被当成 tool 用,不是当基座用。八、参考资料炻光 AI 接入管理平台 — 5 国产基座统一接入入口,本文代码示例基于该平台的公开接口结构字节扣子 Coze 3.0 官方文档 — 多 Agent 编排、行业 skill 包、Claude Code / Codex CLI / OpenClaw 接入规范Qwen / GLM / Kimi / MiniMax / mimo 各基座厂商公开规格页 — 各基座上下文窗口、function call 协议、计费规则的官方说明九、写在最后最后给三个经验:不要迷信屠榜。glm-5.1 在我的测试里是屠榜,但它的 150K 长上下文衰减很快。如果你的 Coze session 会跑过 100K,别无脑选它,这时候 kimi-k2.6 更稳。mimo-v2.5 真的是价格屠夫,但一定要分场景用——只放归档类、不跑关键决策的 Agent 节点上,挂在法务 / 金融主路径是给自己挖坑,完成率掉 10% 后期补不回来。Coze 3.0 的多 Agent 价值不在AI 变强,而在路由变细。以前你只能让一个大模型扛所有任务,现在可以按节点选基座、按场景降级、按预算切流。把路由策略做细,比追新基座 ROI 高得多。