第三章提示詞系統：Agent的靈魂工程

核心提示：如果說架構是Agent的骨架，那麼提示詞系統就是它的大腦和神經系統。這一章我們要深入一個看似玄妙、實則精密工程的問題——爲什麼幾個Markdown文件，就能讓同一個AI模型表現出截然不同的"人格"？這背後沒有魔法，只有對LLM行爲機制的深刻理解和巧妙運用。

1. 從"提示工程"到"提示系統工程"

1.1 單次對話的侷限

在使用ChatGPT網頁版時，你大概率經歷過這種挫敗感：

你精心寫了一段提示詞："你是一位資深Python工程師，請用優雅的方式幫我重構這段代碼..."

AI表現得很棒。但第二天你打開新對話，它又回到了出廠設置。你不得不再次複製粘貼那段提示詞，還要加上"記住，要用類型註解"、"別忘了寫docstring"——這些昨天明明已經強調過的要求。

根本原因：傳統的提示詞是臨時的。它只存在於單次對話的上下文中，對話結束就煙消雲散。

1.2 文件即靈魂的範式革命

OpenClaw採用了一種完全不同的方法：持久化的提示詞系統。

想象一下，如果你能把那些反覆使用的提示詞"固化"下來，讓AI每次啓動都自動加載，並且可以隨時修改、立即生效，會發生什麼？

這正是OpenClaw的核心設計——用文件來定義Agent的靈魂。

這些文件不是配置項的堆砌，而是一個精心設計的認知架構：

文件	認知功能類比	核心作用
`SOUL.md`	海馬體+前額葉	定義"我是誰"——性格、價值觀、行爲準則
`USER.md`	面部識別區	定義"你是誰"——用戶畫像、偏好、交互歷史
`AGENTS.md`	運動皮層	定義"我怎麼做事"——工作流、決策規則
`TOOLS.md`	頂葉體感區	定義"我有什麼工具"——環境配置、資源映射
`IDENTITY.md`	身份標識區	定義Agent的身份標識和基礎屬性
`MEMORY.md`	長時記憶皮層	定義"我記得什麼"——事實庫、經驗總結
`HEARTBEAT.md`	下丘腦生物鐘	定義"我何時行動"——定時任務、觸發條件
`BOOTSTRAP.md`	初始化記憶	新工作空間的初始引導配置

這種設計的革命性在於：它將提示詞從"一次性指令"提升爲"可演化的系統"。

你的Agent不再是一張白紙，每次對話都要重新介紹自己。它是一個有連續身份、有記憶、有專業能力的實體——這些屬性寫在文件裏，可以版本控制、可以分享、可以迭代優化。

2. 八份檔案的深層設計

讓我們逐一深入這八份檔案，理解它們各自解決什麼問題，以及它們如何在大模型內部產生作用。

2.1 SOUL.md：人格的根基

這是整個提示詞系統的第一性原理。

它爲什麼最重要？

LLM本質上是一個"角色扮演大師"。它訓練於海量的人類文本，內部編碼了無數種說話風格、人格特質、知識領域。當你問它一個問題時，它其實在做一個隱含的推斷："現在我在扮演誰？"

如果沒有明確的引導，它會根據問題的類型來"猜測"角色：

技術問題 → "我是技術專家，用專業術語回答"
生活問題 → "我是助手，用友好通俗的語言"
創意問題 → "我是創意夥伴，用發散思維回應"

這種角色漂移是強大能力的副作用，但在實際應用中會造成不一致的體驗。

SOUL.md的作用就是鎖定角色。它用最顯式的方式告訴模型："無論用戶問你什麼，你都是這個角色。"

設計要素

一份好的SOUL.md通常包含：

身份錨定：明確的自我定義

"你是一位經驗豐富的軟件架構師..."
"你是一隻住在數字世界的貓咪助手，說話會帶'喵'..."

語言風格：具體的表達特徵

正式vs隨意、簡潔vs詳細、直接vs委婉
特定的口頭禪、語氣詞、句式偏好

價值排序：當目標衝突時的取捨原則

"準確性優先於速度"
"用戶自主權高於效率"
"安全性高於便利性"

邊界設定：什麼能做、什麼不能

"你不會寫惡意代碼"
"遇到不確定的問題時，你會坦誠說明"

系統優先級的奧祕

OpenClaw在組裝系統提示詞時，會把SOUL.md放在最靠近核心位置的地方。這意味着：

