多Agent协同的三层调度架构详解

一、起因：为什么先做一只桌面宠物

2025 年 12 月，我开始做一个桌面 AI 电子宠物，后来给它起名叫 Doly。但宠物只是个载体。我真正想做的，是一个陪伴类的东西，能待在你的桌面上、你的生活里，而不是一个用完就关掉的工具。

为什么强调陪伴？我的想法是：陪伴类的产品也要能解决实际问题，能解决实际问题的 Agent 也不该是冰冷的。这两件事不矛盾，反而是同一件事的两面——一个东西只有先让人愿意天天打开，它的能力才有机会被用到。现成的例子就摆在那：国内使用率最高的 AI 产品是豆包，不是参数最强的那些。当然有网络环境的原因，但我觉得更根本的是，它贴近普通人，普通人用得起来。技术再强，用不起来就是零。

所以 Doly 从一开始就不只是一个对话框。它有身体：一个板端加小车底盘，装了传感器，其中一个是 LD2410B 毫米波人体存在雷达——它能知道你是不是在电脑前，人在不在、动没动。陪伴的前提是感知，连你在不在都不知道，谈什么陪伴。PC 端是它的大脑，负责听、想、说、记。语音这条链路在 2026 年 1 月先打通了，差不多同一时间，OpenClaw（小龙虾）走红，个人 Agent 突然成了热门话题。但我做这个东西的起点比那阵热闹要早，想法也和热闹关系不大：我就是想要一个有感知、能陪着人、又真能干活的东西。

大脑要干的第一件事，是分流。人说一句话，先得判定这是什么：是情感陪伴类的，想聊天、想被回应？是问答类的，查个东西、问个问题？还是操控类的，要动电脑——开文件、调音量、操作浏览器？先分流，再决定用哪套方式处理。这一步看着简单，但它是我后面所有架构的源头：先判定，再分工。

而且分流不只是路由，它连着体验。陪伴的话，你得接住情绪，回应得像个伴儿；操控的话，一句废话都不要有，判定完直接执行，执行完给回执。把这两类混在一个脑子里处理，结果就是陪人聊天时冷冰冰地下指令、让它干活时又絮絮叨叨。分流分的其实是人格和纪律：哪类请求进哪条通道，用哪个模型、带哪套上下文、守哪套规矩，从这一步就定死了。后来的三层也好、人物卡也好，都是这一步的放大版。

操控类里最难啃的是浏览器操作。网页是真实环境，有登录态、有弹窗、会改版，点错了还有真实后果。现在回头看，浏览器操作和命令行 Agent 其实正在合流，新出的工具甚至能直接执行浏览器操作；但在当时，市面上没有现成的成品能拿来用。没有，就自己做。而我当时还不知道，这个被迫自己做的部分，会成为我验证整套架构想法的第一块试验田。

二、经过：三层不是给浏览器发明的

先把顺序说清楚，免得误会：三层架构不是我做浏览器时灵机一动想出来的。恰恰相反，我是先有了三层的想法，才拿浏览器去试它的。

我想解决的问题是上下文爆炸。一个 Agent 要长程地干一件复杂的事，如果把所有信息都堆在一个上下文里，很快就会爆：任务进行到哪一步、试过什么、错在哪，全糊在一起，模型越往后越乱。所以我的设想是把系统拆成三层，用分层本身来管理上下文：

• 第一层只做判定和拆任务。 它站在最上面，只回答“这是什么任务、该拆成哪几个阶段”，不碰任何细节。它是决策层，上下文里只留全局。
• 第二层监督并推进阶段性任务。 第一层拆出的每一个阶段，交给第二层盯着完成：它拿着这一阶段的目标往下推，推不动了就换路或者往上汇报。它只背一个阶段的上下文。
• 第三层是执行器。 只负责把具体动作做掉，把结果回上来。它不判断任务对不对，只管做了没有。

