一个职场人同时承担工作、家庭、投资、学习多个角色，领域边界清晰，为什么不能交给一个"全能助理"？这一篇讲清楚"按域拆"的分水岭，以及我 5 个月 4 轮架构踩出来的蜂王-工蜂编队思路。

为什么一个"全能助理"不够用：从单 Agent 到蜂王-工蜂编队

上一篇序言回答了"为什么职场人需要一套自己的 Agent 助理团队"。这一篇回答搭建过程中的第一个关键决策：为什么我最后没有用一个"全能助理"，而是拆成了一支编队？

行业里有句话说得很扎心：多 Agent 不是默认更强，难点不在分工，而在交接。 我踩了 4 轮架构才明白这句话——让"蜂王"只管路由、"工蜂"各管一摊、交接走持久记忆而不是临时上下文，这条路线才跑得通。这一篇讲清楚为什么。

一、问题的起点：一个职场人为什么要拆助理

先从一个最朴素的事实说起：一个职场人在社会生活中，同时承担着多个角色，而这些角色的需求边界其实非常清晰。

你是公司里的风控从业者，也是家庭里的家长，还是投资者、阅读者、学习者……工作、生活、家庭、学习，这几个领域你平时是分开过的——上班开的是工作的上下文，回家聊的是家庭的事，复盘的是投资的账。领域之间边界清晰，这是人脑处理复杂性的天然方式。

但当你把这些需求全部交给一个"全能助理"时，边界就被抹掉了。你上午让它分析一只股票的财报，下午让它规划周末陪孩子的安排，它没有一个"现在是工作模式还是家庭模式"的开关——所有信息都堆在同一个上下文窗口里互相渗透。

而"全能助理"真正擅长的，恰恰不是跨领域，而是同一领域内的不同角色切换——比如一份行业周报里的"研究员"视角和"汇报者"视角，需要的是共享上下文、共享记忆、连续承接。这两种场景，对助理的架构要求是相反的：

我一开始没分清这两件事，才让一个 Agent 去管所有领域，结果就是——每个领域都做不深，还互相污染。

二、隔离 vs 共享：架构的分水岭

上一节的对比表，其实是整篇的分水岭，值得单独拎出来讲透。

关键要认清一点："共享"不等于"什么都共享"，"隔离"也不等于"各过各的"。 分界线只有一条——信息需不需要互通。

• 跨领域：工作、投资、家庭、学习，彼此信息不互通、各有隐私，甚至互相干扰（投资情绪影响家庭判断）。这种场景要的是隔离——每个领域一个独立上下文、独立记忆，互不渗透。
• 同领域内多角色：比如"写一份行业周报"，要从"研究员"视角收集资料，再切到"汇报者"视角成文。两个角色边界模糊、必须共享同一份背景、连续推进，中间不能断档。这种场景要的是共享——放在同一个 Agent 的同一会话里，上下文与记忆天然接得上。

所以架构的选择不是"多 Agent 还是单 Agent"的二选一，而是先判断信息要不要互通，再决定隔离还是共享：

跨领域 → 拆成多个 Agent（隔离） 同领域多角色 → 留在同一个 Agent（共享）

我之前最大的失误，是把这两种场景混在一个 Agent 里：既想要跨领域的专注，又想要同领域的连续。结果两头不讨好——跨领域的被污染了，同领域的也没法真正共享。想通这一点之后，"按域拆"这个决策就不再是直觉，而是从这条分界线上推导出来的必然结果。

三、"上下文污染"到底是什么

这是本篇的核心概念，值得单独拆开讲。

LLM 的所有"聪明"都来自它当前上下文窗口里的内容。你把 A 领域的信息塞进去，它就带着 A 的视角去做 B 的事——这是它的工作原理，不是 bug。

但当你让一个 Agent 同时管四条线（工作/投资/家庭/效率），就出现了行业里公认的两个痛点：

1. 单 context 装不下：四条线的背景、偏好、进行中任务，全堆在一个上下文窗口里，信息互相干扰，越堆越乱
2. 既当裁判又当球员：它自己负责"该做什么"，又负责"做这件事"，还负责"检查做得对不对"——三重角色压在同一个脑子上，没有制衡

更隐蔽的是记忆污染：它会把"上周聊过的家庭事"当成"分析股票时的有效背景"一起检索出来。单 Agent 模式下，这种污染你根本意识不到，只觉得"它最近怎么有点奇怪"。

三、我不是第一个这么想的人，但大多数人没坚持下来

先说清楚：我这套"蜂王-工蜂"的思路，不是我发明的。

行业里已经有明确的共识（微软的编排模式文档、多篇多智能体研究都在说）：

