OpenClaw源码10条使用原则！

拆源码这件事，本身并不是目的。理解系统原理的真正意义，是它会改变你使用系统的方式。如果只是知道 OpenClaw 的内部结构，但在使用方式上依然和别人一样，那这种理解其实价值并不大。

换句话说，如果你已经知道它的运行机制，那你在使用 OpenClaw 时，理应比别人更有优势。你应该更清楚它的边界在哪里，更知道哪些能力来自模型，哪些来自工具，哪些来自上下文工程，也更知道怎么使用才能真正发挥这套系统的能力。

所以，这篇文章我想延续上一篇的思路，基于对源码的理解，尝试为你总结出十条 OpenClaw 的最佳使用原则。

下面我们就开始吧：

第一条：不要把OpenClaw当万能助理，把它当任务系统

很多人第一次用 OpenClaw，很容易把它当成一个更强的聊天机器人，习惯性地去想让这条龙虾帮自己做点什么。比如去搜个信息、去看个文档等等。

但从系统结构来看，OpenClaw并不是一个单纯的聊天助手，而更像一个任务调度系统。它背后有消息路由、Agent运行环境、工具系统和会话上下文。如果你给它的任务是模糊的，它就会在一个很大的空间里乱跑，最终输出的结果也往往会比较发散。

更有效的方式，是把每次会话都当成给它下一张任务单，去定义清楚它在这个会话里到底该负责什么。

也就是说，你每一次和龙虾的对话，最好先想清楚：

• 它服务的是哪个场景。
• 它能调用哪些工具。
• 它要读哪些资料。
• 它要输出成什么结果。
• 它什么时候该停。

因此，从这个角度看，更适合你的做法，是把 OpenClaw 用在这几类事上：

• 一类是有明确输入输出的知识类工作，比如资料搜集、文档整理、方案初稿、文章提纲、代码排查。
• 一类是需要工具参与的半自动执行任务，比如批量读文件、搜索项目文档、汇总多个目录下的信息。

当任务边界清晰时，Agent的行为就会更稳定。

第二条：模型选型，要按任务分层

从源码中可以发现，OpenClaw的任务效果，是由模型能力、上下文长度、工具调用稳定性三者综合决定的。

而很多人用 OpenClaw 时，对模型选型这件事会比较“一刀切”，要么就是用云端一键部署的默认模型，要么就直接怼到Claude Opus 4.6，代价就是不好用 or 账单爆掉。

因此更实用的思路，是“按任务类型分层选择模型”。

复杂规划、长链路推理、关键决策，用更强的模型。

比如你要写个多步骤的Skill、要做复杂流程的深度研究、完成一条工作流（比如视频创作、长文撰写），这类任务对推理要求高，宁可贵一点，也要上更强的模型。比如Claude Opus 4.6。

资料整理、改写润色、常规问答、轻量执行，用成本更低、速度更快的模型。

比如DeepSeek系列。 因为这类任务真正的瓶颈不在智力，而在上下文组织和任务边界。

工具密集型任务，优先考虑工具调用稳定、上下文容忍度高的模型，而不只是纸面上的智商高。

比如GPT‑5.4、Kimi K2.5。 因为在 OpenClaw 里，模型不是只回答，它还要理解工具说明、决定是否调用工具、消化 tool result，再继续下一轮。这里稳定性比一次惊艳的输出更重要。

所以在实际使用时，建议你按任务类型，多养几只接不同模型的龙虾：

• 专门跑研究型任务的龙虾，接重推理模型
• 专门跑执行型任务的龙虾，接工具响应稳定的模型
• 专门做内容理解、摘要提取、数据格式化的龙虾，接性价比高模型

当这样分层使用模型时，龙虾跑得就会更稳，也更省钱~

第三条：指令不要写成聊天，要写成任务说明

Agent系统和聊天助手的一个重要区别，在于 OpenClaw 不是普通的对话助手，它背后有工具、文件、会话历史、系统提示词，它会根据上下文和工具去执行操作。

