推荐语
单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 很实用：
| 场景 | 推荐架构 |
|---|
| 单一职责、流程明确 | 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 句概括，不展开
注意看：每个 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 跑通核心工作流开始，遇到上下文问题了再拆，不要一上来就搞六个。
粤ICP备14082021号
免费POC，
零成本试错
