我一直有個疑問：我們店裡已經用了好幾年的 ERP 和訂單流程，要導入 AI，是不是一定要整個打掉重練？

最近在 arXiv 上看到一篇論文，講的是怎麼把既有的 workflow engine 升級成 agentic BPM，不用換掉原本的系統。讀完之後我的感想是：工程師世界在煩惱的問題，跟我們開店的人其實一模一樣。

論文提出了一個概念叫 process harness，概念是說：讓 AI agent 只在特定的「控制點」介入，其他地方還是讓原本的系統跑。他們把任務拆成三層，大概是「執行型 agent、決策型 agent、流程管理型 agent」，各自有各自的職責，不讓一個 agent 包辦所有的事。

用貸款審核當例子：計算信用分數是一回事，「要不要批」是另一回事，遇到法規特殊狀況又是另一回事。這三層各自找 AI 介入，比全部丟給一個大 agent 更穩、更好追蹤。

這跟我在店裡的感受非常像。

我們客服的流程已經跑了五年，雖然不算很酷，但規則都在上面。哪種退貨要走哪個流程、哪種客訴要升級給主管、哪些節日要特別處理，這些都是累積出來的「隱性知識」。

如果叫我今天全部砍掉、換一套「全 AI 的客服系統」，我光想就頭痛。

但如果是說：「你現有的流程不用動，只是在『退貨理由判斷』這個節點插一個 AI，讓它幫你分類，不確定的才丟給人工」，這個我可以考慮。

這就是 process harness 概念吸引我的地方。它不是說 AI 要取代你的流程，而是說：原有系統繼續掌管結構控制，AI 只在你指定的地方出手。

對小公司來說，這個思路比「全面 AI 化」現實太多了。

我們沒有工程師團隊去重寫整套系統，也沒有預算去試一個不知道會不會成功的大翻新。但我們可以：找出流程裡判斷最花時間、出錯最多的那幾個節點，先在那裡試試看 AI 能不能幫忙。

比如說：哪些訂單是高風險？哪些客戶的問題需要人工回覆、哪些可以自動處理？哪些商品組合的退貨率特別高，可以預先警告？

這些都是「決策點」，不是整條流程。

論文裡還有一個細節讓我印象深刻：他們用可以版本控管的 markdown 檔管理 AI 的 policy。意思是說，AI 怎麼判斷、遵守什麼規則，是明文寫出來的，可以被修改、被追蹤。

這個對非工程師背景的我來說很有感。你不希望 AI 是個黑盒子，你希望它像一個新員工，有 SOP 可以查、有規則可以改。

說真的，AI 導入最怕的不是技術，是老闆不知道從哪裡開始、又怕改了之後系統壞掉。

這篇論文給了我一個答案：不用從頭開始，先找出你最想解決的那一個決策點，在那裡插入 AI，看看結果。夠好再往下一個走。這才是小公司能真正做到的節奏。