~/blog/openclaw-legacy-system-integration-without-api-2026.md
API 串接與系統整合 · 2026 / 03 / 29

沒有 API 的老舊系統,重寫還是用 OpenClaw 畫面自動化串接?

Eric — 浪花科技創辦人 / AI 架構師
Eric
浪花科技創辦人 · AI 架構師
沒有 API 的老舊系統,重寫還是用 OpenClaw 畫面自動化串接?
目錄 table-of-contents.md

沒有 API,也能串接老舊系統嗎?

可以。當內部老舊系統(沒有 API、原廠已不維護、跑在過時瀏覽器或終端機介面)無法用傳統方式對接時,你不必砸大錢重寫或汰換它,而是改用「畫面層」自動化來搬運資料。本文主角 OpenClaw 是一個結合大型語言模型(LLM)與電腦視覺(CV)的自主型 AI 代理人,它像人一樣「看畫面、理解意圖、操作介面」,因此能在完全不改動舊系統一行程式碼的前提下,把資料擷取出來,再透過 Webhook 打進你的新系統。

換句話說:沒有 API,就用「擬人化操作」當作臨時 API。底下會說明為什麼老舊系統難搞、傳統 RPA 為何脆弱、OpenClaw 的運作原理、一段任務設定範例,以及導入時要注意的成本、資安與穩定性。

在系統開發與企業數位轉型這行打滾多年,相信不少人都遇過這種讓人血壓飆升的經典情境:老闆或 PM 興沖沖地跑來說:「我們買了最新的 AI CRM 系統,只要把舊 ERP 的資料串過去就好,很簡單吧?」

簡單個大頭鬼。當你打開那套號稱「企業核心」的 ERP,發現它是一套跑在舊瀏覽器上、甚至還有藍底白字終端機介面的老古董。想找 API 文件?沒有這種東西。想請原廠開 API 端點?原廠不是收掉了,就是開出高額報價外加漫長的開發期。於是,數位轉型大夢往往就卡死在這座「資料孤島」前。

為什麼老舊系統是企業數位轉型最大的絆腳石?

在談解法之前,先釐清「沒有 API」為什麼這麼致命。現代軟體架構(如 Headless 架構、微服務)大多建立在 RESTful API、GraphQL 或 Webhook 之上。API 就像系統之間的溝通橋樑;一旦沒了橋,資料就只能靠人工搬運,問題會像滾雪球一樣放大。

  • 資料孤島效應:舊系統的訂單無法即時同步到新的電子報或行銷系統,導致自動化流程在源頭就斷掉。
  • 人工錯誤率高:每天請人把 ERP 資料逐筆 Key 進新 CRM,不只浪費人力,只要打錯一個數字,下游報表就跟著全錯,而且很難追查。
  • 技術債越滾越大:為了屈就舊系統,團隊常被迫寫一堆「暫時性腳本」當補丁,久了變成沒人敢動、也沒人看得懂的維護黑洞。

關鍵在於:這些舊系統「還堪用、不能停」,但又「無法被現代工具直接讀寫」。多數企業卡在「全面汰換太貴、繼續手動太痛」的兩難。突破口,就在於換一個對接的「層次」。

傳統 RPA 為什麼那麼脆弱?

過去遇到沒有 API 的情況,工程師通常只能咬牙硬幹傳統的 RPA(Robotic Process Automation,機器人流程自動化)。RPA 的概念是錄製或編寫一連串的滑鼠點擊與鍵盤輸入,讓機器人模擬人在介面上的操作。立意很好,但實務上非常脆弱,原因在於它通常綁死在「固定位置」或「固定選擇器」上:

  • 依賴座標或固定選擇器:腳本常記錄「點第 X、Y 個像素」或「點某個固定 id 的按鈕」。一旦按鈕位移、版型改版、或選擇器變動,腳本就找不到目標而報錯。
  • 依賴硬等待(Hard Sleep):為了等畫面載入,傳統做法常用「固定睡幾秒」。網路快時浪費時間,網路慢時則還沒載入完就去抓,結果抓到空值或錯位資料。
  • 缺乏判斷力:遇到非預期的彈窗、警告訊息或轉圈圈,腳本不會「想辦法」,只會卡死或繼續往下執行,造成錯誤擴散。

