OpenClaw 多 Agent：怎么配置、怎么用，普通人也能上手的一套思路

很多人第一次用 OpenClaw，会下意识把它当成“一个助手”。但任务一复杂——比如要查资料、写稿、做排版、再发到不同平台——你就会发现：把所有事都塞进一个对话里，容易乱、容易忘，也不好追责。

这就是“多 Agent”存在的理由：把大任务拆成几个小角色，每个角色只做自己擅长的一段，最后再汇总。感觉就像从“一个人硬扛”变成“一个小团队协作”。

一、先把核心概念讲清楚

1）主会话（Main Session）

主会话可以理解成“项目经理”的对话窗口：你在这里下指令、做决策、看结果、决定要不要继续。它更适合做取舍、定方向、做最终确认。

2）子 agent（Subagent）

子 agent 更像“专职同事/外包小组”。主会话把任务切一块丢给它：比如“只负责写草稿”“只负责 QA 挑错”“只负责把资料整理成要点”。

子 agent 的典型好处是：

• 专注：不容易被主会话里各种分支需求干扰。
• 结构化交付：可以强制按 schema 输出，利于下一步自动化。
• 并行：如果任务能拆开、资源也允许，通常可以同时跑几块，从而缩短总耗时。

3）ACP（结构化交接：让每一棒都“说清楚”）

你可以把 ACP 当成“交接格式/协议”。重点不是多一个角色，而是让上一棒的输出、下一棒的输入都“有标准可对齐”，比如用 JSON schema 约束字段。这样就不怕“话说半截、下一棒接不住”。

在 Content Factory 这类流水线里，常见做法是：每一棒输出严格的 JSON（比如 Writer output schema），下一棒只认这个格式，减少歧义。

二、配置思路：什么时候用哪个、模型怎么选、权限怎么管

1）什么时候用主会话？什么时候用子 agent？

一个简单判断：

• 需要你拍板、需要综合权衡（范围/取舍/敏感操作）→ 放主会话。
• 能把输入输出说清楚的执行任务（写草稿/抽要点/检查错误/跑命令）→ 丢子 agent。

最小可用搭配（先照这个跑通再升级）：

1. 主会话：定主题/受众/字数 + 最终确认
2. Writer 子 agent：只管写草稿
3. QA 子 agent：只管挑错 + 润色

举个例子：你要写一篇文章。主会话负责定主题、受众、风格、字数和禁区；Writer 子 agent 负责把文章按要求写出来；QA 子 agent 负责挑事实风险、逻辑漏洞、语气过度等。

2）模型选择：别迷信“越大越好”

一般来说：

• 写作/总结/改写：用更擅长语言的模型；成本敏感时可以先用中档模型出草稿，再用强模型做一轮润色或 QA。
• 工具调用/脚本执行/结构化输出：稳定性比文采更重要，选“遵循指令更稳”的模型。
• 长链路任务：把强模型用在关键决策点，把便宜模型用在可复用的体力活，性价比更高。

3）权限与安全：能不给就别给

多 agent 的一个重要原则是“最小权限”。比如：

• 写作 agent 不需要操作云盘，就不要给它 Drive 权限。
• 做运维检查的 agent 需要跑命令，但不应该默认拥有删除文件的能力。
• 涉及外发（发消息、发邮件、删改线上文档）这类动作，通常建议放在主会话里二次确认。

OpenClaw 里工具很多（读写文件、跑命令、发消息、访问文档系统等），权限越大，误操作风险越高。你可以把子 agent 当成“临时工”：只给它完成这份工所需的最少钥匙。

三、典型用法：3 个你马上用得上的场景

场景 1：内容工厂（选题→写作→QA→发布包）

这是最经典的多 agent 流水线：

1. Intel agent：找选题、给角度和资料来源（结构化输出）
2. Writer agent：按大纲写草稿（按 schema 输出 JSON）
3. QA agent：查逻辑、查夸大、查不清晰术语，给修改建议，必要时产出“可直接发布版”
4. Producer agent：整理标题/摘要/标签/封面提示词/发布文案

好处是每一步都可替换：你不满意 Writer 的风格，换一个 Writer；你更在意合规，就把 QA 变得更严格。

场景 2：机器健康检查（定期体检→风险清单→你确认→执行修复）

把任务拆成两段更安全：

• 子 agent 负责“只读检查”：版本、磁盘、端口暴露、日志异常等，输出报告和建议。
• 主会话负责“你确认后再改”：比如重启服务、调整防火墙、更新系统。

这样既省心，又能避免“自动修复把服务搞挂”的尴尬。

场景 3：办公自动化（读文档→整理→写回复/生成表格）

比如你给一堆会议纪要：

• 子 agent A：抽要点、行动项、负责人。
• 子 agent B：把行动项整理成表格字段（任务、截止时间、风险）。
• 主会话：你看一眼，确认无误后再写回文档或发送消息。

四、常见坑：踩一次就够了

1）schemas 路径写错

很多流水线要求“按 schema 输出”。最常见的坑就是：路径不对、文件不存在，或者你以为读了 schema 其实没读。

建议：在工作区里用稳定路径（例如 skills/.../schemas.md 这种），并在任务里明确要求“先读取 schemas 文件”。

2）cwd（当前工作目录）不一致

工具调用（尤其是 exec 跑命令、read/write 读写文件）很吃 cwd。你以为文件在 workspace/xxx，结果子 agent 的工作目录不同，写到了别处或读不到。

实用做法：

• 路径尽量用绝对路径，或明确“以 workspace 为根”。
• 产物统一落到固定目录（比如 articles/<id>/），别到处散。

3）子 agent 乱用上下文

子 agent 不是“更聪明的你”，它只是“更专注的一段执行”。如果你没把输入说清楚（目标、受众、限制、输出格式），它就会凭经验补全，结果你看着像“它自作主张”。

解决方式：把需求写成清单，尤其是“不能做什么”。

4）工具权限太大（或太小）

权限给太大，你会担心误操作；给太小，它又处处报错。一般做法是：先从最小权限开始，缺什么再补，别一上来全开。

小结：用多 Agent 的正确姿势

OpenClaw 的多 Agent，不是炫技，而是一种更工程化的“分工方法”：

• 主会话负责决策与确认；
• 子 agent 负责专注执行；
• 用 ACP/JSON schema 做交接，减少扯皮；
• 用最小权限把风险关在笼子里；
• 产物路径、cwd、schema 文件这些“地基”先打牢。

你不需要一开始就搞得很复杂。先把一个你经常做的流程（比如写文章）拆成 2-3 个角色跑通，等你尝到“稳定、省心、可复用”的甜头，再逐步扩展到更多场景就行。