从单一Agent到多Agent架构：一次上下文优化的实践复盘

在AI Agent的开发实践中，单一Agent处理多任务的场景并不罕见。然而，当任务复杂度不断提升时，一个容易被忽视的问题会逐渐凸显——上下文窗口的局限性。本文将分享一个将单一Agent拆分为六个专用Agent的真实案例，探讨背后的技术考量和实践收获。

认知转变：重新定义上下文窗口的角色

问题的根源在于上下文窗口的“滥用”。当一个Agent同时承担公众号撰写、信息采集、开发辅助等多项职责时，系统提示词（SOUL.md）会变得臃肿不堪。更关键的是，每次对话时所有工具定义——无论当前任务是否需要——都会被加载到上下文中。写作任务的素材与开发任务的代码片段相互交织，导致模型在处理过程中频繁“失忆”，忘了之前搜索过什么、忘了文章的目标读者是谁。

拆分决策：基于职责的任务解耦

Karpathy提出的“上下文工程“概念提供了一个关键认知转变：Context Window不是数据库，而应该被视为CPU的L1/L2缓存——昂贵、有限且易失。这意味着我们需要像管理计算资源一样精细地管理上下文。当不同类型的任务上下文混合在一起时，模型的注意力被稀释，本质上不是模型变笨了，而是被无关信息“淹没“了。

Anthropic在《Building Effective AI Agents》中提供了一个实用的判断框架：当任务可以清晰拆分时使用Workflow，当需要灵活性和模型驱动决策时才使用Agent。参考这一原则，结合Parallel Workflow的典型场景——写作和信息采集是完全独立的任务，没有依赖关系——多Agent架构成为自然选择。拆分后的六个Agent各司其职：Main作为总调度负责协调，Writer专注于内容创作，Info负责信息采集，Dev提供开发辅助，Coach处理职业咨询，Researcher进行深度调研。每个Agent拥有独立的上下文窗口和工具集，实现了真正的职责隔离。

拆分后的效果是显著的。Info的四个定时任务（早8点简报、午12点更新、晚6点摘要、夜间采集）实现全天稳定推送；Writer每日定时触发，走完完整的写作流水线后自动生成草稿；Main在凌晨3点进行安全审计。写作时只加载写作相关内容，采集时只加载采集工具，不再互相干扰。

实践效果与演进路径

当然，协作深度仍有提升空间。目前六个Agent更像是六个独立的定时任务各跑各的，真正的跨Agent协作只有Writer→Researcher这一条路径。这与Anthropic建议的演进路径一致：从单Agent证明价值，到按职责拆分，再到深度协作。我们目前处于第二阶段向第三阶段过渡的过程中。

如有侵权，请联系删除。