一句话定义：长时程多轮评估（Long-Horizon Multi-Turn Evaluation）是一种评测方式——不再只给模型一道题、一次机会、一个补丁，而是把它放进一段持续几十甚至上百步的交互里，看它能不能在反复试错、被追问、需求变更的过程中，最终把活干完。
用一个比方说清楚
传统的单轮评测像驾考科目二：倒车入库，一次动作标准就得分，压线就挂。长时程多轮评估像真的开车跑一趟长途：中途导航改了目的地，乘客不停问东问西，你走错路口得自己倒回来，油表还亮了灯。考的不是"你会不会打方向盘"，而是"你能不能把人和车一起带到终点"。
在编码场景里，这个差别尤其明显。单轮评测通常给一个 bug 描述，模型输出一个补丁，跑测试通过就算对。可真实的开发不是这样：你要先问清楚需求，找到相关文件，改一处发现另一处坏了，跑测试看到回归，回滚，换个思路再改，中途同事说"这个方案我们不接受"，你还得重新规划。
和相邻概念的区别
| 维度 | 单轮评测 | 长时程多轮评估 |
|---|---|---|
| 交互轮次 | 一问一答，一次提交 | 几十到上百轮 |
| 中间反馈 | 基本没有 | 测试报错、用户追问、需求变更 |
| 评判对象 | 最终补丁是否正确 | 最终状态 + 过程质量 + 有没有越改越乱 |
| 典型失败 | 做错题 | 迷路、反复推翻自己、目标漂移、上下文耗尽 |
近两年出现的 SWE-Journey 这类基准，走的就是这条路：把"修一个 bug"扩展成"走完一段开发旅程"，让助手在连续多轮的对话与操作中接受考验，而不是交完一个补丁就结束。
对从业者和普通人的意义
对做模型和做产品的人：单轮榜单的分数已经不够用了。上下文管理、记忆保持、工具调用的稳定性、失败后的自我恢复、时间与 token 预算控制——这些能力在单轮设置里几乎测不出来，却恰恰决定了 AI 能不能被托付真正的长任务。选型时，值得专门看多轮、长时程设置下的表现。
对普通职场人：工具再强，也得会"带它跑长跑"。把大目标拆成阶段性目标，给中间反馈，发现跑偏及时纠偏，比一次性甩一个巨大需求效果好得多。
要注意的地方：长时程评估更慢、更贵，也更依赖运行环境的稳定，评判标准往往掺入主观判断，容易把"环境问题"记成"模型问题"。具体某个基准包含哪些任务、怎么打分，以官方页面为准。