Future AGI：把模擬、評估、護欄與閘道收進同一個自架堆疊
Open-source, end-to-end platform for evaluating, observing, and improving LLM and AI agent applications. Tracing · Evals · Simulations · Datasets · Gateway · Guardrails. Self-hostable. Apache 2.0.
秒懂
- 它是什麼？
- Future AGI 是一個 Apache 2.0 的 LLM 與 agent 平台，把 tracing、evals、simulations、datasets、gateway、guardrails 六件事放在同一份 Docker Compose 堆疊裡。它的價值在於省掉拼接多套工具的功夫，代價是你要自己承擔整套服務的維運。
- 適合誰用？
- 如果你的團隊已經在跑 LLM 應用，而且願意維護一組 Docker Compose 服務，Future AGI 值得先進 staging 試一輪：用 ./bin/install 起堆疊，接上 traceai_openai 的 instrumentor，看 trace 與 eval 結果是否真的回到同一條回饋路徑上。若你只想在既有 observability 後端加一層評分，或無法承擔自架資料庫與升級遷移的人力，這個專案就不合適，改用單一用途的評估套件會更省事。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它想解決的是工具鏈斷裂，不是單點功能不足
多數團隊在 agent 上線後遇到的問題，不是缺少某一個評估指標，而是評估、觀測、護欄各自獨立，訊號無法回流到下一次改版。README 的開場把這件事講得很直白：團隊最後是在拼接 evals、observability 與 guardrails，而這條迴路從來沒有閉合。Future AGI 的定位就是把 simulate、evaluate、protect、monitor、optimize 這五個階段收進同一套系統，讓資料在其中循環。
目標讀者是有 LLM 應用已經在生產環境跑、但評估流程還散落在筆記本與臨時腳本裡的工程團隊。它假設你願意自己跑服務，因為自架路徑需要 Docker Desktop 或 Docker Engine 加上 Docker Compose。若你只是想在單一模型呼叫上算幾個分數，這個平台的份量明顯過重。
六個模組共用一條資料路徑，而不是六個獨立產品
從 README 的模組清單可以看到，這個平台同時包含 tracing、evals、simulations、datasets、gateway 與 guardrails。它們不是各自獨立的服務，而是共用同一份 trace 資料：instrumentor 把應用端的呼叫寫成 OpenTelemetry 格式的 trace，評估與護欄讀同一批資料，模擬產生的案例再回到資料集裡。
接入方式是 Python 端的 register 加上框架專屬的 instrumentor。README 給的例子是 from fi_instrumentation import register 與 from traceai_openai import OpenAIInstrumentor，註冊時指定 project_name，然後呼叫 instrument()，既有的 OpenAI 呼叫程式碼不需要改寫就會被追蹤。專案也標示了 50+ framework instrumentors 與 OTel 相容的 HTTP 介面，意味著你可以只替換堆疊中的某一層，而不是整包接受或整包放棄。
gateway 是用 Go 寫的，README 給出的數字是加權路由約 9.9 ns、在 t3.xlarge 上約 29k req/s、開啟護欄後 P99 不超過 21 ms，並註明這些數字可透過隨附的 benchmark harness 重現。這些是專案自己公布的量測，我沒有實機驗證，把它們當成專案的宣稱而非中立事實來讀。
安裝只有一行，但升級才是有成本的地方
自架路徑的指令是 git clone 之後進到目錄執行 ./bin/install，Windows 用 .\bin\install.ps1。安裝腳本拉的是已發布的映像檔，不在本機建置原始碼，裝完開 http://localhost:3000。正式環境則改用 ./deploy/setup.sh 產生必要的 secret 並鎖定映像檔版本。
真正需要注意的是升級段落。README 明講：在已經含有 trace 的安裝上升級時，要在新堆疊健康之後，另外執行 ./bin/property-catalog-backfill --execute（Windows 為 .\bin\property-catalog-backfill.ps1 -Execute），把尚未啟用的 unified property catalog 初始化。一般重啟不會觸發歷史掃描，這個指令只會用 Docker Compose 已經選定的映像檔，不會去拉分支或原始碼，會跳過已啟用的 workspace，並透過 catalog 的持久 ledger 續跑。掃描範圍被限制在自架 supervisor 允許的 active workspace 與 project，以及 366 天的滾動來源視窗。
換句話說，這個平台對時間視窗有明確假設。若你的 workspace 數量多、trace 歷史又長，升級不是重啟容器就結束，而是要規劃一次有界的回填作業。這是自架路線最容易被低估的一塊。
nightly 標籤是現在最大的採用風險
README 最上方掛著一行警告，說明這是 nightly release、供早期測試、預期會有粗糙邊角，穩定版即將推出，遇到問題請開 issue。這件事比任何功能清單都更影響採用決策。
從 release 紀錄看，v1.37.1、v1.37.0、v1.36.1 分別落在 2026 年 9 月 8 日與 9 日，兩天內三個版本，節奏與 nightly 的自我描述一致。這代表介面與行為仍在快速變動，把這個平台放進需要長期穩定性的生產路徑前，要先確認你鎖定的映像檔版本對應的是哪一種發布通道。
另一個限制在資料層。回填指令的 366 天滾動視窗是設計上的邊界，不是可以隨意調大的參數；如果你的合規要求是保留更久的 trace，或需要對更久以前的資料重新評分，這個視窗會直接擋住你。README 沒有說明超過視窗的資料如何處理，這點在採用前應該直接向專案確認。
與 Langfuse、Braintrust 這類工具的差別在哪
README 自己點名了替代組合：Langfuse、Braintrust、Helicone、Guardrails AI 再加上一套自製模擬器。差別不在於單項功能深淺，而在於整合方式。
Langfuse 一類的工具重心是 tracing 與觀測，評估通常掛在同一個後端上，但護欄與模擬往往要靠外部服務或自己寫。Braintrust 走的是評估與實驗管理路線，離線評測的流程完整，線上即時攔截則不是它的核心。Guardrails AI 專注在輸出檢查這一層，本身不負責 trace 儲存與評估流程。Future AGI 的做法是把這些層放進同一個堆疊，讓 trace 同時是評估輸入與護欄依據。
代價是耦合。你接受的是整組服務與它的資料模型，而不是可以逐項替換的函式庫。README 提供了 OTel 與 OpenAI 相容 HTTP 作為逃生口，讓你在某一層換回自己的元件，但核心的 trace 儲存與 catalog 結構仍屬於這個平台。
授權與長期維護的實際盤算
授權是 Apache-2.0，核心可自架，README 強調每個 evaluator、prompt、trace 都可檢視，沒有黑箱評分。對需要資料主權的團隊，自架路線把 trace 留在自己的基礎設施內，這是它相對雲端方案的直接好處。
維護成本主要來自兩端。一是服務本身：Docker Compose 堆疊、Go 撰寫的 gateway、Python 端的評估元件，都要跟著上游版本走，而 nightly 節奏意味著你跟版越緊、變動越多。二是資料遷移：每次升級若牽涉 catalog 變更，就要跑一次回填，並確認它能在你的 workspace 規模下於合理時間內完成。
授權條款允許商業使用，但這不構成法律意見。若你要把平台包進對外產品，或對授權邊界有疑慮，應該自行確認 Apache-2.0 的條文，而不是依賴 README 的敘述。
該不該現在就導入
適合的對象是已經有 agent 在生產環境運行、評估流程散落各處、而且有維運容器化服務能力的團隊。對這類團隊，把 trace、eval、護欄收進同一條迴路所省下的整合工，通常大於自架的成本。
不適合的對象也很清楚。只想在既有 observability 後端加一層評分的人，導入整套平台是過度投資；沒有能力處理 Docker Compose 升級與資料回填的人，會在第一次版本更新時卡住；需要保留超過 366 天 trace 並對舊資料重新評分的人，目前的設計視窗不符合需求。
要驗證的第一件事是版本通道：確認你要部署的映像檔對應的是 nightly 還是穩定發布，README 明說穩定版尚未推出。第二件事是回填指令在你實際資料量下的行為，先在 staging 跑一次 ./bin/property-catalog-backfill --execute 並記錄耗時。第三件事是接入成本，用 traceai_openai 的 instrumentor 對一個真實 agent 註冊 project_name，確認 trace 與評估結果確實落在同一個專案底下，而不是各自為政。
編輯結論
如果你的團隊已經在跑 LLM 應用，而且願意維護一組 Docker Compose 服務，Future AGI 值得先進 staging 試一輪：用 ./bin/install 起堆疊，接上 traceai_openai 的 instrumentor，看 trace 與 eval 結果是否真的回到同一條回饋路徑上。若你只想在既有 observability 後端加一層評分，或無法承擔自架資料庫與升級遷移的人力，這個專案就不合適，改用單一用途的評估套件會更省事。動手前先確認三件事：你鎖定的 image tag 是否為穩定版而非 nightly、你的 trace 資料量是否落在 366 天滾動視窗的設計假設內、以及升級時 ./bin/property-catalog-backfill --execute 在你的環境中需要跑多久。
社群筆記