我發現我在設計我的 AI 工具時是反向的。 這是一個例子。這是我的新聞通訊處理 Chain : 閱讀電子郵件，調用新聞通訊處理器，提取公司，然後將它們添加到 CRM。這涉及四個不同的步驟，每處理一千封新聞通訊的成本為 3.69 美元。 之前：新聞通訊處理 Chain（第一張圖片） 然後我創建了一個統一的新聞通訊工具，將所有內容結合在一起，使用 Google Agent Development Kit，這是 Google 用於構建生產級 AI 代理工具的框架：（第二張圖片） 為什麼統一的新聞通訊工具更複雜？ 它在單一界面中包含多個操作（處理、搜索、提取、驗證），實施狀態管理以跟踪使用模式並緩存結果，內置速率限制，並生成帶有元數據的結構化 JSON 輸出，而不是純文本。 但這裡有一個反直覺的部分：儘管內部更複雜，統一工具對 LLM 的使用卻更簡單，因為它提供了一致的、結構化的輸出，這些輸出更容易解析，即使這些輸出更長。 為了理解影響，我們對每個測試場景進行了 30 次迭代的測試。結果顯示了新架構的影響：（第三張圖片） 我們能夠將令牌減少 41%（p=0.01，統計上顯著），這線性轉化為成本節省。成功率提高了 8%（p=0.03），我們能夠在 30% 的時間內命中緩存，這又是一項成本節省。 雖然單個工具產生了更短的、“更乾淨”的響應，但它們迫使 LLM 更努力地解析不一致的格式。來自統一工具的結構化、全面的輸出使 LLM 處理更高效，儘管這些輸出更長。 我的工作流程依賴於數十個專門的 Ruby 工具來處理電子郵件、研究和任務管理。每個工具都有自己的界面、錯誤處理和輸出格式。通過將它們整合成元工具，最終性能更好，並且節省了大量成本。您可以在 GitHub 上找到完整的架構。