AgentScope 2.0.0 – Share Your Ideas & Feedback

[DavdGao]

We are excited to announce that AgentScope 2.0.0 is currently in the works! 🎉

The AI agent ecosystem is evolving at a rapid pace, and we want AgentScope to stay at the forefront of this exciting landscape. To that end, we are planning a major new release to keep up with the latest advancements and better serve our community.

As we plan and shape the next major release, we'd love to hear from you. Whether you have feature requests, suggestions for improvements, or ideas for new directions — all thoughts are welcome and appreciated. Feel free to share them in this discussion!

📌 Roadmap for AgentScope 2.0.0

• Project Board

We look forward to building the next version of AgentScope together with you. 🚀

[June0623]

When will the human-in-the-loop module be supported? Also, for the 2.0 version scheduled on April 30 — is that the expected release completion date?

[June0623]

After the 2.0 update, will the corresponding runtime deployment project be developed and updated in sync?

[DavdGao]

Thanks for the questions!

• Human-in-the-loop: Yes, this will be supported in 2.0, including user confirmation and external execution. We're currently building this into the new agent class.
• 2.0 release date: April 30 is our target release date.
• Runtime deployment: In 2.0, we plan to migrate the deployment functionality directly into the AgentScope library, so developers can build and deploy their agents within a single library. That said, the standalone runtime project will still be available as an option — both are built around the FastAPI ecosystem, so they can be used interchangeably and share the same interfaces.

[lven010]

许愿能在agentscope框架下做出一个协助制订spec的agent和根据spec配置harness架构的agent,还有把这套harness固化（可复用）、优化的agent

[PangRongHua]

到时候 2.0 的 ts 版本，也会同步上线吗？

[DavdGao]

That's the plan! However, given our limited development bandwidth, we'll be focusing on delivering the Python 2.0 version first.

Building the TypeScript version has given us a wealth of experience and insights, and we expect the Python 2.0 implementation to bring even more well-refined feature designs. We look forward to backporting these improvements to the TypeScript version as well — so stay tuned!

[PangRongHua]

ts 版本会比Python 版本迟很多吗？ts 版本五月初能上吗

[PangRongHua]

目前钉钉群已经满了，找不到交流的入口，能否有新的钉钉群？

[DavdGao]

This one for new dingtalk group:

[monkeycraps]

harness 模式会增强 plan 和 hitl 的融合么 ？之前这两块逻辑都是分开的；

[DavdGao]

harness 模式会增强 plan 和 hitl 的融合么 ？之前这两块逻辑都是分开的；

What does the integration here refer to? Could you please give some examples?

[HHHardi]

在AgentScope之前我很喜欢Agno框架，在目前的了解中似乎未来agentscope-runtime和agentscope贴合更近，更像Agno的AgentOS的设计，这真的很酷！。在我的理解中agentScope 2.0像将整个agentscope-ai现有产品的一次整合。

1. 希望2.0可以增加更好的多用户管理连接ReMe方案（真的希望ReMe可以变为原生的多用户memory方案）
2. 希望2.0可以有更多buildin工具
3. 希望2.0上线时有更多的sample
4. 希望2.0上线时Alias可以同步更新并有更多的template模板

[DavdGao]

@HHHardi Thanks for your interest in AgentScope! You're right that we're working to integrate different components into AgentScope so that developers don't need to worry about managing multiple libraries separately.

1. Regarding ReMe integration, @jinliyl what are your thoughts on this?

2. For built-in tools, we currently plan to provide Bash, Read, Write, Edit, Grep, Glob, along with the meta tools Reset_tools and SkillViewer. Do you have any suggestions for additional tools you'd like to see?

3. We're currently building the foundation of the 2.0 framework. Samples and templates will be added once the core development has stabilized — stay tuned!

4. We'll also make sure Alias is updated with more templates when 2.0 launches.

[HHHardi]

感谢！

