Kyndryl 與 AWS 推出 Agentic Modernization：傳統系統整合服務開始變成可重複執行的軟體

專題編輯：Adrian Hsu｜企業 AI 策略編輯

企業不缺新的系統，最缺的是把舊系統安全改掉的方法

大型企業的核心系統往往運作十幾年，承載訂單、財務、製造、客戶資料和大量隱藏在程式碼裡的業務規則。當管理者想更換介面或導入 AI，第一個阻礙通常不是找不到新的 SaaS 產品，而是不確定舊系統有哪些依賴、哪些規則沒有文件、哪些批次作業影響下游部門，以及修改一個欄位會不會造成帳務或物流異常。傳統系統整合因此需要大量訪談、程式盤點、規格整理、開發與測試，進度難以完全標準化。

Kyndryl 與 AWS 此次公告試圖針對這個結構性問題提出新交付方式。Kyndryl 表示，方案把自家 Agentic Modernization services-as-software、AI 支援的工程工作流與 AWS Transform 結合，目的是在應用、基礎設施和核心系統現代化過程中提高一致性，降低轉型風險。這是一個包含方法、軟體與工程服務的整體敘事，而不是宣布某一個新的通用 AI 聊天機器人。

要理解新聞的重要性，先要看系統整合產業如何賺錢。傳統模式常以專案範圍、人月、階段交付與維運合約計價；客戶買的是供應商團隊理解複雜系統並完成轉換的能力。AI Agent 出現後，部分診斷、文件整理、程式對照、轉換規劃與測試準備可以變成可重複執行的軟體任務。若真的能維持品質，交付能力便不再完全受到可派遣工程師的人數限制。這是「服務軟體化」的重要商業含義。

Services-as-software 到底是什麼？它不是把顧問改叫 AI Agent

Kyndryl 在官方公告中把 services-as-software 描述為一種以自動化、智慧工作流及可規模化數位流程交付專業服務的模式。白話來說，原本需要顧問逐項重做的部分工作，變成有規則、有輸入、有輸出、有監督的軟體服務。它不代表不再需要顧問，而是試圖讓專業經驗以更低的重複成本被使用，並讓人類專家集中處理例外與高風險決策。

以企業核心系統盤點為例。傳統團隊可能先訪談十個部門、閱讀數千頁技術文件，再請工程師搜尋程式碼中的資料表、介面與批次排程。代理化流程可先進行文件分類、程式依賴分析、資料流整理及規格草稿產生，再由系統負責人驗證哪些關係是真實、哪些僅是模型推測。若這些步驟被標準化成工作流，下一個專案就能沿用可用的方法、工具與交付格式，而不必從空白開始。

但能複用不等於能複製結果。兩家企業可能都使用大型主機，法規、資料品質、例外邏輯、營運時間和上下游介面卻完全不同。標準化的應該是工作流程、證據格式、權限管理和驗收方法，而不是假設所有客戶可以套用同一份程式轉換模板。若供應商無法說明哪些部分共用、哪些需要客製及如何處理例外，「services-as-software」就容易淪為新的行銷名詞。

AWS Transform 在合作裡扮演什麼角色

AWS Transform 是 AWS 提供的代理式現代化工具組合，主要方向是協助企業分析既有程式與環境、萃取系統脈絡、規劃及執行轉換。AWS 官方先前的主機現代化技術文章展示了從舊程式碼和資料結構進行逆向理解，再建立業務邏輯、整合介面及未來架構的工作方向。這些技術步驟與 Kyndryl 擅長的企業大型系統營運與工程服務，形成此次方案的互補定位。

對客戶來說，工具名稱並不直接代表能處理自己全部的系統。更具體的問題是：支援哪幾種原始語言、資料庫與批次工作？能否在封閉網路或符合既有資料安全政策的環境執行？哪些中介文件可以保存？轉換後的程式是否有可重現測試？與既有雲端、地端或混合環境的相容性如何？這些條件必須依實際產品版本、服務契約與 PoC 結果核對，不能把合作公告視為全部功能已普遍可用的證明。

若從工作責任拆解，AWS 提供的是工具與雲端技術能力的一部分，Kyndryl 則主張提供企業營運經驗、服務編排、工程與治理；最終的業務決策權、資料處理責任與正式上線批准仍應由客戶依合約與內部制度管理。這種分工是否實際清楚，將決定大型企業能否信任代理化服務。

合作公告另提到 Kyndryl Agentic Framework 與 Kyndryl Bridge，作為推動可規模化 AI 工作流的架構與營運平台。這些產品與方法是否能與企業現有 ITSM、CMDB、Git、測試和監控工具串接，對長期成效的影響可能比簡報中的單次轉換速度更大。因為現代化並非一次性的資料搬遷，而是持續調整仍在運作的系統。

