多 Agent：一个人也能跑出团队感

多 Agent 架构任务流转三 Agent 分工Context 管理

有人问我：用 OpenClaw 配一个 Agent 不够吗，为什么要搞多个？

够用——但只够你一个人凑合。

想象一下，你让同一个员工今天做竞品调研，明天写 Python 脚本，后天帮你管日程。三个月后，他脑子里全是混乱的碎片，效率越来越低，你也越来越看不懂他在做什么。

多 Agent 要解决的就是这件事：把不同的工作交给合适的人，让每个人只做自己该做的事。

1一个 Agent 打天下，会撞上四堵墙

单 Agent 用久了，问题会一个一个冒出来。不是模型不够好，是架构本身有局限：

1

Context 膨胀，模型开始”失忆”

让同一个 Agent 又做竞品调研又写代码，搜索结果、页面内容、代码片段全堆在一个 context 里。跑几轮之后，token 撑满了，Agent 开始”失忆”——新内容进不来，早期的重要信息被挤出去了。不是它变笨了，是塞不下了。

2

人格冲突，风格互相拉扯

调研需要严谨、引用来源、不武断下结论；写代码需要直接、高效、敢于 exec 命令。同一个 SOUL.md 配两种风格，Agent 要么调研写得像工程日志，要么代码注释啰嗦得像学术论文。它不是没法改变，是你一直在让它分裂。

3

故障传播，一挂全挂

一个跑了两小时的调研任务占住了 session，你突然想问个日程或者发一条消息——没法用了，得等它跑完或者强制中断。把任务拆开，坏了一个，其他的继续跑，互不影响。

4

记忆混乱，三天后找不到自己的笔记

调研笔记、代码 debug 日志、聊天记录全堆在一个 memory/ 目录。一个月后打开，完全不知道哪条重要、哪条是垃圾。不是记性差，是根本没有分类。

四个问题的根源是同一件事：一个人在做所有类型的工作。解法也是同一件事：拆开。

2Agent vs Subagent：全职员工和外包临时工

在聊怎么拆之前，先搞清楚两个概念的区别，否则后面很容易搞混。

一句话区别：Subagent 解决”做一件事”，Agent 解决”做一类事”。

一次性的数据处理、格式转换、临时调研——用 Subagent，spawn 一个，做完自动走人。长期的调研职能、代码维护、日常对话——配独立 Agent，让它积累领域知识和记忆。两者不冲突，完全可以混用。

3三 Agent 分工：一个可以直接抄的方案

说一个我在用的结构，三个 Agent，各管一块：

每个 Agent 有自己的 SOUL.md，配不同的风格。research Agent 的 SOUL.md 里写”严谨、引用来源、不武断下结论”；coding Agent 的 SOUL.md 里写”工程优先、直接 exec、报告错误而不是猜测”。main Agent 保持中立，专注协调。

三个 Agent 各有独立的 memory/ 目录，调研笔记归调研 Agent，代码日志归 coding Agent，互不污染。

4任务流转：一次完整的协作过程

光说架构有点抽象。来看一个真实的场景，感受一下三个 Agent 是怎么协作的。

场景：Karl 想调研5个竞品，输出一份对比报告，然后根据报告写一个原型。

这是个典型的跨 Agent 任务——调研和写代码是两件性质完全不同的事，不该挤在同一个 context 里。来看它怎么流转：

全程 main Agent 的 context 只有”任务协调”：发了什么请求、收到了什么结果。调研数据、代码调试、debug 日志，一字没有进来。每个 Agent 只看自己需要的东西，context 干净，效率高，互不干扰。

5工具优先级：一段话说清楚

工具这边有一个优先级顺序值得记住：Skill > CLI > MCP。Skill 触发最稳定，不依赖额外进程，在所有模式下都能正常工作；MCP 能力强但配置复杂，Cursor ACP 模式下完全不可用，属于高风险高维护成本。优先建 Skill，比折腾 MCP 省心得多。

最后

如果你现在只有一个 main Agent，先把它跑稳再说。但当你发现某类任务开始拖慢响应、memory 越来越乱、Agent 越来越”分裂”，那就是该拆的信号。拆的时机比拆的方式更重要。

三 Agent 的结构不是唯一答案，但是个好的起点——main 做协调，research 做调研，coding 做工程，各有独立的记忆和风格。任务在 Agent 之间流转，每个环节只看自己需要的东西。