設計 agent 的 handoff 機制，比讓它學會做事更難
做 AI 產品這幾年，遇到最多的討論都集中在「能力」那塊，這個模型支不支援 function call、那個架構能不能做 multi-agent。但真正走到商業部署，我越來越覺得能力不是最難的部分。
有一個物流業務的 agent 部署案例讓我很有感觸。那個人採保守策略：agent 只讀取業務資料、起草 proposal，所有實際決策和執行都保留在人手上。正式上線之前還打算做一輪 audit/discovery，去估算維護成本和常見故障模式。
看起來很保守，但他設計得比很多「功能更強」的系統更清楚。他解的不是「讓 agent 更聰明」，而是「當系統輸出有問題時，人在哪裡接住」。
這個 draft proposal + human review 的設計，從 throughput 角度看不是最優的。人工審核就是個瓶頸，業務量大起來這塊很快會成為卡點。但它的好處是 audit trail 清楚，stakeholder 心理安全感高，而且 failure mode 很好預測。agent 起草錯了，review 的人接住；review 沒接住，問題也留在人的操作記錄裡，可以回溯。
問題是，很多部署案例在設計 agent 時，從來沒有把「接住的點」設計清楚。
另一個讓我印象深的是 multi-agent 架構的卡死問題。表面上，把任務分給幾個 agent 跑起來很順，直到遇到 long-running project，整個流程開始 stall。一個具體情況是這樣的：supervisor agent 知道有個子流程卡住了，但流程規則裡沒有定義那個狀況的 off-ramp，系統就停在那邊，不繼續也不 escalate，就這樣卡著。
這是個很典型的 undefined off-ramps 問題。設計 multi-agent 的人通常把精力放在 happy path：各 agent 怎麼分工、任務怎麼傳遞、中間狀態怎麼維護。但遇到例外時，流程往哪裡走、誰來介入、介入的 trigger 是什麼，這些往往是最後才想，或乾脆沒想。在 production 環境裡，exception 不是邊緣情況，它就是主幹。業務越複雜，exception 頻率越高。
從產品面來拆，我覺得商業部署 agent 有三個東西必須在上線前想清楚。
第一個是 handoff 點的定義。不只是「人在哪裡確認」，而是明確的 trigger condition：什麼情況下 agent 自走，什麼情況下進 human review queue，什麼情況下要 escalate 給特定人。條件越模糊，實際運作越容易爛掉。
第二個是 control surface 的可見度。supervisor agent 看得到卡住，這很好，但不夠。你還需要讓人類操作員也能清楚看到哪裡卡住、卡了多久、影響哪些下游。audit/discovery 那個環節就是在建立這個可見度的基線，不只是上線前的測試，而是讓你真正理解 failure surface 在哪裡。
第三個是 maintenance cost 要在前面估，不是上線後才算。維護成本的大頭通常不是正常監控，而是 exception handling。每個 undefined off-ramp，上線之後都是一個需要人工介入的 ticket，積久了就是隱形的維運債。
Trade-off 很實際：給 agent 更多自主性，人工成本下降，但 control surface 變薄，風險也跟著上去。保守設計讓 handoff 清晰，但 throughput 受限，人一旦成為瓶頸，效率優勢就縮水了。選哪邊沒有通用解，取決於你的業務對錯誤的容忍度、以及你的 stakeholder 對 agent 的信任程度有多高。
但在選方向之前，至少要能回答一個問題：如果 agent 今天做出了一個錯誤的決定，流程裡有沒有一個地方可以抓住它，而且那個地方是有人在守的。
這個問題答不出來，agent 能力再強都不算準備好了。
作者：MingTech