一個舊系統改造案，哪些工作適合代理化

典型現代化工作可拆成幾個連續但不同的任務。第一層是資產發現：哪些應用正在運作、彼此怎麼交換資料、哪些批次任務有時間依賴、誰負責維護。代理能協助整理分散資訊，但最終資產範圍要由系統擁有人確認。若一開始就漏掉關鍵服務，後續再快的轉換也可能在上線時暴露嚴重問題。

第二層是業務規則萃取。舊程式碼裡的條件判斷可能對應折扣、信用額度、合約期限或特殊計費規則。模型可以把程式轉成自然語言規格草稿，並找出相似或互相矛盾的條件，但不能保證每條註解都是真正的現行規則。工程師需要結合實際輸入輸出、營運資料與部門確認，才能建立可信的規格基線。這一步如果做對，後續的測試與新系統設計才有穩固基礎。

第三層是轉換設計。企業可能選擇保留既有核心、逐步包 API、替換部分模組，或在證據足夠時重建新的系統。每條路線對營運中斷、資料一致性與供應商依賴的影響不同。AI 可以協助產生架構選項與估算工作量，但不能自行決定企業究竟能承受多少風險。現代化不一定等於全部搬到雲端；合理方案也可能是在地端先建立文件、測試與資料治理，分階段降低技術負債。

第四層是驗證與切換。轉換完成後，必須比較新舊系統在相同輸入下的輸出，檢查資料遺失、金額差異、例外處理、權限與效能。對財務、金融或製造排程系統而言，表面上的功能正常並不等於商業行為相同。驗收需要由業務單位與工程團隊共同確認，並規劃故障時能否回到原系統。代理可以大量準備測試資料與差異報表，卻不能替代實際的切換批准。

這些工作裡，最值得軟體化的是可標準定義的輸入輸出、可重複的檢查、能以測試比較的規則，以及可以追查的決策流程。最不適合完全自動化的是契約責任、重大業務取捨、資料主權與不可承受的停機風險。把兩者劃分清楚，才能判斷合作方案是否真的適合自身企業。

系統整合的成本結構，可能因此重新分配

傳統大型改造案的成本包含需求訪談、技術分析、開發、資料轉換、測試、專案管理及正式切換。AI 若能降低前幾項重複工作，供應商可能用同一組工程團隊服務更多客戶，也可能把節省的工時投入更深入的驗證與維運。但客戶不應直接假定供應商成本下降必然等於自己的總支出同比下降，因為 AI 工具授權、資料治理、測試資源、監控與風險保險等成本也可能上升。

另一個變化是交付計價。若大部分產出都可以標準化，顧問服務有機會從單純人月計價轉向按系統、按工作流、按使用量或按可驗收成果收費。這屬於對產業商業模式的分析，並非 Kyndryl 已公布採用所有這些定價方式。企業在簽約前仍應要求廠商清楚說明哪些工作列入固定費用、哪些屬於變更需求、模型使用成本如何分攤，以及錯誤返工由誰承擔。

所謂「顯著降低轉型風險」也必須拆成可衡量項目。是否減少未發現的相依系統？是否縮短需求確認時間？是否提升轉換程式的測試覆蓋？是否降低切換後的重大故障？這些指標需要在相近類型的案件中比較，單次展示很難得出結論。管理者應要求至少有基準時程與交付品質資料，才能辨識速度進步是來自 AI、流程改善，還是專案範圍縮小。

對台灣企業與 AI 顧問產業的啟示

台灣中小企業不一定有大型主機或複雜的全球資料中心，卻常遇到 ERP、POS、CRM、報價與財務系統各自運作、資料難以連接的問題。從 Kyndryl 這類大型服務商的方向可以抽出一個適用原則：真正能長期提供價值的 AI 服務，不是進公司展示幾個對話技巧，而是了解產業工作模式、提出完整導入路徑，並留下持續可操作的系統與驗收證據。

假設一家製造業企業想在現有 ERP 和品質管理系統之間建立異常追蹤。若顧問一開始就推薦特定模型或工作流工具，可能忽略各部門資料如何產生、誰在批准異常、哪些欄位能代表最終品質。更適合的做法，是先盤點營運規則與跨系統資料流，建立改善目標，再依環境條件選擇 API、RPA、規則引擎、AI Agent 或組合方案。這個例子是架構推演，不代表 Kyndryl 已在該情境有已證實的客戶成果。

