.Net: Remote Chat Completion Agent Demo
Motivation and Context
This demo shows how we could implement a RemoteChatCompletionAgent that can be used to interact with a remote Semantic Kernel ChatCompletionAgent.
The new type RemoteChatCompletionAgent implements the ChatHistoryKernelAgent methods using a custom HTTP client to send requests to an API that hosts the ChatCompletionAgent functionality. This allows us to use the same interface as the local ChatCompletionAgent, but with the added benefit of being able to interact with a remote service.
Description
Benefits of having a remote agent
- Polyglot Support: The remote agent can be implemented with different programming languages and frameworks, allowing for better integration and support for different platforms.
- Reusability: The remote agent can be reused across different applications and services, allowing for better code reuse and maintainability.
- Scalability: The remote agent can be hosted on a powerful server, allowing for more complex computations and larger models.
- Resource Management: The remote agent can be managed and monitored more easily, allowing for better resource allocation and usage tracking.
- Security: The remote agent can be secured and monitored more easily, allowing for better protection of sensitive data and computations.
- Cost Efficiency: The remote agent can be hosted on a pay-as-you-go basis, allowing for better cost management and resource allocation.
- Flexibility: The remote agent can be updated and maintained more easily, allowing for better support for new features and improvements.
Details about the sample
I am using an AgentGroupChat to show how to use different remote agents togethere in the same chat. It's a useful use case. Since theRemoteChatCompletionAgent extends the type ChatHistoryKernelAgent, it can be used in the same way as the local agent.
In thie simple Group Chat, we have two agents:
TranslatorAgent: this agent translates the text to English. Program.csSummaryAgent: this agent summarize the text. Program.cs
The Group Chat will call the TranslatorAgent first, and then the SummaryAgent.
I am also using .NET Aspire to have all the different microservices start and run together. I am also leveraging the .NET Service Discovery to have the correct endpoints for each agent.
.NET Aspire is not required. It just make it easier to run the sample and monitoring all the different microservices. You can run the RemoteChatCompletionAgent in any .NET application.
Contribution Checklist
- [x] The code builds clean without any errors or warnings
- [x] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone :smile:
The pipelines will break until #11539 is merged, because I'm using a newer version of the Aspire SDK. #11539 updates other Aspire demo's SDK and should solve the build issues.
I was just having a conversation with a colleague about whether it makes sense to implement a remote Agent based on an API, and now I come across this PR.
Is there any plan to include this in the Framework?
I was just having a conversation with a colleague about whether it makes sense to implement a remote Agent based on an API, and now I come across this PR.
Is there any plan to include this in the Framework?
We are certainly measuring response to this demo as part of considering to promote this pattern to the framework.
any update on this?
@markwallace-microsoft does #12050 makes this PR obsolete?
Considering there are few emerging standard protocol for agent-to-agent communication, it makes sense to close this PR without merging it.