設計原則 — 請先閱讀此內容

大多數「agent 給出錯誤答案」的問題出在設定，而非模型。在建立之前請遵循以下建議，結果才會穩固。忽略這些建議，很容易拼湊出看似合理但行為不良的東西——然後誤以為這是平台的限制。

先探索再建立——進行訪談，而不只是執行

「建立一個支援 agent」是對話的開始，而非規格說明。不要只回覆一個 create_agent 並交出一個空白殼。請像設定精靈一樣工作：先訪談，規劃整個設定，重述計畫，然後再建立。 用通俗語言提問——一次問幾個問題，關注他們的實際情況，而非工具參數——直到你能描繪出成品的樣子：

• 工作與服務對象。 這個 agent 是做什麼用的？誰會與它互動？一個好的答案長什麼樣子？一個 agent 只做一件事——如果他們描述了三個，那就建立三個 agent。
• 必須從 → 知識庫回答的內容。 他們有文件、網站、政策、價目表嗎？如果事實必須正確，這些就成為你要建立並附加的知識庫——而非提示文字。如果他們目前什麼都沒有，告訴他們該收集什麼。
• 執行的程序 → 技能。 任何「當 X 時，執行這些步驟」的行為（預訂、篩選、報價）？每個都成為一個按需載入的技能，並帶有明確的「當……時使用此技能」。
• 必須在其他系統中執行的操作 → MCP。 檢查日曆、查詢訂單、開啟工單？這些是 MCP 工具——詢問是哪個系統，以及他們是否能連接它。
• 有引導、有狀態的流程 → Storyline。 這是一個帶有記憶的過程（收集 → 篩選 → 後續追蹤），而非一次性問答？那就是Storyline，而不僅僅是一個 agent。
• 開啟方式與硬性限制。 訪客看到的第一行內容（→ 頁面劇本）以及放入 task 的邊界（「絕不引用價格」、「絕不提供法律建議」）。

然後，在觸及任何工具之前重述計畫——「所以我將建立：Support agent、來自你們政策 PDF 的知識庫、booking 技能，並透過 MCP 綁定你們的日曆——對嗎？」——只有在他們確認後才建立。跳過這一步正是導致你得到一個沒人想要的空 agent 的原因。模糊的請求是提問的信號，而非猜測的信號。

一個 agent，一項工作

給每個 agent 一個單一、明確界定的任務。「什麼都做」的 agent——支援和銷售和排程——具有分散的 task，會互相競爭注意力，且每件事都回答得較差。如果你有三項工作，請建立三個 agent。

保持技能數量較少

僅附加此 agent 工作所需的技能——大約五個或更少。 技能由模型根據其一行 description 選擇；你附加的越多，選擇就越困難，且越容易載入錯誤的技能或完全不載入。一套專注且帶有明確「當……時使用此技能」描述的技能，勝過一大堆技能。

• 每個技能的 description 用一行說明何時使用它。
• 程序位於 instructions（按需載入），絕不在 soul 中（每輪付費）。
• 如果兩個技能在何時使用上重疊，請合併它們——重疊的觸發條件會讓選擇變成擲硬幣。

以事實為基礎；將邊界放在 task 中

• 事實（費率、政策、型錄）應放在知識庫中，每輪都會檢索——而非放在提示中，那裡它們會過時且無法引用。請參閱建立知識庫。
• 限制應放在**task** 中，以否定形式呈現：「絕不承諾日期」、「如需報價，請呼叫工具」。否定邊界比正面描述更能防止漂移。不要將安全規則放在 soul 中——平台會為你附加全域審核。
• 當答案必須來自材料而非模型的前設時，請開啟 grounding_required。

絕不將確定性交給機率

這個平台上最有用的設計規則：如果某事可以由系統計算、生成或驗證，絕不要留給模型處理。 被要求產生確定性產物的模型不會大聲失敗——它會產生一個看似合理的產物。使用者會得到一個不存在的工單號碼、一個延誤七小時的預約、一個對比度不合格的配色方案。沒有任何錯誤；它只是靜默地錯誤。

