万亿级MoE模型如何支撑长程Agent任务

一、背景：长程Agent正在重新定义基础模型

过去两年，大模型的主战场正从“单轮问答”转向“多步骤任务执行”。一个典型的长程Agent任务——例如在真实终端中定位并修复一个缺陷、完成一次跨越多个网页的金融信息核查、或根据自然语言描述生成可用的三维CAD模型——往往需要模型在几十轮甚至上百轮“思考—调用工具—观察结果—再思考”的循环中保持目标一致。

这对基础模型提出了三层新要求：

1. 上下文容量：工具返回的日志、网页正文、代码仓库片段会迅速把对话撑到数十万甚至百万Token量级；
2. 推理深度：任务中间步骤多、依赖链长，模型需要“先规划后执行”的长链路思考能力；
3. 行为稳定性：多轮工具调用的格式合规率、参数准确性直接决定任务成败，任何一次格式错误都可能让整条任务链中断。

近期开源社区出现的万亿级参数MoE模型（总参数约2.8T、每Token仅激活约104B），正是围绕这三层要求进行系统化设计的代表方案。本文以这类公开技术信息为线索，拆解“Agent原生”大模型的通用技术路径。需要提醒的是，此类模型的权重通常采用专用许可证而非完全宽松的通用开源协议，企业在复用前应先完成合规评估，这一点后文会展开。

二、MoE架构：解耦“模型容量”与“推理成本”

MoE（Mixture of Experts）的核心思想，是用一个路由器为每个Token只挑选少数专家网络参与计算，从而让“总参数量”与“单次计算量”解耦：

• 总参数（如2.8T量级）代表模型的知识与技能容量上限；
• 激活参数（如104B量级）决定单次前向传播的实际算力开销。

二者解耦后，模型可以在不显著增加推理成本的前提下，通过“加宽”专家层持续扩充容量。但工程上的挑战同样明确：

1. 显存墙：总参数必须全部驻留显存。粗略估算，2.8T参数以BF16存放约需5.6TB显存，即使4bit量化也需1.4TB量级，单机无法承载，必然走向多机集群与专家并行（EP）；
2. 通信开销：专家分布在不同设备上，All-to-All通信容易成为吞吐瓶颈，需要与张量并行（TP）精细组合；
3. 负载均衡：路由塌缩到少数专家会浪费容量，训练中通常引入辅助均衡损失加以约束。

对开发者的启示是：评估这类模型时，重点不是“总参数有多大”，而是激活比与自身算力集群规模的匹配度，以及推理框架对MoE并行策略的成熟度。

三、混合注意力：线性记忆与稀疏检索的双系统

百万Token上下文若全程使用标准全注意力，计算复杂度为O(n²)，KV Cache也随长度线性膨胀。业界的通用解法是“分层混合”：

1. 大部分层使用门控线性注意力：将历史信息压缩进固定大小的循环状态，计算成本与序列长度线性相关，负责维护“摘要式记忆”——任务主旨、对话风格、当前目标等；
2. 少数层保留精确检索能力：采用令牌选择式稀疏注意力，每个查询仅在全部历史中挑选少量最相关的Token（例如2048个）参与注意力计算，负责“精确回忆”——某个函数的原始定义、某条条款的原文。

这种“摘要记忆+精确回忆”的双系统设计，类似人类阅读长文档的认知策略：抓主线，同时能随时翻回原文核对细节。相比全部换成线性注意力（会损失精确复制能力）或全部保留全注意力（成本不可接受），混合方案在精度与成本之间取得更好平衡。

两个配套要点：

• 原生多模态输入：图文输入会被统一为Token序列，图像会显著加长序列，这进一步放大了注意力稀疏化的收益；
• 推理侧KV管理：稀疏注意力意味着大部分历史Token的KV无需常驻高速显存，可分层存储，显著缓解长上下文推理的显存压力。

四、联合强化学习：Agent能力的真正来源

架构解决“能不能装下”，后训练解决“会不会用”。当前Agent能力的主要来源已从监督微调转向大规模强化学习，其关键设计包括：

1. 任务域覆盖：联合RL不再局限于数学与代码，而是覆盖数百个下游领域——终端操作、代码缺陷修复、网页检索与信息核验、金融研究、办公文档处理、CAD/3D生成等，让同一套策略在异构工具环境中泛化；
2. 可验证奖励：这类任务大多能构造客观判据——单元测试是否通过、命令输出是否符合预期、检索信息能否交叉印证，奖励信号因此可规模化自动生成，摆脱对人工标注的依赖；
3. 思考预算分档：推理时提供low、high、max等多档思考预算。简单检索用低档控制延迟与成本，复杂软件工程用最高档换取更长推理链。这本质上是把“快思考/慢思考”的选择权交给调用方；
4. 多轮轨迹一致性：Agent任务的状态不只是用户消息，还包括完整的思考过程与工具调用历史。很多Agent框架要求调用时保留全部历史思考与工具消息，原因正在于此——截断历史等于改变了模型训练时的输入分布，性能会明显下降。

