kimi web被设计成子进程模式的考虑？ || Kimi web is designed as a sub-process mode?

What feature would you like to see?

kimi web的是子进程模式的考虑是什么？

我有个想法，直接改sessionProcess和worker为python的包调用 kimi cli 类库直接用，理论上可以100%复现子进程模式，同时也不用担心进程太多的问题。 然后基于这个session和worker的dict进行维护，一段时间不update的idle的可以先回收，反正可以重新get or create。

我想先讨论下官方能否接受这设计？ 如果可以我可以contribute

Additional information

No response

What feature would you like to see?

What are the considerations for kimi web's sub-process mode?

I have an idea to directly change the sessionProcess and worker to Python packages and call the kimi cli class library directly. In theory, the sub-process mode can be reproduced 100%, and at the same time, there is no need to worry about too many processes. Then maintenance is performed based on the dict of this session and worker. The idle ones that have not been updated for a period of time can be recycled first. Anyway, they can be get or create again.

I would like to discuss first whether the authorities can accept this design? If possible I can contribute

Additional information

No response

Start by reading the existing sessionProcess and worker implementation, then inspect how the Kimi CLI is invoked in subprocess mode. Compare that design with the proposed direct Python package and class-library calls, including session and worker dictionaries and idle recycling. Done would require maintainer agreement on the architecture before implementation begins.