企业官网建设流程全解析

前阵子阶跃星辰把 Step 5 Preview 的权重一放出来，我身边做 Agent 应用的朋友几乎都在转这张图：600B 总参数，每 token 只激活 27B，开源榜单位列第一梯队，宣传口径还死死咬住“长程智能体”不放。乍一看这像又一个大模型“军备竞赛”的产物，但仔细算完账之后，我反而觉得它值得单独写一篇长文聊清楚：为什么“大而稀疏”的结构，会在多轮工具调用这类任务里变成一个意外的帕累托改善；为什么单任务成本能砍下来 8 倍，而不是吹出来的 8 倍；以及作为一个普通开发者和研究者，你到底该怎么看懂、怎么部署、怎么用它去跑真正的智能体任务。

先说结论：Step 5 Preview 不是一个常规意义上的“更大更强的聊天模型”，它更像一枚专门为“长任务、多轮调用、高上下文消耗”设计的性价比武器。600B 是所有专家加起来的家底，27B 是每次推理真正干活的队伍。这种 MoE 架构决定了它下载时很重、跑起来却很轻，也决定了它在长程智能体场景里能把成本优势放大到肉眼可见。这篇文章不打算复述官方 PR，我会从 MoE 的原理、智能体任务的成本结构、部署显存的数学题、实测踩坑记录这几个角度，把这件事彻底拆开。

1. 600B总参只激活27B，Step 5 Preview到底是个什么水平

1.1 “激活参数”比“总参数”更能定义实际体验

传统 Dense 模型里，总参数量和激活参数量是同一个数：无论输入什么 token，整个模型都会跑一遍。可 MoE 不是这样。跟我说句实话，两年前我第一次看 MoE 的论文也觉得很反直觉：一个模型明明有 600B 参数，可每次输入只在若干个专家网络里做路由，最后平均只激活 27B。这意味着什么？用一句最直白的话说，你下载权重的时候要面对的是 600B 的完整体积，但每一次生成 token 的计算开销只相当于一个 27B 的 Dense 模型。

这个区分很重要，因为用户感知到的“快慢”“贵贱”，从来不是总参数量决定的，而是激活参数、上下文长度、KV Cache 共同决定的。我举个生活化的例子：一家 600 人的公司，办公楼要按 600 人建，房租一分不少；但具体接到一个项目，只需要 27 人进场干活，那工资和项目开销就是 27 人的量级。传统 Dense 模型等于每个项目都让 600 人一起上，MoE 则尝试“看菜下饭，按单挑人”。Step 5 Preview 的效果之所以在开源社区引起讨论，正是因为它在“办公楼很大”的前提下，把“项目人力成本”压到了一个非常夸张的程度。

当然，这个机制也有它的隐性成本：路由模块本身需要判断哪个专家适合当前 token，专家之间还有通信开销。如果任务本身简单到所有 token 都只需要同一批共性能力，那 MoE 反而是浪费。但反过来讲，一旦任务需要频繁切换知识域，比如既要写代码、又要查文档、还要做数学推演，那“每次按需激活”的优势就会被拉满。这也是为什么它一上来就强调“长程智能体”，而不是强调通用聊天。

1.2 开源前三到底指什么，怎么理解这个排名

很多人看到“开源前三”四个字，第一反应是去问“哪个榜单”。这里必须说清楚：目前不存在一个真正意义上的全球官方开源模型排行榜，社区里能达成默契的主要是几个参照系，比如 Hugging Face 的 Open LLM Leaderboard、Artificial Analysis、LMArena 的开放式评测，以及各种代码、数学、Agent 专项榜。Step 5 Preview 能在这些综合维度里进入第一梯队，本身说明它不是一个“偏科怪”，而是在通用能力、指令跟随、工具调用上都保持住了水准。

我的看法是，开源模型排名这个东西，背后不光是模型权重本身的胜负，也是对周边工具链的综合性考核。一个 600B 模型就算再强，如果没有 vLLM、SGLang、llama.cpp、GGUF 这些推理框架跟上，个人开发者根本不可能把它跑起来。这几年的现实就是：开源社区的“基础设施红利”让超大模型不再是大厂的专利，Step 5 能登上榜单前列，也说明它的部署路径已经足够平滑，至少不会让你为了推理环境熬三个通宵。

