Qwen3.8 vs Kimi K3：编程、Agent、上下文与 API 就绪度对比
快速结论：如果需要一个已有文档、当前可在 EvoLink 使用的长上下文编程、多模态或 Agent 路由，选择 Kimi K3。如果能接受不断变化的 Preview，并希望提前评估 Qwen 下一代旗舰，则测试 Qwen3.8 Max Preview。在可比路由、价格、限制和同任务结果出现前，不应直接用 Qwen3.8 替换 Kimi，也不能宣布 Qwen 获胜。
**名称辨析：**Qwen3.8 不是 Qwen3-8B。旧版 80 亿参数 Qwen3 模型的结果不属于这次比较。
选择结论
| 你的情况 | 当前更合适的选择 | 原因 |
|---|---|---|
| 需要现在通过 EvoLink 上线 | Kimi K3 | 路由、模型 ID、价格和文档已经可用。 |
| 想评估 Qwen 最新 Preview | Qwen3.8 Max Preview | Qwen Token Plan 已正式列出其推理、视觉理解和文本生成能力。 |
| 需要可预测的 API 成本 | Kimi K3 | 可以查询直连和 EvoLink 路由价格；Qwen3.8 标准 Token 价格尚无文档。 |
| 需要稳定的生产模型 ID | Kimi K3 | Qwen3.8 当前明确是可能被替换的 Preview ID。 |
| 计划开放权重部署 | 等待证据 | Qwen 已宣布开放权重，但最终包尚未提供；选择自部署路径前，也要单独核实 Kimi 当前的权重状态。 |
| 想找最强的编程 Agent 模型 | 执行同任务测试 | 公开定位和发布周 Demo 不能代替你的仓库、工具与验收标准。 |
截至 2026 年 7 月 21 日的已确认事实
本次对比特意把渠道专属 Preview 信息与生产 API 路由分开。
| 维度 | Qwen3.8 Max Preview | Kimi K3 | 生产影响 |
|---|---|---|---|
| 当前阶段 | Qwen Token Plan 官方 Preview | 已发布的 API 模型 | Kimi 目前拥有更成熟的生产路径。 |
| 公开标识 | Token Plan 中为 qwen3.8-max-preview | kimi-k3 | 不能假定 Qwen Preview ID 会保留到 GA 或与 EvoLink 一致。 |
| EvoLink 可用性 | 尚未可用 | 已可用 | 生产路由使用 Kimi；Qwen 页面用于追踪状态。 |
| 后端使用资格 | 个人 Token Plan 禁止自动化脚本、自定义后端和非交互批量调用 | 已记录生产 API 路由 | Preview 入口不等于可部署 API 入口。 |
| 已记录模态 | Token Plan 中的推理、视觉理解、文本生成 | Moonshot 文档中的文本、图片和视频理解 | 两者都值得做多模态评测，但渠道限制不同。 |
| 上下文证据 | Qwen Token Plan 模型列表记录 1M | Kimi 与 EvoLink 模型数据为 1,048,576 tokens | 标称窗口接近，但路由条款与检索质量仍不同。 |
| 推理控制 | Qwen Chat 文档列出 low、medium、xhigh | Kimi K3 文档列出 low、high、max；默认值可能因产品入口不同 | 配置并不等价，应比较实际能发布的设置。 |
| 直连价格成熟度 | Token Plan Credits；标准按 Token 价格未记录 | Moonshot 公布缓存输入、未缓存输入和输出价格 | 现在做精确的 Qwen/Kimi Token 数字对比为时过早。 |
| 生命周期风险 | Preview 可能变化或被替换 | 已有生产路由，但新发布模型仍需监控 | 保留回退，并把模型选择放进配置。 |
编程：有潜力的挑战者 vs 现在就能测试的路由
两款模型都在吸引编程与 Agent 用户，但证据成熟度不同。
Qwen 将 Qwen3.8 定位为编程、复杂推理、数据分析和专业工作流的重大升级。官方客户端配置还为 Preview 暴露了较大的推理预算，因此它值得用于仓库探索、多文件实现和长程规划测试。
Kimi K3 已有完整 API 路径和 EvoLink 路由。它最大的现实优势并不是所有公开跑分都偏向 Kimi，而是团队今天就能运行准确工作负载、检查用量、衡量延迟并判断结果能否通过验收。
不要只做通用 Prompt 擂台，使用下面的编程测试：
| 测试 | 验收标准 | 为什么能区分模型 |
|---|---|---|
| 现有仓库 Bug 修复 | 根因修复、测试通过、无无关修改 | 衡量诊断能力和仓库纪律。 |
| 跨模块功能 | 接口一致、迁移完整、回滚有记录 | 衡量跨依赖规划能力。 |
| 隐蔽代码审查 | 找到预埋缺陷、解释风险、给出有效修复 | 衡量判断力，而不是代码量。 |
| 前端实现 | 视觉、响应式、无障碍、可维护性 | 区分视觉吸引力与生产代码。 |
| 长时间工具任务 | 调用正确、注入失败后可恢复、不循环 | 衡量 Agent 的长期可靠性。 |
不要把 Token Plan 编程客户端中的 Qwen 运行与裸 Kimi API 调用直接比较，再把全部差异归因于模型。必须记录客户端、工具、上下文准备、推理配置和重试策略。
这里还有一道部署边界：Qwen 个人 Token Plan 条款禁止把订阅 Key 用于自定义应用后端、自动化脚本或非交互批处理。因此，编程客户端测试成功只能证明“可以评测”，不能证明“已有可发布后端路由”。本文认为 Kimi 当前更有优势的是 API 就绪度，而不是没有证据支持的“底层模型全面更强”。
Agent：Harness 会改变结果
Qwen 为 Token Plan Preview 记录了联网搜索、代码解释和网页提取等内置工具。Kimi 则提供有文档的 Tool Calling 行为，并要求长推理与工具循环正确保存状态。
这不是两个完全相同的评测环境。
| Agent 层 | 需要保持一致的内容 | 失败信号 |
|---|---|---|
| 目标与 Prompt | 相同任务、约束、文件和完成定义 | 某个模型收到更清晰的任务说明。 |
| 工具权限 | 相同可用工具和破坏性操作限制 | 模型因为工具更好而显得更强。 |
| 状态 | 保留所需 assistant、reasoning 和 tool 历史 | 模型循环或丢失早期决策。 |
| 时间与预算 | 相同超时与通过验收的任务预算 | 某个路由无限消耗才完成。 |
| 审查标准 | 相同通过/失败和严重程度定义 | 结果退化为主观偏好。 |
关键指标是无人协助完成率、无效工具调用、失败恢复、人工介入次数、通过验收所需时间和缺陷率。如果审查者必须修复结果，“完成”本身并不够。
上下文：窗口大小只是入场券
Kimi 文档给出 1,048,576 tokens 上下文，Qwen 当前模型列表也为 Qwen3.8 Max Preview 记录 1M。两者标称窗口已经接近，但路由并不因此等价：输入政策、输出预算、媒体处理、缓存行为和长上下文检索质量仍需要路由级证据。
即使两者能接受相近长度的文本，四种行为仍可能不同：
- 能否从大输入中找到正确证据；
- 能否在多轮中保持指令；
- 能否避免远距离段落间的矛盾；
- 能否通过缓存经济地利用重复上下文。
按 64K、256K、512K 和产品真正需要的最大长度分层测试。在受控位置插入已知事实，要求引用，并把检索得分与最终答案质量分开。若正常工作负载还没到上限时准确率就明显下降，百万上下文本身没有意义。
多模态：验证输入合同与视觉依据
Qwen Token Plan 模型列表包含视觉理解；Moonshot 则为 Kimi K3 记录了文本、图片与视频输入。这带来重叠场景，例如 UI 审查、文档分析、图表提取、视觉编程和多模态研究，但不代表输入合同完全相同。
公平评测应做到：
- 使用同一批源素材；
- 把 OCR 准确性与推理质量分开；
- 要求模型基于并指出视觉证据作答；
- 分别统计遗漏与虚构细节；
- 记录每条路由的预处理、采样和文件限制。
在 Qwen3.8 路由有文档前，不要声称它支持某种具体格式、时长、文件大小或 EvoLink 媒体路径。
API 就绪度：Kimi 赢在证据，而不一定是能力
API 就绪不只是模型名称出现在工具选择器里。
| 就绪门槛 | Qwen3.8 Max Preview | Kimi K3 |
|---|---|---|
| 稳定 EvoLink 路由 | 待确认 | 已确认 |
| EvoLink 模型 ID | 待确认 | 模型页/文档已确认 |
| EvoLink 价格 | 待确认 | 模型页已公布 |
| 生产示例 | 待确认 | EvoLink 文档已提供 |
| 速率与区域行为 | 未来路由必须验证 | 根据当前账户与文档验证 |
| 回退测试 | 当前无法在 EvoLink 完成 | 现在即可测试 |
这不能证明 Kimi 的模型能力更强，只能证明团队目前可以在 EvoLink 上为 Kimi 做预算、集成、观测和回滚。
成本：比较成功任务，而不是促销 Credits
Qwen3.8 当前通过 Token Plan Credits 推广。Credits 是订阅消耗单位，也可能有临时倍率，无法干净地换算成标准输入/输出 Token 价格；现在强行做美元对比只会制造虚假精度。
Qwen3.8 价格公布后，使用以下框架：
通过验收的任务成本 = 输入 + 缓存输入 + 输出 + 工具 + 重试 + 回退 + 审查时间像关注输入价格一样关注输出长度。产生更多 Token 或重复工具工作的推理模型，可能轻易抵消看似便宜的单价优势。
建议的 EvoLink 路由策略
| 路由角色 | 当前候选 | 晋级条件 |
|---|---|---|
| 生产长上下文与多模态路由 | Kimi K3 | 验收率、可靠性和成本持续达标。 |
| Qwen 下一代准备 | Qwen3.8 Max Preview 观察名单 | 冻结任务与验收规则，等待生产可用路由。 |
| 未来挑战者路由 | 若上线 EvoLink 的 Qwen3.8 | 只在同任务测试和路由验证通过后晋级。 |
| 供应商回退 | Claude、GPT 等受支持替代模型 | 发布前演练失败与回滚。 |
| 成本敏感日常路由 | 更小的受支持模型 | 仅把昂贵前沿路由留给真正获益的任务。 |
模型切换应发生在任务边界。保存可持久化的任务说明、仓库状态、产物和验收标准，不要在无关模型家族之间迁移正在进行的推理历史。
哪些情况下值得等 Qwen3.8
如果 Qwen 专属能力、已宣布的开放权重方向或 Qwen 工具体系是路线图核心，并且上线日期能承受不确定性，可以等待。
以下情况不应等待：
- 产品现在就能用受支持模型发布；
- 需要稳定模型 ID 和有文档的计费；
- 无法运营 Preview 回滚路径；
- 工作负载没有客观验收测试；
- 对客户的可用性承诺将依赖 Qwen 的时间表。
现在就用 Kimi 或其他可用模型构建评测 Harness，但在生产可用 API 路由出现前，不要投入大型 Qwen3.8 测试。即使它最终没有成为默认路由，这套 Harness 依然有价值。
常见问题
Qwen3.8 比 Kimi K3 更好吗？
目前没有足够的可比生产证据支撑这一结论。Qwen3.8 是仍在变化的 Preview，Kimi K3 有完整路由。等两者都能在计划发布的环境中运行后，再执行同任务测试。
现在编程应该用哪个模型？
如果现在需要 EvoLink 路由，使用 Kimi K3；如果可以使用 Qwen Preview 渠道并接受变化，则单独评测 Qwen3.8。
哪个模型上下文更大？
两款模型在当前渠道都记录了约 1M Token 的标称上限。这只能说明窗口大小接近，不能证明检索质量、输出额度、媒体支持或生产路由行为相同。
哪个模型更便宜？
Kimi 有已记录的 Token 价格。Qwen3.8 当前使用 Token Plan Credits 与促销倍率，因此还不能公平比较每 Token 成本。
两款模型都是多模态吗？
Moonshot 为 Kimi K3 记录了文本、图片和视频理解；Qwen Token Plan 列表为 Qwen3.8 Max Preview 记录了视觉理解。具体路由格式与限制不同，必须验证。
EvoLink 已支持 Qwen3.8 吗？
Qwen3.8 上线后应立即从 Kimi K3 迁移吗？
不应该自动迁移。重放相同工作负载，比较验收率、可靠性、延迟和成本，并保留 Kimi 或其他路由作为回退。
应该如何比较 Agent 可靠性？
在相同权限和预算下，衡量无人协助完成率、工具调用有效性、恢复、循环、介入次数、通过验收所需时间和缺陷率。
