Answers:
参与者和FRP都不都是关于流媒体的。Actor甚至不支持输出流的外部配置。
FRP的特征在于其在线性时间轴上的建模信号和事件，这使FRP行为能够以确定性的方式构成。演员的主要特点是按不确定的顺序处理消息，几乎没有任何组成属性（即，您不能将两个演员的安排视为更大的演员）。
如果您要寻求相似之处，则参与者和FRP都与lambda演算有密切的关系。两者都可以对响应人类输入的系统进行建模。两者都支持内部（本地）状态建模。
FRP通过积分或累加器（随时间折叠）来支持局部状态，而参与者模型则通过允许每个参与者针对当前消息指定下一条消息的行为来支持状态。这种对本地状态的普遍支持使得FRP和Actor都不足以进行实时编程（或程序代码的运行时升级）；失去重要状态变得太容易了。
关于应用程序域：
Actors模型非常适合开放系统，我们可能希望在运行时安装或维护Actor。Actors模型也不太适合分布式系统，因为消息的不确定性排序可以使一致的实现更容易。（参与者不适合分布式系统的原因是，在发生中断时确保消息“一次且仅一次”到达非常困难，参与者也往往需要分布式GC，这很痛苦。）
FRP非常适合随时间运行的封闭系统，例如机器人控制器，音乐编程，计算玩具。确定性和组成特征使FRP比参与者更方便使用，至少在FRP可以直接为解决方案建模的情况下。事实证明，很难将FRP与效果集成在一起（很好，而不会用杂质破坏模型）。最近通过“虫洞”进行了有效的FRP的工作-有效，独特或线性地访问资源。
FRP和Actor之间还有其他模型。
由John Paul Morrison开发的基于流的编程（FBP）确实支持消息流。
时间扭曲协议（或有关轻量级时间扭曲（LTW）的最新工作）将类似参与者的消息放置在逻辑时间轴上，以提供消息传递的更可控且更复杂的概念。时间扭曲通常用于大型并行和分布式系统，例如科学计算。最初的时间扭曲不适用于交互式模拟（对人类输入的响应），而LTW仅勉强适用。
我正在开发反应式需求编程（RDP），它可以在开放式和分布式系统中实现响应式，组合式，类似于FRP的信号处理和处理，并消除本地状态。RDP是通过将副作用限制为随时间变化的信号对资源状态的可交换，等幂影响。RDP需要重新考虑资源和状态模型。
我想从实际的角度指出它们的不同之处：
1）参与者将消息发送给其他参与者，此消息传递被明确和命令性地描述。
例如：
send msg to Actor137。
2）在FRP中，对数据流进行了声明式描述：
例如：
Cell134=Cell185+Cell42。
消息传递是由FRP框架处理的，您不必“手动”描述如何将消息从一个单元（类似地传递给Actor，封装状态，又称为行为）传递给另一个单元。
换一种说法：
函数式反应式编程的本质是在声明时完全指定值的动态行为。因此，所有的依赖项Cell134都在声明点定义。
这是不正确的角色模型。在A定义参与者的源代码中没有在同一位置定义影响参与者行为的参与者A。
最近，我注意到两者之间有一个有趣的混合体：Akka流，其中以声明的方式描述了数据流，但使用参与者来实现。
另一个区别是：演员倾向于异步，而FRP倾向于同步（通常没有毛刺）。