还有一个容易误读的细节：榜单排名里如果出现“600B”“27B激活”一类的字眼，别急着和其它模型按总参数量横向对比。不同模型的词典大小、层数、专家数量、路由策略都不一样，榜单上的得分是端到端的效果衡量，和你配置的推理框架、量化精度、采样参数也有关系。真正有价值的不是“排第几”，而是这个名次对应的推理成本到底是多少。

1.3 为什么偏偏强调“长程智能体”

先给不熟悉 Agent 概念的读者补个背景。所谓长程智能体，指的是让模型去完成一个需要持续很多步、反复调用外部工具、在长时间内保持目标一致性的任务。比如让模型帮你订一张跨国机票，它得先查航班、比价、确认中转、处理证件要求，再一步步提交预订请求；或者让模型做一个数据分析报告，它得反复检索数据、写代码、执行、看结果、再修改。和普通聊天不一样的是，这类任务不是一问一答，而是“一段马拉松式的多轮协作”。

这种场景里，token 消耗会指数级膨胀。每多一次工具调用，历史记录就要多塞进一段上下文，模型下一次推理时又要把整段历史重新过一遍。你可以简单理解为：一次对话越长，花出去的钱越像滚雪球。传统 Dense 模型在这种场景里最大的问题不是“能力不够”，而是“成本扛不住”。Step 5 的设计恰好击中了这个痛点：参数总量大，代表它有能力处理复杂任务；激活参数小，代表它每次处理长上下文时不会把所有计算量都压在你钱包上。这就是它和“长程智能体”绑定得如此紧密的原因，不是营销话术选得好，而是架构本身就长在这条需求曲线上面。

2. 为什么说这是长程智能体的“帕累托奇迹”：MoE的账其实没那么好算

2.1 MoE不是新东西，这次赢在训练和工程

如果你翻过早期的 NLP 论文，会发现“混合专家”这个概念至少能追溯到二十多年前。它不算新技术，但过去很长一段时间里，MoE 模型在开源社区不受欢迎，原因非常现实：训练不稳定，专家利用率容易坍塌，分布式推理的通信开销又大。那时候大家宁愿堆一个又大又笨的 Dense 模型，至少好训、好部署。

转折点出现在最近两年。一方面，研究者设计出了更聪明的负载均衡损失，让路由模块不会总把 token 丢给同几个“卷王”专家，各专家之间的利用率更健康；另一方面，训练数据质量和多阶段训练策略的提升，让稀疏模型的“学不进去”问题得到了缓解。第三步则是在推理框架层面，vLLM 等工具专门为 MoE 做了张量并行和专家并行的混合优化，把“600B 权重但只激活 27B”这个说法的可实现性拉到了普通工程师也能触碰的范围。

Step 5 Preview 在这个时间点出现，确实占了好几个优势叠加的便宜。但把 600B 总参和 27B 激活做到“既能跑又不笨”，不是简单地把 Dense 层改成 MoE 层就行。它需要足够多样的数据让专家产生分工，需要合适的路由温度避免所有 token 都挤到同一条路上，还需要长上下文阶段对大量工具调用记录保持稳定。很多团队做 MoE 做到一半就放弃，就是因为这些“看不见的工程”远比论文里那几条公式更磨人。

2.2 计算账本：27B激活 vs 600B总参，差距到底在哪

把理想情况下的计算量拉出来算一笔账。自回归生成一个 token 需要的浮点运算量，粗略估算大约是2 × 激活参数量 × token 数。如果有一个 600B 的 Dense 模型，那它每生成一个 token，就要跑几乎全量的 1.2 TFLOPs 级别计算。Step 5 激活参数量只有 27B，每 token 计算量大概在 54 GFLOPs 级别。单看这个数字，理想差距接近 20 倍。

但在真实服务环境里，没有人能拿到这 20 倍。原因有三个：第一，权重文件依然是 600B，显存占用和加载开销一点没省；第二，多专家并行必然引入通信，拆的卡越多，通信成本越高；第三，注意力机制的 KV Cache 只跟层数、隐藏维度、上下文长度有关，和激活参数没有直接关系，长上下文场景下这块开销反而可能成为大头。综合工程损耗，能把单位 token 成本做到同等质量 Dense 模型的 1/5 到 1/10，已经算是非常漂亮的数字。所以“单任务成本砍 8 倍”这个宣传口径，既不夸张，但也最好别理解成“所有场景都便宜 8 倍”。

