研究完OpenClaw源碼后，我的10條使用原則

從'任務(wù)系統(tǒng)而非聊天助手'的定位重構(gòu)，到模型分層策略、上下文注入控制，再到技能設(shè)計的SOP化，這些原則揭示了Agent工具從'能用'到'好用'的關(guān)鍵跨越。本文為真正希望將AI融入工作流的用戶提供了系統(tǒng)化操作框架。

———— / BEGIN / ————

理解系統(tǒng)原理的真正意義，是它會改變你使用系統(tǒng)的方式。如果只是知道 OpenClaw 的內(nèi)部結(jié)構(gòu)，但在使用方式上依然和別人一樣，那這種理解其實價值并不大。

換句話說，如果你已經(jīng)知道它的運行機(jī)制，那你在使用 OpenClaw 時，理應(yīng)比別人更有優(yōu)勢。

你應(yīng)該更清楚它的邊界在哪里，更知道哪些能力來自模型，哪些來自工具，哪些來自上下文工程，也更知道怎么使用才能真正發(fā)揮這套系統(tǒng)的能力。

所以，這篇文章我基于對源碼的理解，嘗試為你總結(jié)出十條 OpenClaw 的最佳使用原則。

下面我們就開始吧：

第一條：不要把OpenClaw當(dāng)萬能助理，把它當(dāng)任務(wù)系統(tǒng)

很多人第一次用 OpenClaw，很容易把它當(dāng)成一個更強(qiáng)的聊天機(jī)器人，習(xí)慣性地去想讓這條龍蝦幫自己做點什么。比如去搜個信息、去看個文檔等等。

但從系統(tǒng)結(jié)構(gòu)來看，OpenClaw并不是一個單純的聊天助手，而更像一個任務(wù)調(diào)度系統(tǒng)。它背后有消息路由、Agent運行環(huán)境、工具系統(tǒng)和會話上下文。如果你給它的任務(wù)是模糊的，它就會在一個很大的空間里亂跑，最終輸出的結(jié)果也往往會比較發(fā)散。

更有效的方式，是把每次會話都當(dāng)成給它下一張任務(wù)單，去定義清楚它在這個會話里到底該負(fù)責(zé)什么。

也就是說，你每一次和龍蝦的對話，最好先想清楚：

• 它服務(wù)的是哪個場景。

• 它能調(diào)用哪些工具。

• 它要讀哪些資料。

• 它要輸出成什么結(jié)果。

• 它什么時候該停。

因此，從這個角度看，更適合你的做法，是把 OpenClaw 用在這幾類事上：

一類是有明確輸入輸出的知識類工作，比如資料搜集、文檔整理、方案初稿、文章提綱、代碼排查。

一類是需要工具參與的半自動執(zhí)行任務(wù)，比如批量讀文件、搜索項目文檔、匯總多個目錄下的信息。

當(dāng)任務(wù)邊界清晰時，Agent的行為就會更穩(wěn)定。

第二條：模型選型，要按任務(wù)分層

從源碼中可以發(fā)現(xiàn)，OpenClaw的任務(wù)效果，是由模型能力、上下文長度、工具調(diào)用穩(wěn)定性三者綜合決定的。

而很多人用 OpenClaw 時，對模型選型這件事會比較“一刀切”，要么就是用云端一鍵部署的默認(rèn)模型，要么就直接懟到Claude Opus 4.6，代價就是不好用 or 賬單爆掉。

因此更實用的思路，是“按任務(wù)類型分層選擇模型”。

復(fù)雜規(guī)劃、長鏈路推理、關(guān)鍵決策，用更強(qiáng)的模型。

比如你要寫個多步驟的Skill、要做復(fù)雜流程的深度研究、完成一條工作流（比如視頻創(chuàng)作、長文撰寫），這類任務(wù)對推理要求高，寧可貴一點，也要上更強(qiáng)的模型。比如Claude Opus 4.6。

資料整理、改寫潤色、常規(guī)問答、輕量執(zhí)行，用成本更低、速度更快的模型。

比如DeepSeek系列。 因為這類任務(wù)真正的瓶頸不在智力，而在上下文組織和任務(wù)邊界。

工具密集型任務(wù)，優(yōu)先考慮工具調(diào)用穩(wěn)定、上下文容忍度高的模型，而不只是紙面上的智商高。

比如GPT?5.4、Kimi K2.5。 因為在 OpenClaw 里，模型不是只回答，它還要理解工具說明、決定是否調(diào)用工具、消化 tool result，再繼續(xù)下一輪。這里穩(wěn)定性比一次驚艷的輸出更重要。

所以在實際使用時，建議你按任務(wù)類型，多養(yǎng)幾只接不同模型的龍蝦：

• 專門跑研究型任務(wù)的龍蝦，接重推理模型

• 專門跑執(zhí)行型任務(wù)的龍蝦，接工具響應(yīng)穩(wěn)定的模型

• 專門做內(nèi)容理解、摘要提取、數(shù)據(jù)格式化的龍蝦，接性價比高模型

