交接发生在任务还没做完的时候
10 月 27 日提交的 arXiv 论文 2610.36523 挑了一个很少被单独测量的环节：任务交接。六位作者，题目就叫「跨智能体交接的任务接管基准」。他们要处理的情况其实很常见——几个智能体一起做一件长任务，活儿没干完，责任先从一个模型转到了另一个模型。接手的那个得在前人的判断、观察和动作基础上继续，同时把剩下的要求做完。
难点在于怎么评。论文说得很直接：任务成功率和记忆留存分数都测不出这段过渡。前者只看结果，后者只看信息有没有留下，至于留下来的东西能不能被接着用，两者都不管。于是他们搭了 HSC-Bench，1039 个任务，拆成两条互补的赛道。
两条赛道，考的不是一回事
一条叫仓库证据恢复：前人读过的文件、查过的提交、踩过的坑，接手的模型能不能重新捞出来。另一条叫状态接续：已经建立起来的对话进度、工具调用记录、文件工作进展，接手的模型能不能从这儿往下接，而不是从头再来一遍。
这两件事在工程里经常被人当成一件事。团队挑接手模型的时候，习惯先看它在检索类任务上的排名，觉得找得到线索就等于做得下去。论文用两条赛道分开测，就是要把这个默认假设拎出来检验。
结果是三条。结构化交接状态让六款接收模型在证据恢复这条赛道上全部变好；在接续这条赛道上，多数模型有改善，但论文措辞留了余地，没说全部。更有意思的是第三条——两条赛道上表现最好的接收者不是同一批模型。也就是说，光看证据恢复的排名去挑接手的人，很可能挑错。
为什么这个环节现在才被拎出来
交接变重要，是因为长任务和多智能体正在同时成为常态。一个任务跑几小时、中间换模型、换上下文窗口、甚至换供应商，这些做法在过去一年里从实验变成了日常。而支撑它们的那套假设——上下文压缩一下、摘要传过去就行——一直没被系统验证过。
论文的做法还多了一层：它不只比对答案，还检查后续回复与动作，用来判断接手方有没有遵守已经定下的承诺、有没有重复做已经完成的工作。这两个检查项很实用，因为交接失败最常见的表现不是答错，而是把做过的事再做一遍，或者把已经否掉的方案重新捡起来。
本站此前记过的几份研究可以和它对上：多智能体工作流设计空间那份研究发现，持续性共享文档明显胜过辩论式结构；异步共享记忆缓冲那份则用一块共享缓冲替代轮流发言。它们都在说同一件事——信息在智能体之间怎么流动，比单个智能体有多聪明更能决定结果。HSC-Bench 补的是另一半：不得不交接的时候，那个包里到底该装什么。
能确定什么，还不能确定什么
要留的余地也不少。公开摘要没有给出逐款模型的得分、两条赛道的具体指标定义，以及这 1039 个任务的来源与分布。所谓「结构化交接状态」具体指什么格式、由谁生成、会不会随任务类型变化，摘要里也没有展开。这些细节目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
对正在搭多智能体系统的团队来说，摘要里已经够用的部分倒很朴素：交接时别只传一段总结，把工具调用记录、文件改动进度和已经定下的承诺一起打包；挑接手模型的时候，在自己的任务分布上分别测「找得到」和「接得住」，不要共用一个榜单。这两件事听着都像常识，恰恰是最常被省掉的两环。