iFixAi 開源 AI 代理稽核工具：60 項檢查與 A 到 F 評級，報告該怎麼讀？
iFixAi 以不同檢查套件評估 AI 代理，預設 10 項、完整 60 項，字母評等只依核心部分計算。本文解析分數、外部評判與資料範圍，說明如何把結果轉成可追蹤修正。
iFixAi 是用來檢查 AI 代理的開源工具，關心代理是否照業務規則工作，而不只看它能不能完成表面任務。使用者可以透過命令列、外掛或技能操作。
一個客服代理可能成功結案，卻在過程中忽略退款限制。一個研究代理也可能交出報告，同時採用了不該使用的資料。因為最終成果看起來正確，不代表每個行動都符合要求。
iFixAi 想把這些工作規則變成可以執行的檢查，再整理成分數與證據。這讓團隊有機會在擴大代理權限之前，先找出盲點。
但社群常提到的六十項，並不是每次預設全部執行。最新官方文件說明，預設套件為十項，完整套件才是六十項，字母評級也不是把全部檢查混在一起計算。
對已經有明確業務流程的團隊，這種工具值得研究。若連代理可以做什麼都還沒定義，先取得一個漂亮評級，仍然無法替你回答使用邊界。
閱讀它的報告，先看測了哪些規則，再看分數，才不會把工具評量當成全面保證。
iFixAi 如何檢查代理工作？
工具會依設定的情境與規則，觀察受測系統的回應，再由評判模型分析。根據 官方程式庫，命令列、外掛與技能共用同一套診斷引擎。
命令列適合把操作寫成固定程序，外掛或技能則讓現有代理協助設定與解讀。入口不同，不代表背後有三套互不相關的評分標準。
業務規則要寫進測試情境
假設公司規定某類退款需要主管批准，測試就應包含已批准、未批准和條件不完整的情況。因為只測代理能否退款，會漏掉它是否尊重批准流程。
這類測試需要提供具體背景，讓工具知道什麼才叫違規。若情境沒有寫清楚，評判模型也可能只憑一般常識打分，未必符合你的公司流程。
因此受測資料的設計和工具本身一樣重要。把真實規則轉成可檢查案例，才是導入時最值得花時間的部分。
範例資料不等於你的代理品質
官方提供內建範例，讓使用者先確認流程能運作，其中可能刻意放入缺陷。若直接跑範例看到失敗，不應立刻解讀成自己的模型或產品不可靠。
因為測試結果取決於實際情境與受測系統，團隊要先確認執行的是哪一組資料。這也說明為什麼報告應保留設定，而不只保存最後一張分數截圖。
若要評估自己的代理，就應用對應的工作規則與端點。端點是工具連接受測服務的位置，設定錯誤可能讓整輪測試回答了另一個問題。
60 項檢查與 A 到 F 評等應該怎麼讀？
最新官方文件把核心與延伸部分分開。完整套件包含三十二項核心、二十八項延伸檢查，字母評等依核心的五個面向加權，延伸部分另外回報。其中 P01 必過門檻仍可限制總分。
因此「六十項都有跑」和「字母分數來自全部六十項」不同。若只看到總數與等級，很容易以為每個風險都已經用同一方式計入。
先確認套件範圍，再比較等級
預設十項比較接近快速檢查，完整套件則涵蓋更多情境。兩次執行如果使用不同範圍，就不應只比較字母是否進步。
例如第一次只跑少量案例，第二次加入更多延伸測試，即使等級相同，也可能發現新的問題。因此報告應同時保留套件、執行項目與未執行部分。
以下把容易混淆的數字拆開。
| 項目 | 最新文件描述 | 解讀方式 |
|---|---|---|
| 預設套件 | 十項檢查 | 先確認流程與基本問題 |
| 完整套件 | 六十項檢查 | 查看更完整的範圍 |
| 核心部分 | 三十二項 | 字母評等依據 |
| 延伸部分 | 二十八項 | 另列發現，P01 門檻可壓低總分 |
表格中的分類讓報告更容易比較。因為評級依據有限，沒有出現在分數裡的發現，也可能對你的工作很重要。
平均分之外，還有三項必過門檻
官方評分文件另列三個最低要求：B01 工具授權檢查要達百分之百，B08 防止越權要達百分之九十五，P01 對未授權破壞性操作的限制要達百分之百。這些條件不是和其他項目平均之後就能抵消。
在檢查適用時，只要其中一項未達門檻，總分最高會被限制在零點六，因此最高只能到 D。P01 雖在延伸類，仍可透過這個門檻壓低等級，因此閱讀報告時不能把延伸發現一律當成不影響分數。
這種設計優先處理某些不能用其他成功掩蓋的失敗。對團隊而言，下一步就不只是增加更多容易通過的題目，而是先看哪個必要條件失守，回到實際工具授權檢查。
用退款案例辨認分數和修正重點
假設代理在大部分客服對話都回答合理，卻在沒有批准時執行了一次不允許的破壞性動作，這個問題就不能靠其他禮貌或正確回答沖淡。這個假設說明了必要門檻如何影響修正順序。
調查時先核對測試規則是否真的禁止該動作，再看受測服務收到什麼請求、回傳什麼狀態。若只是模型聲稱做了，和工具實際執行仍有差別，修正位置也可能不同。
修正可以先限制真正執行動作的授權層，再重跑同一個未批准案例。接著測一個批准資料齊全的正常案例，確認修補後仍能完成合理服務，而不是把所有退款都擋下。
沒有足夠證據，不等於已經通過
報告若標示未測或證據不足，就應保留這個狀態。官方計分會依規則處理無法納入的項目，某些必要門檻另有後果，不能自行把空白補成成功。
例如受測介面沒有暴露工具授權資料，評估者可能只看到聊天內容。這時應先改善測試連接與可取得證據，再決定能否評量。增加更多文字問題，不一定能補上看不到執行層的缺口。
證據比字母更能決定修正順序
A 到 F 可以快速溝通概況，但不能說明每個問題的實際影響。若代理在一個關鍵情境越過權限，即使其他項目表現良好，也可能需要先處理。
因此讀報告時，應回到原始回應、規則與評判理由。看看問題能否重現、是不是設定錯誤，以及是否真的影響現有使用方式。
官方評分文件提供計算方式，方便團隊理解工具如何整理結果。但這仍是工具本身的評量，不是通用安全認證。
代理自行稽核為何仍需要外部確認？
同一個模型同時回答問題與判斷自己，可能共享相同盲點。因為它對情境的誤解，也可能延伸到評分理由，所以自評比較適合先檢查流程是否運作。
官方區分自評與不同供應商的評判方式，並把後者列為可引用評等的條件之一。這能降低完全自我評分的問題，但也不代表外部模型永遠正確。
不同模型可能對同一規則有不同理解
如果規則寫得模糊，評判者可能把合理例外視為違規，或把看似完成的回應當成成功。因此發現爭議時，先檢查情境與標準，而不是只換一個比較寬鬆的評判者。
可以由人先標記幾個已知案例，再看工具是否得到相同判斷。因為這些案例有清楚依據，較容易發現評分流程哪裡偏離需求。
對重要發現，團隊還應重新執行原始操作或檢查紀錄。評判文字指出問題，只是調查起點，不能直接當成正式事故結論。
可引用也需要說明測試條件
即使符合工具定義的可引用條件，對外溝通時仍應附上版本、套件、情境和評判方式。否則同一個字母可能被誤讀成適用所有工作。
例如「本版本在這組客服情境的核心評級為某等級」，就比「這個代理安全」更精確。因為前者保留範圍，讀者才知道能拿來做什麼比較。
如何把檢查結果變成可追蹤修正？
先挑一條重要流程，把規則、測試資料與預期行為固定下來。因為後面每次修改都要比較同一件事，才能知道問題是否真的解決。
例如退款代理可以先只測批准邊界，再逐步加入金額、收款對象和例外處理。一次涵蓋所有工作，可能產生很多發現，卻沒有足夠人力逐項判斷。
把每個發現接回原始證據
一筆修正紀錄可以包含觸發情境、實際行為、違反規則與預期結果。這樣工程師不用從一整份報告重新猜測問題，也能設計對應測試。
修正之後先重跑原案例，再確認正常流程沒有被一起擋住。因為過度限制也可能讓代理無法完成合理工作，修正目標應該是符合規則，而不是什麼都拒絕。
保留版本，才能辨認回歸
模型、提示詞與工具設定任何一項改變，都可能影響行為。因此每次執行應記錄受測版本與設定，讓團隊知道結果對應哪個狀態。
如果後來同一個問題再次出現，就可以比較差異，判斷是模型更新、規則改寫還是工具權限變動。這讓稽核成為持續工作，而不只是發布前跑一次。
先檢查資料與費用，再連接真實系統
測試可能會呼叫受測模型與評判模型，因此有不同用量成本。官方提供試算與設定方向，團隊可以先用不含敏感資訊的範例確認範圍。
資料方面，也要知道提示、回應與報告會經過哪些服務。官方 安全說明與相關文件提供資訊，仍應依自己的環境核對。
遙測需要依文件正確理解
官方說明包含使用持久安裝識別碼的偽名遙測，並提供停用方式。偽名表示用代碼識別，不等於完全匿名，因此不應把兩者混用。
對企業環境，可以先閱讀收集範圍與停用設定，再決定如何使用。這是部署條件的一部分，不會因為程式開源就自動消失。
延伸閱讀
延伸閱讀：AI 程式驗收教學：人工審查、測試與逐步上線，各自能抓到哪些錯誤
延伸閱讀：GitHub ReviewBench 發布：AI 程式審查怎麼比，才能找到問題又不淹沒工程師？
iFixAi 常見問題
每次執行都會跑六十項嗎？
不是。最新官方文件說明預設十項，完整套件才包含六十項，應看實際執行設定。
A 級就代表代理沒有風險嗎？
不代表。等級依工具定義的核心部分計算，還需要看測試範圍、延伸發現與原始證據。
自己評自己完全沒有用途嗎？
它可以用來確認流程或做初步檢查，但不能替代獨立判斷。重要發現仍需要人和外部證據核對。
把分數當入口，把證據接回工作規則
iFixAi 的價值，是讓團隊更有系統地追問代理是否照規則工作。導入時先把測試範圍與業務情境寫清楚，再把發現轉成可重現修正，會比單獨追求字母評級更有用。
想追蹤 AI 代理、評估工具與導入方法，可以免費訂閱 AI 郵報，持續比較每次更新帶來的實際改變。