對服務提供者而言，差異化應來自產業理解與可複製的交付資產。顧問可以把需求診斷、資料盤點、權限審查、PoC、成本評估、驗收與後續監控分成可組合的模組，讓企業依問題選擇深度，並能按階段擴大。這些模組可以使用共通的技術底座，但必須允許不同業務規則、資料環境與治理條件。客戶不需要一套不可變的套裝答案，而需要知道方案可以如何依自己的營運進行設計。

這也改變企業對顧問的期待。過去可能詢問「會不會使用某個 AI 工具」，未來更值得詢問的是「如何證明系統沒有改錯」「誰負責模型輸出的驗收」「完成後我是否能持續維護」「資料與工作流是否可以轉交給內部團隊」。只有答案足夠清楚，AI 才能成為可靠的系統現代化能力，而非一場交付後就結束的展示。

採購 Agentic Modernization，先要求四份證據

第一份是系統與風險盤點：受影響系統、資料分類、關鍵依賴、不能中斷的業務，以及需要遵守的法規。第二份是轉換與驗收基線：哪些功能、報表與資料必須保留，如何在新舊系統之間進行可重現比較。第三份是權限與責任矩陣：代理可以存取什麼、可以執行什麼、誰批准變更、出錯時誰負責復原。第四份是維運及可移轉性方案：顧問離場後，企業如何查看代理工作流、取得紀錄、替換服務商或擴大部署。

若供應商聲稱能縮短開發或改造時間，應要求用可比較的專案任務做驗證，並把原本人工工時、工具費、覆核費及返工成本全部納入。POC 的成功條件不應只寫「完成介面」或「AI 能執行」，而要有資料正確率、可回復性、程式品質、業務簽核與實際維運可行性。如此一來，企業才有基礎判斷何時進入正式擴大階段。

對整合商與顧問而言，也應建立獨立於模型供應商的資產，包括產業需求範本、資料連接規格、權限政策、測試集、工作流定義與驗收報告格式。模型更換或平台升級時，這些資產仍能沿用，服務才不會被單一產品週期綁定。對客戶而言，這類可移轉資產往往比短期節省多少 API 費用更重要。

下一個競爭點：誰能持續交付，而不是一次完成改造

Kyndryl 和 AWS 的合作公告代表一個可以被觀察的產業方向：大型服務商希望把累積多年的顧問經驗、流程規範與工程交付方法轉成可軟體化執行的工作流。它可能改變顧問定價、技術資產的持有方式與企業選擇服務商的標準，但是否真正降低風險、提高效益，仍須等待更多可核實的客戶結果。

現代化不是一次搬遷就結束。系統還會更新、法規還會改變、新業務還會進來，企業需要持續理解既有資產並安全修改。真正有價值的 agentic modernization，應把每次盤點、設計、變更與驗收的證據留下來，讓下一次工作比上一次更可靠。當系統整合服務從大量客製勞務走向可重複的軟體交付，決定競爭力的可能不再是派出多少工程師，而是能否將專業判斷變成可持續改善、可以被客戶信任的系統。

大型系統現代化的四種選擇，不能全部叫作「搬到雲端」

企業常把系統現代化理解成替換舊技術，但不同行動對業務的影響差異很大。最保守的做法，是保留核心運作方式，先整理技術文件、資產清單、測試與監控，降低既有系統不可理解的風險。下一種是把既有能力包成 API 或服務介面，讓新系統可以安全存取，但仍保留核心邏輯。第三種是逐步重構，將容易分離的模組改成新的架構。最後才是全面重建，適用於經過完整評估、確定可承受切換與資料遷移風險的場景。

AI Agent 可以參與上述不同路線，但任務與風險不一樣。保留系統時，代理主要協助盤點、產生文件與測試；包 API 時，需要確保資料契約、身份認證與呼叫限制；重構模組時，必須追蹤舊有業務規則是否完整保留；全面重建則涉及資料移轉、不同系統的並行運作與最終切換決策。管理者應先確定哪條路線符合營運目標，再決定 AI 的使用方式，而不是因為有最新代理工具就假設必須採用最激進的方案。

例如一家連鎖零售企業的 POS 系統與會計系統多年來依賴批次檔案交換資料。若目的是改善每日銷售分析，可能只需要建立可靠的資料抽取與品質檢查流程，未必需要替換全部 POS。若目的是支援跨國即時庫存與訂單承諾，則可能需要更深入的介面重構。兩項需求都能稱為現代化，成本與治理範圍卻完全不同。供應商若沒有充分理解企業的業務目標，提出再完整的代理系統架構也可能解錯問題。

