19. 截至 2026 年 10 月：模型能力与应用边界推进到了哪里

来源：大模型技术演进

2026 年 7 月 17 日，月之暗面发布 Kimi K3。公告里的主角，已经不只是一个更会回答问题的聊天模型：它把原生视觉、百万 token 上下文和长时间编程放到了一起，展示模型怎样借助终端、截图和运行结果继续推进工作。十天后，模型权重与技术报告开放，开发者又多了一条自行部署、研究和改造的路径。K3 发布公告、权重开放公告

到了 9 月，竞争仍在加速。Anthropic 发布 Claude Fable 5.1 与 Mythos 5.1，强调长任务和知识工作；9 月 30 日，Google 公布 Gemini 4 Argon，把复杂工程和专业工作流程作为主要场景，但首先向受信任的网络防御伙伴开放。Anthropic 公告、Google 公告

把这些发布与 2022 年末放在一起看，变化的分量才显出来。当时，公众第一次大规模体验到：计算机竟然可以通过自然对话解释知识、起草文章和编写代码。不到四年，厂商开始竞争另一件事：模型能否读懂一堆材料，操作工具，持续工作，发现自己做错了，再把结果修好。

上一篇的 OpenClaw 热潮，正是这种期待进入个人生活的表现。不过，助手可以常驻，并不能说明它能可靠完成任何事情。本篇把观察时间固定在 2026 年 10 月 3 日，沿着推理、编程、多模态、上下文和工具使用，看看能力究竟推进到了哪里。

这里介绍的是能说明变化的代表节点，不是一张模型总排行榜。公开发布、产品可用、API 可用、开放权重，是不同的事实；厂商展示的成功案例，也不能直接当成所有用户都会获得的结果。

从解出一道题，到持续解决一个问题

在推理模型兴起时，我们最容易感知的进步，是模型愿意花更多计算处理数学、代码和复杂约束。到了 2026 年，问题进一步变成：这些推理能不能在真实工作中连续发生？

一道题通常有相对完整的题面。修复一个软件故障却不同：最初只有“保存后数据不见了”这样的描述。模型要判断读哪些文件、怎样复现、缺少什么证据，再根据测试结果修改判断。第一次猜错以后是否会调整，比第一次解释是否漂亮更重要。

这种能力不是单靠扩大参数量获得的。智谱在 GLM-5.3 的官方仓库中明确说明，它沿用 GLM-5.2 的基础模型，提升来自后训练，重点包括复杂编程和长任务。GLM 官方仓库

“后训练”可以先理解为：模型已经获得广泛的语言和知识能力，再通过任务、反馈和训练方法，改善它如何运用这些能力。用于 Agent 的训练，还需要让模型接触行动之后出现的新情况，例如工具报错、测试失败、信息不足或多个要求相互冲突。

另一条路线仍然包含扩大基础模型。9 月 21 日发布的 Grok 4.7，就同时采用了更大的基础模型和更长的强化学习训练，并把需要较长时间完成的任务纳入训练重点。Grok 4.7 公告

这两个例子放在一起，说明我们不能用一个“模型越来越大”概括所有进步。基础模型、训练任务、反馈质量以及运行时愿意投入的计算，都可能改变最终表现。

应用因此能尝试承担更完整的工作，但目标仍然需要明确。让模型“把我的项目做好”，和让它“修复导入失败，保留原有记录，并用三种输入文件验证”，给出的判断依据相差很大。模型越能连续行动，模糊要求造成的返工也可能延伸得越远。

编程、视觉和工具，开始在同一任务里协作

以前我们很容易把能力分开讨论：语言模型负责写代码，视觉模型负责看图片，自动化脚本负责操作软件。到这一阶段，多种能力开始围绕同一个任务配合。

Kimi K3 的发布材料，把利用截图反馈改进前端、游戏和 CAD 工作作为编程能力的一部分。这里的意义不只是“模型能看图”，而是它可以把看到的问题与刚刚修改的代码联系起来。这个方向与第 14 篇讨论的运行、验证循环接上了。K3 编程与视觉示例

例如，一个页面能够正常编译，按钮却被浮层挡住，文字在窄屏上也溢出了。只读构建日志，很难发现这些问题；看到页面截图以后，模型多了一类纠错依据。要把问题真正修好，应用仍需提供截图、代码编辑和运行工具。

MiniMax 在 6 月 1 日发布的 M3，同样把百万 token 上下文、图像与视频输入、编程和电脑操作放进一个模型的能力范围，并通过 MiniMax Code 与 API 提供使用入口。MiniMax M3 公告

这种结合拓宽了个人项目的可能性。你可以尝试让开发助手参考界面草图实现功能，再根据实际页面修正；也可以让应用读取一段操作录像，帮助解释用户在哪一步遇到了困难。

但需要分清三个层次：模型理解画面，应用提供操作工具，运行环境产生实际结果。 一个模型支持电脑操作，不代表给它发送一张截图，它就自动拥有你的鼠标、文件系统和登录状态。反过来，桌面客户端能够打开软件，也不代表模型每次都能选对目标。