我之前帮一个团队估算过一个内部 Agent 项目的推理成本，他们从 200B 稠密模型切到稀疏激活的 MoE 模型后，在任务成功率基本持平的前提下，Prompt 处理阶段的实际吞吐提升了大约 6～7 倍，到了晚上低峰期甚至能到 8 倍以上。原因是智能体任务里最耗时的往往不是 Decode，而是把越来越多历史记录塞进上下文的那一次 Prefill。MoE 对这部分计算量的削减几乎是降维打击。

2.3 “帕累托奇迹”是个营销词，但方向是对的

我前面说过，所谓帕累托改善，本质上是你多了一个选项：以前模型能力和推理成本像翘翘板，压下一头就抬起另一头；现在稀疏激活结构让你有可能“知识很渊博，但跑起来很便宜”。在经济学意义上，这当然很重要。但做技术的人千万不要被这个词糊住，因为 MoE 的收益高度依赖任务分布。

什么场景适合 MoE 长程智能体？答案是：任务确实需要多领域知识、需要长期保持目标一致性、需要频繁工具调用。比如“企业级数据分析助手”“法律文档自动审阅”“复杂流程自动化”这类任务，它们往往既需要代码能力，又需要领域上下文理解，还动不动就要跑几十轮。反过来，如果你只想要一个“问一答一”的客服机器人，每轮输入很短、输出很短，那 MoE 在通信和显存上的额外开销反而会拖低性价比。

所以“帕累托奇迹”真正的含义，我认为是“在特定任务分布上找到了一组别人没做好的取舍”。它不是模型自己产生了奇迹，而是“稀疏架构 + 长上下文优化 + 开源部署工具链成熟”三件事在 2025 年这个时间点完美对上了。顺着这个逻辑，你就能理解为什么它会叫“Step 5 Preview”，为什么它偏偏面向 Agent 任务发布，以及为什么关注度这么高。

3. 把账算透：单任务成本8倍差距是怎么砍出来的

3.1 长程智能体的成本结构与传统 Chat 完全不同

先不要纠结“8 倍”这个数字本身，先把长程智能体任务的成本模型搭出来。任何一个 Agent 任务，账单上基本由三块构成：输入 token（每次调用时发给模型的指令、历史记录和工具返回结果）、输出 token（模型生成的思考过程和最终答案）、以及失败重试带来的额外消耗。

传统 Chat 里，输入输出往往各几百 token，一次会话结束就完事。但长程智能体不是这样：假设一个任务要执行 15 轮工具调用，每轮新增约 2k token 的工具反馈，那么模型累计已经“见过”的上下文会达到几十 k 甚至上百 k token。最反直觉的地方在于：输出 token 往往只占很小比例，模型可能每轮只回你几十到几百字的文字，真正烧钱的是它每次都要把“越来越长的历史记录”重新完整处理一遍。这个特性决定了，长程智能体任务中真正决定成本的不是生成速度，而是预填充速度。

如果你只盯着“生成速度”去选模型，很容易被带偏。举个例子，一个模型 Decode 速度快，但 Prefill 阶段把所有历史都算一遍需要很久；另一个模型 Decode 稍慢，但 Prefill 在稀疏结构下能省掉大量专家计算。放到 15 轮工具调用的任务里，第二个模型的综合表现很可能会反超。Step 5 的优势恰好落在第二个象限里：它的激活参数小，每次 Prefill 的计算量天然就低。

3.2 为什么“激活少”在累积成本场景能放大 8 倍

还是把问题拆细。模型服务端处理每个 token 的成本，由 Prefill 和 Decode 两段构成。在一个多轮工具调用任务里，每一轮你都要把“上一轮的完整对话 + 工具结果”重新发给模型做一次 Prefill。随着轮次增加，输入长度线性增长，但每次增长都会重复处理之前的全部历史，因此总成本是按轮次的“累计长度”增长的，近似 O(n²)。

在这种增长模型下，激活参数带来的单次优势会被反复乘算。假设 Step 5 每次 Prefill 的计算量是一个 200B 稠密模型的 1/7，而智能体任务要重复执行 15 轮，那么理想情况下总成本差距会在单次的 1/7 基础上进一步被“轮次”放大。当然，实际工程中 KV Cache 和通信开销会吃掉一部分红利，不会达到数学上那么夸张的差距，但 4～8 倍的差距完全在合理区间。“单任务成本狂砍 8 倍”背后的逻辑不是某个魔法优化，而是长上下文 Prefill 的重复代价被稀疏结构大幅削减之后，自然而然体现出来的结果。