关于Bash, Read, Write, Edit这部分包括未来的自定义工具我一直有一个难点。以下均基于我的理解：目前的agentscope 1.0+agentscope+sandbox是一个最小生产环境完整的agent系统。但是面向多用户场景时需要分配每个用户的workspace和sandbox执行环境，当前的内置的Read, Write, Edit工具似乎不能直接连接sandbox，因为agentscope-runtime需要重新定义，因此当前架构下agentscope自带的buildin tools似乎是无法使用的。

agentscope+agentscope-runtime+sandbox server并在runtime侧定义工具进行测试的过程很痛苦（体验上感觉runtime和agentscope agent framework很割裂），希望可以在2.0进行集成的时候整体链路更简单。

总之agentscope做QwenPaw包括Alias的本地个人助理很棒，但是考虑到涉及多用户形式的类Agent computer或者SaaS类web服务时（需要考虑workspace隔离的时候）感觉很confused。

另外，QwenPaw的Read模块似乎做了更多优化（大文件阅读），希望可以同步优化！

[PangRongHua]

这个提议不错，多用户隔离和多用户记忆存储需要做得更好，应用在企业内部，这些都是刚需

[DavdGao]

感谢！

关于Bash, Read, Write, Edit这部分包括未来的自定义工具我一直有一个难点。以下均基于我的理解：目前的agentscope 1.0+agentscope+sandbox是一个最小生产环境完整的agent系统。但是面向多用户场景时需要分配每个用户的workspace和sandbox执行环境，当前的内置的Read, Write, Edit工具似乎不能直接连接sandbox，因为agentscope-runtime需要重新定义，因此当前架构下agentscope自带的buildin tools似乎是无法使用的。

agentscope+agentscope-runtime+sandbox server并在runtime侧定义工具进行测试的过程很痛苦（体验上感觉runtime和agentscope agent framework很割裂），希望可以在2.0进行集成的时候整体链路更简单。

总之agentscope做QwenPaw包括Alias的本地个人助理很棒，但是考虑到涉及多用户形式的类Agent computer或者SaaS类web服务时（需要考虑workspace隔离的时候）感觉很confused。

另外，QwenPaw的Read模块似乎做了更多优化（大文件阅读），希望可以同步优化！

@HHHardi Thanks for your feedback! Regarding sandbox support, here is what we are planning for the upcoming release:

• We will embed an MCP server inside the sandbox, exposing agentscope's built-in tools — such as Bash, Read, Write, Edit, Glob, Grep, etc. — running natively within the sandbox. This will be tunneled outward via an MCP gateway inside the sandbox, making it equivalent to a streamable HTTP MCP server from the outside.
• The sandbox will support dynamically adding and managing STDIO-type MCP servers through its internal MCP gateway, enabling much greater extensibility.
• The sandbox will support to dynamically importing skills and provide a list_skills interface for the agent

With these three integration points, we aim to fully migrate the agent's tool execution environment into the sandbox.

[Baochr]

或许个人使用场景适合cli，但企业数字员工多租户使用场景更适合mcp吧？希望可以更匹配FastMCP v3，比如Skills Provider

[DavdGao]

@Baochr That's a great point. We'll look into FastMCP v3 and explore how features like Skills Provider could be better supported.

[DavdGao]

FYI: Refer to issue #1550 in 2.0 Roadmap

[Baochr]

在图文混排的消息对话场景中，多轮对话中的历史图片是否考虑做自动过滤？让VLM只需要处理最新对话中的图片？

[DavdGao]

在图文混排的消息对话场景中，多轮对话中的历史图片是否考虑做自动过滤？让VLM只需要处理最新对话中的图片？

Yes, this is something we should definitely consider for 2.0.

I think we could expose some configurations to let developers control the maximum number of images kept in the context, though this might break the prompt cache and slow down inference — which is something we need to be careful about.

Also, during memory compression, we'd need to think about how to handle those historical images properly — whether to drop them or keep only the most recent ones. The new offload system in 2.0 might be able to help with this though