因此，当你给它指令时，如果只是自然聊天，很容易让他产生过度解读，不仅输出不是你想要的，回复效率也没那么高。

举个极端的例子，你跟他说“今天天气真好”，他可能会先分析你的潜台词，是要围绕天气来产生后续行为，然后他会主动找有没有天气Skill能查天气，如果没有可能会自己写一个，然后再基于天气规划你今天的日程等等。但其实你可能只需要一句“看起来你心情不错”的回复……

所以，在有明确目标的前提下，就还是少用这样的表达方式：“帮我看看这个东西怎么弄”、“你研究一下这个”、“你帮我搞定这个”……

建议把你的指令，写成结构化的任务说明。明确目标、输入材料、执行步骤、输出格式以及限制条件。

比如让它分析一个开源项目，不要只说：“帮我看懂这个项目源码”，而是要这样表达：

请只从以下3个地方的文件进行分析：README.md、ARCHITECTURE.md、src/auto-reply 目录下的Markdown文件。先回答系统入口在哪里，再回答消息链路如何流转。不要泛泛总结，不要猜测未读到的内容。最后输出一份 5 段式分析，包含关键文件名和职责。

这种写法相当于在给 Agent 发一张工单，输出会更稳定。

第四条：少写人格设定，多写工作边界

很多人用 OpenClaw，最爱往 SOUL.md里堆大量人格设定，比如“你是一位严谨的专家”、“你是一个经验丰富的工程师”。 但你现在已经知道，这东西价值有限。

真正有效的，不是人格描述，而是工作边界的说明。

你更应该写的，是要求他只允许读取哪些目录、优先使用哪些工具、什么情况下必须先提问、什么情况下禁止直接执行、输出必须包含哪些字段、引用结论时必须给出处、遇到上下文不足时先询问而不是瞎猜。

这类会影响模型行为路径的规则，比任何人格设定都更有效。

因为模型真正吃的是操作约束，不是人格夸奖。

第五条：控制上下文注入，不要让系统变成一锅粥

上篇文章中你已经看到了，buildEmbeddedSystemPrompt 会把很多东西拼进去，包括工作目录、可用工具、项目文档以及记忆文件等。这也是为什么 Agent 在某些场景下看起来非常懂你。

但这同时也是一把双刃剑。上下文越长，token消耗越高，而且模型注意力会被稀释。如果再额外塞入大量无关资料，很容易导致推理质量下降。

因此我的建议是：最小必要上下文原则。即：

• 长期规则文件只保留真正稳定的原则。
• 一个文件只写一类事情。
• 背景材料尽量摘要化，不要整篇原文硬塞。
• 和当前任务无关的 README、历史笔记、记忆文档，尽量别默认全带。
• 每次任务只给最小必要上下文。

总之就是只提供当前任务真正需要的信息，其余资料尽量不带入会话。

很多时候，让模型知道得更少，反而会更聪明。

第六条：不要把Skill当能力清单，而要设计成标准作业流程

很多人对Skill的态度，是多多益善，恨不得把Clawhub上的全部Skill都搞下来，美其名曰“让龙虾自我进化”。

但从实际使用来看，刨除掉安全风险，如果只是无脑堆Skill能力，反而会让系统越来越乱、过度输出、频繁消耗token。

更有效的方式，是把 Skill 设计成 SOP。让每个 Skill 都面向一个固定任务，有固定输入、固定步骤和标准输出，也有精确的停止条件。

举个例子，比起安装一个“企业AI顾问专家 Skill”，你更应该把它拆成：

• 客户需求纪要整理 Skill。
• 调研访谈提纲生成 Skill。
• 公众号选题诊断 Skill。
• 项目结构拆解 Skill。
• 竞品资料比对 Skill。

你会发现，一旦 Skill 变成 SOP，效果会稳定很多，也更适合复用。