3.3 算一笔“示范账”：一个 15 轮工具调用任务的对比

为了让你对“8 倍”有一个直观手感，我按一个相对标准的智能体任务来模拟一遍。假设任务总共 15 轮工具调用，每一轮新增上下文 2k token，初始系统提示和任务描述约 2k token。那么第 1 轮的输入长度约 4k，第 2 轮约 6k，第 15 轮约 32k。把所有轮次的输入长度累加，模型在整个任务里处理的输入 token 总量大约是 270k；输出 token 假设总共 20k。

同样这个任务，如果换成一个激活参数为 200B 的稠密模型，单 token 的 Prefill 计算量大约是 Step 5 的 7 倍。虽然通信和工程损耗会让实际差距缩水，但别忘了还有失败重试：Agent 任务很难一次成功，实测量级上 5 次尝试能彻底跑通已经算很优秀。也就是说，如果你的模型单价高到让你“不敢多试几次”，那成功率就会进一步恶化，成本差距反而会拉大。所以“8 倍”并不是一个脱离场景的绝对数字，它是“任务复杂度 + 轮次 + 重试概率”共同作用的结果。

3.4 真正要警惕的隐性成本：显存占用与并发

话虽这么说，我还是要给兴奋的情绪降降温。Step 5 的单任务推理成本低，不代表部署成本低。你想本地跑一个 600B 权重，显存预算依然是一道很硬的坎：FP8 量化后大约 600GB，4bit 量化后大约 300GB，这还没算 KV Cache。小团队如果只是偶尔跑几个 Agent 任务，按云端 GPU 按小时租用可能是更合理的姿势；但要支撑高并发线上服务，8 卡、甚至更多卡的成本依然非常可观。

我常对朋友说，看模型成本要分两个口径：一个是“单位任务口径”，也就是每个成功完成任务花多少钱；另一个是“基础设施口径”，也就是为了让模型能跑起来，你每月最低要付多少 GPU 账单。Step 5 的优势体现在前者，但千万不要因为它“便宜”就忽略后者的规划。很多项目死在“以为便宜所以随便上”，结果并发一高，显存直接顶到天花板，加卡的成本瞬间把省下来的推理费全吃回去。

4. 本地部署实操：显存预算、量化选型与推理配置

4.1 先搞清楚三种部署方案，别一上来就下载 600B

动手之前，先梳理清楚你的目标。如果你只是想验证 Step 5 在某个智能体任务上的效果，最省事的是直接调用官方 API，注册之后把 base_url 换成服务商给的地农民，跑通一个 demo 再决定是否自建。如果你想认真做评测和二次开发，那就需要本地部署，但又可以分成两条路：一条是用多卡大显存跑 BF16/FP8 权重，尽量复现模型真实能力；另一条是用 GGUF/AWQ 做 4bit 量化，塞进你手头已有的卡里，优先验证“能不能跑”和“亏多少”。

我觉得大多数开源玩家会走第二条路，因为一张 H100 不是谁都有的。但这里有一个很容易被忽略的坑：不同量化方案对 MoE 模型的影响并不一致。有些朋友拿 Dense 模型的量化经验硬套，上来就把权重压到 2bit，结果路由模块也跟着被压坏，模型直接“精神分裂”。对 MoE 模型，权重量化的重点不是把每个专家压得多狠，而是保证路由层的精度不崩。

推荐先跑一遍官方支持列表里最成熟的量化格式，比如 AWQ 或 GPTQ 的 4bit，再根据任务效果决定要不要往更低 bit 试。GGUF 的好处是生态好、llama.cpp 直接支持，但对超大模型来说，最好还是确认推理后端对 MoE 的 expert parallelism 支持是否成熟，否则你会遇到“量化完跑不动”的尴尬。

4.2 显存预算怎么做：600B 的数学题

显存估算是部署这类模型最不容易出错、又最容易被人忽略的环节。先背下这个公式：模型权重显存（GB） ≈ 总参数量 × 每参数字节数 + 额外开销（约10%）。

BF16/FP16 是每参数 2 字节，600B 模型权重就要 1200GB；FP8 是每参数 1 字节，大约 600GB；4bit 量化约每参数 0.5 字节，大约是 300GB。注意这只是权重，还没算 KV Cache。长程智能体任务里，上下文可能开到 128K，KV Cache 又是很大一笔开销，一般建议在权重估计算完后直接再加 20%～30% 的余量。拿 4bit 的 300GB 来算，加上 KV Cache 和中间激活，整机显存至少建议 320GB 以上。这意味着一台 8×40GB 的机器勉强够跑，4×80GB 会更从容。