• 模块化与域隔离：主 Agent 把请求委托给不同的子 Agent，就像"IT 客服调销售客服查报价"——各管一摊，互不越界
• orchestrator-worker 是标准编排模式：一个编排者负责调度与验收，多个工人负责执行

但共识归共识，大多数人搭到一半就放弃了。我调研时反复看到同一个失败案例：有人用编码工具的 sub-agent 机制搭了一支"agent 团队"，一开始挺顺，跑了几次任务后开始频繁失败——编排者调度子 agent 时和别的工具调用冲突，孵化失败，最后它自己说"调用失败了，整个流程我接着来吧"，然后独自硬扛到底，系统退化回了单 Agent。

这个案例对我特别有警示性，因为它精确命中了我后来自己踩的同一个坑。

四、我的 1+5 编队：按"域"拆，不按"任务类型"拆

想清楚"为什么要拆"之后，怎么拆是个更实际的问题。

我试过的错法：按任务类型拆——"写文档的 agent""做 PPT 的 agent""查资料的 agent"。很快发现不行，因为同一个任务（比如"写一份行业周报"）会同时触发写文档、查资料、做图表，三个 agent 互相依赖、谁也等不起谁，最后还是乱成一锅粥。

我现在的拆法：按"域"拆——一个领域一个专家 agent：

再往上叠一个蜂王（协调中枢）：它不干具体的活，只做四件事——理解意图、路由任务、把关质量、统一交付。

这里有一个设计决策，是整篇我想强调的重点，也是我认为多数失败案例没做对的地方：

4.1 蜂王不抢活（编排者不下场）

行业里总结"多 Agent 正确用法"时，有一条反复被提到：编排者只负责调度和验收，不要既当裁判又下场干活。

我的第一版就违反了这条——让蜂王"任务分派不过来时也可以自己上手"。结果就是上下文双重污染：它本该只处理"路由"，却开始掺进各域的专业判断，越派越乱。

后来我在 SOUL.md 里写死了边界："不直接执行子 Agent 的专属任务，不抢活。" 它只准分派、只准验收、只准整合。这一条落地之后，整个编队的稳定性上了一个台阶。

4.2 交接走持久记忆，不走临时上下文

回到第三节那个失败案例，它的根因是"子 agent 用完即弃，上下文靠临时传递，传着传着就丢了"。

我的做法相反：每只工蜂有独立的工作空间、独立的长期记忆、独立的人格文件（SOUL/USER/MEMORY 三件套）。任务交接时，靠的是"工蜂自己记得住这个域的历史"，而不是靠编排者把上下文一段段递过去。这是下一篇（02）要展开的核心——隔离边界怎么设计，交接才不会丢东西。

五、踩坑实录：5 个月，4 轮架构

不美化地列一下我的演进轨迹，每一轮都交了学费：

• 第 1 轮（5 月初）：单 Agent 全能版 → 撞上上下文污染，拆成 1+4
• 第 2 轮（6 月）：4 只工蜂 → 发现没有"主动推送"，都是人查 agent，加 cron 触发器
• 第 3 轮（8 月）：定时任务开始批量失败，没人管 → 加第 5 只蜂"运维"（专管巡检自愈）
• 第 4 轮（9 月）：最痛的一次——记忆系统静默停写 40 小时，表面完全正常、零报错，最后靠配置备份对比才定位（这篇先埋个钩子，06 篇详细写）

4 轮改下来，我最大的体会是：编队不是设计出来的，是踩坑踩出来的。 一开始就想清楚"拆几个 agent、怎么交接"几乎不可能，因为你不踩，你不知道自己到底缺什么。

六、结论：什么时候该拆，什么时候别拆

顺着前文，给一个判断（也呼应 04 篇要展开的"最小可复刻版"）：

该拆（多 Agent）当且仅当：

1. 你的任务信息量，单个 agent 的上下文已经装不下
2. 你不想让一个 agent"既当裁判又当球员"（专业域需要独立制衡）
3. 有多个彼此独立、可以并行的领域

别急着拆：

• 只有一两条线 → 单 Agent 足够，先用到极致
• 拆不出边界清晰的域 → 硬拆只会制造同步成本
• 没解决"交接"问题就堆数量 → 一定退化回单 Agent 硬扛

我自己起步时就守住了"先单 Agent 跑到真的不够用，再拆"这条线，没有一上来就堆 6 个 agent——这也是序言里"最小可复刻版"清单为什么只给 2 个 agent 的原因。

下一篇预告：《02｜多 Agent 编队架构设计：隔离边界与分派逻辑》——workspace 怎么隔离、蜂王的意图分类表怎么设计、跨域信息流怎么默认隐私、以及"不抢活"这条边界怎么在 SOUL.md 里写死。

互动：你搭 Agent 助理时，卡在"上下文污染"还是"agent 交接丢东西"？评论区聊聊。