結果就是:腳本三天兩頭罷工,半夜警報響不停,維護成本反而把當初省下的開發成本吃光。這正是 OpenClaw 想解決的痛點。

OpenClaw 如何在沒有 API 的情況下打通老舊軟體?

OpenClaw 不再依賴死板的 XY 座標點擊,它是一個結合了 LLM(大型語言模型)與 CV(電腦視覺)的自主型 AI 代理人(AI Agent)。它最大的轉變是:用「人看畫面的方式」去理解與操作介面,而不是用「程式記住位置」的方式。

核心原理一:語意視覺辨識

當你下達指令「去進銷存系統把昨天的訂單匯出成 CSV」,OpenClaw 會先掃描畫面,理解哪裡是輸入框、哪裡是「匯出」按鈕。判斷依據是「這個元素看起來像什麼、旁邊的文字寫什麼、在版面中扮演什麼角色」,而不是它的絕對座標。因此就算按鈕從左邊換到右邊、甚至換了顏色,它依然認得出來——這正是它比傳統座標式 RPA 耐改版的根本原因。

核心原理二:以意圖驅動的 DOM 操作

對於 Web 介面的老舊系統,OpenClaw 能解析背後的 DOM 結構。即使元素沒有標準的 id 或 class,它也能透過上下文(鄰近文字、表格表頭、欄位語意)推斷出該抓取的資料節點。對工程師的意義是:你不必再去逆向那些充滿巢狀 <table> 的老舊 HTML,也不必為了沒有 id 的按鈕寫一堆脆弱的選擇器。

核心原理三:動態等待與異常自我修復

有別於傳統 RPA 的「硬等待」,OpenClaw 具備動態感知能力:它會觀察 DOM 變化與畫面渲染是否完成,確認資料真的載入後才動作,藉此降低因網路延遲造成的抓取失敗。遇到系統卡頓轉圈圈時,它懂得「等待」與「重試」,並能判讀錯誤訊息,必要時發送 Slack 通知給工程師接手,而不是直接當機。

實戰演練:用 OpenClaw 讀取老舊 ERP 數據

身為工程師,不看點 Code 就是不對勁。下面用一段簡化的 OpenClaw 任務設定腳本(YAML 風格),示範如何讓代理人登入舊系統、抓取資料,再透過 Webhook 打回新系統。重點不在語法細節,而在「思維方式」的轉變:你描述的是「做什麼(意圖)」,而不是「點哪個座標」。

# OpenClaw 任務配置腳本示例
name: Legacy_ERP_Data_Extraction
agent_model: claw-vision-pro-2026

tasks:
  - step: 1
    action: navigate
    target: "http://192.168.1.100/old-erp/login"

  - step: 2
    action: visual_fill
    target_description: "使用者帳號輸入框"
    value: "${ENV.ERP_USER}"

  - step: 3
    action: visual_click
    target_description: "登入按鈕"

  - step: 4
    action: extract_table
    target_description: "今日出貨單總表"
    output_format: json
    save_as: "daily_orders"

  - step: 5
    action: api_post
    endpoint: "https://new-crm.roamer-tech.com/api/webhooks/import"
    payload: "{{daily_orders}}"

看出差別了嗎?每個步驟靠的是 target_description(語意描述),而不是元素座標或寫死的選擇器。OpenClaw 以意圖驅動,直接定位表格、擷取資料並轉成結構化的 JSON,最後再打 API 送到你的現代化系統(例如 Laravel 或 WordPress 端點)。把這個流程拆解成可重用的五個動作,你大致就能套用到多數「沒有 API 的舊系統」場景:

  1. 導航(navigate):進到目標頁面,例如內網的舊系統登入頁。
  2. 填值(visual_fill):用語意找到欄位填入資料,帳密建議放在環境變數,不要寫死在腳本裡。
  3. 點擊(visual_click):以語意定位按鈕,避開座標式 RPA 的脆弱點。
  4. 擷取(extract_table):把畫面上的表格直接轉成結構化資料(如 JSON)。
  5. 送出(api_post):把擷取結果經 Webhook 推進新系統,完成「舊→新」的資料接力。

導入 OpenClaw 的三大優勢

