AI 快讯美团龙猫2.5盯上长程编程
模型上新

美团龙猫2.5盯上长程编程

2026-09-26T08:12:27.243Z

美团上线LongCat-2.5-Preview:延续1.6T参数MoE架构,新增图像理解,并以100万Token上下文强化长程任务和多模态编程。

美团龙猫2.5盯上长程编程

美团在9月25日上线LongCat-2.5-Preview,并同步开放网页端体验与API服务。这次升级没有继续堆高总参数,而是把重点放在更实际的两个方向:让模型看懂图片,以及让它在超长、跨工具的编程任务中坚持得更久。

LongCat-2.5-Preview是美团推出的新一代多模态大模型,核心定位是处理长程任务、视觉信息和自动化编程。根据美团LongCat API开放平台更新日志及IT之家报道,模型总参数约为1.6万亿,每次推理平均激活约480亿参数,原生支持100万Token上下文窗口,并针对Claude Code、Hermes、OpenClaw、OpenCode和Kilo Code等开发环境进行了适配。

参数规模看起来惊人,但1.6T并不是这次发布最值得关注的数字。LongCat-2.0已经采用1.6T总参数、约48B平均激活参数的混合专家架构,因此2.5 Preview更像一次能力边界扩张,而不是重新训练了一个单纯“更大”的模型。

真正的问题是:它能否把100万Token、多模态理解和工具协同组合起来,变成可靠的长程执行能力。

1.6T参数,不代表每次都要跑1.6T

MoE是“混合专家模型”的缩写,指模型拥有大量分工不同的参数模块,但处理每个Token时只调用其中一部分。LongCat-2.5-Preview拥有约1.6万亿总参数,单次推理平均激活约480亿参数,激活比例约为3%。

这套设计可以类比一家拥有1.6万名专业人员的咨询公司:公司能力覆盖面很广,但面对一项具体任务时,不需要所有人同时开会,而是由路由系统挑选最相关的约480人参与。这样既能保留大模型的知识容量,也能把计算成本控制在更接近数百亿参数稠密模型的范围内。

不过,“只激活48B”不等于部署成本很低。模型的完整参数仍然需要被存储、切分和调度,专家之间的通信效率也会直接影响吞吐与延迟。MoE解决的是每个Token的计算量问题,并没有消除万亿参数模型对显存、网络带宽和工程基础设施的要求。

从已披露的信息看,LongCat-2.5-Preview延续了LongCat-2.0的基本规模,升级重点集中在能力层,而非体量层。

| 对比项目 | LongCat-2.0 | LongCat-2.5-Preview | 实际意义 | |---|---:|---:|---| | 总参数量 | 约1.6T | 约1.6T | 参数规模基本延续,2.5并非单纯扩模 | | 平均激活参数 | 约48B | 约48B | 保持MoE稀疏推理路线 | | 上下文窗口 | 原生1M Token | 原生1M Token | 可容纳大型代码库、日志和长文档 | | 图像理解 | 未作为核心能力强调 | 新增 | 可处理截图、图表、界面和跨模态问题 | | 编程定位 | Agentic Coding | 长程任务与多模态编程 | 从代码生成进一步走向持续执行 | | 工具适配 | 强调智能体编程 | Claude Code、Hermes、OpenClaw、OpenCode、Kilo Code | 降低进入现有开发工作流的门槛 |

100万Token的价值,是减少任务中途“失忆”

100万Token上下文是模型一次能够读取和参考的信息容量,适合装入超长文档、大型代码仓库、运行日志以及多轮工具调用记录。按粗略换算,它足以容纳数百万中文字符或一套规模可观的工程代码,但实际可用容量会受到文件结构、提示词、工具返回结果和输出预留空间影响。

超长上下文最直接的价值不是“能读一本更厚的书”,而是减少智能体在执行复杂任务时反复压缩、切片和召回信息的次数。

例如,一个模型需要为大型项目升级依赖时,可能要先读取包管理配置,再检索数百个调用点,随后修改代码、运行测试、分析报错并进行第二轮修复。任务链越长,早期获得的信息越容易在后续步骤中丢失。100万Token窗口可以让模型保留更多源码、错误日志和决策历史,为持续执行提供基础。

但上下文长度不等于上下文能力。模型能够接收100万Token,只说明输入窗口足够大;它是否能准确找到第80万Token附近的一处约束、是否会在数十轮调用后偏离目标、是否能区分关键日志和噪声,仍然需要长上下文检索、跨文件修改和真实仓库测试来验证。

因此,LongCat-2.5-Preview的关键指标不应只是“塞得进去多少”,而应是“隔了多远还能找对”。在官方公布更多基准测试之前,1M上下文是一项明确的产品能力,却还不能直接等同于稳定的百万Token推理。

新增图像理解,多模态首先服务开发场景

多模态理解是模型同时处理文本、图像等不同信息形式,并在这些信息之间建立关联的能力。LongCat-2.5-Preview新增图片理解,可用于图像内容解析、跨模态问答、内容摘要和复杂视觉推理。

