Bring AutoGen to dotnet about autogen HOT 23 CLOSED

Bring AutoGen to Semantic Kernel

from autogen.

@sonichi

Step 1 already been tested. MLNet-task-101 is fully driven by a dotnet implementation of dynamic group chat

For step 2: That would be a really interesting idea. If the method has been proved to work well, we can simply copy-and-paste the methodology over other machine learning python libraries, convert them into dotnet, and Luis's dream (and mine as well) would become true

from autogen.

Step 1 could be: test how well C# works with LLM. For example, create a C# coding agent by modifying the default system message of AssistantAgent, and a C# execution agent by extending execute_code in code_utils.py to support C# code.

It that works well,
Step 2: ask autogen agent to convert python code to C# :)

from autogen.

Porting the source code of AutoGen to .NET/TypeScript/Java/Rust/etc. ist exactly the kind of work, which a system like AutoGen should be able to do.

from autogen.

Nice. A PR with C# agents is welcome.

from autogen.

I am considering making that PR !

from autogen.

@dazinator No IMO, we can just provide a function_call called run_dotnet and let llm decide how to execute the code.

And it takes extra steps to run a piece of dotnet code if we want to utilize dotnet sdk? dotnet interactive would be a better choice here (or dotnet script) as it doesn't require a project to be created before running a piece of code.

from autogen.

Makes sense to me especially the potential for integration with existing .NET libraries and tools.

From a repo / ownership perspective I'm happy to follow the AutoGen community lead here.

from autogen.

@LittleLittleCloud
dotnet interactive looks good. It does appear to execute a different dialect of c# than "standard" c# though, not sure whether that would need any special consideration.

I thought of docker just as means to employ or control the build and execution environment. Its common in dotnet projects to use docker multistage builds - so a dockerfile has a build stage which uses the sdk image to compile the code, and a run stage which uses the runtime image to execute those binaries. The run image could be pushed to a container registry for onwards deployment for example.

I guess I'm too new to this project to decide if any of that is really desirable in this case. It sounds like dotnet interactive could make that all go away.

My dream use case for autogen would be that I'd want to use it to develop simple dotnet command line applications that could be onwards deployed. For me this would mean not only producing c# code to fulfil a certain task but building that code (so via the dotnet sdk) and running it, testing it etc. It's not typical to build run and distribute professional dotnet apps as 'dotnet interactive' apps. Perhaps this is me getting confused with the code interpretor capability in autogen, vs what you can actually achieve with it 🤔

from autogen.

To enable such experience, one of the challenges is how to construct a workflow that can be used to incremental editing/improving a workspace or project, rather than a single file. I don't have a very clear answer for that question now, but feel free to provide any thought on it.

I was thinking at a very high level, I'd want to structure something like a dev team, consisting of:

• Product Owner Role (user proxy agent)
  • initiates work by providing a "user story"
  • is asked to clarify any requirements
• Developer (assistant agent)
  • planning phase
    • tries to break down user story into set of actionable tasks
    • if has any questions around the requirements, asks the product owner for clarification
  • development phase
    • iterate on the tasks until the code passes QA
      • e.g might be a task to create the new dotnet project, then add specific classes and tests that implement the required functionality.
    • let QA know when something is completed for testing.
    • if QA reports any issues then ask any clarifying questions to QA and then plan a task to fix it.
• QA (assistant)
  • take the output from developer assistant and try to run it.
  • if the code passes QA checks then TERMINATE
    • else report any issues back to Developer assistant.

Something like that.

I'm order to try to eliminate some of the complexity, I thought it might be a good idea if this team was always focused on producing an entirely new dotnet project - I.e so it doesn't have to understand any pre-existing code base. I'm not sure how much this helps as I guess if the developer agent has to iterate on its own output then to some degree it has to be able to "understand" the output it has produced in a prior iteration.

I'm completely knew to all this, and I have no feel for whats actually possible yet - so this was going to be my thesis for getting stuck into and learning about this project and just what is possible right now.

from autogen.

Sorry I have no idea about the workspace / single file issue. I thought I had seen another open source project that is able to iterate on a code base containing multiple files, perhaps it was AutoGPT.. but I can't remember :-(

