feat: add Kotlin coroutine extension layer (Mono -> suspend, Flux -> Flow)

[shlokmestry]

AgentScope-Java Version

1.0.4-SNAPSHOT

Description

This PR adds a Kotlin coroutine extension layer for AgentScope Java to improve the Kotlin developer experience while keeping Reactor as the core async implementation.

A new optional module agentscope-kotlin is introduced under agentscope-extensions, providing Kotlin-friendly APIs on top of existing Reactor-based methods:

• Mono<Msg> → suspend fun
• Flux<Event> → Flow<Event>
• Mono<Void> → suspend fun returning Unit

All extensions are implemented as Kotlin extension functions, so no existing Java APIs or behaviors are changed.

What’s Included

• New agentscope-kotlin extension module
• Coroutine wrappers for Agent.call(...), Agent.observe(...), and Agent.stream(...)
• Uses kotlinx-coroutines-reactor for non-blocking interoperability
• No changes to core modules or Java implementations

Example Usage

val response = agent.callSuspend(msg)

agent.streamFlow(msg).collect { event ->
    println(event)
}

##How to test:

mvn -pl agentscope-extensions/agentscope-kotlin -am test

[shlokmestry]

The remaining failure appears to be in agentscope-extensions-a2a-client, which is unrelated to this PR.

[AlbumenJ]

Please revert these changes

[AlbumenJ]

Version should be managed in agentscope-dependencies-bom

[AlbumenJ]

Suggested change

	<artifactId>agentscope-kotlin</artifactId>
	<artifactId>agentscope-extensions-kotlin</artifactId>

[codecov]

Codecov Report

❌ Patch coverage is 56.25000% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...e/src/main/java/io/agentscope/core/ReActAgent.java	56.25%	7 Missing ⚠️

📢 Thoughts on this report? Let us know!

[shlokmestry]

All checks are now passing and the license headers have been aligned with the repo standard.
Ready for review/merge. Thanks!

[Akika404]

Hi, thank you for your contributions to the Kotlin community. However, using Kotlin 1.9.24 feels a bit outdated at this point. The mainstream version in the community has already moved to Kotlin 2.x, which provides better support for the K2 Compiler. To avoid potential technical debt in the future, would it make sense to consider migrating directly to Kotlin 2.x?

[shlokmestry]

Hi, that’s a very valid point.
For this PR, I intentionally aligned with the repository’s current Kotlin version to keep the change focused and minimize risk. Since this contribution introduces a new coroutine extension layer without altering existing core behavior, I wanted to avoid coupling it with a major language upgrade in the same PR.
I agree that moving to Kotlin 2.x (and K2) is an important consideration and would likely be beneficial long-term. However, given the scope and potential impact of such a migration, it may be better handled as a separate, dedicated effort so it can be evaluated, tested, and reviewed independently.
I’m happy to help with or contribute to a Kotlin 2.x migration in a follow-up PR if that’s something the maintainers would like to pursue.

[AlbumenJ]

Please fix conficts :)