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

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 、 ta vily 、 exec 、 write 、 edit——无论用不用，都在上下文里占据空间。更致命的是，写作任务的素材（搜索结果、参考文章）和开发任务的上下文（代码片段、日志输出）混在一起， Agent 做到一半就忘了前面在干什么。

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

Anthropic 在《 Building Effective AI Agents 》里提出了一个关键分界：

。当任务可以清晰拆分时用 Workflow （可预测、一致），当需要灵活性和模型驱动决策时才上 Agent 。他们反复强调一个原则——。这个建议被太多人忽略了。

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

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

一个关键的认知转变：

。昂贵、有限、易失。

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

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

知乎上有一篇分析说得直白：

。写作任务的感性素材和开发任务的代码日志挤在一起，模型的注意力被稀释。

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

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

拆分之前我做了两件事。

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

场景	推荐架构
单一职责、流程明确	Single Agent
多步骤、有先后依赖	Sequential Workflow
独立分析、需要速度	Parallel Workflow
复杂问题、需要多视角	Multi-Agent

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

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

• 原则 2 ：不要把管理学方法乱套在 LLM Agent 上
  。别搞 KPI 、别搞层级汇报。 Agent 不需要"管理"，需要的是清晰的边界和独立的上下文。

• 原则 3 ： Multi Agent 会变成产品本身的 runtime
  。这个观点更激进——Agent 不是工具，是运行时。产品面向用户消费的，不只是 UI 界面，还有背后的 Agent 协作模式。

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

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

六个 Agent 各自干什么

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

Agent	职责	SOUL.md 核心定义	真实使用频率
Main (Jarvis)	总调度、 cron 管理	主 Agent ，协调其他 Agent	每日
Writer	公众号文章写作	WriterBot ，内容主编	每日（ cron 10:00 ）
Info	信息采集与简报	InfoBot ，每日信息采集员	每日（ cron 8:00/12:00/18:00 ）
Dev	开发辅助	DevBot ，开发助手	按需
Coach	职业咨询	树洞，私人职场咨询师	按需
Researcher	深度调研	ResearchBot ，深度研究员	按需（ Writer 触发）

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

SOUL.md 的真实片段：

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

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

注意看：

。只定义它自己该干的事。这就是隔离上下文最直接的方法——不是通过代码去裁剪上下文，而是从根源上不让无关信息进入。

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

说实话。

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

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

这个分布和 Anthropic 建议的演进路径一致：

。我目前还在 Phase 2 到 Phase 3 之间。

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

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

这也是给想尝试多 Agent 的人最直接的建议：

。