[Feature]: Add a tool to wait agent task complete

## Summary

希望增加一个用于等待子 Agent 任务完成的阻塞式内置 Tool。当主 Agent 通过 `submit_to_agent` 提交长时间运行的任务，并已完成自身工作后，可以可靠地等待其他 Agent 返回结果，而不需要反复调用 `check_agent_task` 进行轮询。

Add a blocking built-in tool that allows a primary agent to wait for delegated agent tasks to complete. This would avoid unreliable polling through `check_agent_task`, false assumptions about elapsed time, and accidental termination by the repeated-behavior protection.

## Component(s) Affected

- [x] Core / Backend (app, agents, config, providers, utils, local_models)
- [ ] Console (frontend web UI)
- [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [ ] Skills
- [ ] CLI
- [ ] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

> i don't known which should i choise for "internal tools"

## Problem / Motivation

目前，主 Agent 使用 `submit_to_agent` 提交耗时较长的任务后，只能通过 `check_agent_task` 轮询任务状态。

When a primary agent delegates a long-running task using `submit_to_agent`, it currently has to poll the task status through `check_agent_task`.

`check_agent_task` 会提示：

The response from `check_agent_task` includes this instruction:

> Wait at least 30 seconds before next check.

但 Agent 无法可靠感知真实时间的流逝，因此可能认为两次 Tool 调用之间已经经过了 30 秒，并过早地再次检查。连续获得相同的运行中状态后，Agent还可能错误地怀疑子 Agent 已停止响应或任务已经卡死。
> 当然我本地环境不让它跑shell也有问题🧐，但上次MCP工具异常导致它横向嗅穿了我的环境，已经不信任了

However, an agent cannot reliably perceive real elapsed time between tool calls. It may incorrectly assume that 30 seconds have passed and call `check_agent_task` again too soon. After receiving the same running status several times, it may also begin to suspect that the delegated agent is unresponsive, even though that agent is still working normally.

更严重的是，多次调用 `check_agent_task` 会被系统识别为重复行为，并触发重复行为保护：

More importantly, repeated status checks may trigger the repeated-behavior protection:

> Doom loop: agent stuck after 4 consecutive repetitions

这会导致主 Agent 在子 Agent 仍正常执行时被强制中断。任务越长、并行 Agent 越多，越容易遇到这个问题。
因此，当前机制无法让主 Agent稳定地等待长任务完成，也可能使正常的多 Agent 协作被误判为死循环。

As a result, the primary agent can be interrupted while the delegated agent is still making progress. This makes long-running and parallel multi-agent workflows unreliable.

## Proposed Solution

增加一个阻塞式的内置 Tool，例如：

Add a blocking built-in tool, for example:

```text
wait_for_agent_task
```
该 Tool 在服务端等待指定的 Agent 任务发生状态变化或执行完成，而不是要求主 Agent自行反复轮询。

The tool should wait at the runtime level until one or more delegated tasks change state or finish, instead of requiring the primary agent to repeatedly poll their status.

建议支持以下能力：

Suggested capabilities:

- 接收一个或多个 task_id，允许等待单个或多个 Agent 任务。
Accept one or more task IDs.
- 支持可配置的 timeout。
Support a configurable timeout.
- 在任务完成、失败、取消或超时后返回。
Return when a task completes, fails, is cancelled, or the timeout expires.
- 返回任务的最终状态、结果以及错误信息。
Return the final task status, result, and error details.
- 超时后明确返回 timed_out，但不取消仍在运行的任务。
Report a timeout explicitly without cancelling tasks that are still running.
- 等待过程可被用户消息、任务取消或系统关闭安全中断。
Allow the wait to be interrupted safely by a user message, task cancellation, or system shutdown.
- Tool 内部的等待不计入 Agent 的重复行为检测。
Exclude runtime-managed waiting from repeated-behavior or doom-loop detection.
- 如果受单次 Tool 调用时长限制，可由运行时内部续订等待，而不要求模型重复发起相同调用。
If a single tool invocation cannot remain open for the full duration, renew the wait internally without requiring additional model turns.

示例：

Example input:

```json
{
"task_ids": ["task-123", "task-456"],
"timeout_seconds": 600,
"return_when": "all_completed"
}
```
也可以支持不同的返回策略：

Possible return policies could include:

- `all_completed`：等待所有指定任务结束。
`all_completed`: Return after all specified tasks reach a terminal state.
- `any_completed`：任意任务结束后立即返回。
`any_completed`: Return as soon as any specified task reaches a terminal state.
- `status_changed`：任意任务状态发生变化时返回。
`status_changed`: Return when the status of any specified task changes.

预期工作流：

The intended workflow would be:

1. 主 Agent 使用 submit_to_agent 分配长任务。
The primary agent delegates long-running work with `submit_to_agent`.
3. 主 Agent完成自己能够并行处理的工作。
The primary agent completes any work it can perform in parallel.
4. 主 Agent调用 wait_for_agent_task。
The primary agent calls `wait_for_agent_task`.
5. 运行时负责等待，不再消耗模型轮询回合。
The runtime waits without consuming additional model turns.
6. 子 Agent结束或等待超时后，Tool 将结果返回给主 Agent。
The tool returns when the delegated work finishes or the timeout expires.
7. 主 Agent继续汇总结果或处理异常。
The primary agent resumes and processes or summarizes the results.

这种机制也应与 check_agent_task 共存：后者用于即时查询状态，前者用于明确需要等待的场景。

This tool should coexist with `check_agent_task`: `check_agent_task` remains useful for immediate status inspection, while `wait_for_agent_task` handles cases where the agent explicitly needs to wait.

## Alternatives Considered

### Continue polling with `check_agent_task`

可以调整提示词，要求 Agent减少检查频率。但模型无法准确感知真实时间，仍可能提前轮询，也无法从根本上避免重复行为保护。

The prompt could instruct the agent to poll less frequently, but the model still cannot measure elapsed wall-clock time reliably. This also does not prevent repeated-behavior detection from terminating a valid waiting workflow.

### Increase the repeated-behavior threshold

这只能延后问题发生，并可能降低 Doom loop 检测对真实死循环的保护效果。轮询本身仍会浪费模型回合和上下文。

A higher threshold would only delay the failure and could weaken protection against genuine loops. Polling would still consume model turns and context.

### End the primary agent and resume it through an asynchronous callback

这种方式需要额外的任务恢复与上下文恢复机制，而且主 Agent可能无法在同一执行流程中汇总所有子 Agent结果。

This would require additional task and context restoration mechanisms. It may also make it harder for the primary agent to collect and combine results within the same execution flow.

## Additional Context

一个典型的失败流程如下：

A typical failure flow currently looks like this:

```text
Primary Agent -> submit_to_agent(long-running task)
Primary Agent -> check_agent_task
System -> Task is still running. Wait at least 30 seconds before next check.
Primary Agent -> check_agent_task
System -> Task is still running.
Primary Agent -> check_agent_task
System -> Task is still running.
Primary Agent -> check_agent_task
System -> Doom loop: agent stuck after 4 consecutive repetitions
```

在这个过程中，子 Agent可能始终正常运行，真正被中断的是负责等待和汇总结果的主 Agent。

The delegated agent may remain healthy throughout this sequence. The component that gets interrupted is the primary agent responsible for waiting and collecting the result.

理想流程应为：

The desired flow would be:

```text
Primary Agent -> submit_to_agent(long-running task)
Primary Agent -> wait_for_agent_task(task_id, timeout)
Runtime -> waits without additional model turns
Delegated Agent -> completes
Runtime -> returns the task result
Primary Agent -> continues
```
这个能力尤其适用于代码构建、测试、研究、批量文件处理，以及多个 Agent并行工作后统一汇总结果的场景。

This capability would be especially useful for builds, test suites, research tasks, batch file processing, and workflows where several agents work in parallel before the primary agent combines their results.

## Willing to Contribute

- [ ] I am willing to open a PR for this feature (after discussion).
```