微光札记

折腾 OpenClaw 🦞 这两月，真正拉开差距的不是模型，而是配置。

磨刀不误砍柴工。

公众号原文
今天和你聊聊我这两月折腾小龙虾的血泪史。
说起来，很多人看 OpenClaw，第一眼看到的是“能不能干活”。
我最早也是这么看的。
刚发布那会儿（Clawdbot 阶段），X上面的新闻里基本都是“能帮我做什么”，很少有人认真聊安全边界、权限、网关稳定性、记忆开销这些“脏活累活”。
但这几个月一路踩坑下来，我的结论很简单：
同样是 OpenClaw，有人像小龙虾一样飞快执行，有人像二傻子一样反复抽风，差别常常不在提示词，而在配置和系统设计。
这篇就不聊玄学，聊我自己从云端到本地、从 Telegram 到飞书再到 Discord 的实战经验。

01.
我的折腾历史：从“先跑起来”到“稳定可控”
图片

我自己的路线大概分三段：
第一段是过年后回到工位，先在阿里云买服务器，远程连上去装 OpenClaw；
第二段是直接用官方安装好的配置，先快速验证链路；
第三段是回到 MacBook Pro 本地，把核心工作流迁回本地可控环境。
期间我也试了几套模型套餐和工具链，包括 Kimi Code、百炼等。
如果只看“能不能运行”，第一段就够了。
但如果你要长期跑、多 Agent 并发跑，而且要把风险压住，第三段（本地可控 + 云上补位）会更踏实。

02.
先定架构：一个实例 vs 多实例，不要上来就“堆规模”
图片

前几天傅盛直播里提到他和“三万”（OpenClaw 实例）做多 Agent 协作，这个方向我非常认同：
把任务拆成多个 Agent，做分工和流转，效率通常比单 Agent 高。
但我的建议是：新手不要一上来就多实例。
更稳的路径是：先用一个实例，先把 Agent 角色边界、会话隔离、审批和回滚机制跑顺；再逐步扩到多实例（比如写作、研发、运营分开）。
我自己现在主要是“单实例 + 多 Agent”模式，已经能覆盖大多数工作场景。

03.
模型怎么选：贵模型不一定最省钱，但常常最省总成本
图片

很多人只盯着 API 单价，这是个常见误区。
你要算的是“总成本”：
反复改配置、重启网关、修幻觉、返工代码、人工兜底，这些时间都要算钱。
我的经验是：主调度 Agent 用更强模型（比如 Sonnet/Opus 档）通常更稳，执行型 Agent 可以混用便宜模型。
这个“强模型做调度，便宜模型做执行”的组合，在多 Agent 场景下性价比更高。
至于本地模型，我最近测过 Qwen3.5-9B 一段时间。直接卡死（记忆太多占满了上下文导致无法运行）
至于其他的（比如14B以上的），并不是不能用，而是当任务上下文和记忆负担上来后，响应稳定性和吞吐会明显掉，维护成本会上升。
如果你是生产向任务（持续交付、多人协作），当前阶段我不建议把本地小模型当主力。

04.
通道怎么选：飞书功能强，但 Discord 的效率更高
图片

我最早用 Telegram，那时候配置非常轻。
后来迁到飞书，做了多 Agent + 多 Bot 映射，结果大头时间都花在权限和接入细节上。
比如飞书这类企业通道，你需要把事件订阅、权限、回调链路一项项打通。
在我的本地日志里，2026-03-05 仍能看到大量 Feishu WebSocket 长连接初始化和策略告警。
再后来我切到 Discord，体感是：配置路径更直，频道模型更适合任务并行，临时开子频道跟进新任务也不会打断原上下文。
当然，Discord 也不是没坑。
我在网关错误日志里，连续看到两类典型问题：
1) 端口冲突：`another gateway instance is already listening on ws://127.0.0.1:18789`
2) 网关拉起失败：`Failed to get gateway information from Discord: fetch failed`
所以别神化任何通道，关键是你有没有把“排错路径”标准化。

05.
安全配置：别追求“绝对安全”，先做到“可控安全”
图片

