[Feature]: 希望可以添加 notice_after_complete （完成后通知）工具。让agent在等待 命令行或子agent任务时，可以回复用户其他问题

## Summary

希望为 Agent 增加 `notice_after_complete` 工具/机制，使得 Agent 在发起一个长时间运行的任务（如执行命令行、调用子 Agent 或等待外部 API 响应）后，能够先回复用户“任务已启动，完成后通知您”，并继续处理用户在同一会话中提出的其他问题，待后台任务完成时再主动推送完成通知。

我推想的方案。
agent 使用 shell 启动了进程，放在后台，并获得任务号。
agent 调用 notice_after_complete(任务号) ，注册一个完成通知。
agent 说 我已注册通知。
用户 说 我们闲聊吧。
agent 说 闲聊内容。
任务完成了，自动用户侧推送一条信息，前缀是 [后台任务「任务号」完成通知] ，发送给agent。 （看起来和用户消息很像，只不过是框架发送的消息）
agent 说 收到了通知，继续调用其他的工具，继续干活。

## 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

## Problem / Motivation

当前 Agent 在执行某些阻塞型操作（例如运行耗时较长的 shell 命令、调用子 Agent 进行多轮推理、等待外部工具返回结果）时，会一直等待任务结束才回复用户。这导致：
- 用户体验差：用户必须等待任务完全结束才能收到任何回复，期间界面无响应或长时间“思考中”。
- 无法并行处理：在等待期间，Agent 无法处理用户穿插提出的其他简单问题（例如“当前进度如何？”或“帮我查另一个东西”），即使这些问题与后台任务无关。
- 资源浪费：对于长时间任务，用户往往希望先得到“已接收”的确认，而不是沉默等待。

此功能尤其适用于需要数分钟甚至更久的后台任务场景，如代码编译、大规模数据检索、复杂推理链等。

## Proposed Solution

增加一个名为 `notice_after_complete` 的工具（或内置能力），其工作流程如下：

1. Agent 检测到即将执行一个可能耗时的操作（如 `run_command`、`call_sub_agent`、`http_request` 等）。
2. Agent 调用 `notice_after_complete(task_id, description, callback_context)`，将该任务注册到后台执行队列。
3. 工具立即返回一个占位符（如 `task_id`），Agent 随即向用户回复一条确认消息，例如：“正在执行 [任务描述]，完成后我会主动通知您。您可以继续提问其他问题。”
4. Agent 进入“多任务模式”，可以继续响应当前会话中的其他用户消息，而该后台任务在独立协程/线程中继续运行。
5. 任务完成后，后台机制通过 `task_id` 触发回调，Agent 通过原有通道（如聊天界面）主动向用户推送一条完成通知，包含任务结果或摘要。
6. 如果任务失败，同样推送错误通知。

实现建议：
- 在 Core 层引入任务管理器（TaskManager），维护 `task_id` -> `future` / `callback` 映射。
- 为现有的执行函数（如 `run_command`）提供异步包装，支持 `detach=True` 参数。
- 会话上下文需支持“挂起任务”状态，确保通知能正确投递到对应会话。
- 通知格式可复用现有的消息发送接口（如 `send_message`）。

## Alternatives Considered

- **使用已有的 `send_message` 手动模拟**：用户可以通过在 prompt 中要求 Agent “先回复再执行”，但这不是通用机制，且 Agent 无法在等待后自动推送完成通知，仍需用户主动询问。
- **引入 `background` 修饰器**：让开发者标记函数为后台运行，但缺乏统一的任务 ID 和通知回调管理，不易与对话流集成。
- **依赖外部消息队列**：过于重量级，对于本项目而言增加复杂度和部署成本。

## Additional Context

- 类似设计在 Slack、Discord 的机器人框架中常见（如 `ephemeral` 回复 + `follow-up` 消息）。
- OpenAI 的 Assistants API 支持 `submit_tool_outputs` 的异步模式，但需轮询；我们更希望主动推送。
- 典型使用场景：
- 用户：“帮我在代码库里搜索所有包含 TODO 的文件，并统计数量。”
- Agent：调用 `notice_after_complete`，回复“搜索已开始，预计需要 2 分钟，完成后通知您。”
- 用户：“好的，那顺便问一下，今天天气怎么样？”
- Agent：调用天气工具，立即回复天气信息。
- 2 分钟后，Agent 主动推送：“搜索完成，共找到 127 个文件包含 TODO。”

## Willing to Contribute

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