先補斷點
r/openclaw 上那篇問「真的有人在小公司上線 agent 嗎」的文，我看了兩遍。
不是因為很新鮮，是因為討論裡那個 MSP 的例子說到點了。helpdesk ticket system 跟 ERP 完全不互通，人工撈資料對數字算 margin，每次都是在重複做同一件事。裝了 openclaw 加上 Deepseek，一個週末、大概 10 美元 token，把這個 bridge 跑起來了。
這種場景我帶 backend team 的時候見過很多次。不是沒有 API，是沒有人有資源去接它。外包報價不合，內部工程師永遠排不到，斷點就靠人工撐著，常常撐了好幾年。
agent 接進來之後真正有感的地方，就是這些原本沒有預算去接的斷點，現在能動了。從客戶 email 直接建 client record 和 quote、每天跑 ticket 摘要、批次整理過期 product category，這些聽起來不性感，但落地難度最低，業務最快買單。填的不是「理論上可以更好」的坑，是「一直在燒人工時數」的坑。這個差別比任何 fancy autonomy demo 都更能讓非技術主管點頭。
OCR 跟 data extraction workflow 也有人做起來，省了不少人工錄資料的時間。但有一個問題要注意：agent 的記憶會掉，context 邊界怎麼管需要想清楚，不然跨 session 的任務就會出問題。Slack integration 的設定也比想像中麻煩，如果你的通知鏈走 Slack，把設定時間算進去。
真正麻煩的事，是維護。
第一個是 agent debt。你接了多少 skills、多少 workflow，每個都是一個需要維護的單元。底層模型版本換了、第三方 API schema 改了、工具回傳格式變了，之前寫的那些全部得重新確認一遍。這跟 technical debt 的性質完全一樣，但在導入的時候幾乎沒有人把它算進去。
第二個是 token billing。幾個月後 agent 被接到更複雜的流程，或更多人開始用，成本就不是 10 美元了。建議從一開始就把 billing 走自己控制的 gateway，至少你知道哪個 workflow 最貴、哪個 prompt 可以壓縮。走第三方直接帳單，帳單來了你只知道花了多少，不知道去哪裡優化。
第三個是 skills 的修改權限。使用者能不能改、誰可以改，這個問題容易被跳過，但答案不同，整個維護模型就不一樣。沒想清楚就上線，三個月後你會有一堆不知道是誰改了什麼的 skills，然後開始追 regression。坑我踩過。
原文的 OP 說最想知道的是 audit、handoff、maintenance，六個月後還活著的是什麼。這個問法比大多數人深。一般人問「能不能用」，他問「能不能撐」。
agent 能不能撐過六個月，跟 demo 好不好看關係不大，跟你有沒有在上線前回答這幾件事關係比較大。流程的斷點在哪裡、agent 接的是哪一段，scope 越窄越好維護。誰負責維護，不是「哪個部門在用」，是哪個人要 on-call。token 成本走哪條路、誰看得到帳。Skills 的修改權限先定好。
這四件事清楚了，demo 才比較有機會變 production。不然就是替公司做了一個維護成本很高的 prototype，跑半年後沒人理，然後有人說「AI 在實務上沒什麼用」。
作者：鍵盤工人