openclaw架构篇——多 Agent 不是银弹，是“内耗”陷阱

OpenClaw 最诱人的卖点是“多智能体协作”，但如果你以为堆砌 Agent 数量就能提升效率，大概率会陷入上下文断裂、资源内耗、权限混乱的泥潭。多 Agent 架构是泡沫重灾区，必须严格遵循“最小化”原则。

1. 架构设计：从“全能神”到“流水线”

避坑实操：单 Bot 起步，按职能拆分

新手最容易犯的错是一上来就部署 5-6 个 Agent（写作、代码、运维等），结果发现它们互相抢资源，任务还经常掉链子。

• 动作：坚持“1+1”原则。先只部署 1 个核心 Bot（Core Agent），跑通全流程。待稳定后，仅拆分出 1 个专用 Agent（如将“代码生成”独立）。两个 Agent 之间通过明确的文件路径（Workspace）或 Webhook 传递任务，严禁共享内存或混用上下文。

• 验证：用 openclaw gateway status 查看连接数，如果出现频繁重连，说明架构负载过大，需回退到单 Agent。

2. 路由规则：别让任务在“迷宫”里迷路

避坑实操：手动配置静态路由，禁用自动路由

OpenClaw 的自动路由（Intent Routing）在复杂场景下极不可靠，经常把代码任务误判给写作 Agent。

• 动作：关闭 Gateway 的自动路由功能。在 Dashboard 中手动设置静态路由表（Static Routing）。例如，明确规定 /code 开头的指令只发给 Code Agent，/write 开头的发给 Writer Agent。对于未知指令，统一路由到 Core Agent 并记录日志。

• 监控：定期检查路由日志 openclaw logs --gateway，搜索 “route mismatch” 或 “fallback”，及时修正错误的路由规则。

3. 状态隔离：防止“精神分裂”

避坑实操：物理隔离 Workspace 与 Memory

多个 Agent 共用同一个 Workspace（工作目录）和记忆文件，是导致“幻觉”和任务冲突的元凶。

• 动作：

  1. 目录隔离：为每个 Agent 创建独立的物理目录（如 ~/oc_workspace/code_agent、~/oc_workspace/writer_agent）。

  2. 记忆隔离：在 openclaw.json 中为每个 Agent 配置独立的 memoryPath。绝不允许两个 Agent 读写同一个记忆文件，否则会导致上下文错乱。

  3. 环境变量隔离：不同 Agent 使用不同的 API Key 或 Model Endpoint，避免 Token 消耗统计混乱。

4. 降级预案：当“协作”变成“死锁”

避坑实操：设置熔断机制与手动接管

多 Agent 协作一旦出现循环依赖（A 等 B 的结果，B 等 A 的输入），系统会直接卡死。

• 动作：

  1. 超时熔断：在每个 Skill 的配置中设置 timeout（如 300 秒），超时后自动终止并通知人工介入。

  2. 手动接管：在 Dashboard 中预设“紧急停止”按钮（本质是 kill 掉指定 Agent 进程），并保留一键切换为“单 Agent 模式”的能力。

多 Agent 不是简单的复制粘贴，而是严格的“分封制”。每个 Agent 必须有独立的领地（目录）、明确的职责（路由）和独立的记忆，否则它们不仅不会协作，还会互相“打架”。