夜雨聆风前言：当内容团队遇到多智能体
我曾经接触过一家新媒体公司，他们的运营团队只有5个人，却要每天生产：
• 10篇公众号文章 • 20条短视频脚本 • 15张定制配图 • 5篇行业分析报告
在传统工作模式下，这几乎是不可能完成的任务。即使拼命加班，团队成员也常常在深夜11点还在改稿。内容的质量参差不齐，因为没有人有时间仔细审核每一篇。更糟糕的是，当团队成员请假时，整个工作流就会陷入瘫痪。
这就是我今天要分享的案例的背景。
这家公司后来用OpenClaw的多智能体架构，搭建了一个"AI内容工厂"。现在的运行状态是：
• 5个人的团队变成了"3人+5Agent"的混合工作模式 • 内容日产量从15篇提升到了100+篇 • 发布时间从晚上11点提前到了下午3点 • 内容质量反而更稳定，因为有专职的审核Agent把关
更重要的是，团队成员从此告别了重复性的内容生产工作，把精力放到了更有价值的创意策划和人工审核上。
在接下来的文章中，我将用这个真实的"AI内容工厂"作为案例，从以下几个维度详细讲解OpenClaw多智能体系统的实战技能：
第一部分：架构设计篇 —— 如何设计多Agent的分工和协作模式 第二部分：配置实现篇 —— openclaw.json的每个配置项的含义和写法 第三部分：调度实战篇 —— sessions_spawn的多种用法和注意事项 第四部分：生产级配置篇 —— 安全隔离、权限控制、异常处理的完整方案 第五部分：效果验证篇 —— 如何衡量多Agent系统的效果
每个部分都配有详细的配置示例和运行截图（图文说明），确保你读完就能在自己的项目中落地实践。
第一章：为什么你需要多智能体架构
1.1 单Agent的三个瓶颈
在我深入讲解多Agent架构之前，我想先分析一下为什么单Agent模式会遇到瓶颈。
瓶颈一：上下文膨胀
当一个Agent需要处理多种任务时，它的系统提示词（System Prompt）会变得越来越复杂。写文章需要一套指令，生图需要另一套指令，审核又需要第三套指令。这三套指令放在一起，不仅会消耗大量的Token，还会导致Agent在不同任务之间"串戏"——有时候生图的指令会干扰写文章的质量。
瓶颈二：无法并行
很多内容任务实际上是相互独立的。比如写文章和生配图，这两个任务完全不依赖彼此，可以同时进行。但在单Agent模式下，你只能先写完文章，再生成配图，浪费了大量的等待时间。
瓶颈三：专业度不足
一个"什么都会"的Agent，往往每个领域都只是"半吊子"。让它写文章，它不如专门写作的Prompt工程师；让它生图，它不如专门的图像生成模型。多Agent架构的核心思想就是：让专业的Agent做专业的事。
1.2 多Agent的价值
通过多Agent架构，我们可以解决上述所有问题：
1.3 这个案例能给你带来什么
本文的"AI内容工厂"案例，涵盖了多Agent系统开发中最核心的技能点：
技能点一：Agent职责划分如何给每个Agent定义清晰的职责边界，避免功能重叠和冲突。
技能点二：sessions_spawn调度如何用spawn机制实现任务的并行、顺序、依赖三种执行模式。
技能点三：Bindings路由配置如何配置Bindings让不同的请求自动路由到对应的Agent。
技能点四：工具权限隔离如何通过工具白名单/黑名单控制每个Agent的权限边界。
技能点五：Announce结果汇报如何让子Agent的执行结果正确汇报给主Agent。
技能点六：生产级配置包括会话维护、异常处理、日志追踪等生产环境必需的技能。
第二章：AI内容工厂的架构设计
2.1 团队构成与分工
在设计多Agent系统之前，我们首先要明确每个Agent的职责边界。一个好的Agent分工应该满足以下原则：
原则一：单一职责每个Agent只负责一件事，而且把这件事做到最好。
原则二：接口清晰Agent之间的信息传递通过明确的接口完成，不存在模糊地带。
原则三：独立运行每个Agent都可以独立测试、独立部署，不依赖其他Agent的内部实现。
原则四：易于扩展当需要新功能时，可以新增Agent而不是修改现有Agent。
基于这四个原则，我们设计了"AI内容工厂"的Agent团队：
AI内容工厂 Agent团队├── 内容主编（Main Agent）│ ├── 职责：接收请求、分解任务、整合输出│ └── 模型：Claude Sonnet 4.5（强推理+Function Calling）│├── 文案专家（Writer Agent）│ ├── 职责：文章写作、脚本创作、标题优化│ ├── 模型：GPT-4o（文字能力强）│ └── 输出：Markdown格式文章│├── 视觉设计师（Designer Agent）│ ├── 职责：配图生成、封面设计、图表制作│ ├── 模型：MiniMax-M2.7（生图+中文理解）│ └── 输出：AI生图描述词│├── 质量审核（Reviewer Agent）│ ├── 职责：错别字检查、事实核查、逻辑审核│ ├── 模型：Claude Sonnet 4.5（严谨、规则执行准确）│ └── 输出：结构化审核报告│└── 排版助手（Formatter Agent） ├── 职责：Markdown排版、格式规范化、标题优化 ├── 模型：GPT-4o-mini（轻量级任务） └── 输出：格式化后的最终文章2.2 工作流程设计
Agent分工确定之后，我们需要设计它们之间的协作流程。
用户请求 ↓内容主编（Main Agent） ↓任务分解与分发 ↓┌────────┬────────┬────────┐↓ ↓ ↓ ↓Writer Designer Reviewer Formatter(并行) (并行) (等待) (等待)↓ ↓ ↓ ↓└────────┴────────┴────────┘ ↓内容主编整合输出 ↓最终交付这个流程设计有几个关键点：
关键点一：主Agent不做具体执行主Agent只负责任务分发和结果整合，不参与具体的写作、生图等工作。这样可以让主Agent专注于协调工作，避免因为具体任务而分心。
关键点二：同类任务并行Writer和Designer的工作是完全独立的，所以它们可以并行执行。这大大缩短了总体的执行时间。
关键点三：Reviewer有独立执行权Reviewer可以独立审核，不需要等其他Agent完成。但它的审核结果会影响是否需要打回重写。
关键点四：Formatter在最后Formatter只处理格式问题，在所有内容都审核通过之后才执行。
2.3 信息传递设计
多Agent系统的一个核心问题是如何设计Agent之间的信息传递。在"AI内容工厂"中，我们采用以下设计：
传递方式一：直接调用主Agent通过sessions_spawn直接调用子Agent，任务描述通过task参数传递。
传递方式二：文件系统子Agent的输出写入到指定的文件，主Agent通过读取文件获取结果。文件路径统一规范为：
content-studio/└── output/ ├── article_draft.md # Writer输出 ├── image_prompts.json # Designer输出 ├── review_report.json # Reviewer输出 └── article_final.md # Formatter输出传递方式三：Announce机制子Agent完成工作后，通过Announce机制向主Agent汇报结果。Announce的内容包括执行状态、输出文件路径、错误信息（如有）。
第三章：配置文件详解——openclaw.json的每个配置项
3.1 完整配置展示
以下是"AI内容工厂"的完整openclaw.json配置：
{ "agents": { "list": [ { "id": "main", "name": "内容主编", "default":true, "workspace": "./workspace-main", "model": "anthropic/claude-sonnet-4-5", "groupChat": { "mentionPatterns": ["@主编", "@main", "@内容"] } }, { "id": "writer", "name": "文案专家", "workspace": "./workspace-writer", "model": "openai/gpt-4o", "tools": { "allow": ["read", "write", "edit"], "deny": ["exec", "browser", "sessions_send", "sessions_spawn"] } }, { "id": "designer", "name": "视觉设计师", "workspace": "./workspace-designer", "model": "minimax/MiniMax-M2.7", "tools": { "allow": ["read", "image"], "deny": ["write", "exec", "sessions_send", "sessions_spawn"] } }, { "id": "reviewer", "name": "质量审核", "workspace": "./workspace-reviewer", "model": "anthropic/claude-sonnet-4-5", "tools": { "allow": ["read"], "deny": ["write", "edit", "exec", "browser", "sessions_send", "sessions_spawn"] } }, { "id": "formatter", "name": "排版助手", "workspace": "./workspace-formatter", "model": "openai/gpt-4o-mini", "tools": { "allow": ["read", "write", "edit"], "deny": ["exec", "browser", "sessions_send", "sessions_spawn"] } } ], "defaults": { "subagents": { "maxConcurrent": 4, "maxSpawnDepth": 2, "runTimeoutSeconds": 300 } } }, "bindings": [ { "agentId": "main", "match": { "channel": "webchat" } } ], "session": { "dmScope": "per-channel-peer", "maintenance": { "mode": "enforce", "pruneAfter": "7d", "maxEntries": 200, "rotateBytes": "10mb" } }, "tools": { "agentToAgent": { "enabled":false } }}3.2 配置项逐项解析
下面对每个关键配置项进行详细解析：
配置项一：agents.list
agents.list定义了整个系统中所有的Agent。每个Agent的必填配置包括：
配置项二：tools配置
每个子Agent都可以通过tools配置来限制其可用工具：
"tools": { "allow": ["read", "write", "edit"], "deny": ["exec", "browser", "sessions_send", "sessions_spawn"]}这个配置的含义是：
• allow列表：只有列表中的工具可以用 • deny列表：列表中的工具绝对不能用 • 如果只有allow没有deny，表示只允许使用allow中的工具 • 如果只有deny没有allow，表示禁止使用deny中的工具，其他都可以
为什么Writer Agent要deny sessions_spawn？
因为Writer Agent的职责是写文章，它不应该有能力去spawn其他Agent。如果允许它spawn，就可能发生Writer spawn了一个恶意的Agent来执行危险操作。
配置项三：subagents配置
"subagents": { "maxConcurrent": 4, "maxSpawnDepth": 2, "runTimeoutSeconds": 300}这个配置定义了子Agent的运行策略：
为什么要限制maxConcurrent？
如果不限制，当用户提交大量任务时，系统可能会同时启动几十个子Agent，导致：
• Token消耗暴增 • API限流 • 系统资源耗尽 • 响应变得极慢
设置maxConcurrent=4可以确保系统始终保持可管理的负载。
配置项四：session.maintenance
"session": { "maintenance": { "mode": "enforce", "pruneAfter": "7d", "maxEntries": 200, "rotateBytes": "10mb" }}这个配置定义了会话存储的维护策略：
为什么需要维护策略？
在生产环境中，每天可能产生数百个会话。如果不清理：
• sessions.json会越来越大 • 读取速度变慢 • 磁盘空间被耗尽
第四章：工作区配置——每个Agent的"大脑"
4.1 主Agent工作区：workspace-main
主Agent的工作区是整个系统的"指挥部"。它的AGENTS.md定义了主Agent的角色定位和行为规则。
workspace-main/AGENTS.md
# 角色：AI内容工厂总指挥## 核心职责1. **接收用户请求** - 理解用户的创作需求 - 判断任务类型和复杂度2. **任务分解** - 将复杂任务分解为可并行的子任务 - 确定任务执行顺序和依赖关系3. **调度执行** - 通过sessions_spawn启动子Agent - 监控子Agent的执行状态 - 处理超时和异常4. **结果整合** - 收集各子Agent的输出 - 审核结果（如需要） - 生成最终交付物## 调度规则### 任务类型判断当收到用户请求时，首先判断任务类型：| 任务类型 | 处理方式 ||----------|----------|| 纯文章 | 只调度Writer，最后Formatter || 文章+配图 | 并行调度Writer和Designer，最后Formatter || 仅配图 | 只调度Designer || 需要审核 | 调度Reviewer，结果影响后续流程 |### 执行模式并行模式：tasks = [spawn(writer), spawn(designer)]results = await all(tasks)
顺序模式：result1 = await spawn(task1)result2 = await spawn(task2, depend_on=result1)
## 输出规范所有输出必须包含：- status: "success" | "failed" | "partial"- tasks: 任务列表及其状态- output: 最终输出文件路径- errors: 错误信息（如有）workspace-main/SOUL.md
# 性格设定：专业、高效、严谨## 沟通风格- **专业但不死板**：用简洁清晰的语言沟通- **主动汇报**：任务开始、进展、完成都及时反馈- **透明决策**：任务分解的逻辑对用户透明## 回复模板任务开始时："收到任务，正在分析... 任务已分解为3个子任务：1. [Writer] 生成文章正文2. [Designer] 生成配图描述3. [Reviewer] 审核内容预计完成时间：3-5分钟"任务完成时："[OK] 任务已完成！- 文章：output/article_final.md- 配图：3张（已生成描述词）- 审核：通过了（评分88/100）"任务失败时："[Warning] 任务遇到问题：原因：[具体描述]解决方案：[建议]是否需要我重试？"4.2 文案专家工作区：workspace-writer
Writer Agent是"AI内容工厂"的核心生产者之一。
workspace-writer/AGENTS.md
# 角色：文案创作专家## 专业领域- 公众号文章写作- 短视频脚本创作- 标题优化与AB测试- 配图描述词撰写- SEO文章优化## 工作规范### 写作流程1. 理解需求要点（主题、受众、风格、字数）2. 确定文章结构3. 撰写正文4. 自检（错别字、标点、逻辑）5. 输出### 输出格式所有文章必须遵循以下格式：\`\`\`markdown# [标题]## [副标题][正文内容，每段不超过150字]---作者：糯米AI助手生成时间：[具体时间]字数：[X]字\`\`\`### 禁止事项- 禁止在文章中编造数据（除非用户明确要求）- 禁止使用敏感词汇- 禁止超过用户指定的字数限制±20%workspace-writer/PROMPTS/article-template.md
这是一个提示词模板，Writer Agent可以根据不同任务选择合适的模板：
# 公众号文章模板库## 模板一：干货分享型结构：1. 开篇痛点（100字）：描述读者面临的问题2. 核心观点（3-4个要点，每个200字）：提供解决方案3. 案例分析（150字）：真实或虚构案例4. 总结行动（100字）：核心要点回顾+行动号召适用场景：技能教程、工具推荐、方法论## 模板二：故事叙事型结构：1. 故事引入（200字）：一个有戏剧性的场景2. 冲突升级（300字）：面临的最大挑战3. 转折点（200字）：如何找到解决方案4. 经验总结（200字）：读者能学到什么适用场景：个人经历、团队故事、品牌故事## 模板三：对比测评型结构：1. 测评背景（100字）：为什么做这个测评2. 选手介绍（每个100字）：参评对象3. 维度对比（3-4个维度，每个150字）：客观对比4. 总结推荐（150字）：适合的人群和场景适用场景：产品测评、工具对比、方案对比4.3 视觉设计师工作区：workspace-designer
Designer Agent专门负责人工智能生成图像的提示词优化。
workspace-designer/AGENTS.md
# 角色：AI视觉设计专家## 专业领域- AI生图提示词优化- 封面设计- 信息图表设计- 图片风格转换- 视觉内容审核## 工作规范### 提示词优化原则1. **精确性**：描述词必须精确，避免歧义2. **简洁性**：去掉艺术化描述，保留核心视觉元素3. **比例明确**：注明画面比例（16:9、4:3、1:1等）4. **风格指定**：明确指定风格（科技、温暖、简约等）### 输出格式\`\`\`json{ "image_type": "cover | inline | banner", "aspect_ratio": "16:9 | 4:3 | 1:1", "style": "风格描述", "description": "精确的AI生图描述词", "alt_text": "图片替代文字（用于SEO）"}\`\`\`### 审核标准生成配图描述时，必须检查：- [ ] 描述词中无歧义词汇- [ ] 风格明确- [ ] 比例指定- [ ] 适合目标受众4.4 质量审核工作区：workspace-reviewer
Reviewer Agent是内容质量的守门员。
workspace-reviewer/AGENTS.md
# 角色：内容质量审核专家## 审核维度### 1. 错别字审核- 使用错别字检测工具- 注意形近字（如"己"和"已"）- 注意音近字（如"的地得"的混用）### 2. 标点审核- 无中英文标点混用- 句号使用正确- 引号使用规范### 3. 敏感词审核- 政治敏感词：一票否决- 色情低俗词：一票否决- 虚假夸大词：标注警告### 4. 事实核查- 数据必须有来源或标注"估算"- 引用必须准确- 时效性内容必须注明日期### 5. 逻辑审核- 段落之间逻辑通顺- 论点论据对应- 无自相矛盾## 输出格式\`\`\`json{ "passed": true | false, "score": 0-100, "errors": [ { "type": "typo | punctuation | sensitive | fact | logic", "location": "第X段第Y句", "content": "问题内容", "suggestion": "修改建议" } ], "warnings": [ { "type": "style | clarity | engagement", "content": "建议内容" } ]}\`\`\`## 评分标准| 分数段 | 等级 | 说明 ||--------|------|------|| 90-100 | 优秀 | 无需修改可直接发布 || 75-89 | 良好 | 少量修改后可发布 || 60-74 | 及格 | 需要修改后才能发布 || <60 | 不及格 | 需要打回重写 |## 通过标准- passed = true- errors数组为空- score >= 75如果不满足，输出中必须包含具体的修改建议。第五章：sessions_spawn调度详解——并行、顺序、依赖
5.1 什么是sessions_spawn
sessions_spawn是OpenClaw中用于启动子Agent的核心工具。它的作用是：在当前Agent的会话中，创建一个新的独立会话来执行特定任务。
为什么需要独立的会话？
因为子Agent需要：
• 独立的上下文（不会受到其他任务的影响） • 独立的系统提示词（只加载自己Agent的配置） • 独立的状态管理（执行结果不会干扰主Agent）
5.2 基础用法：并行执行
当多个任务相互独立时，可以使用并行执行模式：
场景：用户请求"写一篇AI的文章，配一张封面图"
这两个任务是完全独立的，可以同时进行：
{ "task": "写一篇关于大语言模型发展历程的公众号文章。字数：800-1000字。目标读者：对AI感兴趣的普通用户。保存到 output/article_draft.md。", "runtime": "subagent", "agentId": "writer", "label": "article-write"}同时发起另一个任务：
{ "task": "为文章生成封面图描述词。文章主题：大语言模型。风格要求：科技感、现代、蓝色系。比例：16:9。请生成3个不同风格的描述词供选择，保存到 output/image_prompts.json。", "runtime": "subagent", "agentId": "designer", "label": "image-generate"}执行效果：
[并行执行]Writer Agent ──→ 生成文章 ──→ output/article_draft.md ↑Designer Agent ──→ 生成描述词 ──→ output/image_prompts.json ↑ └── 两者同时进行，总耗时 ≈ max(t1, t2)5.3 进阶用法：顺序依赖
当任务B依赖任务A的结果时，需要使用顺序执行模式：
场景：必须先写完文章，才能根据文章内容生成配图描述
{ "task": "写一篇关于AI Agent的文章。保存到 output/article_draft.md。", "runtime": "subagent", "agentId": "writer", "label": "step1-write"}等待Writer完成后，读取output/article_draft.md的内容，然后执行：
{ "task": "根据以下文章内容，生成配图描述词。文章核心内容：[读取output/article_draft.md]。生成3个描述词，保存到 output/image_prompts.json。", "runtime": "subagent", "agentId": "designer", "label": "step2-design"}执行效果：
[顺序执行]Writer Agent ──→ 生成文章 ──→ output/article_draft.md ↓Designer Agent ──→ 读取文章 ──→ 生成描述词 ──→ output/image_prompts.json ↑ 总耗时 = t1 + t2（无法并行）5.4 高级用法：条件分支
当审核结果决定后续流程时，使用条件分支：
# 伪代码示例review_result = await spawn(reviewer, task="审核 output/article_draft.md")if review_result.passed: # 审核通过，直接格式化输出 final = await spawn(formatter, task="格式化 output/article_draft.md")else: # 审核不通过，打回重写 rewrite_result = await spawn(writer, task="根据审核意见修改文章，保存到 output/article_draft_v2.md") # 重新审核 review_result2 = await spawn(reviewer, task="审核 output/article_draft_v2.md")5.5 批量任务处理
当用户一次提交多个任务时，使用批量处理：
{ "task": "创建5篇文章的任务队列：['AI编程工具盘点', '2024 AI趋势预测', 'ChatGPT使用技巧', '主流大模型对比', 'AI入门完全指南']。每篇文章需要：正文800-1000字+配图描述词。请按顺序执行，完成一篇再下一篇，每篇输出到 output/article_[序号].md。", "runtime": "subagent", "agentId": "main", "label": "batch-processing"}主Agent内部维护任务队列状态：
[Batch Progress]任务1: AI编程工具盘点 - ✓ 已完成任务2: 2024 AI趋势预测 - → 执行中任务3: ChatGPT使用技巧 - ○ 排队中任务4: 主流大模型对比 - ○ 排队中任务5: AI入门完全指南 - ○ 排队中第六章：Bindings路由配置——让请求找到对的Agent
6.1 路由规则基础
Bindings是OpenClaw中用于将请求路由到特定Agent的配置。它的核心原理是"最具体匹配优先"。
匹配优先级（数字越小优先级越高）：
1. peer匹配（精确的DM或群组ID） 2. parentPeer匹配（线程继承） 3. guildId + roles（Discord角色路由） 4. guildId（服务器级） 5. accountId（渠道账户） 6. channel（渠道级） 7. 默认Agent
6.2 实际配置示例
以下是"AI内容工厂"的Bindings配置：
{ "bindings": [ { "agentId": "main", "match": { "channel": "webchat" } } ]}这个配置的含义是：所有来自webchat渠道的请求都路由到main Agent。
更复杂的场景：
如果你有多个渠道：
{ "bindings": [ { "agentId": "main", "match": { "channel": "webchat" } }, { "agentId": "work", "match": { "channel": "telegram" } }, { "agentId": "family", "match": { "channel": "whatsapp", "peer": { "kind": "group", "id": "120363999999999999@g.us" } } } ]}这个配置的含义：
6.3 Bindings的常见错误
错误一：顺序错误
{ "bindings": [ { "agentId": "family", "match": { "channel": "whatsapp" } // 这个会匹配所有WhatsApp }, { "agentId": "main", "match": { "channel": "whatsapp", "peer": { "kind": "group", "id": "120363...@g.us" } // 这个永远不会被匹配到 } } ]}正确顺序：更具体的匹配要放在前面！
错误二：channel名称拼写错误
// 错误：whatsapp 拼成了 WhatsApp{ "agentId": "main", "match": { "channel": "WhatsApp" } }// 正确：检查实际的channel名称{ "agentId": "main", "match": { "channel": "whatsapp" } }第七章：工具权限隔离——保护系统安全
7.1 为什么需要工具隔离
在多Agent系统中，工具隔离是保障安全的关键。想象一下：
如果Writer Agent可以执行exec命令，它就能在服务器上执行任意shell命令。如果Designer Agent可以调用sessions_spawn，它就能启动无限层级的子Agent。如果Reviewer Agent可以写入文件，它就能修改其他Agent的输出。
这些都是不应该发生的越权行为。
7.2 分层隔离设计
我们采用"最小权限原则"进行工具隔离设计：
主Agent（main）
"tools": { "allow": ["read", "write", "edit", "sessions_spawn", "sessions_list", "sessions_history"], "deny": []}主Agent需要调度子Agent，所以需要sessions_spawn。但不允许直接调用危险工具。
文案Agent（writer）
"tools": { "allow": ["read", "write", "edit"], "deny": ["exec", "browser", "sessions_send", "sessions_spawn", "cron"]}Writer只需要读写文件来保存文章，不需要其他权限。
视觉Agent（designer）
"tools": { "allow": ["read", "image"], "deny": ["write", "exec", "sessions_send", "sessions_spawn", "cron"]}Designer只需要读取文章内容并生成图片，不需要写入权限。
审核Agent（reviewer）
"tools": { "allow": ["read"], "deny": ["write", "edit", "exec", "browser", "sessions_send", "sessions_spawn", "cron"]}Reviewer只需要读取文章进行审核，不需要任何写入或执行权限。
7.3 权限矩阵
第八章：Announce机制——子Agent如何回报结果
8.1 Announce的工作原理
当子Agent完成任务时，它会通过Announce机制向主Agent汇报结果。这个过程是自动的，不需要子Agent显式调用。
Announce包含的信息：
• Result：子Agent的回复文本，或最新的toolResult • Status：completed successfully / failed / timed out • Runtime：运行时间 • Token使用：输入/输出token统计 • sessionKey和sessionId：可用于后续查询
8.2 主Agent如何处理Announce
主Agent会接收到子Agent的Announce作为系统事件，然后进行处理：
子Agent完成 → Announce事件 → 主Agent处理 → 决定后续流程处理逻辑示例：
# 伪代码on_receive_announce(announce): task_label = announce.label status = announce.status result = announce.result if status == "completed successfully": if task_label == "article-write": # 读取输出文件，进入下一步 content = read_file("output/article_draft.md") spawn(reviewer, task=f"审核文章: {content}") elif task_label == "image-generate": # 读取描述词，继续 prompts = read_json("output/image_prompts.json") notify_user(f"配图已生成: {prompts}") elif status == "failed": # 处理失败 notify_user(f"任务失败: {announce.error}") # 可能需要重试或人工介入8.3 Announce的注意事项
注意一：结果的完整性
子Agent应该确保输出完整再返回。如果输出不完整（比如写入文件时中断），主Agent可能会获取到错误的结果。
注意二：超时处理
如果设置了runTimeoutSeconds，子Agent超时时Announce的status会变成"timed out"。主Agent应该能处理这种情况。
注意三：ANNOUNCE_SKIP
如果子Agent的最终回复恰好是"ANNOUNCE_SKIP"这个字符串，系统不会发送Announce。这在某些特殊场景下有用，但大多数情况下不要这样做。
第九章：生产级配置——让系统稳定运行
9.1 会话维护配置
在生产环境中，会话数量会快速增长。如果不进行维护，会导致：
• sessions.json越来越大，读取变慢 • 磁盘空间被耗尽 • 系统重启后加载变慢
我们配置的维护策略：
"session": { "maintenance": { "mode": "enforce", "pruneAfter": "7d", "maxEntries": 200, "rotateBytes": "10mb" }}这个配置的含义：
• 超过7天的会话自动清理 • 最多保留200个会话 • sessions.json超过10MB时自动轮换
9.2 日志追踪配置
当出现问题时，我们需要能够追踪到具体是哪个环节出了问题。
OpenClaw的日志默认保存在：
~/.openclaw/logs/gateway.log对于重要的操作，我们建议在关键节点添加日志：
# 主Agent的关键日志点1. 收到请求时： [INFO] Received request: {user_id} - {task_type}2. 任务分解时： [INFO] Task decomposed: {subtasks}3. 启动子Agent时： [INFO] Spawning subagent: {agent_id} - {task_label}4. 收到Announce时： [INFO] Received announce: {label} - {status}5. 任务完成时： [INFO] Task completed: {output_path}9.3 异常处理机制
以下是建议的异常处理流程：
# 伪代码async def execute_with_retry(agent_id, task, max_retries=3): for attempt in range(max_retries): try: result = await spawn(agent_id, task) if result.status == "completed successfully": return result except Exception as e: if attempt == max_retries - 1: # 所有重试都失败 return {"status": "failed", "error": str(e)} # 等待后重试 await sleep(5) return {"status": "failed", "error": "Max retries exceeded"}第十章：效果验证——如何衡量多Agent系统的价值
10.1 效率指标
指标一：任务完成时间
指标二：并行度
# 计算并行度parallelism = sum(task_duration for task in parallel_tasks) / max(task_duration for task in parallel_tasks)# 例如：Writer 3分钟，Designer 2分钟# 总耗时 = 3分钟（并行）# 理论耗时 = 3 + 2 = 5分钟（串行）# 实际并行度 = 5 / 3 = 1.6710.2 质量指标
指标一：审核通过率
{ "total_articles": 100, "first_pass": 85, "after_revision": 15, "rejected": 0, "pass_rate": "100%"}指标二：平均审核评分
通过持续优化提示词和规则，审核评分在稳步提升。
10.3 成本指标
Token消耗对比（以一个月为例）：
结论：多Agent虽然总Token消耗略有增加，但内容产量大幅提升，单篇成本反而大幅下降。
结语：你的多智能体实践之路
在本文中，我通过"AI内容工厂"这个真实案例，系统性地讲解了OpenClaw多智能体系统的核心技能：
架构设计：如何划分Agent的职责，设计协作流程，规划信息传递机制。
配置实现：openclaw.json的每个配置项的含义、注意事项和最佳实践。
调度实战：sessions_spawn的并行、顺序、条件分支、批量处理等用法。
路由配置：Bindings的匹配规则、优先级和常见错误。
安全隔离：工具权限的分层设计，最小权限原则的落地。
结果汇报：Announce机制的工作原理和处理逻辑。
生产部署：会话维护、日志追踪、异常处理的完整方案。
效果验证：效率、质量、成本三个维度的衡量指标。
现在，你已经有了足够的基础知识来搭建自己的多智能体系统。以下是我建议的实践路径：
第一步：从最小系统开始
不要一开始就设计5个Agent的系统。先从2个Agent开始：一个主Agent，一个子Agent。比如：
• 主Agent + Writer Agent（最简单的文章生产） • 主Agent + Reviewer Agent（最简单的审核流程）
第二步：逐步增加复杂度
当2Agent系统稳定运行后，再增加新的Agent。比如增加Designer Agent，变成：
• 主Agent + Writer Agent + Designer Agent
第三步：优化和调优
观察系统的瓶颈和错误，不断优化提示词、调整并发数、完善异常处理。
第四步：扩展到生产环境
当系统足够稳定后，考虑接入真实的用户请求，建立完整的监控和告警机制。
多智能体协作是一个广阔的领域，本文学到的只是基础。但基础扎实了，高级玩法自然就水到渠成。
祝你搭建出属于自己的多智能体系统！
附录
附录A：完整项目目录结构
content-studio/├── openclaw.json # 主配置文件│├── workspace-main/ # 主Agent工作区│ ├── AGENTS.md # 角色定义│ ├── SOUL.md # 人设配置│ └── TASKS/ # 任务队列│├── workspace-writer/ # 文案Agent工作区│ ├── AGENTS.md│ └── PROMPTS/│ └── article-template.md│├── workspace-designer/ # 视觉Agent工作区│ ├── AGENTS.md│ └── STYLE/│ └── design-rules.md│├── workspace-reviewer/ # 审核Agent工作区│ ├── AGENTS.md│ └── RULES/│ └── checklist.md│├── workspace-formatter/ # 排版Agent工作区│ └── AGENTS.md│└── output/ # 输出目录 ├── article_draft.md ├── image_prompts.json ├── review_report.json └── article_final.md附录B：快速启动命令
# 1. 创建项目目录mkdir content-studiocd content-studio# 2. 初始化配置# 复制上面的openclaw.json到当前目录# 3. 创建工作区mkdir -p workspace-main workspace-writer workspace-designermkdir -p workspace-reviewer workspace-formatter output# 4. 创建各Agent配置文件# 按照本文的配置创建相应的AGENTS.md和SOUL.md# 5. 启动Gatewayopenclaw gateway start# 6. 验证Agent列表openclaw agents list# 7. 发送测试任务# 向主Agent发送：# "写一篇关于AI大模型的文章，500字，配一张科技风封面图"附录C：常见问题排查
附录D：相关资源链接
• OpenClaw官网：https://openclaw.ai • 官方文档：https://docs.openclaw.ai • GitHub仓库：https://github.com/openclaw/openclaw • Discord社区：https://discord.gg/clawd • ClawHub技能市场：https://clawhub.com • 模型提供商：OpenAI / Anthropic / Google Gemini / MiniMax
