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 改版,而是三个动作:

1. 多人多 Agent 协作放开——以前只能单 Agent 串流程,3.0 直接把多 Agent 编排做成了一等公民

2. 行业技能包上线——医疗、金融、电商、法务的预制 skill,接上就能跑

3. 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):

注:价格区间取自各家公开定价页;接入统一入口时会有平台溢价(具体幅度参考对应接入文档)。

三、Coze 上的实测数据表

我搭的 5 Agent 协作场景是:用户问"我有一份劳动合同,帮我审一下,再让 HR Agent 起草解除函,法务 Agent 复核,财务 Agent 算补偿金,最后 BD Agent 把对话归档"。每个 Agent 在 Coze 里绑定不同基座,跨 Agent 上下文共享 128K,压测 1000 个真实合同样本。

3.1 端到端成功率

glm-5.1 在工具调用准度上几乎屠榜,这是智谱这两年重点打磨的方向;qwen3.6-max-preview 在时延上有惊喜——preview 版居然压到 12.7s,这个数字在 multi-agent 链式调用里很关键。

3.2 长上下文衰减曲线

我做了个压力测试:Coze session 里堆到 100K token,看每个基座的注意力衰减。

kimi-k2.6 长上下文抗压明显——200K 窗口不是白给的;mimo-v2.5 到 150K 时掉到 65%,基本不可用。

3.3 单会话成本拆解

按公开价格区间 + 接入代理通道计费:

mimo-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( base=trace.base_model, agent=trace.agent_name, outcome="success" if trace.tool_failures == 0 else "partial", ).inc() prometheus_histogram.labels(base=trace.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, json=payload, timeout=aiohttp.ClientTimeout(total=30)) 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": "算 N+1 补偿金", "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 怎么控制总成本?

两个手段:

1. 在 Coze Agent 节点上设 max_tokens 上限(每个 Agent 独立设)

2. 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 协议、计费规则的官方说明

九、写在最后

最后给三个经验:

1. 不要迷信"屠榜"。glm-5.1 在我的测试里是屠榜,但它的 150K 长上下文衰减很快。如果你的 Coze session 会跑过 100K,别无脑选它,这时候 kimi-k2.6 更稳。

2. mimo-v2.5 真的是价格屠夫,但一定要分场景用——只放归档类、不跑关键决策的 Agent 节点上,挂在法务 / 金融主路径是给自己挖坑,完成率掉 10% 后期补不回来。

3. Coze 3.0 的多 Agent 价值不在"AI 变强",而在"路由变细"。以前你只能让一个大模型扛所有任务,现在可以按节点选基座、按场景降级、按预算切流。把路由策略做细,比追新基座 ROI 高得多。