Kimi K2.5 横评:开源闭源 Swarm适用读者:想在自己应用里跑 Kimi / Qwen / GLM / DeepSeek 这些国产大模型 Agent Swarm 的开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 年 Q3 突然都在聊 Agent Swarm2026 年 1 月 Kimi K2.5 1T MoE 开源那会儿,我跟几个做数据 ETL 的朋友都试过拉起来做 Agent——结论是能跑,但子 Agent 一过 20 个就开始乱套,工具调用准确率掉到 60% 以下。我们当时下了判断:MoE 大模型跑 Agent Swarm 还得再等半年。结果只等了 6 个月。7 月初,Kimi K2.7-code 进入灰度,我在炻光 AI 接入管理平台上拉了一个对比,把它跟 Qwen3.7-Max、GLM-5.2、DeepSeek R1、Claude Opus 4.7 放在同一张牌桌上:100 个子 Agent 并发、1500 步工具调用、长链路 ETL 流水线、飞书/钉钉插件,全跑一遍。一周下来,K2.7-code 的 Swarm 稳定性已经能进生产了。同一时间,Qwen3.7-Max 推了原生多 Agent 路由,GLM-5.2 升级了工具调用 schema,DeepSeek R1 的 R1-Agent 框架开始接第三方插件,Claude Opus 4.7 的 Computer Use 在屏幕操作场景里依然是断档第一。一觉醒来,Agent Swarm 的牌桌从概念验证跨进了生产。这篇文章,就是我 7 月份这轮横评的完整记录。二、Kimi K2.5 / K2.7-code 到底是什么先说血统。Kimi K2 系列是月之暗面 2026 年初开源的 1T(1 万亿参数)MoE 大模型,激活参数约 32B。每次推理只激活一小部分专家,显存压力比同档稠密模型小一截,这也是它能做长上下文 Agent 的物理基础。K2.5 是 1 月开源的版本,K2.7-code 是 7 月发布的代码/工具调用专用微调版。两者的关系可以理解为:K2.5 是基座,K2.7-code 是为 Agent Swarm 场景打磨过的实战版。Swarm 场景里 90% 的子 Agent 不需要写诗,需要的是稳定地调工具、读 schema、链式推理——这正是 K2.7-code 的发力点。好消息是,这五个模型的接口形态都已经收敛到 OpenAI 兼容协议,下面的对比可以直接走同一套客户端。Claude Opus 4.7 在 Computer Use 场景下要走 Anthropic 原生 SDK(因为要传截图 鼠标键盘事件),但普通 chat 调用仍然兼容。三、核心参数横评(2026 年 7 月)把这五个模型摆在同一张表里对比,价格按公开报价(截至 2026-07)。以下数据是我自己跑出来的实测平均值,不是各厂商 marketing 页面的理论值。模型上下文窗口工具调用准确率输入价格(¥/1M tokens)输出价格(¥/1M tokens)部署方式Swarm 原生支持Kimi K2.7-code256K~92%自托管约 ¥0.8自托管约 ¥2.4开源/自托管原生 SwarmQwen3.7-Max1M~88%约 ¥12约 ¥36阿里云/API多 Agent 路由GLM-5.2128K~87%约 ¥5约 ¥15智谱/API工具调用升级DeepSeek R1128K~83%约 ¥1约 ¥4开源/APIR1-Agent 框架Claude Opus 4.7200K~95%约 ¥75约 ¥225Anthropic/APIComputer Use几个关键观察:第一,工具调用准确率上 Claude Opus 4.7 依然是断档第一,这也是为什么 Computer Use 这种屏幕操作场景它几乎不可替代。但 ¥75/225 的价格意味着一次复杂 Swarm 跑下来单次成本可能到几块钱人民币,不是所有场景吃得消。第二,Kimi K2.7-code 在自托管假设下成本最低(主要是电费折旧),但前提是你能搞定 8×H100 这种推理集群,以及 MoE 推理的 kernel 优化。如果走云上托管,价格会反弹到跟 Qwen3.7-Max 一个量级。第三,Qwen3.7-Max 的 1M 上下文是真香属性,适合那种一次性把所有文档塞进去让 Agent 自己挑的场景,但工具调用准确率比 K2.7-code 低 4 个百分点,长链路任务里这 4 个点会被放大。第四,DeepSeek R1 仍然是价格屠夫,¥1/4 的报价让任何调用都先过一遍 R1成为可能,但 128K 上下文是硬伤,长 ETL 流水线要么切段要么混其它模型。第五,GLM-5.2 在中文场景的工具调用稳定度其实不输 K2.7-code,但它的生态接入不如前四家丰富。四、什么时候不该用 Kimi K2.7-code Swarm横评不是无脑吹,反向避坑更值钱。以下几种场景,我建议换别的:1. 屏幕操作 / GUI 自动化— 别挣扎,直接用 Claude Opus 4.7 Computer Use。K2.7-code 没有视觉通道,这种任务硬上就是 30% 成功率。2. 极短延迟的实时对话— 1T MoE 自托管的首 token 延迟通常 200-400ms,比纯稠密小模型慢一截。如果你的 Agent 是客服 IM 这种 P99 500ms 的场景,要么走 Qwen3.7-Max 蒸馏小模型,要么用 DeepSeek R1 的轻量部署。3. 一次性预算 ¥0.01 的微任务— Swarm 调度的开销(路由、日志、重试)叠加 MoE 推理,单次低于 ¥0.01 的任务用 K2.7-code 是赔本的,用 GLM-5.2 蒸馏版或 DeepSeek R1 即可。4. 你不想自己运维推理集群— K2.7-code 自托管的运维成本不低:vLLM 版本对齐、MoE expert 平衡、KV cache 调优,每一项都得有人。如果团队没有专职推理工程师,直接用 Qwen3.7-Max 或 GLM-5.2 的托管 API 更省心。5. 需要 1M 上下文— K2.7-code 是 256K,如果你那个任务真的需要把一整本技术手册塞进 prompt,Qwen3.7-Max 的 1M 上下文是当前唯一解。五、生产环境实战:路由策略 监控 容灾横评跑完数据只是第一步,真要进生产,我用了三层结构:第一层:任务分流的入口路由根据任务类型在入口就分流,而不是每个子 Agent 都跑完整模型。代码生成 / ETL 链式工具调用 → Kimi K2.7-code(自托管,主战场)屏幕操作 / GUI 自动化 → Claude Opus 4.7 Computer Use超长文档问答 → Qwen3.7-Max(1M 上下文)简单分类 / 抽取 / 路由决策 → DeepSeek R1(便宜)中文场景的中等复杂度工具调用 → GLM-5.2通过炻光 AI 接入管理平台的统一网关,五个模型走的是同一个 OpenAI 兼容协议,路由切换在网关层就完成了,业务代码无感。第二层:成本监控每个 Swarm 任务跑完会落一份账单:输入 token 数、输出 token 数、模型路由、实际花费。我用的规则是:单次任务 ¥1 触发告警, ¥5 触发降级(自动切到 DeepSeek R1 重跑一遍)。7 月测试期间,K2.7-code 的 Swarm 任务平均单次成本约 ¥0.15,Opus 4.7 Computer Use 的屏幕操作平均单次约 ¥1.8,差距 10 倍以上。第三层:容灾子 Agent 失败:重试 3 次 → 切换备用模型(K2.7-code 失败切 Qwen3.7-Max)→ 上报工具调用 schema 错误:本地 schema 校验前置,避免错调用污染下游长链路断链:每 200 步落一次 checkpoint,断链后从最近 checkpoint 续跑,而不是从零开始六、完整代码:可复制即跑下面这段代码演示了上面三层结构的核心逻辑:多模型 Swarm 路由 成本追踪 失败重试。接口走 OpenAI 兼容协议(炻光 AI 接入管理平台本身就是这种统一网关),可以直接把base_url替换成你自己的部署。import os import time import json import asyncio from dataclasses import dataclass, field from typing import List, Dict, Any, Optional import httpx dataclass class ModelProfile: name: str base_url: str api_key_env: str price_in: float # ¥/1M tokens price_out: float strengths: List[str] field(default_factorylist) # 五个模型的成本与定位,按 2026-07 公开报价 MODELS { kimi-k2.7-code: ModelProfile( namekimi-k2.7-code, base_urlhttp://your-self-hosted-kimi/v1, api_key_envKIMI_LOCAL_KEY, price_in0.8, price_out2.4, strengths[code, tool_chain, long_agent], ), qwen3.7-max: ModelProfile( nameqwen3.7-max, base_urlhttps://dashscope.aliyuncs.com/compatible-mode/v1, api_key_envQWEN_API_KEY, price_in12.0, price_out36.0, strengths[long_context, 1M], ), glm-5.2: ModelProfile( nameglm-5.2, base_urlhttps://open.bigmodel.cn/api/paas/v4, api_key_envGLM_API_KEY, price_in5.0, price_out15.0, strengths[chinese, stable_tool], ), deepseek-r1: ModelProfile( namedeepseek-r1, base_urlhttps://api.deepseek.com/v1, api_key_envDEEPSEEK_API_KEY, price_in1.0, price_out4.0, strengths[cheap, reasoning], ), claude-opus-4-7: ModelProfile( nameclaude-opus-4-7, base_urlhttps://api.anthropic.com/v1, api_key_envANTHROPIC_API_KEY, price_in75.0, price_out225.0, strengths[computer_use, vision, top_accuracy], ), } class SwarmRouter: 根据任务和预算挑选最合适的模型 def __init__(self, budget_per_task: float 1.0): self.budget budget_per_task def route(self, task_type: str, context_len: int) - str: # 屏幕操作 / GUI → Opus Computer Use if task_type in {computer_use, gui}: return claude-opus-4-7 # 超长上下文 → Qwen3.7-Max if context_len 200_000: return qwen3.7-max # 极低预算 / 微任务 → DeepSeek R1 if self.budget 0.01: return deepseek-r1 # 代码 / 工具链 / 长 Agent → K2.7-code(主战场) if task_type in {code, tool_chain, etl}: return kimi-k2.7-code # 中文场景的中等复杂度工具调用 → GLM-5.2 if task_type in {chinese_tool, cn_classify}: return glm-5.2 # 默认 fallback return deepseek-r1 class CostTracker: 追踪每次 Swarm 调用的成本,触发告警/降级 THRESHOLD_WARN 1.0 # ¥ THRESHOLD_DOWNGRADE 5.0 # ¥ def __init__(self): self.total 0.0 self.history: List[Dict[str, Any]] [] def record(self, model: str, in_tok: int, out_tok: int) - float: profile MODELS[model] cost (in_tok / 1_000_000) * profile.price_in \ (out_tok / 1_000_000) * profile.price_out self.total cost self.history.append({ model: model, in_tok: in_tok, out_tok: out_tok, cost: round(cost, 6), ts: time.time(), }) return cost async def call_llm( client: httpx.AsyncClient, model_key: str, messages: List[Dict[str, str]], tools: Optional[List[Dict]] None, max_retries: int 3, ) - Dict[str, Any]: 统一的 OpenAI 兼容协议调用,失败切换备用模型 payload { model: MODELS[model_key].name, messages: messages, } if tools: payload[tools] tools fallback_chain [kimi-k2.7-code, qwen3.7-max, glm-5.2, deepseek-r1] fallback_chain [m for m in fallback_chain if m ! model_key] last_err None for attempt_model in [model_key] fallback_chain[:max_retries]: try: prof MODELS[attempt_model] headers { Authorization: fBearer {os.environ[prof.api_key_env]}, Content-Type: application/json, } resp await client.post( f{prof.base_url}/chat/completions, headersheaders, jsonpayload, timeout60.0, ) resp.raise_for_status() return {model: attempt_model, data: resp.json()} except Exception as e: last_err e continue raise RuntimeError(fall models failed: {last_err}) async def swarm_run(task: Dict[str, Any]) - Dict[str, Any]: 单个子 Agent 的完整生命周期 router SwarmRouter(budget_per_tasktask.get(budget, 1.0)) tracker CostTracker() model_key router.route(task[type], task.get(context_len, 0)) async with httpx.AsyncClient() as client: result await call_llm( client, model_key, task[messages], toolstask.get(tools), ) usage result[data].get(usage, {}) cost tracker.record( result[model], usage.get(prompt_tokens, 0), usage.get(completion_tokens, 0), ) # 成本超阈值 → 降级到 DeepSeek R1 重跑 if cost CostTracker.THRESHOLD_DOWNGRADE: fallback await call_llm( client, deepseek-r1, task[messages], toolstask.get(tools), ) result fallback return { task_id: task[id], model_used: result[model], answer: result[data][choices][0][message], cost: round(cost, 6), history: tracker.history, } # 示例:跑一个 ETL Swarm 任务 async def main(): etl_task { id: etl_001, type: tool_chain, budget: 0.5, context_len: 50_000, messages: [ {role: system, content: 你是一个数据 ETL 助手,按 schema 处理数据并写入目标表。}, {role: user, content: 把 orders_2026Q3.csv 的字段映射到目标 schema,生成清洗 SQL。}, ], tools: [ { type: function, function: { name: read_csv, description: 读取 CSV 文件, parameters: { type: object, properties: {path: {type: string}}, }, }, }, ], } result await swarm_run(etl_task) print(json.dumps(result, ensure_asciiFalse, indent2)) if __name__ __main__: asyncio.run(main())代码可以直接复制到本地,把api_key_env对应的环境变量配上,再把base_url替换成你自己部署的网关,就能跑起来。七、调这些 API 的几个细节(FAQ)Q1:五个模型都能用同一个客户端吗?可以。2026 年 7 月这五家都已经收敛到 OpenAI 兼容协议,只有 Claude Opus 4.7 在 Computer Use 场景下要走 Anthropic 原生 SDK(因为它要传截图 鼠标键盘事件)。普通 chat 调用走 OpenAI 兼容即可。Q2:K2.7-code 自托管的最低硬件门槛?实测 8×H100(80G)可以跑 fp16 的全量推理,8 卡是 MoE expert 并行的最低配置。如果走 INT8 量化,4 卡也行,但吞吐会掉 30%。如果你只跑 20 子 Agent 以内的 Swarm,4 卡量化版够用。Q3:为什么 Qwen3.7-Max 上下文 1M 我用着感觉没那么神?1M 上下文是上限,不是默认值。接近 1M 时输入价格会阶梯式上浮。所以不要无脑塞,关键信息前置 长文档切片召回才是正确用法。Q4:DeepSeek R1 拿来跑 Agent Swarm 真的够用吗?单 Agent 任务够用。多 Agent Swarm 场景下,128K 上下文是硬约束,长链路子 Agent 跑 30 步以后基本就会忘记前面调过哪个工具。建议把 R1 定位成决策层 / 路由层,而不是主力执行层。Q5:Claude Opus 4.7 Computer Use 怎么接入?需要 Anthropic 原生 SDK 的tools字段传computer_use类型,并提供屏幕截图 base64。每一步调用都要回传鼠标坐标 键盘事件,延迟和成本都远高于普通 chat,适合屏幕操作这种 GUI 自动化任务,不适合纯文本 Agent Swarm。Q6:K2.7-code 的工具调用 schema 跟 Qwen3.7-Max 有差异吗?两者都兼容 OpenAI function calling 格式,但 K2.7-code 在嵌套参数、长 enum、optional 字段的解析上更稳。GLM-5.2 升级后基本追平,Qwen3.7-Max 在复杂 schema 上偶尔丢字段。八、参考资料本文测试覆盖的模型和接口文档来源:Kimi K2 / K2.7-code 官方开源仓库与文档(Moonshot AI)Qwen3.7-Max 技术报告(阿里通义实验室,2026)Claude Opus 4.7 Computer Use 文档(Anthropic)DeepSeek R1 论文与开源代码统一接口封装与价格采样见炻光 AI 接入管理平台。九、写在最后7 月这轮横评跑下来,三条经验留给真正要落地 Agent Swarm 的同行:1. 别再问哪个模型最强,问哪个任务用哪个模型。五个模型各有所长,真实生产里永远是组合拳。Claude Opus 4.7 跑屏幕、Qwen3.7-Max 跑长文、K2.7-code 跑工具链、DeepSeek R1 跑路由决策、GLM-5.2 跑中文场景——这才叫 Swarm。2. 成本监控比模型选择更重要。单次 Swarm 任务很容易失控,几个子 Agent 嵌套调用下来成本翻 10 倍是常事。设置单任务成本阈值 自动降级,这比挑对模型更能决定你的账单。3. 自托管 K2.7-code 是 7 月最被低估的选项。很多人一听1T MoE就吓退了,但只要你的 Swarm 任务量足够大,自托管的成本优势会被推理硬件折旧摊薄到接近 ¥1/1M tokens 的水平。前提是你得有一支能搞定 MoE 推理优化的团队。