Albert zhang

我們建立 AgentForge 來解決自己的問題。以下是 6 個月生產環境多代理部署的經驗。

經驗 1：從失敗模式開始，而非成功案例

每個人都會設計快樂路徑，但在多代理系統中，失敗模式會成倍增加：

  • 代理 A 成功但耗時 30 秒 → 代理 B 等候逾時
  • 代理 A 回傳格式錯誤的 JSON → 代理 B 解析時當機
  • 兩個代理嘗試寫入同一個檔案 → 競爭條件

先以「什麼會壞掉」來設計你的協調架構。

經驗 2：可觀測性不是可有可無

你需要每個代理的執行追蹤，不只是日誌，還要有結構化的追蹤，顯示：

  • 輸入參數（確切值而非摘要）
  • 任何後處理前的輸出
  • 帶有退避的重試次數
  • 斷路器狀態轉換

我們將此功能建置於 AgentForge 的執行引擎中。每次執行都會產生可重播除錯的 JSON 追蹤。

經驗 3：代理需要記憶，但不需要無限記憶

無限制的對話歷史會降低效能。我們使用滑動視窗 + 摘要策略：

  • 保留最後 N 輪原始內容
  • 將較舊的輪次摘要成結構化上下文
  • 讓代理透過記憶儲存明確「記住」關鍵事實

經驗 4：成本最佳化就是架構

執行 5 個代理 × 4K tokens × GPT-4 成本會快速上升。我們的做法：

  • 路由代理決定要呼叫哪個專家（使用較便宜的模型）
  • 專家代理只在需要時才使用較大模型
  • 對確定性查詢進行回應快取

結果：比原始實作降低 60% 成本。

技術堆疊

  • Python 3.11+
  • Pydantic 用於結構驗證
  • AsyncIO 用於並行代理執行
  • SQLite/Redis 用於狀態持久化
  • WebSocket 用於即時監控 UI

開源。沒有創投提案。只是能運作的程式碼。

https://github.com/agentforge-cyber/agentforge-mvp

加入我們：https://discord.gg/Qy6HKHsqP

由 AgentForge 團隊於 2026-08-01 發佈。