在 PHP 应用中处理限流和 API 节流：扩展、防滥用的最佳实践

纠嗜勒姿一）三层物理隔离详解

1. 身份层 (Identity Layer)：定义智能体的”人格与准则”

身份层通过一组独立的配置文件，为每个智能体塑造独特的”灵魂”与行为规范，决定了智能体的性格、职责和能力边界，核心文件包括：

SOUL.md：智能体的核心人格定义，明确其性格、语气和行为准则，是智能体的”精神内核”；

AGENTS.md：智能体的工作规范与工具使用指南，规范其工作流程和操作标准；

USER.md（可选）：存储用户偏好和上下文信息，提升智能体的个性化响应能力；

agent.md：配置智能体的系统提示词、模型选择和凭证信息，是智能体的”运行基础”。

2. 状态层 (State Layer)：保障智能体的”记忆独立”

每个智能体拥有完全独立的状态存储，确保会话历史、记忆和路由状态不被混淆，具体包括：

会话历史：存储路径为 ~/.openclaw/agents//sessions/，仅该智能体可访问；

路由状态：每个智能体的消息路由独立管理，避免消息误传或混淆；

记忆存储：跨会话的长期记忆完全隔离，确保不同智能体的记忆不相互污染。

3. 工作层 (Workspace Layer)：划定智能体的”工作边界”

每个智能体拥有独立的文件系统边界，仅能访问自身工作区内的文件，避免敏感数据泄露。以下是两个典型智能体的工作区结构示例：

~/.openclaw/workspace-writer/ # 写作助手的工作区

├── SOUL.md

├── AGENTS.md

├── USER.md

├── MEMORY.md

└── memory/

└── 2025-01-04.md

~/.openclaw/workspace-coder/ # 代码助手的工作区

├── SOUL.md

├── AGENTS.md

├── MEMORY.md

└── projects/

（二）物理隔离 vs 逻辑隔离：为什么必须选物理隔离？

逻辑隔离看似配置简单，但在实际使用中会出现诸多问题，而物理隔离则能从根源上解决这些痛点，具体对比如下：

? 逻辑隔离的问题：记忆污染（不同任务上下文混合）、工具冲突（不同智能体工具权限冲突）、安全风险（敏感数据可被跨智能体访问）、成本失控（无法精准追踪单个智能体资源消耗）；

? 物理隔离的优势：数据安全（仅访问自身工作区）、记忆清晰（会话与长期记忆完全隔离）、成本可控（可单独配置模型和 API 配额）、专业分工（专注特定领域，提升效率）。

二、实操第一步：创建多个工作区，打造专业化智能体

创建多工作区的核心是通过 OpenClaw CLI 生成独立智能体，再为每个智能体配置专属的身份与工作规范，步骤清晰、可直接落地。

步骤 1：创建智能体，自动生成工作区

使用 OpenClaw 命令行工具（CLI）创建不同用途的智能体，系统会自动为每个智能体建立独立的工作区和会话存储，无需手动创建文件夹。执行以下命令：

openclaw agents add writer

openclaw agents add coder

openclaw agents add analyst

执行完成后，系统会在 ~/.openclaw/ 目录下生成以下结构，每个智能体的工作区和会话存储完全独立：

~/.openclaw/

├── agents/

│ ├── writer/

│ │ └── sessions/ # 写作助手的会话存储

│ ├── coder/

│ │ └── sessions/ # 代码助手的会话存储

│ └── analyst/

│ └── sessions/ # 数据分析的会话存储

├── workspace-writer/ # 写作助手工作区

├── workspace-coder/ # 代码助手工作区

└── workspace-analyst/ # 数据分析工作区

步骤 2：配置智能体身份（SOUL.md）

SOUL.md 是智能体的”人格说明书”，需为每个智能体单独配置，明确其核心职责、性格特点和能力边界，避免功能重叠。以下是三个典型智能体的 SOUL.md 配置示例：

1. 写作助手（~/.openclaw/workspace-writer/SOUL.md）

专注于内容创作、文案撰写和文档优化，不处理技术代码任务。

