技術長觀點：與執行長討論代理式 AI

Arvind Mathur：
感謝你與我們一起收看這一集的領袖觀點。我是 Arvind Mathur，擔任 AWS 的企業策略師。今天很榮幸能與同事 Matthias Patzak 展開對談。Matthias 近期在 LinkedIn 發表了一篇部落格，引發了廣泛討論。今天我們將探討該文章的內容，以及它為何能引發大量討論。Matthias，歡迎來到本節目。  

Matthias Patzak：
是的，非常感謝。事實上，這篇文章確實引發了很多討論。我收到了許多留言。

Arvind Mathur：
而最重要的是，這類引人深思的文章所引發的對話，才是最具價值的部分。

我認為這正是文章獲得高度互動的原因，我們身為技術領導者，都曾面臨這類處境：明知必須關注某個新趨勢，卻未能投入足夠注意力。此時若執行長或其他高階主管前來詢問，你總會感到被動。我想這正是文章能引起許多人共鳴、獲得高度互動的關鍵。 

Matthias Patzak：
是的，確實如此。我想這也是為何這篇 LinkedIn 文章能獲得高曝光。文中提到「執行長不得不問技術長：『嘿，什麼是代理式 AI？』」的場景，確實引人關注。 而我在許多組織中仍能看到：技術長、資訊長、工程部副總裁往往忙於日常業務、維持系統正常運作，並且需將資源分配到各項當前重點任務中。而他們其實沒有足夠的資源彈性，不光是心力，還包括人力和預算，去真正嘗試新技術。 

Arvind Mathur：
深表同意。而且我認為，現今技術變革速度飛快，技術長與技術領導者比以往任何時候都更需要投入時間關注新技術。更重要的是，許多技術能力已趨向大眾化，企業領導者對這些技術的認知也大幅提升。當這類問題出現時，你絕不能處於被動地位。你必須投入部分資源去關注這些技術，並主動向企業領導者介紹，就像你之前指出的一樣，對吧？

Matthias Patzak：
是。

Arvind Mathur：
我們來聊聊你對「如何推動這件事」的具體建議吧。我知道這部分也引發了一些討論。你的部分建議頗具挑戰性，我很欣賞，深入探討這些內容會很有意義。

Matthias Patzak：
事實上，我提出的第一個步驟是「將技術討論轉化為業務對話」。因為目前大多數時候，技術長與資訊長仍只專注於「理解新技術」。他們想了解技術的防護機制與成本，卻未採用 Amazon 所謂的從客戶需求反向推導思維。也就是說，他們沒有走出辦公室去觀察客戶與使用者的真實需求。他們沒有真正理解客戶的需求與痛點，也無法以 IT 專家的身份，與業務部門的同事展開業務層面的對話。這就是我在 LinkedIn 文章中提出的第一點建議：將技術討論轉化為業務對話。

Arvind Mathur：
深表同意。我認為必須轉化為業務對話，因為這是創造業務價值的機會。這不只是一項後端技術的改進。我認為文章中引發一些討論的另一個點，是「尋求 10 倍成效的創新，而非僅限 10% 的小幅改善」。坦白說，我很欣賞這個觀點，因為它非常具有挑戰性。尤其在代理式 AI 領域，如今找到這類「10 倍成效機會」的可能性，比過去許多技術都更高。但現實是，我們日常工作中可能 90% 都是「10% 小幅改善」的構想，只有 5% 到 10% 是「10 倍成效」的創新。為什麼你強調要專注於「10 倍成效」的創新呢？

Matthias Patzak：
總體而言，我認為組織中的「逐步迭代改善」確實是組織成功的關鍵，因為這樣的組織具備持續學習的能力。若你了解業務與技術，並能每週、每天都實現 1%、2%、3% 甚至 10% 的改善，這很寶貴。但我觀察到，在關於生成式 AI、通用 AI 乃至現今代理式 AI 的討論中，許多組織僅著眼於「提升內部效率」，卻未思考如何「調整業務模式」。在我看來，未來會發生的情況其實就像 10 到 20 年前「數位原生企業」興起，爾後「行動優先企業」誕生一樣。我們即將見證生成式 AI 原生公司，以及代理式 AI 組織的誕生。若你仍局限於現有業務模式，很可能會被時代淘汰。