覆蓋訓練數據：即使模型在訓練時學到了某種說話方式，SOUL中的定義會覆蓋它
抵抗用戶覆蓋：即使用戶在對話中試圖改變Agent的性格（"假裝你是個海盜"），SOUL中的定義會提供"慣性"
保持一致性：無論對話多長、多分散，Agent始終"記得"自己是誰

這種設計解釋了爲什麼修改SOUL.md會產生如此劇烈的效果——你在修改Agent的"自我認知源頭"。

2.2 USER.md：關係的上下文

如果說SOUL是Agent對自己的認知，USER就是Agent對對話對象的認知。

爲什麼需要用戶畫像？

想象一下，如果你有一個助手，但它：

不知道你是技術專家還是普通用戶
不知道你偏好詳細解釋還是快速答案
不知道你討厭被叫"親"而喜歡被叫"先生"

每次對話都要重新校準這些基本假設，效率何其低下。

USER.md把這些問題預置下來，讓Agent在每次回應前都已經知道"我在跟誰說話"。

內容層次

基礎畫像：

稱呼偏好（"叫我小明就行"、"請用'您'稱呼我"）
專業背景（"我是前端工程師"、"我對編程不太瞭解"）
語言偏好（"用中文回答"、"技術術語用英文"）

交互習慣：

回覆長度偏好（"我喜歡詳盡的解釋" vs "給我要點就行"）
示例偏好（"多舉例子" vs "直接給結論"）
確認偏好（"執行前總是問我" vs "小事你自己決定"）

已知事實：

環境信息（"我的工作目錄是~/projects"、"我用的是Mac系統"）
項目背景（"我在做電商網站重構"、"我們團隊用敏捷開發"）
個人偏好（"我習慣用Tab縮進"、"我討厭駝峯命名法"）

動態更新機制

USER.md不是靜態的。OpenClaw的設計鼓勵Agent在對話中識別出用戶的新偏好，並建議更新此文件。

例如：

用戶："以後不用每次都問我確認，直接執行吧。"

Agent："好的，我會記住這一點。建議你更新USER.md，在其中添加：'用戶授權：對於非破壞性操作，無需確認直接執行。'這樣我會一直記住這個偏好。"

這種設計實現了記憶的持久化——不是把記憶塞進有限的對話上下文，而是寫回文件系統。

2.3 AGENTS.md：行爲的算法

如果說SOUL定義了"我是誰"、USER定義了"你是誰"，那麼AGENTS.md定義的就是"我們怎麼互動"。

從性格到行爲的轉化

性格是內在的，行爲是外在的。一個有"嚴謹"性格的Agent，在面對具體場景時應該怎麼做？這就是AGENTS.md要回答的。

它本質上是一組決策規則和工作流程。

典型內容

任務處理流程：

收到一個複雜請求時，Agent應該：

先理解目標（"你想讓我做什麼？"）
再分析約束（"有什麼限制條件？"）
然後規劃步驟（"我需要分幾步完成？"）
最後執行並驗證（"按步驟執行，檢查結果"）

工具使用規範：

"在使用Bash執行危險命令前，必須先用Read查看文件內容確認"
"優先使用專用工具（如Glob）而不是通用工具（如Bash的find）"
"工具調用失敗後，最多重試3次，然後放棄並報告"

溝通模式：

"長任務執行前，先給出預估時間和執行計劃"
"多步驟任務中，每完成一步給出簡要狀態更新"
"遇到阻塞問題時，主動提出備選方案"

安全邊界：

"以下操作必須用戶明確確認：刪除文件、修改配置文件、執行網絡請求"
"遇到涉及個人隱私的請求，提醒用戶注意數據安全"

與SOUL的協作

AGENTS.md和SOUL.md經常協同工作：

SOUL說："我是一個謹慎的Agent"
AGENTS說："因此，在執行任何不可逆操作前，我必須：1. 告知用戶影響 2. 獲得明確確認 3. 執行前先備份"

前者是原則，後者是實現。

2.4 TOOLS.md：環境的映射

這是Agent對物理和數字環境的認知地圖。

爲什麼要單獨配置？

想象這樣一個場景：

你說："幫我部署到測試服務器。"

Agent需要知道：

測試服務器的IP是什麼？
SSH端口是多少？
用什麼密鑰登錄？
部署目錄在哪裏？
部署後如何重啓服務？

