美团在 9 月底放出了新一代大模型 LongCat-2.5-Preview（2026-09-28 AI 工具集专页口径，转述美团官方）。纸面规格有两个抓眼球的点：一是体量，MoE 稀疏激活架构，总参数 1.6T，即 1.6 万亿，每次推理只激活约 48B，也就是 480 亿；二是窗口，原生 1M token 上下文，最大输出 128K tokens。多模态方面新增图片理解，原生并入基座，多模态路线承袭 LongCat-Next 验证的 DiNA（离散原生自回归）范式，把模态词法化为离散 token 统一建模（转述口径）。产品定位延续了 LongCat 系列的 Agentic Coding 基因，官方把目标场景指向终端、浏览器、GUI、电子表格、设计工具等长流程自主操作。
但这些是发布稿的视角。对想把模型接进自己 Agent 工具链的开发者来说，真正值得关心的只有三件事：接口长什么样、要改多少代码、有什么坑。LongCat-2.5-Preview 的答案是 API 同时兼容 OpenAI 与 Anthropic 双协议，这意味着市面上绝大多数主流 Agent 工具都能以「改配置」而非「改代码」的方式接入，迁移成本被压到了配置文件层面。这篇 SOP 按门槛递进拆成三条路线：网页直接体验、OpenAI 协议接入、Anthropic 协议接入 Claude Code，每条都给可直接复制的最小配置示例。
动手前先交代两件事。一是分工边界：站内的美团 LongCat 2 与国产芯片训练线讲的是 LongCat 2 与国产芯片的训练侧故事，本文只谈 2.5-Preview 模型本身的接入实操，两篇互为内链不重复。二是必须提前说的冷思考：LongCat-2.5-Preview 目前没有任何公开 benchmark 分数，官方对比表中明确标注「无公开 benchmark」，所以本文不会引用任何测试成绩，你能依赖的只有自己的任务实测。这一点后文还会展开。
第零步：注册、Key 与 500 万 tokens 福利
三条路线共享同一个起点。到 LongCat 平台（longcat.ai/platform）注册账号并创建 API Key。计费模式是按 token 套餐，注册赠送 500 万免费 tokens（转述口径，以平台实际规则为准）。注册过程没有特殊门槛，常规邮箱流程即可。
500 万 tokens 是什么概念：按 1M 上下文满载粗算，大约只够五次满窗口调用；但对跑通接入、验证协议兼容性、拿自己的任务集做一轮小规模评测来说，这个量绰绰有余。建议把免费额度优先花在评测上而不是生产流量上，评测结论才有复用价值，生产放量再谈套餐选购。还有一个使用细节值得提醒：Agent 任务的平均 token 消耗远高于单轮对话，一次带工具循环的任务跑掉几万 tokens 很正常，预估用量时要按 Agent 口径而不是聊天口径来算。
Key 管理走老规矩：不进代码仓库、不进日志、按环境隔离、定期轮换，泄露立即吊销。后面所有配置示例里出现的 Key 占位符，都请替换成你自己的密钥，并通过环境变量或密钥管理服务注入，不要硬编码。
选型决策：三条路线对号入座
| 路线 | 适合谁 | 门槛 | 典型用途 |
|---|---|---|---|
| 网页直接体验 | 所有人 | 最低，打开官网即用 | 能力摸底、看图任务、小规模试用 |
| OpenAI 协议接入 | 有现成 OpenAI SDK 代码的团队 | 低，改两行配置 | 把模型接进现有 Agent 管线 |
| Anthropic 协议接入 | Claude Code 用户 | 低，配三个环境变量 | 终端编码与长流程 Agent 任务 |
选型口诀：只想看看模型什么水平，走路线一；现有系统基于 OpenAI SDK 或任何 OpenAI 兼容库，走路线二；日常主力工具是 Claude Code，走路线三。路线二与路线三不互斥，双协议意味着同一个模型 ID 可以同时服务两套工具链，很多团队会两条并行，按任务类型分配流量。
路线一：网页直接体验，零配置摸底
LongCat 官网（longcat.ai）提供网页对话入口，注册后直接可用。它支持上传图片，所以可以做一些简单的 Agent 式任务：贴一张报错截图让它定位问题、传一张表格截图让它整理数据、给一张设计稿让它输出前端页面描述。图片理解是 2.5 相对 2.0 时代的结构性变化，原生并入基座后不再依赖拆分的独立仓库，网页端就能直接验证这块能力。
不过要清楚网页形态的边界：长流程自主操作这类 Agent 能力，网页端能验证的部分有限，真正的工程验证要靠后面两条路线。另外，网页端与 API 的行为可能存在差异，网页上好用的表现不能直接等价于 API 调用的表现，最终结论以接口实测为准。这一步的产出物建议是一份小任务集：挑五到十个你业务里最典型的任务，记录网页端的表现。后面接 API 时，这就是你评测集的雏形，免费额度的花法也因此有了明确的优先级。
路线二：OpenAI 协议接入，改两行配置就完事
这是存量代码最多、改动最小的一条路。OpenAI 协议端点为 base_url=https://api.longcat.ai/openai，模型 ID 为 LongCat-2.5-Preview。如果你的现有项目用的是 OpenAI 官方 SDK 或任何兼容库，理论上只需要改两处：base_url 与 API Key，模型名换成 LongCat-2.5-Preview。Python 的最小示例：
from openai import OpenAI
# 只改这两行：base_url 换成 LongCat 端点，api_key 换成平台密钥
client = OpenAI(
api_key="填入你的 LONGCAT API KEY",
base_url="https://api.longcat.ai/openai"
)
# 模型 ID 逐字照抄，注意大小写与连字符
resp = client.chat.completions.create(
model="LongCat-2.5-Preview",
messages=[
{"role": "user", "content": "把这份需求描述拆成带验收标准的开发任务清单"}
]
)
print(resp.choices[0].message.content)三个实操提醒。第一，模型 ID 是 LongCat-2.5-Preview，逐字照抄，Preview 阶段不要自己写简称或别名。第二，工具调用等标准 OpenAI 请求字段按官方兼容口径使用，具体字段行为以官方文档为准，上线前逐一验证，不要凭假设裸奔。第三，既然是 Preview，把模型 ID 与 base_url 集中放在配置层，别散落在业务代码里，后面换模型或换端点时你会感谢这个决定。
接入跑通后，别急着上生产。先用第零步攒的任务集跑一轮小流量评测，重点看三项：工具调用成功率、长上下文下的指令遵循、输出格式的稳定性。这三项是 Agent 场景最容易出问题的位置，也是不同模型之间差异最大的位置，实测数据比任何发布稿都可靠。
路线三：Anthropic 协议接入 Claude Code
如果你是 Claude Code 用户，这条路的体验最接近「无感切换」。按官方教程口径，配三个环境变量即可：
# Anthropic 协议端点
export ANTHROPIC_BASE_URL="https://api.longcat.ai/anthropic"
# 平台密钥
export ANTHROPIC_AUTH_TOKEN="填入你的 LONGCAT API KEY"
# 模型 ID
export ANTHROPIC_MODEL="LongCat-2.5-Preview"
claude三个变量各司其职：ANTHROPIC_BASE_URL 把请求指到 LongCat 的 Anthropic 协议端点，ANTHROPIC_AUTH_TOKEN 带上平台密钥，ANTHROPIC_MODEL 指定模型。配置完成后，Claude Code 的请求就会走 LongCat-2.5-Preview，工具调用、文件编辑、长会话这些能力按 Claude Code 的既有流程使用，工作习惯完全不用改。
切换后的第一件事是冒烟验证：跑一个带工具调用的小任务，确认请求真的走到了新端点，而不是还在用默认配置。最直接的证据是平台侧的用量统计出现变化，配合响应表现做双重确认。这一步只花一两分钟，却能避免「以为切了其实没切」的经典事故。
官方教程同时点名了一批同类工具：Codex、OpenClaw、OpenCode、Kilo Code、Hermes 等，接入逻辑同理，都是改 base_url 与模型名。速查如下：
| 工具 | 改法（官方教程口径） |
|---|---|
| Claude Code | 设 ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL 三个环境变量 |
| Codex、OpenClaw、OpenCode、Kilo Code、Hermes 等 | 改 base_url 与模型名，端点与模型 ID 认准上文 |
把环境变量写进 shell 配置文件时注意作用域：建议按项目或按终端会话注入，而不是全局写死，这样官方模型与 LongCat 之间可以随时切换，也方便做对照评测。如果你的 Agent 栈还在选型阶段，站内有几篇现成的参考：编码 CLI 工具看MiniMax Code CLI 资源篇，Codex harness 开源生态看这篇热点，DeepSeek 系 harness 看这篇梳理，编码 IDE 的横向对比则在这篇横评。
1M 上下文与 128K 输出怎么用才不浪费
窗口规格是 2.5-Preview 最值得单独展开的部分，但大窗口不等于无脑塞满，用错了反而又贵又差。
先说 1M 上下文的适用面。Agent 场景里它真正发挥价值的地方有三类：整仓或大部分仓库代码一次性载入做跨文件理解、长会话轨迹完整保留做长程任务、大批文档合并喂入做汇总分析。同时要认清长上下文的代价：塞进去的每个 token 都计费，而且与任务无关的噪声会稀释模型对关键信息的注意力，Agent 决策质量反而下降。实操原则是按任务裁剪上下文，把 1M 当作上限而非目标，真正需要大窗口的场景才值得喂满。
再说 128K 最大输出。单次响应能吐 128K tokens，意味着大文件生成、长报告输出可以一次成型，Agent 写多文件项目时的截断风险显著降低。但输出越长，人工 review 成本越高，建议在系统提示里约定输出结构，让长输出可分段验收，而不是一整块无法局部确认的文本。两者组合起来看，1M 进加 128K 出给长流程 Agent 任务的完整管线留足了空间，你要做的是在管线设计里把上下文的进与出都当成显式管理的资源，而不是默认参数。
成本参照：站内对比表口径显示，Claude Opus 5.5 的定价为每百万 tokens 输入 4 美元、输出 20 美元（约合 29 元与 143 元），上下文同样 1M、最大输出 128K，但仅提供 Anthropic 协议。LongCat-2.5-Preview 按 token 套餐计费，具体单价以平台页面为准，接入前先按自己的预估调用量算一笔账，再决定评测与生产的流量分配。
当前的局限：三件事必须心里有数
第一，没有公开 benchmark。这是本文反复强调的冷思考：官方对比表中 LongCat-2.5-Preview 一栏标注「无公开 benchmark」，本文也严格遵守这条纪律，不引用任何分数。对你而言，这意味着一切「它比某模型强」的说法都不可信，包括发布稿里的定性描述。唯一可靠的办法是拿自己的任务集实测，注册赠送的 500 万 tokens 正好够干这个。
第二，权重未放出。截至 2026-09-29，GitHub 的 meituan-longcat 组织经实核 30 个仓库，没有 LongCat-2.5-Preview 的仓库；组织最新推送是 9 月 24 日的 LongCat-DeepResearch（9 星）与 WBench（240 星），既有模型仓是 LongCat-2.0（565 星，MIT）、LongCat-Flash-Chat（1367 星，MIT）、LongCat-Video（8439 星，MIT）等。也就是说，2.5-Preview 目前只通过 API 提供，想本地部署或基于权重微调的团队暂时没有这条路，只能等后续动作。开源旗舰模型的整体格局，可以参考站内的开源旗舰横评。
第三，Preview 阶段一切可能变。模型 ID、端点、参数行为、价格套餐都可能调整。工程上的对策很简单：把所有 LongCat 相关配置收敛到一个配置模块，业务代码只依赖抽象接口，模型升级或回退都只改一处。这一条对任何 Preview 模型都适用，不是 LongCat 特有的问题，但它决定了你的接入工程是三分钟还是三天的差别。
常见问题
Q1： LongCat-2.5-Preview 的 benchmark 成绩怎么样？
A1： 没有公开 benchmark，官方对比表中明确标注这一点，任何第三方引用的分数都不可信。建议用注册赠送的免费 tokens 拿自己的任务集实测，重点看工具调用成功率与长上下文下的指令遵循。
Q2： 权重能下载吗，可以本地部署吗？
A2： 截至 2026-09-29 不能。meituan-longcat 组织没有 2.5-Preview 仓库，模型只通过 API 提供。组织内开源的是 LongCat-2.0、LongCat-Flash-Chat、LongCat-Video 等模型，均为 MIT 许可。
Q3： 500 万免费 tokens 怎么拿，够用吗？
A3： 到 longcat.ai/platform 注册即可获得（转述口径，以平台规则为准）。跑通双协议接入、做一轮小规模评测足够；按 1M 上下文满载粗算大约五次满窗口调用，建议优先花在评测上。
Q4： 现有 OpenAI SDK 项目要改多少代码？
A4： 理论上只改两行：base_url 换成 https://api.longcat.ai/openai，API Key 换成 LongCat 平台密钥，模型名填 LongCat-2.5-Preview。上线前用真实任务回归一遍工具调用与长上下文场景，确认兼容行为符合预期。
Q5： 1M 上下文是越多越好吗？
A5： 不是。每个 token 都计费，且无关内容会稀释注意力、拖累 Agent 决策质量。1M 是上限不是目标，按任务裁剪上下文，长会话与整仓代码这类真正需要大窗口的场景才值得喂满。