Arvind Mathur：
是的，我同意。越早開始尋求「10 倍成效」的機會，對企業越有利。不過在這類情境中，有一點需要留意：若你已處於被動地位，且企業領導者主動找你討論，他們有時也會帶著自己的想法而來。根據我的觀察，這其中的關鍵在於「判斷情境」：有時你必須快速行動，針對執行長提出的想法，例如「嘿，我一直很擔心這個問題，我們能用代理式 AI 來解決嗎？」做出成果並展示。 快速找到方法實現該想法，通常會非常有幫助。與此同時，一旦你透過成果建立了信任與公信力，就能進一步提出：「這不只是一個小幅改善的機會，透過代理式 AI 我們其實能做更多事。」 我知道聊天互動中也針對這個話題展開了精彩討論，這個思路非常好。我們來看第二點建議。

Matthias Patzak：
第二點建議是對傳統思路的調整，我將其重新表述為「組建轉型團隊，而非純技術團隊」。但其核心是「不應局限於傳統 IT 部門的獨立運作」。當然，團隊首先需要理解新技術的核心概念。但若你真的想推出原型、挖掘業務機會，就必須讓銷售總監、營運人員、財務人員與法律人員共同參與。且不應僅讓他們扮演「監督者」角色，而應形成「跨部門轉型討論機制」。因為這不只是是一項技術專案，而是「業務重塑」。

Arvind Mathur：
我認為討論中大家對這一點的認知完全一致。我也深表認同，尤其對於代理式 AI 這類技術而言。若你想專注於「10 倍成效」的創新，這些創新絕不會是「內部技術改進」層面的構想。這類創新機會在於「重新構想客戶體驗產品與服務的方式」、「拓展產品與服務的能力邊界」等層面。這需要全方位的轉型。

Matthias Patzak：
在與客戶的對談中，你對這一點的觀察與感受是怎樣的？ 你看到的是組織真的在組建跨部門轉型團隊，還是仍處於 IT 部門獨立運作的狀態？

Arvind Mathur：
顯然，不同企業的成熟度差異很大。有些成熟度較高的企業已經意識到：僅將其作為技術專案推動是行不通的，並有過相關經驗教訓。但仍有大量組織，依舊以「處理技術專案」的模式來推動這類轉型工作。而我們與技術長或企業高階主管交流時所扮演的角色，就是協助他們理解：應將此視為一個需跨職能、跨部門協作的機會。我個人也從自身經歷中獲得了許多寶貴的啟示。我曾任職於一家保險公司，當時我們試圖改造核保、理賠等流程，儘管這些流程隸屬於營運部門，但參與者絕不僅限營運團隊，還需銷售、產品、風控及客戶體驗部門共同投入。不論進行何種變革，這些部門都必須參與其中。當時我們的目標是將理賠處理時間從 3 至 4 週，縮短到一小時以內。這類大幅變革，絕非僅靠改進內部運營流程就能實現。因此我完全認同。

Arvind Mathur：
好的，接下來我們來看第三點。

Matthias Patzak：
第三點建議是：挑選 2 至 3 個相關的應用場景，並快速推動。核心在於「快速行動」，這些試點專案需「並行推動」而非「逐個執行」，同時要在「有防護機制的前提下追求速度」。開展這類實驗時，「防護機制約束」至關重要，這比「完美規劃」更具實際意義。正如我們團隊同事 Jake Burns 常說的一句話：「不要等到準備就緒才開始，而是透過行動讓自己準備就緒。」 這點我非常認同，尤其在代理式 AI 的應用上，更應如此推薦。此外，快速並行推動試點還有另一層考量：代理式 AI 是新技術，對應的使用案例也較新。既然是實驗，就需要預期約 70% 的嘗試可能會失敗。

若你逐個推動試點，可能前三次都會失敗，直到第四次嘗試才有望成功。因此我建議，身為技術長，不僅要具備足夠的心力，還需在預算與人力上保留彈性，才能實現試點的並行推動。這點引發了大量討論，因為許多組織不僅缺乏這類「風險承受意願」，也沒有足夠的資源彈性。

Arvind Mathur：
正如你先前問到的，我與客戶交流時發現，這或許是他們面臨的首要挑戰。其原因在於，多數技術長此類情境下，既缺乏「並行推動多個大型專案」的能力，也因此沒有足夠的信心。他們會傾向於選擇「更安心的方式」，就連我過去面對新事物缺乏信心時，也會先低調地進行小型實驗，透過學習累積信心後，再逐步加快腳步。

