想象一下这样的场景：某个城市突发地震，救灾指挥中心需要立刻知道哪些区域受损严重、哪些道路还能通行、哪些建筑下面可能埋着人。你能调动的是一千个携带手机的志愿者和两千个需要分布式采集的环境数据点——而且这些数据点的位置、时间要求、需要的传感器类型各不相同，志愿者们的技能组合也五花八门。你怎么在几小时内把这些任务分配出去，让志愿者们都跑在合理的路线上，尽可能多地完成任务？
这不是一个虚构的问题。西北工业大学和福州大学的研究团队在 2023 年发表的一篇 IEEE TMC 论文（以下简称 TsPY）里，就把这个问题的数学形式完整地摆了出来，并且给出了一个看起来相当聪明的解法。
这篇文章是我准备在这个系列里讲的第一篇。它发表于 2023 年，是五篇同领域论文里时间最早、方法最"经典"的一篇——但"经典"不意味着简单。恰恰相反，它把"大规模异构任务在线分配"这个问题的骨架搭得非常清晰，后面四篇论文（图论建模的 HoCs-MPQ、强化学习的 MANF-RL-RP、分层混合的 Hi-HUTA、演化博弈的 HoAs-PALN）几乎都可以看作是在这个骨架上不断长肉。
所以，我们从它开始。
问题有多难？
论文把这套场景抽象为七个同时需要满足的约束条件：任务有丰富的技能类型要求（不是所有志愿者都能干所有活）、时空要求不规则（你3点之前到不了西区就没用）、多个任务在时空上有重叠（同一个志愿者可能同时被三个任务抢）、任务和参与者都是动态加入的（不是一开始就全摆好）、志愿者可能同时具备多项技能、参与者既可能"顺便"完成任务也可能"专门"去完成任务、分配方式既可以是"推荐一个点"也可以是"推荐一条路径"。
同时满足这七条的分配问题，在数学上是一个典型的 NP-hard 组合优化——你不可能用暴力枚举找到全局最优解，必须在合理的时间内找到一个足够好的近似解。
核心思路：用一棵四层树组织所有任务
这应该是全篇最漂亮的设计。
研究团队没有用集合（Set）也没有用队列（Queue）来管理任务——这两种数据结构在前面的大量工作里有人用过，但它们都有一个致命问题：任务的属性被"封装"了，你没法直接按某个维度去切分和检索。
TsPY 的做法是把每个任务拆解为四个属性层：技能类型 → 时间要求 → 空间位置 → 原子任务。然后按这四个层级把任务组织成一棵层级树。
打个比方。假设你要管理一千本书，如果把它们全部扔进一个大箱子，你想找一本"计算机类的、2020 年以后出版的、在第三书架上的书"，就得每次翻遍整个箱子。但如果你先把书按类别分架（第一层），每个架子里按出版年份排（第二层），每年里按书架位置排（第三层），每一格里再按具体书名排（第四层）——你只需要沿着这个层级一路往下走就能定位。
TsPY 做的事情本质上就是这个。技能层在最顶端，这意味着当你知道一个志愿者具备哪些技能后，可以直接跳到对应的技能子树里去检索，不需要关心他根本做不了的任务。时间层按时间升序排列，保证在同一个技能子树里优先检索时间更紧迫的任务。空间层进一步缩小范围。最底层的原子任务是实际被"分配"的最小单元。
时间优先 vs 空间优先：一棵树的两种建法
论文里有一个很有趣的发现。构建层级树的时候，到底是先按时间分层再按空间分（time-first），还是反过来（space-first）？直觉上可能觉得差别不大，但实验结果很明确：time-first 的平均任务-参与者匹配率比 space-first 高出超过 13%。
为什么？文中给了一个很直观的解释。假设一个志愿者有技能 s2 和 s3，树下有两个候选任务：t21（时间要求 m3，空间要求 l4）和 t31（时间要求 m1，空间要求 l5）。在 space-first 的树里，这个志愿者会先匹配到 t21——因为空间层靠近根节点。t21 的时间要求是 m3（较晚），这意味着他完成 t21 后已经没有机会再去做别的事了。但在 time-first 的树里，他会先匹配到 t31（时间要求 m1），完成之后可能还有余力在 m2、m3 时间段继续接任务。
用生活化的语言说：先看时间的策略让每一个志愿者的"可用窗口"被更充分地利用，而不是被一个时间要求很宽松但恰好空间匹配的任务提前锁死。
并行计算：为什么实际加速只有 3.8 倍而不是 6 倍？
TsPY 的层级树还有一个特别适合并行的特性：顶层按技能分完之后，不同技能子树之间是完全独立的，可以在不同 CPU 核上并行处理。论文的实验用了一颗 6 核 CPU，理论加速比应该是接近 6 倍，但实际只实现了 3.8 倍（运行时间从 22572 秒降到 5827 秒，减少了约 74%）。
差距在哪？论文详细拆解了函数运行时间后给出了答案：并行计算的额外开销（广播并行变量等）消耗了约 12% 的时间，而且分配到每个核上的参与者数量往往不是 6 的倍数，没法让 CPU 一直满负荷运转。但如果你只看核心函数（合并树和任务分配），并行加速比确实达到了 5 倍——接近理论极限。
这个分析本身虽然不是什么惊天发现，但它很诚实地展示了"从理论到工程"的那个 gap，对于想真正复现这个系统的人来说很有参考价值。
实验：九个维度下的全面评估
TsPY 的实验设计非常细致，覆盖了九个维度：改变参与者数量、改变任务数量、改变技能类型数量、改变任务内容数量、比较点推荐 vs 路径推荐、比较参与式感知 vs 机会式感知、改变空间分布（高斯分布 vs 签到经验分布）、降低速度范围、比较层级树 vs 集合/队列。
几个值得注意的结论：
- 层级树 vs 队列/集合：当任务量小的时候（1000），三者的运行时间差距不大；但当任务量涨到 3000 时，层级树的运行时间（TsPN）是 2037 秒，而队列是 14258 秒、集合是 15250 秒——层级树的复杂度是 O(n)，而集合/队列是 O(n²)。这是数据结构选择对性能的直接影响，非常直观。
- 技能类型越多，匹配率越低——这符合直觉，因为每个任务对技能的要求更严格，候选参与者变少了。
- 路径推荐（给你一条完整路线）比点推荐（只告诉你下一个点在哪）的匹配率反而更低——因为路径推荐对时空约束的要求更苛刻。
局限与伏笔
TsPY 也有一些明显的限制。首先，它假设参与者的移动时间可以精确估计——但现实中即使最好的导航软件也无法做到这一点。论文在"未来工作"部分也诚实承认了这个问题，并提出可以用"时间段+区域"代替"时间点+位置点"来缓解。
其次，TsPY 的方法本质上是启发式规则驱动的——时间优先、近距离优先、并行计算——没有涉及到任何学习或博弈的成分。这在 2023 年是可以接受的，但随着问题场景从"一群人做一堆事"变成"无人机+车辆+工人三方协同"，纯粹规则的方法就越来越吃力了。
而这个"越来越吃力"的方向，正好是后面四篇论文要解决的问题。
个人点评
读 TsPY 最让我感慨的倒不是技术本身——层级树这种数据结构说起来并不新奇。而是论文对工程细节的诚实程度。很多顶会论文在汇报加速比的时候喜欢拿最优情况说事，而 TsPY 在 4.4.2 小节里老老实实地告诉你"理论 6 倍加速，实际 3.8 倍，因为我们发现并行广播变量吃掉了很多时间"。这种对"为什么做不到完美"的解释，比一堆漂亮的数字更让我觉得可信。
另外，这棵层级树的设计有一个隐藏的好处：它天然支持"动态加入"。因为有新任务或新参与者加入时，只需要在对应的子树里进行局部更新，不需要重排全局。论文虽然没有特别强调这一点，但如果你顺着它的索引逻辑想下去，会发现这个特性对于需要在线实时响应的场景非常关键。
当然，TsPY 毕竟是一篇 2023 年的论文，它解决的问题场景是"单层：参与者直接去做任务"，没有涉及到无人机、车辆等异构智能体的协同。而在这个领域里，把无人机拉进来之后，问题复杂性会陡然上升——下一篇要讲的 HoCs-MPQ，就是在这个方向上迈出的关键一步。
素材来源
| 标题 | 来源 | 链接 |
|---|---|---|
| Online Organizing Large-Scale Heterogeneous Tasks and Multi-Skilled Participants in Mobile Crowdsensing | IEEE Transactions on Mobile Computing (TMC), 2023 | DOI: 10.1109/TMC.2021.3135155 |