我见过不少人在这一步踩坑：看到别人用 4bit 说“能跑”，就以为一张 24GB 显卡也行，结果权重加载到一半，显存直接爆掉。虽然也有人在 GitHub 上用极端量化在单卡上跑出过 demo，但那种方式牺牲了太多质量，只适合“装逼截图”，不适合真的做 Agent 开发。如果预算有限，建议直接租云 GPU，按小时计费，先把流程跑通再考虑采购。

4.3 推荐推理配置：vLLM + 长上下文参数

Step 5 的长程智能体优势严重依赖长上下文能力，所以配置推理服务时，第一件事是把 max-model-len 调到足够大。如果你只留 8K，那基本等于自断一臂。我的建议是至少 32K，有显存余量就直接 128K。vLLM 是当前对 MoE 模型支持最好的框架之一，启动参数可以这样写：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/step5 \ --tensor-parallel-size 8 \ --max-model-len 131072 \ --gpu-memory-utilization 0.92 \ --trust-remote-code \ --dtype bfloat16

这里有个值得多讲两句的参数是--tensor-parallel-size。很多人以为卡越多越好，直接拉满全部 GPU，但在 MoE 场景里并不一定最优。MoE 的专家可以放在不同的卡上做 expert parallel，而 Attention 部分需要张量并行，这两者如果混在一起，通信开销可能抵消掉算力收益。实践中最靠谱的做法是先用默认值跑 benchmark，再试着拆成两个 TP 组加一个 DP 组，对比吞吐变化，不要盲目照搬别人的启动参数。

4.4 用 OpenAI 兼容接口快速接上智能体框架

vLLM 启动之后会提供一个 OpenAI 兼容接口，这一步对做 Agent 开发的工程师来说非常友好。你完全不需要修改已有的工具调用代码，只需要把base_url改成http://127.0.0.1:8000/v1，把 API key 随便填一个非空字符串，就能像调用 GPT 一样调用本地模型。唯一要留意的是参数名差异，比如有些开发框架习惯用max_tokens，个别后端则要求max_completion_tokens，好在 vLLM 对前者做了兼容。

如果你用的是 LangGraph 这类框架，最简单的接入方式就是把 LLM 对象替换成一个指向本地服务的ChatOpenAI实例。跑一个小 demo 时，建议先执行一个只有两三轮工具调用的简单任务，观察响应时延、token 耗用、上下文截断情况。不要一上来就跑 50 步的长任务，否则一旦出问题，你很难分清是模型规划能力不行、上下文窗口不够、还是你服务端配置错了。

5. 长程智能体任务实测避坑指南

5.1 agent 任务最常踩的 5 个坑

我拿 Step 5 做过几组不同难度 Agent 实验，也和社群里的朋友交流过，发现大家踩的坑高度一致。第一个坑是上下文静默截断。模型本身支持长上下文，但很多调用代码里默认只取最近 N 条消息，或者后端配置没跟上，导致第十轮工具返回之后模型“失忆”。排查方法很简单：在 prompt 里塞一个需要引用最开始信息的问题，如果答不上来，基本就是上下文被截了。

第二个坑是工具定义不规范。Step 5 对工具调用的支持很完整，但如果你的 JSON Schema 写得含糊，模型就会陷入“想调用工具但参数永远不对”的循环。建议把所有工具描述写成“什么场景该用、参数具体含义、可接受枚举值”三件套，别指望模型自己脑补。

第三个坑是失败重试策略太粗暴。Agent 任务失败后，很多人直接从头重跑，于是成本翻倍式上升。正确做法是引入断点续跑：把已完成工具调用的结果序列保存下来，失败时只从出错的步骤往后重试，这样既节省 token，又能明显提高最终成功率。

第四个坑是系统提示写得太长。我理解大家都想把任务规则写清楚，但对 MoE 模型来说，系统提示只是一个正在被 Prefill 的上下文，长度和成本直接挂钩。把固定规则放在独立静态 prompt 里，每轮只追加动态的 agent scratchpad，能省很多没必要的花销。

第五个坑是采样参数没调对。工具调用类任务最怕温度太高，温度一高，模型就可能凭空发明工具参数；但温度压到 0，又容易陷入重复输出同一套计划。实践下来，temperature=0.2~0.4是一个比较稳妥的区间，既保留了探索性，又不至于太飘。