而我認為這裡有個至關重要的點：希望你在與執行長展開討論前，就已完成這些基礎實驗。因為透過小型實驗累積經驗後，你才有信心去探索「10 倍成效」的創新，並開始並行推動。這也是文章中我非常欣賞的核心觀點：不應由執行長主動開啟這類討論。你應先完成實驗、整理好想法後再主動找執行長，如此才能有信心地推動後續工作。

Matthias Patzak：
是的，這必須成為你營運模式的一部分，更要融入企業的文化當中。

Arvind Mathur：
聊天互動中有人提出一個問題：「現今新技術層出不窮，除了代理式 AI，機器人技術也在朝新方向發展，還有核心 AI、資料技術及驅動資料分析能力的新方法等。你如何持續關注這些動態，並透過充足的實驗積累經驗，以便主動向企業領導者提出建議？ 你觀察到的最佳實務有哪些？

Matthias Patzak：
事實上，你不可能針對每個新趨勢都進行嘗試與研究。這就是為什麼組織也需要建立「創新」或「技術雷達」機制。思想領袖 Pascal Finette 曾撰寫《Disrupt Disruption》一書，其中探討了如何辨識技術、市場、客戶層面出現變化的信號。接下來的關鍵是：你多久會接觸到這類信號？ 若某項技術的相關信號頻繁出現，你就必須及時跟進並展開實驗。因此，你還需要針對「實驗」採用不同的工作模式。

例如，面對某些信號，你可能只需讓一名開發人員、設計師或產品經理在週五下午，結合真實客戶需求測試原型。而面對另一些實驗，則需安排一個團隊，在兩週的「時間盒」內專注推動。也就是說，團隊必須在兩週內達成明確目標，且不會額外投入更多經費、人力或時間。但核心在於，你必須具備「辨識信號並採取行動」的能力。或許更重要的一點是：要學會對部分信號說「不」。因而學會優先排序至關重要。

Arvind Mathur：
沒錯，而且你稍早提到的另一點，也是我親身實踐並建議大家的關鍵要素，那就是：​培養好奇心、實驗精神，最終帶動創新的文化。​根據我的實踐經驗，若你在團隊或企業中建立了這類文化，即便沒有制訂明確的策略或行動計畫，團隊成員也會主動展開實驗，並持續關注技術雷達中的新動態。對我而言，最寶貴的時刻莫過於團隊主動找我說：「Arvind，我們一直在研究這項技術，認為它很有潛力。」 這讓我有機會與業務團隊溝通：「我們發現了一項有潛力的技術。是否有機會落地？」 若你已建立這類文化，那非常好。若尚未建立，從現在開始行動吧。因為在當今環境中，若團隊無法自主關注技術動態、開展實驗，那麼當機遇來臨時，你將很難及時把握。

Matthias Patzak：
是的，完全認同。而此舉的關鍵在於，你必須公開實驗的成敗，否則到最後，產品經理或業務部門的同事遲早會抱怨，畢竟團隊將部分資源用於測試新技術，導致資源被分散，影響了業務價值或功能的交付。因此，你必須表彰成功的實驗。即便實驗失敗，其帶來的經驗教訓也算是一種「實驗成果」，同樣需要在企業內部肯定其價值。唯有如此，才能在企業中建立「撥出資源來測試新技術或新業務構想屬於合情合理」的文化。

Arvind Mathur：
非常好。接下來我們看第四點。

Matthias Patzak：
好的，第四點。在我看來，這點引發的討論非常精彩。建議是：在試點階段就為「規模化」做好準備。也就是說，不要只開發「看似亮眼的演示原型」，而應從一開始就打造「具備企業級規模處理能力、可直接上線的解決方案」。在我看來，代理有不同的類型，例如面向知識工作者的代理。例如，客服人員可在桌面端使用代理，實現某項工作流程的自動化。但身為前技術長，我認為「具備智慧的微服務型」代理更讓我感興趣。然而，要將這類代理整合到企業架構與應用中，卻並非易事。

這需要你具備「事件驅動架構」。你還需建立完善的「可觀測性」機制；且至少在原型開發初期，需實現人類擔任監督者、參與迴圈，有時甚至是完全脫離迴圈的管控模式。若你將這類代理部署到生產環境，就能深入了解其能力。或許不必覆蓋 100% 的流量，只需針對 1% 的使用者、1% 的流量即可。如此一來，在測試「10 倍成效」創新構想時，就能有效控制風險影響範圍。但對許多人來說，理解並在自身環境中落實這點並不容易，原因可能在於他們缺乏「容錯文化」。

