Actor 的模型为什么会被吹起来，你可以找英文维基的 History of the Actor Model 这个词条，下面有一梭子论文可以吃。

然后你可能逐渐会发现，他们讲的和你看到的东西差不多是两码事。这是因为一开始作为 model，纯粹要的就是 model of computation，而不是体系结构研究里的 model of computer，所以性能之类的预设情形下是不管的，要关心的就是“表达能力”。

就 model 本身来看，并发实际上是很被强调的，卖点之一就是 concurrent computation modeling。只是 actor model 并不只是要做基于其它 model 上扩充的理论，而是要完整地替代先前的理论，所以当然不只是并发，只不过把顺序的计算当作并发的特例而已。就发展过程的特色来看，还有就是强调指称语义(denotational semantics) ，不过这个你用不上。

注意这里的并发和一般开发者理解的概念有不小距离。理论上，并发是指表达计算作用(computational effect) 的程序的非确定性组合(nondeterministic composition) ，要解决的是如何应对本质上不可预测发生的现象（例如，接受用户的输入作为一种计算上的副作用）的抽象问题。而实际开发者理解的并发经常和多任务混淆，认为并发关心的是某个计算任务在“何时”“是否同时”“如何发挥计算资源”这样的具体实现下的具体性质，还经常和并行（确定性的计算渐进行为）混淆。这种偏差导致真正意义上的 model 本身的性质并不容易直接被利用。

顺便，上面有人提到的线程是抢占式多任务的主要实现方式，强调某些计算资源的独占性。协程是协作式多任务的一种实现。这些和并发其实没啥直接关系……硬说的话，任务调度策略本身还能扯上点关系。要回到模型，在 actor model 里扯 threading，显然就很不 pure 了。其实也有其它扩充既有设计实现多任务的替代方法（而且理论上显而易见更优越只是不足以使工业界广泛接受），只不过听起来没那么主流知道的人稍微少点而已。比如抢占式多任务用 engine （ timed-lambda ），协作式多任务可以直接用 continuation。

至于你现在看到的具体框架的实现吹的 model，已经是跟 OOP 互相扯皮了……要知道 OOP 根本就几个的像样的 model （比较著名的也就是 Luca Cardelli 的 sigma calculus，相当地脱离实际而且睁眼说瞎话吹简单），理论上对比根本没什么意义……苦口婆心连 thread of execution 都上了地 red herring 黑了半天 OOP，站得住脚的合理理由就是它黑的 class-based OOP 在这方面确实过于弱鸡这点罢了，但实际上 OOP 在这个问题上几乎弱鸡到是个其它不建议共享可变状态的阵营的都能干翻（比如纯 FP ），并没有体现出非 actor model 才能上位这点。（而且更讽刺的是，Alan Kay 等强调的“正版” OOP 实际上用的也就是 message passing。）

所以选择 actor model 很大程度还是 political 的问题了。