用「畫面層」對接老舊系統,相較於重寫或硬接 API,通常有三個明顯好處:

  • 成本效益高:不必啟動動輒上百萬的舊系統客製化專案,也不必因為「無法串接」而被迫提早汰換還堪用的核心系統。
  • 部署速度快:撰寫自動化腳本通常以「天」為單位,相較傳統 API 開發冗長的規格溝通與測試,能更快看到成效。
  • 無侵入性串接:對舊系統而言,代理人就只是一個「不會喊累的操作員」,完全不需更動舊系統的任何程式碼或資料庫結構,系統穩定性不受影響。

需要提醒的是:這類做法的本質仍是「模擬人操作」,因此舊系統若做了大幅改版,腳本仍需要維護調整——只是因為改用語意定位而非座標定位,耐受度比傳統 RPA 高很多,而非完全免維護。把它定位成「優雅的過渡橋樑」,會比「一勞永逸的銀彈」更貼近現實。

打破限制,迎接 Agentic 自動化時代

技術演進的目的,是解決真實世界的泥淖。「沒有 API 也能串接資料」對許多卡在資料孤島的企業而言,已經從一句口號變成可落地的選項。它不是要你放棄正規的 API 整合——如果舊系統還有機會開放 API,正規對接仍然更穩定、更可維護;但當 API 真的不存在、原廠也回不來時,以 AI 代理人從畫面層搭一座過渡橋樑,往往是兼顧成本、速度與穩定性的務實解。

需要專業團隊幫你打通系統任督二脈嗎?

還在為公司內部那些連 API 都沒有的老舊系統頭痛嗎?別再讓工程師或業務助理把時間耗在無意義的複製貼上。浪花科技擁有系統架構重構與 AI 代理人導入經驗,能協助你評估「該硬接 API、還是先搭畫面層橋樑」,量身打造最適合的自動化方案。

👉 立即填寫表單,讓我們的架構師為你進行免費諮詢:聯絡浪花科技(Contact Us)

延伸閱讀

// FAQ

常見問題

老舊系統沒有 API,還能跟新系統串接資料嗎?
可以。當內部老舊系統沒有 API、原廠已不維護,或只剩終端機介面時,可改用「畫面層」自動化來搬運資料,不必重寫或汰換系統。做法是讓結合大型語言模型與電腦視覺的 AI 代理人像人一樣看畫面、操作介面,把資料擷取出來後再透過 Webhook 打進新系統。換句話說,就是用擬人化操作當作臨時 API。
傳統 RPA 為什麼那麼容易出錯、那麼脆弱?
傳統 RPA 通常綁死在固定座標或固定選擇器上,一旦按鈕位移、版型改版或選擇器變動就會找不到目標而報錯。它也常依賴固定秒數的「硬等待」,網路慢時還沒載入完就去抓,導致抓到空值或錯位資料。此外它缺乏判斷力,遇到非預期彈窗或警告只會卡死或繼續執行,造成錯誤擴散。
AI 視覺辨識為什麼比傳統座標式 RPA 更耐改版?
因為它用語意視覺辨識,判斷依據是「這個元素看起來像什麼、旁邊文字寫什麼、在版面中扮演什麼角色」,而不是絕對座標。因此就算按鈕從左邊換到右邊、甚至換了顏色,它依然認得出來。對 Web 介面還能解析 DOM 結構,即使元素沒有標準 id 或 class,也能透過上下文推斷出該抓取的資料節點。
用 AI 代理人串接資料會有資安外洩疑慮嗎?
可透過部署方式來控管。這類工具支援企業地端部署(On-premise)或在 VPC 隔離環境執行,讓視覺解析與資料擷取都鎖在企業內部網路進行,不必把機密營業資料上傳到公共雲。
舊系統有兩階段驗證(2FA),還能自動登入嗎?
可以。可透過串接內部信箱讀取驗證碼,或整合企業的 TOTP(基於時間的一次性密碼)產生器,在登入流程中自主填入驗證碼完成登入。實務上建議把驗證來源直接設計成流程中的一個步驟,而非事後補救。
~/roamer-tech/newsletter // FREE
// newsletter

訂閱免費電子報

把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧,整理成電子報寄給你。只寄精選內容、不灌垃圾信,一鍵就能退訂。

$
// final.exec()

準備好讓你的網站開始為你工作了嗎?