FailproofAI 評測：把 AI 代理的每一次工具呼叫都變成可審計的事件
Observability and enforcement for AI agent harnesses. Capture every run and runtime reliability with policy enforcement. 40 built-in policies, a local dashboard, no account required with a generous free cloud plan
秒懂
- 它是什麼？
- FailproofAI 是一個掛鉤在 12 種 AI 代理框架上的觀測與執行層，宣稱能攔截危險工具呼叫並提供 39 條內建政策。本文檢視它的安裝方式、運作機制、授權陷阱與適用邊界。
- 適合誰用？
- FailproofAI 適合已經把 Claude Code、Codex 或 Hermes 等代理當作日常工具，且需要留下可稽核軌跡的個人開發者或小型團隊。它不適合需要完全離線、或想自己控制政策邏輯的組織，因為授權裡的 Commons Clause 禁止將它作為付費服務的一部分轉售，這對商業產品內嵌是硬傷。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 MDX（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「代理做錯事之後才發現」的問題
多數 AI 代理工具鏈只有事後日誌。代理呼叫了 rm -rf，你從輸出裡看到慘劇，但為時已晚。FailproofAI 的定位是在工具呼叫執行前介入，用政策決定要不要放行。這不是另一個 tracing 面板，它把「記錄」和「否決」綁在同一個掛鉤上。README 開頭直接寫「we can say no」，這是它與純觀測工具最根本的差異。目標使用者是那些把 Claude Code、Codex 這類編碼 CLI 當作正式開發流程一部分的人，他們需要的不只是看到代理做了什麼，而是能在它做之前擋下特定行為。
掛鉤架構：12 種 harness，同一套事件模型
專案的核心抽象是「harness」。README 列出 12 種受支援的代理框架，分成兩類：十種編碼 CLI，包含 Claude Code、OpenAI Codex、GitHub Copilot CLI、Cursor Agent CLI、OpenCode、Pi、Factory Droid、Devin CLI、Antigravity CLI 與 Goose；另外兩種是聊天與助理閘道，Hermes 與 OpenClaw。關鍵設計在於，無論代理跑在哪個 harness 裡，產生的事件、套用的政策、記錄的工作階段歷史都是同一套。這意味著你不需要為每種代理學習不同的觀測語法。不在這 12 種清單內的代理，官方提供的 Python SDK 只能做到 tracing、工作階段與稽核，政策執行需要你自己在 runtime 裡寫掛鉤。這是個明確的邊界：SDK 是半套方案。
安裝與啟動：npm 套件與本地儀表板
安裝方式是 npm 套件，套件名稱是 failproofai，目前版本為 v1.0.4-beta.4。README 的安裝段落被截斷，只留下「npm」二字，但從版本號與 npm 頁面連結可以確認它發布在 npm registry 上。授權標示為 MIT 加上 Commons Clause，這不是純 MIT，後面會細談。README 聲稱提供本地儀表板、不需要帳號即可使用，同時也有一個「慷慨的免費雲端方案」作為選項。實際的啟動指令、設定檔格式與儀表板網址，在提供的資料裡沒有具體列出。想評估的人需要直接查閱 docs.befailproof.ai 上的文件，或從 npm 套件本身的 README 下手。以 beta 版本而言，安裝路徑可能還未穩定。
39 條政策與「零延遲」的宣稱需要打折扣
README 提到 39 條內建政策，以及「Zero latency」的口號。政策數量本身不是重點，重點是這些政策覆蓋了哪些行為，以及它們的執行點在哪一層。如果政策是在工具呼叫前同步檢查，那延遲取決於政策檢查的複雜度與事件傳輸方式。任何聲稱「零延遲」的系統都該被懷疑，因為網路傳輸、本機 IPC 或政策規則的運算都需要時間。比較合理的理解是，政策檢查的延遲相對於代理本身呼叫 LLM 的數秒級延遲而言，小到可以忽略。但若政策需要查詢外部服務來決定是否放行，這個宣稱就不成立了。文件沒有列出政策的具體清單，這對想預先評估的人是一個資訊缺口。
授權陷阱：MIT 加上 Commons Clause 不是開源
GitHub 頁面上的 license 欄位顯示 NOASSERTION，但 README 的徽章明確寫著 MIT 加上 Commons Clause。Commons Clause 是一個附加條款，它限制你將軟體作為付費服務的一部分轉售。這代表 FailproofAI 不是 OSI 認證的開源授權，雖然原始碼公開，但商業使用有額外限制。對內部工具、個人專案或非營利使用來說，這個限制影響不大。但如果你打算把 FailproofAI 嵌入自己的商業產品，或作為 SaaS 服務提供給客戶，就需要謹慎評估。這不是法律建議，只是從授權名稱本身就能讀出的約束。評估時應該把這點放在決策表的前幾行，而不是最後才發現。
與純 tracing 工具的差異：執行點是分水嶺
市面上多數 AI 代理觀測工具，例如 Langfuse 或 Helicone，做的事情是記錄 token 用量、延遲與對話內容。它們是被動的，代理跑完之後你去看報告。FailproofAI 的設計哲學是主動的，它要在工具呼叫執行前說不。這個差異決定了適用場景。如果你只需要成本分析與效能監控，FailproofAI 是殺雞用牛刀，而且它的政策執行機制對你毫無用處。如果你擔心的是代理執行破壞性指令，例如刪除檔案、推送程式碼或存取敏感憑證，那純 tracing 工具幫不上忙，你需要的是執行層的閘道。FailproofAI 的 Python SDK 恰好說明了這個分界：沒有掛鉤的 SDK 只能 tracing，不能 enforcement。
版本狀態與維護成本的現實評估
最新版本是 v1.0.4-beta.4，發布日期為 2026 年 9 月 9 日，前一版 beta.2 在 9 月 8 日發布，再前一天是 SDK 的 0.0.1b2。三天內三個版本，這顯示專案處於快速迭代期。beta 版本意味著 API 可能變動，政策語法可能調整，儀表板功能可能增刪。採用 beta 軟體作為開發流程的執行層，本身就有風險：如果政策引擎的 bug 讓代理無法正常運作，你的開發流程會直接卡住。另一方面，專案有持續的 CI 與供應鏈掃描工作流程，顯示維護者重視基本品質。升級成本方面，由於版本跳動頻繁，每次升級都需要重新驗證政策行為沒有改變。
編輯結論
FailproofAI 適合已經把 Claude Code、Codex 或 Hermes 等代理當作日常工具，且需要留下可稽核軌跡的個人開發者或小型團隊。它不適合需要完全離線、或想自己控制政策邏輯的組織，因為授權裡的 Commons Clause 禁止將它作為付費服務的一部分轉售，這對商業產品內嵌是硬傷。尚未導入任何受支援 harness 的人不該先裝它，你沒有東西可掛。動手前先確認兩件事：一是你的代理版本是否在官方支援清單內，二是你能否接受政策執行與觀測資料的傳輸路徑，尤其是雲端方案。若這兩點都過關，它提供的「先攔截、後記錄」模型值得一試；若過不了，請回頭找純 tracing 方案。
社群筆記