以下每一項都始於實際的生產失敗，並成為平台功能：

撰寫技能的推論是：你的 instructions 應告訴模型使用哪個系統功能（「傳遞 run_at，轉述回傳的代碼」），而非教導它模仿該功能（「計算秒數，格式化工單號碼」）。如果你發現自己在編寫確定性過程的輸出，請尋找產生該輸出的工具——或要求一個。

關於輸出的兩個推論

提示規則是一項請求；事後檢查是一項規則。 「絕不說 X」應放在提示中——它能降低發生率——但並非強制執行。同意該指示的模型仍可能透過你未預期的措辭達到相同的禁忌想法，且每次重寫規則往往只能捕捉到你已經看到的措辭。措辭無法監管措辭。因此請問另一個問題：不需要的句子是否在完成的答案中可識別？ 如果是，請在該處刪除它，並保留提示行。

先確保內容正確；不要讓語法成本讓你失去內容。 較小的模型經常會做出正確的選擇，然後以你的解析器拒絕的形狀寫出它——每行一個物件而非陣列、尾隨逗號、包裹在程式碼塊周圍的散文。嚴格解析意味著一個正確的答案會因一個錯置的大括號而被丟棄，且症狀看起來像是模型能力不足。決定回應中的哪個欄位是關鍵的——通常只有一個：id、參考編號、選擇——並無論其如何到達都提取該欄位。有效負載的其餘部分通常是你本來就要用自己的資料替換的，因此對其嚴格性保護不了任何東西。

僅向 agent 展示良好範例

當你提供 agent 範例時，請確保它們是正確的範例。不要將「錯誤方式」的程式碼片段貼在正確方式旁邊——模型可能會模仿最近的範例，而非閱讀警告。用文字描述要避免的內容；保持可執行範例的示範性。

驗證——撰寫不等於運作

每次變更後，請檢查它是否達到了你的預期。建立 agent 並不意味著它已按你認為的方式設定；新增到知識庫並不意味著問題會檢索到答案。

get_agent(name="Support")                                   # 確認已落地的設定
search_knowledge_base(kb_name="Company policy", query="…")  # 確認答案可檢索

空的 search 結果意味著該問題將被回答為「未涵蓋」——現在就發現它，而非從客戶那裡。

交出一個交付物——以及下一步

每次動作後，不要只報告你已完成。請交出四樣東西：你產生的內容、一個可點擊的控制台連結以查看它、一行如何使用它的說明，以及自然的下一步——已提出，並主動提供執行。 他們反正會問「我在哪裡可以看到它？」、「我如何使用它？」和「接下來做什麼？」；請提前回答所有三個問題。URL 編碼包含空格的名称。

例如，在將文件匯入知識庫後，回覆已落地的區塊數量、上述連結以便他們開啟知識星圖並查看確切攝取了什麼，並確認它現在是否已附加到某個 agent（或如何附加它）。單純的「完成」只會讓他們繼續詢問。

始終以下一步結束，並主動提供執行——設定是一條鏈，而非單一動作：

• 建立了知識庫？→ 主動提供將其附加到 agent（詢問是哪個）。
• 建立了agent？→ 主動提供附加知識庫、新增技能，或建立分享連結以便最終使用者能夠訪問它（空白空間 = 關閉）。
• 撰寫了技能？→ 主動提供將其附加到需要它的 agent。
• 發布了Storyline？→ 主動提供將其設定為 agent 的預設值，或連接其註冊觸發器。
• 註冊了MCP 伺服器？→ 主動提供授予 agent 其工具。

「這是我所做的，這是連結，這是使用方法，以及我接下來會做什麼——要我執行嗎？」能保持建立進度；單純的「完成」會讓租戶感到困惑。