从 Clawdbot 到现在 OpenClaw 一天一个版本，安全策略明显在加速收紧。
我的态度是：权限太大会失控，权限太小会瘫痪。
真正可用的是“分层权限”而不是“一刀切”。
我自己的最小实践是这几条：
  1. 端口不要用默认暴露口，至少做基础隔离和访问限制。
  2. 密钥不明文写进业务文件，统一走环境变量或 Secret 管理。
  3. 高风险执行必须走审批，且审批人白名单要单独维护。
  4. 每次升级先做配置校验，再灰度上线，不要直接全量切。
这里给一个很关键的版本提醒：
我本地 OpenClaw 版本是 `2026.2.26`，但更新检查显示可用版本已到 `2026.3.2`（检查时间是 2026-03-05）。
而官方 v2026.3.2 release（GitHub）里有一个明确 breaking change：
新安装默认 `tools.profile` 会偏向 `messaging`，不再默认放开广泛 coding/system 工具（所以很多每天更新的同学都在这里踩坑，而且让 OpenClaw 修复，它还不一定能找对位置）。
这会直接影响“为什么我的 Agent 看起来变笨了、只会聊天不执行”。
这不是模型问题，是权限模型变了。

06.
记忆系统：长期记忆不是越多越好，而是检索结构要变
图片

OpenClaw 当初很打动人的卖点，是“长期记忆、越用越懂你”。
但我自己跑下来发现：
如果把 MEMORY 当仓库一直堆，最终每次都背着巨量上下文，速度和 token 成本都会越来越差。
我的解决办法是：在 Docker 上安装 MemOS，把记忆拆成四层：
  1. 工作记忆
  2. 情景记忆
  3. 语义记忆
  4. 程序记忆
再加优先级（比如 P0/T0）和渐进加载：只有任务需要时才调相关记忆，不让所有记忆“默认上车”。
这套结构对我很有用。
我把 Obsidian 里 3 年多的资料导进去，累计 9000+ 记录后，仍然能保持可用。
不过也要说真实情况：
我在 2026-03-05 的网关日志里看到过 memory 插件相关告警（`memory-core` 槽位异常提示）。
这类问题在快速迭代期并不罕见，所以“记忆可观测性”一定要做。

07.
给你的一套“安装后配置清单”
图片

如果你刚安装完 OpenClaw，我建议按这个顺序来，不要跳步：
  1. 先定角色：写清楚每个 Agent 的职责、边界、可用工具，不要先写提示词。
  2. 先通一条通道：把一个通道跑通（Discord 或飞书二选一），确保消息-路由-回复闭环可用。
  3. 把配对和权限先卡死：默认用 pairing，不要一上来就 open。
  4. 做一次基础安全清理：把密钥迁出配置正文，做一次 secret 审计。
  5. 建立日志巡检：每天至少看三类日志：网关启动、通道连接、审批执行。
  6. 再上多 Agent 协同：先单实例多 Agent，再考虑多实例。
  7. 最后才做性能优化：先稳定再提速，避免“边抖边快”。

08.
OpenClaw 的上限，不在模型榜单，在你的架构能力
图片

很多人把 OpenClaw 当“一个会聊天的工具”。
但当你把它当“一个可运营的系统”，你会发现：
真正决定结果的，不是某个模型名字，而是你怎么做配置治理、权限设计、记忆结构和通道编排。
磨刀不误砍柴工。
把配置这件事做好，你的小龙虾才会真的长出钳子。
参考信息

  • 本地日志与配置（截至 2026-03-05）：
  • `~/.openclaw/logs/gateway.log`
  • `~/.openclaw/logs/gateway.err.log`
  • `~/.openclaw/update-check.json`
  • `~/.openclaw/gateway.json`
  • 官方文档：
  • https://docs.openclaw.ai/channels/feishu
  • https://docs.openclaw.ai/channels/discord
  • https://docs.openclaw.ai/channels/pairing
  • https://docs.openclaw.ai/gateway/configuration-reference
  • https://docs.openclaw.ai/cli/memory
  • 官方发布：
  • https://github.com/openclaw/openclaw/releases/tag/v2026.3.2