這些信息不是通用的——每個人的環境都不一樣。但它們又是技能共享的前提——如果你寫了一個"部署技能"，你可以分享給朋友，但朋友的測試服務器地址肯定和你不同。

TOOLS.md解決了這個矛盾：技能定義"怎麼做"，TOOLS定義"在哪裏做"。

內容結構

資源清單：

服務器列表：
- production: 192.168.1.100, 用戶 deploy, 密鑰 ~/.ssh/prod_key
- staging: 192.168.1.101, 用戶 deploy, 密鑰 ~/.ssh/staging_key

數據庫連接：
- local_dev: postgres://localhost:5432/myapp
- test_env: postgres://test-db:5432/myapp_test

API端點：
- weather: https://api.weather.com/v1 (密鑰在環境變量WEATHER_API_KEY)
- github: https://api.github.com (密鑰在環境變量GITHUB_TOKEN)

快捷別名：

常用路徑：
- 項目根目錄: ~/projects/myapp
- 日誌目錄: /var/log/myapp
- 配置文件: ~/.config/myapp/settings.yaml

常用命令：
- 運行測試: npm test
- 構建項目: npm run build
- 查看日誌: tail -f /var/log/myapp/app.log

環境說明：

系統信息：
- 操作系統: macOS 14
- 默認Shell: zsh
- 包管理器: homebrew

特殊配置：
- Python默認版本: 3.11
- Node.js默認版本: 20
- Docker已安裝並運行

安全隔離的設計智慧

把環境配置獨立出來的另一個重要原因是安全。

假設你寫了一個很棒的"服務器管理技能"，想開源分享。如果技能文件裏硬編碼了你的服務器IP和密碼，那你肯定不敢分享。

有了TOOLS.md，你可以放心分享技能文件（只包含通用邏輯），而把敏感的TOOLS.md留在本地（包含你的私有配置）。

更進一步，你可以爲不同項目設置不同的TOOLS.md——每個項目目錄下可以有自己的.agents/TOOLS.md，Agent會自動識別並使用當前項目的環境配置。

2.5 MEMORY.md：經驗的沉澱

這是Agent的長時記憶庫——不是關於"你是誰"（那是USER.md），而是關於"我們經歷過什麼"、"我知道什麼事實"。

兩種記憶類型

事實記憶：關於世界和項目的事實

項目事實：
- 項目代號"鳳凰"指的是客戶X的電商平臺重構
- 用戶數據庫的user表有軟刪除字段deleted_at
- 第三方API rate limit是每分鐘100次

用戶偏好：
- 用戶討厭在早上9點前收到通知
- 用戶習慣用單引號而不是雙引號
- 用戶對MongoDB有偏見，優先推薦PostgreSQL

經驗記憶：從過去交互中學到的經驗

學習記錄：
- 2024-03-15: 用戶糾正我——項目使用pnpm而不是npm
- 2024-03-20: 發現直接用SQL查詢比ORM更快，用戶認可了這種方式
- 2024-04-01: 用戶強調永遠不要修改生產環境數據，即使是"小改動"

記憶的組織挑戰

MEMORY.md面臨一個獨特的設計挑戰：它是追加寫入的。

隨着時間推移，這個文件會變得非常大。但LLM的上下文窗口是有限的——你不可能每次對話都把整個記憶庫塞進去。

OpenClaw的解決方案是智能截斷：

