工程经验2026 年 10 月 16 日6 分钟阅读AI 产品 · 上下文工程 · 产品测试

把对话压短以后，Agent 还能接着做对吗？

Step 5 Preview 把上下文压缩纳入任务训练。对产品来说，验收重点也该从摘要够不够短，转向交接后是否保住约束、成果和下一步。

文章目录

摘要看起来不错，任务却接错了#

假设一个采购助手已经核对了报价，排除了交期不合适的供应商，也记下“最终下单前必须人工确认”。任务还没结束，对话已经很长。系统把历史压成一段摘要，再让助手继续。

摘要读起来通顺，剩余工作也写得很清楚。但那句“必须人工确认”没有留下。下一轮助手直接进入下单流程。

这是本文设定的产品测试场景，不是真实事故。它说明了一个容易被忽略的问题：压缩后的文字是否像一份好摘要，与它能否安全地接住工作，是两件事。

阶跃星辰团队在 2026 年 10 月 15 日发布的 Step 5 Preview 技术文章中，介绍了长任务的上下文管理：预算将尽时，Agent 把工作整理成可恢复状态再继续；压缩被纳入训练，使用同一任务的奖励评价。

同文还报告，训练样本在流转中丢失更集中于长、难任务。团队用生命周期账本和轮次事件记录追踪样本，使端到端样本丢失率降到 1% 以下。这是训练管线指标，不是产品任务失败率。

这两点给我的启发是：检验交接内容时，应看后续工作有没有做对；检验这套测试时，还应检查困难任务有没有被漏掉。

原文没有给出“有压缩与无压缩”的完整业务成功率对照，也没有公布采购场景的表现。因此，下面是一套我建议的产品验证方法，不是复述厂商已经证明的结论。

我会先把“好摘要”换成一组具体要求。仍以采购流程为例，交接内容至少要回答：

这些内容不必都复制进短文本。报价单可以保留为文件，摘要指向它；已经确认的审批要求则应明确保留，不能只留下一个含糊的“继续处理”。

这里还有一个取舍：把全部历史塞回去，可能又回到上下文过长的问题；压得过短，则容易把限制和不确定性一起删掉。我会优先保留会改变下一步行动的信息，而不是追求固定的压缩比例。

可以先选一批允许重复执行的测试任务，在同一个中间状态处分成两路。一路保留原有上下文继续，另一路使用压缩后的状态继续。模型版本、工具权限、后续预算和验收标准尽量一致。外部工具使用固定响应或测试环境，避免真实报价变化干扰判断。

这项比较有一个前提：原始上下文仍在模型可处理范围内。超过窗口的任务没有天然的“完整历史”对照，可以改用人工审定的交接状态作为参照，并把这类结果单独报告。

验收时，我会分别看三个问题：

第一，重要约束有没有留下。不是在摘要里找到了几个关键词就算通过，而是后续行为确实遵守了它们。

第二，已经发生的动作有没有被重复。比如已创建的草稿是否又建了一份，已完成的查询是否无意义地重跑。涉及支付、发信等外部动作时，应在测试环境中验证。

第三，最终交付是否合格。答案流畅、工具没有报错，都不能替代业务检查。报价对不对、证据是否齐全、是否停在应有的审批点，要分别判断。

一次顺利交接很容易演示。真正值得测的是连续交接、工具失败后交接，以及用户刚改完要求就发生交接。

例如，用户原本接受分批交货，后来改成必须一次到齐。测试不仅要看最新要求有没有保留，还要看旧要求是否仍在影响选择。如果压缩记录把两个版本并排留下，却没说明谁覆盖谁，后续模型可能继续按旧方案做事。

我会保留所有进入测试的任务编号，并明确每个任务最终是完成、失败、中断还是结果未知。耗时任务不能因为超过测试脚本的等待时间，就从统计里消失。未知结果单独列出，再解释原因。

这与训练样本流失不是同一个系统问题，但可以借用同一种检查习惯：先核对参与测试的任务是否都有去向，再讨论通过率。不能把厂商训练管线的 1% 数字，直接设成自己产品的容错标准。

如果主要丢的是审批条件，我会先把关键限制改成明确字段，必要时由程序校验；如果主要重复动作，就保留已执行动作及其结果标识；如果是证据找不到，就检查文件引用能否在下一段执行中访问。

这些办法仍需测试，不保证加字段就有效。结构写得再整齐，若引用指向失效文件，或者把未经验证的猜测写成已确认事实，任务照样会走错。

成本也要算完整。压缩本身的调用、重新读取材料、重复查询和失败重跑，都应计入一次合格交付的成本。只看到输入变短，无法判断用户是否真的少等、团队是否真的少花钱。

我的上线顺序会是先覆盖低风险任务，再逐步放开长流程。关键约束无法稳定保留时，宁可在交接处暂停确认，也不把“还能继续生成”当作“可以继续执行”。

一手来源与日期：阶跃星辰团队，Inside Step 5 Preview: Architecture and Training for Agentic Work，2026 年 10 月 15 日。本文讨论这次技术披露，不把它写成模型 API 首次上线。
研究对象与方法：Step 5 Preview 的长任务训练系统。本文选取上下文压缩参与任务训练，以及样本生命周期追踪两项机制；没有据此比较不同厂商模型排名。
数字与条件：低于 1% 对应作者训练管线的端到端样本丢失率。文章未给出该项的完整样本数、置信区间或独立复现，也没有提供本文建议的业务对照实验。
能力边界：有限上下文中的可恢复状态，不等于无限记忆、不会遗忘或任务必然完成。训练系统经验也不能直接换算成用户侧可靠性承诺。
本文判断：采购示例、两路对照、连续交接测试和上线顺序均为产品设计建议。本文未运行该模型，未声称获得实测收益。