feat: add multi-worker scheduling and control-message priority for Feishu/IM scenarios

[huangrichao2020]

Scenario

This is a real pitfall ordinary developers will hit.

After GenericAgent is connected to Feishu/WeChat, it is common for a user to send another message while a long task is still running. The second message may be something simple like “stop”, “what is the current progress?”, “switch directory”, or “add this constraint”; it may also be a completely independent small task.

If there is only one worker, the second message can only be blindly queued. From the user’s point of view, the agent looks frozen. This is especially obvious in mobile IM scenarios.

Current Pain Points

• Once a long task occupies the only worker, new messages cannot be handled in time.
• Control messages such as /status, /stop, and extra constraints also get queued, and by the time they are processed it may be too late.
• Tasks from different chats/users block each other.
• It is not possible to run a long task and a lightweight status query at the same time.
• The queue lacks priority, session isolation, and concurrency limits.

Suggested Direction

Consider upgrading the current “single queue + single worker” model into a lightweight dispatcher:

• Prioritize control messages: /status, /stop, /tasks, and /resume should not enter the normal task queue.
• Isolate normal task queues by chat_id/session_id.
• Add a global concurrency limit for the worker pool, for example 1-2 by default, to avoid overwhelming the local machine.
• For the same session, support configurable behavior: queue, interrupt the current task, or inject the new message as steer/context into the current task.
• Long tasks should return a task_id so the frontend can keep querying progress.

At minimum, task execution should be decoupled from the message entry point. The message entry point should create tasks, query status, and relay progress instead of blocking inside the LLM loop.

Acceptance Criteria

• While a long task is running, a second /status message returns immediately.
• While a long task is running, /stop <task_id> can interrupt it promptly.
• Messages from different chats do not block each other indefinitely.
• Worker count is configurable and clear backpressure messages are shown when capacity is full.