當(dāng)這樣分層使用模型時，龍蝦跑得就會更穩(wěn)，也更省錢~

第三條：指令不要寫成聊天，要寫成任務(wù)說明

Agent系統(tǒng)和聊天助手的一個重要區(qū)別，在于 OpenClaw 不是普通的對話助手，它背后有工具、文件、會話歷史、系統(tǒng)提示詞，它會根據(jù)上下文和工具去執(zhí)行操作。

因此，當(dāng)你給它指令時，如果只是自然聊天，很容易讓他產(chǎn)生過度解讀，不僅輸出不是你想要的，回復(fù)效率也沒那么高。

舉個極端的例子，你跟他說“今天天氣真好”，他可能會先分析你的潛臺詞，是要圍繞天氣來產(chǎn)生后續(xù)行為，然后他會主動找有沒有天氣Skill能查天氣，如果沒有可能會自己寫一個，然后再基于天氣規(guī)劃你今天的日程等等。但其實你可能只需要一句“看起來你心情不錯”的回復(fù)……

所以，在有明確目標(biāo)的前提下，就還是少用這樣的表達(dá)方式：“幫我看看這個東西怎么弄”、“你研究一下這個”、“你幫我搞定這個”……

建議把你的指令，寫成結(jié)構(gòu)化的任務(wù)說明。明確目標(biāo)、輸入材料、執(zhí)行步驟、輸出格式以及限制條件。

比如讓它分析一個開源項目，不要只說：“幫我看懂這個項目源碼”，而是要這樣表達(dá)：

請只從以下3個地方的文件進(jìn)行分析：README.md、ARCHITECTURE.md、src/auto-reply 目錄下的Markdown文件。先回答系統(tǒng)入口在哪里，再回答消息鏈路如何流轉(zhuǎn)。不要泛泛總結(jié)，不要猜測未讀到的內(nèi)容。最后輸出一份 5 段式分析，包含關(guān)鍵文件名和職責(zé)。

這種寫法相當(dāng)于在給 Agent 發(fā)一張工單，輸出會更穩(wěn)定。

第四條：少寫人格設(shè)定，多寫工作邊界

很多人用 OpenClaw，最愛往 SOUL.md里堆大量人格設(shè)定，比如“你是一位嚴(yán)謹(jǐn)?shù)膶＜摇薄ⅰ澳闶且粋€經(jīng)驗豐富的工程師”。 但你現(xiàn)在已經(jīng)知道，這東西價值有限。

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

你更應(yīng)該寫的，是要求他只允許讀取哪些目錄、優(yōu)先使用哪些工具、什么情況下必須先提問、什么情況下禁止直接執(zhí)行、輸出必須包含哪些字段、引用結(jié)論時必須給出處、遇到上下文不足時先詢問而不是瞎猜。

這類會影響模型行為路徑的規(guī)則，比任何人格設(shè)定都更有效。

因為模型真正吃的是操作約束，不是人格夸獎。

第五條：控制上下文注入，不要讓系統(tǒng)變成一鍋粥

上篇文章中你已經(jīng)看到了，buildEmbeddedSystemPrompt 會把很多東西拼進(jìn)去，包括工作目錄、可用工具、項目文檔以及記憶文件等。這也是為什么 Agent 在某些場景下看起來非常懂你。

但這同時也是一把雙刃劍。上下文越長，token消耗越高，而且模型注意力會被稀釋。如果再額外塞入大量無關(guān)資料，很容易導(dǎo)致推理質(zhì)量下降。

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

• 長期規(guī)則文件只保留真正穩(wěn)定的原則。

• 一個文件只寫一類事情。

• 背景材料盡量摘要化，不要整篇原文硬塞。

• 和當(dāng)前任務(wù)無關(guān)的 README、歷史筆記、記憶文檔，盡量別默認(rèn)全帶。

• 每次任務(wù)只給最小必要上下文。

總之就是只提供當(dāng)前任務(wù)真正需要的信息，其余資料盡量不帶入會話。

很多時候，讓模型知道得更少，反而會更聰明。

第六條：不要把Skill當(dāng)能力清單，而要設(shè)計成標(biāo)準(zhǔn)作業(yè)流程

很多人對Skill的態(tài)度，是多多益善，恨不得把Clawhub上的全部Skill都搞下來，美其名曰“讓龍蝦自我進(jìn)化”。

但從實際使用來看，刨除掉安全風(fēng)險，如果只是無腦堆Skill能力，反而會讓系統(tǒng)越來越亂、過度輸出、頻繁消耗token。

更有效的方式，是把 Skill 設(shè)計成 SOP。讓每個 Skill 都面向一個固定任務(wù)，有固定輸入、固定步驟和標(biāo)準(zhǔn)輸出，也有精確的停止條件。

舉個例子，比起安裝一個“企業(yè)AI顧問專家 Skill”，你更應(yīng)該把它拆成：

• 客戶需求紀(jì)要整理 Skill。

• 調(diào)研訪談提綱生成 Skill。

• 公眾號選題診斷 Skill。

• 項目結(jié)構(gòu)拆解 Skill。

• 競品資料比對 Skill。

