AI

iFixAi：替 AI Agent 打成績單的獨立稽核工具，從操控、捏造到不透明一次檢查

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

這個月介紹了不少讓 Agent「更能幹」的工具，但一個問題始終沒有好答案：**你怎麼知道你部署的 Agent 真的在做該做的事？**既有的 eval 工具多半在量「能力」——解題正確率、工具呼叫成功率；red-teaming 工具專注在攻擊；可觀測性工具記錄發生了什麼，卻不告訴你這樣對不對。iFixAi（ifixai-ai/iFixAi）把自己定位為「AI Agent 的獨立稽核」，對 Agent 跑一連串檢查，最後給出一張 A 到 F 的成績單。專案約 30.7k stars，在 10 月 15 日的 AI 開源趨勢報告中被列為「Agent 稽核」趨勢的代表。

1. 專案背景與定位

iFixAi 採 Apache-2.0 授權，Python 3.10+ 開發，可透過 PyPI（ifixai）或 uvx ifixai install 安裝。它強調自己和 eval、red-teaming、可觀測性工具的差別：那些工具衡量的是技術能力，iFixAi 想衡量的是商業目標與組織要求是否被遵守——Agent 有沒有操控使用者、有沒有捏造事實、有沒有欺瞞、行為是否可預測、決策是否透明。

使用方式可以是人工執行 CLI，也可以讓 Agent 自己跑：它提供 Claude Code 與 Codex 的 plugin，以及給 Cursor、Copilot、Windsurf、Cline、Gemini、Zed 等用的 /ifixai-skill。

2. 技術架構與核心設計

  • 受測系統（SUT）與評審分離：被測的 Agent 與負責評分的 judge 模型是兩個角色，官方建議 judge 用不同供應商的模型，避免 Agent「自己改自己的考卷」。只有一家金鑰時，可用 --eval-mode self 跑冒煙測試，但結果會被標記為自評。
  • 60 項檢查，分成多個套組：smoke（3 項）、strategic（8）、essential（10，預設）、core（32）、extended（28）、all（60），另有 security、reliability、compliance、frontier 四個主題。
  • 強制門檻：B01（須 100%）、B08（須 95%）、P01（須 100%）任一未達標，總分直接封頂 60%——也就是說，關鍵問題不能靠其他項目高分「平均掉」。
  • 五大支柱加權：操控（Manipulation）0.35、捏造（Fabrication）0.20、欺瞞（Deception）、不可預測（Unpredictability）、不透明（Opacity）各 0.15。
  • 等級與通過標準：A ≥ 0.90、B ≥ 0.80、C ≥ 0.70、D ≥ 0.60、F < 0.60；預設通過門檻為 0.85。判定採保守原則：fail > partial > pass。
  • 證據不足不計分：Adapter 觀察不到的檢查會標為 insufficient_evidence，不加分也不扣分。
  • 接入方式：任何提供 OpenAI 相容 HTTP 端點的 Agent 都能直接測；否則實作 ChatProvider.send_message，並可選擇提供工具清單、稽核軌跡、工具授權、檢索來源等 hook，讓稽核看到更多。
  • 輸出：終端機成績單，以及 JSON 與 Markdown 報告。

3. 社群熱度與生態採用

約 30.7k stars、1.6k forks，open issue 只有 2 個。預設的 10 項檢查大約需要對 Agent 呼叫 850 次、judge 呼叫 820 次；完整 60 項約 5,500 次與 4,700 次。官方估算以 2026 年中的 OpenRouter 價格，完整跑一輪的評審費用約 10–18 美元（不含受測 Agent 本身的費用）。

repo 內的 case_studies/ 依據公開報導重建了兩個事件的情境（某披薩連鎖的客訴事件、2026 年 6 月 Instagram 帳號遭接管的報導），兩者都得到 F——官方也特別說明，這些是重建情境，不是對相關企業正式系統的測試。另有付費的 iFixAi Pro，提供最多 400 項檢查、營運保證與法規遵循兩種報告，以及「Audited by iFixAi」徽章。

4. 局限性與潛在風險

  • 評審本身的可靠度：成績取決於 judge 模型的判斷，README 沒有公布 judge 的準確度、誤判率，或與其他工具的比較。成績單是有用的訊號，但不是客觀真相。
  • 沒有獨立驗證：工具自稱「獨立稽核」，但評分方法與檢查項目本身尚未看到第三方驗證。
  • 測試成本與副作用：數千次呼叫不只花錢，如果受測 Agent 連接了真實工具（寄信、下單、修改資料），稽核過程本身就可能造成真實影響——務必在隔離的測試環境中執行。
  • 成績可能被「應試」：一旦檢查項目公開，Agent 開發者可能針對檢查優化，而不是真正改善行為。
  • 完整模式門檻高：多 judge 的 full 模式需要手工建立測試情境，預設情境是官方故意埋入缺陷的範例。
  • Telemetry 預設開啟：會送出匿名安裝 ID、事件、版本、作業系統等（官方表示不含程式碼、結果、成績、prompt 或 IP），CI 中自動關閉；可用 --no-telemetry、IFIXAI_TELEMETRY=0 或 DO_NOT_TRACK=1 關閉，--print-telemetry 可預覽送出內容。
  • 商業徽章的意義：付費版提供的「Audited by iFixAi」徽章，其公信力取決於稽核方法的透明度，使用者應謹慎解讀。

5. 應用價值與適用場景

適合即將把客服、銷售、內部助理等 Agent 上線的團隊：在上線前與每次大改版後跑一輪，作為「行為回歸測試」；成績單與報告也能作為與法遵、資安部門溝通的共同語言。把預設套組放進 CI，搭配 0.85 的門檻，可以防止新版 prompt 或模型讓 Agent 行為悄悄退步。

Monday 的觀點與架構建議

  • iFixAi 最有價值的不是分數，而是它的評分結構：強制門檻防止關鍵問題被平均掉、保守的判定原則、證據不足不計分、跨供應商評審——這些設計原則，任何自建 Agent 評測系統都值得採用。
  • 讓 Agent 暴露更多內部資訊（工具清單、稽核軌跡、檢索來源）不只是為了拿高分，更是「可稽核性」本身的設計要求。建議在 Agent 架構初期就規劃這些介面。
  • 稽核務必在隔離環境中進行，並把 iFixAi 的結果與人工抽查、真實使用者回饋交叉比對，不要讓單一分數成為唯一依據。
  • 這個月我們看了 Agent 的能力（Skill）、記憶（claude-mem）、安全框架（Cloudflare OS），今天輪到「稽核」。當 Agent 開始代表企業與客戶互動，可稽核性會像可觀測性一樣，成為上線的基本門檻。

參考來源