Xurrent Q2 AI 讓 ITSM 變成代理

Xurrent 的 Q2 2026 AI 發佈把 Assist、Copilot、autonomous agents 分層塞進 ITSM 工作流。

我看 ITSM 工具有一陣子了，真的很容易一眼看出哪家是在做事，哪家只是把舊流程包一層 AI 皮。我打開 Xurrent 這份 Q2 2026 AI release 的時候，原本也以為會是老套路：多一個 sidebar、加一個聊天框、再把「智慧」兩個字貼滿頁面。結果讀下去，我反而有點不爽，因為它不是在賣單一 chatbot，而是在把 AI 拆成四種工作方式，直接塞回 service desk 的既有介面裡。這種做法比較像真的懂現場，不像那種只會做 demo 的產品簡報。

我這次主要看的是 Xurrent 自家的更新文章：Agentic AI: Xurrent’s Q2 2026 AI Releases。作者是 Jim Hirschauer，發佈時間是 2026-05-12。文中還提到 Sera AI 已經在 91% 的客戶環境中上線，這個數字我覺得很重要，因為它不是實驗室玩具，而是已經進到真實工作流裡了。這也是我願意拆它的方法論，而不是只看行銷詞的原因。

先別把 AI 做成另一個分頁

“Most enterprise teams aren’t ready to abandon their service desk interface for a blank chat prompt. They shouldn’t have to.”

翻譯一下就是：Xurrent 先承認一件很現實的事，企業團隊根本不想離開自己每天在用的 service desk，跑去對著一個空白 prompt 發呆。這句話很直白，但我很買單。因為我看過太多 AI 導入失敗，不是模型不夠強，而是工作流被切成兩半。系統裡有一半資料，AI 工具裡有另一半，最後專家要自己在兩邊搬來搬去，超煩。

Xurrent 的做法是把 Sera AI Assist 直接放進 specialist 的操作畫面裡。它不是要你開新頁面問問題，而是在 request 裡直接做摘要、找相似案件、拉出相關問題。這種設計看起來很小，實際上很關鍵，因為它解決的是上下文切換成本，不是炫技。

我之前幫一個 support 團隊看過類似需求。模型可以摘要得很好，但大家就是不想把 ticket 內容複製到另一個工具裡。最後不是 AI 不行，是流程很蠢。工作都在 ticket 裡發生了，你卻要人跳出去問 AI，這就是在逼人中斷思考。

實操上，我會先問三件事：

• AI 能不能在同一個 request 畫面裡摘要內容？
• 能不能直接找出相似 incidents、problems 或 KB？
• 建議能不能被 specialist 直接接受、修改或忽略？

如果這三題答不出 yes，我就不會把它叫做 workflow AI。我會把它叫做 demo wrapper，漂亮但沒用。

Copilot 不是會聊天就夠了，它得看得懂系統

“When they need to go deeper, they ask.”

這句話其實在講一個很重要的邊界：Assist 是幫你看表面，Copilot 才開始讓你追問。也就是說，Xurrent 想做的不是單純的摘要機，而是能在 request 上下文裡繼續問問題的互動式分析工具。這個差別很大，因為 service work 本來就不是單一答案的世界，而是要把歷史、責任歸屬、影響範圍、最近變更全部串起來。

如果 Copilot 只會把人話改寫得更順，那它其實沒什麼用。真正有價值的是，它要能讀懂目前這張單、這個 CI、這個 assignment group，甚至最近相似事件的脈絡。沒有這些上下文，它再會講也只是 polished autocomplete，聽起來像懂，其實沒懂。

我很常看到團隊被「AI assistant」騙到。介面做得很順，回答也像人話，但它根本分不出 password reset 跟 Sev 1 outage 的差別。這種東西拿來聊天可以，拿來做 service decision 就很危險。Xurrent 這份 release 比較有意思的地方，是它一直把 Sera AI 跟 service data、signals、workflow 綁在一起，意思就是它不是一顆飄在空中的腦袋。

實操上，我會把 Copilot 的問題設計得很具體，別問那種「幫我看這張單」的廢話。直接問這些：

• 過去 24 小時哪些變更可能跟這次 spike 有關？
• 有哪些相似 request 是同一個團隊解掉的？
• 依照 CI 與分類，最可能的 owner 是誰？

