Add a `run` api?

[qingyun-wu]

Why are these changes needed?

In many scenarios, we may just want to involve one single agent to finish a straightforward task. Currently, we need to do that through generate_reply, which is not easy to use. To improve usability, shall we add this run API? This addition won't break the existing usage of generate_reply.

The change in this PR is an initial proposal. If we agree we should add this run API, there are more changes to be made.

Related issue number

Checks

• [ ] I've included any doc changes needed for https://autogen-ai.github.io/autogen/. See https://autogen-ai.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
• [ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
• [ ] I've made sure all auto checks have passed.

[marklysze]

I think this would be useful! Looks straightforward - one thought is whether it's called run or chat, feels a bit like chatting with an agent.

[randombet]

I think this would be useful! Looks straightforward - one thought is whether it's called run or chat, feels a bit like chatting with an agent.

Agree 'run' sounds ambiguous. We need make this self explanatory. What is the use case here?

[qingyun-wu]

I think this would be useful! Looks straightforward - one thought is whether it's called run or chat, feels a bit like chatting with an agent.

Agree 'run' sounds ambiguous. We need make this self explanatory. What is the use case here?

The use case is we just want one agent to generate a reply. Almost same use cases as the current generate_reply api. But both the name generate_reply and the arguments of generate_reply are complex. Find a comparison below.

[marklysze]

I think this would be useful! Looks straightforward - one thought is whether it's called run or chat, feels a bit like chatting with an agent.

Agree 'run' sounds ambiguous. We need make this self explanatory. What is the use case here?

The use case is we just want one agent to generate a reply. Almost same use cases as the current generate_reply api. But both the name generate_reply and the arguments of generate_reply are complex. Find a comparison below.

How about respond?

[sonichi]

One clarification I'd like to ask is what happens when the same API is invoked twice consecutively. Is it allowed? Does it restart or continue the conversation? It's ambiguous from the api name. Also remember that we have an API send which is less ambiguous and allows a simple message to be the input. We can add a default_user_proxy which can be imported from the library and let users do default_user_proxy.send to be the one-liner.