一句話定義
Qlik 代理式 AI，是指 Qlik 平台上一組具備任務執行能力的 AI 代理，以及協調它們的編排機制。與只會回答問題的助理不同，代理會把一個目標拆成幾個步驟、按當下情況決定下一步、調用平台上的計算與自動化能力，最後交出結果或直接完成動作。
它與市面上其他代理框架最實際的分別在於依據：代理的每一步計算都落在 Qlik 的分析引擎與經治理的數據產品上，而不是讓模型自行拼湊答案。這決定了輸出能不能被拿去做管理決策。
和過去那些「AI 助理」到底差在哪
過去幾年幾乎每家 BI 廠商都做過對話式問答，多數停在「幫你把問題翻譯成一張圖」。代理式的分別在下面三點，而這三點都是要付出治理成本的。
🧩
會拆解，不只是回覆
收到一個含糊的目標時，代理會自行拆成幾個可執行步驟：先取數、再比對、再找異常、最後彙總。使用者不必事先想好查詢邏輯。
🔁
會依情況調整路徑
中途發現數據缺口或結果不合理，代理會改變做法再試一次，而不是原樣把錯誤答案交出來。這也代表它的行為需要被記錄與審視。
⚙️
會動手，而不只是建議
在授權範圍內，代理可以觸發流程、寫回系統、派發報表。能力越往「行動」走，權限邊界與稽核紀錄就越不能省。
Qlik 代理式 AI：一次提問背後實際發生了什麼
下圖是一次自然語言提問在平台內部走過的路徑。重點不在最上層的對話框，而在最底下那一層。
代理編排流程 · 從一句提問到一個可交代的結果
使用者用日常語言提出目標
例如：本季華南區毛利為什麼掉了，幫我找出主要原因
▼
編排層：拆解任務、分派給合適的代理
按目標決定要動用哪幾種能力，並管理彼此之間的次序
分析代理
知識代理
異常發現代理
預測代理
自動化代理
▼
可信數據層：分析引擎 + 經治理的數據產品
所有計算落在同一份模型與同一套指標定義上，來源、口徑與權限可追溯
▼
交出結果，或在授權範圍內直接執行
回覆分析結論、產出報表、觸發流程或寫回業務系統
綠色那一層是能不能上線的關鍵。缺了它，上面所有代理都只是在猜。
編排層決定「該找誰做」。 一個目標往往需要好幾種能力接力：先查非結構化文件、再算結構化指標、再判斷是否異常。編排層負責把這條路排出來，而不是丟給單一模型硬答。
數據層決定「答案敢不敢用」。 這是我們最想跟客戶講清楚的一點。代理式 AI 的失敗案例，九成不是代理不夠聰明，而是底下的指標口徑不一致、權限沒切乾淨、或者根本沒有人能說明某個數字是怎麼來的。
開放介面決定「能不能接進你現有的 AI」。 Qlik 提供 MCP 伺服器，讓外部的助理與代理生態（例如 Claude、ChatGPT、Copilot）可以取用平台上的計算能力與經治理的數據，而不必把數據複製一份出去。原廠的完整說明見 Qlik 官方代理式 AI 頁面。
代理越自主，數據治理的欠帳就越貴
一個只會回答問題的助理答錯了，使用者自己會發現。一個會動手的代理答錯了，錯誤會直接寫進下游系統。這就是為什麼導入順序不能倒過來。
口徑不一致，代理只會放大分歧
同一個「毛利」在財務與營運各有算法時，代理不會替你調解，它只會挑一個。指標定義必須先寫進模型，這件事沒有捷徑。
權限必須切在數據層，不是介面層
代理會繞過你原本設計的操作路徑。列級與欄級的存取控制若只做在儀表板上，等於沒做。這是金融與公營客戶的第一道審查關卡。
每一步都要留得下紀錄
代理用了哪些數據、走了哪幾步、依據什麼下的判斷，都要能事後調閱。做稽核與監管報送的機構，這一項通常比功能本身更被在意。
行動範圍要先劃線，再開權限
哪些動作可以自動執行、哪些必須人手覆核，應該在導入前就定義好並寫進流程，而不是等出事之後再回頭補。
平台上目前有哪些代理
下表按原廠現行命名整理。實際可用範圍會隨版本與訂閱層級不同，選型前建議由我們代為核對。
| 代理 | 負責什麼 | 常見使用場景 |
|---|---|---|
| Discovery Agent | 持續監看數據，找出趨勢變化、異常與離群值 | 營運指標異動預警、風控初篩 |
| Analytics Agent | 回應分析類提問並產出洞察 | 臨時性分析需求，不必再排期給分析師 |
| Knowledge Agent | 從大量非結構化資料中取得答案 | 合約、政策文件、工單紀錄的查找 |
| Predict Agent | 執行預測建模並輸出結果 | 流失預測、需求預測 |
| Automate Agent | 依據數據與推理結果執行流程與動作 | 條件觸發告警、跨系統寫回 |
| Data Quality Agent | 自動產生數據品質規則，檢查準確性與完整性 | 上線前的數據體檢、持續監控 |
| Data Catalog Agent | 自動盤點、分類並記錄數據資產 | 數據資產盤點，找出無人認領的表 |
| Data Product Agent | 協助數據產品的建立與維護 | 把常用數據集標準化後對外提供 |
| Data Glossary Agent | 維持全機構業務術語與定義一致 | 指標口徑統一，跨部門對齊 |
| Declarative Pipelines | 以意圖描述取代人手編寫管線程式碼 | 數據管線開發與維護 |
| Agentic Data Stewardship規劃中 | 數據品質問題的偵測與修復建議 | 原廠已公布方向，上線時間以官方為準 |
Qlik 代理式 AI：香港企業導入前要先答的四個問題
我們不建議一開始就全面鋪開。以下四題答得出來，代表你已經具備做第一個場景的條件；答不出來，先做的應該是數據治理而不是代理。
1
第一個場景是什麼，怎麼算成功
挑一個範圍清楚、數據齊全、結果可驗證的場景，例如某條業務線的異常監察。不要拿全公司的營運分析當第一個題目，那不是試點，是豪賭。
2
關鍵指標的定義有沒有寫下來
如果三個部門對同一個指標有三種算法，代理只會更快地把分歧散播出去。這一步通常比技術實施更花時間，但省不掉。
3
數據存放地點與合規要求如何
香港的金融與公營機構對數據落地、模型調用位置常有明確規定。雲端與本地部署的合規路徑不同，這一題決定整個架構走向。
4
哪些動作允許自動執行
建議先全部設為「建議 + 人手確認」，累積一段時間的紀錄，再逐項放開。開放範圍應該由業務與合規共同決定，不是由技術團隊單方面設定。
常見問題
最主要的分別是計算由誰負責。直接接大模型時，數字往往由模型自行生成或從片段資料推斷，難以核對；在 Qlik 上，代理負責決定要算什麼，實際計算交給分析引擎，結果與人手開儀表板看到的來自同一份模型。對需要把答案寫進報告的機構，這個分別是決定性的。
代理繼承的是使用者在平台上的權限，而不是另開一套。因此關鍵在於權限本身是不是切在數據層。如果貴機構目前的存取控制只做在報表層面，導入前要先補這一塊，這也是我們評估階段一定會檢查的項目。
可以。Qlik 提供 MCP 伺服器作為對外介面，外部助理與代理可以透過它取用平台的計算能力與經治理的數據。這樣做的好處是數據不必再複製一份到外部環境，權限與稽核仍然由平台這邊控制。實際可用範圍視版本與訂閱層級而定。
技術部分通常不是瓶頸。如果數據來源已經接好、指標定義也談攏，單一場景的試點可以在數週內看到結果；反之若指標口徑仍有爭議，那段時間會花在會議室而不是機器上。我們的做法是先做一次現況評估，把時間耗在哪裡先說清楚。
我們是 Qlik 的 Elite Channel Partner，並非 Qlik 的分公司。在代理式 AI 項目上，我們負責導入前的現況評估、場景挑選、指標與權限設計、環境部署、試點交付與後續運維支援，並以繁體中文及粵語在香港時區內對接。產品本身的功能規劃與原廠支援政策由 Qlik 決定。
Qlik®、Qlik Sense®、Qlik Cloud Analytics®、Qlik Answers®、Qlik Predict®、Qlik Automate®、Qlik NPrinting®、QlikView® 及 Qlik Talend® 為 QlikTech International AB 的商標或註冊商標。文中提及的其他產品名稱為其各自擁有者的商標。愛普國際實業有限公司為 Qlik 的授權合作夥伴，與 Qlik 之間並無隸屬關係。
想知道貴機構現在適不適合做第一個代理場景？
把現有的數據來源、指標管理現況與最想自動化的環節告訴我們，我們會給出一份直白的評估，包括不建議現在做的理由。首次諮詢不收費。