跳转至

龙虾装上了，可以用来干啥？分享下我的 OpenClaw 多智能体团队搭建经验！

Ch03.012 龙虾装上了，可以用来干啥？分享下我的 OpenClaw 多智能体团队搭建经验！

📊 Level ⭐ | 9.6KB | entities/龙虾装上了可以用来干啥分享下我的-openclaw-多智能体团队搭建经验.md

龙虾装上了，可以用来干啥？分享下我的 OpenClaw 多智能体团队搭建经验！

大家好，欢迎来到 code秘密花园，我是花园老师（ConardLi）

相关实体

→ 原文存档

深度分析

这篇文章的核心洞察并非某个具体的 OpenClaw 配置技巧，而是对「专精智能体优于全能智能体」这一设计原则的实证。作者从自己两个月内迭代出六个专精 Agent 的实践经验出发，总结出了三个阻碍全能 Agent 的根本原因：上下文污染、技能冲突和人设冲突。这三个问题本质上都是单一 Agent 上下文窗口容量有限性与多场景需求之间的结构性矛盾——在 LLM 的上下文窗口有物理限制的前提下，往里面塞入的异质性内容越多，每个子任务能分配到的注意力密度就越低，最终表现为 Agent 在每个任务上的表现都不够专业。专精 Agent 的设计通过将上下文空间按职能领域做隔离，让每个 Agent 的注意力资源始终高度集中，这是该方法论的有效性来源 。

作者提出的「不是设计出来的，是用出来的」这一 Agent 搭建方法论值得特别注意。与传统软件工程中先完整设计再实现的范式不同，多智能体系统的设计本身是一个持续迭代的过程：先从最高频的单一需求开始搭建第一个 Agent，在使用中积累对这个 Agent 能力边界的认知，进而发现新的痛点和需求，再搭建下一个 Agent。这是一种典型的渐进式架构设计思路——它的代价是初期可能要经历几次重新调整，但最终得到的系统与真实需求的匹配度远高于一开始就做完整设计的方案。作者以「七个 Agent 覆盖十几个场景」的实践验证了这条路径的可行性，对于正在规划多 Agent 系统的团队具有直接的参考价值 。

OpenClaw 的多 Agent 协作机制（sessions_spawn + Announce 非阻塞广播 + subagents allowlist）是该系统的关键架构设计。与直接通过函数调用进行同步协作不同，OpenClaw 的协作是事件驱动的异步模式：主管 Agent 发起调用后立即继续自己的任务，被调用的子 Agent 完成工作后主动广播结果。这种设计的好处在于系统的容错性和可扩展性：即使某个子 Agent 的响应时间较长，主管 Agent 也不会被阻塞，可以并行调度多个子 Agent 同时工作。但代价是结果汇总的时序变得不确定，需要主管 Agent 具备主动等待和收集所有子 Agent 结果的能力，这对主管 Agent 的规划能力提出了更高要求。在文章给出的「AI 日报协作任务」示例中，主管按依赖关系分三阶段执行（先获取内容→先生图→再写作），实际上是在用人工定义的顺序约束弥补了异步协作中的不确定性，这在实践中是一个务实且有效的折中方案 。

记忆系统的分层设计（短期/中期/长期）是 OpenClaw 多 Agent 架构中最具工程深度的一部分。短期记忆利用 LLM 自身的上下文窗口，中期记忆以日期为单位的事务日记（memory/YYYY-MM-DD.md），长期记忆以 MEMORY.md 存储跨会话的核心信息。这种分层的好处在于将不同生命周期的信息做了清晰的物理隔离：高频但无需持久化的信息（当前会话上下文）由上下文窗口承载，中频信息（近几天的操作记录）由文件系统承接，低频但需要长期保持的信息（用户偏好、核心规则）存入 MEMORY.md。这种设计避免了单一大一统记忆系统的维护复杂度，同时也让不同层级记忆的检索和更新策略可以独立优化。值得注意的是，作者在实践中将「记住工作流程」作为长期记忆的核心内容之一，这实际上是将 Agent 的标准操作程序（SOP）外部化为可编辑的文件，使得 Agent 行为规范的调整不需要重新训练或修改 prompt，而只需更新对应的 Markdown 文件 。

