Kimi K3携1M上下文上线，七大伏笔全串起

#探寻人工智能，人与AI全新序章#

刚写完“Kimi Code 连更数版，K3 可能要来”的分析，谜底就自己跳了出来。

7 月 16 日，Kimi Code 页面出现了非常直接的提示：K3 已经上线，最高支持 100 万 Token 上下文，并针对编程、3D 游戏和复杂知识任务进行了优化。

更关键的是，Kimi Code 团队负责人 Kai 也终于公开确认：现在的 Kimi Code 已经用上了 K3。他甚至开玩笑说，用多了 K3，再看 Claude 和 GPT 都有点“菜”。

这句话当然不能当成严谨评测，但它至少消除了最后一层悬念：K3 不是还在 PPT 上，也不是只存在于小范围匿名测试里，而是已经进入真实产品，开始接用户的活了。

回头再看 Kimi Code 过去一段时间那一串密集更新，模型刷新、子代理扩权、长任务放宽、失败重试增加、思考机制调整、多模态输入和用量系统补齐，原本像七块散落的拼图，现在终于拼成了同一幅图。

不是“即将发布”，而是已经开始提供服务

这一次，K3 没有等一场发布会把参数、榜单、价格和演示一次性端上来，而是先从 Kimi Code 打开了入口。

页面弹窗写得很清楚：K3 现已上线，最高支持 1M 上下文。这里的措辞不是“即将推出”，也不是“敬请期待”，而是已经可以使用。

这也解释了一个看起来有些矛盾的现象：有人已经在 Kimi Code 里体验 K3，但普通用户在其他入口里仍未必能看到完整的 K3 信息。它更像一次产品端抢跑——模型先进入真实工作流，完整发布信息再陆续补齐。

这种上线方式并不奇怪。编程 Agent 对底层模型的升级，完全可以先在服务端完成。用户继续使用原来的产品入口，后台却已经换上了新引擎。

所以，K3 的大门已经打开，只是发布大厅还没有完全布置好。

内部团队终于能说了：Kimi Code已经换上K3

真正让这次上线“坐实”的，不只是页面上的一句话，还有来自产品团队内部的正面确认。

Kimi Code 团队负责人 Kai 在 X 上说，自己“憋了太久，终于能聊 K3”，并明确表示，当前的 Kimi Code 是由“K3 + Kimi Code”构建的。

他还用了一个很有传播力的说法：K3 用多了，感觉 Claude 和 GPT 有点“流口水（菜）”。随后又补了一句，好消息是 K3 终于发了，坏消息是自己也要和大家一起抢容量。

先别急着把这句话剪成“K3 已经全面碾压 Claude 和 GPT”。Kai 是直接参与产品的人，他的判断有很强的体验价值，但也天然带有团队立场，而且没有给出统一任务、相同配置和可复现过程。

不过，这条信息仍然很重要。它说明三件事：K3 已经真实接入；内部团队对它的能力提升相当有信心；当前最现实的瓶颈，可能已经从“模型能不能用”变成了“上线后容量够不够用”。

1M上下文，不是把聊天记录简单拉长4倍

K3 目前最明确、也最容易被低估的升级，是最高 100 万 Token 上下文。

如果把此前 256K 量级的窗口作为参照，1M 接近四倍。但它真正的意义，并不是让聊天记录从一百页变成四百页，而是让编程 Agent 的“工作台”突然变大了。

过去，一个模型面对大型项目时，经常要在代码、需求、日志和历史修改之间反复取舍。读了后面的文件，可能忘了前面的约束；修了当前报错，又可能破坏另一处逻辑。上下文扩大以后，它才有机会把更多代码文件、产品文档、测试记录、报错日志和操作历史同时摆在桌面上。

对于普通对话，长上下文意味着“能聊得更久”；对于 Kimi Code，它可能意味着一次理解更大的仓库、跨越更长的任务，并在多轮修改之后仍然记得最初目标。

但窗口大，不等于记得准。仓库能全部装进去，不代表模型一定能找到最关键的那几行代码。K3 接下来要证明的，是接近 1M 时还能否准确检索、稳定推理，以及速度、费用和额度是否可接受。

1M 是入场券，不是免试金牌。

X上的第一批体验：一边惊艳，一边泼冷水

K3 上线后，X 上很快出现了第一批试用反馈，而且两种声音都很典型。

开发者 NZ 展示了一次视频转代码任务：K3 仅凭视频复刻出完整页面，整个项目一次生成成功，用时约 25 分钟。他特别强调了细节完成度，以及模型端到端把项目做完的能力。

这类案例能说明 K3 在视觉理解、前端生成和长链路执行上的上限。它不是只吐出一个静态页面，而是要连续观察视频、推断交互、组织代码并完成交付。

