在视频客流统计系统中，人体检测并不是最难理解的部分。真正影响最终计数结果的，是检测结果如何关联成连续轨迹，以及轨迹如何转换为有效事件。
如果将每一帧检测到的人体数量直接累加，就会导致同一人员被反复统计。
因此，系统需要在检测和计数之间增加目标跟踪、轨迹管理和事件状态机。
本文从工程模块设计角度拆解这一处理过程。
1. 系统模块划分
建议将客流统计逻辑拆分为六个独立模块：
| 模块 | 核心职责 |
|---|---|
| Detector | 人体检测 |
| Tracker | 多目标关联 |
| Track Manager | 轨迹生命周期管理 |
| Zone Manager | 区域和边界判断 |
| Event Engine | 进出事件生成 |
| Aggregator | 统计结果聚合 |
这种设计可以降低模块之间的耦合度。
例如，更换人体检测模型时，只要输出协议保持一致，后续跟踪和事件模块就不需要完全重写。
2. Detector：统一检测结果的数据结构
检测模块负责输出当前帧中的人体目标。
建议使用统一的数据结构：
class Detection:
def __init__(self, bbox, confidence, class_id):
self.bbox = bbox
self.confidence = confidence
self.class_id = class_id
其中：
- bbox：目标边界框；
- confidence：检测置信度；
- class_id：目标类别。
如果使用3D视觉，还可以增加深度或空间坐标字段。
但需要注意，深度数据必须标记有效性。不能将无效深度值直接传递给后续空间关联模块。
3. Tracker：维护连续目标ID
跟踪模块接收当前帧的检测结果，并与已有轨迹进行匹配。
一个简单的轨迹数据结构可以设计为：
class Track:
def __init__(self, track_id):
self.track_id = track_id
self.bbox = None
self.center = None
self.age = 0
self.missed_frames = 0
self.state = "ACTIVE"
跟踪模块需要处理三种情况：
匹配成功： 更新已有轨迹的位置和状态。
没有匹配的检测目标： 创建新轨迹。
已有轨迹没有匹配目标： 增加丢失帧数，并根据阈值决定是否保留。
实际系统可以使用卡尔曼滤波预测目标位置，并结合IoU、运动距离和外观特征进行关联。
4. Track Manager：处理轨迹生命周期
并不是每条轨迹都应该立即参与计数。
例如，目标可能只在画面边缘短暂出现，也可能因为遮挡而暂时丢失。
因此，需要对轨迹设置生命周期状态：
TENTATIVE
|
| Confirmed
v
ACTIVE
|
| Temporarily Missing
v
LOST
|
| Re-associated
v
ACTIVE
LOST
|
| Timeout
v
REMOVED
其中：
- TENTATIVE：待确认轨迹；
- ACTIVE：有效轨迹；
- LOST：暂时丢失；
- REMOVED：已移除。
通过轨迹生命周期管理，可以减少短暂误检和瞬时遮挡对后续统计的影响。
5. Zone Manager：区域与虚拟计数线
在入口区域建立虚拟计数线，使用目标中心点判断其相对位置。
对于直线：
[
ax+by+c=0
]
目标点 (P=(x,y)) 的位置关系可以通过：
[
S(P)=ax+by+c
]
进行判断。
当连续位置从直线的一侧移动到另一侧时，系统可以认为发生了候选跨线事件。
但实际工程中还需要增加方向判断、最小位移、边界缓冲区和轨迹连续性检查。
这样可以避免目标在边界附近轻微移动时反复产生事件。
6. Event Engine：使用状态机管理计数
事件模块不应直接在每次跨线检测时执行累加，而应该先完成状态确认。
一个简化状态机如下：
class EventState:
OUTSIDE = "OUTSIDE"
ENTERING = "ENTERING"
INSIDE = "INSIDE"
EXITING = "EXITING"
状态转换逻辑：
OUTSIDE -> ENTERING
ENTERING -> INSIDE
INSIDE -> EXITING
EXITING -> OUTSIDE
只有当目标完成符合规则的状态转换时，才生成ENTRY或EXIT事件。
事件模块还需要考虑：
- 轨迹丢失；
- 短时间反向移动；
- 多人交叉；
- 重复触发；
- 入口边界附近停留。
状态机参数应通过实际视频标注和测试确定，不能直接将一组固定参数应用到所有入口。
7. 数据去重：处理重复事件和重复上传
工程上有两种常见的重复计数问题。
第一种是算法重复：同一条轨迹多次触发计数。
第二种是传输重复：设备上传失败后重新发送，导致服务端收到同一事件多次。
建议为每条事件分配唯一ID：
event = {
"event_id": "cam01_track102_entry_001",
"device_id": "cam01",
"track_id": "track102",
"event_type": "ENTRY",
"zone_id": "entrance01",
"timestamp": 1730800000
}
服务端可以利用唯一索引或幂等键处理重复提交。
需要注意，track_id通常只在特定设备或特定运行周期内有效，不能直接作为跨设备的永久人员标识。
8. Aggregator：将事件转换为统计数据
当有效事件进入统计模块后，可以根据时间和区域进行聚合。
例如：
[
NetFlow=EntryCount-ExitCount
]
其中：
- EntryCount：统计周期内进入事件数量；
- ExitCount：统计周期内离开事件数量。
还可以按照门店、设备、入口和时间段生成不同维度的统计结果。
需要注意，净流量不等于当前门店实时人数。如果统计开始前已经有人员在店内，还需要考虑初始人数和统计边界。
9. 性能测试与异常场景
建议将系统测试拆分为算法测试和工程测试。
| 测试项目 | 主要验证内容 |
|---|---|
| 单人进出 | 基础计数准确性 |
| 多人同时通过 | 目标关联能力 |
| 交叉遮挡 | ID切换和轨迹中断 |
| 入口徘徊 | 状态机与重复事件 |
| 设备断网 | 缓存和补传 |
| 长时间运行 | 内存和资源稳定性 |
| 高密度输入 | FPS和端到端延迟 |
系统性能指标建议同时记录平均值和P95值。
对于最终人数结果，还应使用人工标注数据计算MAE，并在不同测试场景中分别报告。
10. 总结
AI客流统计系统的核心不是简单累加人体检测结果，而是建立完整的目标跟踪和事件处理链路。
Detector负责发现目标，Tracker负责维持轨迹，Track Manager管理生命周期，Zone Manager识别空间变化，Event Engine生成事件，Aggregator负责最终统计。
这种模块化设计更便于算法替换、参数调整和故障排查，也更适合复杂零售场景下的长期维护。
