把人放進迴圈:需要確認的動作該怎麼設計
刪除資料、寄信、付款這類動作不該由 Agent 自行決定。這篇是確認機制的實作模式。
Agent 越有能力,誤動作的代價越高。判斷標準很簡單:這個動作能不能輕易復原。不能的,就要人確認。
把工具分成兩類
- 唯讀工具:查詢、計算、搜尋。自動執行。
- 有副作用工具:寫入、刪除、寄送、付款、對外發布。需要確認。
TOOLS = {
'search_orders': {'fn': search_orders, 'confirm': False},
'cancel_order': {'fn': cancel_order, 'confirm': True,
'preview': lambda a: f"將取消訂單 {a['order_no']},此操作無法復原。"},
}中斷與續跑
需要確認時,把當前狀態序列化存起來並回傳待確認事項;使用者同意後再從斷點續跑。這代表 Agent 的狀態必須是可序列化的。
if TOOLS[call.name]['confirm']:
token = store.save({'messages': messages, 'pending': call.as_dict()})
return {'status': 'need_confirm',
'preview': TOOLS[call.name]['preview'](call.arguments),
'resume_token': token}確認畫面要顯示什麼
- 具體動作,用使用者的語言而非工具名稱。
- 受影響的對象,例如訂單編號、收件人、金額。
- 是否可復原,不可復原要明講。
- Agent 的理由,讓使用者判斷是不是誤解了需求。
不要用「是否繼續?」這種空泛問法。使用者連續按了幾次確認之後就會變成無意識點擊,等於沒有這道關卡。