Open WebUI 的 sub-agents 架构：把长任务拆给后台子代理，主对话为何不再卡顿

子代理不是多线程聊天，而是一等公民的工具

很多人第一次看到 Open WebUI 的 sub-agents，直觉是『这不就是再开一个聊天窗口让我自己切换吗』。如果只停留在界面层，这个理解只对了一半。Open WebUI 把 sub-agent 当成模型可以调用的一种工具（tool），而不是给人用的第二个标签页。管理员在设置里打开 ENABLE_SUBAGENTS 之后，主对话里的模型在接到一个复杂请求时，可以自己决定：这件事要不要派一个后台 helper 去跑。

关键在于，helper 不是『复制一份当前对话』那么简单。它拿到的是任务描述、可调用的工具集、以及由并发（concurrency）和迭代（iteration）上限约束的运行预算。也就是说，子代理是一个有边界、可计量、可失败的独立执行体，而不是主线程的克隆。这一点决定了它和『多开窗口』在工程上的根本差异：主对话在派活之后可以立刻继续接收用户输入，helper 在后台跑它的工具循环，跑完才把一段结构化结果贴回主对话。

触发与边界：谁来决定拆、拆到哪一层

子代理的触发权在模型手里，但边界在管理员手里。Open WebUI 用三个旋钮把『模型能野到什么程度』钉死：ENABLE_SUBAGENTS 是总开关；concurrency 控制同时能跑几个 helper；iteration 控制单个 helper 最多能转几轮工具调用。这构成了一种分层的执行预算——主模型是调度者，子代理是被调度者，预算耗尽就停。

为什么需要这种边界？因为一旦允许模型无限派活，你面对的就不是『一个 Agent』，而是『一个会自我复制的 Agent 集群』，每一层都吃 token、都占上下文、都可能卡在某个工具调用上。Open WebUI 的解法是把『递归深度』和『并行宽度』都变成可配置的资源配额，而不是交给模型自由发挥。这和操作系统给进程设 CPU 配额是同一类思路：把失控的可能性提前关进配额里。

与 OpenAI Swarm、Anthropic 子代理的对照

OpenAI 的 Swarm（以及后来的 Agent SDK）走的是『编排器 + 手写 handoff』路线：你显式定义 agent 之间怎么交接上下文，控制权在开发者写的代码里。Anthropic 的子代理（sub-agent）更多出现在研究类 Agent 场景，强调把一个大问题拆给多个并行 worker、各自检索后汇总，重心在『检索与综合』。

Open WebUI 的版本则更『平民』：它不要求你写编排代码，而是把子代理能力直接焊进一个面向终端用户的聊天界面，靠系统提示词（system prompt）和设置项来约束。代价是灵活性不如手写编排器——你很难精确控制 handoff 时传递哪一段记忆、在哪一层做收敛。但收益是普通用户零代码就能用上『派活』能力，这也是它和前两者最本质的分野：Swarm 是给工程师的乐高，Open WebUI 是给自托管用户的开关。

代价：上下文割裂、计费翻倍与排障盲区

子代理不是免费午餐。第一个代价是上下文割裂：helper 在自己的上下文里跑，主对话看不到它的中间思考，除非它把结果贴回来。这意味着如果 helper 跑偏了，主模型往往只能看到『最终结果不对』，却看不到『它中间哪一步错了』，调试体验比单线程差。

第二个代价是计费与延迟：每一次子代理调用都是一次独立的模型对话，token 消耗大致是『主对话 + N 个 helper』的叠加，长任务下账单可能翻倍甚至更多。第三个代价是排障盲区——当多个 helper 并发运行时，到底哪一段输出来自哪个 helper、哪一步超时，对用户是黑盒。Open WebUI 目前靠把结果回填主对话来缓解，但并未提供像分布式追踪那样的调用链视图。

权限继承：helper 拿到的是谁的钥匙

一个容易踩坑的细节是子代理的工具权限从哪来。Open WebUI 里，helper 默认沿用主模型可用的工具集与权限范围，也就是说你在主对话里给模型开的『文件读写、代码执行、网页搜索』，子代理一样能调用。这带来便利，也带来风险：你本意是让 helper 去『查一下资料』，但它理论上同样能『删一个文件』。

更隐蔽的是 human-in-the-loop 审批在子代理场景下的行为——主对话里你可以逐条 Allow/Deny 工具调用，但 helper 在后台跑时，如果没有人在主对话盯着，审批弹窗可能落到无人响应的状态。这也是为什么 Open WebUI 明确把自动化任务、定时任务排除在 HITL 阻塞之外：否则一个无人值守的子代理会卡死在等审批上。理解这一点，才能正确配置『哪些工具允许子代理碰、哪些必须回到主线程人工确认』，否则『派活』就会变成『放权』。

责任归属：排障为何变成考古

更进一步的代价是『责任归属』。当主模型派了三个 helper，其中一个把错误数据写进了知识库，事后很难说清是主模型的调度失误，还是某个 helper 的执行偏差。在缺乏调用链追踪（trace）的情况下，排障从『看日志』退化成『考古』——你只能拿到最终回填主对话的那段结果，中间的推理与工具轨迹散落在各自独立的上下文里。这也是为什么子代理适合『任务边界清晰、失败可观察』的场景，而不适合『一步错步步错、且中间过程必须可审计』的关键流程。

作者判断：长任务该不该离开主线程

我的判断是：凡是『主对话需要保持响应、但手头任务很重』的场景，子代理都是正确的默认形态。聊天界面最怕的不是慢，是『卡住』——用户发一句新消息，模型却卡在某个 5 分钟的工具循环里不理人。子代理把重活挪到后台，主线程腾出来继续交互，体验上是从『死机感』变成『后台忙』。

但要清醒：子代理解决的是『交互不卡顿』，不是『任务更聪明』。它不会自动让模型拆题拆得更准，只是让拆完之后的执行不阻塞你。把它当成『异步执行单元』而非『更强的智能』，就不会误用。对自托管用户来说，Open WebUI 这步的意义在于：把原本只在研究 Demo 里出现的子代理能力，变成了一个勾选框就能开的日常功能——这比任何新模型都更贴近『Agent 真正可用』的那一刻。