你會發(fā)現(xiàn)，一旦 Skill 變成 SOP，效果會穩(wěn)定很多，也更適合復(fù)用。

第七條：復(fù)雜任務(wù)采用兩段式調(diào)用

在很多復(fù)雜任務(wù)中，最容易出現(xiàn)的問題是讓 Agent 一次完成探索和總結(jié)兩件事情。這樣往往會導(dǎo)致輸出內(nèi)容冗長且結(jié)構(gòu)混亂。

而更好的方式是分多輪執(zhí)行。

第一輪，讓 OpenClaw 做探索。

比如搜集、掃描、初步歸類、列出可能路徑。

第二輪，再讓它做收口。

比如只基于第一輪的結(jié)果，輸出判斷、摘要、對比、結(jié)論。

不要一上來就讓它直接給最終答案。因為 Agent 一旦同時承擔(dān)探索和定稿兩個任務(wù)，就容易又長又散。

我們寫文章、做方案、做項目分析判斷，都很適合用這套方法。

第八條：對要穩(wěn)定交付的任務(wù)，增加檢查點

如果只是你自己研究、試驗，可以放開讓 OpenClaw 自由發(fā)揮。

但如果是一些要穩(wěn)定交付的確定性工作，比如讓它寫一個Skill、生成一套PPT、給客戶出最終方案，最好在關(guān)鍵步驟增加檢查點。

比如：

• 先讓它列計劃，不直接執(zhí)行。

• 先讓它展示將讀哪些文件。

• 先讓它給出目錄和證據(jù)來源。

• 先給你中間稿，再決定是否繼續(xù)。

• 在工具執(zhí)行前先確認(rèn)一次。

因為 OpenClaw 的背后是個大語言模型，而大語言模型是會騙人的。

我就有過無數(shù)次，讓 OpenClaw 寫個記日程的 Skill ，告訴我寫完了，結(jié)果workspace文件夾里啥都木有；讓 OpenClaw 幫我記日程，也是虛晃一槍，第二天告訴我昨天什么事都沒做。

后來我學(xué)聰明了，讓它干完活兒自己檢查，結(jié)果幻覺率大大減少。

對高價值任務(wù)，半自動協(xié)作，往往比全自動更可靠。

第九條：把 OpenClaw 當(dāng)放大器，而不是演示工具

很多人使用 OpenClaw，只是為了展示 Agent 能做什么。但從長期來看，它更適合用作研究工具。

我自己在用 OpenClaw 時，覺得下面三個場景最能幫到我：

第一類，產(chǎn)品研究。

OpenClaw 很適合做文檔掃描、模塊梳理、關(guān)鍵文件抽取、問題定位。

第二類，多源雜亂內(nèi)容的預(yù)處理。

比如幫你讀會議紀(jì)要、項目資料、訪談記錄，先做結(jié)構(gòu)化整理，再由你做判斷。

第三類，內(nèi)容創(chuàng)作前的系統(tǒng)性調(diào)研。

不是直接幫你寫終稿，而是先幫你拆結(jié)構(gòu)、找證據(jù)、梳理觀點、比較差異。這些工作往往需要大量閱讀和整理，正是 Agent 系統(tǒng)擅長的領(lǐng)域。

如果把它當(dāng)作研究放大器，它的價值會比單純演示能力高得多。

第十條：為自己建一套使用手冊

當(dāng)你使用 OpenClaw 一段時間后，最有價值的沉淀，其實不是某個具體的 Skill，而是一套自己指揮龍蝦的方法。

建議你給自己沉淀一份個人龍蝦使用手冊，內(nèi)容大概可以分成下面四塊：

1. 什么任務(wù)適合用 OpenClaw。

2. 什么任務(wù)不適合。

3. 不同任務(wù)用什么模型。

4. 不同任務(wù)的指令模板怎么寫。

比如這樣的一套組合技：

• 源碼解讀：Code大蝦 + 限定目錄 + 證據(jù)輸出。

• 資料匯總：Speed大蝦 + 指定文件夾 + 固定摘要格式。

• 文章選題：Speed大蝦 + 探索Skill + 修正方向 + 終稿生成Skill。

• 客戶方案：Smart大蝦 + 音頻轉(zhuǎn)錄解讀工作流Skill + 信息補(bǔ)充 + 方案生成Skill。

當(dāng)這些經(jīng)驗形成一份簡短的個人手冊時，你使用 OpenClaw 的效率就會越來越高。

系統(tǒng)本身并不會自動變得更聰明，但使用者會。

結(jié)語

回頭看這段時間對 OpenClaw 的研究，我最大的感受是：理解系統(tǒng)原理，并不會立刻讓你能設(shè)計出同樣的工具，但它會改變你使用工具的方式。

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

本文來自公眾號：互聯(lián)網(wǎng)悅讀筆記 作者：申悅

想要第一時間了解行業(yè)動態(tài)、面試技巧、商業(yè)知識等等等？加入產(chǎn)品經(jīng)理進(jìn)化營，跟優(yōu)秀的產(chǎn)品人一起交流成長！