用 OpenClaw 搭建一人公司：10 个 AI Agent，0 个员工，24 小时自动开工

昨天晚上 11 点，翔宇关了电脑去睡觉。今天早上 8 点醒来，打开通讯平台一看：情报部已经采集完今天的 AI 行业热点，微信部根据热点写好了一篇深度长文初稿，课程部把最新的工具测评整理成了教学大纲，研发部审查完了昨天提交的代码——全部自动完成，没人值班。

不是请了实习生，是 10 个 AI Agent 在 OpenClaw（开源多 Agent 编排框架）里跑了一夜。

一个开源工具，10 个各司其职的 AI 员工，24 小时自动开工。这篇文章，翔宇把搭建这套系统的完整思路和架构选型全部拆开讲。

要点速览

• OpenClaw 是开源多 Agent 编排框架，让多个 AI Agent 像公司部门一样 24 小时协作
• 翔宇部署了 10 个 Agent（小红书/微信/视频/课程/研发/情报等），每个有独立身份、记忆和技能
• 三级通信体系：shared/inbox 文件委派（最可靠）+ sessions_spawn 即时派发（最快）+ message 公告（仅通知）
• 6 种架构模式对比，翔宇选了 1:1 专职模式——每 Agent 一个 Channel，专精胜通才
• 建议从 1 个 Agent 起步，逐步扩展到 10 个，不要追求一步到位

你的 AI 是不是也在"摸鱼"

你有没有这种经历——让 AI 助手写完小红书笔记，接着写公众号文章，它把种草语气带过来了。你说"别用那种语气"，它说"好的"，下一段又犯。

问题不是 AI 不行，是你让一个 AI 同时干了 10 个部门的活。

换个角度想：你见过哪家公司的 CEO 亲自写文案、亲自修 Bug、亲自追热点、亲自剪视频吗？不会对吧。正常公司的做法是：分部门，每个部门各司其职。

那为什么你的 AI 不能也分部门？

回顾 AI 的进化路径：2023 年我们跟 AI 对话，2024 年我们把对话编排成工作流，2025 年工作流沉淀为可复用的 Agent——到 2026 年，下一步自然是：让一群 Agent 像公司一样 24 小时自动协作。

这正是 OpenClaw 在做的事。这个开源项目在 GitHub 上火得一塌糊涂，名字取自小龙虾的钳子——多只钳子协同作业，恰好就是多 Agent 协作的隐喻。

借鉴公司治理框架：用 OpenClaw 让 AI 像公司一样运转

翔宇的思路很简单：成熟公司怎么治理，AI 就怎么治理。分部门、定职责、设流程、各司其职。 于是用 OpenClaw 部署了 10 个 Agent，直接套用公司的组织架构：

这不是闹着玩的——这 10 个 Agent 真的在 24 小时自动运行。在 OpenClaw 里，每个 Agent 有自己的 Channel（独立频道），有自己的 SOUL.md（身份定位文件），有自己的 MEMORY.md（独立记忆系统），甚至还有 Heartbeat（心跳巡检机制）——每 55 分钟自动巡检一次收件箱，看看有没有其他部门委派的任务。

OpenClaw 就是让这一切运转的基础设施。

OpenClaw 是什么：AI 公司的操作系统

💡 划重点

OpenClaw 是一个开源的多 Agent 编排框架。它让你在一台电脑上同时运行多个 AI Agent（智能体），每个 Agent 有独立身份、独立记忆、独立技能，并通过 Discord（一个海外团队通讯平台，类似企业微信）来跟它们对话。

用一句话说：OpenClaw 是 AI 公司的操作系统。

它做 4 件事：

• Agent 管理：注册 Agent、定义身份（SOUL.md）、分配技能（TOOLS.md）
• 消息路由：你在哪个 Channel 说话，消息就自动路由到绑定的 Agent
• Agent 协作：Agent 之间通过文件委派、sessions_spawn（即时派发）互相派发任务
• 记忆持久化：每个 Agent 的 Session（会话）独立存储，MEMORY.md 跨会话保留经验