服務商真正應交付的，是每一種路線的前提、好處、風險、時間成本與可回復性。客戶需要看到哪一部分被保留、哪一部分被改造、何時必須停止與重新評估。當方案能讓企業比較多種可選路線並保留必要的客製空間時，才比較符合策略合作夥伴的定位，而不只是銷售一套固定產品。

舊系統最難搬走的是隱藏規則，不是程式語言本身

許多核心系統的程式碼裡保留了十幾年前訂定的條件與例外。某個折扣欄位可能依客戶等級、合約日期與商品組合決定；某筆財務資料可能必須經過特定月底批次作業，才算完成正式入帳。當年寫下規則的人可能早已離職，文件未必完整。AI 能協助閱讀大量程式碼，卻仍然需要現有營運資料與業務負責人確認，才能知道哪些行為應該繼續保留、哪些其實是已經過時的歷史負擔。

因此現代化專案不能只比新舊程式碼在語法上是否等價，更要核對業務結果是否一致。舉例而言，新系統在同一筆訂單上產生相同總金額還不夠，還要確認稅額、折扣、庫存扣抵、取消交易與異常處理的細節是否符合現行政策。若舊系統原本就存在問題，管理者還要決定是維持舊結果以保證相容，還是在新系統明確修正，並承擔修正所需的跨部門驗收。這些都是業務決策，不能只交給程式代理處理。

可以用「黃金測試資料」管理這些風險。企業挑選一組經業務單位同意、涵蓋正常、邊界與異常情境的案例，保存預期輸入輸出，讓新舊系統反覆比較。當代理產生新程式碼、資料轉換腳本或介面定義，必須通過這份測試集，並記錄每次差異與人工批准的例外。測試集需要持續更新，因為業務規則會改變；但其版本與批准紀錄應被保存，讓未來維護者理解每個結果為何被接受。

若企業關心的是資料治理，還需檢查欄位定義、資料來源、更新頻率與責任人。AI 能快速產生資料字典初稿，但不能因此認定各系統對同一個詞有相同定義。例如「營收」可能在業務端指訂單總額，在財務端指已認列收入。資料整合如果沒有先確認定義，就可能把看似一致的數字合成完全錯誤的決策報表。真正可重用的現代化資產，應包含來源、版本與業務含義，而不只是技術上的轉換程式。

Agentic Modernization 的價值，該用什麼指標驗收

如果專案目標是系統盤點，應衡量已辨識資產與相依關係的完整度、人工確認時間及遺漏的高風險依賴。若目標是程式轉換，應衡量同一測試集下的功能一致性、回歸失敗率、需要人工修正的比例與交付時間。若目標是正式遷移，則必須增加資料一致率、可用性、切換時間及故障回復能力等營運指標。每一種目標的成功條件不同，不能全部用「代理自動完成多少程式行數」代表。

比較人工作業與 Agentic 方案時，也要保留公平基準。供應商若把最熟悉、資料最完整的模組交給代理，卻把最複雜的功能留在人工處理，最後得到的平均速度可能無法代表整體專案。企業應挑選多種難度的代表性工作包，明確記錄排除範圍、資料品質和測試條件。更重要的是計入人工覆核與返工；如果代理在短時間內產生大量程式碼，卻需要同仁耗費更久時間追查差異，實際交付成本未必下降。

治理指標也應成為正式驗收的一部分。每個代理必須有清楚的身份、可使用的工具、可存取的資料範圍與操作紀錄。正式部署或資料遷移應經過人類負責人批准，重大變更必須能回復。對高敏感業務而言，還要評估供應商是否能在既有資安制度與執行環境中工作，不能因產品展示在雲端順利，就假設封閉網路、地端部署或客戶特定合規要求都已得到支援。

財務上的效益評估應納入全部成本：原有顧問與工程工時、AI 工具授權、模型執行與運算、測試環境、資料清理、資安審查、變更管理及正式維運。供應商若聲稱可以縮短專案週期，應要求將其轉成可量測的里程碑與交付物，而非單靠展示速度。經過這樣的驗收，企業才知道服務軟體化究竟是降低成本、提升品質，還是把原本的部分工作轉移到另一個費用項目。

系統整合商下一步如何打造自己的可複用資產

AI 導入服務若依賴顧問個別能力，往往每換一位成員就要重新傳遞知識。要走向 software-as-service 之外的 services-as-software，供應商需要把經驗整理成能被版本管理的交付資產。第一組是產業與業務模型，例如常見工作流程、角色權限、交易資料與例外規則；第二組是技術資產，例如連接器、資料字典、測試模板與可配置代理工作流；第三組是治理資產，包括批准矩陣、稽核紀錄、風險測試與回滾計畫。

