夜雨聆风很多人第一次用 OpenClaw，真正踩的坑并不是“不会提问”，而是把它误当成了一个更聪明的聊天框。
这个判断非常关键。OpenClaw 一旦接上 API、skills、cron、多 agent 和外部账户，它就不再只是“对话界面”，而是一套持续运行、持续读写、持续消耗预算的系统。你给它什么权限、让它多久醒一次、让几个 agent 并行、让哪一类任务调用哪一档模型，最后都会变成真实的账单、上下文压力和维护成本。
一、第一件事不是装更多功能，而是先给“心跳”和例行任务找便宜模型
如果你不控制 routine task 的成本，Agent 会在你睡觉的时候继续悄悄烧钱。很多人以为模型费用主要发生在自己主动提问的时候，但一旦你把 heartbeat、cron、健康检查、状态巡检也挂到高价模型上，成本就会从“用一次花一次”变成“系统只要活着就持续花”。
这里最重要的不是争论哪个模型更聪明，而是做模型分层。判断类、研究类、收口类任务交给高价模型；心跳、巡检、状态确认、日报拼装这类苦力任务交给便宜模型，或者直接交给本地模型。你没必要把最贵的模型浪费在“有没有新任务”“今天是否需要生成日报”“这个脚本是不是还活着”这种低价值判断上。
如果再讲得更工程一点，这件事本质上是在做资源隔离。把高智商模型保留给高杠杆节点，系统才会稳定。否则你越自动化，固定消耗越高，最后最先被停掉的不是任务，而是你继续实验的耐心。
二、别在同一个任务里频繁切模型，模型切换不是超能力，是上下文折损
很多新手一看到某个模型限流，第一反应就是手动切另一个模型继续干。表面看这是在“应急”，实际上经常是在主动把上下文打碎。不同模型对上下文压缩、历史偏好和文件重点的理解差异很大，任务跑到一半切脑子，最容易出问题的不是速度，而是目标漂移。
所以，比“能不能切模型”更重要的问题是：系统有没有提前定义好主模型、备用模型和便宜模型。也就是说，模型切换不应该是临场拍脑袋，而应该是配置层里的预案。主脑负责复杂判断，备用脑负责兜底，低价脑负责 routine task。这样即便某个 provider 波动，任务也不会突然换一种理解方式继续往下跑。
模型真正该对应的是岗位，而不是情绪。主 agent 和研究型 agent 用贵的、聪明的；创作、运维、巡检这类高频重复工种，用稳定、便宜、上下文足够长的模型。模型切换不是禁止，而是要把它变成可控的架构行为。
三、Skills 是杠杆，但也是权限边界最容易塌的地方
OpenClaw 真正和普通聊天工具拉开差距的地方，就是 skills。没有 skills，它更像一个会说会想的助手；有了 skills，它才开始接触你的文件、浏览器、外部服务，甚至执行命令。问题也在这里：一旦你开始装 skills，本质上就是在给系统引入外部能力和额外权限。
“装 skill 之前先看 SKILL.md”，这条应该升级成默认流程。判断一个 skill 值不值得装，不是看它功能吹得多大，而是看它申请的权限和它的功能是否匹配。如果一个只负责排版的 skill 却想拿到广泛执行权限，这种东西就不该进生产环境。
更稳妥的做法，是把 skill 安装和执行都纳入白名单逻辑。研究型 agent 可以多一点读取和抓取能力，运维型 agent 只跑包装脚本，创作型 agent 只处理稿件、图片和草稿箱。你不是在“限制智能”，你是在防止系统把本来应该是局部能力的东西，扩散成全局风险。
四、上下文不是无限的，Context Rot 不是玄学，是运行规律
很多人第一次碰到 Context Rot，会以为是模型突然变笨了。更准确的说法是：你的任务已经远远超过了对话窗口天然适合承载的长度。随着对话越来越长，系统总要压缩旧信息、丢掉细节、保留摘要。于是你三天前辛苦讲清楚的架构决策，到了今天只剩一句“曾讨论过路由方案”。
不要一味问“你还记得吗”，而要让系统去搜自己的历史、搜文件、搜 session。也就是说，关键上下文最好不要只活在聊天里，而要落进 PLAN.md、ROADMAP.md、MEMORY.md、review.md 这类文件。聊天是工作台，文件才是制度层。
这一条和多 agent 其实是连在一起的。Agent 越多、会话越多、技能越多，上下文污染和遗失就越容易发生。解决办法不是把上下文喂得更多，而是把重要信息从“暂存聊天”升级成“稳定文件”。这样即使换了 session、换了 agent、甚至换了模型，系统也有一个固定的重建入口。
五、别迷信 agent 数量，真正需要的是隔离，而不是热闹
“你不需要另一台电脑，也不需要九个 agent 编队”。很多人在 X 上看到复杂的多 agent 架构，第一反应是“我也得上一个十人舰队”。但如果任务边界、目录隔离、权限隔离都没理清楚，agent 一多，代价通常不是效率翻倍，而是上下文混乱、token 飙升、调试难度陡增。
所以，多 agent 的重点不是“多”，而是“隔离”。什么时候需要新 agent？不是因为一时兴起，而是因为这个任务确实需要独立 workspace、独立记忆、独立技能和独立权限。比如代码库工程师和外部研究助手就应该分开；公众号创作和系统运维也应该分开。相反，如果只是想临时清空上下文，开新 session 往往比开新 agent 更便宜也更稳。
把 agent 看成岗位，而不是分身，这件事会让系统立刻清爽很多。岗位有职责、有边界、有权限；分身则容易越开越多，最后没人知道谁该负责什么。
六、别在聊天框里做长期规划，Markdown 文件才是长期项目的真地基
不要把两周冲刺、系统重构、架构决策全都留在聊天记录里。因为聊天记录天然是流式的、反应式的、不断滚动的。你今天说过的话，过几天不一定还在有效上下文里；你今天临时改过的方向，下一次也不一定能被准确继承。
这就是为什么一个长期项目必须有 PLAN.md 或 ROADMAP.md。这类文件的价值，不是“让文档更好看”，而是让人和 agent 都有一张稳定地图。你每次开新 session，可以直接要求它先读 PLAN.md 再执行下一步；你每次改方向，也可以要求它把新决策写回文件，而不是只停留在口头确认。
把规划写进文件，还有一个更现实的好处：它能显著降低解释成本。一个没有计划文件的团队，后续所有工作都会变成“不断重复解释”。而一个计划文件维护得好的系统，后续每次会话都只需要重载文件，不需要重演前史。
七、记忆不是自动长出来的，关键事实必须手动固化
很多人对 Agent 的记忆有一种天然误解：以为自己讲过了，系统就会“永久懂了”。现实不是这样的。没有明确写入、没有被提炼成稳定事实的内容，最多只能算暂时停留在上下文里。上下文会被挤压、会被清空、会被替换，真正稳定的是文件化的记忆。
在关键时刻明确说“记住这件事”，这很重要，但更重要的是你要审记忆文件本身。MEMORY.md 不应该是一份充满情绪和流水账的日记，而应该是一份硬事实列表：技术栈、禁用规则、关键偏好、流程约束、重要账户边界。什么属于未来每次任务都该继承的，就应该进记忆；什么只是一次临时 brainstorm，就不该污染长期记忆。
如果你不主动治理记忆，记忆就会从“有用的偏好集合”退化成“模糊的废话堆”。到了那一步，系统不是更聪明，而是更难纠偏。
八、一人一岗，别造“全能神 agent”
当系统越做越复杂，另一个常见误区就出现了：把所有账户、所有权限、所有职责全塞给同一个 agent。表面上这很省事，因为你只要对一个入口说话；实际上它会迅速制造两个问题。第一，系统提示和可用技能会无限膨胀，导致模型每次推理都在更大的噪声池里找重点。第二，权限一旦出问题，影响面会非常大。
更合理的做法，是岗位化。代码 agent 就专注代码目录、代码技能和代码规则；研究 agent 只做外部搜索、信息整理和资料包；创作 agent 只处理文章、图片和草稿箱；运维 agent 只做健康检查、白名单脚本和自动修复。真正需要临时并行时，再起窄职责的子 agent，而不是把所有东西都塞进一个“大总管”里。
这也是为什么“少 agent”和“一人一岗”并不矛盾。前者是避免无意义扩编，后者是强调真的需要开的 agent 必须职责单一。
九、别只在聊天界面里猜，系统状态必须可观测
很多人只愿意在聊天窗口里和 agent 对话，却很少去看系统到底跑成了什么样：现在谁在执行、cron 有没有卡死、哪个模型掉线、哪些任务在反复重试、费用曲线怎么变化。结果就是，平时感觉一切正常，等到月底一看账单，才知道自己已经用一个坏配置跑了很多天。
对运行系统来说，可观测性不是附加项，而是必需品。你至少应该形成几个习惯：看 dashboard、看 status、看模型健康、看 cron 执行结果、看会话树。尤其是开始做多 agent 和自动化之后，“会不会说话”已经不是关键，“能不能看见系统正在干什么”才是关键。
如果你看不见系统状态，你做的就不是自动化，而是在赌博。
十、最贵的不是模型，而是你用错了模型、权限和付费方式
一个很现实的问题：很多人低估了 raw API 费率下 agent 的真实消耗。因为你看到的只是自己输入的一句话，但系统实际发出的请求里，还可能包含系统提示、技能说明、记忆、历史上下文和工具描述。一句看起来很轻的请求，到了 provider 那里，可能已经不是“小对话”，而是一整包运行上下文。
这也是为什么“换更便宜模型”本身并不一定解决问题。真正该优化的是三件事：模型分层、权限收敛、任务拆分。高价模型只在关键节点出现，廉价模型承担 routine task，skills 和 agent 严格按岗位隔离，计划和记忆写进文件而不是塞满聊天窗口。只有这样，系统才会越跑越稳，而不是越跑越贵。
如果再进一步，开始用固定预算的 coding plan 或其他更适合 agent 的计费方式，本质上也是在做成本确定性管理。不是因为 raw API 一定不能用，而是因为当系统开始高频自动化后，不做预算上限管理，代价很容易失真。
最后：OpenClaw 不会替你思考，但会把你的工作方式放大
把这 10 条经验串起来看，其实都在指向同一件事：OpenClaw 是一个放大器。你的边界清晰，它会放大清晰；你的流程混乱，它也会放大混乱；你的权限治理做得好，它会成为杠杆；你的权限治理做得差，它就会变成风险。
所以 Day 1 最应该做的，不是下载更多 skill，不是堆更多 agent，也不是一口气接十个模型。真正优先级更高的，是先把系统当基础设施：给不同任务分不同模型，给不同 agent 分不同权限，把计划和记忆写进文件，把状态监控和成本控制放在台面上。
一旦这套底层习惯立住了，OpenClaw 才会从“一个很酷的 AI 玩具”变成“一个真的能替你放大产出的工作系统”。