第七条：复杂任务采用两段式调用

在很多复杂任务中，最容易出现的问题是让 Agent 一次完成探索和总结两件事情。这样往往会导致输出内容冗长且结构混乱。

而更好的方式是分多轮执行。

第一轮，让 OpenClaw 做探索。

比如搜集、扫描、初步归类、列出可能路径。

第二轮，再让它做收口。

比如只基于第一轮的结果，输出判断、摘要、对比、结论。

不要一上来就让它直接给最终答案。因为 Agent 一旦同时承担探索和定稿两个任务，就容易又长又散。

我们写文章、做方案、做项目分析判断，都很适合用这套方法。

第八条：对要稳定交付的任务，增加检查点

如果只是你自己研究、试验，可以放开让 OpenClaw 自由发挥。

但如果是一些要稳定交付的确定性工作，比如让它写一个Skill、生成一套PPT、给客户出最终方案，最好在关键步骤增加检查点。

比如：

• 先让它列计划，不直接执行。
• 先让它展示将读哪些文件。
• 先让它给出目录和证据来源。
• 先给你中间稿，再决定是否继续。
• 在工具执行前先确认一次。

因为 OpenClaw 的背后是个大语言模型，而大语言模型是会骗人的。

我就有过无数次，让 OpenClaw 写个记日程的 Skill ，告诉我写完了，结果workspace文件夹里啥都木有；让 OpenClaw 帮我记日程，也是虚晃一枪，第二天告诉我昨天什么事都没做。

后来我学聪明了，让它干完活儿自己检查，结果幻觉率大大减少。

对高价值任务，半自动协作，往往比全自动更可靠。

第九条：把 OpenClaw 当放大器，而不是演示工具

很多人使用 OpenClaw，只是为了展示 Agent 能做什么。但从长期来看，它更适合用作研究工具。

我自己在用 OpenClaw 时，觉得下面三个场景最能帮到我：

第一类，产品研究。

OpenClaw 很适合做文档扫描、模块梳理、关键文件抽取、问题定位。

第二类，多源杂乱内容的预处理。

比如帮你读会议纪要、项目资料、访谈记录，先做结构化整理，再由你做判断。

第三类，内容创作前的系统性调研。

不是直接帮你写终稿，而是先帮你拆结构、找证据、梳理观点、比较差异。这些工作往往需要大量阅读和整理，正是 Agent 系统擅长的领域。

如果把它当作研究放大器，它的价值会比单纯演示能力高得多。第十条：为自己建一套使用手册

当你使用 OpenClaw 一段时间后，最有价值的沉淀，其实不是某个具体的 Skill，而是一套自己指挥龙虾的方法。

建议你给自己沉淀一份个人龙虾使用手册，内容大概可以分成下面四块：

• 什么任务适合用 OpenClaw。
• 什么任务不适合。
• 不同任务用什么模型。
• 不同任务的指令模板怎么写。

比如这样的一套组合技：

• 源码解读：Code大虾 + 限定目录 + 证据输出。
• 资料汇总：Speed大虾 + 指定文件夹 + 固定摘要格式。
• 文章选题：Speed大虾 + 探索Skill + 修正方向 + 终稿生成Skill。
• 客户方案：Smart大虾 + 音频转录解读工作流Skill + 信息补充 + 方案生成Skill。

当这些经验形成一份简短的个人手册时，你使用 OpenClaw 的效率就会越来越高。

系统本身并不会自动变得更聪明，但使用者会。

结语

回头看这段时间对 OpenClaw 的研究，我最大的感受是：理解系统原理，并不会立刻让你能设计出同样的工具，但它会改变你使用工具的方式。

很多时候，真正和其他人拉开差距的，是使用工具的方式。

我也很想知道你的养虾体验，你目前用 OpenClaw 最常见的场景是什么？有没有遇到一些特别有效或特别踩坑的用法？

欢迎在评论区聊聊。