在Akka Management参与者的特定情况下，因为该项目不依赖于Akka Typed（因此所涉及的参与者是Classic参与者），您可以将Typed ActorContext视为Classic ActorContext并使用ActorSelection。
从你的问题来看，我猜是Java（在Scala中，隐式语句使这一点不那么冗长，也许还能阐明意图）：

akka.actor.typed.javadsl.Adapter.toClassic(context).actorSelection(path).resolveOne(timeout)

对于只想解析一个Typed本地参与者的情况，我发现的最有效的策略是将解析功能合并到创建ActorSystem时提供的行为中。想被找到的参与者将向ActorSystem注册，其他参与者可以向ActorSystem请求ActorRef。
这里的一个微妙之处是context.getSystem()给了你一个ActorSystem<Void>，它扩展了ActorRef<Void>。

// Might not actually be syntactically valid Java, but hopefully the fix to make it
// legal is obvious...
ActorRef<MyActorSystemCommand> systemRef = context.getSystem().unsafeUpcast<MyActorSystemCommand>()

请注意，为ActorSystem获取正确的消息类型非常重要：如果ActorSystem的行为不接受这种类型的消息，那么当您发送消息时，actor系统将崩溃（据我所知，没有办法防止actor系统关闭）。
此方法的一个改进是定义一个仅限本地的接收器参与者，它在ActorSystem启动时产生：希望与该接待员交互的参与者通过上述方法获得其X1M15N1X，然后该参与者处理解析。
当然，请注意，在这两种方法中（就像集群感知的Receptionist一样），只有显式地选择这样被解析的参与者才是可解析的。让演员更多地负责向外界展示多少。