The question seems like it should have an obvious answer, but that's not necessarily the case. There are several possible interpretations of the term actor in ActivityPub. So, what is an ActivityPub actor?
A Profession?
According to Oxford's Advanced Learning Dictionary, an actor is "a person who performs on the stage, on television or in films, especially as a profession." I think it's safe to say that an actor in ActivityPub does not generally represent that, although an ActivityPub actor could represent a professional actor in specific cases.
Activity Streams 1.0 (AS1)
The predecessor to Activity Streams 2.0 that ActivityPub is based upon defined as actor as follows: "Describes the entity that performed the activity."
That sounds like a very reasonable, commonsense definition. At a technical level, an actor is represented as a JSON object (any JSON object).
Activity Streams 2.0 (AS2)
The Activity Streams 2.0 Recommendations describe an actor as "entities capable of carrying out an Activity" [Core] and "entities that either performed or are expected to perform the activity" [Vocabulary].
Again, this seems like a solid commonsense definition. Technically, this version of the specification defines several specific actor types in JSON-LD (Person, Group, etc.), but no actor abstract type. Extended actor types are allowed but it's not clear how they are identified. One could argue that any AS2 object in the actor role of an activity is an AS2 actor.
ActivityPub (AP)
ActivityPub constrains the Activity Streams 2.0 JSON-LD representation of an actor to contain inbox and outbox properties. This could be thought of as an ActivityPub actor as opposed to the more general Activity Streams 2.0 actor. An application could actually have representations for both kinds of actors. An ActivityPub actor can participate in AP message transfer while an AS2 actor can represent actors without that AP-specific capability.
Note that although AP actors are required to have both an inbox and an outbox (even if they are nonfunctional), the AP Recommendation doesn't not prohibit other non-actor AS2 objects from having an inbox, outbox or both. Claiming this isn't allowed is a fallacy of the inverse.
Hewitt's Actor Model of Computation
The other claim I see from time-to-time (including from one of the ActivityPub Recommendation authors) is that ActivityPub is based on Hewitt's Actor Model of Computation (or more tersely, that it is based on the "actor model"). This position appears extremely dubious to me. Sure, both Hewitt and AP use the word "actor", but that doesn't mean they are the same concept. The most obvious problem is that an actor in AS2 and AP is not a "unit of computation" as it is defined in Hewitt's model. Behaviors (side-effects) defined in the AP Recommendation are performed by server code, not by AP actors.
I've searched the archives of the W3C working group that created ActivityPub and I see no discussion or even mention of Hewitt's model. The same goes for the IRC transcripts prior to the Recommendations approval. There may have been some private discussions about it, but the public mention of this claim seems to be after-the-fact. However, even if it weren't it doesn't resolve the issue that an AP actor is fundamentally different than a Hewitt actor.
Sometimes people promoting this "AP is an actor model" view refer to the AP inbox as supporting their claim. However, there are problems with that too. I assume they consider an inbox to correspond to an actor's "mailbox", but Hewitt's paper explicitly states that an actor mailbox is not required in his model.
The following are not required by an Actor: a thread, a mailbox, a
message queue, its own operating system process, etc. ... For example, if an Actor were required to have a mailbox then, the mailbox would be an Actor that is required to have its own mailbox… - Carl Hewitt
The AP inbox is explicitly based on the inbox concept in the Linked Data Notifications Recommendation (it even uses the same JSON-LD context term). The word "actor" isn't even used in that specification.
To be clear, I think the actor model is very interesting. It would be interesting to implement an AP server using Hewitt's actor model. However, those computational actors would almost certainly not be AP actors. (Also, just because a server is implemented using an actor model-related programming language like Elixir, doesn't mean the developers actually used those features to implement their AP server.)
Conclusion
The Activity Streams documents provide good commonsense definitions of the meaning of an actor, even if the AS2 JSON-LD representation makes it challenging to identify which objects are actors (if they are not one of the small set of predefined actor types). ActivityPub extended the concept of an actor to include message exchange, but this doesn't mean it's based on the "actor model" (Hewitt's model). Both AP and AS2 actors can coexist in an AP implementation (although I don't know of any servers that currently do this).