关键认知：OpenClaw 本身不是 AI——它是 AI 的编排层（Orchestration Layer，协调调度层）。真正干活的是大语言模型，OpenClaw 负责让它们各司其职、协同工作。

OpenClaw 的核心配置文件是 openclaw.json，所有 Agent、Guild（群组）、Binding（绑定）、Heartbeat（心跳）配置都在这一个文件里定义。一个文件，管一家公司。

📦 这篇文章翔宇讲思路和架构选型。 完整的 openclaw.json 配置文件、每个 Agent 的 SOUL.md 模板、搭建录屏都在翔宇的「AI 编程实操课」里——文末有入口。

OpenClaw 的 5 个核心概念：Agent / Guild / Channel / Binding / Session

要用 OpenClaw 搭建多 Agent 系统，你需要理解它的 5 个核心概念。翔宇用"开公司"做类比，保证你一看就懂。

Agent（智能体）= 员工

一个 Agent 就是一个独立的 AI 助手。在 OpenClaw 里，每个 Agent 有三样独有的东西：

• SOUL.md（身份定位文件）——相当于岗位职责说明书。写着它是谁、负责什么、行为准则是什么
• MEMORY.md（工作记忆）——相当于工作笔记本。只记录自己领域的经验，跨会话保留
• TOOLS.md（技能清单）——相当于工具箱。小红书 Agent 会用小红书发布工具，研发 Agent 会用代码执行工具

在 openclaw.json 里，Agent 通过 agents.list（智能体列表）数组定义，每个 Agent 有唯一 ID（如 main、xhs、wechat）。

Guild（群组）= 公司

在通讯平台里，一个 Guild（群组）就是一个 Server（服务器）。你可以理解为你的"AI 公司"的物理空间。

翔宇的 AI 公司就是通讯平台上的一个 Server，在 openclaw.json 里通过 guilds 配置注册。OpenClaw 支持 allowlist（白名单）模式，只有授权频道才能触发 Agent。

Channel（频道）= 办公室

Guild 里面有很多 Channel，每个 Channel 就是一个"办公室"。翔宇有 10 个 Channel，分别对应 10 个部门。你走进哪个 Channel，就跟哪个 Agent 对话。

Channel 在 OpenClaw 中不仅是消息入口，更是上下文边界——同一个 Channel 的对话共享 Session，不同 Channel 的 Session 完全隔离。

Binding（绑定）= 门牌号

Binding 是 OpenClaw 的路由规则——它把 Channel 和 Agent 关联起来。在 openclaw.json 的 bindings 数组里配置：{ kind: "channel", channelId: "xxx", agentId: "xhs" }。

有了 Binding，OpenClaw 就知道这个 Channel 的消息该交给谁。

🎯 一句话理解：Binding 是纯配置路由，不需要 AI 参与判断。所以路由零误差——你不会走进小红书的 Channel，结果出来一个修 Bug 的 Agent。

Session（会话）= 对话记忆

Session 是一次对话的上下文容器。你跟小红书 Agent 聊的所有内容，都存在这个 Session 里。

最关键的一点：每个 Agent 的 Session 是完全隔离的。 OpenClaw 的 Session Key 格式是 agent:::group:，天然按 Agent + Channel 分离。

这意味着什么？小红书 Agent 只能看到你在小红书 Channel 说的话，它看不到你在研发 Channel 跟研发 Agent 聊了什么。隔离保证了专注。

一张图看清 OpenClaw 的概念体系

10 个 Agent，各管一摊

很多人问翔宇：10 个 Agent 真的有必要吗？3 个不够吗？

翔宇的回答是：看你的业务有几条线。

翔宇的业务有 5 条内容线（小红书、微信、海外社媒、视频、课程）+ 3 条支撑线（研发、情报、运维）+ 2 条管理线（总部、行政）= 10 个明确的职能。

在 OpenClaw 里，每个 Agent 只做一件事，带来三个好处：

第一，SOUL.md 不打架。 xhs Agent 的 SOUL.md 写着"活泼有趣、善用 emoji、标题要有钩子"；wechat Agent 的 SOUL.md 写着"专业深度、逻辑严密、术语要加注释"。两套完全不同的写作人格，绝不会互相污染。

