时间消耗型任务，不该让整条对话干等

初衷文说的是关系：通讯录里的专职 Agent，跨界再组队。

组队一旦真跑起来，下一刀切在时间上。

查文献、估交互、跑构建、盯一段长日志，这些都是时间消耗型。若主会话必须同步等完，用户体感就是：助理说「我去办」，然后整条对话假死。

最近 coding agent 里很扎眼的一个模式，就是把这类活异步化：先返回句柄，主会话继续聊；做完再回注。AgentUp 这轮，是把这个模式落到「专家 subagent」上，并准备把普通长任务也收进同一套管法。

同步等结果，只适合短活

最早的委托很朴素：指定专家，写有界 brief，默认同步等回来。

一两分钟能结束的活，这样最干净，结果直接进本轮 tool result。

一拉长就不行。你要同时查结构、估交互、扫风险，串行同步等于把等待时间加总。主助理也不能边等边回你别的问题。

所以工具改成可扇出：tasks=[{agent_id, brief}, ...]。多项默认异步，立刻返回各 task_id；这轮就必须汇总，再显式 wait=true。

边界写死：

• 一次最多扇出 8 个专家子任务
• 同用户并发闸门 4，超出排队
• check_delegation 可按多个 task_id 汇合

异步不是「扔出去不管」。是把阻塞从主 turn 上拿掉，换成可查询的任务。

业界也在把 subagent 往后台推

这不是我一个人的偏好。开源 agent 框架和主流 coding agent 文档里，越来越常见同一套分工：

• 同步 subagent：主会话阻塞到子任务结束。适合短、确定、下一步立刻依赖结果的活。
• 异步 / background subagent：立刻返回 task id；可检查、可改指令、可取消；完成后用通知或新一轮回注，而不是卡死当前 tool 调用。

有的实现还强调：结果要等主会话空闲再注入，避免插在 tool result 和 assistant 消息中间，把角色交替和缓存搅乱。AgentUp 的异步委托也走「完成后空闲唤醒」，同一类顾虑。

一句话：时间消耗型工作，默认不该绑架主对话的时钟。

专家异步了，普通长任务也要

耗时的不只是「问另一个 Agent」。

长命令、本地构建、盯日志、跑测试，往往根本不需要招募专家，但一样能把对话拖死。常见做法是开异步任务：跑起来拿编号，可查进度，不行就停。

我想要的形状是：

今天落地的是左边：专家委托异步、扇出、取消、Fleet。右边在架构里写明了：自研对齐后台作业契约，Desktop Fleet 扩展成「委托 ∪ 后台作业」统一条。第三方包和当前运行时版本对不上，不能直接装，所以不硬接。

目标一致：凡是会烧时间的，都先变成可监视的后台项，主会话先往下走。

异步之后，人要看得见、停得掉

派出去减等待，只对了一半。看不见、停不掉，用户还是不敢放开用。

子过程不塞进父消息 parts，免得主对话被过程日志淹没。顶栏加 Fleet：轮询进行中的异步项，显示头像、短 brief、数量；点开看过程；列表可展开。

取消是任务级的：cancel_delegation、HTTP cancel、Fleet / 过程弹窗上的「停止」。任务 AbortController 和父 turn signal 并联；终态 cancelled 再回注。这跟「停止当前回复」不是一层：后者打断眼前这一轮，前者打断已经在后台转的活。

审批仍要过人。委托范围可记到 session 或 agent。异步放大了并行，也放大了误派成本；许可和中止得一起给。

消息侧的 Artifacts 则补另一面：异步跑完常会改文件，列表里能看见新增 / 修改 / 删除，不只读一段总结。

我在优化的等待，到底是什么

不是让模型「算得更快」。是让用户少坐在假死的输入框前面。

短活：同步等，结果马上用。
长活、可并行活：异步派，主会话继续聊，Fleet 盯着，跑偏就停。
专家和非专家：两条入口，一套可见与取消。

扇出 8、并发 4 只是本机默认刹车。后台作业统一进 Fleet，还在后面。数字和 UI 都会再调；模式先钉住。

想试用：https://agentup.me。