对开发者来说,这项能力的意义不只是上传照片聊天。软件开发过程中本来就存在大量无法被纯文本模型直接读取的信息,例如网页截图、设计稿、监控图表、流程图、终端截图以及测试失败后的界面状态。

一个典型任务是:开发者上传产品原型图,让模型检查现有前端实现与设计稿的差异,再结合代码库修改组件。如果模型只能读代码,视觉对齐仍然需要人来完成;具备图像理解后,模型有机会把“看截图—定位组件—修改样式—再次检查”串成一条任务链。

另一个更现实的场景是排障。用户提交一张错误弹窗或监控曲线截图,模型需要先识别其中的报错信息和异常趋势,再进入代码库查询相关模块,并结合日志提出修复方案。这里的难点不是单次识图,而是视觉信息能否成为后续工具调用的可靠依据。

LongCat-2.5-Preview把图像能力与100万Token上下文放在同一版本中,方向是合理的。单独看图和单独读长文本都已经不是稀缺能力,真正有价值的是让模型把图片、源码、文档、日志和工具结果放进同一个任务状态中持续处理。

深度适配Claude Code,争的是开发入口

Agentic Coding是让模型自主读取项目、调用工具、修改文件、执行命令并根据结果继续迭代的编程方式。它与传统代码补全的差别在于,模型不再只写一个函数,而是承担一段包含规划、执行、检查和修正的完整流程。

LongCat-2.5-Preview明确强调与Claude Code、Hermes、OpenClaw、OpenCode和Kilo Code协同,说明美团争夺的并不只是聊天网页里的用户时长,而是开发者已经形成习惯的智能体入口。

这是一个务实选择。开发者通常不会因为底层模型更新,就立刻更换编辑器、终端工具和权限配置。新模型如果能直接进入现有工作流,迁移成本会明显降低。模型厂商也不必从头打造一套成熟的编程客户端,而可以把资源集中在推理质量、上下文管理、工具调用和服务稳定性上。

不过,兼容工具协议只是第一步。长程编程模型的竞争最终集中在四项能力:能否正确理解整个仓库,能否把复杂目标拆成可执行步骤,能否在工具报错后自行恢复,以及能否避免修改无关文件。

一次漂亮的代码生成并不难,连续执行几十步仍然保持目标一致才难。模型可能在第一轮准确定位问题,却在第五轮测试失败后开始重复尝试;也可能修复一个模块,同时破坏另一个隐含依赖。所谓“长程任务”,本质上考验的是状态管理和纠错,而不是上下文窗口数字本身。

没有公开跑分,现阶段不宜急着封神

LongCat-2.5-Preview当前最大的事实缺口,是官方更新信息尚未给出足够完整的第三方可复核成绩。现有信息可以确认模型的参数规模、上下文长度、图片理解能力和工具适配范围,但还不足以判断它与同期主流编程模型之间的真实差距。

社区已经出现关于实际速度、简单推理测试和免费体验额度的讨论,但这些零散体验没有统一提示词、采样参数、并发环境和评测集,不能替代标准化测试。尤其是单道“糖果题”之类的小样本测试,最多能暴露一次失败,无法推导模型整体推理能力。

评估LongCat-2.5-Preview,更值得观察以下指标:

  • 在真实代码仓库中完成问题修复的成功率,而非只看代码生成题;
  • 读取数十万Token后,对早期约束和跨文件依赖的召回准确率;
  • 连续工具调用中的失败恢复能力,以及是否会陷入重复循环;
  • 图像输入与代码修改结合时,能否把视觉判断落实到正确文件;
  • 长上下文开启后的首Token延迟、输出速度、服务稳定性与实际成本;
  • 模型进行大范围修改时,能否控制变更边界并保留用户已有代码。

对于开发者而言,最有效的测试也不是让模型写一个俄罗斯方块,而是交给它一项团队真实积压的任务:附上需求文档、仓库、设计截图和失败测试,观察它能独立推进到哪一步,以及人工最终需要接管多少工作。

美团这次押注的是“能干多久”,不是“会答多少”

LongCat-2.5-Preview的产品逻辑很清楚:用1.6T MoE架构承载能力广度,用约48B激活参数约束推理计算量,用100万Token保存任务现场,再用图像理解和开发工具适配扩展输入与执行范围。

这条路线比单纯刷新参数规模更接近当前开发者的真实痛点。代码模型已经普遍能够写出局部函数,下一阶段的差异将来自它能否读懂整套系统、跨越多种信息形式,并在较少人工干预的情况下完成长链条工作。

LongCat-2.5-Preview目前仍带有“Preview”标签,这意味着它更适合被视为能力预览和工程验证,而不是已经定型的生产级结论。企业如果准备用它处理私有代码库,还需要进一步核查数据保留政策、权限隔离、调用稳定性和输出可审计性,不能只依据上下文长度做决定。

美团这次没有靠“参数翻倍”制造新鲜感,而是试图把原有万亿参数底座推向多模态智能体。这个方向值得肯定,但它是否真正跨过长程任务的可靠性门槛,最终要看真实仓库成功率、长期运行稳定性和可复现评测,而不是1.6T这个醒目的数字。

参考来源

相关推荐

查看全部