chatdev. possibly @dazinator

from autogen.

Would the user proxy agent have to be extended so that it could recognise and execute c# code as opposed to python?

Dotnet has a docker image for a runtime as well as the sdk, so it would also be really nice if the code can execute via the docker container.

from autogen.

@LittleLittleCloud dotnet interactive looks good. It does appear to execute a different dialect of c# than "standard" c# though, not sure whether that would need any special consideration.

I thought of docker just as means to employ or control the build and execution environment. Its common in dotnet projects to use docker multistage builds - so a dockerfile has a build stage which uses the sdk image to compile the code, and a run stage which uses the runtime image to execute those binaries. The run image could be pushed to a container registry for onwards deployment for example.

I guess I'm too new to this project to decide if any of that is really desirable in this case. It sounds like dotnet interactive could make that all go away.

My dream use case for autogen would be that I'd want to use it to develop simple dotnet command line applications that could be onwards deployed. For me this would mean not only producing c# code to fulfil a certain task but building that code (so via the dotnet sdk) and running it, testing it etc. It's not typical to build run and distribute professional dotnet apps as 'dotnet interactive' apps. Perhaps this is me getting confused with the code interpretor capability in autogen, vs what you can actually achieve with it 🤔

Ha I see, so you are seeing a larger picture than I was. dotnet interactive would be a good solution for creating one-time solution on a task. But to create solution that can be reuse/deploy/distribute will require a more sophisticated workflow. It's both challenging and exciting!

To enable such experience, one of the challenges is how to construct a workflow that can be used to incremental editing/improving a workspace or project, rather than a single file. I don't have a very clear answer for that question now, but feel free to provide any thought on it.

from autogen.

Sorry I have no idea about the workspace / single file issue. I thought I had seen another open source project that is able to iterate on a code base containing multiple files, perhaps it was AutoGPT.. but I can't remember :-(

from autogen.

(sorry im new to all this so sorry if i come across as an idiot for asking this) could you add support for local llm's heres a template that im using that works for me

config_list = [
{
"api_type": "open_ai",
"api_base": "https://yyyyyyyyyy-5001.proxy.runpod.net/v1",
"api_key": "sk-1111111111111111111111111111111111111111"
}
]

from autogen.

from autogen.

I just don't see any future for multiple codebases unless there is first class support. Things are always going to end up missing, or different, maybe even architecturally or conceptually.

from autogen.

Looks like Qdrant has built support for AutoGen. It'd be interesting to test out the integration in .NET.

https://qdrant.tech/documentation/integrations/autogen/

from autogen.

Hi @LittleLittleCloud ! Is this still being worked on? If so, how are you keeping up to date with the broader Python counterpart, including beta features?

from autogen.

from autogen.

I just don't see any future for multiple codebases unless there is first class support. Things are always going to end up missing, or different, maybe even architecturally or conceptually.

Does this mean you're in favor of merging #924 ? My initial thoughts:

• It's difficult for me to imagine it not being disruptive in terms of issues and PRs.
• Every dotnet issue and PR will need to be tagged as such.
• We will likely end up with many additional issues which go unresolved for long periods of time unless the port has parity with the Python module.
• Installing the Python module direct from the repo will pull the dotnet port into the project each time.
• My IDE will index symbols from the port (Maybe this can be handled).
• Is there a nexus between the main Python module and the dotnet port? Do they interop in some way?
  • Note: Currently, if I wanted to made use of something in dotnet, I would probably use pythonnet or similar.
  • Might it be easier for future humans to deal with wrapping the existing module for use in dotnet?
    • IronPython comes to mind, though I have never used it.
    • I think there are other ways to wrap a Python module in dotnet as well. The laziest way would probably be to bundle python.
  • A path to automated transpile would be cool.

from autogen.

• Is there a nexus between the main Python module and the dotnet port? Do they interop in some way?

one of the things we are pondering is about using the work in .NET Interactive as a mean of interoperability.

from autogen.

Great to see someone is working on getting AutoGen in .Net!

I also want to point people to https://github.com/SciSharp/BotSharp
Which is a comparable multi-agent llm framework. Check it out!

from autogen.