字节跳动 6 月 23 日发布 Seed2.1 时，也将文件处理、跨工具任务、代码工程交付和视觉理解作为相互关联的能力，并同步接入豆包、TRAE 和火山引擎 API。Seed2.1 公告

由此可以看到，模型和产品的迭代越来越难完全分开理解。模型改进后，需要一个能把输入、工具和结果接起来的产品，用户才有机会感受到完整的变化。

多模态的重点，从“多一种输入”走向“完成一段工作”

2024 年的实时语音和视觉交互，让用户感受到自然交流的可能。到了 2026 年，多模态还在向另一端延伸：理解长音视频、定位具体内容，再参与编辑、整理和交付。

阿里 9 月 18 日发布的 Qwen3.8-Omni-Flash，是这个方向的代表。官方材料列出文字、图像、音频和视频输入，以及百万 token 上下文，并把工具调用和音视频工作流程作为重点；另有面向实时交互的 API。Qwen3.8-Omni-Flash 公告

对开发者来说，差别可以落到一个很具体的任务上：过去做视频笔记，可能先转录语音，再把文字交给模型；现在可以探索把讲解、画面里的图表和时间位置结合起来。讲者说“看左边这条曲线”时，文字转录本身没有提供足够信息，视觉理解就有了实际用途。

不过，理解视频与生成视频依然是不同能力。应用能输出一段成片，还可能需要剪辑工具、素材处理和专门的生成模型。不要因为某个产品同时能聊天、画图、配音，就默认它背后只有一个能做所有事情的模型。

OpenAI 的 GPT-6 Astra 文档提供了一个容易核对的例子：模型支持文本输入输出和图像输入，模型页没有把音频、视频列为支持模态；与此同时，Responses API 下可以配置图像生成等工具。调用绘图工具，与模型直接输出图像，是两回事。GPT-6 Astra 模型文档

因此，选模型时，“支持多模态”还不够具体。你需要知道应用要读什么、写什么，以及中间哪些工作交给其他工具。这比记住一个笼统的“全能模型”标签更有用。

百万上下文，解决了容量问题的一部分

从第 8 篇的长文档热潮走到这里，百万 token 已经出现在多家模型的规格里。它让整套项目资料、较大的代码上下文、较长的工具运行记录，有机会留在一次任务的工作范围内。

但两个容易混淆的数字需要分开。

上下文窗口描述模型处理一次请求时可容纳的信息范围；最大输出长度限制一次生成最多能延续多长。GPT-6 Astra 文档分别列出 1,050,000 token 上下文窗口和 128,000 token 最大输出。Google 对 Gemini 4 Argon 公布的百万 token 指标，则特别强调了输出上限的扩展。它们不能直接放进同一列比较“谁能读更多”。Astra 规格、Argon 输出说明

容量扩大以后，工作中的难点会继续变化。一本资料能放进去，不代表每个细节都被同样准确地使用；几百轮工具记录留在上下文里，也不代表模型始终分得清哪条结论已经被推翻。

考虑一个持续开发的项目：昨天的接口方案已经废弃，今天测试出的错误仍未解决，而最初的验收条件不能丢。把所有记录原样保留，会让关键信息与过时信息混在一起；压缩得太狠，又可能删掉仍然重要的约束。

所以，“保留什么、重新读取什么、把什么写成明确状态”越来越重要。Meta 7 月 9 日发布 Muse Spark 1.1 时，就将长任务中的上下文管理、工具与电脑使用放在一起介绍，并开放 Meta Model API 的公开预览。Muse Spark 1.1 公告

这也解释了为什么长上下文没有让 RAG 和持久化数据失去意义。你仍然需要找出相关资料，保留来源，把用户已完成的卡片或订单状态存成可查询的数据。更大的窗口增加了处理空间，应用仍要组织这个空间。

腾讯的变化：模型进步与产品交付开始接上

回顾中国厂商，腾讯在 2026 年值得放进这条主线，原因不只是公司规模，而是模型与工作产品出现了可以具体观察的结合。

腾讯 8 月 5 日的公告确认，Hy3 已于 7 月 6 日正式发布，并通过 WorkBuddy、Miora 和 TokenHub 扩大国际可用范围，也提供 API 接入。公告使用 Tencent Hy 名称，并说明其前身是 Tencent Hunyuan，也就是我们熟悉的混元品牌。腾讯 Hy3 公告

WorkBuddy 则属于应用产品。用户交给它的是整理材料、生成文件或制作应用这样的任务；Hy3 是可被接入的模型。不能把 WorkBuddy 的全部能力和表现，都直接归因于某一个自研模型。

一个很具体的产品节点发生在 9 月。腾讯云 CloudBase 团队 9 月 18 日介绍，WorkBuddy 前一天发布的 5.5.6 版本加入完整应用生成能力，启用云服务的应用由 CloudBase 提供数据库、登录、文件存储和发布环境。WorkBuddy 与 CloudBase 的集成说明