• 用词优美、生动，善用比喻和例子
• 注重文章的可读性和逻辑结构
• 对文字有洁癖，追求表达的精准

? 可以做：

• 撰写各类文章、文案、脚本
• 润色和优化已有文本
• 提供创意灵感和写作建议

? 不做：

• 代码编写和调试
• 数据分析和计算
• 系统运维任务

• 先理解需求，再动笔
• 注重细节，反复打磨
• 保持客观，避免过度修饰

openclaw docker 教程
2. 代码助手（~/.openclaw/workspace-coder/SOUL.md）

专注于代码开发、调试、重构和技术方案设计，不处理非技术类任务。

• 精通 JavaScript/TypeScript、Python、Go
• 熟悉前端框架（React、Vue）和后端开发
• 了解云原生、容器化和 DevOps 最佳实践

• 简洁清晰，注释充分
• 遵循 SOLID 原则和设计模式
• 注重性能优化和安全性
• 优先使用标准库和成熟方案

? 可以做：

• 编写、重构、调试代码
• 设计技术架构和方案
• 代码审查和最佳实践建议

? 不做：

• 文案撰写和内容创作
• 非技术类咨询
• 跨领域的通用建议

3. 数据分析助手（~/.openclaw/workspace-analyst/SOUL.md）

专注于数据处理、统计分析和可视化，提供基于数据的洞察和建议。

• 数据清洗和转换
• 统计分析和假设检验
• 数据可视化（图表、仪表板）
• 趋势预测和异常检测

• 数据驱动，避免主观臆断
• 透明展示分析过程
• 指出数据局限性和不确定性
• 用通俗语言解释技术结论

? 可以做：

• 处理结构化数据（CSV、JSON、SQL）
• 统计分析和数据挖掘
• 制作图表和报告

? 不做：

• 代码开发和部署
• 文案创作
• 非数据的业务决策

步骤 3：配置工作规范（AGENTS.md）

AGENTS.md 用于定义智能体的工作流程、质量标准和工具使用规范，确保智能体的工作符合预期。以写作助手为例，其 AGENTS.md 配置如下：

1. 理解需求：明确写作目标、受众、风格
2. 大纲规划：先列大纲，确认结构再动笔
3. 初稿撰写：快速完成，不纠结细节
4. 反复打磨：优化表达，调整节奏
5. 最终检查：校对错别字，确认格式

• 标题吸引人且准确
• 开头 50 字抓住读者
• 段落之间逻辑连贯
• 结尾有力或引发思考

• 优先使用飞书云文档协作
• 使用 Obsidian 管理笔记
• 必要时调用 summarize 工具总结资料

三、实操第二步：创建多个飞书机器人，实现独立响应

OpenClaw 支持两种多机器人配置模式，可根据使用场景选择。本文重点介绍”独立团”模式（每个智能体对应一个独立飞书机器人），角色更清晰、隔离更彻底，适合团队协作和专业化场景。

（一）两种配置模式对比

模式一：分身术（单 Bot 多路由）：适合个人用户，仅创建 1 个飞书机器人，通过路由规则分配到不同智能体，配置简单但机器人形象统一；

模式二：独立团（多 Bot 独立）：适合团队协作，为每个智能体创建独立飞书机器人，直接绑定对应智能体，角色清晰但配置工作量稍大。

（二）步骤 1：为每个智能体创建飞书应用

访问 飞书开放平台，为写作助手、代码助手、数据分析助手分别创建独立应用，每个应用对应一个飞书机器人，步骤完全一致，以下以写作助手为例：

1. 创建应用

登录飞书开放平台，点击”创建企业自建应用”；

应用名称：写作助手（建议与智能体 ID 一致，便于管理）；

应用描述：专注内容创作的 AI 助手；

上传专属头像：建议使用与角色相关的图标（如笔、文档等），区分不同机器人。

2. 配置权限

在”权限管理”中添加以下必要权限，确保机器人能正常接收和发送消息、访问相关资源：

权限名称 权限 ID 用途

接收消息 im:message 接收用户消息

接收群组@消息 im:message.group_at_msg 接收群组提醒

