上下文压缩进了训练：Step 5 Preview 让长程 Agent 学会给自己写交接单
10 月 15 日，阶跃星辰（StepFun）开放了 Step 5 Preview 的模型权重。BF16 和 FP8 两种数值精度版本同时上线 Hugging Face 与 ModelScope，官方还发布了一篇技术博客，解释模型为何这样设计。
纸面规格很醒目：它采用稀疏 MoE（混合专家）架构，总参数 600B，但处理每个 token 时只激活其中 27B；上下文窗口最长 100 万 token，并支持文本和图像输入。按 InfoQ 引用的数据，截至发布当天，它在 OpenRouter 的 Token 用量周榜和日榜都排在全球第二。
但读完技术博客，我觉得最值得记住的不是“百万上下文”，而是其中一句话：
The scaling law we want is one where the horizon is unbounded while the working context stays finite.
（我们想要的扩展规律是：任务的长度不设上限，而工作上下文保持有限。）
换句话说，阶跃没有把赌注只押在“窗口越大越好”上。它承认窗口总会被填满，于是把上下文压缩（context compaction）直接放进强化学习：当可用窗口快耗尽时，模型主动整理已完成的工作，留下一个可以继续执行的状态。这个状态保留得好不好，最终由任务能否完成来评价。
压缩不再只是套在模型外面的一段摘要提示词，而成了模型要学会的一项本事。
这篇文章重点回答三个问题：它和普通摘要有什么不同，什么样的架构与训练系统才能支撑长任务，以及开放权重对想自己部署的企业究竟意味着什么。
一、窗口再大也会满：任务长度和上下文窗口是两件事
先说清楚长程 Agent 到底难在哪。
单轮问答里，模型读一段输入、给一段输出，事情就结束了。长程任务不一样。以软件工程为例，Agent 要读需求、读代码、改文件、跑测试、看报错、再修改，可能循环几十甚至上百轮。
每一轮的工具返回、执行日志和中间决策都会堆进上下文。任务越长，历史越多，模型既要支付更高的计算成本，也更容易忘掉最初的约束。
这时候有两种思路。
第一种是扩大窗口，从 128K 提升到 1M，再继续往上。这能抬高天花板，却不能取消天花板：只要任务足够长，窗口终会被填满。与此同时，历史越长，每一步推理通常越贵，早期信息也越容易被后来的内容淹没。
第二种是在窗口快满时压缩历史。业界常见的做法是在 Agent 框架外加一层规则：上下文超过阈值，就让模型按固定提示词写摘要，再用摘要替换原始历史。
问题在于，这类摘要通常只追求“概括得像不像”，而不是“能不能支撑后续任务”。提示词可以要求保留关键约束，但什么最关键，模型往往只能按通用写作习惯判断。
Step 5 走的是第二种思路，但换了一个位置：
- 压缩动作由模型自己触发和执行，在预算接近耗尽时，把工作整理成可恢复的状态（resumable state）再继续；
- 压缩被当作整个行动策略的一部分，与任务执行使用同一个结果奖励。如果压缩漏掉关键信息，最终导致任务失败，这次失败也会成为压缩策略的训练信号。
用一个职场类比：框架层摘要像让新同事按模板写交接单。模板上有“背景”“进展”“待办”几栏，写得工整，却未必写到点子上。
Step 5 的做法，则像让同一个人反复经历“写交接单—第二天接着干—项目成败”的完整循环。交接单写漏了，第二天因此返工，这个结果会反过来纠正他的写法。久而久之，他学会的不是“交接单长什么样”，而是“哪些东西不写下来，明天就会出事”。
技术博客把这个选择归到 Rich Sutton 的“苦涩的教训”（The Bitter Lesson）名下：与其人工设计规则，不如让通用方法在足够的计算和反馈中自己学会。
这背后的含义值得多想一步。如果压缩是可以训练的能力，那么长程 Agent 的上限就不再只由窗口大小决定，而是由“会不会给自己写交接单”决定。百万窗口仍然有用，它让每一段工作期更长、压缩次数更少，但它不再是唯一的答案。
当然，代价也随之而来。两种方式生成的摘要都可以阅读和检查，但框架层摘要的规则更容易审计：你能直接看到提示词和保留字段。训练出来的压缩策略为何保留某项、舍弃另一项，则更难解释。对需要追溯决策依据的场景，这是一个必须正视的问题。
二、为什么是“窄而深”：给隐式推理留出层数
压缩解决的是“该记什么”，架构解决的是“面对漫长历史，怎样算得动、想得深”。Step 5 有两个取舍值得单独说。
92 层：工具调用太多，模型来不及显式思考
Step 5 有 92 个 Transformer 块。技术博客称，这个深度与一些万亿级开源模型相当，但总参数和激活参数分别不到它们的四分之一和三分之一。这就是所谓“窄而深”。
为什么要深？技术博客的解释很有意思。Agent 任务里到处是多跳依赖：这个函数被哪里调用，那个配置影响哪些模块，上一次失败和这次改动有什么关系。理想情况下，模型可以写一大段思维链，把这些关系逐步理清楚。
但 Agent 会频繁调用工具，大量 token 用于读取工具返回，也就是模型先消化输入的预填充阶段。为了控制 token 和时间成本，模型没有太多机会把所有推理过程都写出来。
因此，更多推理需要在预填充过程中隐式完成。按团队的解释，一条依赖链每多跳一次，信息就需要经过更多网络层继续传递；模型不够深，复杂关系还没整合完，层数就先用完了。
这个推理链条是团队的设计假设，不是定论；但它给了一个清楚的思路：在 Agent 场景里，深度可能比宽度更值钱。
深也有代价。团队在扩大训练规模时遇到了数值爆炸和梯度尖峰，而这类问题在更浅、更宽的网络里较少出现。他们用了三道修补：
- 隐藏状态及其梯度改用精度更高的 FP32；
- RMSNorm 的缩放参数也从 BF16 改成 FP32，避免某些通道因精度不足反复“关闭又打开”；
- 对极少数异常梯度做细粒度截断，每层只处理约 0.00004% 的梯度值。
Sparse GQA：省的是索引开销，不是整体推理时间
Step 5 的注意力层按 3:1 交替：三层负责完整查看最近的内容，一层负责从更早的历史里挑选相关部分。可以把它理解为：近处全看，远处挑着看。
这种稀疏全局注意力叫 Sparse GQA。它先用索引器从历史里挑出相关片段，再只对这些片段计算注意力。团队发现，在超长上下文下，“挑选历史”本身甚至可能比后续计算更贵。于是他们把相邻 8 个 token 合并成一个索引块，让索引与 top-k 选择的开销降到原来的八分之一。
块变粗了，挑得就没那么细。他们的补偿办法是把选中的 token 预算 k 从 2048 提高到 4096（即选 512 个块）。官方给出的对比是：token 覆盖率 78.06%，参考配置为 79.09%，损失约 1 个百分点。
这里有一个容易被误读的地方，InfoQ 的报道也专门提醒过：“索引开销降到八分之一”是局部算子的收益，不等于整个推理快了八倍，更不等于服务成本降到八分之一。 实际部署还有权重读取、跨卡通信、KV 缓存、工具执行等成本。要判断真实收益，得在相同硬件、相同上下文长度和并发条件下，测一个完整任务的耗时和资源占用。
三、真正的护城河，可能在训练系统里
如果只看架构，Step 5 的选择大多有迹可循。技术博客里更有信息量的，其实是长程强化学习的工程细节：怎样保证训练和推理一致，怎样避免困难样本在流水线里消失，以及怎样把最终成败归因到几百轮决策上。
训练和推理必须算出完全一样的结果
在线强化学习要同时跑两套系统：推理侧让模型执行任务并生成轨迹，训练侧再根据这些轨迹更新模型。两边使用的算子和并行方式可能不同，因此同一段输入也会产生细微的数值差异。在 MoE 的专家路由和 92 层网络中，这些差异会被逐步放大。
团队的目标是：只要使用同一版模型，训练侧和推理侧就应算出完全相同的结果，也就是逐比特对齐。即使训练侧使用 1 路张量并行、推理侧使用 8 路，两边算出的对数概率差异仍为零，额外开销低于 10%。
模型更新后，旧轨迹天然不再对应当前策略，无法继续逐比特对齐。对此，训练侧会重放轨迹生成时的关键计算状态，包括当时选中了哪些专家、候选 token 集合是什么。
他们观察到的差异很直观：对齐之前，模型会逐渐退化成单轮输出又长又乱；对齐之后，每轮输出长度稳定，模型也能持续完成更多轮交互。
最长最难的样本，最容易悄悄丢掉
这是我认为整篇博客里最值得每个做 Agent 训练或评测的人记住的一个观察。
一条长程轨迹从生成到进入训练，要经过很多环节，每个环节都可能让样本悄悄掉出去：超时、调度失败、格式异常、资源不足。团队发现，这种丢失不是均匀的，而是集中在最长、最难的那些轨迹上。结果是训练分布被系统性地偏向了短而容易的任务。
这是一种典型的幸存者偏差：你以为在用全部数据训练，其实在用“活下来的”数据训练，而活下来的恰恰是你最不需要的那部分。
他们的解决办法朴素而有效：建一本“生命周期账本”，让每一条预期的轨迹都必须落到一个有名字的终止状态；再在 Agent 框架里记录每一轮的每一次干预。最终，端到端样本丢失率被压到 1% 以下。
这个做法对评测同样适用。如果你的 Agent 评测里，超时和崩溃的任务被默默跳过而不是计为失败，那么分数会系统性偏高，而且偏高的部分恰好集中在最难的任务上。
一个结果，要解释几百轮的决策
长程任务通常只在最后给一个结果：成了，或没成。可这个结论要分摊到几百轮、几百万 token 的决策上，到底哪一步做错了，结果本身说不清楚。
Step 5 在两个尺度上处理这个问题。
在 token 层面，它用一个可学习的评价器（critic）估计每一步对最终结果的贡献，减少训练信号的波动。在轮次层面，对格式错误的工具调用这类“孤立失败”，只惩罚出错的那一轮，不让无关步骤一起背锅。
奖励作弊也走同一条通道。运行中有一个检测器，一旦发现作弊动作就当场拒绝并惩罚该轮，告诉 Agent 换个办法，轨迹继续跑下去，而不是直接作废整条轨迹。
数据：Agent 造的题，天然偏简单
在数据构造上，团队称搭建了覆盖科学推理、软件工程、机器学习研发和专业工作的百万级可验证环境，而且很大一部分构造工作由 Agent 在专家规则下完成。
他们坦白了一个现象：让 Agent 自己出题，它倾向于出简单的题。 它会主动简化问题、给出过多提示，还会反复生成熟悉的题型。
所以团队必须显式控制难度和多样性：用补丁长度、测试用例数量、不同前沿模型的通过率等信号校准难度，同时追踪题目来源，避免数据集中在少数仓库、主题和工作流上。
此外还要专门审查题目和评分规则里有没有可被钻的空子。前沿模型非常擅长在不真正解决问题的情况下拿到奖励，而且环境越真实、越复杂，越容易出现这种情况。
他们用三个维度筛选值得训练的任务：持续时间（Agent 要连续推进多久）、深度（达到通过状态之前要累积多少次状态变化，实践中用改动的文件数和行数衡量）、区分度（同一组尝试之间奖励的方差有多大）。前两个是设计出来的，第三个要拿当前模型去测。区分度为零的题，无论太难还是太简单，都提供不了学习信号。
四、值得对照的分工：判断交给模型，重复操作交给代码
把 Step 5 的技术博客和本站 9 月那篇《Growing Harness：别再让模型重复生成控制逻辑》放在一起读，会发现一个有意思的张力。
Growing Harness 的主张是：Agent 里反复出现的控制决策，比如查询改写、错误恢复、终止判断，应该沉淀成可复用的代码，而不是每次都让模型重新生成。Step 5 却把“压缩”这一类控制决策交给了模型，用强化学习去训练。
看起来是相反的方向，但 Step 5 自己在数据构造流程里其实也做了同样的切分。技术博客写得很明白：专家提供原则和关键节点的审查；Agent 负责跨步骤的协调和根据中间结果调整；而构建 Docker 镜像、检查任务验证、测量测试覆盖率、校验输出格式这类确定性、可重复的操作，刻意交给可复用的代码和工具，不让 Agent 去做。
所以两者并不矛盾，区别在于这个控制决策本身是什么性质：
| 控制决策的性质 | 例子 | 更适合放在哪 |
|---|---|---|
| 有明确规则、结果可确定校验 | 构建环境、跑测试、校验格式、重试网络错误 | 代码与工具 |
| 依赖任务语义、好坏要看后续结果 | 压缩时保留什么、何时换方案、何时停止 | 模型，并用任务结果训练 |
| 需要领域经验、错误代价高 | 题目难度原则、评分规则是否可被钻空子 | 人来定原则并审查关键节点 |
对在企业里搭 Agent 系统的团队，这张表比“该不该用框架”“该不该微调”这类二选一更实用。一个具体的判断标准是：如果某个决策的对错只能通过后面几十轮的结果来判断，就很难用规则写好，适合交给模型学；如果当场就能确定对错，就别让模型每次都猜。
五、开放权重：27B 激活不等于小模型的部署门槛
开放权重意味着企业可以把模型放进自己的代码库、文档和工具链里验证。但“每次只激活 27B 参数”很容易制造一种错觉：它似乎只需要部署一台 27B 模型。事实并非如此。
第一，激活参数不等于需要加载的参数。 每个 token 只激活 27B 参数，减少的是单步计算量；600B 的全部专家权重仍需要由部署系统管理。按官方模型卡给出的参考配置：
| 精度 | 推理框架 | 参考硬件 |
|---|---|---|
| FP8 | vLLM / SGLang | 单机 4 张 B300，或单机 8 张 H200 |
| BF16 | vLLM | 单机 8 张 B300，或两机共 16 张 H200 |
模型卡还特别说明，这些配置只保证能加载权重，不保证能跑满 100 万 token 的请求，KV 缓存和运行时缓冲也要占显存。另外，BF16 版本用 Transformers 做离线推理的完整流程，官方注明尚未端到端验证。
第二，“开放权重”不等于宽松开源。 模型使用 StepFun Model License 1.0。官方描述为“Apache-2.0 风格”，但附带署名和商业许可方面的额外条件。商用之前需要法务逐条核对，不能按 Apache-2.0 的习惯直接默认可用。
第三，基准成绩是厂商自报的。 模型卡列出的几项 Agent 相关成绩如下（均为高推理档位、厂商自测或引用）：
| 基准 | 衡量什么 | Step 5 Preview |
|---|---|---|
| DeepSWE v1.1 | 仓库级软件工程任务 | 67.7% |
| Terminal-Bench 4 | 终端环境下的多步任务 | 33.3% |
| ALE-CLI | 命令行界面下的 Agent 任务 | 29.5% |
在官方对比表中，DeepSWE 上它与几家同代开源模型接近，比最强的闭源模型低约 6 个百分点。这些数字可以作为是否值得试的参考，但不能替代在自己业务上的测试。本站之前讨论过的分数迁移问题说明，公开榜单上的高分到真实场景可能大幅缩水。
六、怎么验证一个模型的长程能力
既然 Step 5 把赌注押在“压缩之后还能接着干”上，验证它就不能只测一次性任务。如果要做内部评估，至少应记录下面五项指标：
- 跨压缩的任务完成率。 挑选足以触发多次压缩的任务，对比触发 0 次、1 次、3 次以上压缩时的成功率。如果成功率随压缩次数陡降，说明压缩策略在你的场景里并不可靠。
- 早期约束的保留情况。 在任务开头埋几条明确约束（比如“不得修改某个目录”“必须兼容某个版本”），检查多轮压缩之后，Agent 是否仍然遵守。这是压缩最容易出问题的地方。
- 每个完成任务的成本，而不是每个 token 的成本。 长程任务的成本取决于轮数、重试次数和人工介入，单价低不等于总价低。
- 人工接管次数和接管原因。 接管集中在哪一类问题上，比总体成功率更能说明能不能上生产。
- 失败样本的去向。 超时、崩溃和格式错误都要计为失败，并记录原因，不能悄悄跳过。否则评测会和训练一样，被幸存者偏差带偏。
小结
- Step 5 Preview 最值得关注的不是百万窗口，而是把上下文压缩放进了端到端强化学习。 任务长度和工作上下文由此脱钩，长程能力的上限从“窗口有多大”转向“会不会给自己写交接单”。
- 架构上押注“窄而深”。 理由是 Agent 频繁调用工具，来不及显式思考，多跳推理只能在预填充中隐式完成，需要足够的层数。Sparse GQA 降低的是索引开销，不等于整体推理同比例提速。
- 训练系统的细节比参数规模更有信息量。 训练与推理逐比特对齐、用账本防止最难样本悄悄丢失、分尺度分配奖励、主动纠正 Agent 出题偏简单的倾向——这些都是长程 Agent 训练中真实的坑。
- 开放权重的门槛需要按实际配置估算。 FP8 至少要 4 张 B300 或 8 张 H200；许可证有商业条件；基准成绩需要在自己业务上复核。
从这次发布看，长程 Agent 的竞争已经从“谁的窗口更大”，延伸到“谁能让模型在有限的工作记忆里持续推进”。前者是硬件和架构问题，后者还涉及训练系统、数据构造和评测方法。
如果你在搭长程 Agent，你会把“压缩时保留什么”交给模型去学，还是坚持写成可审计的规则？
本文部分内容由 AI 辅助生成，经人工审校和补充后发布。
参考资料
- StepFun. “Inside Step 5 Preview: Architecture and Training for Agentic Work.” 2026-10-15. https://platform.stepfun.ai/blog/inside-step-5-preview
- StepFun. “Step 5 Preview” 模型卡. Hugging Face. https://huggingface.co/stepfun-ai/Step-5-Preview
- 阶跃星辰. “Step 5 Preview” 模型介绍页. https://www.stepfun.com/step-5-preview
- 李冬梅. 《阶跃星辰开放 Step 5 Preview 权重：长程 Agent 的竞争，延伸到上下文管理与训练系统》. InfoQ, 2026-10-15. https://www.infoq.cn/article/EwqsJX6f03ODRac6Kk4c
- SGLang Team. “Step 5 Preview: Day-0 Inference and RL Support with SGLang and Miles.” https://www.sglang.io/blog/step-5-preview-day0-support
- Rich Sutton. “The Bitter Lesson.” 2019. http://www.incompleteideas.net/IncIdeas/BitterLesson.html