系統提示正在過時！ 這裡有一個來自構建現實世界代理的反直覺教訓： 撰寫巨大的系統提示並不會改善代理的表現；它往往會使情況變得更糟。 例如，你添加了一條有關退款政策的規則。然後是有關語氣的規則。再來是有關何時升級的規則。不久之後，你就擁有了一本 2,000 字的說明手冊。 但我們學到的是：大型語言模型在處理這些方面非常差。 最近的研究也證實了我們許多人所經歷的情況。存在一種「指令詛咒」。你在提示中添加的規則越多，模型在遵循任何單一規則時的表現就越差。 這裡有一個更好的方法：上下文條件指導。 與其使用一個巨大的提示，不如將你的指示分解成模塊化的部分，只有在相關時才加載到大型語言模型中。 ``` agent.create_guideline( condition="客戶詢問退款", action="首先檢查訂單狀態以查看是否符合條件", tools=[check_order_status], ) ``` 每個指導有兩個部分： - 條件：什麼時候加載？ - 行動：代理應該做什麼？ 魔法在幕後發生。當查詢到達時，系統評估哪些指導與當前對話狀態相關。 只有那些指導會被加載到模型的上下文中。 這使得大型語言模型的認知負擔最小化，因為它不再需要同時處理 50 條規則，而是專注於當前實際重要的 3-4 條。 這導致了顯著更好的指令遵循。 這種方法稱為對齊建模。根據上下文結構化指導，使代理保持專注、一致和合規。 與其等待一個所謂更小的模型，重要的是擁有一種尊重大型語言模型基本運作方式的架構。 這種方法實際上在 Parlant 中實施 - 一個最近流行的開源框架（13k+ 星）。你可以查看完整的實現並自己嘗試。 但核心見解無論你使用什麼工具都適用： 對上下文工程更加有條理，並實際解釋你期望在你關心的特殊情況下行為是什麼。 然後代理可以變得真正專注和有用。 我已經在回覆中分享了 repo 連結。

上下文工程與提示工程： 在大型語言模型（LLMs）的早期，巧妙的提示是成功的秘訣。 但如果你今天正在構建嚴肅的 AI 代理，僅僅依賴提示工程是行不通的。 你需要上下文工程。 原因如下： - 提示是關於你所說的內容 - 上下文工程是關於模型所看到的內容 而它所看到的內容比以往任何時候都更重要。 上下文中的每個標記都會消耗注意力。上下文越大，模型越容易分心、忘記或變慢。 就像人類一樣，LLMs 也會失去專注。 這就是為什麼好的代理不會將所有內容都丟進上下文中。他們： 1️⃣ 策劃有用的內容 2️⃣ 總結舊的內容 3️⃣ 按需提取所需的內容（及時） 4️⃣ 為自己寫筆記 5️⃣ 在需要時將工作委派給子代理 這不是理論，而是像 Claude Code、現實世界的代理和有效的記憶工具等系統今天已經在運作的方式。 上下文工程正成為任何構建長期、多步驟代理的人的核心技能。 如果你對代理認真，開始將上下文視為有限的高價值資源。 並以此方式進行工程。 這篇文章的靈感來自 Anthropic 最新的博客，內容相同。 我強烈推薦閱讀；鏈接會在下一條推文中分享！

類似 Figma 的畫布來構建和測試 AI 工作流程！ 使用 Postman 的 AI 代理構建器，超過 100,000 個 API 變成您的代理工具。 還有一個可視化的無代碼畫布，可以快速構建和測試多步驟的 AI 工作流程。 為了更好地理解，想像一下您正在構建一個客戶支持工作流程： - 它接受用戶查詢。 - 檢索相關上下文（來自過去的對話、文檔等） - 決定上下文是否相關（這是一個條件）： → 如果是，它會生成一個回應並返回給用戶。 → 如果不是，它會通知人類支持團隊。 如下面的視頻所示，您可以在 Postman 的 AI 代理構建器內構建這些工作流程並測試所有集成，以確保它們按預期運行。 這樣，AI 開發者只需做他們應該做的事情：構建代理工作流程並改進它們，而不必擔心集成和測試挑戰。 要開始，請查看下一條推文中的鏈接！ 感謝 Postman 與我合作發表這篇文章！