ONEKEY AI Agent 是什麼？

ONEKEY AI Agent 是整合於 ONEKEY 平台的對話式 AI 功能，讓使用者以自然語言查詢韌體分析結果、漏洞資訊、軟體元件與軟體物料清單（Software Bill of Materials，SBOM），也能取得平台操作指引及 ONEKEY Query Language（OQL）查詢協助。

其資料基礎來自平台既有的韌體擷取、二進位分析、元件辨識與漏洞情報。使用者可以沿著問題追問，減少為了取得相關資訊而反覆切換頁面或查閱文件的操作。

理解這項功能時，應分清楚兩個層次：韌體分析負責產生發現與證據，AI Agent 則協助查詢、解釋與整理這些資料。對話回覆的價值，需要回到具體分析結果檢查。

五項韌體安全查詢與分析輔助能力

ONEKEY AI Agent 的主要應用，涵蓋漏洞說明、元件與 SBOM 查詢、頁面情境理解、OQL 查詢輔助及平台操作指引。這些能力讓不同經驗的使用者更容易取得資訊，並為後續技術確認建立起點。

1. 查詢 CVE 與漏洞相關資訊

使用者可詢問常見漏洞與暴露（CVE）的內容、嚴重程度、受影響元件，以及值得評估的緩解方向。AI Agent 可結合漏洞資料與目前韌體的分析情境，協助釐清需要進一步確認的條件。

例如，面對一項高嚴重性漏洞，可以追問「哪個元件與這項 CVE 有關？」或「有哪些證據能說明它與此韌體的關聯？」再由工程團隊檢查實際版本、設定與暴露情況。

2. 探索 SBOM 與軟體元件

SBOM 記錄產品中的軟體組成；AI Agent 則提供更容易查詢這些資訊的入口。使用者可探索已偵測到的元件、版本、相關漏洞，以及平台可取得的產品或韌體關聯。

這類查詢適合供應商韌體審查與元件盤點。例如，先確認某個開源元件是否存在，再檢查其版本與相關發現。可查到的範圍仍取決於分析資料是否完整及使用者權限。

3. 結合目前頁面的工作情境

在支援的頁面中，AI Agent 能帶入使用者正在查看的韌體、漏洞或元件資訊，讓問題更貼近目前任務。例如，開啟某韌體的 CVE 頁面後，可接續詢問其中的高風險項目。

部分頁面不提供完整情境；切換分析對象或韌體版本後，也應確認回覆引用的是正確資料。提問時補上韌體名稱、版本或 CVE 編號，有助於減少情境誤判。

4. 產生、解釋與調整 OQL 查詢

OQL 是 ONEKEY 平台的查詢語言。使用者可以描述想找的條件，請 AI Agent 協助建立查詢，或解釋既有語句的篩選邏輯，再依調查需求調整條件。

平台也在支援的 OQL 輸入欄位提供自然語言轉換。使用者應檢查產生的查詢是否符合目前欄位及調查目的；產生查詢語句與建立、套用正式分析規則，是不同的操作。

5. 取得平台操作與文件指引

AI Agent 可以運用產品文件回答功能與操作問題，例如如何找到某項功能、完成特定工作或查閱版本變更。對偶爾使用平台的產品與管理人員，這提供了接近工作現場的說明入口。

以分析證據為基礎，保留人工判斷

ONEKEY 將 AI Agent 定位為以證據為基礎的分析助手。韌體安全團隊應能從回覆追查到相關元件、漏洞紀錄或分析結果，再判斷這些資料是否足以支持處置決策。

依據 ONEKEY AI Agent 官方文件，目前 AI Agent 採唯讀設計，協助使用者找到與理解既有資料，不會代替使用者建立分析規則或新增自訂問題、CVE。這項邊界也適用於理解後續路線圖：未來規劃的工作流程能力，不能直接視為目前已提供的自動執行功能。

• 核對資料來源：檢查回覆對應的韌體、元件、漏洞與分析時間。
• 驗證技術條件：將版本、修補狀態、功能啟用情況與實際暴露面納入判斷。
• 保留人工複核：由負責人決定修復順序、緩解方式及風險接受條件。

以平台資料為基礎，仍不代表每則 AI 回覆都必然正確。AI 提出的整理與建議，應作為可查核的研判材料；企業也應保留處置決策與確認依據。

路由器韌體示例：從漏洞清單走向處置問題

提供文件以採用 OpenWrt 19.07.10、Linux 核心 4.14.275 的路由器韌體為示例。當使用者詢問優先處理項目時，示例中的 AI 回覆建議檢視核心與系統基線升級，並提醒漏洞匹配分數不足以單獨證明可利用性。

這個示例的重點，在於把大量漏洞紀錄轉換為可以與開發團隊討論的問題。若多項發現涉及相同老舊元件，團隊可以進一步評估共同原因、升級可行性與回歸測試範圍。

實際評估仍需檢查供應商是否回補修正、相關功能是否啟用、漏洞觸發條件是否成立，以及設備如何連網與部署。AI 能協助整理待確認項目，產品團隊則需以實際證據完成判斷。

ONEKEY 四階段 AI 路線圖

ONEKEY 於 2026 年 7 月公布四階段 AI 路線圖，從自然語言取得安全資訊，逐步朝企業系統串接、決策支援及完整工作流程輔助發展。核心原則是讓人員保有關鍵決策責任，並維持權限控制與操作可追溯性。

此表依原廠公布的路線圖整理；第二至第四階段描述的是規劃方向，未在本文確認其完整交付狀態或時程。採購與導入時，應另行核對實際版本與交付範圍。

企業導入前的四個評估步驟

建議先以一份已完成分析的韌體與明確問題進行小範圍驗證，再評估是否擴大使用。以下為本文提出的導入建議，可協助團隊檢查資料品質、回答可核查性與實際工作價值。

1. 確認分析基礎：選擇已成功完成分析的韌體，記錄版本與分析時間，確認元件及漏洞資料可供查閱。
2. 設計具體問題：例如「這項 CVE 對應哪個元件？」或「請協助整理需要優先人工確認的項目」，讓回覆能對應可檢查的資料。
3. 逐項驗證回覆：將答案與原始紀錄交叉比對，記錄情境錯誤、遺漏與需要追加證據的地方。
4. 確認治理與使用範圍：由資安及 IT 團隊檢查啟用設定、角色權限、資料傳輸、模型服務安排與對話保存需求，再制定使用規則。

資料治理尤其需要事先確認。官方使用文件說明，對話、頁面情境與工具取得的資料可能傳送至模型 API，且可能包含韌體中的敏感內容；因此，不能把唯讀功能或平台內對話，直接理解成資料完全不離開企業環境。應依實際部署與合約安排完成評估。

導入成效可觀察找到證據所需時間、人工交叉比對負擔，以及提交開發團隊的問題是否更明確。若未實際測量，應避免宣稱固定的效率提升比例。