发送消息 im:message 发送回复消息

获取群组信息 im:chat 读取群组信息

获取用户信息 contact:user.base:readonly 识别用户身份

查看、评论云文档 docs:docs 读取和评论文档

创建云文档 docs:docs:create 创建新文档

3. 启用事件订阅

在”事件订阅”中启用”长连接接收事件”；

订阅以下两个核心事件：im.message.receive_v1（接收消息）、im.message.message_read_v1（消息已读）。

4. 获取凭证

在”凭证与基础信息”页面，获取该应用的 App ID 和 App Secret（点击”查看”可复制密钥），这两个凭证将用于后续 OpenClaw 通道配置，需妥善保存。

5. 重复创建其他机器人

按照上述步骤，分别创建”代码助手”和”数据分析助手”的飞书应用，注意：每个应用的名称、头像需区分，且会获取独立的 App ID 和 App Secret，避免混淆。

（三）步骤 2：配置机器人发布范围

创建完成后，需发布机器人才能正常使用，步骤如下：

进入每个飞书应用的”版本管理与发布”页面；

点击”创建版本”，填写简单的版本信息（如”初始版本”），点击”保存”；

在”发布管理”中选择发布范围：测试阶段选择”仅本组织”，邀请内部用户测试；正式发布选择”所有组织”，供所有用户使用。

四、实操第三步：配置通道与路由，实现智能体与机器人绑定

完成工作区和飞书机器人的创建后，需通过 OpenClaw CLI 配置通道，将每个飞书机器人与对应的智能体绑定，确保消息能准确路由到目标智能体。

步骤 1：添加飞书通道，绑定智能体

使用以下命令，为每个智能体添加对应的飞书通道，替换命令中的 App ID 和 App Secret 为你获取到的凭证：

openclaw channels add feishu

–account-id “writer-bot”

–agent “writer”

–app-id “cli_axxxxxxxxxxxxxxxx”

–app-secret “xxxxxxxxxxxxxxxxxxxx”

openclaw channels add feishu

–account-id “coder-bot”

–agent “coder”

–app-id “cli_ayyyyyyyyyyyyyyyy”

–app-secret “yyyyyyyyyyyyyyyyyy”

openclaw channels add feishu

–account-id “analyst-bot”

–agent “analyst”

–app-id “cli_azzzzzzzzzzzzzzzz”

–app-secret “zzzzzzzzzzzzzzzzzz”

参数说明：

–account-id：通道的唯一标识符（自定义，建议与机器人名称一致，便于区分）；

–agent：绑定的智能体 ID（与创建智能体时的 ID 一致，如 writer、coder）；

–app-id：飞书应用的 App ID；

–app-secret：飞书应用的 App Secret。

步骤 2：验证通道配置

通道添加完成后，执行以下命令，验证智能体与通道的绑定关系是否正确：

openclaw channels status

openclaw agents list –bindings

预期输出如下，表明绑定成功：

╔═════════════╤════════════════════════════════╗

║ Agent │ Channel Bindings ║

╠═════════════╪════════════════════════════════╣

║ writer │ feishu:writer-bot ║

║ coder │ feishu:coder-bot ║

║ analyst │ feishu:analyst-bot ║

╚═════════════?════════════════════════════════╝

步骤 3：配置路由规则（可选）

对于”独立团”模式（每个智能体对应独立机器人），添加通道时已自动完成路由配置，无需额外操作。若选择”分身术”模式（单机器人多路由），或需要更细粒度的路由控制（如同一机器人在不同群组路由到不同智能体），可手动编辑 ~/.openclaw/openclaw.json 文件，示例配置如下：

