5大核心AI概念
在開始使用EasyClaw之前，先花5分鐘了解這些概念——它們將幫助你真正理解AI是如何運作的，而不是盲目地輸入指令。
你不需要成為工程師，但你需要知道：AI為什麼能做事、怎樣才能做得更準、什麼時候會失誤。
1. Agent（智慧體）
新手怎麼理解
Agent（智慧體）可以簡單理解成：「會做事的AI同事」。它不僅能聊天解釋， 更重要的是能把你的目標變成具體步驟，並在每一步做完後繼續推進，直到達成你想要的結果。
AI Agent的核心簡介
一個典型的AI Agent通常由三個部分共同完成：
大腦（理解與決策） + 工具/能力（能去哪裡做） + 執行迴圈（邊做邊檢查）。
因此它看起來不是「一次性生成答案」，而是像專案負責人那樣：先想清楚，再動手，再核對。
接下來講清楚它是怎麼運作的。你可以把Agent的工作過程想像成一個反覆執行的迴圈： 理解任務 → 制定計畫 → 呼叫工具 → 執行動作 → 驗證結果 → 繼續調整 → 回報。
1）理解任務：
Agent會先判斷你要解決什麼問題、成功標準是什麼、是否有約束條件（例如格式、語氣、時間、不能做什麼）。
如果資訊不夠，它可能會先向你提問，或先做必要的假設並說明。
2）制定計畫（拆解步驟）：
大任務往往需要拆成小步驟。比如「整理收件匣」可能被拆成：
掃描郵件 → 識別類型（通知/帳單/客戶/雜項）→ 判斷優先順序 → 歸檔 → 起草回覆（如需要）→ 彙總清單。
這一步決定了「先做什麼、後做什麼」。
3）呼叫工具/能力：
這也是Agent能「做事」的關鍵。沒有工具，它只能停留在文字層面的建議；
有了工具，它就能真實執行動作，例如：讀取檔案、搜尋資訊、傳送訊息、存取企業系統、產生文件等。
你會看到Agent會「去對接外部世界」，而不只是產生一句話。
4）執行並記錄：
在合適的步驟上，Agent會真正觸發操作（例如呼叫某個服務介面、完成一次資料處理、產生一段可用內容）。
同時它會記錄「我做到了哪一步」，方便後續繼續推進或回溯糾錯。
5）驗證與糾錯：
Agent不會只追求「看起來完成了」，它還會檢查結果是否符合要求。
例如：輸出是否缺少關鍵欄位、是否違反了你的格式要求、是否存在明顯錯誤或不確定點。
不滿足就會重新規劃下一步，繼續迭代。
6）回報結果與下一步：
最後，Agent會把它完成的內容、重要發現、以及下一步需要你確認的事項整理給你。
你能清楚知道：它做過什麼、哪些完成了、哪些還在進行中。
你說：「幫我整理收件匣，並把需要我回覆的郵件彙總成待辦清單。」
Agent可能會：先讀取郵件列表 → 分類歸檔 → 擷取寄件人/主旨/關鍵時間點 → 判斷哪些需要回覆 →
產生「待辦清單」（含優先順序與建議回覆要點）→ 告訴你「已完成哪些分類、還剩哪些未讀/不確定項」。
注意：它不是只給「整理思路」，而是產出可用的結果（清單/歸檔/草稿/進度）。
新手容易把Agent當成普通的對話工具：只問「怎麼做」。但真正的Agent需要可用的能力與執行流程。 如果一個系統只能解釋步驟、卻無法產出結果或觸發動作，它更像「問答助手」，而不是Agent。 記住一句話：會說 ≠ 會做；Agent的優勢在執行與回饋。
2. Skill（技能）
新手怎麼理解
Skill（技能/能力）可以理解成：Agent用來「幹活」的具體能力模組。
Agent負責思考與排程（接任務、決定下一步），而Skill負責把「下一步怎麼做」變成
可執行的操作：比如檢索資料、寫文件、產生報告、呼叫介面、執行計算等。
沒有Skill的Agent往往只能停留在建議層面；有了Skill，Agent才能真正產出結果。
Skill到底是什麼（本質）
從工程角度看，一項Skill通常是一種「可呼叫的能力」，常見型態包括：
1）工具/函式（例如：搜尋、計算、生成、翻譯）；
2）業務流程（例如：下單、報銷、工單建立）；
3）介面呼叫（例如：CRM查詢、行事曆同步、傳送郵件）。
關鍵不在「會不會聊天」，而在於Skill一般都有明確的邊界：輸入是什麼、怎麼執行、輸出是什麼。
這讓Agent能夠把任務拆解得更可靠，並在執行後獲得可驗證的結果。
Agent的迴圈裡經常會出現「呼叫工具/能力」這一步， 而那一步呼叫的就通常是Skill。你可以把它想成：Agent像大腦，Skill像手腳與工具箱。
為了更深入，我們把「Agent迴圈裡Skill是如何運作的」講透：
1）Agent判斷需要什麼Skill
當任務進入執行階段，Agent會分析目前步驟需要哪些能力。
例如「查詢某個客戶的歷史溝通記錄」需要「檢索/讀取」類Skill；
「起草跟進郵件」需要「生成文字/套版」類Skill；
「把任務同步到待辦系統」需要「寫入/更新」類Skill。
2）Agent把參數填入Skill（輸入）
Skill通常要求特定的輸入格式，例如：關鍵字、時間範圍、客戶ID、目標受眾、輸出風格等。
Agent會把上下文擷取出來並整理成Skill所需的參數。
這一步決定了執行是否準確：輸入不對，輸出大概率就會偏。
3）Skill執行得到結果（輸出）
Skill執行後會回傳結構化或半結構化結果，例如：檢索到的項目列表、計算結果、產生的文件文字、介面回傳的狀態碼等。
這些結果能被Agent再次讀回，用於後續決策。
4）Agent校驗輸出並繼續下一步（閉環）
Skill做完不是終點，Agent還會檢查：結果是否滿足約束、是否存在缺失資訊、是否需要二次生成或修正。
如果不滿足，它可能會呼叫另一個Skill（例如「補充檢索」「重寫文案」「格式化輸出」）再迭代。
這就是Skill與Agent的「協同閉環」。
新手常把Skill當成「聊天指令」。但真正的Skill更像「介面」：
輸入越清晰，輸出越穩定；Agent才能可靠地重複執行並完成任務。
例如同樣是「生成郵件」，Skill會要求語氣、長度、收件人資訊、關鍵資訊欄位，
這樣生成出來的內容才不會每次跑偏。
舉例：你讓Agent「給潛在客戶寫跟進郵件，並建立待辦」。
這通常會串聯多項Skill，形成一個完整動作鏈：
1）客戶資料檢索Skill：輸入客戶ID/姓名，輸出姓名、公司、最近一次溝通要點；
2）資訊擷取/總結Skill：輸入溝通記錄，輸出關鍵痛點與已達成事項；
3）郵件生成Skill：輸入語氣（專業/友好）、範本（跟進/促成）、關鍵點，輸出郵件正文；
4）待辦生成Skill：輸入郵件內容與行動建議，輸出待辦項目（負責人、截止時間、步驟）；
5）寫入行事曆/待辦系統Skill：輸入待辦結構化資料，輸出建立成功狀態或連結。
你會發現：Agent看起來像是在「會做銷售工作」，但這背後是Skill模組把真實能力拼成了一個工作流。 Agent負責把這些能力按對的順序用起來。
許多人在做系統整合時會把Skill理解成一段提示詞或一句話指令。
但如果沒有明確的輸入輸出與可執行機制，Agent並不能穩定地重現同樣的結果。
更正確的理解是：Skill是可呼叫的能力單元，提示詞只是幫助你更好地「選擇/組織」它。
可以用三個問題快速判斷：
它能被呼叫嗎？
它需要什麼輸入、輸出是什麼？
執行後是否能讓Agent獲得可用結果（而不僅是解釋）？
滿足這些，就更接近Skill；否則可能只是「建議型文字能力」。
繼續用Agent的「執行迴圈」來理解Skill：Agent負責思考與排程，Skill負責執行具體步驟。 當Agent發現任務需要某項能力時，就會選擇合適的Skill，把需要的參數塞進去，等待它回傳結果， 再把結果拿回迴圈裡做校驗、補充或下一步規劃。
舉例：你讓Agent「幫我寫一封客戶跟進郵件並產生待辦」。
它可能會呼叫不同Skill：
1）檢索客戶資訊（取得姓名、上次溝通要點）；
2）產生郵件草稿（按語氣/長度/範本輸出）；
3）產生待辦清單（把下一步行動拆成項目）。
這些Skill拼起來，才形成「看起來很會做」的Agent行為。
Skill讓Agent從「會說」變成「能落地」，通常帶來三點好處：
更可靠（步驟固定、參數明確）、更可控（知道它在做哪件事）、更可重複使用（同一能力可用於不同任務）。
有人以為Skill就是「提示詞」。其實Skill更像是可呼叫的能力模組（工具/介面/流程）。 沒有清晰的輸入輸出與執行方式，Agent很難穩定重複同樣的效果。
3. Prompt（提示詞）
大眾認知
Prompt（提示詞）就是你用自然語言告訴AI的「一句話需求」。 你提出要做什麼，AI就盡力把結果寫出來。
深入理解
更準確地說，Prompt是你與AI溝通的核心介面。 對於接入了Agent和Skill的系統而言，好的Prompt不只是「讓它生成文字」， 而是要讓它知道什麼時候該呼叫Skill、怎麼填參數、輸出長什麼樣子、失敗怎麼處理。
| 類型 | 示例 | 效果 |
|---|---|---|
| ❌ 普通Prompt | 「幫我寫封郵件」 | AI會自由發揮，資訊缺失時容易亂猜，難以校驗 |
| ✅ 好的Prompt（面向可執行） | 「你是B2B銷售顧問。請寫給技術總監的產品跟進郵件：語氣專業簡潔； 需要先從CRM讀取張三的公司與上次溝通要點； 郵件必須包含：1）一句價值點2）對齊上次溝通的2點確認3）明確的下一步行動； 輸出最後附上3條待辦（含日期格式YYYY-MM-DD）。」 | 觸發條件清晰 + 可呼叫能力明確 + 輸出結構可校驗 |
可以發現Prompt和前面兩個概念（Agent / Skill） 是同一套運作邏輯的另一面：Agent需要Prompt來決定怎麼做，Skill需要Prompt來決定填什麼與怎麼驗。
「Agent的工作迴圈」可以被理解為：
理解任務 → 制定計畫 → 決策呼叫Skill → Skill執行 → 驗證結果 → 繼續調整 → 回報。
而Prompt的作用，就是在每一步都給出規則，讓它不走偏、不憑空猜、能形成閉環。
1）Prompt先定義「目標與成功標準」（為什麼做）
這一步決定了Agent的「評分規則」。Prompt需要告訴它：你要解決的到底是什麼問題、
以及什麼結果算完成。
例如：不是「幫我寫郵件」，而是「郵件必須包含哪些段落、語氣怎樣、長度範圍、最後要給出下一步待辦」。
沒有成功標準的Prompt，Agent就只能做「看起來差不多」的輸出，難以驗證品質。
2）Prompt給出「觸發條件與約束」（什麼時候做什麼）
一個能落地的Prompt通常會寫清：什麼時候該呼叫Skill，什麼時候要提問。
比如：當缺少客戶姓名或日期時，必須先索取，而不是預設「隨便寫個姓名/日期」。
這相當於減少了不確定性：約束越清楚，Agent越穩定。
3）Prompt描述「需要哪些Skill，以及每個Skill的輸入輸出約定」（用什麼工具做）
Prompt裡要明確：
要呼叫哪個Skill、它需要的輸入欄位是什麼、輸入欄位從哪裡來、格式要求是什麼；
同時要明確：Skill輸出應該以什麼結構回傳（例如JSON欄位、列表、表格、固定段落結構等）。
這一步是Prompt真正「工程化」的關鍵：讓Agent把「下一步怎麼做」變成「可以執行的能力呼叫」。
4）Prompt要求「校驗與失敗處理」（做完怎麼判斷對不對）
僅僅產生結果還不夠，Prompt必須寫明校驗規則與失敗策略。常見寫法包括：
- Skill呼叫失敗/回傳空結果：先診斷原因（參數錯誤/權限/網路/資料缺失）再重試或降級；
- 輸出缺少關鍵欄位：必須補全或向使用者提問，不允許硬猜；
- 格式不符合：觸發「格式化Skill/重排Skill/重新產生」。
這讓Agent不會陷入「反覆輸出但不收斂」的迴圈。
5）Prompt定義「最終輸出格式」（輸出要給誰用）
最後Prompt要規定結果如何呈現：哪些欄位必須回傳、欄位名稱是什麼、是否需要結構化結果、
是否需要附帶可追蹤資訊（例如「是否呼叫了Skill、呼叫了哪個Skill、關鍵輸入輸出是什麼」）。
你說：「幫我給潛在客戶寫跟進郵件，並建立待辦」。
如果使用一個「可執行Prompt」，它會明確三件事：
觸發條件：缺少客戶姓名/日期先問；
Skill呼叫：先呼叫「檢索客戶資訊Skill」，再呼叫「產生郵件Skill」，最後呼叫「建立待辦Skill」；
輸出校驗：郵件必須包含價值點確認與下一步行動；待辦必須含截止日期（YYYY-MM-DD）與負責人。
這樣Agent才會從「寫一封像樣的郵件」變成「完成一個完整可落地的工作流」。
很多人寫Prompt只要求「幫我做」，但沒有成功標準、沒有輸入輸出約定、也沒有失敗處理。
結果就是：Agent可能會自由發揮、缺欄位時硬猜、輸出難以校驗，最終你也無法確認「它到底做對了沒有」。
正確思路是：Prompt要像給Agent簽的執行合約，讓它每一步都可判斷、可修正、可重複使用。
1）寫角色與邊界：告訴AI它是誰、你希望它遵循什麼規則（「必須先校驗再輸出」「不得編造不存在的資訊」）。
2）定格式與欄位：規定輸出結構（「回傳JSON，包含欄位A/B/C」或「郵件必須包含三段內容」）。
3）分步驟寫觸發：把任務拆成可執行動作，並給出什麼時候呼叫Skill、什麼時候提問、什麼時候重試。
對比一下：「總結這篇文件」 vs 「用3個要點總結，並且每點不超過20個字，最後輸出關鍵字列表（不少於5個）」——後者可校驗、可重複使用，效果更穩定。
Agent負責思考與排程，Skill負責具體執行，而Prompt負責告訴Agent：何時呼叫Skill、怎麼填參數、怎麼驗結果、最終輸出要長什麼樣子。
4. Memory（記憶）/ MEMORY.md
大眾認知
AI的記事本：用來長期儲存你的偏好和規則。
深入理解
Memory是Agent的長期記憶核心。普通對話往往只在一次工作階段裡有效； 而寫入MEMORY.md的內容，會在Agent每次啟動時被優先讀取， 從而讓它「按你的方式做事」，而不是每次都從零開始問你需求。
例如你告訴Agent：「我偏好簡潔的中文回覆，程式碼用Python」。
如果這條偏好以合適的格式寫入Memory，那麼以後Agent再處理相同類型任務時，會預設遵循這些規則；
你就不需要反覆強調，也更不容易產生「每次回覆風格不一致」的問題。
如果把Agent看作執行者、把Skill看作工具箱，那麼Memory就是Agent的長期設定：
Agent每次開始，會先讀Memory取得你的偏好與SOP，然後在規劃與呼叫Skill時把這些約束帶進去。
因此Memory讓「可執行規則」長期生效。
為了確保Memory真正「可用」，它需要具備前面三點的標準：穩定觸發、輸入清晰、輸出可校驗。 也就是說，寫進Memory的內容要能明確指導Agent接下來怎麼做，而不是一句泛泛的情緒表達。
建議把Memory寫成這種「規則清單」風格：
- 寫作風格偏好：例如「中文且簡潔」「結論先行」「每段不超過3句」
- 格式要求：例如「程式碼用Python」「表格輸出欄位包含A/B/C」「日期格式YYYY-MM-DD」
- 決策SOP：例如「發現資訊不足先提問，不要猜測；給出備選方案並標註風險」
- 長期上下文：例如「我的團隊是B2B交付」「常用工具為XX（如適用）」
與其每次都解釋「你希望它怎麼輸出」，不如一次性把你的工作習慣寫進Memory，讓Agent每次啟動都自動遵循。
你越早把這些規則固化，後續越省心、越一致。
你可以按頻率優先順序來寫：高頻且穩定（長期偏好、固定流程）優先寫入。
Memory不是草稿箱。臨時性的、一次性的任務（如「今天幫我查一下深圳的天氣」）
不要寫入記憶，否則Memory檔案會逐漸臃腫雜亂，導致Agent在長期判斷時被干擾。
原則：固定偏好與長期SOP才寫入，臨時任務忽略。
如果答案是：
1）這條規則未來還會反覆用到嗎？
2）它能穩定改變輸出格式/風格/執行策略嗎？
3）它不會隨著時間頻繁變化嗎？
滿足越多，就越適合寫入Memory。否則就放在本次對話的指令裡即可。
Memory讓Agent形成長期一致的工作方式：把穩定偏好與SOP固化進去，而把臨時任務留在當次執行。
5. Soul（靈魂）/ SOUL.md
大眾認知
AI的「個性設定」與行為底線：決定它「該怎麼做、不能怎麼做」。
深入理解
SOUL.md定義Agent的行為規則、價值觀和操作邊界。
它是Agent的「底層憲法」——哪些能做、哪些絕對不能做，在這裡寫清楚。
因此SOUL不只是風格偏好，它直接影響Agent的安全邊界與合規輸出。
如果說Memory是「記住了什麼」，那Soul就是「規定了成為什麼樣的AI」。 例如：只回答產品相關問題；財務操作必須二次確認；禁止索取密碼或敏感憑證； 涉及法律/醫療時必須給出免責聲明並引導人工/專業管道等。
SOUL.md的設定會直接決定Agent在高風險情境下的「拒絕方式」和「替代路徑」。
如果部署為團隊工具或涉及企業資料，SOUL設定不當可能導致越權、越界或合規風險。
因此在上線前，務必認真設定此檔案，並用測試案例驗證邊界是否生效。
建議你把SOUL寫成「可執行的規則清單」，並涵蓋以下幾類內容：
- 允許做什麼：Agent的工作範圍與領域邊界（例如：只處理產品諮詢/內部流程）。
- 禁止做什麼：明確高風險行為的硬拒絕（例如：索取密碼/金鑰；承諾不確定結果；繞過權限）。
- 需要確認的動作：涉及轉帳、退款、合約、權限變更等必須二次確認或走審批的規則。
- 輸出方式與語氣：例如必須禮貌、不得人身攻擊、不得使用威脅性表達。
- 遇到邊界如何處理：無法完成時給出替代方案（例如：記錄並轉交人工/建議諮詢專業部門）。
假設你為公司設定了一個客服Agent，它的SOUL.md可能包含：
• 永遠保持禮貌，不使用辱罵或負面定性措辭；
• 不承諾退款或賠償，只能說「我會記錄並回饋/轉交處理」；
• 遇到法律相關提問，統一回覆「請諮詢法務部門/專業人士」；
• 遇到索取密碼、驗證碼、金鑰：直接拒絕，並引導使用者走正規流程驗證。
設定之後，無論使用者怎麼引導，Agent都不會越界。
修改Soul後建議用幾個測試問題驗證：哪些應該拒絕、哪些應該需要確認、哪些可以正常回答。
你可以準備6類測試問題來驗證Soul是否生效：
1）領域外問題：Agent是否拒絕或轉導？
2）高風險請求：是否明確拒絕？
3）需要二次確認的動作：是否先確認再執行？
4）敏感資訊索取：是否拒絕並給出安全替代流程？
5）合規/免責聲明：是否按規則輸出？
6）「誘導越權」：使用者要求跳過流程時是否堅持邊界？
SOUL.md決定Agent的「底線與邊界」：它讓AI在執行時既有原則、又可預期， 從而在團隊與業務情境中更安全、更可靠。
進階概念（可選）
以下三個概念會讓你更「懂自動化」。它們並不是另起爐灶的知識點，而是把前面講過的 Agent / Skill / Memory / Soul / Prompt 這套運作邏輯，真正落實到「能跑起來、能串起來、能穩定整合」的層面。 新手可以先跳過；當你開始做多步驟流程、接入外部服務或排查資料傳遞問題時，再回來看會很省時間。
🔀 1）Workflow（工作流程）
Workflow（工作流程）可以理解成一條可重複使用的執行路線：把多個步驟串起來，讓系統按順序完成一個目標。 如果說Agent是「會想、會執行的同事」，那Workflow就是「給這位同事排好的任務佇列和銜接方式」。 它解決的是：當任務不是一句話就能完成的時候，怎麼穩定地把多步執行做成鏈路。
一個常見的Workflow往往包含以下元素（你可以按這個思路去理解EasyClaw的多步驟能力）：
- 步驟清單：第1步做什麼、第2步做什麼……每一步的職責邊界清楚。
- 輸入與輸出：每一步都應該產生可被下一步使用的結構化結果，而不是只給「文字描述」。
- 條件與分支：例如「如果缺少關鍵欄位就先提問/先補檢索」，否則直接進入下一步。
- 校驗與失敗處理：例如「解析失敗就重試或退回到備用方案」。
- 彙總輸出：把最終結果以你能用的形式交付（清單、報告、任務列表、通知內容等）。
Workflow與前面概念如何對齊？可以用一句話串起來：
Agent負責決策與排程，Skill負責具體執行，Memory/Soul負責長期規則與邊界，Prompt負責告訴它「怎麼做」，Workflow負責把這些步驟按順序連成鏈路。
舉例：你要完成「把使用者投訴升級為工單，並通知負責人」。 一個合理的Workflow可能像這樣：
- 採集輸入：從表單/訊息中取得投訴內容、使用者資訊、時間軸。
- 資訊擷取：用Agent將投訴要點結構化（例如：問題類型、影響範圍、關鍵時間點）。
- 規則判定：根據Soul/規則判斷是否屬於高優先順序，需要升級還是先收集更多資訊。
- 呼叫工單建立Skill：把結構化欄位填入工單系統介面，產出工單編號。
- 呼叫通知Skill：將工單編號、要點摘要傳送給負責人（飛書/郵件/IM）。
- 結果校驗：確認工單建立回傳成功狀態、通知是否已發送。
- 彙總回饋：向使用者或管理端輸出「已建立工單 + 連結/編號 + 下一步處理建議」。
你會發現：Workflow解決的不是「怎麼寫一段解釋」，而是「如何把多個工具呼叫與校驗步驟可靠地串起來」。 當你開始做複雜流程（尤其跨系統：IM + 工單 + 資料庫）時，Workflow就會成為你最依賴的能力。
📦 2）JSON（資料交換格式）
JSON是Agent與外部工具、API之間傳遞資料的標準格式。 在多步驟自動化裡，JSON的作用非常關鍵：它讓「下一步能不能拿到正確資料」變成可驗證的問題， 而不是「靠直覺讀懂一段自然語言」。
你可以把JSON理解為：系統內部的「結構化資料袋」。裡面裝的不是散句子，而是明確欄位與類型，例如： 工單標題、使用者ID、優先順序、截止日期、通知內容等。
在EasyClaw的工作鏈路中，JSON典型出現在這些位置：
- Skill的輸入與輸出：Skill往往需要特定欄位作為輸入，回傳結構化結果供Agent決策。
- API呼叫參數：例如呼叫飛書介面時，參數需要按欄位組織成JSON。
- 步驟間傳遞資料：Workflow某一步的輸出JSON會被下一步讀取。
那為什麼很多問題看起來「像Agent不會做」，其實是JSON的原因？ 常見情況包括：
- 欄位名稱不一致：例如期望輸入是
user_id，但實際給了userId。 - 欄位缺失：例如缺少必填欄位，導致介面回傳錯誤。
- 型別不匹配：例如日期應為字串卻傳成了數字，或應為陣列卻給了文字。
- JSON格式錯誤：缺引號、少括號、末尾多逗號等，導致解析失敗。
因此你排查整合問題的最佳順序通常是： 先看JSON，再看Prompt，再看Agent的判斷邏輯。 因為JSON是「能不能跑通」的底座。
🔑 3）API Key（接入金鑰）
API Key是存取AI模型或第三方服務時的身份憑證。 沒有正確的API Key，系統通常就無法呼叫對應模型或服務；就算Agent推理得再好，也只能停留在「無法執行」的狀態。
在EasyClaw情境裡，你需要區分兩類情況：
- 預設使用官方能力/積分的情況：新手一般無需自備Key，因為平臺已經幫你完成了接入。
- 接入自定義模型/自定義服務的情況：你需要在相應位置填寫API Key，並讓對應的Agent/Skill指向該模型。
API Key不僅是「能不能用」，還影響「用什麼能力、成本與穩定性」：
- 選擇模型：不同Key/不同模型可能帶來不同推理品質、速度與輸出格式表現。
- 成本控制：有的平臺會按用量計費，Key對應的帳戶/額度會影響可用成本。
- 權限邊界：某些服務的Key可能只允許有限介面呼叫，導致特定Skill執行失敗。
排查「Skill呼叫失敗」的常見思路包括： 確認Key是否填寫正確、Key是否過期/額度不足、該Key是否具備呼叫權限。 如果API回傳鑑權錯誤（401/403類），優先懷疑API Key設定問題。
什麼時候必須認真看這些？（快速對照）
- 你要做多步驟自動化：Workflow會決定鏈路能否穩定跑通。
- 你要對接飛書/企業系統/外部介面：JSON決定資料能否正確傳遞、能否被解析。
- 你要接入自己的模型或自定義服務：API Key決定能否呼叫到對應能力。
- 你在排查「能解釋但不能執行」或「執行失敗但不知原因」：通常從Workflow串聯、JSON結構、API Key權限這三處依次排查會最快。
Workflow 讓步驟按順序可靠執行，JSON 讓每一步傳遞的資料結構正確可用， API Key 讓工具與模型真的能被呼叫。三者合起來，你的自動化才能從「看起來智慧」變成「真的能落地」。
Agent = 有執行力的AI同事
Skill = 可呼叫的能力模組（工具/介面/流程）
Prompt = 告訴Agent怎麼做（規則、觸發、輸出、失敗處理）
Memory = 長期偏好與SOP（讓規則長期生效）
Soul = 行為憲法與邊界（允許/禁止/確認策略）
Workflow = 多步驟接力賽的執行路線
JSON = 結構化資料交換格式（保證欄位可用）
API Key = 第三方/模型接入憑證（保證能力可呼叫）