Improve AGS ComponentFactory spec to add provider class

[victordibia]

AGS component spec currently has a broad component_type attribute that is used to determine the class needed to load the spec.

{
      "component_type": "agent",
      "name": "assistant_agent",
      "agent_type": "AssistantAgent",
      "system_message": "You are a helpful assistant. Solve tasks carefully.",
      "model_client": {
        "component_type": "model",
        "model": "gpt-4o-mini",
        "model_type": "OpenAIChatCompletionClient"
      }
    }

The limitation here is that component_factory needs to include logic for importing the right class needed to instantiate runtime objects for the component.

This could simplify the process of supporting new component types - i.e. component_factory will automatically attempt to load the class using the args provided.
It would perhaps be useful to expand the spec such that information about how to load the component is self contained in the spec.

{
    "component_provider": {
        "python": "autogen_agentchat.agents.AssistantAgent"
    },
    "name": "assistant_agent",
    "agent_type": "AssistantAgent",
    "system_message": "You are a helpful assistant. Solve tasks carefully.",
    "model_client": {
         "component_provider": {
        "python": "autogen_ext.models.OpenAIChatCompletionClient"
    },
        "model": "gpt-4o-mini",
        "model_type": "OpenAIChatCompletionClient"
    }
}
 

Design Issues

Some components needs custom logic to map from declarative spec to runtime instances e.g.,

• parsing the representation of combinations of termination conditions
• adding default behaviours e.g., default system messages if none provided etc

In these cases, the benefit of an expanded spec is reduced (adds bloat to the spec) and perhaps can only be used for some validation (e.g., verifying that the intended class exists etc).

Discussions welcome.

[jackgerrits]

Essentially the same way we want to handle model client provider loading, I like it! #3624