文章中对工具权限的「最小权限原则」实践也值得关注。作者明确指出「开发助手需要 ACP 协议来调度 Claude Code，这个权限对写作助手来说完全多余且有安全风险」——这说明在多 Agent 系统中，工具权限的配置不应是全局统一的，而应为每个 Agent 配置其所需的最小工具集。在 OpenClaw 中这是通过每个 Agent 独立的 tool blacklist/whitelist 实现的。在实际工程中，这意味着安全边界的设计和多 Agent 系统的设计是耦合进行的：你在定义 Agent 职能的同时就在定义它的攻击面（如果某个 Agent 被恶意 prompt 注入了，它能调用哪些工具），这是一个在系统设计早期就需要纳入架构讨论的安全视角 。

实践启示

  1. 多 Agent 系统的搭建顺序应从最痛、最高频的单点需求开始，而非追求全面覆盖。作者的路径是先生成日报（资讯助手）→需要配图（生图助手）→需要代码（开发助手）→需要投资分析（投资助手）→需要社区运营（社区助手）→写作（写作助手）→最后是主管。这种渐进式的搭建确保了每个新 Agent 的出现都是已有能力缺口的真实反映，而非预先设计的系统蓝图中的预设节点，避免了过度设计和功能冗余 。

  2. 为每个 Agent 建立独立的 SOUL.md、AGENTS.md、USER.md、MEMORY.md 四个核心文件，形成完整的人设-执行手册-用户模型-长期记忆闭环。这四个文件分别回答了「Agent 是什么角色」「Agent 怎么工作」「用户是谁」「Agent 积累了什么经验」四个根本问题，任何 Agent 的调整都应先判断修改落在哪个文件中，而非将所有配置混在一个巨大的 system prompt 中。以投资助手为例：SOUL.md 定义严谨、数据驱动、风险第一的分析原则；USER.md 定义用户是投资初学者、偏好稳健；MEMORY.md 定义具体的分析流程和数据源选择规则，职责边界清晰 。

  3. 主管 Agent（Orchestrator）的核心职责是「分派+汇总」而非「替代子 Agent 执行任务」。主管应充分了解每个子 Agent 的能力边界，以便在收到复杂任务时做出正确的分派决策。作者建议在主管的长期记忆中详细写入每个子 Agent 的功能描述和调用方式，就是为了确保分派决策的准确性。此外，主管对子 Agent 调用结果的汇总逻辑（如何处理部分子 Agent 失败的情况、如何在结果冲突时做裁决）也应在 AGENTS.md 中明确定义 。

  4. 工具权限必须按 Agent 独立配置，采用最小权限原则。在 OpenClaw 的配置中，每个 Agent 应只启用其职能必需的 Tools 和 Skills，并对 subagents 的调用范围做精确限制。开发助手需要 GitHub 和 ACP 权限，但写作助手不需要；投资助手需要 Tushare 和 a-stock-analysis 技能，但生图助手不需要。混用的工具集不仅带来安全风险（攻击面扩大），还会导致 Agent 在决策时调用错误的工具（工具选择困惑），降低系统的行为可预测性 。

  5. Skill 的复用性是多 Agent 架构可扩展的关键。作者在生图助手和投资助手的配置中都将技能抽象为独立的 SKILL.md + references/ 目录结构，使得同一技能可以被多个 Agent 调用（如两个 Agent 都可能需要联网搜索），而不是每个 Agent 都维护自己版本的同类能力。在搭建多 Agent 系统之前，应先识别所有 Agent 之间可能共享的技能（搜索、文档读写、数据获取等），优先将其封装为可复用 Skill，避免重复建设同时也减少未来维护成本 。