第二，MEMORY.md 不串台。 xhs Agent 的记忆里只有小红书运营经验——哪些标题格式容易爆、什么时间段发布效果好、哪些话题最近热门。它不会突然跟你聊 Bug 修复。

第三，能同时干活。 你在小红书 Channel 跟 xhs Agent 写笔记的同时，intel Agent 正在自动采集热点，rnd Agent 正在审查代码。OpenClaw 的 subagents.maxConcurrent（最大并发数）配置支持最多 8 个 Agent 同时并行执行。

📌 记住这点：Agent 的"专业度"不是天生的，而是你通过 SOUL.md（身份）+ MEMORY.md（记忆）+ TOOLS.md（技能） 三者组合塑造出来的。一个什么都干的通才 Agent，永远比不上一个只做一件事的专精 Agent。这就是 OpenClaw 多 Agent 架构的核心价值。

OpenClaw 的三级通信体系：Agent 之间怎么协作

10 个 Agent 各管各的，但业务是交叉的。intel Agent 采集完热点，xhs Agent 要拿去写笔记；xhs Agent 写完笔记，rnd Agent 要帮忙审查质量。

OpenClaw 怎么让 Agent 之间互相协作？翔宇基于 OpenClaw 的能力设计了三级通信体系，每一级对应 OpenClaw 的不同机制。

Level 1：shared/inbox 文件委派——放一份文件到对方桌上

这是最可靠的方式，利用 OpenClaw 的 workspace（工作区）共享目录。

发起 Agent 写一个任务文件，放到 shared/<目标>/inbox/ 目录。目标 Agent 的 Heartbeat（心跳机制）每 55 分钟自动巡检一次 inbox，发现文件后读取、执行、完成后写回执到 archive/。全程异步，不依赖对方是否有活跃 Session。

• 优点：100% 可靠、有完整的文件审计链、支持离线异步
• 缺点：最慢可能要等 55 分钟（Heartbeat 间隔）
• 适用场景：复杂任务、需要详细上下文、不急的正式任务

Level 2：sessions_spawn 即时派发——给对方打个电话

当你需要立刻得到结果时，用 OpenClaw 的 sessions_spawn。系统会自动为目标 Agent 创建一个临时 Session，目标 Agent 马上执行，完成后结果自动 announce（广播回传）到发起方的 Channel。

关键优势：不需要目标 Agent 有活跃 Session，OpenClaw Gateway（网关）自动创建。

• 优点：即时响应、不需要对方在线
• 缺点：spawn（派发）深度上限 2（OpenClaw 配置 maxSpawnDepth: 2，即最大派发深度为 2），不适合复杂多轮任务
• 适用场景：简单任务、当场要结果的查询

Level 3：message 公告通知——在 Channel 留个言

通过 OpenClaw 的 message 工具在 Channel 发一条消息。仅供人类查看。

注意：这种方式不会触发目标 Agent 做任何事。 它只是在 Channel 里留了一条消息。

• 适用场景：公告、进度提醒、sessions_spawn 失败时的兜底

怎么选：一句话决策

🎯 一句话理解：默认用 shared/inbox（正式任务）。一句话能说清、当场要结果？用 sessions_spawn。只给人看、不需要 Agent 动？用 message。

实战：一句话触发 5 个 Agent 协作

光讲概念太抽象。翔宇用一个真实的工作流展示 OpenClaw 的 10 个 Agent 怎么协作。

场景：全平台发布一篇 AI 工具推荐

第一步：翔宇在 main Channel 说"今天的主题是 AI 视频工具推荐，先让情报部采集素材，然后小红书、微信、海外社媒各写一篇。"

第二步：main Agent 开始调度

main Agent 分析这句话，拆解为 4 个子任务，选择合适的通信 Level：

第三步：intel Agent 执行采集

OpenClaw Gateway（网关）为 intel Agent 创建临时 Session。intel Agent 开始全网搜索 AI 视频工具的最新动态、用户评价、价格对比。完成后，结果通过 announce（广播回传）自动回传给 main Agent。

第四步：三路并行创作

main Agent 拿到素材后，同时发起三个 sessions_spawn：