Arvind Mathur：
而且我認為這點與前面提到的內容也有密切關聯。事實上，就連「實驗」本身也存在階段性。有些實驗可能完全獨立於企業核心業務之外。若其中某些實驗展現出潛力，接著就可以先在 IT 部門內部展開進一步實驗。你剛才提到的觀點我非常認同：既然企業已有透過服務與 API 運作的業務流程，不妨在內部為這些流程賦能智慧。這能讓你累積經驗，更有把握打造符合生產級標準的代理能力。如此一來，當你與團隊討論跨部門的「10 倍成效」業務機會時，就能有信心在生產環境中並行推動多個創新構想。這一點非常好。在「從實驗到創新」的過程中，先在技術部門內部開展這類嘗試，本身就是重要的一步。

如今我也理解了針對這點的相關意見，確實有很多人對此感到不安。他們認為，如你先前所言，早期開展實驗、控制風險影響範圍非常重要。而我們真正想強調的是：這些前期實驗必須在與業務部門展開討論前完成。若你已完成這些「小規模、低風險」的試點與實驗，那麼當業務機會出現時，就能迅速採取行動。此時你已不再處於「實驗」階段，且有望擺脫「70% 嘗試失敗」的困境，此時能提供更穩定的技術能力。​

Matthias Patzak：
是的，我完全認同。這就是為何人們需要及早親自體驗新技術，我的建議是，可聯合合作夥伴與 AWS 客戶團隊，讓他們指導你如何實際操作新技術。

Arvind Mathur：
好的，我們來看第五點。

Matthias Patzak：
好的，第五點。雖說這點看似理所當然，但仍有討論空間。第五點建議是：關注業務影響，而非技術指標。也就是追蹤營收增長、成本降低、週期時間縮短、轉化率變化等指標，而非模型準確度或使用者適應率。當然，仍需關注使用者適應率等先行指標。你也需要了解一些品質指標，但引入新技術的目的不應是「為了技術而技術」，而是要麼實現業務流程 10% 的效率提升，要麼打造出「10 倍成效」的使用案例。因此，你必須針對每個上線的解決方案，結合真實使用者資料衡量其實際業務影響。你不應只是在功能清單上「打勾確認」。你真正需要做到的是能明確表示：「透過這款新的代理式 AI，我們成功將網站跳出率降低了 X%。」

Arvind Mathur：
我認為大家對這點的看法完全一致。我也想快速分享一下自己的親身經歷，同樣是之前提到的理賠流程加速專案。一開始推動該專案時，我們犯了一個錯誤：團隊中不同角色採用了不同的衡量指標。例如，營運團隊有一套營運指標。技術團隊以「功能交付」作為營運指標，銷售團隊則有另一套衡量標準。正因為如此，專案最初無法達到「10 倍成效」的目標。直到所有人都統一了目標，將理賠時間從 3 週縮短至 5 分鐘，情況才有所改變。這不僅讓團隊方向一致，更激發了創造力：跨部門團隊共同找出了阻礙達成「10 倍成效」的障礙，並提出了富有創意的解決方案。這不僅是「衡量指標」的問題。透過統一目標來凝聚團隊，讓大家集中精力突破阻礙「10 倍成效」的核心難題，這本身就是一種極佳的方法。

Matthias Patzak：
是的，你說得對。「目標一致」這一點非常重要。

Arvind Mathur：
關於這點的討論非常精彩。我希望能繼續與大家交流，收集更多相關意見。但在這次對談中，我最大的收穫，也是想推薦給所有人的是：從現在開始主動「關注技術動態」。當前技術變革迅速，你必須提前了解技術潛力，並主動向企業領導者提出相關構想，才能搶佔先機。因此，基於這點，我的建議是：現在就登錄你的 AWS 帳戶，與 AWS 客戶團隊溝通，明確如何開始使用這些工具並立即採取行動。

Matthias Patzak：
是的，我完全認同。而你應使用的工具或 Amazon 服務，就是 Amazon Bedrock Agent Core。儘管我們有多款與代理相關的服務，但在架構中整合代理的核心，仍是 Amazon Bedrock Agent Core。這也是我建議各家企業儘早親自體驗的服務。

Arvind Mathur：
太棒了。讓我們開始打造吧。

Matthias Patzak：
讓我們開始打造吧。

立即收聽

立即收聽

立即收聽