8.1 为什么需要多Agent
想象一下这个场景：
你让 AI 帮你写一篇产品文案。
它写到一半，突然开始引用三天前你让它修过的代码 bug。
你说“不对，是写文案”，它停顿了一下，继续写——但上下文已经乱了。
你叹了口气，删掉重来。
这不是你的配置有问题，而是单 Agent 的瓶颈到了。
第七章你学会了渠道接入——让 AI 在飞书、钉钉、QQ 里待命。但当你用一个 Agent 扛所有工作时，问题就来了。这一节，我们用10分钟，理解为什么需要多Agent，以及什么时候该“招小弟”。
单Agent的局限性
一个 Agent 就像一名全能员工，什么都能干，但精力有限。
记忆污染
你昨天让它记了一堆代码规范，今天写文案时它可能还会引用那些规范。不同的工作混在一起，上下文互相干扰。
就像一个员工同时负责销售、技术、运营——说着说着就串台了。
上下文溢出
每次对话都有 token 上限。当记忆文件涨到 30KB、50KB，真正能用于干活的空间就不多了。
你：帮我写个周报 AI：（加载 50KB 记忆文件...） AI：（上下文快满了...） AI：好的，周报内容如下...（输出被截断）
无法并行
一个 Agent 同一时间只能处理一个对话。如果你需要同时做研究、写文案、审代码，只能排队等。
成本浪费
每次对话都要加载完整的记忆文件，哪怕这次任务只需要其中一小部分。用 Claude Opus 写简单回复，就像开法拉利去买菜。
多Agent的优势
把一个大 Agent 拆成多个专业 Agent，每个只负责一件事。
| 维度 | 单Agent | 多Agent |
|---|---|---|
| 记忆管理 | 臃肿混乱 | 各自独立，互不干扰 |
| 上下文 | 容易溢出 | 精简专注 |
| 并行处理 | 无法并行 | 多个Agent同时工作 |
| 成本 | 高（加载冗余信息） | 低（只加载相关记忆） |
| 专业化 | 一人多岗 | 专人专岗 |
真实案例
Datawhale 分享过一个 6 人 AI 团队配置：
| 角色 | 职责 |
|---|---|
| Monica（首席协调官） | 统筹任务分配 |
| Dwight（研究员） | 每天扫描 AI 趋势 |
| Kelly（Twitter运营） | 写推文 |
| Rachel（LinkedIn运营） | 写深度内容 |
| Ross（工程师） | 代码审查 |
| Pam（邮件专员） | 写邮件通讯 |
6 个 Agent 各司其职，每天早上自动产出 6 项工作成果，月成本不到 400 美元，每天节省 4-5 小时。
什么时候该拆？
三个信号告诉你该考虑多 Agent 了：
信号一：上下文溢出
MEMORY.md 超过 30KB，每次对话加载大量无关信息。
信号二：职责交叉干扰
写文章写到一半被别的任务打断，Agent 开始“神经错乱”。
信号三：并行处理需求
必须同时干多件独立的事，比如一边研究一边写文案。
试一试：评估你的现状
看看你的 Workspace：
ls -lh ~/.openclaw/workspace/*.md如果 MEMORY.md 超过 30KB，或者 AGENTS.md 超过 200 行，就该考虑拆分了。
真实场景举例
场景一：内容创作者
| Agent | 职责 |
|---|---|
| 主Agent | 日常对话、任务分配 |
| 研究Agent | 收集资料、整理情报 |
| 写作Agent | 专注写稿，不受其他干扰 |
| 运营Agent | 负责多平台分发 |
场景二：跨境电商
| Agent | 职责 |
|---|---|
| 大总管 | 接收指令、任务分发 |
| VOC分析师 | 抓取竞品评价 |
| 内容优化师 | 写产品描述 |
| Reddit专家 | 社区运营 |
| TikTok编导 | 短视频制作 |
场景三：开发团队
| Agent | 职责 |
|---|---|
| 项目经理 | 需求拆解、进度跟踪 |
| 产品经理 | 写PRD、画流程图 |
| 开发工程师 | 写代码 |
| 测试工程师 | 写测试用例 |
多Agent不是万能药
拆 Agent 也有代价：
| 代价 | 说明 |
|---|---|
| 多套 workspace | 每套都要维护 |
| 信息同步 | Agent 之间要配置通信 |
| 踩坑成本 | 通信配置容易出错 |
如果 MEMORY.md 只有 3KB，Cron 任务跑在独立会话里，分发是串行的不需要并行——那暂时不用拆。
一人多岗也能扛：靠 Cron + Skill + Workspace 文件体系，等记忆涨到 30KB 以上再考虑招“小弟”。
故障排查
怎么判断要不要拆？
| 检查项 | 判断标准 |
|---|---|
| MEMORY.md 大小 | 超过 30KB → 考虑拆 |
| AGENTS.md 行数 | 超过 200 行 → 考虑拆 |
| 任务干扰频率 | 经常串台 → 该拆了 |
| 并行需求 | 需要同时做多件事 → 该拆了 |
这一节，你做了什么
| 学了什么 | 核心理解 |
|---|---|
| 单Agent局限 | 记忆污染、上下文溢出、无法并行 |
| 多Agent优势 | 物理隔离、专人专岗、可并行 |
| 拆分信号 | 上下文溢出、职责干扰、并行需求 |
| 决策原则 | 有需要再拆，不要过度设计 |
下一节
了解了为什么需要多 Agent，接下来我们看看多 Agent 的物理隔离是怎么实现的。