AI agent 進公司的第一步，是找出有多少事情是靠「人記得」才能跑的
我在 SRE 工作有個習慣，叫做找「toil」，就是那些人工、重複、沒有持久價值的工作，找出來才能考慮自動化。但 AI agent 導入之前要做的準備，比找 toil 難，因為你要找的是那些靠人腦記憶才能維持運轉的流程。
小公司尤其這樣。業務邏輯不在 SOP 裡，不在文件裡，在某個做了十幾年的老員工腦子裡。哪幾種貨走哪條路，哪個客戶在意哪種包裝，例外狀況發生時要打電話給誰。一旦要讓 agent 接手或輔助這些工作，這些隱性知識就必須先挖出來，變成可以被查驗的東西。
這個 discovery 過程，往往比後面的技術設定花更多時間，也更容易被跳過。
我看到一個 solo builder 分享他幫一間小型物流公司設計 AI assistant 的思路。做法很保守，agent 只讀公司資料、起草 proposal，由人確認後才執行。他最在意的是 audit trail、交接點，以及六個月後系統還在不在。有人提到類似場景，把 helpdesk ticket 跟 ERP 串起來讓 agent 算毛利，原本手動太花時間所以就沒在做，現在一個週末加幾美元 token 就跑起來了。
這個例子讓我想到，它之所以能成立，前提是那間公司的 ERP 分類是準確的。但我遇過不少公司，用了十五年以上的舊系統，分類早就是一人一個理解，有些欄位的定義連老員工自己都說不清楚。agent 接進去之前如果沒有認真做 data audit，算出來的毛利是幻覺，看起來有在動，跑的是錯的東西。
交接點的設計，是另一個常被低估的地方。
handoff 就是人和 agent 之間的交棒點。設計不清楚的系統，你不知道什麼時候 agent 在等你，什麼時候它已經自己決定了。這種模糊的邊界持續一段時間之後，使用者會習慣不理，直到出錯才回來看。
那個物流公司的設計多了一個確認步驟，看起來多餘，但這個步驟讓系統有一個明確的邊界，出問題知道去哪裡找。另外有一個觀點我覺得也是在解同一個問題，把 agent 隔離在獨立的 network 之外，用 app 當 parser 跟 submitter，讓每個動作都有清楚的入口跟出口，workflow 才不會漂移。每個動作留 trace，才有東西可以 audit。
維護責任要一開始就講清楚，這件事通常沒人提，然後半年後翻車。
agent debt 是真的，跟 tech debt 一樣積累。skill 設定要不要讓使用者自己改、改的人要懂原始設計的假設、要知道 prompt 背後的業務邏輯、要測過改完之後有沒有壞掉其他地方。很多小公司沒有這樣的人，或是原來設計的人已經離職了。token billing 走自己控制的 gateway 這件事，不只是省錢，是你要有地方可以看 agent 在做什麼決定，有 audit trail，維護才有著力點。
我整理下來的判斷是，human-in-the-loop 的設計，讓系統有可以被維護的邊界。功能全自動可以很炫，但六個月後如果沒有人能看懂它在做什麼、沒有人知道要怎麼改，這個部署就死掉了。保守的設計是讓案子活得久的基本條件，不是技術不成熟的妥協。
認真做 data audit、清楚設計 handoff、一開始就把維護責任定義好，這三件事比模型選哪個更影響最終能不能撐過第一年。
作者：承翰