五、MXFP4量化与开放权重的部署实践

开源大模型普遍选择MXFP4（微缩放4位浮点）发布权重：

• 格式原理：将权重切分成小块，每块共享一个高精度缩放因子，块内元素用4位浮点存储。相比朴素INT4，浮点格式对权重分布（尤其是零附近的密集区域）拟合更好，量化损失更小；
• 收益：显存占用约为BF16的1/4，使万亿级总参数有机会装入可负担的集群；主流加速器对MXFP4具备原生或近原生计算支持，吞吐损失可控。

部署层面的通用要点：

1. 框架适配：主流开源推理框架已普遍支持MoE与MXFP4组合，选型时应重点验证百万Token级长上下文下的显存占用与吞吐表现；
2. 并行策略：总参数超出单机显存时，需专家并行配合张量并行，并对权重与KV Cache做分层放置；
3. API协议兼容：对外服务建议兼容业界通用的对话补全API协议，并额外暴露思考预算、工具调用等扩展字段，降低上层Agent框架的迁移成本；
4. 消息管理：多轮工具调用必须原样保留历史思考与工具调用消息（包括中途失败的尝试），不能擅自截断或改写。

一个示意性的Agent循环（伪代码，接口以通用对话补全协议为例）：

messages = [{"role": "user", "content": "定位并修复仓库中的失败用例"}]
while True:
    resp = llm.chat(
        messages,
        thinking_budget="high",   # 思考预算分档
        tools=TOOL_SCHEMAS,
    )
    # 关键：把带思考过程的完整回复原样写回历史
    messages.append(resp.message)
    if not resp.tool_calls:
        break
    for call in resp.tool_calls:
        result = run_tool(call.name, call.arguments)
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": result,
        })

六、Agent能力评测的正确打开方式

公开Benchmark分数只能作为参考，选型时应更关注评测方法本身：

1. 维度覆盖：完整的Agent评测应至少覆盖终端/系统操作、软件工程（缺陷修复、仓库级改动）、网页检索与信息核验、办公文档问答、专业领域生成（如CAD/3D）等类别，单一高分不代表全面能力；
2. 执行环境：代码与终端类评测必须在沙箱中真实执行命令与测试，浏览类评测需对抗站点污染，纯静态问答无法反映真实Agent水平；
3. 档位与框架统一：不同思考档位的分数差异巨大，跨模型比较必须固定思考档位，并说明是否借助外部编程Agent框架执行；
4. 关注稳定性：多次运行的方差、格式合规率、长任务中途放弃率，往往比单次最高分更能反映生产可用性。

七、许可证合规：开源权重不等于自由使用

此类模型普遍采用专用许可证，而非完全宽松的通用开源协议。常见附加条款包括：按用户规模分级的商用授权、对品牌与名称使用的限制、特定用途或辖区的禁止条款。企业落地前的合规清单应至少包含：确认自身用户规模对应的授权路径、审查再分发与衍生模型条款、评估未来用户量激增后的授权风险。

八、云上落地路径与成本优化

对多数团队而言，从零搭建TB级显存集群并不现实，可行路径包括：

• 私有化部署：借助云平台的GPU容器实例或专属集群承载推理，用对象存储存放数百GB的量化权重，用日志服务与监控告警保障Agent长任务的可观测性；
• 托管接入：百度智能云等云平台通常提供模型托管与推理服务等通用能力，支持以标准API协议调用大模型，并可配合函数计算、消息队列编排Agent工作流，适合先快速验证场景价值，再决定是否自建；
• 成本控制：按任务复杂度动态选择思考档位、复用前缀缓存、对工具返回内容做摘要压缩，是三个收益最明显的优化点。

九、结语

万亿级MoE、混合稀疏注意力、大规模联合强化学习，构成了当前“Agent原生”大模型的三条技术主线。对开发者而言，比追逐单个模型分数更重要的，是理解这些机制背后的设计逻辑——容量与成本如何解耦、长上下文如何在精度与开销之间权衡、Agent行为如何被强化学习塑造。掌握这套分析框架，无论模型如何迭代，都能快速判断其技术成色以及与自身场景的匹配度。