这样一来，最上层永远不用背细节，细节被关在各自的层里，上下文就不会滚雪球。当时这套想法还只是个框架，浏览器自动化是我给它找的试验场。选它是因为它够苛刻：任务够长，一件事要几十步才做完；环境够真，登录态、弹窗、改版一样不少；对错够显形，点错了地方、进错了页面，立刻就能看出来。一个架构要是能在这种地方站住，换到温和点的场景里只会更稳。要是连这种地方都站不住，那它在纸上写得再漂亮也没用。2026 年 3 月到 4 月，我基本就泡在这件事上。下面是试验场里沉淀下来的几件事，每件都对应三层里的一个位置，我点到为止：

接管现成的浏览器，而不是另开一个。 我否决了“复制一份浏览器配置、另开一个干净浏览器”的常见做法。用户的登录态、开着的页面、真实环境都在他正用的浏览器里，另开一个，等于把现场扔了。做法是接管他正在用的 Chrome，而且任务默认新开一个标签页执行，绝不覆盖他原来的页面，接管的是浏览器，不是他的页面。

动手之前，意图先落盘。 执行层每做一个动作之前，先把“基于什么事实、这一步想达成什么、要避开什么”写成结构化的记录，再去动手。想法不落下来，就没法查、没法防重复、没法复盘。这条后来迁移到了我所有的系统里。

执行要防重，动作后要有裁判。 页面状态没变时，模型会反复产出同一个动作，我在执行前加了一道按签名比对的拦截。每个动作执行完，由一个独立的裁判对照事实判断：推进了、停滞了，还是跑偏了——动作发出去了，不等于页面响应了，更不等于目标推进了。阶段做完还有一次正式验收，验收的只看证据，不看执行者怎么说。当时的标准验证任务是去 B 站找到指定创作者的最新视频并播放，验收时要交回作者、标题、链接、播放状态四样证据，交不齐就不算完成。

记事实的，不许下判断。 系统里有个标签页账本，专记页面状态。它一度既记事实又掺判断，链路一长就乱。后来我把它砍成纯粹的事实记录者：只记有什么、变了什么，哪个页面算数由上面两层决定。事实和判断分开，是我后来最看重的一条纪律。

状态全部外置。 任务状态、会话、记忆，全部落盘，不指望上下文“记住”。上下文只当预算来用，按需组装，压缩的时候还要留痕，压掉了什么得记下来。

试验的结果，说好听点是验证，说实话是喜忧参半。大回路——拆阶段、执行、验收、推不动就重规划——在真实网站上确实跑通了，不是一次性的演示。但稳定性没有收口：出现过判定过宽、错误放行的情况，进错了页面没被及时拦住，等等。这些故障我都记在了问题日志里。更大的问题是，4 月中旬之后，我的精力被同一项目的另一条线——小车和音视频链路——吸走了，浏览器这条线再没推进，所有成果留在了开发分支上，从未合回主分支。所以定性只有一句：验证过骨架，没收口的产品。 骨架经受住了真实环境的检验，但它欠的账也是真的。

三、结果与畅想：这副骨架长成了什么，还要长成什么

浏览器那条线停下来之后，骨架没有停。后来我把主要精力转到一个多角色小说创作系统上：每个角色是一个独立的智能体，只知道自己亲历过的事，由主笔按大纲写成正文，审核专门抓视角越界。换到这个系统上时我发现，三层几乎原样能用：最上面有管理层，只判定和分工；中间推进每个场景、每条线；人物在自己的上下文里行动，行动之前先落下判定；出口再设一道监督，只查推断有没有落到行动上。这让我更确信，三层从来就不是浏览器的架构，它是一个通用骨架，浏览器只是它第一次下地干活的地方。

但我真正想往下走的，是另一件事：拼装式。

设想是这样的。往后这套系统不该只有一个“通用智能体”，而应该像发牌一样，有很多张不同的人物卡。卡和卡的区别不是名字，是思维方式：有工程师的卡，专门写代码；有写文档的卡；有审查的卡，专挑毛病；还有产品经理的卡、市场营销的卡。各有各的脑子，各有各的干法。

