[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).

No files or tests are named. Start by tracing the Core / Backend entry points for run_command, call_sub_agent, http_request, and send_message, then inspect how app, agents, config, providers, utils, and local_models handle session state. The scope is complete only when the project agrees on task ownership, concurrent conversation handling, success or failure notifications, and delivery through the existing channel.

Scritto dal modello di indicizzazione a partire dal testo della issue.