• xhs Agent 开始写笔记（活泼有趣、配图建议、话题标签——按其 SOUL.md 人格）
• wechat Agent 开始写长文（深度分析、横向对比——按其 SOUL.md 人格）
• social Agent 开始写海外社媒内容（精炼英文、社群话题——按其 SOUL.md 人格）

三个 Agent 同时执行，互不干扰。 OpenClaw 的 maxConcurrent: 8（最大并发 8 个）配置保证并行无压力。总时间 = 最慢那个 Agent 的时间，而不是三个加起来。

第五步：结果汇总

三个 Agent 陆续完成，结果都通过 announce（广播）回传到 main Channel。main Agent 播报："小红书笔记已完成、公众号文章已完成、推文已完成。"

翔宇在 main Channel 就能看到所有成果，不需要挨个 Channel 去翻。

💡 划重点：整个过程翔宇只说了一句话。OpenClaw 调度了 5 个 Agent（main 调度、intel 采集、xhs + wechat + social 三路创作），全程自动化。如果手动做，同样的事情至少要 2 小时。

🎯 想直接拿到这套工作流的完整配置？ 10 个 Agent 的 openclaw.json、SOUL.md 模板、三级通信调试方法——翔宇都整理在了「AI 编程实操课」里，见文末。

OpenClaw 支持的 6 种多 Agent 架构

同样是用 OpenClaw 编排多个 Agent，组织方式可以完全不同。核心变量就两个：Agent 数量和 Binding（路由）策略。翔宇穷举了 6 种架构。

模式 A：单 Agent——一个 Agent 管所有事

OpenClaw 配置：agents.list 只有 1 个 Agent，所有 Channel 的 Binding 都指向它。

• 优点：零协调成本，openclaw.json 配置最简单
• 缺点：SOUL.md 指令冲突、MEMORY.md 记忆污染、无法并行——你让它写笔记的时候，其他任务只能排队

💬 通俗讲：就像让一个人同时接 10 个电话——理论上能做到，实际上每个电话的质量都很差。

适合谁：只有 1-2 个简单需求的个人用户。

模式 B：1:1 专职——每 Agent 一个 Channel（翔宇在用）

OpenClaw 配置：agents.list 有 10 个 Agent，bindings 数组 10 条记录，每条 { kind: "channel", channelId: "xxx", agentId: "yyy" } 一对一绑定。

• 优点：SOUL.md 专精、Session 隔离、并行处理、故障隔离（一个 Agent 挂了不影响其他）
• 缺点：配置量大（每个 Agent 需要 SOUL.md + MEMORY.md + TOOLS.md + HEARTBEAT.md）、Heartbeat 巡检消耗 Token

💬 通俗讲：就像一家正规公司——每个部门各有各的办公室和分工，互相独立但可以通过三级通信协作。

适合谁：多领域业务、需要专业化分工、任务量大。这是 OpenClaw 的推荐架构。

模式 C：N:1 共享——多个 Channel 共享一个 Agent

OpenClaw 配置：agents.list 只有 4 个 Agent，bindings（绑定配置）中多个 Channel 指向同一个 Agent。例如小红书 + 微信 + 海外社媒 + 视频四个 Channel 都绑定到一个 content Agent。

• 优点：Agent 数量少、Heartbeat（心跳巡检）和 Token 开销降低 60%
• 缺点：一个 Agent 的 SOUL.md 要覆盖多个平台策略，专业度下降；同 Agent 的 Channel 之间无法并行

💬 通俗讲：就像一个合伙人管所有内容平台。省钱但不够精细。

适合谁：资源有限、领域相近的业务。

模式 D：层级制——加一层 VP Agent

OpenClaw 配置：在模式 B 基础上增加 3 个 VP Agent（内容线 VP、技术线 VP、运营线 VP），main Agent 通过 sessions_spawn（即时派发）只调度 3 个 VP，VP 再 spawn（派发）给下属 Agent。总共 13 个 Agent、13 个 Channel。

• 优点：main Agent 从管 9 人变成管 3 人；VP 可以做质量审查
• 缺点：多 3 个 Agent 的开销、spawn 链多一层延迟（需要注意 maxSpawnDepth: 2，即最大派发深度为 2 的限制）