每张卡还不只是换一套提示词。每张卡下面挂着它自己的工具集和技能集，而且是隔离的：工程师能用命令行、用 PowerShell 去写代码，但他手里没有市场营销的技能，也调不动营销的工具；营销的卡反过来一样。这种隔离不是为了防谁，是为了专业——一个什么工具都能碰、什么技能都装一点的智能体，最后每样都只有半瓶水。工具和技能划进卡里，这个“人”才成立。

那最上面那层干什么？主 Agent 只做一件事：判定。 判定你给的到底是个什么任务、你真正想要的是什么，然后把活分到对的人手里。想做个产品，就先分给产品经理；要写代码，分给工程师；写完要审，分给审查；产品出来了要推向市场，再分给营销。分到手的人自己拆任务、一步步执行，中间那层监督着他把这一段做完。这样的串行链条能把一件任务做得很深：写代码、审核、把产品做完、做市场调研，一环扣一环，而不是一个智能体在一团上下文里从头忙到尾，忙到最后自己都不知道自己在干嘛。

拼装式还顺手解了上下文问题的另一半。三层解决的是纵向的爆炸：别让一个上下文背下整个任务。而人物卡解决的是横向的爆炸：工程师不需要知道营销在想什么，审查的不需要背写代码的全部过程，每张卡只背自己那份专业上下文，接力棒交出去，上一棒的细节就留在上一棒那里。一个大脑全背，是把所有问题堆给记忆；分层加拼装，是把问题分给结构。

这套东西，说白了就是把小说系统里的玩法搬了回来：小说里，世界书按思维类型分区，不同的人物用不同的分析方法，方法给错人，人物就失真。现在我发现这不只是小说的道理——现实里的分工本来就是这样，人是带着自己的专业和工具上岗的。所以拼装式人物卡，是这副骨架在我这里最终想长成的样子：三层管纵向，把上下文和职责切开；人物卡管横向，把专业和工具切开。

四、一点对照

写这篇的时候，我顺手把自己的时间线和几份公开工作对照了一下，放在这里只为印证，不争先后。

2026 年 10 月底，DeepSeek 的 Harness 团队公开了他们叫 Super-agent 的设计：上面一层 Router 只分派不干活，下面一层 Worker 在隔离的会话里执行，外面还挂了一个 Watchdog 盯着每个 Worker 有没有实质进展、偏没偏。分层、隔离、外部监督，和我 3、4 月在浏览器试验田里摸出来的东西大体是收敛的。差不多同期，也有人写过小说流水线的复盘，核心发现是同一个 AI 扮演所有角色必然自己认可自己，必须靠上下文隔离来解决——我小说系统里防视角越界的做法，和它在机制上是同源的。再有 2026 年 6 月的一篇论文，做“视角受限记忆”：角色只能检索自己可见的事实，靠可见性标签划界，和我“角色只知道自己亲历的事、主观记忆分别落盘”几乎是同一道题。

对照下来，真正属于我自己的差异可能只剩一条：现在主流的分层架构里，下面的执行者是无差别的工位，换谁执行都一样；而我想做的拼装式人物卡里，执行者是有差别的——有自己的思维方式，有自己的工具边界。工位解决的是并发和注意力，我想多走的那半步，是专业和人格。

结语

回头看这条线，从一只桌面宠物开始，先长出意图分流，再长出三层，最后指向拼装式人物卡。它真正沉淀下来的不是某个项目——宠物没做完，浏览器没收口——而是一套想问题的方式：先判定，再分工；给模型结构、边界和验收，而不是给它信任；让记事实的只记事实，让做判断的只用事实。

这些想法是不是只有我有？显然不是，这一年我不止一次撞见别人走到了同一个地方。但撞见得越多，我反而越确定它们不是谁的偏好，而是被问题本身逼出来的：只要认真让 AI 在真实环境里长程干活，就会被逼到分层、隔离、落盘、验收这几件事上。

欠的账我也认：骨架验证过了，成品还差着。但我对这副骨架的信心不是来自想象，是来自那几十轮跑通、也跑崩过的真实记录——它被真实环境打过，也站住过。下一篇如果有，应该写拼装式人物卡真正跑起来之后的事——到那时，我希望自己拿得出的是运行结果，不只是想法。