平台技能 — 每個代理程式都具備的通用能力

原則 — 平台技能是 方法，租戶技能是 您的業務。 共享程式庫包含一般的工作方式（研究競爭對手、閱讀法規、評估潛在客戶）。任何與您的產業或您的資料相關的內容都應放在您自己的技能中。更多資訊請見 設計原則。

每個代理程式都預設擁有一組 平台技能，無需特別賦予。它們是一般的工作方法，會像其他技能一樣按需載入，且您無需逐一附加它們。

為什麼它們不是單純的「代理程式上的更多技能」

一個包含數百種方法的程式庫無法放入提示詞中。完整列出所有方法會顯著影響選擇效果：當完整列出 207 個技能時，模型選對的機率為 30%；當列表先縮減至最相關的 15 個時，選對機率為 51%。因此，平台會在列出之前先進行檢索。

檢索會針對當前的訊息，同時在兩個程式庫（共享程式庫與您的程式庫）中運行。您的技能不會因為與一般技能共享空間而處於劣勢：在將 18 個真正具有產業專屬性的技能混入 193 個一般技能中進行測量時，產業專屬技能的識別率 更高（86% 對比 79%），因為產業詞彙與一般方法詞彙在向量空間中相距較遠。

大約在八個技能以下不會進行檢索——會直接顯示完整列表。 在此規模下，列表已經準確，而檢索反而可能引入新的失敗情況：正確的技能未出現在短列表中，導致模型憑藉自身知識作答，且日誌中無任何跡象。

您能控制與不能控制的

使用英文撰寫

平台技能以英文撰寫——包括 description、instructions、menu_label 以及生成的觸發詞組。

這不僅是為了示範。在對相同的 193 個中文技能程式庫進行測量時，將三個平台技能從中文切換為英文 提高了每個技能的識別可靠性：競爭對手研究 75% → 83%，政策閱讀 83% → 100%，潛在客戶資格驗證 50% → 62%。英文技能在向量空間中與大量中文技能相距較遠，因此更容易被選出。（這種優勢來自於 不同，而非英文本身——在純英文程式庫中，這種優勢會消失。）

語言並不影響模型能否呼叫技能：無論是自託管的 35B 模型還是託管模型，都能從中文和英文的描述中發出正確、格式良好的 load_skill 呼叫。選擇英文是產品決策，而非技術上的權宜之計。

您自己的技能則另當別論——使用您的客戶所使用的任何語言撰寫。

讓平台在技能開工前先去調研

技能可以要求平台先把材料備好再開工。在 instructions 的最上面寫這一行：

PREFETCH: web x4

平台會把訪客那句話變成這麼多條檢索式、跑一遍，再把一張編號的事實表交給技能去引用。只寫 PREFETCH: web 表示用預設的兩條；不寫這一行就什麼都不搜。

只在問題有好幾個面向的時候才要更寬的。 一次產品調研——價格、限制、匯出——用窄的那一版實測是 2957 字配 5 條出處，裡面每個價格都是任何來源裡都找不到的具體數字；改成四條檢索式之後，同一個問題帶回 17 條出處。起草、改寫、算帳的技能則應該什麼都不聲明：一次它不需要的檢索，就是白花的時間和錢。

這替代不了把規則寫下來，但它是真正起作用的那一半。同一個技能的指南裡本來就寫著絕不寫出材料裡沒有的價格，它照寫不誤。改變答案的是材料，不是那句話。

撰寫真正會被使用的技能

遵循與任何技能相同的規則，外加一個僅在規模化時顯現的規則：

• description 說明 何時 使用，並使用客戶會使用的詞彙。 這是檢索匹配的依據。
• instructions 以該技能 不 涵蓋的內容結尾。 在數百個技能中，近鄰技能不可避免；這句結尾是讓模型意識到自己開啟了錯誤技能的唯一方式。
• 觸發詞組由系統為您生成——八種以自然語言表達的詢問方式——且您可以編輯它們。它們會被用於匹配，但不會顯示給訪客，且您的編輯不會被重新生成所覆蓋。

在撰寫後有一個值得執行的檢查：詢問程式庫，其自身的每個觸發詞組會檢索到哪個技能。如果某個技能自身的觸發詞組總是返回 其他 技能，表示該技能雖然在程式庫中，但無法被觸及——將其與總是勝出的技能合併，或讓兩者明確說明它們如何不同。