microsoft / autogen

A programming framework for agentic AI. Discord: https://aka.ms/autogen-dc. Roadmap: https://aka.ms/autogen-roadmap
https://microsoft.github.io/autogen/
Creative Commons Attribution 4.0 International
28.18k stars 4.12k forks source link

[Suggestion]: Change behavior of config cloning in `register_reply` #2487

Open PyroGenesis opened 2 months ago

PyroGenesis commented 2 months ago

Describe the issue

When you register a reply to a ConversableAgent, you have the option of providing a config parameter which could be used for LLM generation or other extra variables.

This is then assigned to the "private" _reply_func_list in this way:

self._reply_func_list.insert(
    position,
    {
        "trigger": trigger,
        "reply_func": reply_func,
        "config": copy.copy(config),
        "init_config": config,
        "reset_config": reset_config,
        "ignore_async_in_sync_chat": ignore_async_in_sync_chat and inspect.iscoroutinefunction(reply_func),
    },
)

My focus is specifically on config and init_config. This works well when the config is modified over time by the reply function, and reset() resets the config as expected. However, this approach leaves no way to modify the config from outside the reply function, which is a useful functionality.

If the user really wants to modify the config, they will need to access _reply_func_list. What if we invert the cloning behavior so that config is the original object and init_config is the clone? That way, the user can keep a reference to the config object and update it if needed accordingly,

Let me know if I've missed something important or there is a better way to give reply functions additional mutable data. My current workaround is to use functools.partial() to pass in a mutable dict.

Steps to reproduce

No response

Screenshots and logs

No response

Additional Information

No response

ekzhu commented 2 months ago

I think it makes sense to allow config to be modified externally from the agent. You might want to take a look at experimental branch as we are working toward more extensible API. cc @jackgerrits