💬 通俗讲：就像大公司的组织架构——CEO → VP → 部门经理。适合 Agent 很多的时候。

适合谁：Agent 数量超过 15 个、需要审查层的大规模部署。

模式 E：@mention 路由——同一个 Channel @谁谁来

OpenClaw 配置：1 个 Channel，10 个 Agent 都绑定到这个 Channel。通过 OpenClaw 的 mentionPatterns（提及匹配规则）分流——每个 Agent 配置 groupChat.mentionPatterns: ["@xhs", "@小红书"]，收到 @ 时才响应。设置 requireMention: true（需要 @ 才响应）。

比如你发"@xhs 写个笔记"，xhs Agent 响应；发"@intel 查个热点"，intel Agent 响应。

听起来很方便？但有一个致命问题——上下文碎片化。每个 Agent 的 Session（会话）只能看到你 @ 它的那几条消息。你跟 xhs Agent 聊了 3 句，中间穿插了跟 intel Agent 的 2 句，xhs Agent 只看到 3 句，完全不知道你们之间还聊了别的。

而且，你每句话都要加 @。忘了 @ 就没 Agent 响应。

⚠️ 重要提示：模式 E 最大的坑：所有对话混在一个 Channel 里，一周后你回来翻记录，根本分不清哪句是跟哪个 Agent 说的。OpenClaw 的 Session 隔离在这个模式下反而成了问题——隔离太彻底，导致每个 Agent 都只看到碎片。

适合谁：Channel 数量受限的平台、个人轻量使用。

模式 F：Supervisor（总调度）单入口——一个 Channel，main Agent 做路由

OpenClaw 配置：1 个 Channel 只绑定 main Agent。main Agent 分析你说的话，通过 sessions_spawn（即时派发）把任务自动分发给对应 Agent。

你说"写个小红书笔记"，main Agent 判断"这是 xhs 的事"，自动 spawn（派发）给 xhs Agent。你不需要切 Channel，不需要 @。

听起来是最省事的？代价也很大。

第一，main Agent 是绝对瓶颈——所有消息串行经过它。

第二，路由判断依赖 AI 理解——你说"这个内容能发到海外社媒吗"，main 可能误 spawn（派发）给 social Agent。

第三，目标 Agent 没有上下文——xhs Agent 只收到 main 转发的一句 task（任务）描述，看不到你和 main 之间的完整 Session。

💬 通俗讲：就像公司只有一个前台，所有客户都通过前台转接。前台很忙，偶尔还会接错线。

适合谁：不想管路由、任务以简单指令为主的用户。

我踩过的 3 个大坑（和 OpenClaw 的解法）

翔宇在搭建这套系统的过程中，踩了不少坑。分享 3 个最痛的教训，帮大家避雷。

坑一：sessions_send 传话失败

最早翔宇用 OpenClaw 的 sessions_send（消息发送）让 Agent 之间通信。结果发现——目标 Agent 没有活跃 Session 时，消息无处投递，直接丢了。

OpenClaw 的解法：改用 sessions_spawn 替代 sessions_send。spawn（派发）不需要目标有活跃 Session，Gateway（网关）自动创建临时 Session。再加上 shared/inbox 文件委派作为兜底——哪怕 spawn 也失败了，文件还躺在 inbox 里，Heartbeat 巡检时一定会被拾取。

📌 记住这点：不要依赖单一通信方式。翔宇的三级体系（shared/inbox + sessions_spawn + message）就是为了冗余——一种挂了，另一种兜底。

坑二：message 发出去了，但 Agent 没反应

翔宇用 message 工具给 intel 的 Channel 发了一条："热点素材已更新"。结果等了半天，intel Agent 毫无反应。

后来才搞明白：message（Level 3）是 OpenClaw 的"人类通知"工具，不会触发 Agent 执行任务。它只是在 Channel 里留了一条消息，翔宇自己能看到，但 Agent 不会因此启动任何操作。

如果需要 Agent 主动响应，应该用 sessions_spawn（Level 2）。

坑三：10 个 Channel 管理起来很乱？

