warringstates的aiplayer中有几个管理器每帧更新:
1. build_mgr（工程部）
2. exploration_mgr(探索部)
3. army_mgr(军工部)
4. unit_mgr（人力部）
5. resource_mgr(资源部)
每个管理器相当于一个部门，它每帧会更新处理两个事情：a. 请求列表(request)处理; b.工作(job)列表处理;c.job的响应事件（触发式：
job提交的请求得到满足时触发回来）
每个部门更新时在job中处理自己要做的事情（这是b.步骤），发现需要其它部门的帮助时，则向其它部门发出请求, 其它部门会把请求收入队列，
然后更新时检查是否可以满足对应的请求(这是在a.步骤)，是则立即给响应，否则按排工作组员(job)去完成; 完成后再给对应请求部门（这里直接是请求者（job）发出响应 (这是c.步骤)
例如：
1. aiplayer的更新中发现人口太多，房屋不够则向build_mgr发出一个增加住房的请求，build_mgr收到后找到消耗金钱少的但住人多的
户型并产生一个AIBuildJob让组员去完成.
2. AIBuildJob的更新中发现要建造这样的户型所需的资源当前不够（缺少木村），于是他向resource_mgr（资源管理器）MakeRequest申请
所需要的资源。
3. resource_mgr的更新中:
a. 从请求列表中取出该请求，产生对应的AIHarvestJob放入jobs列表中。
b. 接着遍历更新jobs取出该AIHarvestJob更新
c. AIHarvestJob的更新发现该采集job还没有对应农民，于是它向unit_mgr请求对应类型的农民。
4. unit_mgr的更新中:
从请求列表中取出该请求, 发现当前mAvailableUnits中有符合的已产生的农民，于时立即响应给对应的请求者AIHarvestJob
AIHarvestJob把对应的农民登录到mHarvesters中.(说明：如果没有的话则产生一个AITrainJob，在AITrainJob的处理中会看是否有对应unitype的工厂，
没有则向build_mgr发出请求，有则向资源请求对应的单位所需要的资源，等资源管理器更新时发现请求满足并响应回来时则开始向对应的工厂发出
eCOMMAND_TYPE_Train指令，之后就会跑到GameBuilding的Train工作流程）
5. resource_mgr的更新中:
遍历更新jobs取出该AIHarvestJob进行更新，该AIHarvestJob遍历mHarvesters取得那个农民，向他发出eCOMMAND_TYPE_Harvest
指令。
6. object_mgr的更新中:
遍历所有单位进行更新，轮到那个农民更新时，它think函数中发现当前指令是eCOMMAND_TYPE_Harvest，于是它开始了Harvest的
工作流程：判断背包中木材是否满了，是则回城（搜索路径），否则寻找木材资源（搜索路径），到达后卸载/收割资源.
这样当木材足够时在resource_mgr的更新中,发现对应的木材资源请求足够时就会移除该请求并向
对应的AIBuildJob发出响应说明木材已收集够了; AIBuildJob收到后接着会向unit_mgr请求一名建筑工人。
（插入说明： 向unit_mgr请求所得的工人都是出租方式的，时间到了会收回并按请求级别优先级重新分配给其它需要他的请求）
由于之前收割的农民租期到了，而且那个木材收割的request已被移除(因此没再请求分配农民)。
所以unit_mgr会把当前这个农民重新分配为建筑工人，向对应AIBuildJob发出响应。AIBuildJob收到后开始在主城附近有块空地
并向建筑工人发出eCOMMAND_TYPE_Build指令让其开始建造的工作流程.
其它军工部的更新会判断当前是否需要军队，并向人力部请求对应的兵，人力部又会看是否有这样的兵，没有的话则判断对应产生
这样兵种的兵工厂是否存在，不存在的话又会向工程部发出请求对应的兵工厂，工程部收到后又会判断是否有足够资源，没有的话
又会向资源部要求对应的资源，资源部又会向人力请求对应的农民来采集资源，等等，如此类似的相关循环。。。