夜雨聆风OpenClaw 不能做什么？了解边界才能用得更好
任何工具都有边界，OpenClaw 也不例外。了解它能做什么、不能做什么，才能避免踩坑，也能知道什么时候该换其他方案。
架构层面的限制
1. 单 Gateway 设计
现状： 一台机器只能运行一个 Gateway 实例
类比： 就像一台路由器只能有一个 WiFi 网络（虽然可以有多个频段，但本质是一个设备在管）
影响：
• 不能在同一台机器上运行两个完全独立的 OpenClaw
• 如果需要完全隔离（比如两个公司共用一台服务器），只能用 Docker 或虚拟机
workaround：
物理机
├── Docker 容器 A（公司 A 的 OpenClaw）
└── Docker 容器 B（公司 B 的 OpenClaw）
2. 国内云部署方案
现状： 目前国内已有多家平台提供一键部署 OpenClaw 的云服务
| KimiClaw | ||
| Qclaw | ||
| ClawHub 云服务 |
优势：
• ✅ 无需自己维护服务器
• ✅ 一键部署，5分钟上线
• ✅ 内置国内网络优化
• ✅ 自动更新和维护
限制：
• 数据存储在第三方服务器（敏感数据需谨慎）
• 部分高级自定义功能受限
• 可能需要付费订阅
选择建议：
• 个人尝鲜 → KimiClaw（免费额度足够）
• 小团队使用 → Qclaw（性价比高）
• 企业级需求 → 自建或联系官方定制
3. 飞书的单会话限制
现状： 一个 Gateway 只能控制一个飞书会话
类比： 就像一台电脑只能登录一个微信（虽然可以切换，但不能同时在线）
影响：
• 不能同时用两个飞书账号
• 如果需要多账号，必须配置多账户（multi-account）
解决方案：
{
channels:{
feishu:{
accounts:{
personal:{/* 个人号 */},
business:{/* 工作号 */}
}
}
}
}
功能限制
1. 实时音视频
不能做的：
• ❌ 语音通话
• ❌ 视频通话
• ❌ 实时屏幕共享
能做的：
• ✅ 发送语音消息（先录音，再发送）
• ✅ 视频文件传输
• ✅ 截图分享
为什么？
OpenClaw 本质上是"文字消息"的桥梁，不是实时通信工具。语音/视频通话需要完全不同的技术栈（WebRTC 等）。
替代方案：
如果确实需要语音交互，可以：
• 使用 OpenClaw 的 TTS（文字转语音）功能
• 配合其他语音助手（Siri、Google Assistant）
2. 大文件处理
限制：
• 各聊天应用有自己的文件大小限制（飞书 2GB、微信 25MB 等）
• OpenClaw 本身不存储文件，只是转发
实际影响：
• 不能通过 OpenClaw "处理" 一个 10GB 的视频文件
• 不能让它 "分析" 一个超大的日志文件（如果超过上下文限制）
workaround：
你：分析这个 5GB 的日志文件
AI：文件太大，我无法直接处理。建议：
1. 先用 grep 筛选出错误行：grep "ERROR" log.txt > errors.txt
2. 把 errors.txt 发给我分析
3. 长期自主运行
不能做的：
• ❌ "帮我监控服务器，有问题就通知我"（7×24 小时持续监控）
• ❌ "每隔 5 分钟检查一次邮件"
能做的：
• ✅ Cron 定时任务（最短 1 分钟间隔）
• ✅ Webhook 触发（收到外部事件时响应）
为什么？
OpenClaw 是"事件驱动"的，不是"持续运行"的。它不会主动"盯着"什么东西看，只能被动响应消息或定时触发。
workaround：
{
cron:{
jobs:[
{
id:"monitor",
schedule:"*/5 * * * *",// 每 5 分钟
prompt:"检查服务器状态，如果有异常发送告警"
}
]
}
}
企业级功能的缺失
1. 用户管理系统
没有的：
• 用户注册/登录界面
• 权限分级（管理员/普通用户/访客）
• 用户组管理
现状：
OpenClaw 只有简单的 allowlist/pairing，没有复杂的 RBAC（基于角色的访问控制）。
影响：
不适合大型企业的复杂权限需求。
workaround：
通过多 Agent + 路由规则模拟：
{
bindings:[
// 高管 → 高级 Agent
{agentId:"executive",match:{peer:{id:"ou_ceo"}}},
// 员工 → 普通 Agent
{agentId:"employee",match:{channel:"feishu"}}
]
}
2. 审计和合规
没有的：
• 完整的操作审计日志
• 数据保留策略自动化
• 合规报告生成
现状：
虽然有日志，但需要自己处理和分析。
3. SLA 保障
现状：
• 没有商业支持合同
• 没有 99.9% 可用性保证
• 出问题需要自己排查或等社区修复
适合： 个人、小团队、技术能力强的组织
不适合： 对稳定性要求极高的大型企业
性能边界
1. 并发处理
默认配置：
{
agents:{
defaults:{
maxConcurrent:4// 同时处理 4 个请求
}
}
}
实际意义：
• 如果 10 个人同时发消息，后 6 个需要排队
• 对于个人使用完全够用
• 对于大群（1000+ 人）可能不够用
2. 响应延迟
正常情况：
• 简单问答：2-5 秒
• 需要工具调用：5-15 秒
• 复杂任务（写代码）：30 秒-几分钟
瓶颈：
• 主要是 AI API 的响应时间
• OpenClaw 本身的处理很快（毫秒级）
3. 扩展性
不能做的：
• ❌ 水平扩展（多个 Gateway 负载均衡）
• ❌ 自动扩容
能做的：
• ✅ 垂直扩展（换更强的服务器）
• ✅ 多实例分片（不同用户连不同 Gateway）
技术门槛
1. 需要的能力
基础要求：
• 会用命令行
• 能理解 JSON 配置
• 有 Linux/服务器基础知识
进阶要求：
• 会写简单的脚本（Shell/Python）
• 了解 Docker（如果用沙箱）
• 能排查网络问题
2. 维护成本
需要定期做的：
• 更新 OpenClaw 版本
• 检查日志，排查问题
• 管理 API 密钥和余额
• 备份配置文件
类比： 就像自己维护一台服务器，不是"开箱即用、永不操心"。
什么时候不该用 OpenClaw？
场景 1：大型企业需要合规
表现：
• 需要 SOC2/ISO27001 认证
• 需要完整的审计日志
• 需要 99.99% SLA
建议： 用企业级方案（Microsoft Copilot、企业版 Claude）
场景 2：只需要简单聊天
表现：
• 就在手机上偶尔用用
• 不需要多平台同步
• 不在意数据隐私
建议： 直接用官方 App 更简单
场景 3：需要复杂工作流
表现：
• 需要可视化的流程编排
• 需要连接 100+ 个 SaaS 服务
• 需要条件分支、循环等复杂逻辑
建议： 用 n8n、Make 等工作流工具
边界总结表
| 部署 | ||
| 通道 | ||
| AI | ||
| 自动化 | ||
| 企业 | ||
| 技术 |
了解边界的好处
1. 避免失望
知道不能做什么，就不会期待落空。
2. 正确选型
在正确的场景用正确的工具。
3. 合理 workaround
知道边界后，可以想办法绕过或替代。
4. 贡献改进
了解限制后，可以向社区提出改进建议，甚至自己开发插件。
结语
OpenClaw 不是万能的，但它在"自托管多通道 AI 网关"这个细分领域做得非常好。
关键是：在适合的场景用它，不适合的场景换别的。
下一篇预告：《OpenClaw vs 其他方案：Claude Code、n8n、ChatGPT，我该选哪个？》
我们将全面对比各种 AI 工具，帮你做出最适合自己的选择。