有人觉得 10 个 Channel 太多了。翔宇的答案是：10 个 Channel 远比 1 个 Channel 清晰。

在通讯平台的左侧栏，10 个 Channel 一目了然。切 Channel 只需要点一下。你可以清楚地看到每个 Agent 最近在干什么，消息按部门分类，不会混杂。

反过来，如果所有对话挤在一个 Channel 里，一天下来几百条消息，你根本找不到上周 intel Agent 的采集报告在哪儿。

在 OpenClaw 里，Channel = 上下文边界 = Binding 路由 = Session 容器。 这四个概念在模式 B 里天然统一，这就是它好用的根本原因。

翔宇的选择与上手路径

翔宇选了模式 B（1:1 专职），核心原因就一个：切 Channel 的成本是一次点击，换来的是每个 Agent 都有完整的 Session 上下文、干净的 MEMORY.md、专精的 SOUL.md。 这笔买卖太划算了。

OpenClaw 架构设计的核心取舍：你的方便（少切 Channel）vs Agent 的能力（完整上下文）。翔宇选了后者。

但不要被 10 个 Agent 吓到。翔宇的建议：从 1 个 Agent 开始，逐步扩展。

翔宇知道，看完这篇文章很多人会想：我也想试试，但 10 个 Agent 一上来太多了。翔宇的建议：从 1 个 Agent 开始，逐步扩展。

关键心态：不要追求一步到位。翔宇自己也是从 4 个 Agent 起步，运行了一段时间后才扩展到 10 个。

🔧 实操技巧：判断什么时候需要拆分：当你发现一个 Agent 的 SOUL.md 超过 100 行，或者你经常要对它说"别用那种语气、用这种语气"——就说明它在做两件冲突的事，该拆成两个 Agent 了。

翔宇的判断

很多人把 AI 当工具用——用完即弃，下次从头来过。但翔宇的做法不一样。翔宇把 AI 当员工养——给它身份、给它记忆、给它成长空间。 时间越长，它越了解你的业务，越能产出高质量的内容。

翔宇下一步要做的事：加一个 CEO Agent。它的职责不是执行具体任务，而是根据 10 个部门积累的 MEMORY.md，自动识别哪些流程已经成熟、哪些环节还需要人介入，然后把成熟的流程固化成自动化规则——不再需要翔宇下指令，公司自己运转。

想想看：每个 Agent 的 MEMORY.md 里沉淀着数百次任务的经验——什么选题容易爆、什么时间发布效果好、什么代码模式容易出 Bug。这些记忆不是聊天记录，是公司的核心资产。 随着记忆越来越丰富，流程越来越沉淀，这家 AI 公司会从"半自动"走向"全自动运营"。

10 个 Agent，24 小时在线，全年无休、状态稳定、随叫随到。记忆在增长，流程在进化。这不是未来，这是翔宇用 OpenClaw 正在搭建的日常。

而这一切的起点，只是一个命令：openclaw init。

⚠️ 最后叠个甲：多 Agent 现阶段的 Token 成本确实不低，实际运营需要合理调度来控制开销，这部分不是今天的主题。但模式跑通后，一个人撬动 10 个部门 24 小时产出，成本相对效益不言自明——何况 AI 推理成本过去一年已降了 10 倍不止，趋势只会更便宜。

更重要的是：理解多 Agent 协作架构，就是在理解 AI 的发展方向。 掌握这套思维，等成本降下来那天，你就是第一批能直接用上的人。

这篇文章翔宇讲了架构思路和设计选型——但真正落地时，你还需要这些东西：

• 完整的 openclaw.json 配置文件（10 个 Agent 的真实配置，不是示意图）
• 每个 Agent 的 SOUL.md / MEMORY.md / TOOLS.md 模版（拿来改两行就能用）
• 三级通信体系的调试方法（Heartbeat 不触发、spawn 丢消息怎么排查）

这些内容翔宇都整理在了「翔宇工作流:AI 编程实操课」里。不是泛泛而谈的概念课，是翔宇每天在用的真实配置——你拿到手，改成自己的业务线，直接跑起来。

下一步

• AI 编程实操课：国内版-FlowUS | 国际版-BMC
• YouTube 频道：翔宇工作流