如果它能在這種問題上給出可追溯的答案，才算真的有上下文。答不出來，那就是把錯誤講得比較順而已。

Autonomous agents 不是魔法，是有權限邊界的流程

“Whether your team wants AI woven into the interface they already use, or you’re ready to deploy autonomous agents across your workflows, these capabilities meet you where you are.”

翻譯一下就是：Xurrent 沒把 autonomy 當成另一個獨立產品在賣，而是把它當成成熟度階梯的一段。這點我覺得比很多廠商誠實，因為大部分人一講 agent 就像在講召喚獸，彷彿模型一接上去就能自己把事情做好。現實不是這樣，尤其在 ITSM 裡，agent 一旦會動作，就一定要先問權限、範圍、稽核、例外處理。

我之前處理過一套自動化，表面上很聰明，實際上很難追。票被重新分派了、通知發了、流程被跳過了，但沒人能說清楚為什麼。這種 automation 不叫省工，叫製造法務和維運的共同噩夢。Xurrent 這次的說法比較像是想把 autonomy 留在平台治理框架裡，這才是正路。

如果 agent 要真的去動 ITSM record，我會要求三件事：role-based permissions、完整 audit trail、明確 scope。最重要的是，human override 不能跟系統打架。你不能一邊說可控，一邊把人工接手做得比 agent 還麻煩。

實操上，我會把 autonomy 切成四層，而不是二選一：

• Tier 1：摘要與建議
• Tier 2：產生待審核動作
• Tier 3：在政策內執行低風險動作
• Tier 4：依信心門檻自動升級或轉派

只要你講不出風險邊界，就先不要談 autonomous agent。那不是成熟，那只是希望模型不要出事。

Sera AI 真有料，前提是你的資料也要像樣

“Sera AI has been part of how Xurrent works for years, routing and classifying requests, drafting knowledge articles, and assisting users directly as a virtual agent, with 91% of customers already running it in production.”

這段我認為是整篇最有份量的地方，因為它把 release 從「未來規劃」拉回到「已經上線」。91% 這個數字是 Xurrent 自己提供的，我不亂加戲，但它確實代表一件事：這不是在空中畫餅，而是建立在既有 production 基礎上。

白話講，新的 AI 功能不是從零開始，而是疊在既有的 signals、service data 跟 workflow 上。這很重要，因為 AI 最怕的不是模型不夠會講，而是你的環境根本沒什麼可讀的東西。資料亂、分類亂、關聯亂，最後只會得到一台很會講幹話的機器。

我看過太多 service environment 的真實問題都不是模型問題，而是 taxonomy 爛、assignment group 過期、knowledge base 沒人維護、CMDB 一堆垃圾資料。這種情況下你上 AI，只是把混亂自動化。Xurrent 這次一直強調 service data 和 workflow，我反而覺得比「agentic」這個詞本身更值得注意。

實操上，我會先做一輪 readiness check：

• 分類是否夠一致，能支撐自動分類或提示
• assignment group 是否還活著，不是歷史遺跡
• knowledge articles 是否夠新，能安全引用
• incidents 和 problems 是否有足夠關聯，能看出模式

這四項只要有兩項很爛，你就先別急著上 agent。先整理資料，不然 AI 只是在幫你更快複製混亂。

真正的賣點不是 AI 很多，是它放在大家信任的地方

“All governed by the platform your team already trusts.”

這句話聽起來很像廠商口吻，我知道。但我不覺得它空。enterprise 裡面，治理跟信任就是能不能上線的差別。Xurrent 明顯想把 Sera AI 包成平台內的受控能力，而不是一個另開政策文件、另做風險審查的外掛 AI 產品。

翻譯一下就是：這波產品策略不是在賣新奇，而是在賣 adoption。最容易被團隊接受的 AI，通常不是最聰明的，而是用幾天之後大家就忘了它叫 AI、只覺得流程變順的那種。這種東西不酷，但真的會被用。

我自己也比較相信這種做法。AI 如果出現在 request、incident、knowledge article、assignment queue 這些熟悉物件裡，團隊學習成本很低。相反地，如果它跑去另一個 portal，還要人重新學一套互動方式，採用率通常很慘。

