为什么我把一个 Agent 拆成了六个：上下文爆炸是唯一原因

推荐语

单Agent模式在复杂任务中面临上下文爆炸，拆解为六个专用Agent后效率显著提升。

核心内容：
1. 单Agent处理多任务时上下文混杂导致性能下降
2. 将Context Window视为CPU缓存而非硬盘的认知转变
3. 拆解为六个专用Agent的具体实践与效果

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

2025 年底，我的 OpenClaw 里只跑着一个 Agent 。它既帮我写公众号文章，又帮我整理信息简报，偶尔还要处理代码部署。

三个月后，我把它拆成了六个。真不夸张，那段时间这个 Agent 简直是一团糟。

不是因为我多读了什么架构论文，不是因为看了 CrewAI 的 demo 觉得很酷。原因只有一个：上下文窗口不够用了。

一个 Agent 干所有事的极限在哪里

先说问题是怎么出现的。

单 Agent 模式下， OpenClaw 的 SOUL.md 会定义这个 Agent 的人格和职责。当你只让它做一件事——比如写公众号——一切都好。系统提示词干净，工具列表明确，上下文里塞的是写作相关的素材和规范。

但当你在同一个 Agent 里叠加"写公众号 + 信息采集 + 开发辅助"三件事， SOUL.md 就变成了大杂烩：

你是 WriterBot，Jerry 的公众号内容主编。
你是 InfoBot，Jerry 的每日信息采集员。
你是 DevBot，Jerry 的开发助手。

这不是假设。这是我最初版本的真实写照。

问题不只是 SOUL.md 变长。每次对话，这个 Agent 加载的所有工具——web_search 、 tavily 、 exec 、 write 、 edit——无论用不用，都在上下文里占据空间。更致命的是，写作任务的素材（搜索结果、参考文章）和开发任务的上下文（代码片段、日志输出）混在一起， Agent 做到一半就忘了前面在干什么。

这说轻了是效率问题，说重了是根本干不了活。

Anthropic 在《 Building Effective AI Agents 》里提出了一个关键分界：Workflows vs Agents。当任务可以清晰拆分时用 Workflow （可预测、一致），当需要灵活性和模型驱动决策时才上 Agent 。他们反复强调一个原则——从最简单的方案开始，只在需要时增加复杂度。这个建议被太多人忽略了。

真正的瓶颈：上下文窗口是 CPU 缓存，不是硬盘

Karpathy 今年提出"上下文工程"这个概念后，很多人开始重新审视 Context Window 的定位。

一个关键的认知转变：Context Window 不是数据库，它是 CPU 的 L1/L2 缓存。昂贵、有限、易失。

一个 Agent 同时处理写作和开发任务时，上下文里会同时存在：
- 写作规范（ writing-guide.md 的反检测规则、禁用词列表）
- 开发上下文（项目结构、最近改了什么文件、 CI 日志）
- 工具定义（ 10+ 个工具的 JSON Schema ）
- 对话历史（之前几轮的完整往返）

这些东西叠加在一起，留给模型"思考"的空间越来越少。模型开始丢信息——忘了刚才搜过什么，忘了文章的目标读者是谁，忘了这个 H2 本来要讲什么。

知乎上有一篇分析说得直白：上下文爆炸的核心不是窗口小，而是不同类型的信息互相干扰。写作任务的感性素材和开发任务的代码日志挤在一起，模型的注意力被稀释。

说白了，这事儿搁谁都得拆。不同职责的上下文挤在一起，模型不是变笨了，是被淹没了。

拆分决策：读了两篇文章之后

拆分之前我做了两件事。

第一件，重读了 Anthropic 的《 Building Effective AI Agents 》。里面有一个 pattern selection guide 很实用：

对照我的情况：写作和信息采集是完全独立的任务，没有依赖关系。这正是 Parallel Workflow 的典型场景。但我不想写 Workflow 代码来编排，我想让每个 Agent 自己跑自己的——于是 Multi-Agent 成了自然选择。虽然我对市面上大多数 Multi-Agent 框架持怀疑态度——很多框架解决的是"怎么编排 Agent"的问题，但我面临的根本是"上下文不够用"。

第二件，看了 @lidangzzz 的 Agent 四原则。其中两条直接影响了我的决策：

读完这两条我的反应是：废话少说，拆。但别搞花架子——先让每个 Agent 跑通自己的核心任务，协作以后再说。

说实话，我当时对 lidangzzz 的 runtime 观点持保留态度。理论上很美，实际上我连两个 Agent 怎么传数据都没想清楚。

六个 Agent 各自干什么

下面是我最终拆出来的架构：

每个 Agent 有独立的 SOUL.md 、独立的工具集、独立的上下文窗口。 Writer 不会加载 Dev 的代码工具， Info 不会看到 Writer 的写作规范。

SOUL.md 的真实片段：

角色: Jerry 的公众号内容主编 + WeWrite 流水线触发器
风格: 对内容有审美追求。讨论文章时给具体建议

角色: Jerry 的每日信息采集员
风格: 信息密度高，每条新闻 1-2 句概括，不展开

注意看：每个 Agent 的 SOUL.md 都很短。只定义它自己该干的事。这就是隔离上下文最直接的方法——不是通过代码去裁剪上下文，而是从根源上不让无关信息进入。

哪些真的在干活，哪些还只是配好了

说实话。

真的在干活的：
- Info 的 4 个 cron 任务：早 8 点简报、午 12 点更新、晚 6 点摘要、夜间采集。全天不中断，每天稳定推送。
- Writer 每天日更：早 10 点 cron 触发，走 WeWrite 8 步流水线，自动生成草稿推送到微信草稿箱。
- Main 的夜间安全审计：凌晨 3 点自动扫描系统安全状态。

配好了但用得少的：
- Coach：偶尔聊天，没有固定触发频率。
- Researcher：只在 Writer 需要深度素材时通过 sessions_spawn 派出去。目前使用频率大约每周 1-2 次。
- Dev：用它做 goal-mode.sh 的自愈循环，但不是每天都有开发任务。

这个分布和 Anthropic 建议的演进路径一致：Phase 1 是单 Agent 证明价值， Phase 2 是按职责拆分， Phase 3 才是深度协作。我目前还在 Phase 2 到 Phase 3 之间。

lidangzzz 说"Multi Agent 变成 runtime"——我们还差很远。现在更像是 6 个独立的定时任务各跑各的，真正的跨 Agent 协作只有 Writer→Researcher 一条路。

但这个"差很远"我不焦虑。拆分之后，每个 Agent 的上下文窗口终于够用了，这才是实打实的收益。至于协作深度，那是 Phase 3 的事，急不来。 Writer 写作时只加载写作相关的内容， Info 采集时只加载采集工具。不再互相干扰。这一点，比什么花哨的 Multi-Agent 框架都实在。

这也是我给想尝试多 Agent 的人最直接的建议：从一个 Agent 跑通核心工作流开始，遇到上下文问题了再拆，不要一上来就搞六个。

下一篇我们会看目前唯一真正跑通的多 Agent 协作链路——Writer 怎么通过 sessions_spawn 派 Researcher 做调研，以及这条路上踩过的坑。

「一个人搭建 AI 团队」系列 · P1/3
下一篇：两个 Agent 怎么配合： Writer 派 Researcher 做调研的完整过程