但另一位开发者 Ed 给出了完全相反的提醒。他承认 K3 的 UI 表现很强，甚至可能优于部分顶级模型；可当任务换成真实代码库里的 Bug 定位时，K3 没找到问题，也没有修好，还开始编造解释。相同任务交给 Fable 5 和 GPT-5.6 后，两者都一次完成了修复。

这两条体验并不互相否定，反而恰好勾勒出 K3 当前最值得观察的边界：生成一个漂亮的新东西，与读懂一个混乱的旧系统，是两种完全不同的能力。

前者考验视觉、代码生成和执行速度；后者考验架构理解、因果定位、克制幻觉和修改后的回归验证。K3 的首批演示已经足够吸睛，接下来真正决定口碑的，是第二类任务。

7个伏笔，现在全串起来了

再回头看 Kimi Code 近期的更新，许多当时不起眼的改动，现在都有了明确指向。

第一，模型目录从静态读取改成频繁刷新，是在为新模型随时切入做准备。

第二，子代理获得计划、待办、技能和继续分工的能力，是在让更强模型真正组织复杂任务，而不只是一次回答一个问题。

第三，后台任务放宽时间限制，是为了让长上下文转化为长时间工作能力。否则模型记得再多，也会在任务做完前被系统叫停。

第四，失败重试从少量次数大幅增加，是在给多步骤任务补可靠性。链路越长，中途一次网络波动或工具失败造成的损失就越大。

第五，思考强度和上下文缓存连续调整，很可能是在适配新的推理节奏和更大的窗口。

第六，文件、图片和视频输入逐步打通，让 K3 面对的不再只是提示词，而是现实工作中混杂的需求文档、界面、录屏和项目资料。

第七，充值、用量、诊断、安全和会话恢复同时补齐，解决的是新模型上线后，大量用户涌入时产品能不能扛得住。

单看任何一项，都像普通版本更新；当 K3 真正在产品里出现，这七项改动就像一条提前铺好的跑道。

为什么K3先上Kimi Code，而不是先开发布会

因为编程 Agent 可能是检验新模型最残酷、也最有价值的场景之一。

聊天机器人答错一句话，用户追问一次也许就过去了。编程 Agent 一旦在第一步理解错需求，后面的读文件、改代码、跑测试、调用工具和分配子任务都可能一起跑偏。

它不仅要“会答”，还要记得住、做得完、失败后能恢复，并且知道什么时候该把任务交给子代理，什么时候必须自己验收。

把 K3 先放进 Kimi Code，相当于直接送进真实考场。用户的代码库不会为了模型精心整理，报错也不会像基准题一样给出标准提示。哪里会忘、哪里会重复修改、哪里会调用工具失败，很快就会暴露。

从产品角度看，这也是更聪明的发布路径：先让模型在高价值场景里产生真实反馈，再决定如何扩展到更多入口。Kimi Code 既是 K3 的首发产品，也是一块大规模压力测试场。

真正值得测的，是长任务完成率

接下来，社交平台上一定会出现更多 K3 生成网站、动画、3D 游戏和仿操作系统的演示。这些内容适合传播，却未必能测出 1M 上下文最核心的价值。

更有意义的测试，是把一个包含大量文件的真实项目交给 K3：先理解架构，再定位跨模块问题；同时给它需求文档、设计图、历史代码和测试日志，让它连续工作数小时，并在出错后自主恢复。

还要观察它能否在十几轮修改后继续遵守第一轮提出的限制，子代理之间会不会重复劳动，主代理能否发现子任务交付里的隐患，以及接近 1M 上下文时能不能准确找回早期信息。

对于 K3，最值得看的不是“第一次生成的画面够不够炸”，而是三个更朴素的问题：

它有没有真正理解？

它能不能坚持做完？

它交付的东西能不能直接使用？

如果这三道题都能稳定答好，1M 才会从一串醒目的数字，变成真正的生产力。

K3已经赢了吗？真正的考试才刚开始

现在可以确认的事实已经足够清楚：K3 已经进入 Kimi Code，1M 上下文已经作为产品能力亮相，内部团队也公开确认完成切换。

但目前仍然缺少几块关键拼图：完整架构和参数还没有完全展开，开放权重与调用方式仍待观察，1M 在不同套餐下的速度和消耗也需要实测，更缺少统一条件下的大规模独立对比。

团队负责人的一句“Claude、GPT 有点菜”很有冲击力，却不能替代基准和复现；一次视频转代码的惊艳演示，也不能抵消真实代码库调试中的失败。反过来，一位开发者的一次失败体验，同样不能给整个模型判死刑。

K3 真正要争的，不是一晚上的热搜，而是未来几周里，开发者愿不愿意把越来越难、越来越长、越来越真实的任务继续交给它。

所以今天最准确的结论不是“K3 已经赢了”，而是：

大事不再只是将临。

门已经打开，真正的考试现在才开始。