實操上，我會把導入問題改寫成「AI 出現在哪裡」，而不是「AI 能做什麼」。如果它能直接出現在系統記錄、queue 或 dashboard 裡， adoption 就比較有機會。最後跟主管講的時候，也不要講什麼 transformation，講這四個就好：

• 少切換上下文
• 更快 triage
• 更穩定的摘要
• 更一致的 routing

這才是能過會議的語言。其他那些很會喊的詞，通常只會讓人更想睡。

我會怎麼把這套 rollout 到自己團隊

“Four new AI capabilities — from in-interface assistance to fully autonomous agents.”

這句話其實已經把 Xurrent 的產品路線講完了：不是單點功能，而是從 assistive 到 autonomous 的完整範圍。這種 framing 我覺得比較健康，因為它讓不同成熟度的團隊都能找到切入口，不會一上來就被迫接受最激進的玩法。

白話講，這是一個分階段 adoption model。先從風險低的地方開始，證明有用，再慢慢擴大。這才是 enterprise service operations 的正常節奏。你如果一開始就把 agent 放到高風險流程裡，最後不是收到掌聲，是收到 incident review。

我自己的做法會是三步走。第一步先開 Assist，讓它做摘要和相似 request 查找。第二步再開 Copilot，讓它針對固定類型的單做上下文問答。第三步才挑一個低風險流程交給 agent，讓它在 policy 內執行。不要反過來，真的會出事。

如果要借 Xurrent 的邏輯，我會把 use case 切成三種：

• Assist：摘要、建議、找相似案件
• Copilot：針對記錄做上下文問答
• Agent：執行一個邊界清楚的流程

這樣講給團隊聽很清楚，也比較容易跟資安、維運、主管對齊。每一步都對應不同風險和不同 success metric，不會整團人都在同一個模糊地帶打轉。

可抄的模板

# ITSM Agentic AI rollout template（可直接改成你們內部版本）

## 1) 先挑 workflow，不要先挑模型
- 選一個高頻、邊界清楚的 service workflow
- 定義 AI 介入的確切時機
- 第一版一定要放在既有 ticket / incident 畫面裡

## 2) 分三層上 AI
### Assist
用來：
- 摘要目前 request
- 找相似 incidents / requests
- 提示下一步建議

### Copilot
用來：
- 針對目前 record 做上下文問答
- 解釋歷史、owner、impact
- 草擬回覆給 specialist 審核

### Agent
用來：
- 執行一個低風險 workflow
- 只在明確 policy 與權限內動作
- 每一步都寫入 audit log

## 3) 必備 guardrails
- 開 RBAC，不要讓 agent 到處亂跑
- 記錄 prompts、outputs、actions
- 設 confidence threshold
- 高風險動作一律保留 human approval
- 超出 scope 就直接擋掉

## 4) 資料準備清單
導入前先確認：
- 分類一致
- assignment groups 還有效
- request / incident 歷史可用
- knowledge articles 有在維護
- CMDB 或 service data 沒一堆過期垃圾

## 5) Pilot 成功指標
追這些就夠：
- time to triage
- time to assignment
- time to resolution
- 減少多少 context switches
- AI 建議被接受的比例
- AI 動作需要 rollback 的比例

## 6) 上線節奏
1. 先開 inline summarization
2. 再加 contextual Q&A
3. 只讓一個 agent 跑一個 bounded workflow
4. 每週 review logs
5. 有信任再擴大

## 7) 決策規則
- AI 不能在 system of record 裡工作，就先不要上
- AI 不能解釋自己的建議，就先不要上
- AI 不能被 audit，就先不要上

## 8) 一句操作原則
AI 在 service management 裡的工作，是減少 friction、保留治理，並且待在大家原本就會用的 workflow 裡。

這段就是我會真的丟給平台團隊的版本。它不花俏，但夠用，而且把治理、資料品質、導入節奏都講清楚了。比起喊 agentic，我更在意的是你能不能把它安全地放進既有流程。

原始來源是 Xurrent 的產品更新頁：Agentic AI: Xurrent’s Q2 2026 AI Releases。上面這篇拆解裡，產品觀點和數字來自原文；流程判讀、導入建議和可抄模板則是我根據這份 release 延伸整理出來的。