这件事为什么有代表性？因为用户说“做一个有登录功能的读书记录网站”，需要的远不止几段代码。页面要能运行，记录要有地方保存，不同用户的数据要有访问规则，还要得到能打开的地址。模型负责理解与生成，产品和云服务把这些环节连接起来，才形成可体验的结果。

这并不保证生成应用已经满足所有正式使用要求，却说明了产业竞争的变化：有影响力的产品，可以把模型进步转化为更多人的使用机会；真实使用暴露的问题，又为下一轮模型和产品优化提供方向。

成本要按一次完整任务计算

连续工作的 Agent 会读取资料、运行工具、观察结果并多次调用模型。这样的应用里，每百万 token 的价格仍然重要，却不足以代表总成本。

Google 在 9 月 2 日发布 Gemini 3.8 Flash 时，一方面强调延续 3.7 Flash 的速度和较低价格，另一方面也说明：复杂任务中增加推理和工具循环，可能消耗更多 token；开发者可以降低思考强度来控制开销。Gemini 3.8 Flash 公告

DeepSeek 的 9 月 10 日更新，则把 V4.1-Flash 的原生视觉理解、更快推理和 API 降价放在同一个节点，并使用 deepseek-flash 作为调用名称。能力覆盖扩大和价格变化，在这里共同影响应用能否做得起。DeepSeek 更新日志

可以用一个教学假设理解账单：方案甲单次调用便宜，却需要反复尝试、人工修正；方案乙单次贵一些，但更容易通过验证。最终应比较的是完成同一任务所消耗的模型调用、工具运行和人工检查，而不是只比较一次请求的报价。这个例子没有假定任何具体模型必然更划算。

个人项目因此有了更灵活的设计空间。给笔记分类、提取固定字段，可以先试成本较低的方案；处理相互矛盾的资料、诊断复杂故障，再调用更强的模型。是否值得这样分工，要用自己的任务验证，不能仅凭“大模型负责难题、小模型负责简单题”的口号决定。

缓存也会影响长任务成本：反复读取相同内容时，供应商可能提供不同于普通输入的计费方式。但缓存命中条件、上下文长度档位、输出与工具费用各不相同。做项目时，应记录完整任务的实际消耗，再决定是否调整。

怎样理解“能力边界已经推进”

把本篇的变化放到个人项目里，可以得到下面这张对应表。它描述值得尝试的设计方向，不承诺某个模型单独完成全部环节。

能力变化	可以尝试的任务	验证结果时要看什么
推理与长任务训练改善	拆解问题，依据失败结果调整方案	是否遵守原始约束，是否根据新证据改正判断
编程、视觉与工具结合	实现页面，运行后观察并修改	真实页面、用户操作和数据保存是否正确
音视频理解扩展	对照画面与讲解生成有时间位置的笔记	对应片段是否存在，画面和语音有没有被混淆
上下文容量与管理改善	综合成套资料，延续较长任务	是否漏掉关键资料，是否使用了过时状态
成本和效率改善	更频繁地分析、检查与迭代	每个合格结果的总费用、耗时和人工返工

这里还要跨过两道容易被忽略的边界。

第一道是可获得性。Fable 5.1 普遍开放，Mythos 5.1 则通过受信任访问计划提供；两者是同一底层模型采用不同保护措施，并非两个可以随意互换的公开档位。Argon 在本篇截止时也处于分阶段开放过程。另一方面，K3 已开放权重，也不等于普通笔记本具备运行完整模型的硬件条件。Anthropic 的开放范围、Argon 的发布阶段、K3 部署说明

第二道是评测与实际任务之间的距离。编程评测可能使用不同工具、运行环境、思考强度和尝试次数。有的统计最终完整成功，有的还给部分完成计分。模型名称相同，测试条件不同，分数也不能直接当成你项目的成功率。K3 发布材料就为不同评测列出了所用的运行框架和设置。K3 评测注释

回到前几篇的个人复习助手，假设你想加入“导入课程录像，生成带来源的卡片，再制作复习页面”。今天的模型让这一整段流程更值得尝试，但你仍应选一小段有图表、口述更正和易混术语的材料来检查：卡片能否回到正确片段，更正后的结论是否被采用，页面保存的数据是否能重新打开。这个教学构造，比询问模型“你是否擅长视频理解和编程”，更接近开发者需要的证据。

截至 2026 年 10 月，最值得把握的变化，是多种能力开始在持续工作的任务里互相支撑。更强的推理帮助决定下一步，视觉与长上下文补充证据，工具把判断变成行动，效率改善让更多循环有机会承担得起。

但当一次任务需要接入模型、读取资料、调用工具、保存状态和恢复失败时，开发者面对的已经是一套应用系统。下一篇将沿着这些实际需要，回看 LangChain、LangGraph、LlamaIndex 等开发框架怎样演进，以及它们为什么会在不同阶段变得重要。

---

上一篇：18｜2026 年初起：OpenClaw 与个人 Agent 生态热潮

下一篇：20｜应用变复杂之后，开发框架怎样演进

返回：第 0 部分大纲