這些資產的重點不是讓所有客戶看起來相同，而是將重複工作標準化，將真正需要理解產業的部分保留給專業團隊。供應商可以提供不同層級的合作：先做診斷與路線選擇，再做範圍明確的試點，接著串接正式系統，最後進入持續維運與優化。每個階段都有獨立驗收，也能依企業預算與內部能力調整。這種模式可以減少「第一次會議就賣固定工具」所造成的不信任感。

當平台與流程可以複用，商業模式也可能改變。除了既有的人月報價與專案承攬，服務商可能逐步提供固定範圍的診斷方案、按模組計價的交付服務，或綁定持續營運指標的維運合約。這些是商業模式選項，不表示 Kyndryl 已公開宣布採用。無論用哪種定價，關鍵仍是能否定義清楚的工作範圍、變更條件與責任歸屬，讓客戶看到價格與成果之間的關係。

對買方而言，選擇權同樣重要。當服務商能清楚標示哪些資料與工作流程由客戶持有、哪些共用元件由供應商持有、契約終止後可移轉哪些文件和測試，合作才更有長期可信度。反之，如果現代化完成後所有規則仍只能由原廠解讀，企業可能只是用新的技術換來新的依賴。服務軟體化的成熟，不只是顧問會用 AI，而是把交付資產、責任與治理做得更加透明。

導入前 90 天先證明一段系統可以被理解與安全改造

前 30 天宜以選定的核心業務為單位，完成系統清冊、責任人、資料流、變更限制與基準工作量。管理者要先確認改善目標，是縮短維護時間、降低技術負債、提升資料品質，還是建立新產品能力；不同目標會決定後面應選擇什麼現代化路線。這一階段最重要的產出，是經業務和 IT 共同確認的現況圖與風險清單。

第 31 至 60 天建立受控的試點任務包，讓代理輔助分析一個規模有限、具有明確邊界的舊模組。輸出應包括現行規則、相依系統、轉換方案與測試案例，再由人類專家確認。若資料缺漏或系統相依關係無法確認，就應列為停止或擴充調查條件，而不是為了完成 PoC 擅自補上未知的事實。這段過程也可以測出導入工具真正需要的資料與授權條件。

第 61 至 90 天才測試改造與回歸驗收，讓相同輸入在新舊流程中比較，檢查資料與業務結果差異，並演練回滾。最後由管理層依品質、成本、風險與維運可行性決定是否擴大。即使最終選擇暫不進行全面遷移，完成可重用的系統清單、資料字典、測試基線與風險矩陣，仍然是對下一次現代化投資有價值的成果。這正是把一次專案服務逐步轉成企業長期數位能力的起點。

一張可供採購與專案經理使用的現代化驗收表

Kyndryl 與 AWS 宣布的是新的整合交付方式，而不是一張能保證任何企業轉型成功的成績單。企業在要求服務商導入 Agentic Modernization 時，可以先挑選風險可控、依賴關係清楚的系統，使用以下獨立編製的評估矩陣確認是否真的做到「持續現代化」。

所謂「可重複執行」，應表現在相同類型系統能重用盤點規則、測試與部署流程，而不是把一次性顧問簡報改成工具儀表板。若供應商無法提供可審查變更與明確責任歸屬，採購方仍難以把 AI 作業視為持續營運能力。

本文附上的 legacy_modernization_acceptance.csv 是空白可複用範本，並非 Kyndryl 或 AWS 官方部署架構。

常見問題

Kyndryl 與 AWS 推出的是新 AI 模型嗎？ 不是。11 月 5 日公告的是整合 Kyndryl Agentic Modernization 服務軟體化能力與 AWS Transform 的企業現代化方案。

Services-as-software 是否代表不再需要系統整合顧問？ 不代表。部分重複工作可以自動化，但業務規則確認、風險決策、驗收與正式上線仍需要專業人員與企業權責單位。

台灣中小企業可以直接照搬這套方案嗎？ 應先評估自己的系統規模、資料環境與預算，再決定使用何種工具與服務方式。較能移轉的是盤點、治理、測試及可複用工作流的方法。

資料來源

1. Kyndryl，與 AWS 推出代理式現代化整合方案，2026／11／05
2. Kyndryl 投資人新聞稿，2026／11／05
3. AWS，主機系統 Agentic AI 現代化方法

圖片資訊

封面圖片為原創概念示意圖，呈現既有系統向模組化工作流轉換的抽象路徑，不是 Kyndryl 或 AWS 的真實系統架構圖。

延伸閱讀

探索更多 AI 工作實務