{

“agents”: {

“list”: [

{

“id”: “writer”,

“workspace”: “/Users/qiqi/.openclaw/workspace-writer”,

“model”: “claude-sonnet-4-“

},

{

“id”: “coder”,

“workspace”: “/Users/qiqi/.openclaw/workspace-coder”,

“model”: “claude-opus-4-“

},

{

“id”: “analyst”,

“workspace”: “/Users/qiqi/.openclaw/workspace-analyst”,

“model”: “claude-sonnet-4-“

}

]

},

“channels”: {

“feishu_writer”: {

“type”: “feishu”,

“accountId”: “writer-bot”,

“appId”: “cli_axxxxxxxxxxxxxxxx”,

“appSecret”: “xxxxxxxxxxxxxxxxxxxx”

},

“feishu_coder”: {

“type”: “feishu”,

“accountId”: “coder-bot”,

“appId”: “cli_ayyyyyyyyyyyyyyyy”,

“appSecret”: “yyyyyyyyyyyyyyyyyy”

},

“feishu_analyst”: {

“type”: “feishu”,

“accountId”: “analyst-bot”,

“appId”: “cli_azzzzzzzzzzzzzzzz”,

“appSecret”: “zzzzzzzzzzzzzzzzzz”

}

},

“bindings”: [

{

“agentId”: “writer”,

“match”: {

“channel”: “feishu”,

“accountId”: “writer-bot”

}

},

{

“agentId”: “coder”,

“match”: {

“channel”: “feishu”,

“accountId”: “coder-bot”

}

},

{

“agentId”: “analyst”,

“match”: {

“channel”: “feishu”,

“accountId”: “analyst-bot”

}

}

]

}

步骤 4：重启 Gateway，使配置生效

所有配置完成后，重启 OpenClaw Gateway，确保通道和路由配置生效：

openclaw gateway restart

执行以下命令，查看启动日志，确认无错误信息：

openclaw logs –tail 50

五、测试与验证：确保多智能体正常运行

配置完成后，需通过私聊、群组测试和隔离性验证，确认每个智能体能正常响应、路由准确，且记忆完全隔离。

（一）测试步骤

1. 私聊测试

在飞书中分别与三个机器人私聊，验证其响应是否符合配置的身份：

与写作助手对话：”你好，你是谁？” → 预期响应：介绍自己是专注内容创作的写作助手；

与代码助手对话：”你好，你会做什么？” → 预期响应：介绍自己是专注代码开发的代码助手；

与数据分析助手对话：”你好，你的职责是什么？” → 预期响应：介绍自己是专注数据处理的数据分析助手。

2. 群组测试

创建不同的飞书群组，邀请对应的机器人，@ 机器人测试其响应：

“内容创作群” → 邀请写作助手，@写作助手 帮我写一段产品介绍；

“技术开发群” → 邀请代码助手，@代码助手 这段代码有什么问题？；

“数据分析群” → 邀请数据分析助手，@数据分析助手 帮我分析这组数据的趋势。

预期结果：每个机器人仅响应自身职责范围内的请求，不跨领域回应。

3. 隔离性验证

验证不同智能体的记忆是否完全隔离，这是物理隔离的核心体现：

与写作助手对话：”记住，我最喜欢的颜色是蓝色”；

切换到代码助手，问：”我最喜欢的颜色是什么？”；

预期结果：代码助手回复”不知道”或类似内容，表明记忆未被污染。

（二）常见问题排查

问题 1：机器人无响应

openclaw gateway status

openclaw logs –follow

openclaw channels status –probe

问题 2：消息路由错误

openclaw agents list –bindings

openclaw doctor –fix

问题 3：机器人消息无法接收

检查飞书开放平台：确认事件订阅已启用、应用已发布、权限已审批。

六、高级配置：优化智能体性能与成本

基础配置完成后，可通过高级配置进一步优化智能体的专业性、安全性和成本控制，实现更精细的管理。

（一）为不同智能体分配不同模型

根据任务复杂度，为不同智能体选择不同的模型，平衡性能和成本。编辑 ~/.openclaw/openclaw.json 文件：

{

“agents”: {

“list”: [

{

“id”: “writer”,

“model”: “claude-sonnet-4-“,

“workspace”: “/Users/qiqi/.openclaw/workspace-writer”

},

{

“id”: “coder”,

“model”: “claude-opus-4-“,

“workspace”: “/Users/qiqi/.openclaw/workspace-coder”

},

{

“id”: “analyst”,

“model”: “claude-sonnet-4-“,

“workspace”: “/Users/qiqi/.openclaw/workspace-analyst”

}

]

}

}

