Agent 做髒活，人拍板。這個公式看起來很土，但確實留下來了。
說真的，我以前也是那個在追全自動的人。感覺 agent 嘛，如果還要人一直干預，那幹嘛叫 agent。
最近在 r/openclaw 看了一串大家分享真實使用場景的討論，有個感覺越來越強：留下來的東西，幾乎都不是全自動的。
客服這條線最典型。ticket 一進來，agent 先去歷史工單、客戶合約、產品文件翻一遍，幫客戶回一封「我們收到了，大概這樣」的初稿，同時把 brief 整理好給 product team 看。到這裡，agent 沒有做任何「決定」的事。真正要決定怎麼處理，是靠 approval card，讓人進去選要往哪個方向走。
approval card 這個設計我覺得是整件事的靈魂。不是讓 agent 幫你決定，是讓 agent 把跨系統的資料搬過來、整理好、列出選項，然後人來簽。agent 的工作是做到「你可以在三十秒內做決定」的程度，你的工作是最後那個判斷。
這樣分工聽起來很普通，但真的很穩。SLA 快到了自動 flag、開 dev work item 前讓人過一眼、回覆客戶前有人先看一下。每個節點 agent 省你時間，但責任很清楚在哪裡。
bug 那條線也是同一個邏輯。agent 幫你重現問題、跑 smoke test、甚至開小範圍的 PR，但 merge 還是要人按。這不是不信任 agent，是出問題的時候要知道誰要負責。全自動的版本如果壞了，你連要從哪裡開始查都不知道。
我覺得最有意思的是那個 MSP helpdesk 的案例。有人把 OpenClaw 拿去串 helpdesk、ERP、報價系統、工時追蹤、還有 OCR 進來的文件，花不到一個週末，token 成本大概十塊美金，就把之前要跨系統手動填的東西打通了。
這件事帥嗎。不帥，一點都不帥。串的都是很老的系統，邏輯也不複雜。
但 biz dev 願意上船的原因是這個：把一封客戶 email 貼進去，就能自動建客戶資料和報價單。不需要全自動，只需要讓人少做十幾個複製貼上。
我現在的判斷是這樣。agent workflow 能活下來的，通常是把「人一定要出現的節點」搞清楚的設計。agent 跑前段，人卡在中間拍板，agent 再接著跑後段。這個結構比「全自動跑完」的版本穩，也容易 debug、也容易說清楚責任在哪。
全自動確實存在，但那些場景通常是低風險、可逆、或出錯成本很低的東西。稍微有點後果的決定，幾乎所有真的在跑的 workflow 都留了 human-in-the-loop。只是很多人沒意識到，這才是他們的 workflow 真正撐得住的原因。
把責任界線切清楚比追全自動更難，也更有用。先讓 agent 做髒活、整理、跨系統搬運，讓人的判斷落在真正值得花腦力的地方，這個邏輯看起來很土，但確實留下來了。
作者：島民No.9527