5.2 如何判断模型在智能体任务里“真的强”

刷 MMLU 和 HumanEval 分数没什么意义，想评估一个长程智能体模型，得用 agent 类基准。社区里常被拎出来的有 τ-bench、AgentBench、GAIA，以及一些自建的真实工具流程。我自己的习惯是先把一个固定任务跑三遍，看成功率；再手动记录模型每一轮的规划文本，看它有没有频繁推翻之前计划、是否记得早期关键信息。

Step 5 给我的整体感觉是：规划主线的稳定性非常好，大多数情况下不会跑偏；但遇到那种“之前已经执行完的工具结果突然需要被修正”的边角情况，它仍然会多探几步，并出现一两次多余的试探性调用。这不算致命伤，但如果你把 tools 描述写得不够细，这种试探会被放大。最实用的缓解方式是给工具描述加“使用条件”字段，明确告诉模型什么情况下千万别调用它。

5.3 量化精度对 agent 任务的影响，比想象中小

很多人一量化就担心“模型变傻”。我在实际的工具调用任务里对比过 4bit 和 BF16 的差距，结论是差异远小于 Dense 模型在同等量化下的衰减。这里的原理也不复杂：MoE 的路由模块参数量占比小，量化对它的影响有限；而专家网络本身的误差又会在门控加权平均的过程中被部分对冲。所以如果你只是为了跑 Agent 任务，4bit 完全够用。

但有一个地方不能省：KV Cache。长上下文任务里，KV Cache 的精度如果也被压得很低，位置编码和键值信息损失会直接破坏长程记忆，这种情况比权重量化更致命。省显存可以压权重，但对于 KV Cache，我建议要么保留较高精度，要么直接增加显存余量，不要为了省那几十 GB 把模型的长上下文能力废掉。

6. 开源模型竞赛的下半场，已经换了赛道

6.1 从“谁的模型最大”到“谁的每 token 更值”

Step 5 Preview 不是一个孤立事件，它背后是开源模型竞争逻辑的一次重要切换。以前大家评判模型的口径是“多少 B”，似乎参数越大越有面子，但长程智能体这类真实应用把这个逻辑颠覆了：真正决定产品能不能活下来的，是“用可接受的成本把任务跑成功”的概率。换句话说，下一个阶段的竞争会被重新定义为“谁的每 token 更值”。

如果一个 600B 总参、27B 激活的开源模型能稳定完成复杂工具调用，那么它对中小团队的价值，可能超过许多闭源 API。因为它意味着你可以把智能体任务的边际成本压到极低，可以放心地让模型多试几次，可以在真实业务里跑出更高的成功率。这种“可负担的试错能力”，才是稀疏架构对应用层最有吸引力的地方。

6.2 个人开发者还能做点什么

面对这个趋势，我觉得个人开发者和研究者的机会不在“再训练一个大模型”，而在把长程智能体的基础设施做薄。目前最缺的不是模型本身，而是配套工具：一个能优雅处理断点续跑的任务状态管理模块；一个能在任务即将超预算时自动压缩历史、切换策略的 token 预警系统；一套能显著降低模型无效猜测的工具约束模板。这些工具不要求你手里有几百张卡，但都需要你真正理解模型在长任务里的行为模式。

我在实际使用中还有一个感受：模型发布之后，周围很多人急于测试它的“智商上限”，却忽略了为它设计“稳定的工作环境”。对长程智能体来说，一个可靠的提示词框架、一组规范的 tools、一条清晰的中断恢复逻辑，带来的成功率提升可能比模型版本迭代还大。从这个角度看，Step 5 Preview 不仅让“600B 开源模型跑长任务”这件事变得现实，也把开发者的注意力重新拉回到产品工程本身上来。

最后再分享一个小技巧：如果你打算拿 Step 5 做长程智能体任务，不要把它当做一个“单一模型”用，试着让它在每一轮工具调用前先只输出非常简短的计划状态，而不是长篇思考。短计划不仅省 token，还能显著降低长任务里“想太多导致跑偏”的概率。我试过把某条 Agent 流程的中间思考长度砍掉一半，任务成功率反而涨了十几个点。这件事在稀疏 MoE 模型身上体现得尤其明显，因为它每 token 的成本虽然低，但“绕圈子”的时间成本依然非常宝贵。