美团正式开源 LongCat-2.0，并同步开放国产卡推理代码。这个模型拥有 1.6T 总参数，但平均每个 Token 仅激活约 48B 参数，目标不是停留在代码补全，而是处理需要理解仓库、修改文件、调用工具并根据执行结果继续修正的真实 Agentic Coding 任务。
1.6T 总参数不等于每次都计算 1.6T
LongCat-2.0 的关键数字是“总参数 1.6T、平均激活约 48B”。这意味着模型具备巨大的总容量，但在一次前向计算中只动态调用其中一部分参数。
对工程团队来说，需要区分三个概念：
- 总参数量决定权重存储、加载和分片的总体压力。
- 激活参数量更直接地影响单个 Token 的主要计算成本。
- 动态激活意味着不同输入可能经过不同的计算路径，因此吞吐、通信和负载均衡不能只根据 48B 这个数字静态推算。
48B 约占 1.6T 的 3%。这展示了稀疏模型扩大容量的思路，但并不代表部署成本自动等同于普通 48B 稠密模型。完整权重仍需要存放，跨设备路由和通信也可能成为瓶颈。评估国产加速卡部署时，至少应同时记录显存或高带宽内存占用、首 Token 延迟、持续解码吞吐、设备间通信和长上下文下的稳定性。
长上下文为何对 Coding Agent 更重要
普通代码补全通常只观察当前文件附近的内容，而 Agentic Coding 会接触更多状态：目录树、多个源文件、测试日志、构建配置、工具返回值以及此前的修改记录。上下文一旦变长，模型既要找到相关信息，也要避免被大量无关文本干扰。
LongCat-2.0 在架构上引入 LongCat 稀疏注意力和 N-gram Embedding。根据公开摘要，这两项设计分别面向长上下文处理效率和 Token 级表示能力，并与动态激活结合，强化代码理解、生成和执行表现。
可以从工程视角理解它们试图解决的问题：
- 稀疏注意力减少长序列中不必要的全量交互，让模型更有机会处理大型仓库上下文。
- N-gram Embedding 为连续 Token 片段提供更直接的表示能力。代码中频繁出现运算符组合、限定名、调用片段和重复语法结构，这类局部模式可能从中受益。
- 动态激活让模型按输入选择部分参数，为扩大知识与能力容量提供另一条路径。
不过，架构优势最终仍应通过仓库级任务验证。只测单轮生成速度，很难判断模型能否正确定位文件、保留接口兼容性、执行测试并根据错误继续修复。
可以这样搭建一个最小 Agentic Coding 评测器
下面是一个可直接改造的 Python 示例。它假设推理服务提供 OpenAI 兼容的 /v1/chat/completions 接口；这只是通用接入示例，并不表示开源代码必然使用该协议。
运行前设置 BASE_URL、MODEL，如果服务需要鉴权，再设置 API_KEY。脚本仅允许读取工作目录中的文件和运行预先批准的测试命令，避免把模型输出直接交给任意 Shell。
#!/usr/bin/env python3
import json
import os
import subprocess
import urllib.request
from pathlib import Path
BASE_URL = os.getenv("BASE_URL", "http://127.0.0.1:8000/v1")
MODEL = os.getenv("MODEL", "longcat-2.0")
API_KEY = os.getenv("API_KEY", "")
WORKSPACE = Path(os.getenv("WORKSPACE", ".")).resolve()
def chat(messages):
payload = json.dumps({
"model": MODEL,
"messages": messages,
"temperature": 0.1,
"max_tokens": 1200
}).encode("utf-8")
headers = {"Content-Type": "application/json"}
if API_KEY:
headers["Authorization"] = f"Bearer {API_KEY}"
request = urllib.request.Request(
f"{BASE_URL}/chat/completions",
data=payload,
headers=headers,
method="POST"
)
with urllib.request.urlopen(request, timeout=300) as response:
result = json.load(response)
return result["choices"][0]["message"]["content"]
def repository_context():
files = []
for path in sorted(WORKSPACE.rglob("*")):
if path.is_file() and ".git" not in path.parts:
relative = path.relative_to(WORKSPACE)
if path.stat().st_size <= 20_000:
files.append(str(relative))
if len(files) >= 200:
break
return "\n".join(files)
def run_approved_test():
command = ["python", "-m", "pytest", "-q"]
completed = subprocess.run(
command,
cwd=WORKSPACE,
text=True,
capture_output=True,
timeout=180,
check=False
)
return completed.returncode, (completed.stdout + completed.stderr)[-8000:]
messages = [
{
"role": "system",
"content": (
"你是代码仓库维护代理。先分析目录，再提出最小修改方案。"
"不得虚构文件，不得要求执行破坏性命令。"
)
},
{
"role": "user",
"content": (
"任务：修复失败的测试，并保持现有公开接口兼容。\n\n"
"仓库文件列表：\n" + repository_context()
)
}
]
analysis = chat(messages)
print("=== Model analysis ===")
print(analysis)
return_code, test_output = run_approved_test()
messages.append({"role": "assistant", "content": analysis})
messages.append({
"role": "user",
"content": f"测试退出码：{return_code}\n测试输出：\n{test_output}\n请给出下一步修改建议。"
})
print("\n=== Recommendation after test ===")
print(chat(messages))
可以在一个带测试的 Python 仓库中这样运行：
export BASE_URL=http://127.0.0.1:8000/v1
export MODEL=longcat-2.0
export WORKSPACE=/path/to/your/repository
python agent_eval.py
这个示例故意不自动写文件。生产级 Agent 应将“模型提议”“补丁应用”“命令执行”和“结果验收”拆成独立步骤，并为写入路径、命令参数、运行时长和网络访问设置明确边界。
国产卡部署不能只看能否启动
同步开放国产卡推理代码降低了适配和复现门槛，但实际采用仍取决于硬件、驱动、通信库和推理框架的具体组合。来源摘要没有给出支持的设备型号、量化方案或服务接口，因此部署时应以项目实际发布的兼容矩阵和配置为准。
建议把验收拆成四组指标：
| 维度 | 建议观测项 |
|---|---|
| 正确性 | 单元测试通过率、补丁可应用率、接口兼容性 |
| Agent 能力 | 工具调用成功率、平均修复轮次、任务完成率 |
| 推理性能 | 首 Token 延迟、输出 Token/s、并发吞吐 |
| 系统稳定性 | 峰值内存、长上下文错误率、跨卡负载均衡 |
同一批任务还应固定提示词、采样参数、最大上下文和工具权限。否则，模型效果与推理后端优化会混在一起，难以判断性能变化究竟来自模型、硬件还是 Agent 工作流。
采用前的检查清单
LongCat-2.0 值得关注的地方，不只是 1.6T 的参数规模，而是稀疏注意力、N-gram Embedding、动态激活和国产卡推理代码共同指向了一个更具体的目标：让大模型进入真实的软件工程执行链路。
落地时可以按下面的顺序推进：
- 先用内部仓库构建可重复的修复任务集，不要只依赖公开代码题。
- 将编译、测试和静态检查结果作为验收标准，而不是只看回答是否流畅。
- 在相同任务上对比短上下文与长上下文，确认额外输入确实提高成功率。
- 单独压测长上下文和多卡通信，避免平均激活参数量掩盖系统瓶颈。
- 默认隔离 Agent 的文件、Shell、网络和凭据权限，并记录完整审计日志。
对于准备在国产加速卡上建设 Coding Agent 的团队，这次开源提供了新的模型与推理实现选择。是否进入生产环境，仍应由仓库级任务成功率、端到端延迟、硬件利用率和安全边界共同决定。