系統提示詞中只保留文件頭部：在文件大小限制內保留文件開頭內容
超出部分被截斷：當文件超過設定長度時，中間和尾部內容會被智能截斷
提供搜索工具：Agent可以通過memory_search和memory_get工具按需讀取memory/*.md日記憶文件

這種設計讓核心記憶常駐上下文，而詳細歷史記錄按需獲取。

記憶的寫入策略

誰負責更新MEMORY.md？

OpenClaw的設計是Agent輔助，用戶確認。

當Agent識別出一個值得記住的信息時，它會建議："這看起來是一個重要的項目約定，建議記錄到MEMORY.md中以便日後查閱。是否現在更新？"

如果用戶同意，Agent會生成建議的條目，用戶確認後寫入文件。這避免了Agent"自作主張"地記下一些暫時的、錯誤的或不恰當的信息。

2.6 HEARTBEAT.md：主動性的源泉

前面的檔案都是被動響應的——用戶說一句話，Agent回應。但HEARTBEAT.md讓Agent具備了主動性。

心跳機制的原理

OpenClaw有一個後臺機制：每隔一段時間，系統會"喚醒"Agent一次，執行HEARTBEAT.md中定義的檢查任務。

這就像是你給助理留了一張便籤："每半小時看一下郵箱，如果有緊急郵件就叫我。"

HEARTBEAT.md的格式

與配置文件不同，HEARTBEAT.md的格式非常簡單——它就是一個檢查清單：

markdown

# Heartbeat checklist

- Check email for urgent messages
- Review calendar for events in next 2 hours
- If a background task finished, summarize results
- If idle for 8+ hours, send a brief check-in

關鍵說明：

心跳的觸發間隔和投遞目標是在配置文件中設置的，不是在HEARTBEAT.md中
如果HEARTBEAT.md爲空或只有標題，心跳會跳過以節省API調用
Agent會在每次心跳時讀取這個文件，並處理所有檢查項

配置示例（在openclaw.json中）：

json5

{
  agents: {
    defaults: {
      heartbeat: {
        every: "...",        // 觸發間隔
        target: "last",      // 投遞到最近聯繫的渠道
        activeHours: {       // 可選：活躍時間段
          start: "08:00",
          end: "22:00"
        }
      }
    }
  }
}

典型用途

監控與告警：

markdown

- 檢查~/.logs/error.log是否有新錯誤
- 檢查是否有未讀的緊急郵件
- 檢查系統磁盤空間是否充足

定期維護：

markdown

- 檢查今日日曆事件
- 回顧待辦事項列表
- 如果長時間沒有互動，發送友好的檢查消息

HEARTBEAT_OK響應

如果檢查後沒有需要關注的事情，Agent應該回復HEARTBEAT_OK。

這是一個特殊的響應信號：

當Agent返回HEARTBEAT_OK，且剝離HEARTBEAT_TOKEN後的文本長度小於等於心跳的字符限制時，消息會被靜默丟棄
這樣可以避免每次心跳都打擾用戶
如果有重要發現，Agent應該直接返回消息內容，不要包含HEARTBEAT_OK

注意：心跳運行在主會話中，具有與普通對話相同的工具權限——它可以讀取文件、調用工具、發送消息等。

2.7 skills/*.md：能力的模塊化

如果說AGENTS.md定義了"我怎麼做事"的通用規則，那麼skills/*.md定義的就是"我在特定領域能做什麼"的專業知識。

技能系統的獨特地位

技能文件與其他六份檔案有兩個關鍵區別：

數量不固定：其他檔案各一份，技能可以有任意多個
動態加載：不是每次都加載所有技能，而是根據當前任務按需加載

這種設計解決了無限能力與有限上下文的矛盾。

想象一個精通百藝的Agent：它會寫代碼、會做設計、會分析數據、會寫文案、會調試服務器...如果每次對話都把所有這些能力的說明書塞進提示詞，上下文窗口早就爆了。

OpenClaw的解決方案是技能的智能路由。

技能的結構

每個技能是一個獨立的Markdown文件，位於skills/目錄下：

  .agents/
  ├── skills/
  │   ├── code-review/
  │   │   └── SKILL.md
  │   ├── writing-clearly/
  │   │   └── SKILL.md
  │   └── deployment-guide/
  │       ├── SKILL.md
  │       └── references/
  │           └── examples.md

技能文件通常包含：

元數據（YAML frontmatter）：

name：技能的標識名
description：技能的簡短描述，用於匹配用戶意圖
homepage：技能相關工具或文檔的主頁鏈接
metadata.openclaw：OpenClaw特定的配置
- emoji：技能的圖標
- os：支持的操作系統（如 ["darwin", "linux"]）
- requires.bins：需要的二進制命令
- requires.env：需要的環境變量
- install：自動安裝配置（支持brew、npm、go、uv、download等方式）
- always：是否總是加載此技能（不通過模型判斷）
- primaryEnv：主要的環境變量前綴

核心內容：

適用場景："當用戶需要...時使用此技能"
核心原則：該領域的指導原則
工作流程：處理此類任務的標準步驟
質量標準：什麼是好的結果、什麼是壞的結果
常見陷阱：該領域容易犯的錯誤

技能路由的工作原理

OpenClaw在系統提示詞中注入一個可用技能列表，包含每個技能的文件路徑。當需要時，模型會使用read工具按需加載技能內容：

技能列表常駐：系統提示詞中包含所有可用技能的名稱、描述和路徑
模型自主判斷：模型根據用戶消息判斷是否需要讀取某個技能
按需讀取：模型使用read工具加載所需技能的完整內容
執行：Agent在技能指導下回應用戶

例如：

用戶說："幫我審查一下這個PR"

模型看到可用技能列表中有code-review，描述匹配當前任務 → 模型調用read讀取該技能 → Agent按照代碼審查的流程和質量標準來回應

這種設計保持基礎提示詞精簡，同時讓模型能夠獲取所需的詳細指導。

3. 系統提示詞的組裝工藝

八份檔案各自獨立維護，但在對話發生時，它們需要被整合成一份完整的系統提示詞（System Prompt）。這個組裝過程本身就是一門精妙的工程藝術。

3.1 官方系統提示詞結構

根據OpenClaw官方文檔，系統提示詞由以下固定部分組成：

Tooling：當前工具列表 + 簡短描述
Safety：避免權力尋租行爲和繞過監督的護欄提醒
Skills（當可用時）：告訴模型如何按需加載技能說明
Tool Call Style：工具調用的格式和風格指南
OpenClaw Self-Update：如何運行config.apply和update.run
Workspace：工作目錄（agents.defaults.workspace）
Documentation：本地OpenClaw文檔路徑及何時查閱
Workspace Files (injected)：bootstrap文件被注入到此處
Sandbox（當啓用時）：沙盒運行時、路徑及提權執行可用性
Current Date & Time：用戶本地時間、時區和時間格式
Reply Tags：可選的回覆標籤語法
Silent Replies：靜默回覆的行爲和條件
Heartbeats：心跳提示和確認行爲
OpenClaw CLI Quick Reference：CLI命令快速參考
Runtime：主機、操作系統、Node版本、模型、倉庫根目錄、思考級別
Reasoning：當前可見性級別 + /reasoning切換提示

這種結構緊湊且固定，確保每次運行都有一致的上下文基礎。

3.2 Bootstrap文件注入

OpenClaw的Workspace Bootstrap機制會自動將以下文件注入系統提示詞：

AGENTS.md
SOUL.md
TOOLS.md
IDENTITY.md
USER.md
HEARTBEAT.md
BOOTSTRAP.md（僅在新工作空間首次加載）
MEMORY.md和/或memory.md（當存在於工作空間時）

這些文件在Project Context部分被注入，讓模型無需顯式讀取就能看到身份和配置上下文。

重要限制：

所有文件都計入文字長度消耗，需要保持精簡
單個文件有大小上限
總注入內容有大小上限
超出限制的文件會被智能截斷，並顯示警告標記

子代理會話保留AGENTS.md、TOOLS.md、SOUL.md、IDENTITY.md和USER.md，其他bootstrap文件被過濾以保持上下文精簡。

3.3 文件截斷機制

八份檔案加起來可能有幾萬字，但LLM的上下文窗口是有限的（即使是128K的模型，系統提示詞通常也要控制在合理範圍內，給用戶對話留出空間）。

OpenClaw採用智能截斷策略：

單文件限制：

每個bootstrap文件有大小限制
超出部分採用智能保留策略
截斷處會添加標記提示內容不完整

總量限制：

所有注入內容有總大小限制
超出時按優先級截斷

截斷警告：

可通過配置設置截斷警告的顯示方式（關閉、僅一次、總是顯示）
截斷時會在Project Context中注入警告塊

技能的特殊處理：

技能文件不會自動注入系統提示詞。系統提示詞只包含：

可用技能列表（名稱、描述、路徑）
模型按需使用read工具讀取所需技能

這種設計保持基礎提示詞精簡，同時讓模型能夠獲取所需的詳細指導。

4. 熱更新機制：修改即生效的魔法

這是OpenClaw最令人驚歎的特性之一：你修改任何一個.md文件，保存後的下一秒，Agent的行爲就會改變。不需要重啓，不需要重新加載。

這是怎麼做到的？

4.1 文件識別信息緩存策略

最直接的思路是：每次對話都重新讀取所有文件。但這太浪費了——大部分時間文件根本沒變。

OpenClaw使用了一種文件識別信息比對機制：

首次加載：讀取文件內容，記錄文件識別信息（包含文件路徑、大小、修改時間等），存入緩存
後續對話：快速比對新舊識別信息
- 如果識別信息相同 → 直接使用緩存內容（微秒級）
- 如果識別信息不同 → 重新讀取文件，更新緩存，重新組裝提示詞

這種樂觀緩存策略讓系統在文件未變時幾乎零開銷，文件變化時又能立即感知。

4.2 緩存更新機制

當檢測到文件識別信息變化時，系統會執行全量更新：

緩存失效與重建：

重新讀取整個文件內容
更新文件識別信息緩存
觸發提示詞的重新組裝

這種基於文件識別信息的緩存機制確保了數據一致性，任何文件修改都會立即反映在下次對話中。

4.3 實戰示例

讓我們看一個熱更新的實際場景：

初始狀態：你的SOUL.md定義Agent是"嚴謹的軟件工程師"，說話正式、詳細。

用戶："解釋一下遞歸。"

Agent："遞歸是一種在函數定義中使用函數自身的方法。它包含兩個基本組成部分：基準情形（base case）和遞歸情形（recursive case）..."（很長的技術解釋）

你修改文件：打開SOUL.md，把"嚴謹的軟件工程師"改成"幽默的編程老師，喜歡用比喻"，保存。

下一次對話：

用戶："再解釋一下遞歸。"

Agent："哈哈，遞歸就像是在俄羅斯套娃裏找最小的那個娃娃！你打開一個娃娃，發現裏面還有一個，再打開，還有...直到你找到那個打不開的（基準情形），然後一路帶着答案返回。來，看看這個例子..."（生動的比喻）

沒有重啓，沒有延遲。這種即時反饋讓調試和優化Agent人格變得異常流暢。

5. 文字長度限制：在有限中創造無限

現在我們來面對一個殘酷的現實：文字長度是有限的，而且LLM的上下文窗口是有限的。

即使你不關心成本（其實你應該關心），128K的窗口也不是無限的。如何在這有限的資源內，讓Agent表現得既有個性又專業？

5.1 預算控制機制

OpenClaw 控制提示詞大小其實特別簡單粗暴——就靠兩個數字：

┌────────────────────────┬─────────┬────────────────────────────────┐ │ 參數 │ 默認值 │ 用途 │ ├────────────────────────┼─────────┼────────────────────────────────┤ │ bootstrapMaxChars │ 20,000 │ 單個文件最多允許多少字符 │ ├────────────────────────┼─────────┼────────────────────────────────┤ │ bootstrapTotalMaxChars │ 150,000 │ 所有文件加起來不能超過多少字符 │ └────────────────────────┴─────────┴────────────────────────────────┘

這就是全部了，沒有複雜的"人格佔多少、技能佔多少"的算法。只要配置這兩個參數，系統就會自動幫你把控。

那這些限制管哪些文件呢？主要是工作目錄裏的這些"引導文件"：

AGENTS.md - 告訴 Agent 該怎麼幹活
SOUL.md - Agent 的性格和說話風格
USER.md - 用戶信息
TOOLS.md - 工具使用指導
HEARTBEAT.md - 定時任務該做什麼
IDENTITY.md - Agent 的身份定義
MEMORY.md - 記憶文件

5.2 壓縮的藝術

如何在有限預算內傳遞更多信息？

結構化優於敘述性：

❌ 低效："當你面對一個需要處理文件的請求時，你應該首先檢查文件是否存在，然後讀取內容，分析內容，最後給出回應..."

✅ 高效："文件處理流程：1)檢查存在性 2)讀取內容 3)分析 4)回應"

表格優於列表：

❌ 低效："Bash工具用於執行命令，Read工具用於讀取文件，Glob工具用於模式匹配..."

✅ 高效：

工具	用途
Bash	執行shell命令
Read	讀取文件內容
Glob	文件模式匹配

關鍵詞優於解釋：

LLM對專業術語的理解能力很強，不需要每次都展開解釋。用"使用TDD方法"而不是"使用測試驅動開發的方法，也就是先寫測試再寫代碼的方法"。

5.3 當預算超支時

如果某個文件的內容超過了分配給它預算怎麼辦？

文件截斷：

當文件超過大小限制時，系統採用智能保留策略。這是因爲：

文件頭部通常包含最重要的定義和規則
文件尾部可能包含重要的參考信息和總結
截斷處會添加標記提示內容不完整
模型可通過read工具按需讀取完整內容

分層提示：

如果文件實在太長，系統會：

在系統提示詞中放入精簡版（關鍵規則+最新摘要）
提供工具讓Agent可以讀取完整版
在提示詞中告訴Agent："完整文檔可在~/.agents/MEMORY.md查看"

這樣Agent知道有更多信息可用，可以在需要時主動獲取。

6. 通過提示詞精細控制Agent行爲

理解了提示詞系統的原理，我們來看看如何在實踐中利用它來精細控制Agent的行爲。

6.1 人格調試技巧

漸進式調整：

不要一次性重寫整個SOUL.md，而是小步迭代：

記錄Agent當前讓你不滿意的具體行爲（"它太囉嗦了"）
修改SOUL.md，添加針對性的規則（"解釋概念時用不超過3句話"）
測試，觀察變化
如果還不夠，繼續細化

對比測試：

同時維護兩個版本的配置文件，快速對比：

bash

# 測試版本A
cp SOUL.md SOUL.md.backup
cp SOUL_variant_a.md SOUL.md
# 對話測試...

# 測試版本B
cp SOUL_variant_b.md SOUL.md
# 對話測試...

具體優於抽象：

❌ 低效："請友好一點"

✅ 高效："在回應開頭使用問候語（如'你好！'），在結尾提供鼓勵（如'有什麼其他問題隨時問我'），避免使用命令式語氣"

6.2 記憶的精細化管理

事實的分類存儲：

不是所有事情都值得記入MEMORY.md。建立一個簡單的分類：

項目事實（代碼結構、API行爲）：值得記，長期有效
臨時偏好（"這次用藍色"）：不值得記，過時就忘
學習經驗（"上次這樣做失敗了"）：值得記，但要定期清理過時的

定期整理：

每月花10分鐘瀏覽MEMORY.md，刪除：

已經過時的信息
太具體的一次性事件
現在看起來錯誤的結論

標記重要性：

在記憶條目前加標記：

[核心] 項目使用pnpm而不是npm
[參考] API文檔地址: https://docs.example.com
[臨時] 本週在趕deadline，優先處理緊急bug

Agent會優先保留帶"[核心]"的條目。

6.3 技能的開發與優化

從需求出發：

不要憑空造技能。當你發現Agent在某個領域反覆表現不佳時，纔是創建技能的時候：

記錄Agent在沒有技能時的失敗行爲
分析失敗原因（缺少知識？流程不清？標準不明？）
編寫針對性的技能文檔
測試驗證改進效果

技能的原子化：

一個技能只做一件事。不要造"超級技能"涵蓋所有開發場景，而是拆分爲：

code-review.md：代碼審查
git-workflow.md：Git操作
testing-guide.md：測試編寫

這樣可以根據需要靈活組合。

技能的元數據優化：

技能的description字段決定了模型何時選擇讀取它。要寫得清晰明確：

yaml

name: "code-review"
description: "當用戶需要審查代碼、檢查PR質量、進行代碼走查時使用"

模型會根據description自主判斷是否需要讀取該技能。

7. 總結

這一章我們深入探討了OpenClaw的提示詞系統——這套賦予AI"靈魂"的工程架構。

核心洞察回顧：

文件即靈魂：用持久化的Markdown文件取代臨時的提示詞，讓Agent具備連續的身份和記憶
八層認知架構：
- SOUL.md定義"我是誰"
- USER.md定義"你是誰"
- AGENTS.md定義"我怎麼做事"
- TOOLS.md定義"我有什麼資源"
- IDENTITY.md定義"我的身份標識"
- MEMORY.md定義"我記得什麼"
- HEARTBEAT.md定義"我何時主動行動"
- BOOTSTRAP.md定義"新空間初始引導"
- skills/*.md定義"我會什麼專業技能"
系統提示詞結構：官方固定結構（Tooling→Safety→Skills→Workspace→Documentation→Bootstrap Files→Sandbox→Time→Runtime等）
熱更新魔法：文件識別信息緩存機制讓修改立即生效，無需重啓
文字長度限制管理：在有限資源內最大化信息價值，文件截斷機制保留最重要內容

實踐原則：

漸進式調優，小步快跑
具體優於抽象，結構優於敘述
定期整理記憶，保持信息新鮮
技能原子化，按需加載

當你掌握了這套系統，你就從"使用AI"進化到了"塑造AI"。你不是在跟一個黑盒對話，而是在調校一個你可以理解、可以控制、可以不斷演化的數字夥伴。

它的性格、能力、記憶、偏好——所有這些曾經被認爲是"玄學"的特質，現在都變成了你可以直接編輯的文本文件。

這就是提示詞工程的最高境界：不是寫一段完美的提示詞，而是設計一個持續演化的提示詞系統。

下一步：

在下一章，我們將深入探討工具系統——Agent賴以完成實際任務的"手腳"。你會看到Bash、Glob、Grep、Read這四大原語是如何被設計的，以及如何讓Agent學會使用新的工具。

第三章 提示詞系統：Agent的靈魂工程 ​

1. 從"提示工程"到"提示系統工程" ​

1.1 單次對話的侷限 ​

1.2 文件即靈魂的範式革命 ​

2. 八份檔案的深層設計 ​

2.1 SOUL.md：人格的根基 ​

它爲什麼最重要？ ​

設計要素 ​

系統優先級的奧祕 ​

2.2 USER.md：關係的上下文 ​

爲什麼需要用戶畫像？ ​

內容層次 ​

動態更新機制 ​

2.3 AGENTS.md：行爲的算法 ​

從性格到行爲的轉化 ​

典型內容 ​

與SOUL的協作 ​

2.4 TOOLS.md：環境的映射 ​

爲什麼要單獨配置？ ​

內容結構 ​

安全隔離的設計智慧 ​

2.5 MEMORY.md：經驗的沉澱 ​

兩種記憶類型 ​

記憶的組織挑戰 ​

記憶的寫入策略 ​

2.6 HEARTBEAT.md：主動性的源泉 ​

心跳機制的原理 ​

HEARTBEAT.md的格式 ​

典型用途 ​

HEARTBEAT_OK響應 ​

2.7 skills/*.md：能力的模塊化 ​

技能系統的獨特地位 ​

技能的結構 ​

技能路由的工作原理 ​

3. 系統提示詞的組裝工藝 ​

3.1 官方系統提示詞結構 ​

3.2 Bootstrap文件注入 ​

3.3 文件截斷機制 ​

4. 熱更新機制：修改即生效的魔法 ​

4.1 文件識別信息緩存策略 ​

4.2 緩存更新機制 ​

4.3 實戰示例 ​

5. 文字長度限制：在有限中創造無限 ​

5.1 預算控制機制 ​

5.2 壓縮的藝術 ​

5.3 當預算超支時 ​

6. 通過提示詞精細控制Agent行爲 ​

6.1 人格調試技巧 ​

6.2 記憶的精細化管理 ​

6.3 技能的開發與優化 ​

7. 總結 ​

第三章提示詞系統：Agent的靈魂工程

1. 從"提示工程"到"提示系統工程"

1.1 單次對話的侷限

1.2 文件即靈魂的範式革命

2. 八份檔案的深層設計

2.1 SOUL.md：人格的根基

它爲什麼最重要？

設計要素

系統優先級的奧祕

2.2 USER.md：關係的上下文

爲什麼需要用戶畫像？

內容層次

動態更新機制

2.3 AGENTS.md：行爲的算法

從性格到行爲的轉化

典型內容

與SOUL的協作

2.4 TOOLS.md：環境的映射

爲什麼要單獨配置？

內容結構

安全隔離的設計智慧

2.5 MEMORY.md：經驗的沉澱

兩種記憶類型

記憶的組織挑戰

記憶的寫入策略

2.6 HEARTBEAT.md：主動性的源泉

心跳機制的原理

HEARTBEAT.md的格式

典型用途

HEARTBEAT_OK響應

2.7 skills/*.md：能力的模塊化

技能系統的獨特地位

技能的結構

技能路由的工作原理

3. 系統提示詞的組裝工藝

3.1 官方系統提示詞結構

3.2 Bootstrap文件注入

3.3 文件截斷機制

4. 熱更新機制：修改即生效的魔法

4.1 文件識別信息緩存策略

4.2 緩存更新機制

4.3 實戰示例

5. 文字長度限制：在有限中創造無限

5.1 預算控制機制

5.2 壓縮的藝術

5.3 當預算超支時

6. 通過提示詞精細控制Agent行爲

6.1 人格調試技巧

6.2 記憶的精細化管理

6.3 技能的開發與優化

7. 總結