成本优化建议：

日常任务（如写作、简单查询）：使用 Claude Sonnet（性价比高）；

复杂任务（如代码开发、深度分析）：使用 Claude Opus（推理能力强）；

简单查询（如快速问答）：使用 Claude Haiku（速度快、成本低）。

（二）配置独立的 API 密钥

为每个智能体配置独立的 API 密钥，便于成本追踪和配额管理，执行以下命令：

openclaw config set writer.anthropicApiKey “sk-ant-xxxxxxxxxx”

openclaw config set coder.anthropicApiKey “sk-ant-yyyyyyyyyy”

openclaw config set analyst.anthropicApiKey “sk-ant-zzzzzzzzzz”

（三）配置专属技能（Skills）

为不同智能体安装专属技能，增强其专业能力，适配具体工作场景：

openclaw skills install feishu-doc –agent writer

openclaw skills install summarize –agent writer

openclaw skills install obsidian –agent writer

openclaw skills install github –agent coder

openclaw skills install git –agent coder

openclaw skills install docker –agent coder

openclaw skills install feishu-bitable –agent analyst

openclaw skills install python –agent analyst

（四）配置沙盒隔离（高安全性需求）

对于代码助手等需要执行外部命令的智能体，启用 Docker 沙盒，避免安全风险。编辑 ~/.openclaw/openclaw.json 文件：

{

“agents”: {

“list”: [

{

“id”: “coder”,

“sandbox”: “require”,

“workspace”: “/Users/qiqi/.openclaw/workspace-coder”

}

]

}

}

七、最佳实践：打造高效、可维护的多智能体系统

要充分发挥 OpenClaw 多智能体的优势，需遵循以下最佳实践，确保系统稳定、高效、易维护。

1. 明确职责边界，避免功能重叠

每个智能体应专注于单一领域，避免功能交叉，提升响应精准度：

? 推荐设计：写作助手（文案、文档、脚本）、代码助手（开发、调试、重构）、数据分析助手（统计、可视化、报告）；

? 不推荐设计：一个智能体同时负责写作和代码、一个智能体兼顾写作和数据分析。

2. 使用描述性命名，便于管理

采用清晰、统一的命名规范，降低管理成本：

? 智能体 ID：writer、coder、analyst（直观反映用途）；

? 通道 ID：feishu-writer-bot、feishu-coder-bot（关联智能体和平台）；

? 避免使用：agent1、bot2、helper3 等无意义命名。

3. 定期备份工作区，防止数据丢失

每个智能体的工作区包含重要的配置和记忆数据，需定期备份：

tar -czf openclaw-backup-$(date +%Y%m%d).tar.gz ~/.openclaw/

0 2 * * * tar -czf /backup/openclaw-$(date +%Y%m%d).tar.gz ~/.openclaw/

4. 监控成本和性能，优化资源配置

定期查看智能体的资源使用情况，调整模型配置，控制成本：

openclaw agents list –stats

5. 渐进式部署，降低风险

不建议直接全面推广，采用分阶段部署策略，确保稳定性：

第一阶段：个人测试，验证隔离性和功能正确性；

第二阶段：小团队试用，收集反馈并优化配置；

第三阶段：全面推广，持续监控和迭代。

八、常见问题 FAQ

Q1: 一个智能体可以绑定多个飞书机器人吗？

A: 可以。这是”分身术”模式，通过 bindings 配置，一个智能体可绑定多个飞书机器人，根据群组或用户进行消息路由。

Q2: 如何实现智能体之间的协作？

A: 有三种方式：① 共享群组：多个智能体加入同一个群组，通过 @ 不同机器人协作；② sessions_send 工具：实现智能体间的消息传递；③ SubAgent 模式：主智能体可生成子智能体执行具体任务。

Q3: 可以混合使用不同的通讯平台吗？

A: 可以。OpenClaw 支持同时连接飞书、Telegram、Discord 等多个平台，每个平台的账户可路由到不同智能体。

Q4: 如何迁移现有的单智能体到多智能体？